Глава 2. RSVP: различия между версиями

Материал из Juniper Exam Wiki
Перейти к навигации Перейти к поиску
Строка 54: Строка 54:
# inet.0: 192.168.0.4: -> BGP, push 30
# inet.0: 192.168.0.4: -> BGP, push 30


На этом туннель считается построенным. Туннель - это просто метки.
На этом туннель считается построенным.  
{{note|text=Туннель - это просто набор меток.}}


'''resvMessage''' должен пройти по тому же пути, что и '''pathMessage'''.
'''resvMessage''' должен пройти по тому же пути, что и '''pathMessage'''.
Строка 68: Строка 69:


Туннель может устанавливаться с требованиями к полосе.
Туннель может устанавливаться с требованиями к полосе.
Задается в bandwith - передается в объекте TSpec.  
Задается в bandwidth - передается в объекте TSpec.  
{{note|text= bandwidth - только для сигнализации, реально полосу не ограничивает }}


Если RSVP не может установить туннель, то на проблемном участке генерируется '''pathErr''' - сообщение с кодом ошибки.
Если RSVP не может установить туннель, то на проблемном участке генерируется '''pathErr''' - сообщение с кодом ошибки.
Bandwith - только для сигнализации, реально полосу не ограничивает.


Если нужно провести траблшутинг, лучше делать тут:  
Если нужно провести траблшутинг, лучше делать тут:  

Версия 20:45, 28 июня 2020

Разное

MPLS метки:

  • label 0 - implicit null
  • label 3 - explicit null

Принцип работы протокола

LDP - автоматом строит full mesh туннели до соседей.

RSVP - не просто рандомно строит туннели, а использует для построения TE + используются механизмы зашиты трафика: FastRerote, LinkProtection...

RSVP - сигнальный протокол.

RSVP инкапсулируется сразу в ip.

RSVP-пакет стоит из объектов.

Объект имеет тип, и поле данных.

Для работы RSVP нужно:

  1. Включить протокол RSVP
  2. Конфигурируем туннель только на ingress.

Ingress -> Egress: При построении туннеля на Ingress (A) создается ip-пакет pathMessage, который состоит из:

  1. dst: ip dst (192.168.0.4), по метриками внутреннего протокола узнает где конечный роутер.
  2. session ID - идентификатор rsvp сессии на уровне control plane. Все rsvp роутеры, через которые строится туннель - ассоциируют все сообщения для туннеля по session ID. Генерируется ingress роутером, состоит из router ID + какое-то число.
  3. label request: определяет поведение транзитных маршрутизаторов, заставляет резервировать метки для туннеля.

Transit router 1 (B):

  1. Видит label request, выделяет (запоминает, но никуда не записывает) для туннеля метки из свободных, ассоциирует ее с session ID.

Transit router 2 (C):

  1. Видит label request, выделяет (запоминает, но никуда не записывает) для туннеля метки из свободных, ассоциирует ее с session ID.

Egress router (D):

  1. dst addres = его loopback => он последний. Резервирует метку 3 (по дефлоту).

Формирует ResvPath - основная его суть - проанонсировать зарезервированные метку предыдущему роутеру.

Egress -> Ingress: resvPath: session ID из PathMessage, label: (то, что он зарезервировал) 3.

Transit 2 (C):

  1. По session ID определяет какую метку он зарезервировал (30).
  2. Смотрит в label, видит 3. Понимает, что он должен передавать к egress пакет с меткой 3.
  3. mpls.0: 30 swap 3 = 30 pop

Transit 1 (B):

  1. По session ID определяет какую метку он зарезервировал (20).
  2. Смотрит в label, видит 30. Понимает, что он должен передавать к egress пакет с меткой 30.
  3. mpls.0: 20 swap 30

Ingress (A):

  1. inet.0: 192.168.0.4: -> BGP, push 30

На этом туннель считается построенным.

Туннель - это просто набор меток.

resvMessage должен пройти по тому же пути, что и pathMessage. Но маршрутизация может быть не симметричной, поэтому при построении туннеля адреса роутеров записываются в RRO (record route) объект. Каждый роутер при прохождении pathMessage добавляет в RRO адрес своего исходящего интерфейса => resvMessage будет знать обратный путь. Также предотвращает зацикливание.

При падении линка между роутерами: Генерируются pathTear (в сторону ingress) и resvTear (в сторону egress), чтобы все транзитные роутеры освободили метки, а ingress понял, что этого туннеля больше нет.

В это время IGP пересчитало топологию, ingress router увидел next-hop для egress роутера и RSVP заново начал строить туннель.

Keepalive: Ingress роутер 1 в 30 сек (по дефолту) обновляет состояние с помощью посылки pathMessage.

Туннель может устанавливаться с требованиями к полосе. Задается в bandwidth - передается в объекте TSpec.

bandwidth - только для сигнализации, реально полосу не ограничивает

Если RSVP не может установить туннель, то на проблемном участке генерируется pathErr - сообщение с кодом ошибки.

Если нужно провести траблшутинг, лучше делать тут:

set protocol rsvp traceoptions file RSVP-trouble flag all detail
  • RSVP поддерживает mtu discovery и fragmentstion на ingress роутере.
  • RSVP поддерживает аутентификацию (MD5)
  • RSPV может использовать Gracefull restart.
  • RSVP может работать как point-to-multipoint => можно исключить из ядра всякие multicast протоколы.