集約ラベルが付いたプレフィックスは、MPLSコア全体で完全にトレースルーティングしない

A（Cat6500 w / SUP720-3BXL、IOS 12.2（33）SXH4）およびB（Nexus 7K w / SUP1、NX-OS 5.2（4））の2つのルーターがあり、それぞれMPLSコア全体でいくつかのホップで分離されています。 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に使用されます。2つの直接接続されたルートは共有の集約ラベル（95）を受け取りますが、4つの静的ルートはそれぞれ一意のラベルを受け取ります。

ルータ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

ただし、静的に学習されたすべてのルートへのtracerouteは、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

上記の両方のtracerouteはまったく同じパスをたどる必要があり、それに沿って配置されたフィルタリングメカニズムはありません。同じことが逆方向にも起こります。何が欠けていますか？MPLS /ラベル転送に関して、直接接続と静的構成で学習されたBGPルートの違いは何ですか？

集約ラベルと通常のラベルの違いは、通常のラベルがL2書き換えの詳細（インターフェースとL2アドレス）を直接指すことです。つまり、通常のラベルは、IPルックアップを行わずに、出力PEノードによって直接ラベルスイッチングされます。

逆に、集約ラベルは多くの異なる出力オプションを表す可能性があるため、L2書き換え情報はラベル自体に関連付けられていません。つまり、出力PEノードはパケットのIPルックアップを実行して、適切なL2書き換え情報を決定する必要があります。

通常のラベルの代わりに集約ラベルを使用する一般的な理由は次のとおりです。

1. 近隣探索を実行する必要があります（IPv4 ARP、IPv6 ND）
2. ACLルックアップを実行する必要があります（カスタマーインターフェイスの出力ACL）
3. VRF全体を単一のラベルの下で実行（テーブルラベル）

これらの制限の一部（特に2）は、すべてのプラットフォームに有効なわけではありません。

MPLS VPN環境でtracerouteがどのように影響を受けるかは、トランジットPによるもので、TTL超過メッセージを生成するときに、それを返す方法がわかりません（送信者へのルーティングテーブルエントリがありません）。したがって、トランジットPノードは、TTL超過メッセージを送信元に送信する方法のアイデアが出力PEノートにあることを期待して、元のラベルスタックとともに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に外部アドレスが表示されるのかを心配しています。

人々がサポートチケットを開かせるのを混乱させるもう1つのことは、彼らがUKからUSへのtracerouteを実行しているときです。彼らはUKの2つのコアルーター間のレイテンシが> 100msであり、パス全体が同じレイテンシであることを認識していないためですすべてのパケットがそこから迂回するので、米国の西海岸までずっと。

この問題は、ほとんどの場合、設計上修正できませんが、IOSでは、TTLを超えたときに生成するラベルの最大数（mpls ip ttl-expiration pop N）を決定できます。これにより、INET == 1ラベル、VPN ==> 1ラベルの場合、ある程度まともな近似が得られるため、VPNトラフィックがトンネリングされ、出力PEノードの迂回なしでINETトラフィックが直接返されるように構成できます。ただし、前述のとおり、これは目的の機能の近似にすぎません。輸送中の修理などの機能により、同じサービスに対してラベルスタックが常に同じサイズになるとは限らない場合があるためです。