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

Материал из Juniper Exam Wiki
Перейти к навигации Перейти к поиску
м
 
(не показаны 3 промежуточные версии этого же участника)
Строка 1: Строка 1:
= Разное =
{{#description2: MPLS метки. Принцип работы протокола RSVP. Построение туннелей в RSVP. Информация для подготовки к экзаменам Juniper.}}
MPLS метки:
{{JNCIS_content}}
==MPLS метки==
* label 0 - implicit null
* label 0 - implicit null
* label 3 - explicit null
* label 3 - explicit null
 
== Принцип работы протокола ==
{{JNCIS_content}}
 
= Принцип работы протокола =
LDP - автоматом строит full mesh туннели до соседей.
LDP - автоматом строит full mesh туннели до соседей.


Строка 15: Строка 13:
RSVP инкапсулируется сразу в ip.
RSVP инкапсулируется сразу в ip.


RSVP-пакет стоит из объектов.
RSVP-пакет стоит из объектов. Объект имеет тип, и поле данных.
 
Объект имеет тип, и поле данных.


Для работы RSVP нужно:
Для работы RSVP нужно:
Строка 83: Строка 79:
Если нужно провести траблшутинг, лучше делать тут:  
Если нужно провести траблшутинг, лучше делать тут:  
  set protocol rsvp traceoptions file rsvp-trouble flag all detail
  set protocol rsvp traceoptions file rsvp-trouble flag all detail
== Дополнительная информация ==
*[[Глава 1. Основы MPLS и VPN]]
*[[Глава 2. Label Distribution Protocols (RSVP, LDP)]]
*[[Реализация MPLS в ядре сети]]

Текущая версия на 17:37, 15 июля 2021

Exclamation point.png 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

Дополнительная информация