ロード バランシング MPLS トラフィック
MPLSラベルに基づくロードバランシングの設定
ロード バランシングは、サポートされるプラットフォーム上の MPLS フローのパケット単位で発生します。パケットをネクストホップに一様に配信するには、エントロピー(ランダム分散)が不可欠です。デフォルトでは、トラフィックの分散に負荷分散を使用する場合、Junos OS はハッシュ アルゴリズムを使用してネクストホップ アドレスを選択し、転送テーブルにインストールします。宛先のネクストホップセットが変更されるたびに、ハッシュアルゴリズムによってネクストホップアドレスが再選択されます。ハッシュアルゴリズムを使用して、一連の等コストラベルスイッチパス(LSP)全体でトラフィックの負荷分散を行う方法を設定できます。
VPLS および VPWS トラフィックのエントロピーを確保するために、Junos OS は IP ヘッダーからのデータと最大 3 つの MPLS ラベル(いわゆるトップ ラベル)に基づいてハッシュを作成できます。
場合によっては、ラベルを使用するネットワーク機能の数が増えるにつれて(MPLS Fast Reroute、RFC 3107、RSVP、VPN など)、上位 3 つのラベルのデータが静的になり、エントロピーのための十分なソースにならない可能性があります。その結果、ロード バランシングが偏ったり、アウトオブオーダーパケット配信の発生率が上昇したりする可能性があります。このような場合、ラベル スタックの一番下のラベルを使用できます(条件については、表 1、以下を参照してください)。トップラベルとボトムラベルを同時に使用することはできません。
MPCカードは、通常のハッシュキー設定をサポートしていません。MPCベースのハッシュキー設定を有効にするには、設定が必要です enhanced-hash-key 。
ロードバランシングは、以下の条件が適用された場合にトラフィックを均等に分散するために使用されます。
同じ宛先への異なるインターフェイス上には、複数の等コストネクストホップがあります。
集約されたインターフェイス上に単一のネクストホップがあります。
LSPは、イコールコストネクストホップの1つをランダムに選択し、それを排他的に使用することで、その配置をロードバランスする傾向があります。ランダムな選択は、各トランジットルーターで独立して行われ、IGP(Interior Gateway Protocol)メトリックのみを比較します。帯域幅や輻輳レベルは考慮されません。
この機能は、集約されたイーサネットおよび集約された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ラベルがハッシュキーに含まれています。 |
|
MXシリーズとDPC(Iチップ) M10i、M7i、M120 ではサポートされていません。 |
トップラベルが必要なエントロピーレベルに十分な変数を提供していない場合など、ハッシュキーを計算するために最下部のラベルを使用します。 |
|
MXシリーズとDPC(Iチップ) M10i、M7i、M120 ではサポートされていません。 |
トップラベルが必要なエントロピーレベルに十分な変数を提供していない場合など、ハッシュキーの計算には下から2番目のラベルを使用します。 |
|
MXシリーズとDPC(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ルーターでは、 階層レベルで ステートメントと
ipステートメントの オプションpayloadを[edit forwarding-options hash-key family mpls]設定label-1します。[edit forwarding-options hash-key family mpls] label-1; payload { ip; }PTXシリーズパケットトランスポートルーターでは、
all-labelsおよびip payloadオプションがデフォルトで設定されているため、設定は不要です。
(M320およびTシリーズルーターのみ)IPアドレスと、ハッシュキーに1番目と2番目のラベルの両方を含める場合は、 階層レベルで ステートメントの
label-1および オプションとipオプションを[edit forwarding-options hash-key family mpls]payload設定label-2します。[edit forwarding-options hash-key family mpls] label-1; label-2; payload { ip; }注:このステートメントの組み合わせは、M320とT Seriesルーターにのみ含めることができます。M シリーズ マルチサービス エッジ ルーターに含める場合、最初の MPLS ラベルと IP ペイロードのみがハッシュ キーで使用されます。
T シリーズ ルーターでは、 階層レベルで 、 、
label-2オプションlabel-3をlabel-1含めることで、適切なロード バランシングを[edit forwarding-options hash-key family mpls]確保します。[edit forwarding-options hash-key family mpls] label-1; label-2; label-3;
(M Series、MXシリーズ、T Seriesルーターのみ)レイヤー 2 VPN では、ルーターでパケットの並べ替えの問題が発生する可能性があります。トラフィックのバーストによって顧客のトラフィック帯域幅が制限を超えると、トラフィックが中流で影響を受ける可能性があります。その結果、パケットが並べ替えられる可能性があります。EXP ビットをハッシュ キーから除外することで、この並べ替えの問題を回避できます。ハッシュ計算から最初のラベルの EXP ビットを除外するには、 階層レベルに
no-label-1-expステートメントを[edit forwarding-options hash-key family mpls]含めます。[edit forwarding-options hash-key family mpls] label-1; no-label-1-exp; payload { ip; }
例：負荷分散された MPLS ネットワーク
複数のRSVP LSPを同じエグレスルーターに設定すると、メトリックが最も低いLSPが選択され、すべてのトラフィックを伝送します。すべてのLSPのメトリックが同じ場合、LSPの1つがランダムに選択され、すべてのトラフィックが転送されます。すべてのLSPにトラフィックを均等に分散するには、設定されたロードバランシングのタイプに応じて、イングレスルーターまたはトランジットルーターでロードバランシングを設定できます。
図 1 は、同じエグレス ルーター(R0)に 4 つの LSP が設定された MPLS ネットワークを示しています。ロード バランシングはイングレス ルーターで設定されます R1。この例のネットワークでは、OSPFエリア 0.0.0.0を持つ内部ゲートウェイプロトコル(IGP)として、Open Shortest Path First(OSPF)を使用しています。IGP は、Junos OS のデフォルトである CSPF(制限付き最短パス ファースト)LSP に必要です。さらに、このネットワークの例では、ポリシーを使用してBGPトラフィックを作成しています。
に 図 1 示すネットワークは、以下のコンポーネントで構成されています。
AS 65432を使用したフルメッシュの内部BGP(IBGP)トポロジー
すべてのルーターでMPLSとRSVPが有効
ルーター R1 上の send-statics ポリシーと R0 、ネットワークに新しいルートをアドバタイズできるようにするポリシー
と R0の間R1の 4 つの一方向 LSP、および の間R0R1の 1 つの逆方向 LSP は、双方向トラフィックを可能にします。
イングレスルーターに設定されたロードバランシング 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
以下の設定出力はイングレスルーター 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
以下の設定出力はエグレスルーター 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 は、例で示したネットワーク の例で、6 台すべてのルーターの基本インターフェイス、ルーティング オプション、プロトコル、ポリシー オプションの設定を示しています。負荷分散された MPLS ネットワーク。
ネットワーク内のすべてのルーターで、MPLS、RSVP、BGP が有効になっています。OSPFはIGPとして設定されており、関連するインターフェイスには基本的なIP情報とMPLSサポートがあります。
さらに、すべてのルーターは、重複する RID 問題を回避するために、 [edit routing-options] 階層レベルでルーター ID(RID)を手動で設定しています。ステートメントは passive 、プロトコルがループバック()インターフェイス上で実行されないようにし、ループバック(lo0)インターフェイスがlo0ネットワーク全体で正しくアドバタイズされるようにするために、OSPF設定に含まれています。
サンプル出力 1、3、4、および 5 の R6、 R2、 R4、および R9 は、トランジット ラベルスイッチ ルーターの基本設定を示しています。基本設定には、MPLSで有効なすべてのインターフェイス、手動で設定された RID、および関連プロトコル(RSVP、MPLS、BGP、OSPF)が含まれます。
イングレス ルーター R1 からのサンプル出力 2 は、基本構成と 4 つの LSP(lsp1 を に設定) lsp4) を R0示しています。4 つの LSP は、 および の および および のルーズ ホップをR4lsp1R2lsp4lsp2指定する異なるプライマリ パスで設定されています。lsp3
トラフィックを作成するには、 R1 静的ルート(100.100.1.0/24) 階層レベルで設定)があります [edit routing-options static route] 。プレフィックスは、 階層レベルの send-statics ポリシーに [edit policy-options send statics] 含まれるため、ルートを BGP ルートにすることができます。
さらに、イングレスルーター R1では、 オプションを使用して per-packet ロードバランシングが設定され、 階層レベルで [edit routing-options forwarding-table] ポリシーがエクスポートされます。
エグレスルーターR0からのサンプル出力6は、双方向トラフィックの作成にR6使用される1つのLSP(r0-r6)を示しています。OSPFは、LSPをIGPにアドバタイズする前に、双方向LSP到達可能性を必要とします。LSPはIGPにアドバタイズされますが、LSP上ではhelloメッセージやルーティング更新は行われず、LSPを介してユーザートラフィックのみが送信されます。ルーターは、IGPデータベースのローカルコピーを使用して、双方向到達可能性を検証します。
さらに、 R0 静的ルート(100.100.10.0/24) 階層レベルで設定)があります [edit routing-options static route] 。プレフィックスは、 階層レベルの send-statics ポリシーに [edit policy-options send statics] 含まれるため、ルートを BGP ルートにすることができます。
ACXシリーズルーターのMPLSラベルに基づくロードバランシングの設定
表 2 は、可能なすべての MPLS LSP ロード バランシング オプションに関する詳細情報を提供します。
ACX シリーズ ルーターは、MPLS のパケット単位でロードバランシングが可能です。ロードバランシングは、IPヘッダーと最大3つのMPLSラベルの両方の情報に対して実行することができ、ネクストホップへのMPLSトラフィックのより均一な分散を提供します。この機能は、デフォルトでサポートされているプラットフォームで有効になっており、設定は必要ありません。
負荷分散は、集約されたインターフェイスまたは LAG バンドル上に単一のネクスト ホップがある場合にトラフィックを均等に分散するために使用されます。MPLSラベルを使用したロードバランシングは、LAGインターフェイスでのみサポートされ、ECMP(等価コストマルチパス)リンクではサポートされません。
デフォルトでは、トラフィックの分散に負荷分散を使用する場合、Junos OS はハッシュ アルゴリズムを使用してネクストホップ アドレスを選択し、転送テーブルにインストールします。宛先のネクストホップセットが何らかの方法で変更されるたびに、ハッシュアルゴリズムによってネクストホップアドレスが再選択されます。ハッシュアルゴリズムを使用して、集合型イーサネット(ae)インターフェイス内のインターフェイス全体でトラフィックの負荷分散を行う方法を設定できます。
LSPは、インターフェイスバンドル内のインターフェイスの1つをランダムに選択し、それを排他的に使用することで、その配置を ae- ロードバランスする傾向があります。ランダムな選択は、各トランジットルーターで独立して行われ、IGP(Interior Gateway Protocol)メトリックのみを比較します。帯域幅や輻輳レベルは考慮されません。
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)を設定する場合、および port-data を設定layer-3-onlyすることが必須です。
ロード バランシング機能が適切なハッシュキー設定を行わないと、予期しない動作が発生する可能性があります。
レイヤー 2 VPN/pseudowire トンネル終端では、ハッシュに最大 2 つのラベルを使用し、ペイロード MAC 宛先と送信元アドレスをオプションで選択できます。これらのコントロールは、上で示したハッシュキー設定の下で、ファミリーmplsの ether-pseudowireノブをサポートするために使用できます。ただし、ACX2000とACX4000はTDM擬似回線もサポートしているため、TDM擬似回線を使用しない場合にのみ、Ether-pseudowireノブを使用する必要があります。
レイヤー 3 VPN トンネルの終端では、最大 2 つのラベルを持ち、ペイロード IP 送信元と宛先アドレスに使用し、レイヤー 4 送信元および宛先ポートをオプションで選択できます。これらのコントロールは、上記のハッシュキー設定の下で、ファミリーmplsのIPポートデータノブをサポートするために使用できます。ただし、レイヤー 4 ポート MSB と LSB を個別に選択できないため、宛先 lsb または宛先 msb ノブのいずれか、または source-lsb または source-msb ノブの 1 つで、それぞれレイヤー 4 の宛先ポートまたはソース ポートを選択します。
LSR の場合、ハッシュには最大 3 つのラベルが使用されます。最初の 3 つのラベルを解析するときに BOS が見られる場合、BCM はペイロードの最初の 3 つの値を調べます。つまり、4 であれば、ペイロードは IPv4 として扱われ、最初の 3 文字が 6 の場合、ペイロードは IPv6 として扱われ、そのような場合、ペイロードの送信元と宛先の IP アドレスは投機的にハッシュに使用できます。これらのコントロールは、ハッシュキー設定の下でファミリーmplsのipポートデータノブをサポートするために使用できます。ただし、LSR の場合はレイヤー 4 ポートをハッシュに使用できず、レイヤー 3 のみのノブのみが適用されます。BCM は、3 つの MPLS ラベルを超えるフィールドのハッシュのサポートを要求しません。LSRの場合、そのセッションに固有のすべてのトラフィックが同じMPLSラベルのセットを伝送するため、単一の疑似回線セッションのロードバランシングは実行されません。
LSR AE インターフェイスのロード バランシングは、MPLS セッションの数が増えた場合(最小 10 セッション)達成できます。これは、CCC/VPLS/L3VPNに適用されます。レイヤー 3 VPN の場合、レイヤー 3 アドレスもハッシュ入力関数の(ラベルとともに)説明されるので、トラフィックがメンバー リンク全体に均等に分散されない場合があります。
LER のシナリオでは、ACX5048 と ACX5096 の場合、「ファミリー mpls」階層のペイロード オプションを設定することで、レイヤー 3 とレイヤー 4 のフィールドに基づくハッシュを実行できます。LERのハッシュはラベルに基づくものではありません。レイヤー 3 サービスでは、ペイロードを「レイヤー 3-only」として言及し、レイヤー 4 サービスの場合は「ポートデータ」を指定する必要があります。また、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アドレスと最初のラベルをハッシュキーに含める場合は、 階層レベルで ステートメントと ステートメントの ip オプションをpayload[edit forwarding-options hash-key family mpls]設定label-1します。
[edit forwarding-options hash-key family mpls]
label-1;
payload {
ip;
}
IPアドレスと、ハッシュキーに1番目と2番目のラベルの両方を含める場合は、 階層レベルで ステートメントの label-1 および オプションと ip オプションを[edit forwarding-options hash-key family mpls]payload設定label-2します。
[edit forwarding-options hash-key family mpls]
label-1;
label-2;
payload {
ip;
}
階層レベルで 、 、 オプションをlabel-1含めることで、label-3適切なロードバランシングを[edit forwarding-options hash-key family mpls]確保label-2します。
[edit forwarding-options hash-key family mpls] label-1; label-2; label-3;
MPLSカプセル化ペイロードロードバランシングの概要
ルーターは、MPLS のパケット単位でロードバランシングが可能です。ロードバランシングは、IPヘッダーと最大3つのMPLSラベルの両方の情報に対して実行することができ、ネクストホップへのMPLSトラフィックのより一様な分散を提供します。
ロードバランシングは、以下の条件が適用された場合にトラフィックを均等に分散するために使用されます。
同じ宛先への異なるインターフェイス上には、複数の等コストネクストホップがあります。
集約されたインターフェイス上に単一のネクストホップがあります。
デフォルトでは、トラフィックの分散に負荷分散を使用する場合、ハッシュ アルゴリズムを使用してネクストホップ アドレスを選択し、転送テーブルにインストールします。宛先のネクストホップセットが何らかの方法で変更されるたびに、ハッシュアルゴリズムによってネクストホップアドレスが再選択されます。
MPLSやイーサネット擬似配線を介したイーサネットなどの複数のトランスポートレイヤーネットワークの場合、ハッシュアルゴリズムはペイロードの外部ヘッダーを超えて内側ヘッダーを調べて均等な分布を生成する必要があります。内部カプセル化を決定するために、PFE は固定ペイロード オペットで特定のコードまたは数字の存在に依存します。例えば、ペイロードタイプ0X800の存在や、IPv4パケットのプロトコル番号4の存在などです。Junos OS では、 オプションを設定 zero-control-word して、MPLS ether-pseudowire ペイロード内のイーサネット フレームの開始を示すことができます。この制御ワード(すべてのゼロの数値を持つ 4 バイト)を見ると、ハッシュ ジェネレータは MPLS ether-pseudowire パケット内の制御ワードの最後にあるイーサネット フレームの開始を想定します。
DPC Iチップベースのカードでは、 階層レベルで オプションをzero-control-word[edit forwarding-options hash-key family mpls ether-pseudowire]設定し、MPCカードの場合は 階層レベルで オプションを[edit forwarding-options enhanced-hash-key family mpls ether-pseudowire]設定zero-control-wordします。
ロード バランシングのための MPLS カプセル化ペイロードの設定
デフォルトでは、トラフィックの分散に負荷分散を使用する場合、ハッシュ アルゴリズムを使用してネクストホップ アドレスを選択し、転送テーブルにインストールします。宛先のネクストホップセットが何らかの方法で変更されるたびに、ハッシュアルゴリズムによってネクストホップアドレスが再選択されます。zero-control-word MPLS ether-pseudowire ペイロード内のイーサネット フレームの開始を示す オプションを設定します。この制御ワード(すべてのゼロの数値を持つ 4 バイト)を見ると、ハッシュ ジェネレータは MPLS ether-pseudowire パケット内の制御ワードの最後にあるイーサネット フレームの開始を想定します。
ロード バランシングのための MPLS カプセル化ペイロードの設定を開始する前に、ルーティングとシグナリング プロトコルを設定します。
ロードバランシングのためにMPLSカプセル化ペイロードを設定するには:
zero-control-word MPLS ether-pseudowire ペイロード内のイーサネット フレームの開始を示す オプションを設定します。 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 使用して、特定のルーティング情報ベースにルートエントリーを追加できます。
ポリシーを使用してマルチパスルートを設定し、ネクストホップを組み合わせるルートのリストを選択できます。階層レベルで policy-multipath ステートメントと一緒に ステートメントをpolicy[edit routing-options rib routing-table-name]含めると、ポリシーベースのマルチパスルートが作成されます。
ポリシーベースのマルチパス機能は、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など)はすべて、アクティブルートを使用して評価されます。非アクティブルートの場合、ポリシーは、ルートがマルチパスルートに参加するかどうかを確認するために適用されます。マルチパスルートは、アクティブなルートのすべての属性を継承します。これらの属性は、マルチパスポリシー設定を使用して変更できます。
ポリシーベースのマルチパス ルートのメリット
-
コアネットワークプロトコルを組み合わせて、選択的なトラフィックを誘導する柔軟性を提供します。
-
マルチパスルートを使用して、重み付きイコールコストマルチパスでネットワークパフォーマンスを最適化します。
ルート解決のためのポリシーベースのマルチパス ルート
セグメントルーティングトラフィックエンジニアリング(SR-TE)LDPまたはRSVPルートとSR-TE IPルートを組み合わせて、ルーティング情報ベースにマルチパスルートをインストールできます。ポリシーベースのマルチパス ルートは、ルーティング情報ベースのアクティブなエントリーではありません。ポリシーの設定によってマルチパスルートが生成される場合、アクティブルートではなくプロトコルのネクストホップの解決に使用されます。マルチパス ルートのネクスト ホップは、各構成要素ルートのネクスト ホップのゲートウェイをマージすることで作成されます。
ルート解決のためにポリシーベースのマルチパスルートを設定する場合は、以下を考慮してください。
-
マルチパスルートのメンバールートが、ルーターのネクストホップ以外のネクストホップ、またはルーターのネクストホップへの転送ネクストホップを持つ間接ネクストホップを指す場合、そのようなネクストホップは無視されます。
-
構成要素ルートが間接ネクストホップを指す場合、転送ネクストホップからのゲートウェイはマージされ、間接ネクストホップは無視されます。
-
ゲートウェイの総数がデバイスでサポートされている数を
maximum-ecmp超えた場合、ゲートウェイのみがmaximum-ecmp保持され、他のすべてのゲートウェイは無視されます。 -
重量が低いゲートウェイが優先されます。メンバールートの1つに間接ネクストホップのユニリストがあり、各ネクストホップが転送ネクストホップを指している場合、間接ネクストホップと転送ネクストホップの両方で重み付け値を設定できます。この場合、ゲートウェイの重み値は更新され、両方のレベルでの重みの効果が組み合わされます。
ポリシーベースのマルチパス ルートを使用したルート解決例
例として、以下の出力に表示されているように、宛先1 0.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は、1 0.1.1.1宛先へのアクティブなルートエントリーであり、デフォルトでは、このルートのみが1 0.1.1.1を超えるサービスを解決するために使用されます。
サービスルートの解決に複数のプロトコルを使用する必要がある場合は、プロトコルを組み合わせて ポリシーマルチパス を設定することでこれを実現できます。例えば、サービス解決にセグメントルーティングとLDPパスが必要な場合、プレフィックス1 0.1.1.1のセグメントルーティングとLDPルートを組み合わせて設定policy-multipathする必要があります。
例えば、
[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パスのネクストホップを組み合わせたコマンド出力を確認できます。マルチパスルートはアクティブではなく、デフォルトではルート優先度とメトリックはアクティブルートと同じです。
ポアルシーベースのマルチパス ルートには、以下の組み合わせを使用できます。しかし、active-routeはマルチパスの一部ではないので、LDP/L-ISISのマルチパスを作成することはできません。
-
セグメントルーティングトラフィックエンジニアリングLSPとLDP LSP。
-
セグメントルーティングトラフィックエンジニアリングLSP、およびラベルIS-ISパス。
-
セグメントルーティングトラフィックエンジニアリングLSP、LDP LSP、およびラベルIS-ISパス。
ただし、アクティブなルートはマルチパスルートの一部であるため、LDPとラベルIS-ISのマルチパスルートを作成することはできません。
同じ設定では、プロトコルのネクスト ホップ 1 0.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 に一致します。
ポリシーベースのマルチパス ルート機能を使用すると、特定のプレフィックスに対するラベルのないすべてのネクスト ホップをマッチングすることもできます。これを行うには、 階層レベルで オプションをnon-labelled-next-hop[edit class-of-service forwarding-policy next-hop-map map-name forwarding-class forwarding-class-name有効にする必要があります。
例えば、
[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 Release 18.4R1以前は、MPLSファミリーフィルターでは、IPパラメーターに基づくフィルタリングはサポートされていませんでした。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 トラフィックの選択的ポート ミラーリング
ポートミラーリングは、パケットの通常の処理と転送に加えて、設定された宛先にパケットをミラーリングする機能です。ポートミラーリングは、ファイアウォールフィルターのアクションとして適用され、どのインターフェイスのイングレスまたはエグレスでも適用されます。同様に、選択的ポートミラーリング機能は、IPパラメーターに基づいてフィルタリングされたMPLSトラフィックを、論理トンネルを使用してミラーリングされた宛先にミラーリングする機能を提供します。
選択的なポートミラーリングを有効にするには、既存counteracceptの [edit firewall family mpls filter filter-nameterm term-name then] 、 、および アクションに加えて、 階層レベルで追加のアクションをdiscard設定します。
port-mirrorport-mirror-instance
Port Mirroring
このアクションにより port-mirror 、デバイス上でグローバルにポートミラーリングが有効になります。これは、すべてのパケット転送エンジン(PFEs)と関連するインターフェイスに適用されます。
MPLSファミリーフィルターでは、グローバルポートミラーリングに port-mirror 対してアクションが有効になります。
Port Mirroring Instance
この port-mirror-instance アクションにより、ポートミラーリングに単一のシステム全体設定を使用する必要なく、入力サンプリングとポートミラーリング出力先に対して異なるプロパティで各インスタンスをカスタマイズできます。
階層レベルで [edit forwarding-options port-mirror] ステートメントを含instance port-mirror-instance-nameめることで、FPC(フレキシブルPICコンセントレータ)ごとに2つのポートミラーリングインスタンスのみを設定できます。デバイスのハードウェアに応じて、個々のポートミラーリングインスタンスをFPC、PIC、または(転送エンジンボード(FEB)に関連付けることができます。
MPLSファミリーフィルターでは port-mirror-instance 、ポートミラーリングインスタンスに対してのみアクションが有効になります。
および の両方 port-mirror の port-mirror-instance アクションにおいて、選択的ポートミラーリング機能を機能させるには、出力インターフェイスをレイヤー2ファミリーで有効にし、ファミリーMPLS(レイヤー3)で有効にする必要があります。
設定例
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 アクションにおいて、選択的ポートミラーリング機能を機能させるには、出力インターフェイスをレイヤー2ファミリーで有効にし、ファミリーMPLS(レイヤー3)で有効にする必要があります。
ミラーリングされた宛先設定
[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;
}