Глава 2. RSVP

JNCIS content Статья покрывает только курс JNCIS. Возможно, тема представлена детальнее в других разделах. А для JNCIS и этого достаточно. ¯\_(ツ)_/¯

Разное

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 - сообщение с кодом ошибки.

• RSVP поддерживает mtu discovery и fragmentation на ingress роутере.
• RSVP поддерживает аутентификацию (MD5).
• RSPV может использовать Gracefull restart.
• RSVP может работать как point-to-multipoint => позволяет исключить из ядра multicast.

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

set protocol rsvp traceoptions file rsvp-trouble flag all detail