Awalan dengan label agregat tidak sepenuhnya ditelusuri di seluruh inti MPLS

Saya memiliki dua router, A (Cat6500 w / SUP720-3BXL, IOS 12.2 (33) SXH4) dan B (Nexus 7K w / SUP1, NX-OS 5.2 (4)), dipisahkan oleh beberapa loncatan melintasi inti MPLS, masing-masing dengan VRF ABC. Router A memiliki dua rute yang terhubung langsung dan empat rute statis dalam VRF ini.

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

Pelabelan per awalan digunakan untuk VRF ini di kedua router. Perhatikan bahwa dua rute yang terhubung langsung menerima label agregat bersama (95) sedangkan empat rute statis masing-masing menerima label unik.

Router B menyetujui label VPN untuk digunakan:

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)

Dari router B, saya dapat traceroute ke kedua jaringan yang terhubung langsung pada router A tanpa masalah:

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

Namun, traceroute ke semua timeout rute yang dipelajari secara statis di jalur MPLS dan mengambil kembali hanya pada hop terakhir mereka:

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

Kedua traceroute di atas harus mengikuti jalur yang sama persis, dan tidak ada mekanisme penyaringan di sepanjang itu. Hal yang sama juga terjadi pada arah sebaliknya. Apa yang saya lewatkan? Apa perbedaan antara rute BGP yang dipelajari oleh koneksi langsung versus konfigurasi statis sehubungan dengan penerusan MPLS / label?

Perbedaan antara label agregat dan label normal adalah sedemikian rupa sehingga label normal langsung menunjuk ke rincian penulisan ulang L2 (antarmuka dan alamat L2). Ini berarti label normal akan diberi label yang dialihkan oleh node PE keluar langsung, tanpa melakukan pencarian IP.

Sebaliknya, label agregat berpotensi mewakili banyak opsi jalan keluar yang berbeda, sehingga informasi penulisan ulang L2 tidak terkait dengan label itu sendiri. Ini berarti bahwa simpul PE keluar harus melakukan pencarian IP untuk paket, untuk menentukan informasi penulisan ulang L2 yang sesuai.

Alasan umum mengapa Anda mungkin memiliki label agregat dan bukan label normal adalah:

1. Perlu melakukan penemuan tetangga (IPv4 ARP, IPv6 ND)
2. Perlu melakukan pencarian ACL (keluar ACL di antarmuka pelanggan)
3. Menjalankan seluruh VRF di bawah label tunggal (label-tabel)

Beberapa pembatasan ini (khususnya 2) tidak berlaku untuk semua platform.

Bagaimana traceroute dipengaruhi dalam lingkungan VPN MPLS adalah oleh transit P, ketika menghasilkan TTL melebihi pesan, tidak akan tahu bagaimana mengembalikannya (tidak memiliki entri tabel routing ke pengirim). Jadi simpul P transit akan mengirim pesan terlampaui TTL dengan tumpukan label asli sampai ke simpul PE keluar, dengan harapan bahwa catatan PE keluar memiliki ide tentang bagaimana mengembalikan pesan terlampaui TTL ke pengirim.
Fitur ini secara otomatis aktif di Cisco IOS tetapi membutuhkan 'icmp-tunneling' yang dikonfigurasi dalam Juniper JunOS.

Berdasarkan ini, saya menduga bahwa mungkin perangkat CE Anda tidak menerima paket ketika alamat sumber adalah jaringan tautan P node, dan karena mereka tidak menerima pesan ICMP, mereka tidak dapat mengembalikannya ke pengirim.
Tes cara yang mungkin untuk teori ini adalah dengan mengaktifkan label per-vrf:

• IOS: mode mpls label semua-vrfs protokol bgp-vpnv4 per-vrf
• JunOS: atur rute-instance FOO vrf-table-label

Secara umum saya tidak merekomendasikan menyebarkan TTL, terutama pada lingkungan VPN, setidaknya dalam kasus kami pelanggan menjadi bingung dan cemas tentang hal itu. Mereka khawatir mengapa VPN mereka menampilkan alamat asing.

Hal lain yang membingungkan orang menyebabkan mereka membuka tiket dukungan, adalah ketika mereka menjalankan traceroute dari Inggris ke AS, karena mereka melihat latensi> 100 ms antara dua router inti di Inggris, tidak menyadari bahwa seluruh jalur memiliki latensi yang sama sampai ke pantai barat AS, karena semua paket mengambil jalan memutar dari sana.

Masalah ini sebagian besar tidak dapat diperbaiki oleh desain, namun di iOS Anda dapat menentukan berapa banyak label paling banyak untuk pop (mpls ip ttl-expiration pop N) ketika Anda menghasilkan TTL terlampaui. Ini memberi Anda perkiraan yang agak baik jika label INET == 1, label VPN ==> 1, sehingga Anda dapat mengonfigurasinya sehingga lalu lintas VPN disetel dan lalu lintas INET akan langsung dikembalikan tanpa jalan memutar simpul simpul PE keluar. Tetapi seperti yang saya katakan, ini hanya perkiraan fungsionalitas yang diinginkan, karena fitur seperti perbaikan dalam perjalanan dapat menyebabkan tumpukan label Anda tidak selalu sama ukuran untuk layanan yang sama.