MPLS çekirdeğinde tam olarak izlenmeyen toplu etiketlere sahip önekler

Bir MPLS çekirdeğinde birkaç atlama ile ayrılmış iki yönlendiricim var, A (Cat6500 w / SUP720-3BXL, IOS 12.2 (33) SXH4) ve B (Nexus 7K w / SUP1, NX-OS 5.2 (4)). VRF ABC. A yönlendiricisi, bu VRF içinde iki doğrudan bağlı rotaya ve dört statik yola sahiptir.

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

Önek başına etiketleme, her iki yönlendiricide de bu VRF için kullanılır. Doğrudan bağlı iki yolun paylaşılan bir toplu etiket (95) alırken, dört statik yolun her biri benzersiz bir etiket alır.

Yönlendirici B, kullanılacak VPN etiketlerini kabul eder:

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)

Yönlendirici B'den, yönlendirici A'daki doğrudan bağlı ağların her ikisine de sorunsuz bir şekilde izleyebilirim:

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

Bununla birlikte, MPLS yolu boyunca tüm statik olarak öğrenilmiş rotaların zaman aşımını izler ve yalnızca son atlamalarında geri alır:

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

Yukarıdaki her iki iz de tam olarak aynı yolu izlemeli ve bu yolda hiçbir filtreleme mekanizması bulunmamalıdır. Aynı şey ters yönde de olur. Neyi kaçırıyorum? Doğrudan bağlantı ile öğrenilen BGP yolları ile MPLS / etiket iletme açısından statik yapılandırmayla arasındaki fark nedir?

Toplam etiketler ve normal etiketler arasındaki fark, normal etiketler doğrudan L2 yeniden yazma ayrıntılarını (bir arabirim ve L2 adresi) gösterecek şekildedir. Bu, normal bir etiketin IP araması yapmadan çıkış çıkışı PE düğümü tarafından doğrudan değiştirileceği anlamına gelir.

Tersine, birleştirilmiş etiketler potansiyel olarak birçok farklı çıkış seçeneğini temsil edebilir, bu nedenle L2 yeniden yazma bilgileri etiketin kendisiyle ilişkilendirilmez. Bu, uygun bir L2 yeniden yazma bilgisini belirlemek için bir çıkış çıkışı PE düğümünün paket için bir IP araması gerçekleştirmesi gerektiği anlamına gelir.

Normal etiket yerine bir toplu etikete sahip olmanızın tipik nedenleri şunlardır:

1. Komşu bulma işlemini gerçekleştirme ihtiyacı (IPv4 ARP, IPv6 ND)
2. ACL araması gerçekleştirme ihtiyacı (müşteri arayüzünde ACL'ye çıkış)
3. Tüm VRF'yi tek bir etiket altında çalıştırma (tablo etiketi)

Bu kısıtlamaların bazıları (özellikle 2) tüm platformlar için geçerli değildir.

Traceroute'un MPLS VPN ortamında nasıl etkilendiği transit P'den geçer, TTL aşıldı mesajını oluştururken, nasıl iade edileceğini bilemez (gönderene yönlendirme tablosu girişi yoktur). Böylece bir transit P düğümü, TTL aşılmış mesajını orijinal etiket yığını ile birlikte çıkış PE düğümüne gönderir, umarım çıkış PE notunun TTL aşıldı mesajını gönderene nasıl geri göndereceği hakkında bir fikri vardır.
Bu özellik Cisco IOS'ta otomatik olarak açıktır, ancak Juniper JunOS'da yapılandırılmış 'icmp tüneli' gerekir.

Buna dayanarak, kaynak adres bir P düğümü bağlantı ağı olduğunda CE cihazlarınızın paketleri kabul etmediğinden ve ICMP mesajını kabul etmediklerinden, gönderene geri gönderemediklerinden şüphelenirim.
Bu teori için olası bir yol testi, per vrf etiketini etkinleştirmek olacaktır:

• İOS: mpls etiket modu all-vrfs protokolü bgp-vpnv4 vrf başına
• JunOS: yönlendirme örneklerini ayarlama FOO vrf-table-label

Genel olarak konuşursak, TTL'nin, özellikle VPN ortamında yayılmasını önermiyorum, en azından bizim durumumuzda müşteriler bu konuda şaşkın ve endişeli. VPN'lerinin neden yabancı adreslerinin gösterildiğinden endişe ediyorlar.

İnsanların bir destek bileti açmasına neden olan başka bir şey de, Birleşik Krallık'tan ABD'ye bir iz sürme çalıştırmalarıdır, çünkü İngiltere'deki iki çekirdek yönlendirici arasında 100ms'den fazla gecikme görüyorlar, tüm yolun aynı gecikmeye sahip olduğunu fark etmiyorlar ABD'nin batı kıyısına kadar, çünkü tüm paketler buradan dolambaçlı yoldan gidiyor.

Bu sorun çoğunlukla tasarım gereği düzeltilemez, ancak IOS'ta TTL oluştururken en çok kaç etiketin (mpls ip ttl-sona erme pop N) aşacağını belirleyebilirsiniz. Bu, INET == 1 etiketi, VPN ==> 1 etiketi durumunda size biraz iyi bir yaklaşım sağlar, böylece VPN trafiğinin tünellenmesi ve INET trafiğinin PE düğüm sapması olmadan doğrudan döndürülmesi için yapılandırabilirsiniz. Ancak dediğim gibi, bu sadece istenen işlevsellik bir tahminidir, çünkü taşıma içi onarımlar gibi özellikler etiket yığının aynı hizmet için her zaman aynı boyutta olmamasına neden olabilir.