• 最大 500 の ACE がサポートされます。

• ネイティブ COE のみがサポートされます。

• Cisco IOS XE Bengaluru 17.5.1 では、SR 戦術ポリシーに基づく帯域幅の最適化が RSP3 でサポートされています。

• COE を使用した帯域幅の最適化はサポートされていません。

• PIC コアは SR-TE トンネルではサポートされていません。

• SR-TE を介した PIC エッジはサポートされていません。

• Cisco IOS XE Bengaluru 17.5.1 では、SR-TE を介した ECMP が RSP3 でサポートされています。

• 6PE および 6VPE は、3 つおよび 4 つのトランスポートラベルではサポートされません。

• IPv6 はサポートされていません。

• 最大 10,000 の VPNv4 プレフィックス制限がサポートされています。

• BGP LU（RFC 3107）は、AS 内および AS 間ではサポートされません。

Cisco ASR 900 RSP3 モジュールは、sr_5_label_push_enable および sr_pfp_enable テンプレートをサポートしています。さまざまなテンプレートの組み合わせには、次の制約が適用されます。

sr_5_label_push_enable テンプレートの場合：

• 3 つまたは 4 つの TE ラベルを持つ SR-TE トンネルを介した LB では、1 つのサービスラベルのみがサポートされます。このサービスラベルには、L3VPN、L2VPN、6PE、6VPE、および RFC 3107 BGP-LU ラベルが含まれます。

• 6PE および 6VPE は、3 つおよび 4 つの SR-TE トンネルラベルではサポートされません。

• セグメントルーティングは、enable_portchannel_qos_multiple_active テンプレートではサポートされません。

• L2VPN/EVPN の宛先に SR-TE トンネルを介して設定された静的ルートがある場合、L2VPN/EVPN サービスの HW ロードバランシングはサポートされません。

sr_pfp_enable テンプレートの場合：

• SR PM HW タイムスタンプはサポートされません。

• VLAN COS マーキングはサポートされません。

• HW ロードバランシングはサポートされません。

• 入力でのポリサーベースの階層型 QOS はサポートされません。

• ショートパイプ トンネリング モードはサポートされません。

その他の制約事項：

• SR-TE を介した ECMP は、COE ではサポートされません。

• SR-TE トンネルを介した PIC コアはサポートされません。

• SR TE トンネルを介した PIC エッジはサポートされません。

• SR TE トンネルを介した PIC エッジマルチパスはサポートされません。

• W-ECMP はサポートされません。

• ネクストホップ ECMP は SR ポリシー内ではサポートされません。

• ローカル輻輳緩和（LCM）は、ベストエフォート型トラフィックにのみ適用されます。遅延の影響を受けやすい他のすべてのトラフィックは、安全な SID（Flex Algo 128）を使用します。遅延の影響を受けやすいトラフィックは、LCM トンネルを使用してリダイレクトされません。

現在のネットワーク展開では、ネットワーク内のすべてのルータが、出入りするトラフィックの量に基づいて輻輳を回避するようにトラフィックをプロビジョニングする機能を備えていることが重要です。この輻輳緩和をプロビジョニングするには、ルータが等コストマルチパス（ECMP）のロードバランシングをサポートしている、つまり、宛先に到達するために使用可能なパスの数に基づいてトラフィックを分散している必要があります。

輻輳緩和は、ルータが戦術的 SR ポリシーを使用して、特定のトラフィックを現在のパスとは異なるパスに移動するのに役立ちます。リンク輻輳のしきい値を超えると、インターフェイスカウンタに基づいてリンクの輻輳をモニターする COE（Cisco Optimization Engine）は、PCE を使用してこれらの戦術的ポリシーをプッシュします。ローカル輻輳緩和（LCM）に使用されるこれらの PCE 開始戦術ポリシーは、必要に応じて展開され、ベストエフォート型トラフィックのみがこれらの戦術的 SR-TE ポリシーでロードバランシングされます。

上記のトポロジで、PE1 および PE2 から宛先 PE3 に向かうベストエフォート型トラフィックが P1 に着信し、P1 と PE3 の間のリンクが輻輳していると仮定します。P1 と PE3 の間の輻輳を軽減するには、P1 と PE3 からの ECMP パスが必要です。これはセグメントルーティングでは、P1 から PE3 に複数の戦術的 SR ポリシーを展開し、1 つは直接接続されたリンク P1-PE3 を通し、もう 1 つはパス P1-PE4-PE3 を通すことで実現されます。これらのポリシーは戦術的ポリシーと呼ばれ、これらを介してベストエフォート型トラフィックのロードバランシングを行うことで、ローカル輻輳緩和を回避するために使用されます。LCM はベストエフォート型トラフィックにのみ適用されます。遅延の影響を受けやすい他のすべてのトラフィックは、安全な SID（Flex Algo 128）を使用します。遅延の影響を受けやすいトラフィックは、LCM トンネルを使用してリダイレクトされません。発信元トラフィックは非 LCM トンネルに送られ、safe-SID を持つ中継トラフィックは通常のラベルエントリトラフィックとして扱われ、それに応じて転送されます。

上記のトポロジでは、任意のノードが LCM の戦術的トンネルを展開し、特定のリンク上の輻輳を軽減する場合があります。これらのノードは、LCM トンネルのエンドポイントへ、さらにはトンネルのエンドポイントを越えて、トラフィックを中継したり、場合によっては発信したりします。

PE ノードがトラフィックを発信しており、P ノードが他の場所から発信されたトラフィックの中継ノードであると仮定します。これらの組み合わせに基づいて、考慮する必要があるトラフィックのタイプは次のとおりです。

PE ノードとして、

• L3VPN ベストエフォート型トラフィック

• L2VPN ベストエフォート型トラフィック

• グローバルトラフィック

P ノードとして、

• 非フレキシブルアルゴリズム 0 ラベルに着信するトラフィックは、ラベルルックアップのエントリスワップとして扱われます。

• フレキシブルアルゴリズム 0 ラベルに着信するトラフィックは、スワップケースとして扱われるか、輻輳に基づいてその発信リンク用に作成された LCM がある場合、ラベルのポップおよびプッシュスタックに変換される可能性があります。

LCM トンネルがプッシュする必要のある TE ラベルの数に基づいて、TE ラベルの外側のラベルの数は 1 または 2のいずれかになります（サービスラベル）。

ヘッドエンドでロードバランシングの対象となるさまざまなタイプのトラフィックを下記に示します。ここでのトラフィックタイプには、ベストエフォートと遅延の影響を受けやすいものの両方が含まれます。

PE ノードとして、

• L3VPN トラフィック

• L2VPN トラフィック

• グローバルトラフィック

P ノードとして、

• 着信トラフィックは、ラベルルックアップに基づいて処理されます。

pce
    address ipv4 10.13.13.13
segment-routing traffic-eng
   peer ipv4 10.1.1.1  
    segment-list name ss1
    
    policy 100
     binding-sid mpls 15999
     color 100 end-point ipv4 10.12.12.12
     candidate-paths
      preference 10
       dataplane mpls
 profile-id 100

ここで、PCE が開始した OSPF 自動ルート通知を PCE から PCC にプッシュするには、PCE と PCC のプロファイル ID を一致させる必要があります。次の設定は PCC 設定を示しており、プロファイル ID が PCE と一致しているため、自動ルート通知が有効になっています。

segment-routing traffic-eng                                                             
  pcc
  pce address 10.13.13.13 source-address 10.1.1.1
  profile 100
   autoroute
    include all