MPLS 코어에서 완전히 추적 라우팅되지 않는 집계 레이블이있는 접두사

MPLS 코어에서 여러 개의 홉으로 분리 된 두 개의 라우터 A (Cat6500 w / SUP720-3BXL, IOS 12.2 (33) SXH4) 및 B (Nexus 7K w / SUP1, NX-OS 5.2 (4))가 있습니다. VRF ABC. 라우터 A에는이 VRF 내에 직접 연결된 2 개의 경로와 4 개의 정적 경로가 있습니다.

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

위의 두 추적 경로는 정확히 동일한 경로를 따라야하며 그에 따라 필터링 메커니즘이 없습니다. 반대 방향에서도 마찬가지입니다. 내가 무엇을 놓치고 있습니까? MPLS / 라벨 전달과 관련하여 직접 연결과 정적 구성에서 학습 한 BGP 경로의 차이점은 무엇입니까?

mpls troubleshooting

— 제레미 스트레치
소스

주제가 잘못 되었습니까? 집계 레이블이 경로가 미세하고 일반 레이블이 아닌 것처럼 보입니까? 이것은 어떤 플랫폼입니까? TTL 숨기기 또는 기타 특정 명령과 관련하여 구성된 것이 있습니까? VPN에서 추적 경로는 TTL을 초과하기 전에 항상 송신 PE로 이동하므로 집계되지 않은 레이블의 경우 실제로 TTL을 초과하지 않습니다.

— ytti

플랫폼 (IOS 및 NX-OS)을 반영하도록 질문을 업데이트했습니다.

— Jeremy Stretch

MPW 환경에서 TTL 감소를 처리 할 때 sup720-3bxl에는 HW 제한이 있습니다. 양방향 또는 한 방향으로 만 문제가 발생합니까?

— ytti

정적으로 학습 된 경로의 반대 방향도 마찬가지입니다. 라우터 A가 SUP720-3BXL을 실행 중입니다. 언급 한 제한에 대해 자세히 설명해 주시겠습니까?

— Jeremy Stretch

불행히도 sup720-3blx (또는 PFC3B는 정확히, PFC3C는 고정되어 있음) 문제를 조금 더 생각하면 이것을 설명하지 못합니다. 그 이후로 당신은 traceroute에서 egress PE를 완전히 놓칠 것입니다 (별 없음). 그리고 그것은 양방향에 동일한 문제가 없을 것입니다.

— ytti

집계 레이블과 일반 레이블의 차이점은 일반 레이블이 L2 다시 쓰기 세부 사항 (인터페이스 및 L2 주소)을 직접 가리 키도록하는 것입니다. 즉, IP 조회를 수행하지 않고 일반 PE 라벨이 송신 PE 노드에 의해 직접 라벨 교환됩니다.

반대로 집계 레이블은 잠재적으로 여러 가지 다른 송신 옵션을 나타낼 수 있으므로 L2 다시 쓰기 정보는 레이블 자체와 관련이 없습니다. 즉, 송신 PE 노드는 패킷에 대한 IP 조회를 수행하여 적절한 L2 다시 쓰기 정보를 결정해야합니다.

일반 레이블 대신 집계 레이블이있는 일반적인 이유는 다음과 같습니다.

이웃 검색을 수행해야합니다 (IPv4 ARP, IPv6 ND)
ACL 조회를 수행해야합니다 (고객 인터페이스의 발신 ACL)
단일 레이블 (테이블 레이블)에서 전체 VRF 실행

이러한 제한 중 일부 (특히 2)는 모든 플랫폼에 유효하지 않습니다.

MPLS VPN 환경에서 traceroute가 TTL 초과 메시지를 생성 할 때 전송 P에 의해 영향을받는 방식은 메시지를 반환하는 방법을 알 수 없습니다 (발신자에게 라우팅 테이블 항목이 없음). 따라서 통과 P 노드는 발신 라벨에 TTL 초과 메시지를 발신자에게 반환하는 방법에 대한 아이디어가 있기를 바라면서 발신 라벨에 TTL 초과 메시지를 원본 PE 스택으로 전송합니다.
이 기능은 Cisco IOS에서 자동으로 설정되지만 Juniper JunOS에서 'icmp-tunneling'을 구성해야합니다.

이를 바탕으로 소스 주소가 P 노드 링크 네트워크 인 경우 CE 장치가 패킷을 수락하지 않을 수 있으며 ICMP 메시지를 수신하지 않기 때문에 발신자에게 반송 할 수 없습니다.
이 이론에 대한 가능한 방법 테스트는 VRF 레이블을 활성화하는 것입니다.

iOS : mpls 레이블 모드 all-vrfs 프로토콜 bgp-vpnv4 per-vrf
JunOS : 라우팅 인스턴스 설정 FOO vrf-table-label

일반적으로 말하자면, 특히 VPN 환경에서 TTL을 전파하는 것은 권장하지 않습니다. 적어도 우리의 경우 고객은 혼란스럽고 불안해합니다. VPN에 외부 주소가 표시되는 이유가 걱정됩니다.

지원 티켓을 여는 사람들을 혼란스럽게 만드는 또 다른 것은 영국에서 미국으로 추적 경로를 실행하는 경우입니다. 영국의 두 코어 라우터 사이에 100ms 이상의 대기 시간이 있기 때문에 전체 경로가 동일한 대기 시간을 갖는 것은 아닙니다. 모든 패킷이 거기서 우회하기 때문에 미국 서해안으로가는 길입니다.

이 문제는 대부분 설계 상으로는 해결할 수 없지만, IOS에서는 TTL을 생성 할 때 최대 몇 개의 레이블 (IP ttl-expiration pop N)을 결정할 수 있습니다. 이는 INET == 1 레이블, VPN ==> 1 레이블 인 경우 다소 적절한 근사값을 제공하므로 VPN 트래픽이 터널링되고 INET 트래픽이 송신 PE 노드 우회없이 직접 반환되도록 구성 할 수 있습니다. 그러나 내가 말했듯이, 이는 운송 중 수리와 같은 기능으로 인해 동일한 서비스에서 레이블 스택의 크기가 항상 같지 않을 수 있기 때문에 원하는 기능의 근사치입니다.

— 이티
소스