# RSVP ![](/files/-MZIJVBtZjR0Sf-W5C_I) ## 1. Краткие сведения и настройка Для RSVP используем аналогичную схему. RSVP позволяет: использовать резервирование ширины канала для определённого LSP, строить LSP вне зависимости от IGP Best Path, использовать CoS и прочие вещи необходимые для TE. Настройку LDP можно оставить, так как согласно тблице [Default Preference](https://www.juniper.net/documentation/en_US/junos/topics/reference/general/routing-protocols-default-route-preference-values.html) у RSVP ниже, чем у LDP. То-есть для FEC будет более предпочтителен маршрут, построенный при помощи RSVP. Ради прмера, настроим LSP, идущий по маршруту M34-M9-OBV-MIR-LNX. Сделать это можно при помощи ERO. Выглядит это примерно так: 1\) Loose = OBV 2\) Strict = MIR, LNX Loose говорит, что до точки можно построить путь по IGP. Strict указывает на следующий hop без оглядки на IGP. То-есть нельзя указать Loose OBV, Strict LNX. Эта конфигурация работать не будет. Настраиваем RSVP: ``` root@RT.MSK.M34# show | compare [edit protocols] + rsvp { + interface all; ##Включаем работу RSVP на всех интерфейсах + } + mpls { + path-mtu { + allow-fragmentation; ##Разрешаем фрагментировать пакет до его пометки + rsvp mtu-signaling; ##Позволяет RSVP вычислить минимальный MTU на пути + } + no-cspf; ##Отключаем динамический TE + label-switched-path M34-LNX { ##Указываем имя пути + to 192.168.0.8; ##Loopback-адрес Egress-роутера + corouted-bidirectional; ##Указываем, что это двунаправленный LSP + bandwidth 150m; ##Проверяем доступную ширину канала + oam { + bfd-liveness-detection { ## Настраиваем BFD + minimum-interval 1000; ##Раз в секунду послылаем Hello + multiplier 3; ##Если за время 3х1000мс нет ответа, то разрываем + failure-action teardown; ##LSP и пытаемся снова его построить + } + } + ultimate-hop-popping; ##Снимаем метку на последнем хопе + primary l_MIR-s_OBV,LNX; ##Указываем основной путь + } + path l_MIR-s_OBV,LNX { ##указываем ERO. Порядок важен + 10.0.0.24 loose; + 10.0.0.25 strict; + 10.0.0.27 strict; + } + interface all; ##Для работы RSVP нужно включить интерфейсы ещё в MPLS + } ``` На остальных устройствах просто включам все интерфейсы в RSVP, MPLS и указываем Family MPLS. Некоторые примечания по настройке: * Двунаправленный LSP позволяет произвести настройку LSP только на Ingress. При этом трасстровку и проверку мы сможем делать только на Ingress, но трафик будет ходить в обе стороны. * Проверка на ширину канала не ограничивает пропускную способность, а только проверяет её достпность. Есть проверка не пройдена, то RSVP не сможет построить LSP. * Ultimate-Hop-Popping необходим для поддержки CoS. Т.е. если метка снимается на предпоследнем хопе, то и информация об очереди теряется на нём же. Тут просто для примера. ## 2. Проверка работы LSP А теперь проверим прохождение трафика в обе стороны. Отключим LDP на граничных устройствах: ``` root@RT.MSK.M34# deactivate protocols ldp root@RT.SPB.LNX# deactivate protocols ldp root@RT.SPB.LNX# run show route 140.0.0.1 inet.0: 30 destinations, 30 routes (30 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 140.0.0.0/16 *[BGP/170] 05:49:49, localpref 100, from 192.168.0.1 AS path: 400 I, validation-state: unverified > to 10.0.0.26 via ge-0/0/1.0, label-switched-path M34-LNX ``` Видим, что на Egress у нас указан наш LSP. А теперь запустим трассировку, но сделаем это со стороны Downstream'а (Egress-роутера), предварительно сняв дамп на интерфейсе Ge-0/0/1 RT.SPB.LNX. Вот что мы увидим: ``` root@AS600# run traceroute monitor 140.0.0.1 source 160.0.0.1 My traceroute [v0.69] AS600 (0.0.0.0)(tos=0x0 psize=64 bitpattern=0x00) Tue Apr 27 15:02:52 2021 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 60.0.0.1 0.0% 13 2.5 2.1 1.2 2.8 0.6 2. ??? 3. ??? 4. ??? 5. 10.0.0.0 0.0% 12 3.3 4.2 3.2 6.4 1.1 6. 140.0.0.1 0.0% 12 5.0 5.1 4.1 6.3 0.7 ``` ![](/files/-MZIs1yOxxmnq2VdUeYj) Ответы и запросы приходят на ожидаемом интерфейсе с меткой, а значит трафик посылается так как мы и хотели - в обе стороны по MPLS. Можно обратно включать LDP и проверять как работает RSVP-сессия Иногда может понадобиться очистить сессию и перепостроить путь не дожидаясь таймеров: ``` root@RT.MSK.M34> clear rsvp session ``` Проверка LSP. Тут мы отфильтровали LSP по имени и вывели только LSP, которые были построены от этого роутера: ``` root@RT.MSK.M34> show mpls lsp name M34-LNX ingress Ingress LSP: 1 sessions To From State Rt P ActivePath LSPname 192.168.0.8 192.168.0.1 Up 0 * l_MIR-s_OBV,LNX M34-LNX Bidir Total 1 displayed, Up 1, Down 0 ``` Просто вывести список LSP: ``` root@RT.SPB.LNX> show mpls lsp Ingress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress LSP: 1 sessions To From State Rt Style Labelin Labelout LSPname 192.168.0.8 192.168.0.1 Up 0 1 FF 300016 - M34-LNX Bidir Total 1 displayed, Up 1, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0 ``` Можно произвести трассировку, если нам нужно узнать по какому пути пойдёт трафик (Можно сделать только на Ingress-роутере): ``` root@RT.MSK.M34> traceroute mpls rsvp M34-LNX Probe options: retries 3, exp 7 ttl Label Protocol Address Previous Hop Probe Status 1 299968 RSVP-TE 10.0.0.1 (null) Success 2 299968 RSVP-TE 10.0.0.17 10.0.0.1 Success 3 299984 RSVP-TE 10.0.0.25 10.0.0.17 Success 4 300016 RSVP-TE 10.0.0.27 10.0.0.25 Egress Path 1 via ge-0/0/3.0 destination 127.0.0.64 ``` Можно посмотреть сессии: ``` root@RT.MSK.M34> show rsvp session Ingress RSVP: 1 sessions To From State Rt Style Labelin Labelout LSPname 192.168.0.8 192.168.0.1 Up 0 1 FF - 299968 M34-LNX Bidir ``` И зарезервированную полосу пропускания: ``` root@RT.MSK.M34> show rsvp interface RSVP interface: 5 active Active Subscr- Static Available Reserved Highwater Interface State resv iption BW BW BW mark ge-0/0/0.0 Up 0 100% 1000Mbps 1000Mbps 0bps 0bps ge-0/0/1.0 Up 0 100% 1000Mbps 1000Mbps 0bps 0bps ge-0/0/2.0 Up 0 100% 1000Mbps 1000Mbps 0bps 0bps ge-0/0/3.0 Up 1 100% 1000Mbps 850Mbps 150Mbps 150Mbps lo0.0 Up 0 100% 0bps 0bps 0bps 0bps ``` Более полная информация о LSP: ``` root@RT.MSK.M34> show mpls lsp name M34-LNX ingress extensive Ingress LSP: 1 sessions 192.168.0.8 From: 192.168.0.1, State: Up, ActiveRoute: 0, LSPname: M34-LNX Bidirectional ActivePath: l_MIR-s_OBV,LNX (primary) LSPtype: Static Configured, Ultimate hop popping LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary l_MIR-s_OBV,LNX State: Up Priorities: 7 0 Bandwidth: 150Mbps SmartOptimizeTimer: 180 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 10.0.0.1 10.0.0.17 10.0.0.25 10.0.0.27 OAM state : BFD session up LSP-ping up 12 Apr 27 15:13:09.088 Selected as active path 11 Apr 27 15:13:09.073 Record Route: 10.0.0.1 10.0.0.17 10.0.0.25 10.0.0.27 10 Apr 27 15:13:09.073 Up 9 Apr 27 15:13:08.841 Deselected as active 8 Apr 27 15:13:08.840 Originate Call 7 Apr 27 15:13:08.840 Call was cleared by RSVP 6 Apr 27 15:13:08.840 Session preempted 5 Apr 27 15:13:08.838 10.0.0.0: Down 4 Apr 27 14:03:33.349 Selected as active path 3 Apr 27 14:03:33.348 Record Route: 10.0.0.1 10.0.0.17 10.0.0.25 10.0.0.27 2 Apr 27 14:03:33.346 Up 1 Apr 27 14:03:32.983 Originate Call Created: Tue Apr 27 14:03:33 2021 Total 1 displayed, Up 1, Down 0 ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://netlabs.gitbook.io/juniper/mpls/rsvp.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.