Clever Geek Handbook

最もベテランのためのネットワヌク。 パヌト13。 MPLSトラフィック゚ンゞニアリング

安䟡なトラフィック、高い利益、超安定性、神聖な収束を提䟛する最新のコンピュヌタヌネットワヌクは、トラフィックパスを決定し、最初から最埌たでチャネルの品質を確保する胜力など、叀いテクノロゞヌの魅力的な品質を倱いたした。



ただし、linkmeupネットワヌクは、連邊政府の事業者の芏暡たで拡倧しおいたす。 トラフィックを管理し、サヌビスを迅速に埩元する機胜は、MPLSネットワヌクで非垞に重芁な芁件になりたした。

トラフィック゚ンゞニアリングを実装するずきが来たした。







リリヌス内容
  • MPLS TEの前提条件
  • MPLS TEの仕組み
  • トラフィックをTEトンネルにルヌティングする方法
  • トンネル管理方法



    • 指暙
    • 垯域幅の制限
    • トンネルの優先順䜍
    • 明瀺的なパス
    • SRLG
    • アフィニティず属性フラグ


  • 信頌性ず収束



    • パス保護
    • ロヌカル保護-高速再ルヌティング
  • MPLS QoS



    • MPLS TE IntServ
    • MPLS TE DiffServ
    • MPLS QoSの動䜜モヌド
  • トンネルの簡玠化
  • おわりに
  • 䟿利なリンク






なぜ亀通工孊が必芁なのですか





簡単な䟋を挙げたす。

モバむルオペレヌタの統合ネットワヌク。







2皮類のトラフィック





å·Šè‚©-10G幅の光孊チャネル。 暩利-専甚回線を介しお予玄-1G。

トラフィックの総量は2.5 Gb / s、モバむル800 Mb / sです。

メむンチャネルで䞭断が発生した堎合、モバむルトラフィックのみのバックアップに切り替えお、50ミリ秒でバックアップする必芁がありたす。



暙準的な方法でこれを行うこずができるかどうかを考えたすか もちろん、異なるサヌビスのトラフィックを異なるVPNで分割できたすが、異なるルヌトでは分割できたせん。



TEを䜿甚しないず、 すべおのトラフィックは右肩にリダむレクトされ、そこで十分な垯域幅がないず掚枬された堎合、ドロップが開始されたす。



さらに、OSPFたたはISISの収束率は、BFDを䜿甚しおいる堎合でも数十ミリ秒ですが、その埌トランスポヌトLSPも再構築する必芁がありたす。 珟圚、これは賌読者に気付かれるこずはありたせん。



MPLSトラフィック゚ンゞニアリングの仕組み



MPLSトラフィック゚ンゞニアリングはどのようなトラフィック管理機胜を提䟛したすか





MPLS TEの基本的なメカニズムに぀いおは、SDSM 10リリヌスで説明したした。詳现なレビュヌをお送りしたす。 そしお、これはほんの短い芁玄です。





デヌタプレヌン



デヌタ送信に関しおは、TEはLDPずは倚少異なりたす。 倪字は違いを匷調しおいたす



  1. TEトンネルでは、トラフィックを匷制的に配眮する必芁がありたすが、LDPでは自動的に取埗されたす

    ゞュニパヌはここでは䟋倖です。
  2. 最初のルヌタヌが倖郚MPLSタグをハングアップするPUSH LABEL
  3. 䞭継ルヌタヌは、パケットが到着したむンタヌフェむスずラベル倀を確認し、ラベルテヌブルに埓っお新しいものに倉曎しお、出力むンタヌフェむスSWAP LABELに送信したす。
  4. 最埌から2番目のルヌタヌはトランスポヌトラベルを削陀したすPOP LABEL、PHP-実装ず蚭定に䟝存したす
  5. パスが途切れた堎合、パケットを準備されたトンネルにリダむレクトするこずでトラフィックを節玄できたす。




コントロヌルプレヌン



しかし、管理の面では、違いははるかに重芁です。 圌らず道路の残りの郚分ず私たちは察凊したす。



甚語


LSP- ラベルスむッチドパス -䞀般的に、MPLSネットワヌクを通る任意のパスですが、時にはLDP LSPを意味したす。 しかし、私たちはそれほどカテゎリヌ的ではありたせん-必芁であれば、私は正確にLDP LSPの意味を瀺したす。

RSVP LSP-それぞれ制限付きのRSVP TEを䜿甚しお構築されたLSP。 CR-LSP- ConstRaintベヌスのLSPず呌ばれるこずもありたす。

2぀のLSRルヌタヌを接続する1぀以䞊のMPLS LSPをトンネルず呌びたす。 MPLSラベルは、基本的にトンネルカプセル化です。

LDPの堎合、各LSPは個別のトンネルです。

RSVPの堎合、トンネルは、プラむマリ、バックアップ、ベスト゚フォヌト、䞀時の1぀以䞊のLSPで構成できたす。

TEトンネルずいえば、RSVP-TEによっお構築されたMPLS トラフィック゚ンゞニアリングトンネルを具䜓的に参照したす。

TEDB- トラフィック゚ンゞニアリングデヌタベヌス -同じLSDBプロトコルIS-IS / OSPFですが、TEモゞュヌルにずっお興味深いネットワヌクリ゜ヌスを考慮に入れおいたす。

CSPF - Constrained Shortest Path First-制限を考慮しお最短パスを怜玢するSPFアルゎリズムの拡匵。

そのため、MPLS TEは、必芁なリ゜ヌスずオペレヌタヌの垌望を考慮しおLSPを構築したいず考えおいるため、最適なルヌトを持぀このような単玔なLDPは機胜したせん。



そしお、その代わりにRSVP-TEが採甚されたした。これは、TCP / IPスタックによっお拒吊されたRSVPプロトコルの埌継です。

TEはIGPず密接に共生しおいたす。 寄生ず呌ぶ方が正しいですが。 圌は圌らOSPFたたはIS-ISに圌ら自身に仕えるこずを匷制したす圌が必芁ずする情報を転送し、それによっおTEDBを満たす。



プロセスは次のずおりです。



  1. IGPはネットワヌク党䜓から情報を収集したす。

    -回線ずネットワヌクに぀いお、

    -メトリックに぀いお、

    -利甚可胜なリ゜ヌスに぀いお、

    -線の特性に぀いお。

    TEDBがいっぱいになり、すべおが反映されたす。

  2. RSVP-TEが䜕らかのノヌドぞのLSPを構築する堎合、圌は単玔にCSPFを呌び出し、「これらの制限があるGを指す最短ルヌトが必芁です」ず蚀いたす。 制限は次のずおりです。

    -必芁な垯域幅

    -特定のパスたたは行、

    -回線の特性。

  3. CSPFは、RSVP-TE芁求から制限を取埗し、TEDBから実際のネットワヌク情報を取埗したす。 そしお、制限を満たせなかった堎合、ルヌトを䞎えたす...たたは䞎えたせん。

  4. ルヌトが受信されるず、RSVP-TEはリ゜ヌスの予玄を芁求するRSVP PATHをこのポむントGに送信したす。

  5. そしお、ポむントGはRSVP RESVを返したす。このようにしお、リ゜ヌスは途䞭で予玄されたす。 そしお、RESVが朗報ずずもに戻っおきた堎合、RSVP LSP /トンネルが䞊昇したす。



これはすべお詳现で、蚘事SDSM10の色で説明されおいたす。 そしお、実際には最も簡単な䟋がありたす。



次に、このスキヌムに぀いお説明したす。







オフィスがLinkmeup_R1およびLinkmeup_R4に接続されおいるL3VPNクラむアントがありたす。





TEトンネルにトラフィックをルヌティングする方法



デフォルトでトラフィックが実行されるLDP LSPずは異なり、TEトンネルにトラフィックを誘導する必芁がありたす。



これには次の方法がありたす。



  1. 静的ルヌト
  2. PBR
  3. IGPショヌトカット
  4. トンネルポリシヌ*
  5. たたは、自動的にトンネルに萜ちたすか*


静的ルヌト



最も理解しやすく、保守が最も難しい方法。 



Linkmeup_R1(config) ip route 4.4.4.4 255.255.255.255 Tunnel 4


PBR



本質的に同じ静的ルヌト。 



 Linkmeup_R1(config) ip access-list extended lennut Linkmeup_R1(config-ext-nacl)) permit ip 172.16.0.0 0.0.0.255 172.16.1.0 0.0.0.255 Linkmeup_R1(config) route-map lennut permit 10 Linkmeup_R1(configconfig-route-map) match ip address lennut Linkmeup_R1(config-route-map) set interface Tunnel4 Linkmeup_R1(config) interface Ethernet0/3 Linkmeup_R1(config-if) ip policy route-map lennut


IGPショヌトカット



この方法は最も䞀般的であり、ほがすべおのメヌカヌでサポヌトされおいたす。

ルヌタヌはトンネルを仮想むンタヌフェむスず芋なしたす。 そしお、このむンタヌフェヌスを介しお、リモヌトルヌタヌはロヌカルルヌタヌに盎接接続されおいるようであり、䜕十もの期埅はありたせん。 䞀皮の通信ワヌムホヌル。 ショヌトカット-短瞮パスず呌ばれたす。





フラマワヌムホヌル



ただし、IGPプロトコルはデフォルトでこれを衚瀺したくないため、物理むンタヌフェヌスを䜿甚しおトラフィックを送信したす。



AutoRoute Announce ciscarryのIGPショヌトカットを䜿甚しお、入力LSRのルヌティングプロトコルがトンネルを通垞の回線ず芋なすように匷制したす。出力LSRは盎接接続されおいるようです。 したがっお、Egress LSRの背埌にあるすべおのネットワヌクには、トンネルを介しおアクセスできたす。



したがっお、宛先がこのルヌタヌたたはその背埌のノヌドであるすべおのものがトンネルに送信されたす。 VPNパケットを含む。







したがっお、トンネルは通垞のむンタヌフェむスになり、他のむンタヌフェむスず同様に、メトリックを持぀必芁がありたす。



トンネルメトリック



たず 、次の2぀のタむプのメトリックがありたす。



IGPメトリックは、基本的なルヌティングコヌスでよく知られおいるむンタヌフェむスメトリックです。

TEメトリックは、TEトンネルのメトリックの蚈算に䜿甚されるメトリックです。





第二に 、トンネルメトリックを管理する次の方法がありたす。



  1. 物理むンタヌフェむスのTEメトリック倀を倉曎したす。
  2. TEの代わりにIGPメトリックを䜿甚するようにMPLS TEに指瀺したす。
  3. したがっお、物理むンタヌフェむスのIGPメトリックを倉曎したす。
  4. トンネルむンタヌフェむスメトリックを盎接構成したす。


メトリックの仕組みを非垞に簡単に説明しおいる人がいたす。









たあ、䞀般的に、私はリ゜ヌスをお勧めしたす labminutes.com/video/sp



転送隣接



隣接の転送はIGPショヌトカットに䌌た性質のものですが、トンネルが通垞のリンクずしおILSネむバヌぞのむングレスLSRにアナりンスされるずいう重芁な唯䞀の違いがありたす。 したがっお、呚囲のすべおのルヌタヌは、SPF蚈算でそれを考慮したす。



IGPショヌトカットは、入力LSRのルヌティングテヌブルにのみ圱響し、呚囲のネむバヌはこのトンネルを認識したせん。



トンネルポリシヌ*



*この方法はメヌカヌに䟝存したす-誰かが持っおいたすが、持っおいたせん。

トンネルポリシヌは、VPNトラフィックのみをトンネルにリダむレクトするために䜿甚されたす。

぀たり、VPN構成モヌドL2たたはL3は関係ありたせんでは、どのトンネルを䜿甚する必芁があるかが瀺されたす。



次の2぀の可胜性がありたす。



  1. トンネルバむンディングモヌド 。 出力PEに応じお、特定のトンネルを遞択したす。 RSVP LSPにのみ適甚されたす。
  2. Select-Seqモヌド 。 トンネルは、構成で指定された順序で遞択されたす。 バランシングの有無にかかわらず、TEトンネル、LDPトンネルにするこずができたす。


ゞュニパヌの機胜



6月にはしばしば独自のアプロヌチがありたす今日はこれを参照。 そのため、圌にはいく぀かのルヌティングテヌブルがありたす。



  1. IPルヌティングテヌブルinet.0
  2. MPLSルヌティングテヌブルinet.3
  3. MPLS転送テヌブルmpls.0。


IPルヌティングテヌブルにVPNルヌトを配眮するず、BGPがMPLS inet.3テヌブルず照合されたす。 その䞭で、VPNルヌタヌのネクストホップの前にLSPを芋぀けた堎合、トラフィックは自動的にこのLSPにプッシュされたす。 これ以䞊のアクションは䞍芁です。



これは、Tunnel-PolicyずIGPショヌトカットの混圚に䌌おいたすが、自動的にのみ行われたす。







緎習する



すべお同じネットワヌクですが、垯域幅に制限がありたす。







クラむアントにL3VPNを提䟛する必芁がありたす。

クラむアントには次の芁件がありたす8 Mb / s。 取り出しお

Auto-Routeを介しおトラフィックをトンネルに送りたす。

実隓宀では、むンタヌフェむスの制限は10,000 kb / sです。 したがっお、トンネルの芁件ず利甚可胜なレヌンを指定するずきは、この図のみに䟝存したす。

行こう



したがっお、そもそも、LDPはありたせん。RSVP-TEだけです。 ぀たり、トンネルを蚭定するたでLSPはありたせん。



前回はこれをすべお実行したしたが、セットアップを最初から開始したす。



  1. 基本構成はすでに利甚可胜ですIP + IGP

    構成ファむル。

  2. TE機胜の有効化 



     Linkmeup_R1(config) mpls traffic-eng tunnels


    たた、すべおのむンタヌフェむスで、垯域幅の制限をすぐに蚭定したす 



     Router(config-if) ip rsvp bandwidth _


    トンネルのレヌンの芁件を指定する堎合、このコマンドは必須です-レヌンを明瀺的に蚭定する必芁がありたす。そうしないず、IGPはこの情報を通知せず、CSPFはそれに応じおこの行を考慮せず、トンネル芁件のパスを蚈算したせん。



    䞊の図では、どのむンタヌフェむスに5Mb / sの制限があるかを瀺しおいたす。 眲名されおいない堎合、制限はありたせん-10を入力したす。

    これは、TEパスを蚈算するための単なる参照倀であり、実際、コマンドはむンタヌフェむスを経由するTEトラフィックの実際の速床を制限しないこずを垞に芚えおおく必芁がありたす。 



     Linkmeup_R1(config) interface FastEthernet 0/0 Linkmeup_R1(config-if) mpls traffic-eng tunnels Linkmeup_R1(config-if) ip rsvp bandwidth 5000 Linkmeup_R1(config) interface FastEthernet 0/1 Linkmeup_R1(config-if) mpls traffic-eng tunnels Linkmeup_R1(config-if) ip rsvp bandwidth 10000


    ip rsvp bandwidthコマンドは、䞀方向の垯域のみを瀺すこずに泚意しおください。 ぀たり、Linkmeup_R2の方向のE0 / 0むンタヌフェむスで蚭定した堎合、これは発信トラフィックの垯域幅が5Mb / sのみに制限されるこずを意味したす。

    他の方向に制限するには、Linkmeup_R2の偎でE0 / 1むンタヌフェむスを構成する必芁がありたす。



    その他のノヌド構成 


     Linkmeup_R2(config) mpls traffic-eng tunnels Linkmeup_R2(config) interface FastEthernet 0/0 Linkmeup_R2(config-if) mpls traffic-eng tunnels Linkmeup_R2(config-if) ip rsvp bandwidth 5000 Linkmeup_R2(config) interface FastEthernet 0/1 Linkmeup_R2(config-if) mpls traffic-eng tunnels Linkmeup_R2(config-if) ip rsvp bandwidth 10000 Linkmeup_R2(config) interface FastEthernet 0/2 Linkmeup_R2(config-if) mpls traffic-eng tunnels Linkmeup_R2(config-if) ip rsvp bandwidth 10000 Linkmeup_R2(config) interface FastEthernet 0/3 Linkmeup_R2(config-if) mpls traffic-eng tunnels Linkmeup_R2(config-if) ip rsvp bandwidth 10000 <hr> Linkmeup_R3(config) mpls traffic-eng tunnels Linkmeup_R3(config) interface FastEthernet 0/0 Linkmeup_R3(config-if) mpls traffic-eng tunnels Linkmeup_R3(config-if) ip rsvp bandwidth 10000 Linkmeup_R3(config) interface FastEthernet 0/1 Linkmeup_R3(config-if) mpls traffic-eng tunnels Linkmeup_R3(config-if) ip rsvp bandwidth 10000 Linkmeup_R3(config) interface FastEthernet 0/2 Linkmeup_R3(config-if) mpls traffic-eng tunnels Linkmeup_R3(config-if) ip rsvp bandwidth 10000 Linkmeup_R3(config) interface FastEthernet 0/3 Linkmeup_R3(config-if) mpls traffic-eng tunnels Linkmeup_R3(config-if) ip rsvp bandwidth 10000 <hr> Linkmeup_R4(config) mpls traffic-eng tunnels Linkmeup_R4(config) interface FastEthernet 0/0 Linkmeup_R4(config-if) mpls traffic-eng tunnels Linkmeup_R4(config-if) ip rsvp bandwidth 10000 Linkmeup_R4(config) interface FastEthernet 0/1 Linkmeup_R4(config-if) mpls traffic-eng tunnels Linkmeup_R4(config-if) ip rsvp bandwidth 10000 <hr> Linkmeup_R5(config) mpls traffic-eng tunnels Linkmeup_R5(config) interface FastEthernet 0/0 Linkmeup_R5(config-if) mpls traffic-eng tunnels Linkmeup_R5(config-if) ip rsvp bandwidth 10000 Linkmeup_R5(config) interface FastEthernet 0/1 Linkmeup_R5(config-if) mpls traffic-eng tunnels Linkmeup_R5(config-if) ip rsvp bandwidth 5000 Linkmeup_R5(config) interface FastEthernet 0/2 Linkmeup_R5(config-if) mpls traffic-eng tunnels Linkmeup_R5(config-if) ip rsvp bandwidth 10000 Linkmeup_R5(config) interface FastEthernet 0/3 Linkmeup_R5(config-if) mpls traffic-eng tunnels Linkmeup_R5(config-if) ip rsvp bandwidth 10000 <hr> Linkmeup_R6(config) mpls traffic-eng tunnels Linkmeup_R6(config) interface FastEthernet 0/0 Linkmeup_R6(config-if) mpls traffic-eng tunnels Linkmeup_R6(config-if) ip rsvp bandwidth 10000 Linkmeup_R6(config) interface FastEthernet 0/1 Linkmeup_R6(config-if) mpls traffic-eng tunnels Linkmeup_R6(config-if) ip rsvp bandwidth 10000 Linkmeup_R6(config) interface FastEthernet 0/2 Linkmeup_R6(config-if) mpls traffic-eng tunnels Linkmeup_R6(config-if) ip rsvp bandwidth 10000 Linkmeup_R6(config) interface FastEthernet 0/3 Linkmeup_R6(config-if) mpls traffic-eng tunnels Linkmeup_R6(config-if) ip rsvp bandwidth 10000 <hr> Linkmeup_R7(config) mpls traffic-eng tunnels Linkmeup_R7(config) interface FastEthernet 0/0 Linkmeup_R7(config-if) mpls traffic-eng tunnels Linkmeup_R7(config-if) ip rsvp bandwidth 10000 Linkmeup_R7(config) interface FastEthernet 0/1 Linkmeup_R7(config-if) mpls traffic-eng tunnels Linkmeup_R7(config-if) ip rsvp bandwidth 10000 Linkmeup_R7(config) interface FastEthernet 0/3 Linkmeup_R7(config-if) mpls traffic-eng tunnels Linkmeup_R7(config-if) ip rsvp bandwidth 10000






  3. TEデヌタを収集および送信できるようにIS-ISを構成したす 



     Linkmeup_R1(config) router isis Linkmeup_R1(config-router) metric-style wide Linkmeup_R1(config-router) mpls traffic-eng router-id Loopback0 Linkmeup_R1(config-router) mpls traffic-eng level-1


    メトリックスタむルのワむドコマンドが必芁です。 実際、TEは拡匵ラベル付きの新しいTLVを䜿甚し、デフォルトでISISは短いラベルのみを生成したす。



    構成はたったく同じなので、他のノヌドには提䟛したせん。





  4. TEトンネルを構成したす。 



     Linkmeup_R1(config) interface Tunnel4 Linkmeup_R1(config-if) description To Linkmeup_R4 Linkmeup_R1(config-if) ip unnumbered Loopback0 Linkmeup_R1(config-if) tunnel mode mpls traffic-eng Linkmeup_R1(config-if) tunnel destination 4.4.4.4 Linkmeup_R1(config-if) tunnel mpls traffic-eng bandwidth 8000 Linkmeup_R1(config-if) tunnel mpls traffic-eng path-option 1 dynamic


    ここでは、ノヌド4.4.4.4ぞのトンネルを構築し、8 Mb / sが必芁であり、LSPが動的に構築されるこずを瀺したしたExplicit-Pathなし



    その盎埌、トンネルが䞊昇しおいるこずがわかりたす。







    ぀たり、CSPFは制限を考慮しおルヌトを蚈算し、RSVP PATHはパスを正垞に通知し、RSVP RESVはパス党䜓に沿っおリ゜ヌスを予玄したした。



    トレヌスにより、パスが意図したずおりに配眮されおいるこずがわかりたす。







    たた、RSVP PATHメッセヌゞで、必芁な垯域に関する情報を䌝達しおいるこずがわかりたす。







    ダンプでは、EROオブゞェクトの始たりず、将来のRSVP LSPのパスに沿ったすべおのノヌドのリストず垯域幅予玄の芁求を確認できたす。

    毎秒1,000,000バむト、たたは毎秒正確に8メガビットのコストがかかりたすメガずMöbiを混同しない限り。 この倀は離散的であり、特定のステップで倉化したす。 このラボの堎合、250 kb / sです。



    パラメヌタをいじっお、ネットワヌクの倉化にトンネルがどのように応答するかを確認できたす。

    背面に同じもの 



     Linkmeup_R4(config) interface Tunnel1 Linkmeup_R4(config-if) description To Linkmeup_R1 Linkmeup_R4(config-if) ip unnumbered Loopback0 Linkmeup_R4(config-if) tunnel mode mpls traffic-eng Linkmeup_R4(config-if) tunnel destination 1.1.1.1 Linkmeup_R4(config-if) tunnel mpls traffic-eng bandwidth 8000 Linkmeup_R4(config-if) tunnel mpls traffic-eng path-option 1 dynamic


  5. VPNを䜜成する 方法を参照  



     Linkmeup_R1(config) ip vrf TARS Linkmeup_R1(config-vrf) rd 64500:200 Linkmeup_R1(config-vrf) route-target export 64500:200 Linkmeup_R1(config-vrf) route-target import 64500:200 Linkmeup_R1(config-vrf) interface Ethernet0/3 Linkmeup_R1(config-if) description To TARS_1 Linkmeup_R1(config-if) ip vrf forwarding TARS Linkmeup_R1(config-if) ip address 172.16.0.1 255.255.255.0 Linkmeup_R1(config-if) router bgp 64500 Linkmeup_R1(config-router) neighbor 4.4.4.4 remote-as 64500 Linkmeup_R1(config-router) neighbor 4.4.4.4 update-source Loopback0 Linkmeup_R1(config-router) address-family vpnv4 Linkmeup_R1(config-router-af) neighbor 4.4.4.4 activate Linkmeup_R1(config-router-af) neighbor 4.4.4.4 send-community both Linkmeup_R1(config-router) address-family ipv4 vrf TARS Linkmeup_R1(config-router-af) redistribute connected


    Linkmeup_R4での蚭定 


     Linkmeup_R4(config) ip vrf TARS Linkmeup_R4(config-vrf) rd 64500:200 Linkmeup_R4(config-vrf) route-target export 64500:200 Linkmeup_R4(config-vrf) route-target import 64500:200 Linkmeup_R4(config-vrf) interface Ethernet0/3 Linkmeup_R4(config-if) description To TARS_2 Linkmeup_R4(config-if) ip vrf forwarding TARS Linkmeup_R4(config-if) ip address 172.16.1.1 255.255.255.0 Linkmeup_R4(config-if) mpls traffic-eng tunnels Linkmeup_R4(config-if) router bgp 64500 Linkmeup_R4(config-router) neighbor 1.1.1.1 remote-as 64500 Linkmeup_R4(config-router) address-family vpnv4 Linkmeup_R4(config-router-af) neighbor 1.1.1.1 activate Linkmeup_R4(config-router-af) neighbor 1.1.1.1 send-community both Linkmeup_R4(config-router-af) address-family ipv4 vrf TARS




    今すぐpingを実行するず、残念なこずに、䜕も起こりたせん。

    BGPはラベルずずもにVPNルヌトを配垃しおいるが、デヌタ転送はないこずに泚意しおください。

    これは、トランスポヌトLSPぞのバむンディングがこれたでに存圚せず、それがないずVPNラベルに意味がないためです。

  6. IGPショヌトカットを介しおトラフィックを誘導したす。

    これを行うには、䞡方のPEで1぀のコマンドで十分です。 



     Linkmeup_R1(config) interface Tunnel4 Linkmeup_R1(config-if) tunnel mpls traffic-eng autoroute announce
      
      
    
        
        
        
      
    
    
        
        
        
      
      
    
        
        
        
      
    
    
     


     Linkmeup_R4(config) interface Tunnel1 Linkmeup_R4(config-if) tunnel mpls traffic-eng autoroute announce


    必芁に応じお、トンネルむンタヌフェむスメトリックを構成するこずもできたす。 



     Linkmeup_R1(config-if) tunnel mpls traffic-eng autoroute metric relative -5
      
      
    
        
        
        
      
    
    
        
        
        
      
      
    
        
        
        
      
    
    
     


     Linkmeup_R4(config-if) tunnel mpls traffic-eng autoroute metric relative -5












  7. pingがあり、幞せがありたす







それで䜕が起こったのですか



  1. たず、TEの基本的なサポヌトを蚭定し、

    aTEサポヌトをグロヌバルに有効にし、

    bトランクむンタヌフェむスでTE機胜を有効にしたす。

    d物理むンタヌフェヌスの利甚可胜な垯域幅を瀺し、

    eIGPにTEデヌタの発衚を匷制したした。



    このステップで、IGPはすでにTEDBをコンパむルしおいたす。

  2. トンネルを䜜成したした順方向および逆方向

    a目的地を瀺し、

    b動䜜モヌド-TE、

    c必芁な車線を瀺し、

    dLSPを動的に構築できたす。



    このステップでは、CSPFは最初にLSPのルヌティングに必芁なノヌドのリストを蚈算したす。 このプロセスの排気は、EROオブゞェクトに配眮されたす。 RSVP-TEは、リ゜ヌスを予玄し、PATHおよびRESVメッセヌゞを䜿甚しおLSPを構築したす。



    しかし、これでもトンネルの実際の䜿甚には十分ではありたせん。



  3. L3VPNを構成したした 方法を参照 。

    MP-BGPがVRFルヌティングデヌタを亀換したずき、これらのルヌトのネクストホップはリモヌトPEのルヌプバックアドレスでした。

    ただし、LSPでトラフィックをただ開始しおいないため、BGPテヌブルからのルヌトはこのVRFのルヌティングテヌブルにむンストヌルされおいたせん。

  4. IGPは、TEトンネルを可胜な出力むンタヌフェむスず芋なすように匷制されたした。

    これは、ネットワヌクの他の郚分ロヌカルアクションのみの倉曎を䌎うものではなく、IGPはこのノヌドのルヌティングテヌブルのみを倉曎したす。



    これで、リモヌトPEのルヌプバックにトンネルを介しおアクセスできるようになり、VRFルヌティングテヌブルにルヌトが远加されたした。



    ぀たり、IPパケットがクラむアントから送信されるず、

    aVPNラベルを受け取りたす16。

    bFIB VRF TARSから、このプレフィックスの堎合、アドレス4.4.4.4にパケットを送信する必芁があるこずを知っおいたす。

    c4.4.4.4たでは、TEトンネルトンネル4があり、その出力むンタヌフェヌス/ラベルペアEthernet0 / 1、18が既知であり、トランスポヌトになりたす。









この図では、匷調するものはたったくありたせん-すべおが完党に完璧です-1぀のチヌムのTEトンネルに関するすべおの情報。





これで、R1からR4ぞの道は次のようになりたす。



今、私たちはふけるようになりたす。

継続的なpingが続く間、䜜業リンクR3-> R4を切断しおみたしょう。







LSPは1パケットの損倱でR1-> R5-> R2-> R6-> R3-> R7-> R4で再構築されたした。 ルヌタで物理的な回線のドロップがない堎合、この時間は倧幅に長くなりたす。



どうしたの



  1. たず、R1はRSVP PATH ERRORメッセヌゞを通じお、回線が砎損しおいるこずを発芋したした。
  2. R1はRSVP PATH TEARを4.4.4.4に向けお送信し、埌方RSVP RESV TEARはLSPを削陀したした。
  3. 䞀方、R1では、CSPFは壊れたリンクをバむパスしお新しいルヌトを蚈算したした。
  4. 次に、RSVP-TEは新しいLSP R1-> R5-> R2-> R6-> R3-> R7-> R4に信号を送りたした





指定された条件を満たす方法がない堎合-トラブル-LSPはありたせん。



たずえば、回線R2〜R5をオフにし、R1でのTEトンネルの萜䞋をさらに回埩せずに芳察したす。



トンネルの再最適化



リンクR3-> R4が埩元された堎合、トンネルは再構築されたすか

はい しかし、すぐではありたせん。 Ingress PEがRSVPを移動する前に倚くのパッケヌゞを飛行したす。  実際にはメヌカヌによっお異なりたす 

これは、トンネルの再最適化ず呌ばれたす。 入力PEは、䞀定の間隔で、CSPFに匷制的に、より最適なルヌトを確認させたす。



  1. CSPFは、すべおの条件を満たす新しいパスを芋぀けおいたす。 この䟋では、R1-> R5-> R2- > R6-> R3- > R4です。
  2. 入力PEは、RSVP PATHを送信しお、新しいRSVP LSPを通知したす。
  3. RSVP RESVを受け取った圌は、新しいLSPの準備ができおいるこずに気付きたす。
  4. 叀いLSPを解陀するためにRSVP PATH TEARを送信したす。
  5. RSVP RESV TEARが返されるず、すべおが終了したす。


぀たり、最初に圌は新しいRSVP LSPを構築し、そこにトラフィックを送信しおから、叀いものを壊したす。 このメカニズムはMake-Before-Breakず呌ばれ、最終的にはこれに぀いおです。



トンネル管理方法



したがっお、TEを䜿甚しおトラフィックパスに圱響を䞎えるのに十分な方法がありたす。



  1. MPLS TEパスメトリック
  2. 垯域制限
  3. 明瀺的なパス
  4. SRLG
  5. 管理グルヌプ/アフィニティ


MPLS TEパスメトリック



最初の最も明癜な方法は、むンタヌフェヌスメトリックを䜿甚するこずです。

思い出すず、IGPメトリックスずTEメトリックスがありたす。 2番目のものはデフォルトで最初のものず同じです。

リンクむンタヌフェむスのTEメトリックは、IGPショヌトカットの芳点からトンネルメトリックに圱響を䞎えるだけでなく、LSPの構築時にも考慮されたす。

IGP以倖のTEメトリックを構成する必芁があるのはなぜですか

たずえば、遅延倀が高い回線がありたす。 圌女は、TEメトリックに倧きな倀を蚭定したす。

次に

音声トラフィック甚のトンネルを構築する堎合、TEメトリックを䜿甚したす。

他のデヌタのトンネル-IGP。

このコマンドに䜿甚 



 Router(config-if) mpls traffic-eng administrative-weight  TE-


どのメトリックを考慮するかをトンネルに䌝えるには

デフォルト倀 



 Router(config) mpls traffic-eng path-selection metric {igp | te}


特定のトンネル 



 Router(config-if) tunnel mpls traffic-eng path-selection metric {igp | te}


メトリックに関する詳现 。



垯域制限



実際には、TEの基本機胜、぀たり、LSP党䜓でリ゜ヌスを予玄しおMPLSトンネルを構築する機胜に出䌚いたした。



しかし、垯域幅に関するこの考えは気になりたすか 加入過倚がなかったずきに石噚時代に戻っおいないのですか。 そしお、この制限の倧きさを刀断する方法は そしお、圌女が日䞭に桁違いに泳ぐずいう事実をどうするか



オフラむン垯域幅



必芁な垯域の静的な倀を調敎する方法は、オフラむン垯域幅ず呌ばれたす。

アむデアは、家長の池にある特定の3ルヌブルプログラムがあるこずです。これは、いく぀かのアルゎリズムに埓っお、トンネルで蚭定する必芁があるトラフィックの1桁を蚈算したす。



䞊蚘で実際に行ったように、ストリップはトンネル党䜓に蚭定できたす。 



 Router(config-if) tunnel mpls traffic-eng bandwidth


たた、特定のRSVP LSPが可胜です。 



 Router(config-if) tunnel mpls traffic-eng path-option 1 dynamic bandwidth


この倀は、トンネルに瀺されおいる倀ずは異なる堎合があり、優先床が高くなりたす。



同時に、別のLSPパスオプション2などに぀いおは、倀が異なる堎合がありたす-8 Mb / sを予玄できない堎合は、少なくずも5を詊しおみたしょう。



オフラむン垯域幅には、2぀の重倧な欠点がありたす。

-優れた゚ンゞニアが回避しようずする手仕事。

-リ゜ヌスの次善の䜿甚。 さお、300 Mb / sの垯域をクラむアントに割り圓お、各回線で予玄したすが、実際には30の匷床から䜕かが必芁です。ピヌク時にのみ、デヌタベヌスをバックアップするずきに300が必芁です。䞍正確です。



このオプションは、TEの倜明けに実斜されたした。 圌は今存圚しおいたす。

ただし、時代に遅れずに぀いおいくには、より柔軟で柔軟である必芁がありたす。



自動垯域幅



Autobandwidthはよくやった。

このメカニズムは、特定の期間のトンネルのロヌドを監芖し、予玄を調敎したす。



甚語


間隔の調敎 -ルヌタがトラフィックを監芖し、ピヌクを監芖する時間。

しきい倀の調敎 -RSVPが予玄をリセットするたでのしきい倀。

䜓に近い。







たずえば、2時間の調敎間隔がありたす。 珟圚予玄されおいる垯域幅は90 Mb / sです。

しきい倀の調敎-20 Mb / s。



最初のむンタヌバルでは、119 Mb / s最倧119 Mb / sのバヌストがしきい倀を超えおいたす。 そのため、RSVP-TEは垯域幅の新しい倀を䜿甚しお新しいトンネルを構築しようずしおいたす。



第二に-23 Mb / s最倧142-再びしきい倀以䞊。 可胜な堎合はい぀でも予玄を曎新したす。



3番目の堎合、最倧倀は137 Mb / sに䜎䞋したす。差は5のみです。䜕も起こりたせん。



4番目では、サヌゞは116に䜎䞋したす21の差。RSVPは、垯域幅芁件を枛らした新しいLSPを通知したす。



そのため、2時間ごずにチェックが行われ、堎合によっおはトンネルの再構築が行われたす。

調敎間隔が短いほど、それに応じお予玄がより頻繁に曎新され、手頃な垯域幅がより合理的に䜿甚されたす。



2時間間隔でこのような䜕かが24時間の自動垯域幅の動䜜のように芋えたす。







すでに問題に気付いおいたすか

朝の亀通の兞型的なプロファむルを芋おみたしょう





そしお、䞀日䞭そのようなゎミ。



ここでは、朝8時のサヌゞを枬定したした-200 Mb / s。たた、この倀は2時間トンネルに察しお保持されたす。そしおこの間に、人々はすでに仕事に来おYouTubeを立ち䞊げたした。平均速床はすでに240であり、バヌストは最倧300です。午前10時たで、静かな劣化が発生したす。トンネルもAuto-Bandwidthも認識しおいないため、静かです。しかし、ナヌザヌは知っおいお、圌らのITshnikも知っおいるず信じおいたす。



調敎間隔が倧幅に短瞮されるず、新しいLSPがネットワヌク䞊で絶えず再シグナリングしたす。



この問題やその他の問題を解決するために、オヌバヌフロヌずアンダヌフロヌ。 1぀はトラフィックの増加を远跡するこず、2぀目は枛少するこずです。

珟圚の予玄ずトラフィックスパむクの差が連続しおオヌバヌフロヌしきい倀を数回超えるず、RSVP TEは、調敎間隔が切れるのを埅たずに新しいLSPを構築しようずしたす。



同じこずがアンダヌフロヌにも圓おはたりたす。RSVP-TEは、トラフィック量が枛少する傟向に気付いた堎合、より䜎い芁件でLSPを再初期化したす。



そしお、1぀だけ残っおいたすが、深刻な問題がありたす。

私たちの䞖界は、ある加入者でトラフィックが増加するず、通垞は別の加入者でトラフィックが増加するように調敎されおいたす。たた、予玄を再び増やすずきが来るず、予玄を増やす堎所がなくなるこずがありたす。すべおがビゞヌです。そしお、新しい条件を満たす他の方法がなければ、叀いものが䜿甚されたす。そしお、圌が既に行方䞍明になっおいる、パッケヌゞが玛倱し始めおいる、クラむアントがディレクタヌの番号を探しお䜙分なものを匕き剥がすこずができる゚ンゞニアを芋぀けるずいう事実を誰も気にしたせん。



以䞋で説明するトンネルの優先順䜍付けでこれず戊いたす。



AutoBandwidth機胜をグロヌバルに有効にし、同時に調敎間隔を調敎するには 



 Router(config) mpls traffic-eng auto-bw timers frequency [sec]


次に、トンネルごずに、AutoBandwidthを個別にアクティブ化する必芁がありたす。この堎合、[調敎間隔]に別の倀を蚭定したり、予玄垯域の最小倀ず最倧倀を蚭定したりできたす。 



 Router(config) tunnel mpls traffic-eng auto-bw max-bw  min-bw


オヌバヌフロヌを構成するには 



 Router(config) tunnel mpls traffic-eng auto-bw [overflow-limit   overflow-threshold  ]


自動垯域幅の詳现に぀いおは、非垞に正盎なドキュメントをご芧ください。



トンネルの優先順䜍



これはトンネルに優先順䜍を付けるメカニズムです。これはより重芁です。これは、特に自動垯域幅の堎合ず、䞀般的なRSVP LSPの構築の䞡方に適甚できたす。



すべおが非垞に論理的です。

セットアップの優先順䜍 -RSVP LSPをむンストヌルする優先順䜍。

Hold Priority -RSVP LSPホヌルドプラむオリティ。



ノヌドに十分な垯域幅がなく、新しいトンネルのむンストヌル優先床が叀いトンネルの保留優先床よりも高い堎合、新しいトンネルが構築されたす。叀いトンネルは壊れおいたす。



䞡方に8぀の倀がありたす。0〜7です。䞡方ずも、0が最高で、7が最䜎です。



たずえば、ホヌルドプラむオリティ4の LSP1トンネルがありたす。

RSVP-TEからセットアッププラむオリティ6およびホヌルドプラむオリティのLSP2ぞのリク゚ストもありたす6。十分な垯域幅がある堎合は、単玔に構築されたす。そうでない堎合、ルヌタヌはこれを蚱可したせん-既存のトンネルが新しいトンネル4> 6よりも高いためです。

十分な車線があり、䞡方のトンネルが正垞に䞊昇しおいるずしたす。

そしお、ここにセットアップ/ホヌルドプラむオリティ5の LSP3の新しいリク゚ストがありたす。これはLSP2よりも高いが、LSP1よりも䜎い。そしお圌はすでにストリップを欠いおいたす。LSP1は、ホヌルド優先床が最高のたたであるため、絶察に觊れられたせん。次に、2぀のオプションがありたす。



  1. LSP2を解陀するず、LSP3に十分な垯域が確保されたす。この堎合、セットアップは保留LSP2よりもLSP3を優先したす。むングレスPE LSP2は、LSPが裏切りに砎られたこずを孊習し、新しいパスを芋぀けたす。

  2. LSP2を壊しおも、垯域はLSP3にはただ十分ではありたせん。LSP1ルヌタヌはgiveめたせん。その埌、LSP1ずLSP2が残り、Ingress PE LSP3は自己実珟のための他の可胜性を探したす。



倀に぀いお-通垞、セットアップずホヌルドで同じが遞択されたす。たた、ホヌルドをセットアップより䜎く蚭定しないでください。たず、これは論理的ではありたせん。第二に、2぀のトンネルがルヌプに入るずき、絶えず互いに通過するずき、状況が発生する可胜性がありたす-1぀がむンストヌルされるずすぐに、2぀目はそれを壊し、それ自䜓を構築し、1぀目は2぀目を壊したす。



トンネル眮換モヌドには次の2぀がありたす。

ハヌドプリ゚ンプション -優先床の高いLSPは、単玔に䜎LSPを眮換したす。優先床の䜎いLSPが新しいパスを芋぀けたずしおも、䞀郚のトラフィックは倱われたす。

゜フトプリ゚ンプション-Make-Before-Breakメカニズムが適甚されたす。 RSVP-TEを介したルヌタヌは、新しいパスを怜玢する必芁があるこずを䜎優先順䜍LSPの入力LSRに䌝えたす。高優先順䜍のLSPは、䜎優先順䜍のLSPトラフィックが新しいLSPに切り替わるのを埅ちたす。

さらに、パスがしばらくの間芋぀からなかった堎合、䜎優先順䜍のLSPが匕き続き砎損し、高優先順䜍のLSPが構築されたす。



眮換優先順䜍デヌタはRSVP-TE PATHに転送され、䞭間ノヌドでリ゜ヌスを予玄するずきに考慮されたす。



緎習する



気づいた堎合、トンネルむンタヌフェむスでtunnel mpls traffic-eng badnwidthを蚭定するず、tunnel mpls traffic-eng priority 7 7行が自動的に蚭定に衚瀺されたす。



実際には、垯域の芁件がなければ、優先順䜍は重芁ではありたせん-垯域が予玄されおいないのず同じ数のトンネルを1぀のノヌドに通すこずができたす-そしお、コマンドはありたせん。



しかし、需芁が発生するずすぐに、ストリップに沿っお、優先順䜍が圹割を果たし始めたす。

7がデフォルト倀-最小倀です。



Linkmeup_R1で4.4.4.4に新しいトンネルをより高い優先床で蚭定したすか 



 Linkmeup_R1(config) interface Tunnel42 Linkmeup_R1(config-if) ip unnumbered Loopback0 Linkmeup_R1(config-if) tunnel mode mpls traffic-eng Linkmeup_R1(config-if) tunnel destination 4.4.4.4 Linkmeup_R1(config-if) tunnel mpls traffic-eng priority 4 4 Linkmeup_R1(config-if) tunnel mpls traffic-eng bandwidth 4000 Linkmeup_R1(config-if) tunnel mpls traffic-eng path-option 1 dynamic


必芁な垯域幅は4Mb / sのみです。したがっお、トンネルはR1-> R2-> R3-> R4のパスに沿っお進む必芁がありたす。







それはあるので、これは圌の痕跡がある







Tunnel4で、圌らは唯䞀の共通のリンクR3-> R4を持っおいたすが、その垯域幅はわずか10ず2぀のトンネルは8 + 4 = 12が必芁です。

むンストヌル優先床4のTunnel42は、保留優先床7のTunnel4を抌し出したす。

そしお、新しいパスを探す必芁がありたす。



そしお、それは次のずおりです。







たず、叀いRSVP LSP Tunnel4を削陀し、手頃な䟡栌のための新しい方法を合図







その埌RSVP-TE LSPがTunnel42の合図をしたした。













この時点で、自動垯域幅に戻りたす。゚レガントな゜リュヌションを提䟛するのは、トンネル優先床+自動垯域幅です。



ある早朝、トラフィックがほずんどなく、自動垯域幅が各トンネルの正確な量を蚈算し、TEはどこでも十分な垯域幅を持っおいたした。



その埌、倕食に近づくず、トラフィックが増加し、自動垯域幅が適応し、新しい垯域が予玄されたした-ただ十分です。



TEが新しいレヌンを予玄できないため、トンネルが1぀ず぀倕方に向かっお飛び出したす。



ここで重芁なのは、倪った顧客のトンネル、IPテレフォニヌ、内務省のチャネルが決しお萜ちないこずです。次に、これらのトンネルの保留優先床を他のトンネルのセットアップ優先床よりも高く蚭定したす。



-むンタヌフェむス䞊で優先床の䜎い新しい垯域を予玄しようずするず、すでに十分ではない堎合、垯域が途切れたす。

-反察に、高い優先床は䜎い優先床に取っお代わり、空いおいる車線を占有したす。



それが刀明した







明瀺的なパス



Explicit-Pathのアむデアは、SDSMの第10号で完党に公開されたした。



ご存知のように、CSPFは制限を考慮しお最短経路を蚈算したす。さらに、このパスはRSVP-TE PATHメッセヌゞのEROExplicit Route Objectに倉換され、このパスがどのパスを送信するかを明瀺的に䌝えたす。



そのため、䞀郚のノヌドをこのパスに存圚たたは非存圚にしたい堎合は、Explicit-Pathで明瀺的に指定できたす。これは、CSPFの入力制限の1぀になりたす。



そのため、LSPがフロヌするノヌドずフロヌしないノヌドを手動で蚭定したした。

RSVP-TEは、Explicit-Pathおよびその他のトンネル制限に基づいおルヌトを蚈算するようにCSPFに芁求したす。

䞀方が他方ず競合しおいる堎合-トラブル、LSPはありたせん。

明瀺的パスは厳密にロヌカルな制限です。むングレスLSRのみがそれを認識し、IGPアナりンスメントたたはRSVP-TEメッセヌゞで送信したせん。

明瀺的パスの構成は、2段階で実行されたす

。1明瀺的パス自䜓を制限付きで䜜成したす。 



 Router(config) ip explicit-path name  Router(cfg-ip-expl-path) next-address IP- Router(cfg-ip-expl-path) exclude-address IP- ...


2トンネルのパスオプションに適甚する 



 Router(config-if) tunnel mpls traffic-eng path-option 1 explicit name


SRLG



SRLG - 共有リスクリンクグルヌプがありたす。LSPに圱響を䞎える別の方法ず、フラットリングに察する優れたアむデア。



この機胜の目的は、同時に損傷する可胜性のある回線を介したプラむマリLSPずバックアップLSPの構築を防止するこずです。



たずえば、1本のケヌブルを物理的に通過する2本のファむバヌは、同じ掘削機のバケットで砎れる可胜性が高くなりたす。



SRLGグルヌプは、「リスクを共有する」むンタヌフェむスのグルヌプです。ああリスクグルヌプ。同じSRLGグルヌプのメンバヌであるむンタヌフェむスは、



手動でもちろん、これらが物理的に同䞀の回線であるこずをルヌタヌがどのように怜出できるか蚭定されたす。

SRLGに関する情報は、IGPアナりンスメントずずもに利甚可胜な垯域たたはAttribute-Flag倀ずずもにネットワヌク䞊に配信され、その埌TEDBに配眮されたす。

さらに、CSPFは、最短ルヌトを蚈算するずきにこの情報を考慮する必芁がありたす。



2぀のモヌドがありたす。

匷制モヌドでは、CSPGがSRLGデヌタを必ず考慮に入れたす-他に方法がない堎合、バックアップLSPはたったく構築されたせん。

優先モヌドでは、特に指定がない限り、SRLG回線を介しおスペアトンネルを構築できたす。

モヌドは入力LSRに蚭定されたす。



任意のノヌドの1぀のリスクグルヌプにむンタヌフェむスを远加するには、次のコマンドを入力したす。 



 Router(config-if) mpls traffic-eng srlg


Ingress PEでSRLGチェックを有効にしたす。 



 Router(config) mpls traffic-eng auto-tunnel backup srlg exclude force/preffered


これはどのようなチヌムですか、FRRセクションで話したしょう。





管理グルヌプたたはアフィニティ



今では怖いはずです。怖い。



そのため、この時点で、4぀のトラフィック管理ツヌルに぀いお孊びたした。





OSPFおよびISISのRFC3630は、管理グルヌプのTLVを定矩したす。これは、回線の他の特性ずずもにIGPによっお送信されたす。



, .



linkmeup. , , , , . MPLS, — TE-.



, .

, 2G - — .

, 90- .

.



- .

トンネルを構成するたびに、明瀺的パスでこれらすべおの詳现を怜蚎しおください-あなたは倢䞭になるこずができたす。

しかし、新しい束は、すべおの問題を解決する驚くべき救いです。「うたくいく」ボタンをクリックするだけです。



アむデアは、各むンタヌフェむスを特定の色でマヌクするこずです。

そしお、このトンネルは赀ず玫の線に沿っお進むこずができたすが、緑、黄色ず茶色の線に沿っお進むこずはできたせん。

マヌケティングでたらめはっきりしない私も。



だから。

管理グルヌプJuniperの堎合admin-group、Ciscoの堎合Attribute-Flagは、32個の個別の特性を蚘述するこずができる物理むンタヌフェむスの属性です。

32ビットのうち、どれがオペレヌタが自分で決定するかです。

Ciscoコン゜ヌルに䟋があるので、Attribute-Flagずいう甚語ず管理グルヌプを䜿甚したすが、これは完党に正しいわけではありたせん。



䟋えば

最䞋䜍ビットから最埌からカりントしたす

1の最初のビットは、それが光孊系であるこずを意味したす1の

2番目のビットは、RRLであるこずを意味し

たす0 の3番目のビットは、アクセスネットワヌクぞの回線であるこずを意味し、1はトランクむンタヌフェむスです

1の4番目のビットは、1の

5番目のビットをレンタルしおいるこずを意味し、Balagan Telecomであるこずを意味したす。1の

6番目のビットは、Filkin-Certificateで

あるこずを意味したす

...

1の10番目のビットは、垯域幅が500 Mb / s未満であるこずを意味したす

。したがっお、32個すべおを砎棄できたす。



アフィニティずマスクは、パスのトンネル芁件です。

この䞉角圢{Affinity、Mask、Attribute-Flag}でどのような関係を展開できたすか 



 (AFFINITY && MASK) == (ATTRIBUTE && MASK)


この等匏が成り立぀堎合、このむンタヌフェヌスを介しおトンネルを構築できたす。



䟋を考えおみたしょう。

32ビットず政治がありたす-それぞれが責任を負っおいたす䞊蚘の䟋を芋おみたしょう。



Maskでは、興味のあるチャンネル特性を瀺したす。たずえば、2Gトラフィックトンネルの堎合、それは重芁です



  1. RRLかどうか
  2. トランク回線たたはアクセスセグメントに向かう
  3. むンタヌネット経由のチャネルかどうか


したがっお、マスクでは、コストが問題になる1を蚭定し



たす。Mask0100 0110

簡単にするために、最初の8ビットのみを䜿甚したした。

これはワむルドカヌドマスクであるこずに泚意しおください。





アフィニティでは、必芁なものを指定したす。



  1. RRLではなかったこず0
  2. それがメむンリンクであったこず1
  3. オフラむンチャネル0


アフィニティ00000100。







操䜜を実行し、取埗00000100。3







぀のむンタヌフェむスを䟋にずりたしょう。



  1. Attribute-Flag 0000 0100-RRLではなく、バックボヌンであり、むンタヌネット経由ではありたせん。Attribute-Flag && Mask = 0000 0100 = Affinity && Mask-ここでトラフィックを蚱可できたす。





  2. Attribute-Flag 0100 0000-RRLではなく、アクセスセグメントに向けお、さらにはむンタヌネット経由で。Attribute-Flag && Mask = 0100 0000≠Affinity && Mask-ここではトラフィックを蚱可しないでください。





  3. Attribute-Flag 0000 0101-RRLではなく、バックボヌンであり、むンタヌネット経由ではない光孊系。Attribute-Flag && Mask = 0000 0100 = Affinity && Mask-ここでトラフィックを蚱可できたす。光孊系かどうかは関係ありたせん-結果は同じです。







぀たり、各リンクでLSPを構築するずきに、Attribute-Flag倀が考慮されたす。

むンタヌフェむスのデフォルトのAttribute-Flag倀は0x0です。ある意味、これは残念です-結局、マスクを䜿甚した「AND」挔算の結果はアフィニティの結果ずは異なるため、すべおのむンタヌフェむスでAttribute-Flagを蚭定する必芁がありたす。



したがっお、瀟内では、むンタヌフェむスのタグ付け方法ずトラフィックの管理方法に関するポリシヌを䜜成できたす。このタスクを制埡システムに割り圓おお、゚ンゞニアの䜜業をグラフィカルむンタヌフェむスのチェックマヌクの配眮に限定し、構成を自動的に適甚するこずもできたす。



しかし、いずれにしおも、これは䞀方ではヒュヌマンファクタヌを、他方ではデバッグずメンテナンスの単玔に理解できない耇雑さを損なうものではありたせん。



ただし、ロシアの事業者のネットワヌク䞊であっおも、管理グルヌプの耇雑な実装の堎合がありたす。



他のナヌスケヌスは、地域たたは囜のコヌドです。次に、地理的なトラフィックが通過する必芁があるものを蚭定するこずが可胜になりたす。



この芳点から、32ビットは非垞に小さいため、RFC 7308は拡匵管理グルヌプ、LSAの自然な制限、さらにはMTUによっお制限されるビット数を定矩しおいたす。



指の䞊の男はアフィニティを噛み、それを口の䞭で山に入れたす。



緎習する



ずおも短いです。動䜜を確認しおください。短い。Affinityを䜿甚するには、すべおのノヌドずすべおのむンタヌフェむスでAttribute-Flagを蚭定する必芁があるためです。正盎に蚀うず、これは私が少なくずも望んでいるこずです。







2぀のトンネルがある最埌の構成を続行したす。

構成ファむル。

Tunnel42は、パスR1-R2-R3-R4をたどりたす。圌ず遊ぶ。



デフォルトのAttribute-Flagは0x0です。したがっお、アフィニティず芋なしたす。぀たり、すべおのむンタヌフェむスは条件の察象ずなりたす。 Attribute-Flag 0x1を蚭定するR3-R4を陀きたす。平等が満たされないため、CSPFはこのリンクを通る最短パスを構築できたせん。 



 Linkmeup_R1(config) interface Tunnel4 Linkmeup_R1(config-if) tunnel mpls trafic-eng affinity 0x0 mask 0x1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     


 Linkmeup_R3(config) interface e0/0 Linkmeup_R3(config-if) mpls trafic-eng attribute-flags 0x1


そしお、このリンクをトンネルがどのように回ったかを芳察したす。







しかし、Tunnel4は安党に厩壊したした。デフォルトのアフィニティ倀も0x0ですが、マスクは0xFFFFです。したがっお、圌は再構成されたリンクR3-R4にも適合したせんでした。



しかし、マスク0x0を蚭定できたす-アフィニティビットず属性フラグビットを無芖したす。 



 Linkmeup_R1(config) interface Tunnel4 Linkmeup_R1(config-if) tunnel mpls trafic-eng affinity 0x0 mask 0x0


そしお、これらの制限を考慮せずにトンネルが䞊昇したす。



信頌性ず収束



実際には、故障が発生した堎合にトンネルを再構築するのに数秒かかるこずがすでにわかっおいたす。たあ、私の祖父の時点ではそれほど悪くはありたせん。



コンピュヌタネットワヌクの開発の党歎史は、䌑憩時間を短瞮するための、事故ずの戊い、収束速床の闘争の歎史です。

サヌビスには䜕がありたすか



  1. 物理的な保護。たずえば、APSからSONETたたはLAGからむヌサネット。
  2. IPはすべおの問題の解決策です。IGP、BGP、VRRPなど
  3. MPLSの䞀連のテクノロゞヌ。


もし進化がこの原理に基づいお人々を築いたなら、私たちはほずんど老幎期で死ぬだろう死者数の第二の理由は「自重で死んだ」だろう。

物理局の保護では、通垞、±50ミリ秒の収束時間が提䟛されたす。

IPは優れおいたすが、数秒たたは数分で収束したす。



MPLS TEは、安定性を高め、サヌビス䞭断時間を短瞮するための2぀のオプションを提䟛したす。









1぀目はLSPレベル党䜓で保護を実装し、2぀目はリンクたたはノヌドレベルで保護を実装したす-FRR-Fast ReRouteず呌ばれたす。



パス保護



トンネルを構成するずき、いく぀のLSPを構築するかを指定できたす。







  1. プラむマリは、トラフィックの送信に䜿甚されるプラむマリLSPです。
  2. Secondary — LSP . Ingress PE — .

    :



    • Standby — : LSP . . Hot-standby.

    • Non-standby — , LSP . LSP Ingress LSP RSVP-TE , . . Ordinary.

  3. Best Effort — , RSVP-TE - .


保護は、サヌビスの埩元だけでなく、この回埩の速床に぀いおも重芁です。



このように、明らかなこずは、非スタンバむがたったく圓おはたらないずいうこずです。IGPに䟝存しお、RSVP-TEは最初にルヌティング情報の曎新を埅機し、それから数秒でアカりント自䜓を解決する必芁がありたす。信号は、RSVP-TEたたはBFDからLSPがもう存圚しないずいう通知、たたはトポロゞ倉曎に関するIGPからの情報です。



スタンバむの堎合、プラむマリRSVP LSPずバックアップの䞡方が構築されたす。したがっお、Ingress LSRがメむンLSPのテンプレヌトの䞭断を怜出するずすぐに、トラフィックはすぐに予備のLSPに切り替わりたす。事故が蚘録される盎前に送信されたパケットを倱うリスクがあるだけです。



ロヌカル保護FRR



しかし、FRR -Fast Reroute-は、橋が厩壊したこずを疑うこずなく、すでに予玄のために努力しおいるそれらの車さえも保存するこずができたす。぀たり、FRRは修埩が実行されおいるルヌトのセクション䞊の迂回路のようなものであり、バックアップLSPは別のルヌトです。



FRRは回避策を䜿甚しおおり、RFC4090に蚘述されおいたす。事故怜出埌の平均切り替え時間は50ミリ秒です。



これは単にオンになり、自動的に機胜するものです。぀たり、構成に関しおは、基本的に芋えたす。



それが通垞起こるように、単にカスタマむズ可胜なものは、コヌトの䞋に面癜いものを隠したす。



したがっお、FRRには2぀の機胜がありたす。





したがっお、ロヌカル保護ず呌ばれたす。LSP党䜓を監芖するのではなく、最も近いリンクたたはホストの可甚性のみをチェックしたす。







ひどいこずが起こるず、圌は単にパケットをバむパストンネルに送りたす。







図aは、回線保護を瀺しおいたす。 On b-ノヌドの保護。

RSPをR1からR4に移動したす。 R4を陀くパスに沿った各ノヌドは、独自の回避策を構築しようずしたす。

したがっお、回線R1-R2を保護するR1は、パスR1-> R5-> R2を遞択したす。そしお、R2ノヌドの萜䞋から保護するためにR1-> R5-> R6-> R3。

R2は、R2-R3回線ずR3ノヌドを保護する必芁がありたす。

ITD。



甚語


PLR - ロヌカルのポむント修理 -消費ポむント。これは、回線たたはノヌドの保護を開始するノヌドです。入力PEたたは任意通過Pはなく、PEザ出口倚分

MP - マヌゞポむント -保護トンネルランド消倱点。通過Pたたは出力PE。ただし入力PEは陀く。

プラむマリLSPたたはLSP保護 - LSPを開始、保護を必芁ずしたす。

LSPバむパス - LSPを守りたす。

NHOP - ネクストホップ -プラむマリLSPでPLRノヌド以䞋。

NNHOP - ネクストホップ次に -ネクストホップの埌にそれぞれ次のノヌド。

リンク保護を始めたしょうか



FRRリンク保護



FRRのタスクは、倱敗したリンクの奈萜の底に盎接飛ぶバッグを保存し、このバむパスLSPに持ち蟌むこずです。



PLRは、トランゞットLSPが通過する回線が萜ちたこずに気づくず、即座にトラフィックをリダむレクトしたす。これを凊理するのはIngress PEではなく、ブレヌクが発生したノヌドであるこずに泚意しおください。リンクのフォヌルは、むンタヌフェヌスたたはBFDセッションのフォヌルによっお蚘録されたす。



FRRず鉄道線路の矢印を比范できたす。

パケットを非垞に高速に転送するには、バむパスLSPを事前に構築する必芁がありたす。これが起こるこずです。



プラむマリLSPの過皋の各ノヌドは、次のリンクのフォヌルずネクストホップのフォヌルをバむパスする方法を探したす。



぀たり、完党なLSP構築メカニズムを起動したす。



  1. MPぞのCSPFリンクドロップの堎合はNHOP、ノヌドドロップの堎合はNNHOP
  2. 予玄芁求ずずもに、蚈算されたパスに沿っおRSVP PATHを送信したす。
  3. バックアップが成功した堎合、RSVP RESVを受信したす。


トンネルは自動的に構築され、構成には衚瀺されたせん。ただし、残りは通垞のトンネルで、情報を衚瀺したりトレヌスしたりできたす。



, FRR Bypass-. , - .

. , .

, .



AutoTunnel, Primary LSP Bypass-.

Ingress LSR : 



 Router(config) mpls traffic-eng auto-tunnel backup


auto-tunnel , FRR-. .

次に、2぀の問題を解決する必芁があり

たす。プラむマリLSPからのパケットをこのバむパスLSPに入れる方法です。

-受け取った幞犏をどうするかをMPで理解する方法。



非垞に簡単です-FRR LSPは通垞のトンネルです。぀たり、以前のトンネルをPLRからMPにトンネルするだけで十分です。぀たり、各パケットに別のMPLSタグを远加したす。合蚈で3぀になりたすVPN、トンネル、FRR。







そのため、事故䞭にパケットがPLRに到着するず、最初に倖郚ラベルの通垞のSWAPを䜜成したす。これは、叀い珟圚砎損しおいるむンタヌフェむスから抜け出す必芁があり、FRRトンネルに転送する必芁があるこずも認識しおいるためです。ラベル。



次に、パケットは暙準ルヌルに埓っおバむパスLSPによっおスむッチングされたす。倖郚FRRラベルが倉曎され、2぀の内郚ラベルは倉曎されたせん。



最埌から2番目のノヌドでは、倖郚ラベルが削陀されたす-PHPおよびMPパッケヌゞが元の2぀に付属する前。

MPはパケットを受信し、トランスポヌトラベルを芋お、䜕も起こらなかったようにパケットを亀換したす。

これはすべお、グロヌバルラベルプヌルが䜿甚されおいる堎合にのみ機胜し、むンタヌフェむスに固有ではないこずが重芁です。したがっお、MPは、このラベルを持぀パケットがどのむンタヌフェヌスから来たかを考慮したせん。











FRRノヌド保護



トランスポヌトラベルを陀き、すべおがたったく同じです。PLRは、NNHOPが埅機しおいるラベルを認識しおいる必芁がありたす。



珟圚、トンネルは次のノヌドではなく、1぀NNHOPを経由しお構築されおいたす。RSVPメッセヌゞ属性であるLROLabel Request Objectがこれに圹立ちたす。RSVP PATHにいるず、ラベルを遞択する途䞭でノヌドに尋ねたす。



RSVP RESVラベルオブゞェクトには、これらの非垞に遞択されたラベルが含たれおいたす。















垯域幅保護



Bypass LSPをシグナリングするずき、問題が発生したすリ゜ヌスを予玄するかどうか。

その堎合、すでに垯域幅保護ず呌ばれおいたす。



この堎合、同じトンネルのリ゜ヌスを2回予玄するこずは通垞意味がありたせん。たあ、実際に-プラむマリからバむパスにトラフィックを取ったずいう事実から、リ゜ヌスがPLRずMPで2回䜿甚されるずいうこずにはなりたせんかたた、十分な空き垯域がない堎合もありたす。したがっお、SEShared Explicitの抂念が導入されおいたす。この属性が元のRSVP PATHで蚭定されおいる堎合、リ゜ヌスは2回予玄されたせん-䞭間ノヌドは、これが完党に独立したLSPではないこずを認識したす-この叀いLSPは䜕かにかかっおいたした。





そのため、手順は次のずおりです。



  1. トンネルを構成するずき、FRRずこのトンネルの属性セットが必芁であるこずを瀺したす。

    • — RSVP TE LSP — , NNHOP.
    • ( ).
    • SE — / .


  2. Ingress LSR Primary LSP.
  3. PLR Bypass LSP NHOP. :



    • LSR ID MP (NHOP NNHOP NHOP).
    • , MP FEC.
    • .
    • «», : SE .






    • Bypass LSP.
    • .


  4. PLR



    • , BFD .
    • , , BFD RSVP RSVP Hello.


  5. PLR . Ingress LSR :



    1. , MP.
    2. Bypass .
    3. Bypass LSP.


  6. Ingress PE RSVP — , LSP.
  7. Bypass LSP, Bypass LSP, Bypass ( PHP ).
  8. MP MPLS , , , , .
  9. , FRR .
  10. 切り替え埌、Ingres LSRはMake-Before-Breakメカニズムを䜿甚しおプラむマリLSPを垞に埩元しようずしたす。

    圌が成功するず、新しいLSPはModified LSPず呌ばれたす。

    MPは実際には䜕もしなかったこずに泚意しおください-最初はLSPの䜜成に参加しただけです-ある皮のバむパスLSPであるこずさえ知りたせんでした-圌にずっおは、RSVP TEからの定期的なリク゚ストでした。





FRRモヌド

FRRに぀いおただ議論する䟡倀がある唯䞀の質問は、どのLSPが実際にリダむレクトするのかずいうこずです。圌は䞀人ではありたせん、結局のずころ、圌はおそらくこのPLRを通過したすか



次の2぀のオプションがありたす。





最初のオプションは、リ゜ヌスをより合理的に䜿甚するため、望たしい方法です。ファシリティモヌドに぀いおは以䞊です。䞀察䞀

では、いく぀かの新しい甚語、

Detour LSP - spare tunnelが導入されおいたす。同じバックアップLSPですが、Detourは1぀のプラむマリLSP、

DMP - Detour Merge Point-同じMP のみを保護したす。



この方法はファシリティに非垞に䌌おいたすが、1぀の倧きな違いがありたす。ファシリティモヌドでは、既存のLSPはバむパスLSPにトンネリングされ、スタック䞊の3番目のラベルを受信したす。障害を回避する1察1モヌドでは、スタックに2぀のマヌクが残りたす。぀たり、最も䞀般的なLSPのように芋え、機胜したす。



PLRは、事故が怜出されるず、通垞のスワップトランスポヌトラベルを実行するだけで、叀いLSPの受信パケットを新しい方法で送信したす。しかし、ラベルず出力むンタヌフェむスは新しくなりたす-Detour LSPから。



DMPは通垞のSwapトランスポヌトラベルも実行したす。 Detour LSPタグの代わりに、プラむマリLSPの叀いタグを眮き換えお、さらに送信したす。









ファシリティモヌドが最も䞀般的に䜿甚されおいるため、詳现に芋おいきたした。



, FRR, .



, , , .



, Juniper, One-to-One Fast Reroute — . - FRR . link link-node protection Facility mode.



, Cisco One-to-One, FRR , MPLS- , . — - .



Cisco , LSP . 詳现



Huaweiに぀いお説明する堎合、デフォルトでは、ファシリティモヌドではPLRでトンネルを手動で構成したす。しかし、Auto-FRRモヌドがありたす-すべおが自動的に動䜜したす。



圌らが蚀うように、セルノァの奥に行くほど、ガりチョは意地悪です。



シスコ

ゞュニパヌ。

FRRに぀いお知る必芁があるのはそれだけです。







緎習する



すべおを同じネットワヌクで継続し、停止した瞬間からアフィニティを陀く。

構成ファむル。



パス保護


より䜎い垯域幅芁件のスタンバむLSPを远加したす3 Mb / s。 



 Linkmeup_R1(config) interface tunnel4 Linkmeup_R1(config-if) tunnel mpls traf path-option protect 1 dynamic bandwidth 3000


プリファレンス1はプラむマリLSPず同じである必芁があるこずに泚意しおください。







保護トンネルの経路は次のずおりでした。







たず、R1-R2回線では、5の4 Mb / sがすでにTunnel42によっお取埗されたした。したがっお、予備のLSP Tunnel4甚のレヌンは残っおいたせん。



第二に、プラむマリLSPおよびバックアップLSPは通垞、Shared ExplicitSE垯域予玄方匏を䜿甚したす。これは、同じトンネルに察しお垯域が2回予玄されないこずを意味したす。したがっお、10 Mb / sの埌、リンクR1〜R5はメむンLSP8 Mb / sずバックアップ3 Mb / sの䞡方を配眮できたした。



第䞉に、R6-R4セクションのプラむマリパスず同じパスを遞択したこずがわかりたす。したがっお、Explicit-pathの䜿甚が正圓化される堎合がありたす。



喜びず満足のために、R2-R5リンクを匕っ匵っお、加入者のトラフィックがほずんど䞭断されないようにするこずができたす。

珟圚の構成でpingが停止し、埩元されおいない堎合は、理由を理解しおください。



ロヌカル保護FRR


ただR2-R5リンクをプルしおいる堎合は、停止しおUp状態に戻しおください。

さらに、FRRを明確にするために、Path-Protectionを削陀する必芁がありたす。

構成ファむル

そのため、このTunnel4のFRRを構成したす。



1トンネルでFRRをオンにしたす 



 Linkmeup_R1(config) interface tunnel4 Linkmeup_R1(config-if) tunnel mpls traffic-eng fast-reroute


反察偎でこれを行うこずは論理的です。 



 Linkmeup_R4(config) interface tunnel1 Linkmeup_R4(config-if) tunnel mpls traffic-eng fast-reroute


この盎埌に、RSVPはLSPに沿っお新しい属性を通知し、







このLSPにはリンク保護が必芁であるず報告したした。



しかし、トンネルはただ珟れおいたせん。



2ここで、トンネルを自動的に構築する機胜を有効にする必芁がありたす。 



 Linkmeup_R1(config) mpls traffic-eng auto-tunnel backup


このチヌムは䜕をしたすかロヌカル保護を必芁ずするトンネルに䜿甚されおいるむンタヌフェむスをチェックし、リンクず次のノヌドを保護しようずするため、各ノヌド必芁な堎合に必芁なトンネルを構築したす。



たずえば、Linkmeup_R2には4がありたす。







  1. リンクを保護するためR2-> R6R2-> R5-> R6。





  2. ノヌドR6の萜䞋から保護するにはR2-> R6-> R3R2- > R3。





  3. リンクを保護するためR2-> R5R2-> R6-> R5





  4. ノヌドR5の萜䞋から保護するにはR2-> R5-> R1R2-> R1。







保護トンネルは、垯域幅を考慮せずに構築されるこずに泚意しおください。これに぀いおは、別途説明したす。







それで、R2-> R6の行を分割したす。

理論的には、この回線を保護するために、Tunnel65436R2-> R5-> R6がありたす。しかし、その埌の完党なパスは少し奇劙に芋えるでしょうR1-> R5-> R2-> R5 - > R6-R3-> R4 -すなわちR5-R2のトラフィックラむンは二回開催されたす-そこずバック。したがっお、R2は短時間むンテリゞェンスをオンにし、Tunnel65437を遞択したす。これは、R3に盎接぀ながりたす。



次に、R2-R3セクションで、スタックに2぀のタグVPNずトンネルが衚瀺されたす。 PHPのため、バむパスラベルは挿入されたせん。



必芁に応じお、3぀のラベルすべおを確認した埌、FRRが機胜しおいるこずを確認し、R2でコマンドを入力したす 



 Linkmeup_R2(config) mpls traffic-eng auto-tunnel backup nhop-only


圌女はR2にその非垞に奇劙な方法を䜿わせたす。



ここで泚意する必芁がありたす。私はそれに萜ちた。



実際には、FRRバむパストンネルから新しく構築されたプラむマリぞの切り替えに気付くような、実際のクレむゞヌなトラフィックはありたせん。



プラむマリLSPは、2぀のICMPリク゚スト間で回埩するこずに成功したず蚀いたいです。ダンプには、バむパスLSPではなく、再構築されたプラむマリLSPが衚瀺されたす。したがっお、3぀のラベルではなく、2぀のラベルが衚瀺されたす。



この困難なトレヌニング状況では、垯域幅が圹立ちたす-空き垯域幅が䞍足しおいるため、プラむマリLSPがR2-> R3回線を介しお再構築できなくなり、これを考慮に入れないLSPをバむパスできたす。



したがっお、バむパスからプラむマリぞの切り替えは行われず、長寿呜のバむパスを楜しむこずができたす。



VPNずトランスポヌトラベルを芋るR1











PUSH VPN-16

PUSH Tunnel-26



R5のラベルテヌブルを芋る







SWAP Tunnel 26-> 16



R2のFRRを芋る











SWAP Tunnel 16-> 27NHOPが埅機しおいるラベル

PUSH Bypass Implicit Null -぀たり、実際にはラベルを挿入したせん。



R3のタグ







PHPPOP Tunnel 27埅機。



サむトのダンプを芋おください-2タグ暗黙的なnullは実際には远加されたせんでした







いいね





そしお最埌に、緎習なしの簡単なトピックをいく぀か。



MPLS QoS



QoSトピックは別の問題に専念したす。 準備をしなさい。 しかし、今それに぀いお少しも話さないこずは蚱されないでしょう。



MPLS TE IntServ



そのため、MPLS TEはIntServ QoSパラダむム-途䞭でのリ゜ヌスの事前予玄を䜿甚したす。



぀たり、最初に必芁な垯域およびその他の芁件がサヌビスに提䟛されるず確信しおいたす。同時に、トンネルLSP内のパケットはすべお同じです。



ただし、これはクラむアントのトラフィックが増加しおいる堎合に発生したす。ある時点で、そのボリュヌムが静的に調敎されたしきい倀を超え、空き垯域がなくなっおいるか、自動垯域幅がただ速床の増加をうたく凊理できおいない可胜性がありたす。



䜕らかの方法-パケットは砎棄され始め、分析は行われたせん-それらが重芁かどうか。



぀たり、MPLS TEの実装におけるIntServのアむデアだけでは、個々のノヌドに問題がないこずを保蚌したせん。



MPLS TE DiffServ



たた、ホップ単䜍の動䜜の責任者は誰ですか思い出させお Diffservしかし、これら2぀の矎しいパラダむムを組み合わせるこずができたすか

実際、MPLSヘッダヌにはEXPフィヌルドがありたす。これはExperimentalによっお蚈画されたしたが、パケットの優先床を蚭定するために長い間公匏に䜿甚されおおり、トラフィッククラスず呌ばれたす。これは単なる叀い習慣であり、今埌はEXP

ず呌ばれたす。これはMPLS DiffServ察応トラフィック゚ンゞニアリング-MPLS DS-TEず呌ばれたす。



䞀般的に蚀えば、その考えは、元のパケットが期埅しおいたサヌビス品質をMPLSパケットに提䟛するこずです。぀たり、理想的には、1察1に察応する必芁がありたす。ただし、EXPは3ビット、぀たり8぀の優先床倀であり、DSCP-6ビット64倀-蚀うたでもなく、詳现はそのようなアヌカむブ䞭に倱われたす。

したがっお、2぀のアプロヌチがありたす

E-LSP - EXP-Inferred LSP。私たちが持っおいるものを獲埗しお楜しむために。

LSP-のL - ラベル-LSP掚枬されたす。EXP +ラベルで優先順䜍を゚ンコヌドしたす。



E-lsp


最初にDSCPフィヌルドを凊理する堎合、3぀の最䞊䜍巊DSCPビットのみをMPLS EXPに転送したす。

そしお、はい、詳现の損倱に我慢したす。



PDUがIngress LSRに到着したら、それをトンネルに入れ、EXPフィヌルドに優先順䜍を蚭定したす。

たずえば、1぀のトンネルで、ブロヌドバンドアクセスず固定電話からデヌタを送信したす。圓然、テレフォニヌに優先床5、その他すべおに0を指定したす。

その埌、1぀のトンネル内で茻茳が発生した堎合でも、最初に匱者が死にたす。



L-LSP


この堎合、QoSデヌタはラベル+ EXPで゚ンコヌドされたす。ラベルはキュヌ内の凊理メカニズムを定矩し、ラベルはパケットをドロップする優先順䜍を決定するず想定されおいたす。

PHB情報は、LSPのむンストヌル䞭に通知する必芁がありたす。

各L-LSPは、1぀のタむプのサヌビスのみを䌝送したす。



これたで、ほずんどのオペレヌタヌは、BE、AF、EF、CSの4぀のトラフィッククラスを定矩しおいたす。E-LSPはこれには十分すぎるため、L-LSPは実際には䜿甚されないだけでなく、すべおのベンダヌが実装しおいるわけではありたせん。したがっお、メ゜ッドの比范に぀いおも詳しく説明したせん。



QoSモヌド



しかし、興味深いのは、各ノヌドでどのようなCoSフィヌルドIP DSCP、トンネルEXP、たたはVPN EXPを信頌するかです。



次の3぀のモヌドがありたす。



  1. 均䞀モヌド
  2. パむプモヌド
  3. ショヌトパむプモヌド


MPLS L3VPNで TTLを解析するずきに、そのような抂念に既に遭遇しおいるこずを芚えおいたすかここで䌌たようなもの。



均䞀モヌド



これは、フラットな゚ンドツヌ゚ンドモデルです。







Ingress PEでは、IP DSCPを信頌し、MPLS EXPトンネルずVPNヘッダヌの䞡方の倀をコピヌ厳密には衚瀺ですが、簡単にするために「コピヌ」ず蚀いたすしたす。入力PEからの出力では、パケットはすでに䞊䜍MPLSヘッダヌのEXPフィヌルドの倀に埓っお凊理されおいたす。



各トランゞットPは、トップEXPに基づいおパケットも凊理したす。しかし同時に、オペレヌタヌが望むなら、圌はそれを倉えるこずができたす。



最埌から2番目のノヌドは、トランスポヌトラベルPHPを削陀し、EXP倀をVPNヘッダヌにコピヌしたす。䜕がそこにあったかは関係ありたせん-均䞀モヌドでは、コピヌが行われたす。



出力PEは、VPNラベルを削陀しお、EXP倀をIP DSCPにコピヌしたす他に䜕かが曞き蟌たれおいる堎合でも。



぀たり、トンネルヘッダヌのEXPラベルの倀が途䞭で倉曎された堎合、この倉曎はIPパケットに継承されたす。



パむプモヌド







入力PEでDSCP倀を信頌しないこずにした堎合、オペレヌタヌが必芁ずするEXP倀がMPLSヘッダヌに挿入されたす。



ただし、DSCPにあったものをコピヌするこずは蚱容されたす。たずえば、倀を再定矩できたす-EFたですべおをコピヌし、CS6ずCS7をEFにマップしたす。



各トランゞットPは、䞊䜍MPLSヘッダヌのEXPのみを調べたす。



最埌から2番目のノヌドは、トランスポヌトラベルPHPを削陀し、EXP倀をVPNヘッダヌにコピヌしたす。



出力PEは、最初にMPLSヘッダヌのEXPフィヌルドに基づいおパケットを凊理しおから、倀をDSCPにコピヌせずに削陀したす。



぀たり、MPLSヘッダヌのEXPフィヌルドに䜕が起こったずしおも、IP DSCPは倉曎されたせん。



このようなシナリオは、オペレヌタが独自のDiff-Servドメむンを持ち、クラむアントトラフィックが䜕らかの圢で圱響を䞎えたくない堎合に䜿甚できたす。



ショヌトパむプモヌド







このモヌドは、パむプモヌドのバリ゚ヌションず考えるこずができたす。唯䞀の違いは、MPLSネットワヌクの出口で、MPLS EXPではなく、IP DSCPフィヌルドに埓っおパケットが凊理されるこずです。



぀たり、出力でのパケットの優先床は、オペレヌタではなくクラむアントによっお決定されたす。

入力PEはIP DSCP着信パケットを信頌したせん。トランゞットPは、トップヘッダヌのEXPフィヌルドを調べたす。最埌から2番目のPは、トランスポヌトラベルを削陀し、倀をVPNラベルにコピヌしたす。

出力PEは、最初にMPLSラベルを削陀しおから、キュヌ内のパケットを凊理したす。cisco



からの説明。





トンネルの簡玠化



䞀般的なキャリアネットワヌクでは、自動怜出機胜ず専甚のBGPルヌトリフレクタヌを備えたBGPベヌスのL3 / L2VPNが、負荷をスケヌリングおよび削枛するために展開されおいたす。



LDP LSPがトランスポヌトずしお䜿甚される堎合、システムのMPLSトンネルは自動的に完党に接続されたトポロゞを圢成したす。



このような状況では、新しいPEを远加するには、この新しいPEずRRの構成のみが必芁です。



ただし、RSVP-TEトランスポヌトの堎合、状況はたったく異なりたす。倚くのPEノヌドがある堎合、必芁なルヌタヌのすべおのペア間でトンネルを構成するこずは頭痛の皮になりたす。



この構成䞊の狂気を回避する2぀のアプロヌチがありたす。





TEを介したLDP



このアプロヌチには新しい機胜は必芁ありたせん。階局が導入されたす-ネットワヌクの特定の固定コアでは、Pルヌタヌ間のTEトンネルの完党に接続されたシステムが立ち䞊がりたす。

これは䞀床行われ、倉曎されるこずはありたせん。

通垞のPEルヌタヌは、盞互にLDP LSPを構築したす。







ネットワヌクのコア内を移動するMPLSパケットのスタックには、VPN、LDP、RSVP-TEの3぀のラベルがありたす。

぀たり、RSDP LSPでトンネリングされおいるかのように、LDP LSPです。





サむトwww.nexthop.me からの図では、



これを呌び出したしょう。アクセスセグメントは䟿利で居心地の良いLDPであり、ネットワヌクのコアこれは長距離トランクでも可では、トラフィックを制埡するこずが可胜です。



RSVP自動メッシュ/自動トンネル



これは小さいですが、トンネルのチュヌニングを自動化するために非垞に䟿利な即興挔奏です。



新しいPEデバむスがTEDBに衚瀺されるずすぐに、順方向および逆方向のトンネルが即座に構築されたす。



どの構成が適甚されたすかトンネルむンタヌフェむス蚭定テンプレヌトは事前に䜜成されたす。

新しいノヌドがPEであるこずを確認する方法はACLはテンプレヌトで指定されおおり、䜜成できるナヌザヌを決定したす。



たずえば、PEノヌドのルヌプバック127むンタヌフェむスが10.127.127.0/24になるずいうルヌルにし、IGPでアナりンスしたす。



最も単玔な構成は次のようになりたす。



  1. 䜿い慣れたコマンドを䜿甚しお、メッシュモヌドで自動トンネルを有効にしたす。 



     Router(config) mpls traffic-eng auto-tunnel mesh


  2. ACLで朜圚的なPEを定矩したす。 



     Router(config) ip access-list standard 1 Router(config-std-nacl) permit source 10.127.127.0 0.0.0.255


  3. 構成テンプレヌトを取埗したす。 



     Router(config) interface auto-template 1 Router(config-if) ip unnumbered Loopback127 Router(config-if) tunnel mode mpls Router(config-if) tunnel mpls traffic-eng autoroute announce Router(config-if) tunnel mpls traffic-eng priority 4 4 Router(config-if) tunnel mpls traffic-eng auto-bw Router(config-if) tunnel mpls traffic-eng path-option 4 dynamic Router(config-if) tunnel destination access-list 1






おわりに



単䞀のフレヌズで芁玄したいず思いたす。この蚘事で説明したこずはすべお、実際、この䞖界で芋られるものであり、砂の城ではありたせん。

したがっお、簡単に繰り返したす。





MPLS TEは、ラベル割り圓おおよびリ゜ヌス予玄のプロトコルずしおRSVP-TEを䜿甚したす。そしお、それは順番にLS IGPに基づいおいたす







RSVP LSPの構築方法は、次の方法で制埡できたす。







IGPは、以䞋に関するTEDB情報を広め、蚘録したす。





最短ルヌトを蚈算する堎合、CSPFはTEトンネル蚭定から芁件を取埗し、TEDBから制限を取埗したす。



トンネルの芁件







メッセヌゞ内のRSVP-TEは次を送信したす。







次の2぀の䞻な方法で、トンネルにトラフィックを誘導できたす。







Make-Before-Break



これはMPLS TEで広く䜿甚されおいる抂念です-最初に入手しおくださいすでに機胜しおいるものを壊す前に、新しいLSPを構築したす。



次の堎合に適甚されたす。







共有明瀺的フィルタヌたたは固定フィルタヌ



MBBの抂念ず密接に関連しおいたす。



Shared ExplicitSE-1぀のトンネルの2぀の異なる予玄LSPは接続されおいるず芋なされ、リンスバヌは2回予玄されたせん。



固定フィルタヌFF-同じ送信者からのさたざたなLSPは垞に独立しおいるず芋なされ、それらの垯域は個別に予玄されたす。



SEモヌドはMBBメカニズムでは非垞に䟿利です。FFモヌドでは、倚くの堎合、FRRおよび再最適化機胜が完党に無効になりたす。





トンネル保護







トンネルの優先床



各トンネルには2぀の意味がありたす。





通垞、それらは同等です。

0が最高、7が最䜎です。

蚭定優先床が高いトンネルは、保留優先床が䜎いむンストヌル枈みトンネルに取っお代わりたす。





構成の簡玠化メカニズム







MPLS DS-TEのCoSフィヌルドを凊理するためのルヌル







䟿利なリンク





誰かが蚀うSDSMはたすたす奇劙になっおいたす。あなたは珟実から脱华したす。

そしお、それは間違っおいたす。次回は、燃えおいるトピック-QoSに戻りたす。埅望の、有望な、そしおどのように耇雑な、ちょうど圹に立たない。

140kキャラクタヌのゎミや無駄もありたすが、毎日の䜜業内容に぀いおです。

たた、ネットワヌクに関する最高の本のリストがここにあるこずを思い出させおください。

この蚘事で䜿甚されおいるすべおの略語は、linkmeup甚語集に蚘茉されおいたす。



謝蟞

Andrey Glazkov、Alexander Clipper、およびAlexander Fatinによる校正資料およびコメント。むラストは

Artyom Chernobay。

私の劻ず子䟛たちは苊劎したが、MPLSトピックを閉じるこずを蚱可された。



SDSMのすべおの問題...
12.最もベテランのネットワヌク。パヌト12。MPLS L2VPN

11.1。 最小のネットワヌク。 №6. MPLS L3VPN

11. . . MPLS L3VPN

10. . . MPLS

9. . .

8.1 . №3. IBGP

8. . パヌト゚むト。 BGPおよびIP SLA

7. . . VPN

6. . .

5. : . NAT ACL

4. : . STP

3. : .

2. . パヌト2

1. . . cisco

0. . . 蚈画䞭



More articles:


All Articles