MSDP: различия между версиями
м |
|||
(не показано 5 промежуточных версий этого же участника) | |||
Строка 1: | Строка 1: | ||
== | {{#description2:Описание и работа протокола MSDP. Процесс установления сессии. Флудинг SA-сообщений (source-active). FPR-check для SA сообщений (Peer RPF-check). Mesh groups. Настройка. Траблшутинг. Anycast RP. Материалы для подготовки к экзаменам Juniper Networks}} | ||
==Описание и работа протокола MSDP== | |||
Используется только для IPv4. | Используется только для IPv4. | ||
Строка 21: | Строка 22: | ||
При сконфигурированном MSDP также строятся shared tree (от RP к получателю), source tree (от RP к источнику). И также как и в PIM-SM при получении первого мультикаст пакета DR роутером, он пытается построить shortest-path tree. | При сконфигурированном MSDP также строятся shared tree (от RP к получателю), source tree (от RP к источнику). И также как и в PIM-SM при получении первого мультикаст пакета DR роутером, он пытается построить shortest-path tree. | ||
MSPD | MSPD устанавливает соседство, используя TCP (639 порт). Как только установилось соседство между MSDP peers => возможен обмен SA message. | ||
В SA-message содержится: originating RP, source, group. | В SA-message содержится: originating RP, source, group. | ||
Строка 31: | Строка 32: | ||
Состояния: | Состояния: | ||
*Disable: MSDP peer не сконфигурирован. | *'''Disable''': MSDP peer не сконфигурирован. | ||
*Inactive: MSDP peer сконфигурирован, но не слушает или не подключен. | *'''Inactive''': MSDP peer сконфигурирован, но не слушает или не подключен. | ||
*Connect: active MSDP peer пытается установить TCP сессию. | *'''Connect''': active MSDP peer пытается установить TCP сессию. | ||
*Listen: passive MSDP peer сконфигурирован и слушает 639 порт. | *'''Listen''': passive MSDP peer сконфигурирован и слушает 639 порт. | ||
*Established: TCP сессия установлена. | *'''Established''': TCP сессия установлена. | ||
===Флудинг SA-сообщений (source-active):=== | ===Флудинг SA-сообщений (source-active):=== | ||
Строка 43: | Строка 44: | ||
*Если сообщение прошло RPF-check, MSDP peer хранит его в своем кэше (inet.4). Также сообщения пересылаются всем MSDP пирам, за исключением пира, от которого пришло SA. | *Если сообщение прошло RPF-check, MSDP peer хранит его в своем кэше (inet.4). Также сообщения пересылаются всем MSDP пирам, за исключением пира, от которого пришло SA. | ||
clear msdp cache | clear msdp cache | ||
===FPR-check для SA сообщений (Peer RPF-check)=== | ===FPR-check для SA сообщений (Peer RPF-check)=== | ||
Строка 54: | Строка 49: | ||
Проверяется то, чтобы originated RP и MSDP peer сидят за одним интерфейсом, и трафик передается только в сторону от originated RP. | Проверяется то, чтобы originated RP и MSDP peer сидят за одним интерфейсом, и трафик передается только в сторону от originated RP. | ||
{{note|text=Не используется для предоствращения петель! Но за счет того, что некоторые SA отвалятся - уменьшает их количество в сети.}} | |||
''RPF check проходит, если:'' | ''RPF check проходит, если:'' | ||
Строка 73: | Строка 65: | ||
===Mesh groups=== | ===Mesh groups=== | ||
Используют для уменьшения флуда SA сообщений => между MSDP peers внутри mesh group не распространяются SA-message, т.к. смысла в них нет. Все члены Mesh-group получат SA от originating members. | Используют для уменьшения флуда SA сообщений => между MSDP peers внутри mesh group не распространяются SA-message, т.к. смысла в них нет. Все члены Mesh-group получат SA от originating members. | ||
Строка 82: | Строка 73: | ||
*SA, полученные от пиров, не состоящих в группах - подвергаются обычному RPF-check. Если проверка прошла успешно - SA флудятся всем остальным пирам (в других AS и в mesh-group). | *SA, полученные от пиров, не состоящих в группах - подвергаются обычному RPF-check. Если проверка прошла успешно - SA флудятся всем остальным пирам (в других AS и в mesh-group). | ||
=== | ===Конфигурация=== | ||
set protocols msdp local-address 10.200.86.2 | set protocols msdp local-address 10.200.86.2 | ||
set protocols msdp group anycast-rp mode mesh-group | set protocols msdp group anycast-rp mode mesh-group | ||
Строка 171: | Строка 161: | ||
235.4.5.6,10.66.66.2/32*[MSDP/175/1] 00:00:53, from 10.200.86.2 | 235.4.5.6,10.66.66.2/32*[MSDP/175/1] 00:00:53, from 10.200.86.2 | ||
> to 10.200.86.100 via ge-0/0/0.120 | > to 10.200.86.100 via ge-0/0/0.120 | ||
==Дополнительная информация== | |||
*[[Глава 2. Multicast, IGMP]] | |||
*[[Глава 3. Routing protocols (DVMRP, PIM-DM, PIM-SM)]] | |||
*[[Политики в мультикасте | Глава 6. Политики в мультикасте]] |
Текущая версия на 18:38, 15 июля 2021
Описание и работа протокола MSDP
Используется только для IPv4.
Междоменный обмен мультикастом, использующий PIM-SM.
Проблема заключается в том, что если источник и получатель находятся в разных доменах (разные AS в данном случае), то они не смогут "найти друг друга".
+: Каждый ISP сам решает где расположить RP.
+: Между доменами в качестве маршрутизации используется BGP (делаем RPF check). Если топологии unicast и multicast одинаковые - BGP в inet.0. Если разные - MP-BGP в inet.2.
MSDP распространяет информацию от RP об источниках из других доменов (т.к. их меньше в сети, чем получателей), используя Source-active message (SA).
Как это происходит:
- RP (AS1) знает об источнике
- RP (AS1) шлет инфу об источнике к RP (AS2), используя SA message.
- RP (AS2) получает (S,G) и т.о. все получатели смогут соединиться с этим новым источником из другой AS.
Обычно запускается на PIM-SM RP, но можно использовать и на non-RP роутерах.
При сконфигурированном MSDP также строятся shared tree (от RP к получателю), source tree (от RP к источнику). И также как и в PIM-SM при получении первого мультикаст пакета DR роутером, он пытается построить shortest-path tree.
MSPD устанавливает соседство, используя TCP (639 порт). Как только установилось соседство между MSDP peers => возможен обмен SA message.
В SA-message содержится: originating RP, source, group.
Когда у RP в одной AS появляется получатель и нужная группа находится в другой AS, RP как и в PIM-SM начинает слать PIM-join к источнику (в другую AS).
Процесс установления сессии
- Роутер с наибольшим ip становится пассивным и слушает TCP 639 от активных роутеров.
Состояния:
- Disable: MSDP peer не сконфигурирован.
- Inactive: MSDP peer сконфигурирован, но не слушает или не подключен.
- Connect: active MSDP peer пытается установить TCP сессию.
- Listen: passive MSDP peer сконфигурирован и слушает 639 порт.
- Established: TCP сессия установлена.
Флудинг SA-сообщений (source-active):
- Исходное SA сообщение отправляется, когда источник в первый раз зарегистрировался на RP.
- Если источник все еще активен, RP будет отправлять SA сообщения каждые 60 секунд.
- SA сообщения проходят RPF-check, когда прилетают к MSDP peer.
- Если сообщение прошло RPF-check, MSDP peer хранит его в своем кэше (inet.4). Также сообщения пересылаются всем MSDP пирам, за исключением пира, от которого пришло SA.
clear msdp cache
FPR-check для SA сообщений (Peer RPF-check)
SA сообщения флудятся всем пирам, исключая тот, от которого пришло сообщение. SA сообщения обязательно должны пройти RPF check.
Проверяется то, чтобы originated RP и MSDP peer сидят за одним интерфейсом, и трафик передается только в сторону от originated RP.
Не используется для предоствращения петель! Но за счет того, что некоторые SA отвалятся - уменьшает их количество в сети.
RPF check проходит, если:
- Originating RP = MSDP peer данного маршрутизатора.
- SA сообщения получены от non-originating RP:
- сообщение получено от MSDP peer, который является BGP next-hop для originating RP.
- IGP next-hop MSDP peer = next-hop to originating RP.
- MSDP peer находится в последней AS, в AS-path к originating RP.
RPF-check не делается, если:
- SA сообщение от MSDP peer из mesh группы.
- SA сообщение от default MSDP peer. (случай с stub доменом, где используется всего один единственный MSDP peer).
Mesh groups
Используют для уменьшения флуда SA сообщений => между MSDP peers внутри mesh group не распространяются SA-message, т.к. смысла в них нет. Все члены Mesh-group получат SA от originating members.
Обычно используют для intra-domain, потому что SA не проходят RPF-check, а автоматически становятся accept.
Флуд в mesh-groups:
- SA, полученные от соседей по mesh группы не передаются другим членам. Сообщения принимаются и флудятся другим MSDP peers (не из этой же mesh-group).
- SA, полученные от пиров, не состоящих в группах - подвергаются обычному RPF-check. Если проверка прошла успешно - SA флудятся всем остальным пирам (в других AS и в mesh-group).
Конфигурация
set protocols msdp local-address 10.200.86.2 set protocols msdp group anycast-rp mode mesh-group set protocols msdp group anycast-rp peer 10.200.86.9 set protocols msdp group anycast-rp peer 10.200.86.3 set protocols msdp group customers mode mesh-group set protocols msdp group customers export export-msdp-groups set protocols msdp group customers export export-msdp-sources set protocols msdp group customers peer 192.168.86.13 local-address 192.168.86.14 set protocols msdp group customers peer 192.168.86.37 local-address 192.168.86.38
set protocols msdp peer 192.168.2.1 default-peer || используем, чтобы убедиться, что все SA принимаются от этого пира (диагностика)
Troubleshoting
show msdp show mspd peer 212.1.254.14 detail show msdp source-active show route table inet.4 || SA cache show msdp statisctics
Traceoptions
set protocols msdp traceoptions file msdp-debug set protocols msdp traceoptions file size 10m set protocols msdp traceoptions file files 30 set protocols msdp traceoptions file world-readable set protocols msdp traceoptions flag state set protocols msdp traceoptions flag general detail set protocols msdp traceoptions flag source-active detail
Anycast RP
Обеспечивает работу нескольких RP для группы, что хорошо в плане отказоустойчивости.
Принцип: Несколько RP используют один общий ip (anycast). Эффект достигается засчет введения нескольких RP, использующих одинаковый IP. Источники и получатели при этом используют ближайшую по unicast RP.
Может возникнуть проблема, что получатель и источник сойдутся на разных RP. Для решения этой проблемы используем MSDP.
При этом надежность становится значительно лучше:
- failover timeout зависит только от сходимости IGP.
- распределение нагрузки на RP для группы - становится возможным.
MSDP работает только с IPv4. Anycast-PIM поддерживает IPv4, IPv6.
Настройка
- Создаем уникальный ip на loopback (основной для протоколов маршрутизации) - помечаем его как primary. Также для надежности лучше его прописать как router-id.
- Создаем неуникальный ip на loopback (для anyacst-RP) - назначаем его как local RP.
- Non-RP роутеры должны "изучить" anycast-RP, используя любой discovery механизм (обычно все-таки это static RP, так как он самый простой).
- Включаем MSDP mesh peering с другими anycast-RP роутерами.
RP:
tormore# top show | compare [edit interfaces lo0 unit 0 family inet address 10.200.86.9/32] + primary; [edit interfaces lo0 unit 0 family inet] address 10.200.86.9/32 { ... } + address 10.200.86.100/32; [edit] + routing-options { + router-id 10.200.86.9; + } [edit protocols pim] + rp { + local { + family inet { + address 10.200.86.100; + anycast-pim { + rp-set { + address 10.200.86.3; + local-address 172.30.5.9; tormore# top show | compare [edit protocols] + msdp { + group rp { + mode mesh-group; + local-address 10.200.86.9; + peer 10.200.86.2;
tormore> show msdp Peer address Local address State Last up/down Peer-Group SA Count 10.200.86.2 10.200.86.9 Established 00:04:34 rp 1/1
tormore> show route receive-protocol msdp 10.200.86.2 inet.4: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) 235.4.5.6,10.66.66.2/32*[MSDP/175/1] 00:00:53, from 10.200.86.2 > to 10.200.86.100 via ge-0/0/0.120