Протокол IP : Групповая адресация

Двойной-Homed Источник и Данные MDT в mVPN

11 августа 2015 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (15 июня 2015) | Отзыв

Введение

Этот документ описывает mVPN (Передача Действительная Сеть Поставщика) с двойным-homed Источником и Данными MDT (Дерево Распределения Передачи). Пример в Cisco IOS® используется для иллюстрирования поведения.

Внесенный Люком Де Гееном, Cisco инженер TAC.

Проблема

Если источник в mVPN мире является двойным-homed к двум Входным маршрутизаторам Края поставщика (PE), это могло быть возможно для двух Входов маршрутизаторы PE к обоим передовым движениям для одного (S, G) в Этикетку Мультипротокола, Переключающую (MPLS) облако. Это возможно если, например, существует два Выхода маршрутизаторы PE и каждое Обратное отправление пути (RPF) к различному Входу маршрутизатор PE. Если оба Входа, которые теряют маршрутизаторы PE вперед на Неплатеж, MDT, то утверждать механизм умрет и один Вход PE, выигрывает утверждать механизм и другой так, чтобы один и только один Вход PE продолжил отправлять Клиенту (C-) (S, G) на MDT. Однако, если по какой-либо причине утверждать механизм не начинал на Неплатеже MDT, то для обоих Входов маршрутизаторы PE возможно начать передавать C-(S, G) движение передачи на один MDT данных, который они начинают. Поскольку движение не находится на Неплатеже MDT больше, а на Данных MDTs, оба Входа, маршрутизаторы PE не получают C-(S, G) движение друг от друга в интерфейсе MDT/Tunnel. Это может вызвать постоянное двойное движение вниз по течению. Этот документ объясняет решение этой проблемы.

Утверждайте механизм на неплатеже MDT

Информация в этой секции сохраняется для Неплатежа MDT, независимо от основного протокола дерева. Выбранный основной протокол дерева является Протоколом независимой передачей (PIM).

Cisco IOS используется для примеров, но все, что упомянуто, применяется одинаково для IOS-XR Cisco. Все Группы передачи использовали, группы Источника определенной передачи (SSM).

Взгляд на рисунок 1. Dual-Homed-Source-1. Существует два Входа маршрутизаторы PE (PE1 и PE2) и два Выхода маршрутизаторы PE (PE3 и PE4). Источник в CE1 с IP-адресом 10.100.1.6. CE1 является двойным-homed к PE1 и PE2.


Рисунок 1. Dual-Homed-Source-1

Конфигурация на всех маршрутизаторах PE (Маршрут Distinguisher (RD) может отличаться на маршрутизаторах PE):

vrf definition one
 rd 1:1
 !
 address-family ipv4
 mdt default 232.10.10.10
 route-target export 1:1
 route-target import 1:1
 exit-address-family
!

Чтобы заставить оба Входа маршрутизаторы PE начинать отправлять поток передачи (10.100.1.6,232.1.1.1) на Неплатеж MDT, они должны оба получить Соединение от Выхода PE. Смотрите на топологию в Figure1. Dual-Homed-Source-1. Вы видите, что по умолчанию, если все затраты связей края являются тем же самым и всеми затратами основных связей, то же самое, то PE3 будет, RPF к PE1 и PE4 будет RPF к PE2 для (10.100.1.6,232.1.1.1). Они оба RPF к их самому близкому Входу PE. Эта продукция подтверждает это:

PE3#show ip rpf vrf one 10.100.1.6
RPF information for ? (10.100.1.6)
 RPF interface: Tunnel0
 RPF neighbor: ? (10.100.1.1)
 RPF route/mask: 10.100.1.6/32
 RPF type: unicast (bgp 1)
 Doing distance-preferred lookups across tables
 BGP originator: 10.100.1.1
 RPF topology: ipv4 multicast base, originated from ipv4 unicast base

PE3 имеет RPF к PE1.

PE4#show ip rpf vrf one 10.100.1.6
RPF information for ? (10.100.1.6)
 RPF interface: Tunnel0
 RPF neighbor: ? (10.100.1.2)
 RPF route/mask: 10.100.1.6/32
 RPF type: unicast (bgp 1)
 Doing distance-preferred lookups across tables
 BGP originator: 10.100.1.2
 RPF topology: ipv4 multicast base, originated from ipv4 unicast base

PE4 имеет RPF к PE2. Причина, что PE3 выбирает PE1 как соседа RPF, состоит в том, что unicast маршрут к 10.100.1.6/32 в Действительном Направлении/Отправлении (VRF) каждый является лучшим через PE1. PE3 фактически получает маршрут 10.100.1.6/32 от PE1 и из PE2. Все критерии в Протоколе ворот границы (BGP) Лучший Алгоритм Вычисления Пути являются тем же самым, за исключением стоимости к адресу следующего перелета BGP.

PE3#show bgp vpnv4 unicast vrf one 10.100.1.6/32
BGP routing table entry for 1:3:10.100.1.6/32, version 333
Paths: (2 available, best #1, table one)
 Advertised to update-groups:
    21       
 Refresh Epoch 1
 Local, imported path from 1:1:10.100.1.6/32 (global)
   10.100.1.1 (metric 11) (via default) from 10.100.1.5 (10.100.1.5)
     Origin incomplete, metric 11, localpref 100, valid, internal, best
     Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x000000640200
       OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.2.4.1:0
     Originator: 10.100.1.1, Cluster list: 10.100.1.5
     Connector Attribute: count=1
      type 1 len 12 value 1:1:10.100.1.1
     mpls labels in/out nolabel/32
     rx pathid: 0, tx pathid: 0x0
 Refresh Epoch 1
 Local, imported path from 1:2:10.100.1.6/32 (global)
   10.100.1.2 (metric 21) (via default) from 10.100.1.5 (10.100.1.5)
     Origin incomplete, metric 11, localpref 100, valid, internal
     Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x000000640200
       OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.2.2.2:0
     Originator: 10.100.1.2, Cluster list: 10.100.1.5
     Connector Attribute: count=1
      type 1 len 12 value 1:2:10.100.1.2
     mpls labels in/out nolabel/29
     rx pathid: 0, tx pathid: 0
PE4#show bgp vpnv4 unicast vrf one 10.100.1.6/32
BGP routing table entry for 1:4:10.100.1.6/32, version 1050
Paths: (2 available, best #2, table one)
 Advertised to update-groups:
    2        
 Refresh Epoch 1
 Local, imported path from 1:1:10.100.1.6/32 (global)
   10.100.1.1 (metric 21) (via default) from 10.100.1.5 (10.100.1.5)
     Origin incomplete, metric 11, localpref 100, valid, internal
     Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x000000640200
       OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.2.4.1:0
     Originator: 10.100.1.1, Cluster list: 10.100.1.5
     Connector Attribute: count=1
      type 1 len 12 value 1:1:10.100.1.1
     mpls labels in/out nolabel/32
     rx pathid: 0, tx pathid: 0
 Refresh Epoch 1
 Local, imported path from 1:2:10.100.1.6/32 (global)
   10.100.1.2 (metric 11) (via default) from 10.100.1.5 (10.100.1.5)
     Origin incomplete, metric 11, localpref 100, valid, internal, best
     Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x000000640200
       OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.2.2.2:0
     Originator: 10.100.1.2, Cluster list: 10.100.1.5
     Connector Attribute: count=1
      type 1 len 12 value 1:2:10.100.1.2
     mpls labels in/out nolabel/29
     rx pathid: 0, tx pathid: 0x0

Лучший путь, выбранный PE3, является путем, рекламируемым PE1, потому что это имеет самую низкую стоимость Внутреннего протокола ворот (IGP) (11) против стоимости IGP (21) к PE2. Для PE4 это - перемена. Топология показывает, что от PE3 до PE1 существует только один перелет, в то время как от PE3 до PE2 существует два перелета. Так как все связи имеют ту же самую стоимость IGP, PE3 выбирает путь от PE1 как лучшее.

 Когда нет никакого движения передачи еще, Основа информации о направлении передачи (MRIB) для (10.100.1.6,232.1.1.1) похожа на это на PE1 и PE2:

PE1#show ip mroute vrf one 232.1.1.1 10.100.1.6
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
      L - Local, P - Pruned, R - RP-bit set, F - Register flag,
      T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
      X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
      U - URD, I - Received Source Specific Host Report,
      Z - Multicast Tunnel, z - MDT-data group sender,
      Y - Joined MDT-data group, y - Sending to MDT-data group,
      G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
      N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
      Q - Received BGP S-A Route, q - Sent BGP S-A Route,
      V - RD & Vector, v - Vector, p - PIM Joins on route,
      x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 00:00:12/00:03:17, flags: sT
 Incoming interface: Ethernet0/0, RPF nbr 10.2.1.6
 Outgoing interface list:
   Tunnel0, Forward/Sparse, 00:00:12/00:03:17
PE2#show ip mroute vrf one 232.1.1.1 10.100.1.6
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
      L - Local, P - Pruned, R - RP-bit set, F - Register flag,
      T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
      X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
      U - URD, I - Received Source Specific Host Report,
      Z - Multicast Tunnel, z - MDT-data group sender,
      Y - Joined MDT-data group, y - Sending to MDT-data group,
      G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
      N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
      Q - Received BGP S-A Route, q - Sent BGP S-A Route,
      V - RD & Vector, v - Vector, p - PIM Joins on route,
      x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 00:00:47/00:02:55, flags: sT
 Incoming interface: Ethernet1/0, RPF nbr 10.2.2.6
 Outgoing interface list:
   Tunnel0, Forward/Sparse, 00:00:47/00:02:55

PE1 и PE2 оба получили Соединение PIM для (10.100.1.6,232.1.1.1). Интерфейс Tunnel0 находится в Исходящем интерфейсном списке (OIL) для входа передачи на обоих маршрутизаторах.

Движение передачи начинает течь для (10.100.1.6,232.1.1.1). "Отладьте IP pim vrf один 232.1.1.1", и "отлаживают IP mrouting vrf, один 232.1.1.1" показывает нам, что прибытие движения передачи на Tunnel0 (в OIL) обоих Входов маршрутизаторы PE, заставляет утверждать механизм бежать.

PE3

PIM(1): Send v2 Assert on Tunnel0 for 232.1.1.1, source 10.100.1.6, metric [110/11] 
PIM(1): Assert metric to source 10.100.1.6 is [110/11]
MRT(1): not RPF interface, source address 10.100.1.6, group address 232.1.1.1
PIM(1): Received v2 Assert on Tunnel0 from 10.100.1.2
PIM(1): Assert metric to source 10.100.1.6 is [110/11]
PIM(1): We lose, our metric [110/11]
PIM(1): Prune Tunnel0/232.10.10.10 from (10.100.1.6/32, 232.1.1.1)
MRT(1): Delete Tunnel0/232.10.10.10 from the olist of (10.100.1.6, 232.1.1.1)
MRT(1): Reset the PIM interest flag for (10.100.1.6, 232.1.1.1)
MRT(1): set min mtu for (10.100.1.6, 232.1.1.1) 1500->18010 - deleted
PIM(1): Received v2 Join/Prune on Tunnel0 from 10.100.1.3, not to us
PIM(1): Join-list: (10.100.1.6/32, 232.1.1.1), S-bit set

PE4

PIM(1): Received v2 Assert on Tunnel0 from 10.100.1.1
PIM(1): Assert metric to source 10.100.1.6 is [110/11]
PIM(1): We win, our metric [110/11]
PIM(1): (10.100.1.6/32, 232.1.1.1) oif Tunnel0 in Forward state
PIM(1): Send v2 Assert on Tunnel0 for 232.1.1.1, source 10.100.1.6, metric [110/11]
PIM(1): Assert metric to source 10.100.1.6 is [110/11]
PIM(1): Received v2 Join/Prune on Tunnel0 from 10.100.1.3, to us
PIM(1): Join-list: (10.100.1.6/32, 232.1.1.1), S-bit set
PIM(1): Update Tunnel0/10.100.1.3 to (10.100.1.6, 232.1.1.1), Forward state, by PIM SG Join

Если метрика и расстояние являются теми же самыми из обоих маршрутизаторов к Источнику 10.100.1.6, то существует дополнительное время для определения утверждать победителя. Дополнительным временем является самый высокий IP-адрес соседа PIM на Tunnel0 (Неплатеж MDT). В этом случае это - PE2:

PE1#show ip pim vrf one neighbor 
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
     P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,
     L - DR Load-balancing Capable
Neighbor         Interface               Uptime/Expires   Ver  DR
Address                                                           Prio/Mode
10.100.1.4       Tunnel0                 06:27:57/00:01:29 v2   1 / DR S P G
10.100.1.3       Tunnel0                 06:28:56/00:01:24 v2   1 / S P G
10.100.1.2       Tunnel0                 06:29:00/00:01:41 v2   1 / S P G
PE1#show ip pim vrf one interface 

Address         Interface               Ver/  Nbr   Query DR        DR
                                         Mode  Count Intvl Prior
10.2.1.1        Ethernet0/0             v2/S  0     30    1         10.2.1.1
10.2.4.1        Ethernet1/0             v2/S  0     30    1         10.2.4.1
10.100.1.1      Lspvif1                 v2/S  0     30    1         10.100.1.1
10.100.1.1      Tunnel0                 v2/S  3     30    1         10.100.1.4

PE1 удалил Tunnel0 из OIL входа передачи из-за утверждения. Так как OIL стал пустым, вход передачи сокращен.

PE1#show ip mroute vrf one 232.1.1.1 10.100.1.6
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
      L - Local, P - Pruned, R - RP-bit set, F - Register flag,
      T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
      X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
      U - URD, I - Received Source Specific Host Report,
      Z - Multicast Tunnel, z - MDT-data group sender,
      Y - Joined MDT-data group, y - Sending to MDT-data group,
      G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
      N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
      Q - Received BGP S-A Route, q - Sent BGP S-A Route,
      V - RD & Vector, v - Vector, p - PIM Joins on route,
      x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 00:17:24/00:00:01, flags: sPT
 Incoming interface: Ethernet0/0, RPF nbr 10.2.1.6
 Outgoing interface list: Null

PE2 установили A-флаг в интерфейсе Tunnel0, потому что это - утверждать победитель.

PE2#show ip mroute vrf one 232.1.1.1 10.100.1.6
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
      L - Local, P - Pruned, R - RP-bit set, F - Register flag,
      T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
      X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
      U - URD, I - Received Source Specific Host Report,
      Z - Multicast Tunnel, z - MDT-data group sender,
      Y - Joined MDT-data group, y - Sending to MDT-data group,
      G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
      N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
      Q - Received BGP S-A Route, q - Sent BGP S-A Route,
      V - RD & Vector, v - Vector, p - PIM Joins on route,
      x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 00:17:20/00:02:54, flags: sT
 Incoming interface: Ethernet1/0, RPF nbr 10.2.2.6
 Outgoing interface list:
   Tunnel0, Forward/Sparse, 00:17:20/00:02:54, A

PE2 периодически посылает утверждение на Tunnel0 (Неплатеж MDT), непосредственно перед тем, как истекает утверждать таймер. PE2 как таковой остается утверждать победителем.

PE2#
PIM(1): Send v2 Assert on Tunnel0 for 232.1.1.1, source 10.100.1.6, metric [110/11]
PIM(1): Assert metric to source 10.100.1.6 is [110/11]

Заключение

Утверждать механизм также работает с интерфейсом Tunnel в OIL. Утверждение обменено по Неплатежу MDT, когда Вход, маршрутизаторы PE получают C-(S, G) движение передачи в связанном интерфейсе Tunnel, который находится в OIL.

Утверждайте механизм с данными MDTs

Большую часть времени, когда Данные, MDTs формируются, утверждать механизм, будут все еще управлять на Неплатеже MDT как C-(S, G), движение только переключено с Неплатежа MDT к Данным MDTs после трех секунд. Тогда то же самое происходит, как ранее описано. Обратите внимание на то, что существует только один туннельный интерфейс за позволенный передачей VRF: Неплатеж MDT и все Данные, MDTs используют один тоннель, взаимодействует только. Этот туннельный интерфейс используется в OIL на Входе маршрутизаторы PE или как интерфейс RPF на Выходе маршрутизаторы PE.

В некоторых случаях возможно, что утверждать механизм не вызван перед Данными сообщены MDTs. Тогда возможно, что C-(S, G) движение передачи начинает отправляться на Данных MDT и на Входе маршрутизаторы PE PE1 и на PE2. В таких случаях это могло привести к постоянному двойному C-(S, G) движение передачи через основную сеть MPLS. Для предотвращения этого это решение было осуществлено: когда Вход, маршрутизатор PE видит другой Вход маршрутизатор PE, объявляет о Данных MDT, для которого маршрутизатор PE является также Входом маршрутизатор PE, это присоединяется к тем Данным MDT. В принципе только Выход маршрутизаторы PE (которые имеют нисходящий приемник) присоединился бы к Данным MDT. Поскольку Вход, маршрутизаторы PE присоединяются к Данным MDT, о котором объявляет другой Вход маршрутизаторы PE, это приводит к Входу маршрутизатор PE, получающий движение передачи от интерфейса Tunnel, который присутствует в OIL, и следовательно это вызывает утверждать механизм и приводит к одному из Входа маршрутизаторы PE, чтобы прекратить отправлять C-(S, G) движение передачи на его Данные MDT (с интерфейсом Tunnel), в то время как другой Вход PE (утверждать победитель) может продолжить отправлять C-(S, G) движение передачи на его Данные MDT.

Для следующего примера предположите, что Вход маршрутизаторы PE PE1 и PE2 никогда не видел C-(S, G) движение передачи друг от друга на Неплатеже MDT. Движение находится на Неплатеже MDT в течение только трех секунд, и не трудно понять, что это может произойти, если существует, например, временная транспортная потеря в основной сети.

Конфигурация для Данных MDT добавлена ко всем маршрутизаторам PE. Конфигурация на всех маршрутизаторах PE (RD может отличаться на маршрутизаторах PE):

vrf definition one
 rd 1:1
 !
 address-family ipv4
 mdt default 232.10.10.10
mdt data 232.11.11.0 0.0.0.0
 route-target export 1:1
 route-target import 1:1
 exit-address-family
!

Как только PE1 и PE2 видят движение из Источника, они создают C-(S, G) вход. Оба Входа маршрутизаторы PE отправляют C-(S, G) движение передачи на Неплатеж MDT. Выход маршрутизаторы PE PE3 и PE4 получают движение передачи и отправляют его. Из-за временной проблемы, PE2 не видит движение от PE1 и наоборот на Неплатеже MDT. Они оба посылают Данным Стоимость длины типа (TLV) Соединения MDT на Неплатеже MDT.

Если нет никакого C-(S, G) движения, вы видите это государство передачи на Входе маршрутизаторы PE:

PE1#show ip mroute vrf one 232.1.1.1 10.100.1.6
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
      L - Local, P - Pruned, R - RP-bit set, F - Register flag,
      T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
      X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
      U - URD, I - Received Source Specific Host Report,
      Z - Multicast Tunnel, z - MDT-data group sender,
      Y - Joined MDT-data group, y - Sending to MDT-data group,
      G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
      N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
      Q - Received BGP S-A Route, q - Sent BGP S-A Route,
      V - RD & Vector, v - Vector, p - PIM Joins on route,
      x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 00:00:45/00:02:44, flags: sT
 Incoming interface: Ethernet0/0, RPF nbr 10.2.1.6
 Outgoing interface list:
   Tunnel0, Forward/Sparse, 00:00:45/00:02:42
PE2#show ip mroute vrf one 232.1.1.1 10.100.1.6  
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
      L - Local, P - Pruned, R - RP-bit set, F - Register flag,
      T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
      X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
      U - URD, I - Received Source Specific Host Report,
      Z - Multicast Tunnel, z - MDT-data group sender,
      Y - Joined MDT-data group, y - Sending to MDT-data group,
      G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
      N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
      Q - Received BGP S-A Route, q - Sent BGP S-A Route,
      V - RD & Vector, v - Vector, p - PIM Joins on route,
      x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 00:02:18/00:03:28, flags: sT
 Incoming interface: Ethernet1/0, RPF nbr 10.2.2.6
 Outgoing interface list:
   Tunnel0, Forward/Sparse, 00:02:18/00:03:28

Y-флаг еще не установлен. Оба Входа маршрутизаторы PE имеют интерфейс Tunnel0 в OIL. Это - то, вследствие того, что PE3 имеет RPF к PE1, и PE4 имеет RPF к PE2 для C-(S, G).

Когда движение передачи для C-(S, G) начинает течь, и PE1 и PE2 отправляют движение. Порог для Данных, MDT пересечен и на Входе, маршрутизаторы PE и оба отсылают Данные Соединение MDT TLV и после того, как три секунды начинают отправлять на их Данные MDT. Заметьте, что PE1 присоединяется к Данным, MDT, поставленный PE2 и PE2, присоединяется к Данным MDT, поставленный PE1.

PE1#show ip mroute vrf one 232.1.1.1 10.100.1.6 
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
      L - Local, P - Pruned, R - RP-bit set, F - Register flag,
      T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
      X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
      U - URD, I - Received Source Specific Host Report,
      Z - Multicast Tunnel, z - MDT-data group sender,
      Y - Joined MDT-data group, y - Sending to MDT-data group,
      G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
      N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
      Q - Received BGP S-A Route, q - Sent BGP S-A Route,
      V - RD & Vector, v - Vector, p - PIM Joins on route,
      x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 00:01:26/00:03:02, flags: sTy
 Incoming interface: Ethernet0/0, RPF nbr 10.2.1.6
 Outgoing interface list:
   Tunnel0, Forward/Sparse, 00:01:26/00:03:02
PE2#show ip mroute vrf one 232.1.1.1 10.100.1.6 
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
      L - Local, P - Pruned, R - RP-bit set, F - Register flag,
      T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
      X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
      U - URD, I - Received Source Specific Host Report,
      Z - Multicast Tunnel, z - MDT-data group sender,
      Y - Joined MDT-data group, y - Sending to MDT-data group,
      G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
      N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
      Q - Received BGP S-A Route, q - Sent BGP S-A Route,
      V - RD & Vector, v - Vector, p - PIM Joins on route,
      x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 00:00:41/00:02:48, flags: sTy
 Incoming interface: Ethernet1/0, RPF nbr 10.2.2.6
 Outgoing interface list:
   Tunnel0, Forward/Sparse, 00:00:41/00:02:48

И PE1 и PE получают движение для C-(S, G) в интерфейсе Tunnel0 (но теперь от Данных MDT, не Неплатеж MDT), и утверждать механизм умирает. Только PE2 продолжает отправлять C-(S, G) движение на его Данных MDT:

PE1#
PIM(1): Send v2 Assert on Tunnel0 for 232.1.1.1, source 10.100.1.6, metric [110/11]
PIM(1): Assert metric to source 10.100.1.6 is [110/11]
MRT(1): not RPF interface, source address 10.100.1.6, group address 232.1.1.1
PIM(1): Received v2 Assert on Tunnel0 from 10.100.1.2
PIM(1): Assert metric to source 10.100.1.6 is [110/11]
PIM(1): We lose, our metric [110/11]
PIM(1): Prune Tunnel0/232.11.11.0 from (10.100.1.6/32, 232.1.1.1)
MRT(1): Delete Tunnel0/232.11.11.0 from the olist of (10.100.1.6, 232.1.1.1)
MRT(1): Reset the PIM interest flag for (10.100.1.6, 232.1.1.1)
PIM(1): MDT Tunnel0 removed from (10.100.1.6,232.1.1.1)
MRT(1): Reset the y-flag for (10.100.1.6,232.1.1.1)
PIM(1): MDT next_hop change from: 232.11.11.0 to 232.10.10.10 for (10.100.1.6, 232.1.1.1) Tunnel0
MRT(1): set min mtu for (10.100.1.6, 232.1.1.1) 1500->18010 - deleted
PIM(1): MDT threshold dropped for (10.100.1.6,232.1.1.1)
PIM(1): Receive MDT Packet (9889) from 10.100.1.2 (Tunnel0), length (ip: 44, udp: 24), ttl: 1
PIM(1): TLV type: 1 length: 16 MDT Packet length: 16
PE2#
PIM(1): Received v2 Assert on Tunnel0 from 10.100.1.1
PIM(1): Assert metric to source 10.100.1.6 is [110/11]
PIM(1): We win, our metric [110/11]
PIM(1): (10.100.1.6/32, 232.1.1.1) oif Tunnel0 in Forward state
PIM(1): Send v2 Assert on Tunnel0 for 232.1.1.1, source 10.100.1.6, metric [110/11]
PIM(1): Assert metric to source 10.100.1.6 is [110/11]
PE2#
PIM(1): Received v2 Join/Prune on Tunnel0 from 10.100.1.3, to us
PIM(1): Join-list: (10.100.1.6/32, 232.1.1.1), S-bit set
PIM(1): Update Tunnel0/10.100.1.3 to (10.100.1.6, 232.1.1.1), Forward state, by PIM SG Join
MRT(1): Update Tunnel0/232.10.10.10 in the olist of (10.100.1.6, 232.1.1.1), Forward state - MAC built
MRT(1): Set the y-flag for (10.100.1.6,232.1.1.1)
PIM(1): MDT next_hop change from: 232.10.10.10 to 232.11.11.0 for (10.100.1.6, 232.1.1.1) Tunnel0

PE1 больше не имеет туннельный интерфейс в OIL.

PE1#show ip mroute vrf one 232.1.1.1 10.100.1.6 
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
      L - Local, P - Pruned, R - RP-bit set, F - Register flag,
      T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
      X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
      U - URD, I - Received Source Specific Host Report,
      Z - Multicast Tunnel, z - MDT-data group sender,
      Y - Joined MDT-data group, y - Sending to MDT-data group,
      G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
      N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
      Q - Received BGP S-A Route, q - Sent BGP S-A Route,
      V - RD & Vector, v - Vector, p - PIM Joins on route,
      x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 00:10:23/00:00:04, flags: sPT
 Incoming interface: Ethernet0/0, RPF nbr 10.2.1.6
 Outgoing interface list: Null

PE2 установили A-флаг в интерфейсе Tunnel0:

PE2#show ip mroute vrf one 232.1.1.1 10.100.1.6 
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
      L - Local, P - Pruned, R - RP-bit set, F - Register flag,
      T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
      X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
      U - URD, I - Received Source Specific Host Report,
      Z - Multicast Tunnel, z - MDT-data group sender,
      Y - Joined MDT-data group, y - Sending to MDT-data group,
      G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
      N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
      Q - Received BGP S-A Route, q - Sent BGP S-A Route,
      V - RD & Vector, v - Vector, p - PIM Joins on route,
      x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 00:10:00/00:02:48, flags: sTy
 Incoming interface: Ethernet1/0, RPF nbr 10.2.2.6
 Outgoing interface list:
   Tunnel0, Forward/Sparse, 00:08:40/00:02:48, A

Заключение

Когда Данные MDTs используются, утверждать механизм также работает. Утверждение обменено по Неплатежу MDT, когда Вход, маршрутизаторы PE получают C-(S, G) движение передачи в связанном интерфейсе Tunnel, который находится в OIL.


Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Document ID: 118986