Tiền tố với nhãn tổng hợp không hoàn toàn theo dõi trên lõi MPLS

Tôi có hai bộ định tuyến A (Cat6500 w / SUP720-3BXL, IOS 12.2 (33) SXH4) và B (Nexus 7K w / SUP1, NX-OS 5.2 (4)), được phân tách bằng nhiều bước nhảy qua lõi MPLS, mỗi bước VRF ABC. Bộ định tuyến A có hai tuyến được kết nối trực tiếp và bốn tuyến tĩnh trong VRF này.

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

Ghi nhãn tiền tố được sử dụng cho VRF này trên cả hai bộ định tuyến. Lưu ý rằng hai tuyến được kết nối trực tiếp nhận nhãn tổng hợp chung (95) trong khi bốn tuyến tĩnh mỗi tuyến nhận một nhãn duy nhất.

Bộ định tuyến B đồng ý trên nhãn VPN để sử dụng:

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)

Từ bộ định tuyến B, tôi có thể theo dõi cả hai mạng được kết nối trực tiếp trên bộ định tuyến A mà không gặp vấn đề gì:

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

Tuy nhiên, theo dõi tất cả các tuyến đường đã học tĩnh trong thời gian chờ trên đường MPLS và chỉ nhận lại ở các bước cuối cùng của chúng:

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

Cả hai tracerout ở trên phải theo cùng một đường dẫn và không có cơ chế lọc nào được đặt dọc theo nó. Điều tương tự cũng xảy ra theo hướng ngược lại. Tôi đang thiếu gì? Sự khác biệt giữa các tuyến BGP được học bằng kết nối trực tiếp so với cấu hình tĩnh liên quan đến chuyển tiếp MPLS / nhãn là gì?

Sự khác biệt giữa nhãn tổng hợp và nhãn thông thường là các nhãn thông thường trực tiếp trỏ đến chi tiết viết lại L2 (giao diện và địa chỉ L2). Điều này có nghĩa là một nhãn bình thường sẽ được chuyển đổi trực tiếp bởi nút PE đi ra mà không cần thực hiện tra cứu IP.

Bất lợi, nhãn tổng hợp có khả năng đại diện cho nhiều tùy chọn đầu ra khác nhau, do đó thông tin viết lại L2 không được liên kết với chính nhãn. Điều này có nghĩa là nút PE đi ra phải thực hiện tra cứu IP cho gói, để xác định thông tin ghi lại L2 thích hợp.

Lý do điển hình tại sao bạn có thể có nhãn tổng hợp thay vì nhãn thông thường là:

1. Cần thực hiện khám phá hàng xóm (IPv4 ARP, IPv6 ND)
2. Cần thực hiện tra cứu ACL (đi ra ACL trong giao diện khách hàng)
3. Chạy toàn bộ VRF dưới nhãn đơn (nhãn bảng)

Một số hạn chế này (đặc biệt là 2) không hợp lệ đối với tất cả các nền tảng.

Làm thế nào traceroute bị ảnh hưởng trong môi trường MPLS VPN là do quá cảnh P, khi tạo thông báo vượt quá TTL, sẽ không biết cách trả lại nó (nó không có mục nhập bảng định tuyến cho người gửi). Vì vậy, một nút P quá cảnh sẽ gửi thông điệp vượt quá TTL với ngăn xếp nhãn gốc đến nút PE đi ra, với hy vọng rằng ghi chú PE đi ra có ý tưởng về cách trả lại tin nhắn vượt quá TTL cho người gửi.
Tính năng này được tự động bật trong Cisco IOS nhưng cần 'icmp-đường hầm' được định cấu hình trong Juniper JunOS.

Dựa trên điều này, tôi nghi ngờ rằng có lẽ các thiết bị CE của bạn không chấp nhận các gói khi địa chỉ nguồn là mạng liên kết nút P và vì chúng không chấp nhận thông báo ICMP, nên chúng không thể trả lại cho người gửi.
Một thử nghiệm khả thi cho lý thuyết này sẽ là kích hoạt nhãn per-vrf:

• IOS: chế độ nhãn mpls giao thức all-vrfs bgp-vpnv4 per-vrf
• JunOS: đặt định tuyến-FOO vrf-bảng-nhãn

Nói chung, tôi không khuyên bạn nên truyền bá TTL, đặc biệt là trên môi trường VPN, ít nhất là trong trường hợp khách hàng của chúng tôi bị nhầm lẫn và lo lắng về nó. Họ lo lắng tại sao VPN của họ có địa chỉ nước ngoài hiển thị.

Một điều nữa khiến mọi người nhầm lẫn khiến họ phải mở một vé hỗ trợ, là khi họ đang chạy một traceroute từ Vương quốc Anh đến Mỹ, bởi vì họ thấy độ trễ> 100ms giữa hai bộ định tuyến lõi ở Anh, không nhận ra rằng toàn bộ đường dẫn có cùng độ trễ tất cả các con đường đến bờ biển phía tây của Hoa Kỳ, bởi vì tất cả các gói đi đường vòng từ đó.

Vấn đề này chủ yếu là không thể sửa được bởi thiết kế, tuy nhiên trong IOS, bạn có thể xác định tối đa bao nhiêu nhãn để bật (mpls ip ttl-expires pop N) khi bạn đang tạo ra vượt quá TTL. Điều này mang lại cho bạn một xấp xỉ khá tốt nếu INET == 1 nhãn, VPN ==> 1 nhãn, do đó bạn có thể định cấu hình để lưu lượng VPN được điều chỉnh và lưu lượng INET được trả lại trực tiếp mà không đi ra khỏi đường vòng nút PE. Nhưng như tôi đã nói, đây chỉ là một xấp xỉ chức năng mong muốn, vì các tính năng như sửa chữa quá cảnh có thể khiến ngăn xếp nhãn của bạn không phải luôn có cùng kích thước cho cùng một dịch vụ.