Глава 2. RSVP: различия между версиями
Строка 8: | Строка 8: | ||
= Принцип работы протокола = | = Принцип работы протокола = | ||
LDP - автоматом строит full mesh туннели до соседей. | LDP - автоматом строит full mesh туннели до соседей. | ||
RSVP - не просто строит туннели, а использует для построения TE + используются механизмы | RSVP - не просто строит туннели, а использует для построения TE + используются механизмы зачиты трафика: FastRerote, LinkProtection... | ||
RSVP - протокол signaling. | RSVP - протокол signaling. | ||
RSVP инкапсулируется сразу в ip. | RSVP инкапсулируется сразу в ip. | ||
Строка 20: | Строка 20: | ||
'''Ingress -> Egress:''' | '''Ingress -> Egress:''' | ||
При построении туннеля на Ingress (A) создается ip-пакет pathMessage, который состоит из: | При построении туннеля на Ingress (A) создается ip-пакет pathMessage, который состоит из: | ||
# '''dst''': ip dst (192.168.0.4), по метриками внутреннего протокола узнает где конечный роутер. | |||
# '''session ID''' - идентификатор rsvp сессии на уровне control plane. Все rsvp роутеры, через которые строится туннель - ассоциируют все сообщения для туннеля по session ID. Генерируется ingress роутером, состоит из router ID + какое-то число. | |||
# '''label request''': определяет поведение транзитных маршрутизаторов, заставляет резервировать метки для туннеля. | |||
'''Transit router 1 (B):''' | '''Transit router 1 (B):''' | ||
1.Видит label request, выделяет (запоминает, но никуда не записывает) для туннеля метки из свободных, ассоциирует ее с session ID. | 1.Видит ''label request'', выделяет (запоминает, но никуда не записывает) для туннеля метки из свободных, ассоциирует ее с ''session ID''. | ||
'''Transit router 2 (C):''' | '''Transit router 2 (C):''' | ||
# Видит ''label request'', выделяет (запоминает, но никуда не записывает) для туннеля метки из свободных, ассоциирует ее с ''session ID''. | |||
'''Egress router (D):''' | '''Egress router (D):''' | ||
# ''dst addres'' = его loopback => он последний. Резервирует метку 3 (по дефлоту). | |||
Формирует ResvPath - основная его суть - проанонсировать зарезервированные метку предыдущему роутеру. | Формирует '''ResvPath''' - основная его суть - проанонсировать зарезервированные метку предыдущему роутеру. | ||
'''Egress -> Ingress:''' | '''Egress -> Ingress:''' | ||
Строка 39: | Строка 39: | ||
'''Transit 2 (C):''' | '''Transit 2 (C):''' | ||
# По session ID определяет какую метку он зарезервировал (30). | |||
# Смотрит в label, видит 3. Понимает, что он должен передавать к egress пакет с меткой 3. | |||
# mpls.0: 30 swap 3 = 30 pop | |||
'''Transit 1 (B):''' | '''Transit 1 (B):''' | ||
# По session ID определяет какую метку он зарезервировал (20). | |||
# Смотрит в label, видит 30. Понимает, что он должен передавать к egress пакет с меткой 30. | |||
# mpls.0: 20 swap 30 | |||
'''Ingress (A):''' | '''Ingress (A):''' | ||
# inet.0: 192.168.0.4: -> BGP, push 30 | |||
Туннель - это просто метки. | Туннель - это просто метки. |
Версия 00:35, 4 ноября 2016
Разности
MPLS
- label 0 - implicit null
- label 3 - explicit null
Принцип работы протокола
LDP - автоматом строит full mesh туннели до соседей. RSVP - не просто строит туннели, а использует для построения TE + используются механизмы зачиты трафика: FastRerote, LinkProtection... RSVP - протокол signaling. RSVP инкапсулируется сразу в ip. RSVP пакет стоит из объектов. Объект имеет тип, и поле данных.
Для работы RSVP нужно:
- Включить протокол RSVP
- Конфигурируем туннель только на ingress.
Ingress -> Egress: При построении туннеля на Ingress (A) создается ip-пакет pathMessage, который состоит из:
- dst: ip dst (192.168.0.4), по метриками внутреннего протокола узнает где конечный роутер.
- session ID - идентификатор rsvp сессии на уровне control plane. Все rsvp роутеры, через которые строится туннель - ассоциируют все сообщения для туннеля по session ID. Генерируется ingress роутером, состоит из router ID + какое-то число.
- label request: определяет поведение транзитных маршрутизаторов, заставляет резервировать метки для туннеля.
Transit router 1 (B): 1.Видит label request, выделяет (запоминает, но никуда не записывает) для туннеля метки из свободных, ассоциирует ее с session ID.
Transit router 2 (C):
- Видит label request, выделяет (запоминает, но никуда не записывает) для туннеля метки из свободных, ассоциирует ее с session ID.
Egress router (D):
- dst addres = его loopback => он последний. Резервирует метку 3 (по дефлоту).
Формирует ResvPath - основная его суть - проанонсировать зарезервированные метку предыдущему роутеру.
Egress -> Ingress: resvPath: session ID из PathMessage, label: (то, что он зарезервировал) 3.
Transit 2 (C):
- По session ID определяет какую метку он зарезервировал (30).
- Смотрит в label, видит 3. Понимает, что он должен передавать к egress пакет с меткой 3.
- mpls.0: 30 swap 3 = 30 pop
Transit 1 (B):
- По session ID определяет какую метку он зарезервировал (20).
- Смотрит в label, видит 30. Понимает, что он должен передавать к egress пакет с меткой 30.
- mpls.0: 20 swap 30
Ingress (A):
- inet.0: 192.168.0.4: -> BGP, push 30
Туннель - это просто метки.
При падении линка между роутерами: Генерируются pathTear (в сторону ingress) и resvTear (в сторону egress), чтобы все транзитные роутеры освободили метки, а ingress понял, что этого туннеля больше нет.
В это время IGP пересчитало топологию, ingress router увидел next-hop для egress роутера и rsvp заново начал строить туннель.
Keepalive: Ingress роутер 1 в 30 сек (по дефолту) обновляет состояние с помощью посылки pathMessage.
resvMessage должен пройти по тому же пути, что и pathMessage. Но маршрутизация может быть не симметричной. отличие resv и path: dst add - не loopback конечных роутеров, а адрес предыдущего роутера из ERO (также предотвращает зацикливание).
Туннель может устанавливаться с требованиями к полосе. Задается в bandwith - передается в объекте TSpec.
Если RSVP не может установить туннель, то на проблемном участке генерируется patheErr - сообщение с кодом ошибки. 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 протоколы.