MPLSトラフィックの負荷分散
MPLSラベルに基づいたロードバランシングの設定
負荷分散は、サポートされているプラットフォーム上の MPLS フローに対してパケット単位で行われます。エントロピー(ランダム分散)は、パケットをネクストホップに均一に分散するために不可欠です。デフォルトでは、ロードバランシングを使用してトラフィックを分散する場合、Junos OSはハッシュアルゴリズムを採用して、転送テーブルにインストールするネクストホップアドレスを選択します。宛先のネクストホップのセットが変更されるたびに、ハッシュアルゴリズムによってネクストホップアドレスが再選択されます。ハッシュ アルゴリズムを使用して、一連の等コストのラベル スイッチ パス(LSP)間でトラフィックをロード バランシングする方法を設定できます。
VPLSおよびVPWSトラフィックのエントロピーを確保するために、Junos OSはIPヘッダーと最大3つのMPLSラベル(いわゆるトップラベル)からのデータに基づいてハッシュを作成できます。
場合によっては、ラベルを使用するネットワーク機能(MPLS、高速再ルート、RFC 3107、RSVP、VPN など)の数が増えると、上位 3 つのラベルのデータが静的になり、エントロピーの十分なソースにはならないことがあります。その結果、ロードバランシングが歪んだり、順序外れたパケット配信の発生率が上昇したりする可能性があります。このような場合は、ラベルスタックの最下部のラベルを使用できます(修飾については、以下の表1を参照してください)。トップラベルとボトムラベルを同時に使用することはできません。
MPCカードは通常のハッシュキー設定をサポートしていません。MPCベースのハッシュキー設定を有効にするには、 enhanced-hash-key 設定が必要です。
ロードバランシングは、以下の条件が当てはまる場合にトラフィックを均等に分散するために使用されます。
同じ宛先への異なるインターフェイス上のイコールコストネクストホップが複数存在します。
集合型インターフェイス上にネクストホップが1つ存在します。
LSP は、等コストのネクストホップの 1 つをランダムに選択し、それを排他的に使用することで、配置の負荷分散を行う傾向があります。ランダム選択は各トランジットルーターで独立して行われ、内部ゲートウェイプロトコル(IGP)メトリックのみが比較されます。帯域幅や輻輳レベルは考慮されません。
この機能は、集約型イーサネットおよび集約型SONET/SDHインターフェイス、ならびに複数のイコールコストMPLSネクストホップに適用されます。さらに、T Series、MXシリーズ、M120、およびM320ルーターでのみ、レイヤー2イーサネット疑似配線を介したIPv4トラフィックのロードバランシングを設定できます。また、IP 情報に基づいてイーサネット疑似配線のロードバランシングを設定することもできます。ハッシュキーにIP情報を含めるオプションは、イーサネット回線クロスコネクト(CCC)接続をサポートします。
MPLSラベル情報に基づいてロードバランシングを行うには、 family mpls ステートメントを設定します。
[edit forwarding-options hash-key] family mpls { all-labels; bottom-label-1; bottom-label-2; bottom-label-3; label-1; label-2; label-3; no-labels; no-label-1-exp; payload { ether-pseudowire; ip { disable; layer-3-only; port-data { destination-lsb; destination-msb; source-lsb; source-msb; } } } }
以下の階層レベルでこのステートメントを含めることができます。
[edit forwarding-options hash-key]
表1 は、可能なすべてのMPLS LSPロードバランシングオプションの詳細情報を示しています。
ステートメント |
サポート対象プラットフォーム |
MPLS LSP ロードバランシングオプション |
|---|---|---|
|
MXシリーズおよびPTXシリーズ |
Junos OSリリース19.1R1以前は、パケット転送エンジン内のフローの一意性を識別するために、ハッシュキーに最大8個のMPLSラベルが含まれていました。PTXシリーズルーターでは、この値がデフォルトで設定されます。 Junos OSリリース19.1R1以降、MPCおよびMICインターフェイスを搭載したMXシリーズルーターでは、最大16個の受信MPLSラベルがハッシュキーに含まれるようになりました。 |
|
DPC搭載のMXシリーズ(Iチップ)。M10i、M7i、および M120 ではサポートされていません。 |
ハッシュキーの計算には、例えば、必要なレベルのエントロピーに対して最下段のラベルが十分な変数を提供できない場合などに使用します。 |
|
DPC搭載のMXシリーズ(Iチップ)。M10i、M7i、および M120 ではサポートされていません。 |
たとえば、上のラベルが必要なレベルのエントロピーに十分な変数を提供しない場合など、ハッシュキーの計算に下から2番目のラベルを使用します。 |
|
DPC搭載のMXシリーズ(Iチップ)。M10i、M7i、および M120 ではサポートされていません。 |
ハッシュキーの計算には、下から3番目のラベルを使用します(たとえば、上のラベルが必要なエントロピーレベルに十分な変数を提供しない場合など)。 |
|
M Series、MXシリーズ、T Series |
ハッシュキーに最初のラベルを含めます。このオプションは、単一ラベルパケットに使用します。 |
|
M Series、MXシリーズ、T Series |
ハッシュキーに2番目のラベルを含めます。 |
|
M Series、MXシリーズ、T Series |
ハッシュキーに3番目のラベルを含めます。また、 |
|
すべて |
ハッシュキーからMPLSラベルを除外します。 |
|
M Series、MXシリーズ、T Series |
トップラベルのEXPビットをハッシュキーから除外します。 レイヤー 2 VPN では、ルーターでパケットの並べ替えの問題が発生する可能性があります。トラフィックのバーストによって顧客トラフィックの帯域幅が制限を超えると、フローの途中でトラフィックが影響を受ける可能性があります。その結果、パケットの順序が変更される可能性があります。ハッシュキーからEXPビットを除外することで、この並べ替えの問題を回避できます。 |
|
すべて |
ハッシュキーに含めるIPパケットペイロードのどの部分を設定できます。PTXシリーズパケットトランスポートルーターの場合、この値がデフォルトで設定されます。 |
|
PTXシリーズ |
ハッシュキーからIPペイロードを除外します。 |
|
M120、M320、MXシリーズ、T Series |
レイヤー2イーサネット疑似配線を介してIPv4トラフィックをロードバランシングします。 |
|
すべて |
ハッシュキーにIPv4またはIPv6アドレスを含めます。また、 |
|
すべて |
ハッシュキーにはレイヤー3のIP情報のみを含めます。ハッシュキーからすべての |
|
M Series、MXシリーズ、T Series |
送信元と宛先ポートのフィールド情報を含めます。デフォルトでは、送信元ポートフィールドと宛先ポートフィールドの最上位バイトと最下位バイトがハッシュキーに使用されます。ハッシュキーで使用する特定のバイトを選択するには、 |
|
M Series、MXシリーズ、T Series |
ハッシュキーには宛先ポートの最下位バイトを含めます。他の |
|
M Series、MXシリーズ、T Series |
ハッシュキーには宛先ポートの最上位バイトを含めます。他の |
|
M Series、MXシリーズ、T Series |
ハッシュキーには送信元ポートの最下位バイトを含めます。他の |
|
M Series、MXシリーズ、T Series |
送信元ポートの最上位バイトをハッシュキーに含めます。他の |
次の例は、MPLS LSP ロードバランシングを設定する方法を示しています。
ハッシュキーにIPアドレスと最初のラベルを含めるには:
M Series、MXシリーズ、およびT Seriesルーターでは、
[edit forwarding-options hash-key family mpls]階層レベルでlabel-1ステートメントとpayloadステートメントのipオプションを設定します。[edit forwarding-options hash-key family mpls] label-1; payload { ip; }PTXシリーズパケットトランスポートルーターでは、
all-labelsオプションとip payloadオプションがデフォルトで設定されているため、設定する必要はありません。
(M320およびT Seriesルーターのみ)ハッシュキーにIPアドレスと1番目と2番目のラベルの両方を含めるには、
[edit forwarding-options hash-key family mpls]階層レベルでpayloadステートメントのlabel-1とlabel-2オプションとipオプションを設定します。[edit forwarding-options hash-key family mpls] label-1; label-2; payload { ip; }注:このステートメントの組み合わせは、M320およびT Seriesルーターにのみ含めることができます。これらを M Series マルチサービス エッジ ルーターに含めると、最初の MPLS ラベルと IP ペイロードのみがハッシュ キーに使用されます。
T Seriesルーターの場合、
[edit forwarding-options hash-key family mpls]階層レベルにlabel-1、label-2、label-3オプションを含めて、適切なロードバランシングを確保します。[edit forwarding-options hash-key family mpls] label-1; label-2; label-3;
(M Series、MXシリーズ、T Seriesルーターのみ)レイヤー 2 VPN では、ルーターでパケットの並べ替えの問題が発生する可能性があります。トラフィックのバーストによって顧客トラフィックの帯域幅が制限を超えると、フローの途中でトラフィックが影響を受ける可能性があります。その結果、パケットの順序が変更される可能性があります。ハッシュキーからEXPビットを除外することで、この並べ替えの問題を回避できます。最初のラベルのEXPビットをハッシュ計算から除外するには、
[edit forwarding-options hash-key family mpls]階層レベルにno-label-1-expステートメントを含めます。[edit forwarding-options hash-key family mpls] label-1; no-label-1-exp; payload { ip; }
例:負荷分散 MPLS ネットワーク
同じegressルーターに複数のRSVP LSPを設定すると、メトリックが最も低いLSPが選択され、すべてのトラフィックを伝送します。すべてのLSPのメトリックが同じ場合、LSPの1つがランダムに選択され、すべてのトラフィックがその上に転送されます。すべてのLSPにトラフィックを均等に分散するために、設定されたロードバランシングのタイプに応じて、イングレスルーターまたはトランジットルーターでロードバランシングを設定できます。
図1は、同じegressルーター(R0)に4つのLSPを設定したMPLSネットワークを示しています。ロード バランシングは、ingressルーター R1 で設定されています。この例のネットワークでは、OSPFエリアが0.0.0.0の内部ゲートウェイプロトコル(IGP)としてOpen Shortest Path First(OSPF)を使用しています。IGPは、Junos OSのデフォルトであるCSPF(Constrained Shortest Path First)LSPに必要です。さらに、このサンプルネットワークでは、ポリシーを使用してBGPトラフィックを作成しています。
図1に示すネットワークは、以下のコンポーネントで構成されています。
-
AS 65432を使用したフルメッシュ内部BGP(IBGP)トポロジー
-
すべてのルーターでMPLSとRSVPが有効
-
新しいルートをネットワークにアドバタイズすることを許可する ルーターR1 および R0 のsend-staticsポリシー
-
R1とR0の間に4つの単方向LSP、R0とR1の間に1つの逆方向LSPがあり、双方向トラフィックが可能です。
-
ingressルーターR1に設定されたロードバランシング
図1に示したネットワークは、BGPフルメッシュネットワークです。ルートリフレクタとコンフェデレーションは、BGPで学習したルートを伝播するために使用されないため、各ルーターは、BGPを実行している他のすべてのルーターとBGPセッションを持つ必要があります。
負荷分散された MPLS ネットワークのルーター設定
目的
このトピックの設定は、 ロードバランシングネットワークトポロジーで説明されているネットワーク例の6台の負荷分散ルーター用です。
アクション
ルーターの設定を表示するには、次の Junos OS CLI 運用モード コマンドを使用します。
user@host> show configuration | no-more
サンプル出力 1
以下の設定出力は、エッジルーター R6 のものです。
user@R6> show configuration | no-more
[...Output truncated...]
interfaces {
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.16.14/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
fe-1/3/0 {
unit 0 {
family inet {
address 10.10.12.1/24;
}
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.148/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.6.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
router-id 192.168.6.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
}
protocols {
rsvp {
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
}
mpls {
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.6.1;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.4.1;
neighbor 192.168.9.1;
neighbor 192.168.0.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface fe-0/1/2.0;
interface fe-1/3/0.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
サンプル出力2
以下の設定出力は、ingressルーター R1 のものです。
user@R1> show configuration | no-more
[...Output truncated...]
interfaces {
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.12.13/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.16.13/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.143/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.1.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
route 100.100.1.0/24 reject; #Static route for send-statics policy
}
router-id 192.168.1.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
forwarding-table {
export lbpp; #Routes exported to forwarding table
}
}
protocols {
rsvp {
interface fe-0/1/0.0;
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
}
mpls {
label-switched-path lsp 1 { #First LSP
to 192.168.0.1; # Destination of the LSP
install 10.0.90.14/32 active; # The prefix is installed in the
primary via-r4; # inet.0 routing table
}
label-switched-path lsp2 {
to 192.168.0.1;
install 10.0.90.14/32 active;
primary via-r2;
}
label-switched-path lsp3 {
to 192.168.0.1;
install 10.0.90.14/32 active;
primary via-r2;
}
label-switched-path lsp4 {
to 192.168.0.1;
install 10.0.90.14/32 active;
primary via-r4;
}
path via-r2 { #Primary path to spread traffic across interfaces
10.0.29.2 loose;
}
path via-r4 {
10.0.24.2 loose;
}
interface fe-0/1/0.0;
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
}
bgp {
export send-statics; #Allows advertising of a new route
group internal {
type internal;
local-address 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.4.1;
neighbor 192.168.9.1;
neighbor 192.168.6.1;
neighbor 192.168.0.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface fe-0/1/0.0;
interface fe-0/1/2.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
policy-options { #Load balancing policy
policy-statement lbpp {
then {
load-balance per-packet;
}
}
policy-statement send-statics { #Static route policy
term statics {
from {
route-filter 100.100.1.0/24 exact;
}
then accept;
}
}
}
サンプル出力 3
以下の設定出力はトランジット ルーター R2 のものです。
user@R2> show configuration | no-more
[...Output truncated...]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.0.24.1/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.0.29.1/30;
}
family mpls;
}
}
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.12.14/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.144/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.2.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
router-id 192.168.2.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
}
protocols {
rsvp {
interface so-0/0/1.0;
interface fe-0/1/0.0;
interface so-0/0/2.0;
interface fxp0.0 {
disable;
}
}
mpls {
interface fe-0/1/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.2.1;
neighbor 192.168.1.1;
neighbor 192.168.4.1;
neighbor 192.168.9.1;
neighbor 192.168.6.1;
neighbor 192.168.0.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface fe-0/1/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
サンプル出力 4
以下の設定出力はトランジット ルーター R4 のものです。
user@R4> show configuration | no-more
[...Output truncated...]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.0.24.2/30;
}
family mpls; # MPLS enabled on relevant interfaces
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.0.49.1/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.146/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.4.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
router-id 192.168.4.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
protocols {
rsvp {
interface so-0/0/1.0;
interface so-0/0/3.0;
interface fxp0.0 {
disable;
}
}
mpls {
interface so-0/0/1.0;
interface so-0/0/3.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.4.1;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.9.1;
neighbor 192.168.6.1;
neighbor 192.168.0.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/1.0;
interface so-0/0/3.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
サンプル出力 5
以下の設定出力はトランジット ルーター R9 のものです。
user@R9> show configuration | no-more
[...Output truncated...]
interfaces {
so-0/0/2 {
unit 0 {
family inet {
address 10.0.29.2/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.0.49.2/30;
}
family mpls;
}
}
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.90.13/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.69.206/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.9.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
router-id 192.168.9. 1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
protocols {
rsvp {
interface so-0/0/2.0;
interface so-0/0/3.0;
interface fe-0/1/0.0;
interface fxp0.0 {
disable;
}
}
mpls {
interface so-0/0/2.0;
interface so-0/0/3.0;
interface fe-0/1/0.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.9.1;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.4.1;
neighbor 192.168.0.1;
neighbor 192.168.6.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/2.0;
interface so-0/0/3.0;
interface fe-0/1/0.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
サンプル出力 6
以下の設定出力は、egress ルーターR0のものです。
user@R0> show configuration | no-more
[...Output truncated...]
interfaces {
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.90.14/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
fe-1/3/0 {
unit 0 {
family inet {
address 10.10.11.1/24;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.69.207/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
route 100.100.10.0/24 reject; #Static route for send-statics policy
}
router-id 192.168.0.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
protocols {
rsvp {
interface fe-0/1/0.0;
interface fe-1/3/0.0;
interface fxp0.0 {
disable;
}
}
mpls {
label-switched-path r0-r6 {
to 192.168.6.1;
}
interface fe-0/1/0.0;
interface fe-1/3/0.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.0.1;
export send-statics; #Allows advertising of a new route
neighbor 192.168.9.1;
neighbor 192.168.6.1;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.4.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface fe-0/1/0.0;
interface fe-1/3/0.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
policy-options {
policy-statement send-statics {
term statics {
from {
route-filter 100.100.10.0/24 exact;
}
then accept;
}
}
}
意味
サンプル出力 1 から 6 は、 例: 負荷分散 MPLS ネットワークに示されているネットワーク例における 6 台のルーターすべてのベース インターフェイス、ルーティング オプション、プロトコル、ポリシー オプションの設定を示しています。
ネットワーク内のすべてのルーターで、MPLS、RSVP、BGPが有効になっています。OSPFはIGPとして設定されており、関連するインターフェイスには基本的なIP情報とMPLSサポートがあります。
さらに、すべてのルーターには、重複するRID問題を回避するために、 [edit routing-options] 階層レベルで手動で設定されたルーター ID(RID)があります。 passive ステートメントは、プロトコルがループバック(lo0)インターフェイス上で実行されないようにし、ループバック(lo0)インターフェイスがネットワーク全体で正しくアドバタイズされることを保証するために、OSPF設定に含まれています。
R6、R2、R4、R9のサンプル出力1、3、4、および5は、トランジットラベルスイッチルーターの基本設定を示しています。基本設定には、MPLS が有効になっているすべてのインターフェイス、手動で設定された RID、および関連するプロトコル(RSVP、MPLS、BGP、OSPF)が含まれます。
ingressルーター R1 からのサンプル出力 2 は、ベース設定に加えて、R0 に設定された 4 つの LSP(lsp1 から lsp4)を示しています。4つのLSPは、lsp1とlsp4に対してR4を、そしてlsp2とlsp3に対してR2を介したルーズホップを指定する異なるプライマリパスで設定されています。
トラフィックを作成するために、R1には[edit routing-options static route]階層レベルで設定されたスタティックルート(100.100.1.0/24)があります。プレフィックスは、[edit policy-options send statics]階層レベルの送信静的ポリシーに含まれるため、ルートをBGPルートにすることができます。
さらに、ingressルーター R1では、 パケットごとの オプションを使用してロードバランシングが設定され、ポリシーは [edit routing-options forwarding-table] 階層レベルでエクスポートされます。
egress ルーターR0 からのサンプル出力6には、双方向トラフィックの作成に使用される1つのLSP(r0-r6)から R6 が表示されています。OSPFは、LSPをIGPにアドバタイズする前に、双方向LSPの到達可能性IGPを必要とします。LSPはIGPにアドバタイズされますが、helloメッセージやルーティング更新はLSP上で発生せず、ユーザートラフィックのみがLSPを介して送信されます。ルーターは、IGPデータベースのローカルコピーを使用して、双方向の到達可能性を検証します。
さらに、R0 には、[edit routing-options static route]階層レベルで設定されたスタティック ルート(100.100.10.0/24)があります。プレフィックスは、[edit policy-options send statics]階層レベルのsend-staticsポリシーに含まれるため、ルートをBGPルートにすることができます。
ACXシリーズルーターでのMPLSラベルに基づくロードバランシングの設定
表2 は、可能なすべてのMPLS LSPロードバランシングオプションの詳細情報を示しています。
ACXシリーズルーターは、MPLSでパケット単位でロードバランシングを行うことができます。負荷分散は、IP ヘッダーと最大 3 つの MPLS ラベルの両方の情報に対して実行でき、MPLS トラフィックをネクスト ホップに均一に分散できます。この機能は、サポートされているプラットフォームでデフォルトで有効になっており、設定は必要ありません。
ロードバランシングは、集約されたインターフェイスまたはLAGバンドル上に単一のネクストホップがある場合に、トラフィックを均等に分散するために使用されます。MPLSラベルを使用した負荷分散は、LAGインターフェイスでのみサポートされており、ECMP(等価コストマルチパス)リンクではサポートされていません。
デフォルトでは、ロードバランシングを使用してトラフィックを分散する場合、Junos OSはハッシュアルゴリズムを採用して、転送テーブルにインストールするネクストホップアドレスを選択します。宛先のネクストホップのセットが何らかの形で変更されるたびに、ハッシュアルゴリズムによってネクストホップアドレスが再選択されます。ハッシュアルゴリズムを使用して、集合型イーサネット(ae)インターフェイス内のインターフェイス間でトラフィックをロードバランシングする方法を設定できます。
LSP は、 ae- インターフェイスバンドル内のインターフェイスの 1 つをランダムに選択し、それを排他的に使用することで、配置の負荷分散を行う傾向があります。ランダム選択は各トランジットルーターで独立して行われ、内部ゲートウェイプロトコル(IGP)メトリックのみが比較されます。帯域幅や輻輳レベルは考慮されません。
MPLSラベル情報に基づいてロードバランシングを行うには、 family mpls ステートメントを設定します。
[edit forwarding-options hash-key] family mpls { all-labels; label-1; label-2; label-3; no-labels; payload { ether-pseudowire; ip { layer-3-only; port-data { destination-lsb; destination-msb; source-lsb; source-msb; } } } }
このステートメントを [edit forwarding-options hash-key] 階層レベルに含めることができます。
ペイロードip(user@host# set forwarding-options hash-key family mpls payload ip)を設定する場合、 layer-3-only と port-data の設定は必須です。
適切なハッシュキー構成がないロードバランシング機能では、予測不能な動作が発生する可能性があります。
ACX7000シリーズのデバイスは port-dataをサポートしていません。
レイヤー 2 VPN/疑似回線トンネル終端では、最大 2 つのラベルがハッシュに使用され、ペイロード MAC の宛先アドレスと送信元アドレスをオプションで選択できます。これらのコントロールは、上記のハッシュキー設定の下で、ファミリーMPLSのイーサ擬似回線ノブをサポートするために使用できます。ただし、ACX2000およびACX4000もTDM疑似配線をサポートしているため、イーサ疑似配線ノブは、TDM疑似配線が使用されていない場合にのみ使用する必要があります。
レイヤー 3 VPN トンネル終端では、最大 2 つのラベルが IP 送信元と宛先アドレスの構成とペイロードに使用され、レイヤー 4 の送信元と宛先ポートをオプションで選択できます。これらのコントロールは、上記のハッシュキー設定の下で、ファミリーMPLSのIPポートデータノブをサポートするために使用できます。ただし、レイヤー4ポートMSBとLSBを個別に選択できないため、destination-lsbまたはdestination-msbノブの1つ、またはsource-lsbまたはsource-msbノブのいずれかで、それぞれレイヤー4の宛先ポートまたは送信元ポートが選択されます。
LSRの場合、ハッシュには最大3つのラベルが使用されます。最初の 3 つのラベルを解析するときに BOS が表示された場合、BCM はペイロードの最初のニブルを調べます。ニブルが 4 の場合、ペイロードは IPv4 として扱われ、最初のニブルが 6 の場合、ペイロードは IPv6 として扱われ、そのような場合、ペイロードの送信元と宛先の IP アドレスを推測的にハッシュに使用できます。これらのコントロールは、ハッシュキー設定でファミリーMPLSのIPポートデータノブをサポートするために使用できます。ただし、レイヤー4ポートはLSRの場合のハッシュに使用できず、レイヤー3専用ノブのみ適用可能です。BCMは、3つのMPLSラベルを超えるフィールドでのハッシュのサポートを主張していません。LSR の場合、そのセッションに固有のすべてのトラフィックが同じ MPLS ラベルのセットを伝送するため、単一擬似回線セッションの負荷分散は行われません。
LSR AE インターフェイスのロード バランシングは、より多くの MPLS セッション、つまり最低 10 セッションに対して実現できます。これは、CCC/VPLS/L3VPNに適用されます。レイヤー 3 VPN の場合、レイヤー 3 アドレスも(ラベルとともに)ハッシュ入力機能で説明されるため、トラフィックがメンバー リンク全体に均等に分散されない可能性があります。
LERシナリオでは、ACX5048とACX5096の場合、「family mpls」階層の下にペイロードオプションを設定することで、レイヤー3およびレイヤー4フィールドに基づくハッシュ化が可能になります。LERのハッシュはラベルに基づいていません。レイヤー3サービスの場合、ペイロードを「layer-3-only」と明記し、レイヤー4サービスの場合は「port-data」を指定することが必須です。また、LERルーターでハッシュキーを設定する際に、ラベル数を指定することもできます。
LERおよびLSRのロードバランシング動作は、CCC/VPLS/レイヤー3 VPNおよびその他のIP MPLSシナリオに適用できます。
この機能は、集合型イーサネットおよび集合型SONET/SDHインターフェイスに適用されます。さらに、レイヤー 2 イーサネット疑似配線を介した IPv4 トラフィックのロードバランシングを設定できます。また、IP 情報に基づいてイーサネット疑似配線のロードバランシングを設定することもできます。ハッシュキーにIP情報を含めるオプションは、イーサネット回線クロスコネクト(CCC)接続をサポートします。
| ステートメント |
MPLS LSP ロードバランシングオプション |
|---|---|
|
|
ハッシュキーに最初のラベルを含めます。このオプションは、単一ラベルパケットに使用します。 |
|
|
ハッシュキーに2番目のラベルを含めます。 |
|
|
ハッシュキーに3番目のラベルを含めます。また、 |
|
|
ハッシュキーからMPLSラベルを除外します。 |
|
|
ハッシュキーに含めるIPパケットペイロードのどの部分を設定できます。PTXシリーズパケットトランスポートスイッチの場合、この値がデフォルトで設定されます。 |
|
|
ハッシュキーからIPペイロードを除外します。 |
|
|
レイヤー2イーサネット疑似配線を介してIPv4トラフィックをロードバランシングします。 |
|
|
ハッシュキーにIPv4またはIPv6アドレスを含めます。また、 |
|
|
ハッシュキーにはレイヤー3のIP情報のみを含めます。ハッシュキーからすべての |
|
|
送信元と宛先ポートのフィールド情報を含めます。デフォルトでは、送信元ポートフィールドと宛先ポートフィールドの最上位バイトと最下位バイトがハッシュキーに使用されます。ハッシュキーで使用する特定のバイトを選択するには、 |
|
|
ハッシュキーには宛先ポートの最下位バイトを含めます。他の |
|
|
ハッシュキーには宛先ポートの最上位バイトを含めます。他の |
|
|
ハッシュキーには送信元ポートの最下位バイトを含めます。他の |
|
|
送信元ポートの最上位バイトをハッシュキーに含めます。他の |
ハッシュキーにIPアドレスと最初のラベルを含めるには、[edit forwarding-options hash-key family mpls]階層レベルでpayloadステートメントのlabel-1ステートメントとipオプションを設定します。
[edit forwarding-options hash-key family mpls]
label-1;
payload {
ip;
}
ハッシュキーにIPアドレスと1番目と2番目のラベルの両方を含めるには、[edit forwarding-options hash-key family mpls]階層レベルでpayloadステートメントのlabel-1とlabel-2オプションとipオプションを設定します。
[edit forwarding-options hash-key family mpls]
label-1;
label-2;
payload {
ip;
}
[edit forwarding-options hash-key family mpls]階層レベルでlabel-1、label-2、label-3オプションを含めて、適切なロードバランシングを確保します。
[edit forwarding-options hash-key family mpls] label-1; label-2; label-3;
MPLS カプセル化ペイロード ロード バランシングの概要
ルーターは、MPLS でパケットごとにロード バランシングを行うことができます。負荷分散は、IP ヘッダーと最大 3 つの MPLS ラベルの両方の情報に対して実行でき、MPLS トラフィックをネクスト ホップに均一に分散できます。
ロードバランシングは、以下の条件が当てはまる場合にトラフィックを均等に分散するために使用されます。
同じ宛先への異なるインターフェイス上のイコールコストネクストホップが複数存在します。
集合型インターフェイス上にネクストホップが1つ存在します。
デフォルトでは、ロードバランシングを使用してトラフィックを分散する場合、ハッシュアルゴリズムを使用して、転送テーブルにインストールするネクストホップアドレスが選択されます。宛先のネクストホップのセットが何らかの形で変更されるたびに、ハッシュアルゴリズムによってネクストホップアドレスが再選択されます。
MPLS 上のイーサネットやイーサネット疑似回線など、複数のトランスポート層ネットワークが存在する場合、ハッシュ アルゴリズムは、均等な分布を生成するために、ペイロードの外側のヘッダーを超えて内側のヘッダーを覗く必要があります。内部カプセル化を決定するために、PFEは、固定ペイロードオフにおける特定のコードまたは数値の存在に依存します。例えば、IPv4パケットのペイロードタイプ0X800の存在やプロトコル番号4の存在などです。Junos OSでは、 zero-control-word オプションを設定して、MPLSイーサ擬似回線ペイロード内のイーサネットフレームの開始を示すことができます。この制御ワード(数値はすべてゼロを含む4バイト)を確認すると、ハッシュジェネレータは、MPLSイーサ疑似回線パケットの制御ワードの末尾でイーサネットフレームの開始を前提とします。
DPC Iチップベースのカードの場合は、[edit forwarding-options hash-key family mpls ether-pseudowire]階層レベルでzero-control-wordオプションを設定し、MPCカードの場合は、[edit forwarding-options enhanced-hash-key family mpls ether-pseudowire]階層レベルでzero-control-wordオプションを設定します。
負荷分散のための MPLS カプセル化ペイロードの設定
デフォルトでは、ロードバランシングを使用してトラフィックを分散する場合、ハッシュアルゴリズムを使用して、転送テーブルにインストールするネクストホップアドレスが選択されます。宛先のネクストホップのセットが何らかの形で変更されるたびに、ハッシュアルゴリズムによってネクストホップアドレスが再選択されます。 zero-control-word オプションを設定して、MPLSイーサ擬似回線ペイロード内のイーサネットフレームの開始を示します。この制御ワード(数値がすべてゼロの4バイト)を確認すると、ハッシュジェネレータは、MPLSイーサ擬似回線パケットの制御ワードの末尾にあるイーサネットフレームの開始とみなします。
ロードバランシング用のMPLSカプセル化ペイロードの設定を始める前に、ルーティングプロトコルとシグナリングプロトコルを設定します。
ロードバランシング用にMPLSカプセル化ペイロードを設定するには:
zero-control-wordオプションを設定して、MPLSイーサ擬似回線ペイロード内のイーサネットフレームの開始を示します。
DPC Iチップベースのカードの場合、
[edit forwarding-options hash-key family mpls ether-pseudowire]階層レベルでzero-control-wordオプションを設定します。[edit forwarding-options hash-key family mpls ether-pseudowire] user@host# set zero-control-word
MPCカードの場合、
[edit forwarding-options enhanced-hash-key family mpls ether-pseudowire]階層レベルでzero-control-wordオプションを設定します。[edit forwarding-options enhanced-hash-key family mpls ether-pseudowire] user@host# set zero-control-word
ポリシーベースのマルチパスルートの概要
セグメントルーティングネットワークは、コアに複数のトランスポートプロトコルを含めることができます。セグメント ルーティング SR-TE LDP または RSVP ルートと SR-TE IP ルートを組み合わせて、ルーティング情報ベース(ルーティングテーブルとも呼ばれる)にマルチパスルートをインストールできます。その後、ポリシー設定を通してマルチパスルートを使用して、選択的サービストラフィックを誘導できます。
- ポリシーベースマルチパスルートの理解
- ポリシーベースのマルチパスルートのメリット
- ルート解決のためのポリシーベースのマルチパスルート
- ポリシーベースのマルチパスルートを使用したルート解決の例
- サービスクラス(CoS)転送ポリシーの拡張
- ポリシー一致プロトコルの拡張
- ポリシーベースのマルチパスルートの設定がネットワークパフォーマンスに与える影響
ポリシーベースマルチパスルートの理解
ネットワークには、サービストラフィックを解決するために使用される、IGP、ラベル付きIGP、RSVP、LDP、セグメントルーティングトラフィックエンジニアリング(SR-TE)プロトコルなど、さまざまなトランスポートプロトコルがあります。ただし、トランスポートプロトコルの組み合わせを使用してサービストラフィックを解決することはできませんでした。ポリシーベースのマルチパス機能を導入することで、セグメントルーティングトラフィックエンジニアリング(SR-TE)LDPまたはRSVPルートとSR-TE IPルートを組み合わせて、ルーティング情報ベースにインストールされるマルチパスルートを作成できます。ポリシー設定によりマルチパスルート上のBGPサービスルートを解決し、プレフィックスごとにトラフィックを異なる方法で誘導することができます。
マルチパス ルートは、ロードバランシングに使用されるルート エントリーのネクスト ホップを組み合わせています。マルチパス ルート エントリーでサポートされるすべてのルートは、同じルーティング情報ベースにある必要があります。サポートルートが異なるルーティング情報ベースの下にある場合、 rib-group 設定ステートメントを使用して、特定のルーティング情報ベースにルートエントリーを追加できます。
ポリシーを使用してマルチパスルートを設定し、ネクストホップを結合するルートのリストを選択できます。[edit routing-options rib routing-table-name]階層レベルでpolicyステートメントとともにpolicy-multipathステートメントを含めると、ポリシーベースのマルチパスルートが作成されます。
ポリシーベースのマルチパス機能は、IPプロトコルとIPv6プロトコルの両方でサポートされており、 [edit routing-instances] 階層レベルで設定できます。
次に例を示します。
[edit routing-options] user@host# set rib inet.3 policy-multipath policy example-policy [edit policy-options] user@host# set policy-statement example-policy from example-conditions user@host# set policy-options policy-statement example-policy then accept
設定されたポリシーは、特定のプレフィックスの各ルートエントリに適用されます。マルチパス ルートは、複数のルート(アクティブ ルートを含む)がポリシーを通過した場合にのみ作成されます。ポリシーで設定されたアクションコマンド(applyなど)は、アクティブルートを使用して評価されます。非アクティブなルートの場合、ポリシーが適用されて、ルートがマルチパス ルートに参加できるかどうかを確認します。マルチパスルートは、アクティブなルートのすべての属性を継承します。これらの属性は、マルチパスポリシー設定を使用して変更できます。
policy-multipathルートの場合、Junos OSとJunos OS Evolvedは、アクティブルートの優先度を使用するのではなく、適格ルートの中で最も優先度の低い(数値が最も高い)ルートの優先値を割り当てます。
policy-multipathルートに対してポリシーを通じて適用されるユーザー設定の優先度設定は無視され、常に適格なルートエントリーから最も高い優先度を適用します。
Junos OSとJunos OS Evolvedは、 policy-multipathで設定されたBGPルートのメトリック2値を正しく報告します。ルートのアクティブなプレフィックスがSR-TEで解決中の場合、システムはメトリック2の値をルートメトリックに正確に反映します。この変更により、ルーティングの決定が正確なメトリックに基づいて行われるようになり、全体的なネットワークのパフォーマンスと信頼性が向上します。
ポリシーベースのマルチパスルートのメリット
-
コアネットワークプロトコルを柔軟に組み合わせて、選択されたトラフィックを誘導します。
-
マルチパスルートを使用した加重等コストマルチパスでネットワークパフォーマンスを最適化します。
ルート解決のためのポリシーベースのマルチパスルート
セグメント ルーティングのトラフィック制御(SR-TE)LDP または RSVP ルートと SR-TE IP ルートを組み合わせて、ルーティング情報ベースにマルチパス ルートをインストールできます。ポリシーベースのマルチパスルートは、ルーティング情報ベース内のアクティブなエントリーではありません。ポリシーの設定によりマルチパスルートが生成された場合、アクティブルートではなく、プロトコルネクストホップの解決に使用されます。マルチパスルートのネクストホップは、各構成ルートのネクストホップのゲートウェイをマージして作成されます。
ルート解決のためにポリシーベースのマルチパスルートを設定する際には、以下の点に注意してください。
-
マルチパスルートのメンバールートが、ルーターネクストホップ以外のネクストホップ、またはルーターネクストホップにネクストホップを転送する間接ネクストホップを指している場合、そのようなネクストホップは無視されます。
-
構成ルートが間接ネクストホップを指している場合、転送ネクストホップからのゲートウェイはマージされ、間接ネクストホップは無視されます。
-
ゲートウェイの合計数がデバイスでサポートされている
maximum-ecmpを超える場合、maximum-ecmpゲートウェイのみが保持され、他のすべてのゲートウェイは無視されます。 -
重量の低いゲートウェイが優先されます。メンバールートの1つに間接ネクストホップのユニリストがあり、各ネクストホップが転送ネクストホップを指している場合、間接ネクストホップと転送ネクストホップの両方で重み値が存在する可能性があります。このような場合、ゲートウェイの重み値は更新され、両方のレベルでの重みの複合効果が反映されます。
ポリシーベースのマルチパスルートを使用したルート解決の例
例として、以下の出力に示すように、宛先 10.1.1.1/32 に対してセグメント ルーティング トラフィックエンジニアリング LSP、ラベル IS-IS ルート、LDP LSP があるとします。
10.1.1.1/32 *[SPRING-TE/8] 00:00:58, metric 1, metric2 30
> to 10.13.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
[L-ISIS/14] 1w0d 00:15:57, metric 10
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
[LDP/19] 1w0d 00:09:27, metric 1
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
ここで、セグメントルーティングLSPは10.1.1.1宛先へのアクティブなルートエントリーであり、デフォルトでは、このルートのみが10.1.1.1を介して解決するサービスの解決に使用されます。
サービスルートの解決に複数のプロトコルを使用する必要がある場合、プロトコルを組み合わせるように ポリシーマルチパス を設定することで、これを実現できます。例えば、サービス解決にセグメントルーティングとLDPパスが必要な場合、プレフィックス10.1.1.1 policy-multipath セグメントルーティングとLDPルートを組み合わせて設定する必要があります。
次に例を示します。
[edit policy-options] user@host# set rib inet.3 policy-multipath policy example-policy user@host# set policy-statement abc term 1 from protocol spring-te user@host# set policy-statement abc term 1 from protocol ldp user@host# set policy-statement abc term 1 from route-filter 10.1.1.1/32 exact user@host# set policy-statement abc term 1 then accept
この設定では、セグメントルーティングとLDPプロトコルの構成ルートエントリを使用する、プレフィックス10.1.1.1/32用のポリシーベースのマルチパスルートを作成します。
以下のように、 show route コマンド出力を使用してマルチパスルートを表示することができます。
10.1.1.1/32 *[SPRING-TE/8] 00:10:28, metric 1, metric2 30
> to 10.13.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
[L-ISIS/14] 1w0d 00:25:27, metric 10
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
[LDP/19] 1w0d 00:18:57, metric 1
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
[Multipath/8] 00:03:13, metric 1, metric2 30
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
コマンド出力から、マルチパスルートがセグメントルーティングのネクストホップとLDPパスを組み合わせていることがわかります。この マルチパスルート アクティブではなく、デフォルトでは、ルート優先度とメトリックはアクティブルートと同じです。
ポリシーベースのマルチパスルートには、以下の組み合わせを使用できます。 ただし、アクティブルートはマルチパスの一部ではないため、LDP/L-IS-ISのマルチパスを作成することはできません。
-
セグメントルーティングトラフィックエンジニアリングLSPとLDP LSP。
-
セグメントルーティングトラフィックエンジニアリングLSPとラベル付けIS-ISパス。
-
トラフィックエンジニアリングされたLSP、LDP LSP、ラベルIS-ISパスをセグメントルーティングします。
ただし、アクティブなルートはマルチパス ルートの一部ではないため、LDP のマルチパス ルートを作成し、IS-IS にラベルを付けることはできません。
同じ設定で、プロトコルネクストホップが10.1.1.1であるスタティックルート1.2.3.4/32があると仮定すると、このルートはセグメントルーティングトラフィックエンジニアリングLSPとLDP LSPの両方のマルチパスルートを使用して解決されます。
次に例を示します。
10.1.3.4/32 *[Static/5] 00:00:12, metric2 1
to 10.12.1.1 via ge-0/0/0.1
> to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
サービスクラス(CoS)転送ポリシーの拡張
サービスクラスベースの転送では、 forwarding-policy next-hop-map 設定ステートメントを使用する必要があります。
Junos OSリリース19.1R1以前は、サービスクラスベースの転送でサポートされている一致条件は次のとおりです。
-
next-hop—発信インターフェイスまたはネクストホップアドレスに基づいてネクストホップを一致させます。
-
lsp-next-hop—LSP名の正規表現を使用して、名前付きLSPに一致させます。
-
non-lsp-next-hop—LSP名のないすべてのLSPを照合します。
ポリシーベースのマルチパスルート機能を使用すると、特定のプレフィックスに対してラベルなしですべてのネクストホップを一致させることもできます。これを行うには、[edit class-of-service forwarding-policy next-hop-map map-name forwarding-class forwarding-class-name階層レベルでnon-labelled-next-hopオプションを有効にする必要があります。
次に例を示します。
[edit]
class-of-service {
forwarding-policy {
next-hop-map abc {
forwarding-class best-effort {
non-labelled-next-hop;
}
}
}
}
ポリシー一致プロトコルの拡張
Junos OS リリース 19.1R1 以前は、ポリシーを使用して[edit policy-options policy-statement statement-name]階層レベルで from protocol ステートメントを使用してプロトコルを一致させると、すべてのプロトコル ルート(ラベル付きおよびラベルなし)が一致していました。ポリシーベースのマルチパスルート機能により、ラベル付きのプロトコルルートを具体的にマッチングすることができます。
ラベル付きプロトコルを一致させるためのオプション)は次のとおりです。
-
l-isis- ラベル付き IS-IS ルートに一致します。
isisオプションは、ラベルIS-ISルートを除くIS-ISルートに一致します。 -
l-ospf—ラベル付きOSPFルートに一致します。
ospfオプションは、OSPFv2、OSPFv3、ラベルOSPFを含むすべてのOSPFルートに一致します。
次に例を示します。
[edit]
policy-options {
policy-statement abc {
from protocol [ l-ospf l-isis ];
}
}
ポリシーベースのマルチパスルートの設定がネットワークパフォーマンスに与える影響
ポリシーベースのマルチパスルートを設定する場合、ルーティング情報ベースでルートが変更されると、ポリシーが評価され、マルチパスルートを作成する必要があるかどうかが確認されます。この機能では、メンバー ルートが同じルーティング情報ベースにある必要があるため、 rib-group ステートメントを使用して、異なるルーティング情報ベースからのルートをマージします。アプリケーションレベルで rib-group ステートメントを設定すると、システム内のルート数が増加します。
ルーティング情報ベースに多数のルートがある場合、ルートを絶えず変更することで、マルチパスポリシーの再評価につながります。これは、ネットワークのパフォーマンスに影響を与える可能性があります。ポリシーベースのマルチパスルート機能は、必要な場合にのみ設定することをお勧めします。
MPLSトラフィックのIPベースのフィルタリングと選択的ポートミラーリングの理解
MPLSパケットでは、IPヘッダーはMPLSヘッダーの直後に来ます。IPベースのフィルタリング機能は、内部ペイロードの最大8枚のMPLSラベルを検査できるディープインスペクションメカニズムを提供し、IPパラメータに基づいてMPLSトラフィックのフィルタリングを可能にします。フィルタリングされたMPLSトラフィックは、監視デバイスにポートミラーリングして、コアMPLSネットワークでネットワークベースのサービスを提供することもできます。
MPLSトラフィックのIPベースフィルタリング
Junos OS リリース 18.4R1 以前は、IP パラメーターに基づくフィルタリングは MPLS ファミリー フィルターでサポートされていませんでした。IPベースのフィルタリング機能を導入することで、送信元アドレスと宛先アドレス、レイヤー4プロトコルタイプ、送信元と宛先ポートなどのIPパラメーターに基づいて、MPLSタグ付きIPv4およびIPv6パケットにインバウンドおよびアウトバウンドフィルターを適用できます。
IPベースのフィルタリング機能により、インターフェイスのイングレスでMPLSパケットをフィルタリングすることができ、フィルタリングはMPLSパケットの内部ペイロードの一致条件を使用して行われます。選択的な MPLS トラフィックは、論理トンネルを使用してリモート監視デバイスにポートミラーリングできます。
IPベースのフィルタリングをサポートするために、適切なフィルタが適用される前に、MPLSパケットをディープインスペクションして、レイヤー3およびレイヤー4ヘッダーを持つ内部ペイロードを解析できる一致条件が追加されています。
IPベースのフィルタリング機能は、MPLSタグ付きIPv4およびIPv6パケットでのみサポートされています。つまり、MPLSフィルターは、IPペイロードがMPLSラベルの直後に来る場合にのみ、IPパラメーターに一致します。
MPLSペイロードに疑似配線、inet および inet6 以外のプロトコル、またはレイヤー 2 VPN や VPLS などの他のカプセル化が含まれるその他のシナリオでは、IP ベースのフィルタリング機能はサポートされません。
MPLSトラフィックのIPベースフィルタリングに、以下の一致条件が追加されています。
IPv4送信元アドレス
IPv4宛先アドレス
IPv6送信元アドレス
IPv6宛先アドレス
プロトコル
送信元ポート
宛先ポート
送信元IPv4プレフィックスリスト
宛先IPv4プレフィックスリスト
送信元IPv6プレフィックスリスト
宛先IPv6プレフィックスリスト
MPLSトラフィックのIPベースのフィルタリングでは、以下の一致組み合わせがサポートされています。
送信元アドレスと宛先アドレスの一致条件とIPv4およびIPv6プレフィックスリスト。
送信元と宛先のポートアドレスとプロトコルタイプは、条件をIPv4およびIPv6プレフィックスリストと一致させます。
MPLSトラフィックの選択的ポートミラーリング
ポートミラーリングとは、パケットの通常の処理と転送に加えて、設定された宛先にパケットをミラーリングする機能です。ポートミラーリングは、ファイアウォールフィルターのアクションとして適用され、あらゆるインターフェイスのingressまたはegressに適用されます。同様に、選択ポートミラーリング機能は、IPパラメーターに基づいてフィルタリングされたMPLSトラフィックを、論理トンネルを使用してミラーリングされた宛先にミラーリングする機能を提供します。
選択的なポートミラーリングを有効にするために、既存のcounter、accept、discardアクションに加えて、[edit firewall family mpls filter filter-nameterm term-name then]階層レベルで追加のアクションが設定されます。
port-mirrorport-mirror-instance
Port Mirroring
port-mirrorアクションにより、デバイス上でグローバルにポートミラーリングが有効になり、これはすべてのパケット転送エンジン(PFE)と関連するインターフェイスに適用されます。
MPLSファミリーフィルターでは、グローバルポートミラーリングに対して port-mirror アクションが有効になっています。
Port Mirroring Instance
port-mirror-instanceアクションにより、ポートミラーリングにシステム全体の単一の設定を使用する代わりに、入力サンプリングとポートミラーリング出力先の異なるプロパティで各インスタンスをカスタマイズできます。
[edit forwarding-options port-mirror]階層レベルでinstance port-mirror-instance-nameステートメントを含めることで、フレキシブルPICコンセントレータ(FPC)ごとに設定できるポートミラーリングインスタンスは2つだけです。その後、デバイスのハードウェアに応じて、個々のポートミラーリングインスタンスをFPC、PIC、または(転送エンジンボード(FEB))に関連付けることができます。
MPLSファミリーフィルターの場合、 port-mirror-instance アクションはポートミラーリングインスタンスに対してのみ有効になります。
port-mirrorとport-mirror-instanceの両方のアクションで、選択的ポートミラーリング機能が機能するためには、出力インターフェイスがファミリー MPLS(レイヤー3)ではなくレイヤー2ファミリーで有効にされている必要があります。
設定例
IPベースのフィルタリング設定
[edit firewall family mpls filter mpls-filter]
term ipv4-term {
from {
ip-version {
ipv4 {
source-address {
10.10.10.10/24;
}
destination-address {
20.20.20.20/24;
}
protocol tcp {
source-port 100;
destination-port 200;
}
soure-prefix-list ipv4-source-users;
destination-prefix-list ipv4-destination-users;
}
}
exp 1;
}
then port-mirror;
then accept;
then count;
}
term ipv6-term {
from {
ip-version {
ipv6 {
source-address {
2000::1/128;
}
destination-address {
3000::1/128;
}
protocol tcp {
source-port 100;
destination-port 200;
}
source-prefix-list ipv6-source-users;
destination-prefix-list ipv6-destination-users;
}
}
exp 1;
}
then port-mirror-instance port-mirror-instance1;
then accept;
then count;
}
[edit policy-options]
prefix-list ipv4-source-users {
172.16.1.16/28;
172.16.2.16/28;
}
prefix-list ipv6-source-users {
2001::1/128;
3001::1/128;
}
[edit interfaces]
xe-0/0/1 {
unit 0 {
family inet {
address 100.100.100.1/30;
}
family mpls {
filter {
input mpls-filter;
}
}
}
}
選択的ポートミラーリング設定
[edit forwarding-options]
port-mirroring {
input {
rate 2;
run-length 4;
maximum-packet-length 500;
}
family any {
output {
interface xe-2/0/2.0;
}
}
}
[edit forwarding-options]
port-mirroring {
instance {
port-mirror-instance1 {
input {
rate 3;
run-length 5;
maximum-packet-length 500;
}
family any {
output {
interface xe-2/0/2.0;
}
}
}
}
}
出力インターフェイス xe-2/0/2.0 は、ファミリー MPLSではなく、レイヤー2ファミリー用に設定されています。
port-mirrorアクションとport-mirror-instanceアクションの両方で、選択的ポートミラーリング機能が機能するためには、出力インターフェイスがファミリー MPLS(レイヤー3)ではなくレイヤー2ファミリーで有効にされている必要があります。
ミラーリングされた宛先設定
[edit interfaces]
xe-2/0/2 {
vlan-tagging;
encapsulation extended-vlan-bridge;
unit 0 {
vlan-id 600;
}
}
[edit bridge-domains]
bd {
domain-type bridge;
interface xe-2/0/2.0;
}
変更履歴テーブル
サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がお使いのプラットフォームでサポートされているかどうかを確認します。