У меня есть два маршрутизатора, A (Cat6500 с SUP720-3BXL, IOS 12.2 (33) SXH4) и B (Nexus 7K с 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.
Типичные причины, по которым у вас может быть агрегатная метка вместо обычной метки:
Некоторые из этих ограничений (особенно 2) не распространяются на все платформы.
То, как на traceroute влияют в среде MPLS VPN транзит P, при создании сообщения превышения TTL не будет знать, как его вернуть (у него нет записи в таблице маршрутизации для отправителя). Таким образом, транзитный P-узел будет отправлять сообщение об превышении TTL с исходным стеком меток на весь выходной узел PE, в надежде, что выходная нота PE имеет представление о том, как вернуть отправленное сообщение с превышением TTL.
Эта функция автоматически включена в Cisco IOS, но для нее необходимо настроить icmp-туннелирование в Juniper JunOS.
Исходя из этого, я подозреваю, что, возможно, ваши устройства CE не принимают пакеты, когда адрес источника является сетью связи узла P, и, поскольку они не принимают сообщение ICMP, они не могут вернуть его отправителю.
Возможный способ проверки этой теории - включить метку per-vrf:
Вообще говоря, я не рекомендую распространять TTL, особенно в среде VPN, по крайней мере, в нашем случае клиенты запутываются и беспокоятся об этом. Они волнуются, почему их VPN показывает внешние адреса.
Еще одна вещь, которая сбивает с толку людей, заставляющих их открыть заявку в службу поддержки, это когда они запускают трассировку маршрута, скажем, из Великобритании в США, потому что они видят задержку> 100 мс между двумя основными маршрутизаторами в Великобритании, не понимая, что весь путь имеет одинаковую задержку вплоть до западного побережья США, потому что оттуда все пакеты идут в обход.
Эта проблема по большей части не решаема по проекту, однако в IOS вы можете определить, сколько ярлыков нужно выдать (mpls ip ttl-expiration pop N) при превышении TTL. Это дает вам несколько приличное приближение, если метка INET == 1, метка VPN ==> 1, так что вы можете настроить ее так, чтобы трафик VPN туннелировался и трафик INET возвращался напрямую без обхода выходного узла PE. Но, как я уже сказал, это лишь приблизительная оценка желаемой функциональности, так как такие функции, как ремонт при транспортировке, могут привести к тому, что ваш стек этикеток не всегда будет одного размера для одной и той же службы.
источник