Глава 2. RSVP

Разное

MPLS метки:

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

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

LDP - автоматом строит full mesh туннели до соседей. RSVP - не просто строит туннели, а использует для построения TE + используются механизмы зачиты трафика: FastRerote, LinkProtection... RSVP - протокол signaling. 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.

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

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

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

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 протоколы.