SR_Policy

もしよければ、一言コメントもお願いします!
2

SR-Policyのパス計算処理(SRLGとは?)

SR-Policyのパス計算にはConstraintsで制約をかけてパスの自動計算制御ができることを前回説明しました。
制約条件として、前回はAffinityをルータ間のIFへ設定することにより、そのパスは通らない(もしくはそのパスしか通さない等)ようなパスを自動的に構成することができました。

その他にもパスの例外処理方法があり、この一つにSRLG(Shared Risk Link Group)

もっとみる
もしよければ、一言コメントもお願いします!
2
ありがとうございます。よければフォローもお願いします。
1

SR-PolicyのConstraintsパス計算?

どうも、KATSUです。
今日は、SR-Policyの制約パス条件についての話です。
制約パス条件ってなんだろ?と思った方は見てください。

SR-Policyでパス計算をする時に毎回Explicitで経由するルータをA->B->Cのように指定するのは面倒ですよね?

逆に、自動計算するときは、IGPやTEのような、インターフェースに割り振ったIGPのCost、TEのCostの合計が最小になるパス

もっとみる
ありがとうございます。よければフォローもお願いします。
ありがとうございます。よければフォローもお願いします。
1

SR-Policyで使われるBinding SIDって何?

どうも、KATSUです。
今回の記事はSR-Policyで使われるBSID(Binding SID)についてです。

Segment Routingでは色々なSIDが出てきます。
これまでも、SRの同一ドメイン内でグローバルにユニークなPrefix-SID、ルータ毎にグローバルにユニークなNode-SID、そして、ルータ間のリンクや、VPNラベルとしてルータ毎にユニークなADJ-SIDがありました

もっとみる
ありがとうございます。よければフォローもお願いします。
1
ありがとうございます。よければフォローもお願いします。
2

SR-Policyという魔物を飼い慣らすには?

SR-Policyは基本的にはTraffic Engineeringのことで、経由するルータのパスの制御を行うものでした。

Segment Routingは誤解を恐れずに言うとMPLSの後継だと以前説明しました。
当初はSegment Routingの場合もSR-TEと呼称されていて、MPLS-TEと同じような動作をしていました。
では、SR-TEからSR-Policyへどのように進化をしたので

もっとみる
もしよければ、一言コメントもお願いします!
1