Префікси з сукупними мітками не повністю простежують ядро ​​MPLS

У мене є два маршрутизатори, A (Cat6500 w / SUP720-3BXL, IOS 12.2 (33) SXH4) і B (Nexus 7K w / SUP1, NX-OS 5.2 (4)), розділені декількома перескаками через ядро ​​MPLS, кожен з VRF ABC. Маршрутизатор A має два безпосередньо пов'язані маршрути та чотири статичні маршрути в межах цього VRF.

RouterA# show ip bgp vpnv4 vrf ABC labels
   Network          Next Hop      In label/Out label
Route Distinguisher: 65000:123 (ABC)
   10.30.10.0/24    10.30.200.1     154/nolabel
   10.30.20.0/24    10.30.200.1     88/nolabel
   10.30.30.0/24    10.30.200.1     38/nolabel
   10.30.40.0/24    10.30.200.1     147/nolabel
   10.30.200.0/24   0.0.0.0         IPv4 VRF Aggr:95/nolabel(ABC)
   10.90.90.0/24    0.0.0.0         IPv4 VRF Aggr:95/nolabel(ABC)
   10.133.242.0/25  192.168.255.3   nolabel/17
   10.133.242.128/26
                    192.168.255.3   nolabel/18
   10.255.255.224/29
                    192.168.255.3   nolabel/492474

Маркування за префіксом використовується для цього VRF на обох маршрутизаторах. Зауважте, що два безпосередньо пов'язаних маршрути отримують загальну сукупну мітку (95), тоді як кожен чотири статичні маршрути отримують унікальну мітку.

Маршрутизатор B погоджується на мітках VPN використовувати:

RouterB# show bgp vpnv4 unicast labels vrf ABC
BGP routing table information for VRF default, address family VPNv4 Unicast
BGP table version is 17042469, local router ID is 192.168.255.3
Status: s-suppressed, x-deleted, S-stale, d-dampened, h-history, *-valid, >-best
Path type: i-internal, e-external, c-confed, l-local, a-aggregate, r-redist
Origin codes: i - IGP, e - EGP, ? - incomplete, | - multipath

   Network            Next Hop            In label/Out label
Route Distinguisher: 65000:123     (VRF ABC)
*>i10.30.10.0/24      172.26.64.1         nolabel/154
*>i10.30.20.0/24      172.26.64.1         nolabel/88
*>i10.30.30.0/24      172.26.64.1         nolabel/38
*>i10.30.40.0/24      172.26.64.1         nolabel/147
*>i10.30.200.0/24     172.26.64.1         nolabel/95
*>i10.90.90.0/24      172.26.64.1         nolabel/95
*>l10.255.255.224/29  0.0.0.0             492474/nolabel (ABC)

З маршрутизатора B я можу простежувати до обох безпосередньо підключених мереж на маршрутизаторі A без проблем:

RouterB# traceroute 10.30.200.10 vrf ABC
traceroute to 10.30.200.10 (10.30.200.10), 30 hops max, 40 byte packets
 1  192.168.254.97 (192.168.254.97) (AS 65000)  19.226 ms  19.369 ms  19.079 ms
      [Label=63 E=0 TTL=1 S=0, Label=95 E=0 TTL=1 S=1]
 2  192.0.2.151 (192.0.2.151) (AS 65000)  23.309 ms  28.027 ms  18.977 ms
      [Label=39 E=0 TTL=1 S=0, Label=95 E=0 TTL=2 S=1]
 3  192.168.251.62 (192.168.251.62) (AS 65000)  21.576 ms  24.265 ms  21.503 ms
      [Label=59 E=0 TTL=1 S=0, Label=95 E=0 TTL=1 S=1]
 4  10.30.200.10 (10.30.200.10) (AS 65000)  19.155 ms *  19.414 ms

Однак, перенаправляйте до всіх очікуваних статично вивчених маршрутів через MPLS-шлях та збирайте їх лише під час останніх стрибків:

RouterB# traceroute 10.30.10.10 vrf ABC
traceroute to 10.30.10.10 (10.30.10.10), 30 hops max, 40 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  10.30.200.10 (10.30.200.10) (AS 65000)  19.065 ms  19.281 ms  18.68 ms
      [Label=154 E=0 TTL=1 S=1]
 5  10.30.10.10 (10.30.10.10) (AS 65000)  19.420 ms  19.377 ms  19.73 ms

Обидві сліди, описані вище, повинні йти по точно однаковому шляху, і вздовж нього немає механізмів фільтрації. Те ж саме відбувається і в зворотному напрямку. Що я пропускаю? Яка різниця між маршрутами BGP, засвоєними прямим з'єднанням та статичною конфігурацією щодо пересилання MPLS / мітки?

Різниця між сукупними мітками та звичайними мітками така, що нормальні мітки безпосередньо вказують на перезапису деталі L2 (інтерфейс та L2-адреса). Це означає, що нормальна мітка буде вимикатися міткою, що вимикається вузлом PE безпосередньо, без IP-пошуку.

І навпаки, сукупні мітки потенційно можуть представляти безліч різних варіантів виходу, тому інформація про перезапис L2 не пов'язана з самою міткою. Це означає, що вихідний PE вузол повинен виконувати пошук IP для пакету, щоб визначити відповідну інформацію про перезапис L2.

Типові причини, чому у вас може бути сукупна мітка замість звичайної мітки:

1. Потрібно виявити сусіда (IPv4 ARP, IPv6 ND)
2. Потрібно виконати пошук ACL (вихід ACL в інтерфейс клієнта)
3. Запуск цілого VRF під однією міткою (таблиця-мітка)

Деякі з цих обмежень (особливо 2) не стосуються всіх платформ.

Як впливає traceroute в середовищі MPLS VPN, транзит P, коли генерує повідомлення TTL перевищено, не буде знати, як його повернути (у нього немає таблиці таблиці маршрутизації для відправника). Таким чином, транзитний вузол P надсилатиме повідомлення, що перевищило TTL, з оригінальним стеком міток аж до вихідного PE вузла, сподіваючись, що примітка про вихідний PE має уявлення про те, як повернути відправнику повідомлення, що перевищило TTL.
Ця функція автоматично вмикається в Cisco IOS, але потребує "icmp-тунелювання", налаштованого в Juniper JunOS.

Виходячи з цього, я б підозрював, що, можливо, ваші пристрої CE не приймають пакети, коли адресою джерела є мережа зв’язків P вузла, і оскільки вони не приймають повідомлення ICMP, вони не в змозі повернути його відправнику.
Можливим тестом для цієї теорії було б включити ярлик per-vrf:

• IOS: mpls режим мітки all-vrfs протокол bgp-vpnv4 per-vrf
• JunOS: встановлення екземплярів маршрутизації для FOO vrf-table-label

Взагалі кажучи, я не рекомендую поширювати TTL, особливо в середовищі VPN, принаймні в нашому випадку клієнти плутаються і турбуються про це. Вони хвилюються, чому в їх VPN відображаються іноземні адреси.

Інша річ, яка бентежить людей, що змушують їх відкрити квиток на підтримку, - це те, коли вони проводять трасування від скажіть Великобританія до США, оскільки вони бачать> затримка 100 мс між двома основними маршрутизаторами у Великобританії, не розуміючи, що весь шлях має однакову затримку аж до західного узбережжя США, тому що всі пакети відправляються звідти.

Ця проблема здебільшого не може бути вирішена за допомогою дизайну, проте в IOS ви можете визначити, скільки ярликів максимум для pop (mpls ip ttl-Expir pop N), коли ви генеруєте TTL, перевищено. Це дає дещо пристойне наближення, якщо ярлик INET == 1, VPN ==> 1 мітка, так що ви можете налаштувати його так, щоб трафік VPN був тунельований, а трафік INET безпосередньо повертався без виходу з вузла PE виїзду. Але, як я вже говорив, це лише наближення бажаної функціональності, оскільки такі функції, як ремонт під час транзиту, можуть призвести до того, що стек міток не буде завжди однакового розміру для однієї послуги.