最小のネットワヌク。 パヌト10。 基本的なMPLS

架空の䌚瀟linkmeupのネットワヌクは成長しおいたす。 圌女はすでにさたざたな郜垂に幹線、顧客ベヌス、SDSMサむクルで育った優秀な゚ンゞニアスタッフを抱えおいたす。

しかし、それだけでは十分ではありたせん。 ブロヌドバンドサヌビスは適切で必芁ですが、VPNを必芁ずする䌁業クラむアントにずっおはただ倧きな朜圚垂堎がありたす。

みんなはそれに぀いお考え、困惑し、MPLSなしではできないずいう結論に達したした。



マルチキャストがIPネットワヌクの理解の再構築を必芁ずする最初のトピックであった堎合、MPLSを孊習するずき、以前に知っおいたほずんどすべおを忘れる必芁がありたす-これは独自のルヌルを持぀特別な䞖界です。







今日の問題





そしお、「IPの䜕が問題なのですか」ずいう質問から始めたす。









埓来のビデオ



そしお本圓に、䜕が悪いのでしょうか MPLSをフェンスする理由



はい、そうです。 IPの長所ず短所は、IPが埓来のネットワヌクよりも遅く登堎し、非垞に柔軟であるずいう事実に起因しおいたす。 今日では、ネットワヌクレベルのIPに基づいたあらゆる堎所でのパケットスむッチングぞの移行があり、チャネルむヌサネットはたすたす人気を集めおいたす。

1぀のバックボヌンネットワヌクずアクセスネットワヌクに基づいお、 ブロヌドバンドアクセス 、IPテレフォニヌ、IPTV、およびその他の可胜なサヌビスを提䟛できるため、これは良いこずです。

同じこずが携垯電話䌚瀟のネットワヌクでも芋られたす。 倜明けの第二䞖代ネットワヌクは完党に回線亀換に基づいおいた。 ほずんどの堎合、3Gネットワ​​ヌクのコアはすでにIPですが、回線亀換モヌドでも電話サヌビスを提䟛できたす。 4Gネットワ​​ヌクはすでに本栌的なIPネットワヌクであり、音声䌝送はブロヌドバンドアクセスず同様にアプリケヌションの1぀にすぎたせん。



ただし、叀い技術が䜿甚されおいるセグメントはただ倚数ありたす。 たずえば、ATMのある堎所では、別の堎所でネットワヌクのある郚分から別の郚分にPDHを転送する必芁があり、クラむアントは自分のむヌサネットネットワヌクが盎接接続されおいるかのように、぀たりVPNのように郜垂の反察偎からアクセスできるこずを望んでいたした。

以前に決定されたように、2぀の地理的ポむント間にATMが必芁です-ATM、PDHに基づいおそれらの間にチャネルを構築したす-PDHを構築したす。

ただし、これらすべおを1぀のネットワヌクを介しお行い、トラフィックのタむプごずに個別のネットワヌクを構築する必芁はありたせん。

このために、圓時、GRE、PPPoE、PPPoA、ATM over Ethernet、TDM over IP、および他の倚くのものが発明されたした。 すでにすべおの組み合わせをカバヌするためにさらに1000個を䜜成できたす。そしお、暙準の混乱の䞭で普遍的な幞犏がもたらされたす ちなみに、いく぀かの小さなメヌカヌがこの道を遞んでいたす 。



90幎代半ばに、いく぀かの䌁業IBM、東芝、シスコ、むプシロンのホットヘッドが発生し、ルヌティング䞭にパケットの内郚を芋ずに、より良い方法を求めおルヌティングテヌブルをくたなく特定のラベルでナビゲヌトできるメカニズムを䜜成したした。 シスコで撮圱された、メカニズムはプレヌンず名付けられたしたTAGスむッチング。

さらに、開発者が远求した目暙は、高速スむッチがハヌドりェアのみでトラフィックを送信できるようにするこずでした。 実際、ハヌドりェアIPルヌティングは長い間アクセスできなかった喜びであり、䜎コストのスむッチで䜿甚するこずは非実甚的であり、ラベルに基づいお決定するこずは簡単か぀迅速です。

しかし同時に、超倧芏暡集積回路が登堎したしたがこの甚語には同意したせんが、英語のVLSIは本質をはるかによく説明しおいたす、パッケヌゞの内容の分析を節玄するタスクはそれほど急にはなりたせんでした。 さらに、FIBの抂念が登堎したした。これは、各パケットに぀いお、ルヌティングテヌブルで宛先を怜玢する必芁がなく、それに応じお䞭倮プロセッサが関䞎するこずを瀺唆しおいたす。すべおのホット情報はすでにラむンカヌド䞊にありたす。

぀たり、実際には、このようなメカニズムの必芁性はなくなりたした。



しかし、 突然 、ラベルスむッチングには蚈画倖の可胜性があるこずが明らかになりたした-IP、むヌサネット、ATM、フレヌムリレヌなど、ラベルの䞋にあるものは関係ありたせん。 たた、IPルヌティングの制限を取り陀くこずができたす。

これは、IETF承認のMPLS-MultiProtocol Label Switchingテクノロゞヌの起源です。 1997幎でした。

そしお、この䞀芋取るに足りない詳现が、電気通信の新しい時代を生み出したした。 珟圚、MPLSは倚かれ少なかれ倧芏暡なプロバむダヌにありたす。



珟圚MPLSの䞻なアプリケヌション





それぞれに぀いお個別の蚘事で説明したす-これらは非垞に倧きなトピックです。 ただし、蚘事の最埌で簡単に觊れたす。





MPLS



玔粋なMPLSのみが䜿甚されるこずはほずんどありたせん。 FIBの衚瀺/ヘッダヌの䞀郚のフィヌルドの倉曎ずラベルのテヌブルの衚瀺/ MPLSヘッダヌのラベルの倉曎の違いはそれほど倧きくないため、パフォヌマンスの向䞊はわずかです。 もちろん、䞊蚘のアプリケヌションが䜿甚されたす。

ただし、この蚘事では、最も基本的な圢匏での動䜜を理解するために、玔粋なMPLSに焊点を圓おおいたす。

以䞋では 、玔粋なMPLSの1぀のアプリケヌションも怜蚎したす。



MPLSは、それが動䜜するネットワヌクのタむプに結び付けられおいないずいう事実にもかかわらず、珟圚ではIPずのみ共生しおいたす。 ぀たり、ネットワヌク自䜓はIP䞊に構築されたすが、同時に他の倚くのプロトコルからデヌタを転送できたす。

しかし、すでにポむントに行きたしょう。最初に、 MPLSはIPルヌティングに代わるものではなく 、その䞊で動䜜するこずを述べたいず思いたす。



具䜓的には、このようなネットワヌクを取り䞊げたす。







珟圚は完党な動䜜状態ですが、MPLSのヒントはありたせん。 ぀たり、たずえば、R1はR6を認識し、そのルヌプバックをpingできたす。

PC1はICMP芁求をサヌバヌ172.16.0.2に送信したす。 ICMP芁求はIPパケットです。 R1では、基本原則に埓っお、パケットはR2のFE0 / 0むンタヌフェむスを通過したす-ルヌティングテヌブルはそう述べおいたす。

パケットを受信した埌、R2は宛先アドレスをチェックし、そのFIBを調べ、次のルヌタヌを芋぀けお、パケットをFE0 / 0むンタヌフェむスに送信したす。

そしお、このプロセスは䜕床も繰り返されたす。 各ルヌタヌは、パケットの運呜を独自に決定したす。



これは、トラフィックダンプが非垞によく芋える方法です。







MPLSをアクティブにするずどうなりたすか すぐに、その瞬間に䞖界は倉わりたす。 その埌、ラベルテヌブルがルヌタヌに入力され、耇数のLSPが構築されたす。



そしお今、同じパスが少し異なっお行われたす。







PC1からのIPパケットがMPLSネットワヌクに入るず、最初のルヌタヌがラベルを切断し、このパケットが宛先に送られ、埌続の各ルヌタヌがラベルを別のものに倉曎したす。 MPLSネットワヌクを終了するず、ラベルは削陀され、クリヌンIPパケットが最初に送信されたように送信されたす。



これがMPLSの基本原則です。ルヌタヌは、MPLSパケットの内郚を芋るこずなくラベルによっおパケットを切り替えたす。 最初のものは远加し、最埌のものは削陀したす。



PC1から宛先ノヌドぞのデヌタパケットの段階的な転送を芋おみたしょう。



1. PC1-通垞のコンピュヌタヌ-通垞のパケットをリモヌトサヌバヌに送信したす。



2.パッケヌゞがR1に届きたす。 18のラベルを远加したす。IPヘッダヌずむヌサネットの間に挿入されたす。

圌はFIBからこの情報を取埗できたす。







FIBは、宛先6.6.6.6のパケットに18のラベルを付け、 FE0 / 0むンタヌフェむスに送信する必芁があるこずを瀺しおいたす。

実際、圌はこれを行いたす。圌は芋出しを远加し、18を曞き蟌みたす。





R1ずR2の間のダンプ 。



3. R2はこのパケットを受信し、むヌサネットヘッダヌでMPLSパケットEthertype 8847であるこずを確認し、ラベルを読み取り、そのラベルテヌブルを参照したす。











MPLSパケットにラベル18が付いおいた堎合、20に倉曎し、FE0 / 0むンタヌフェむスにパケットを送信する必芁がありたす。





R2の埌にダンプしたす。



4. R5は同様のアクションを実行したす。ラベル20のパケットが到着したこずを確認し、0に倉曎しおFE1 / 0に送信する必芁がありたす。 ルヌティングテヌブルぞの参照なし。



5. MPLSパケットを受信したR6は、ラベルをチェック解陀する必芁があるこずをテヌブルで確認したす。 それを削陀するず、圌はすでにパケットの宛先-172.16.0.2-が盎接接続されたネットワヌクであるこずを確認したした。 さらに、パケットはラベルなしでルヌティングテヌブルに沿っお通垞の方法で送信されたす。



぀たり、プロセス党䜓は次のようになりたす。




スキヌムを耇雑にしないために、゚ンドノヌドは考慮したせん。



これたでのずころ、すべおが単玔なように芋えたすが、理由は明らかではありたせん。



珟圚、IGPずMPLSドメむンは䞀臎しおおり、MPLSは将来、L2VPN、L3VPN、MPLS TEの利点のみを玄束したす。

しかし、実際、私たちがプロバむダヌであるこずを思い出すず、基本的なMPLSでも利点がありたす。

プロバむダヌずしお、AS間のルヌティングにIGPプロトコルを䜿甚したせん。 このために、BGPを䜿甚したす。 たた、MPLSの利点が明らかになるのは、BGPず連動しおいたす。

ネットワヌクを近隣ASず組み合わせお怜蚎しおください。







BGPリリヌスから、ASの各ルヌタヌでBGPを構成する必芁があるこずがわかりたす。 そうしないず、ASを介しお近隣のASおよびお客様にトラフィックを送信できなくなりたす。 各ルヌタヌはすべおのルヌトを知っおいる必芁がありたす。



しかし、それはMPLSの前でした

ネットワヌクでMPLSを構成するず、ネットワヌク内の各ルヌタヌでBGPを構成する必芁がなくなりたす。 ASの境界ルヌタヌ、他のクラむアントたたはプロバむダヌに接続されおいる境界ルヌタヌでのみ構成するだけで十分です。







しかし、これはすべおの良いニュヌスではありたせん。 AS内のすべおのルヌタヌでBGPを構成できないずいう事実に加えお、ルヌタヌは各BGPプレフィックスのラベルを䜜成する必芁もありたせん。 ネクストホップずしおリストされおいるIPアドレスに到達する方法を知るだけで十分です。 ぀たり、BoopセッションがLoopback0 R1ずLoopback0 R6の間に蚭定されおいる堎合、それぞれがBGPを介しお数十䞇のルヌトを送信しおも、ラベルテヌブルでは䜕も倉曎されたせん。



たずえば、BGPを介したルヌタヌR1は、ルヌタヌR6からいく぀かのルヌトを受信したした。





ネットワヌク100.0.0.0/16に向かうパケットがどのように凊理されるかを芋おみたしょう。





䞊蚘の出力は、パッケヌゞにラベル27が远加されるこずを瀺しおいたす。

たた、ラベルテヌブルを芋るず、BGPが認識しおいるルヌトのラベルはありたせんが、ラベル27があり、6.6.6.6 / 32に察応しおいたす。 そしお、これは、R6からBGP経由で到達したルヌトで芋たアドレスです。





以䞋に蚭定の䟋を瀺したす 。



少し先を走りたしたが、基本的なMPLSが提䟛する利点が明らかになったので、MPLSの䞖界の抂念的な装眮に突入するこずができたす。





甚語



ラベル -ラベル-0〜1,048,575の倀。これに基づいお、LSRはパケットをどう凊理するかを決定したす。どの新しいラベルをハングさせるか、どこに送るかです。

これはMPLSヘッダヌの䞀郚です。



ラベルスタック -タグのスタック。 各パッケヌゞには、1぀、2぀、3぀、少なくずも10個のタグを重ねお運ぶこずができたす。 パッケヌゞをどうするかは、トップラベルに基づいお決定されたす。 各レむダヌはいく぀かの圹割を果たしたす。

たずえば、パケットを送信する堎合、トランスポヌトラベル、぀たり最初から最埌のMPLSルヌタヌぞのトランゞットを線成するラベルが䜿甚されたす。

他の人は、このパケットが特定のVPNに属しおいるずいう情報を䌝える堎合がありたす。

この問題では、垞に1぀のラベルのみが存圚したす。これ以䞊は必芁ありたせん。



プッシュラベル -ラベルをデヌタパケットに远加する操䜜-は、MPLSネットワヌクの最初のルヌタヌこの䟋ではR1で最初に実行されたす。



スワップラベル -ラベル眮換操䜜-MPLSネットワヌクの䞭間ルヌタヌで発生-ノヌドは1぀のラベルを持぀パケットを受信し、それを倉曎しお別のラベルR2、R5から送信したす。



ポップラベル -ラベル削陀操䜜-最埌のルヌタヌによっお実行-ノヌドはMPLSパケットを受信し、 トップラベルを削陀しおからR6に枡したす。



実際、ラベルはMPLSネットワヌク内のどこでも远加および削陀できたす。

それはすべお特定のサヌビスに䟝存したす。 ラベルはパスの最初のルヌタヌLSPによっお远加され、最埌のルヌタヌによっお削陀されるず蚀う方が正しいでしょう。

ただし、この蚘事では、簡単にするために、MPLSネットワヌクの境界に぀いお説明したす。

たた、トップラベルを削陀しおも、ラベルスタックに到達した堎合に玔粋なIPパケットが残るこずを意味したせん。 ぀たり、3぀のラベルを持぀パッケヌゞでラベルのポップ操䜜が実行された堎合、2぀のラベルが残り、MPLSずしお凊理されたす。 そしお、この䟋では1぀ありたしたが、その埌は1぀ではありたせん。これはすでにIPの問題です。





LSR- ラベルスむッチルヌタヌは、MPLSネットワヌク内の任意のルヌタヌです。 タグを䜿甚しおいく぀かの操䜜を実行するため、そのように呌ばれたす。 この䟋では、これらはすべおノヌドR1、R2、R3、R4、R5、R6です。

LSRは3぀のタむプに分けられたす

侭間LSR -MPLS䞭間ルヌタヌ-スワップラベルR2、R5操䜜を実行したす。

入力LSR- 「入力」、最初のMPLSルヌタヌ-プッシュラベルR1操䜜を実行したす。

出力LSR- 「出力」、最埌のMPLSルヌタヌ-操䜜Pop LabelR6を実行したす。

LER- ラベル゚ッゞルヌタヌは、MPLSネットワヌクの゚ッゞにあるルヌタヌです。

特に、入力LSRず出力LSRは境界です。぀たり、これらもLERです。



LSP- ラベルスむッチングパス -ラベルスむッチングパス。 これは、入力LSRから出力LSRぞの単方向チャネル、぀たり、パケットが実際にMPLSネットワヌクを通過するパスです。 ぀たり、LSRシヌケンスです。

LSP は実際には単方向であるこずを理解するこずが重芁です。 これは、第䞀に、それに沿ったトラフィックが䞀方向にのみ送信されるこずを意味したす。第二に、「ある」堎合は必ずしも「戻る」ずは限らず、第䞉に、「戻る」は必ずしも同じ経路をたどらない、それは「そこに行きたす。」 たあ、それはGREのトンネルむンタヌフェヌスのようなものです。



LSPはどのように芋えたすか







はい、衚珟できたせん。

これは、4぀のLSRR1、R2、R5、R6からのコンパむル枈み出力です。 ぀たり、LSRでは、BGPの属性AS-PATHずしお、゚ントリから終了たでのノヌドの完党なシヌケンスは衚瀺されたせん。 ここでは、各ノヌドは入力ラベルず出力ラベルのみを知っおいたす。 しかし、LSPは存圚したす。



これは、IPルヌティングに少し䌌おいたす。 ポむントAからポむントBぞのパスがあるずいう事実にもかかわらず、ルヌティングテヌブルはトラフィックが送信される次のノヌドのみを知っおいたす。 しかし、違いは、LSRは宛先アドレスに基づいお各パケットを決定しないこずです。パスは事前に決定されおいたす。



察凊する最も重芁な抂念の1぀は、 FEC 転送等䟡クラスです。 なんらかの理由で、それは非垞に䞀生懞呜に䞎えられたしたが、実際には-すべおが単玔です。 FECはトラフィッククラスです。 最も単玔なケヌスでは、クラス識別子は宛先アドレスのプレフィックス倧たかに蚀うず、宛先IPアドレスたたはサブネットです。

たずえば、異なるクラむアントおよび異なるアプリケヌションからのトラフィックフロヌがあり、それらはすべお同じアドレスに送られたす。これらのフロヌはすべお1぀のクラスに属し、1぀のFECが1぀のLSPを䜿甚したす。

他のクラむアントおよびアプリケヌションから別の宛先アドレスに他のストリヌムを取埗する堎合、それぞれ異なるクラスおよび異なるLSPになりたす。



理論的には、FECは宛先アドレスに加えお、たずえばQoSラベル、送信元アドレス、VPN識別子、たたはアプリケヌションタむプを考慮するこずができたす。 ここで、同じFECからのパケットが同じ宛先アドレスに移動する必芁がないこずを理解するこずが重芁です。 同時に、2぀のパケットが1぀の堎所に続いおも、必ずしも1぀のFECに属するわけではありたせん。



これがすべお必芁な理由を説明したす。 実際には、各FECに察しお、独自のLSPが遞択されたす-MPLSネットワヌクを通る独自のパスです。 そしお、たずえば、WEBサヌフィンの堎合、QoS BEの優先順䜍を蚭定したす。これは1぀のFECになり、VoIPの堎合はEF-別のFECになりたす。 さらに、FEC BE LSPは広く、しかし長く、保蚌されおいない方法で進むべきであり、FEC EFでは狭いが高速であるこずが指摘できる。



残念ながら、幞いなこずに、IPプレフィックスのみがFECずしお機胜できたす。 QoSマヌキングなどは考慮されたせん。





ラベルテヌブルに泚意を払うず、ラベル眮換パラメヌタがFECに基づいお正確に決定されるため、そこにFECが存圚したすが、これはこれらのラベルが配垃される最初の瞬間にのみ行われたす。 実際のトラフィックがLSPで実行されるず、Ingress LSR以倖は誰もそれを芋たせん。ラベルずむンタヌフェヌスのみです。 入力LSRは、FECずトラフィックを送信するLSPの決定に関するすべおの䜜業を行いたす。クリヌンパケットを受信した埌、それを分析し、所属するクラスをチェックしお、適切なラベルをハングさせたす。 異なるFECのパケットは異なるラベルを受信し、察応するむンタヌフェむスに送信されたす。

同じFECのパケットは同じラベルを受け取りたす。



぀たり、䞭間LSRは、すべおの通過トラフィックに察しおラベルが切り替えるこずのみを行う脱穀機です。 そしお、知的䜜業はすべおIngress LSRによっお行われたす。



LIB- ラベル情報ベヌス -ラベルテヌブル。 IPのルヌティングテヌブルRIBの類䌌物。 各入力ラベルに぀いお、パッケヌゞの凊理方法を瀺したす。ラベルを倉曎たたは削陀し、送信するむンタヌフェむスを指定したす。

LFIB- ラベル転送情報ベヌス -FIBず同様-は、ネットワヌクプロセッサがアクセスするラベルベヌスです。 新しいパッケヌゞを受け取ったら、CPUにアクセスしおラベルテヌブルを怜玢する必芁はありたせん。すべお手元にありたす。






MPLSの最初のアむデアの1぀である、コントロヌルプレヌンずデヌタプレヌンを可胜な限り砎壊するこずは、忘华になりたした。

開発者は、ルヌタヌを介しおパケットを送信する際に分析を行わないこずを望んでいたした。ラベルを読み取っお別のラベルに倉曎し、目的のむンタヌフェヌスに枡すだけです。

これを実珟するために、2぀の別個のプロセスがありたした。比范的長いパスの構築コントロヌルプレヌンず、このパスに沿ったトラフィックの高速䌝送デヌタプレヌンです。



しかし、安䟡なチップASIC、FPGAずFIBメカニズムの出珟により、通垞のIP転送も迅速か぀簡単になりたした。

ルヌタヌの堎合、パケットを送信するずきにFIBたたはLFIBのどこを芋るかは関係ありたせん。

しかし、間違いなく重芁で有甚なのは、MPLSがその芋出しの䞋で送信されるものIP、むヌサネット、ATMを気にしないこずです。 GREやその他の䞍快なVPNを関節痛に保護する必芁はありたせん。 しかし、これに぀いおもう䞀床話したしょう。



MPLSヘッダヌ



MPLSヘッダヌ党䜓は32ビットです。 フィヌルドの圢匏ずその長さは固定されおいたす。 倚くの堎合、タむトル党䜓がラベルず呌ばれたすが、これは完党に真実ではありたせん。







ラベル -ラベル自䜓。 長さは20ビットです。

TC-トラフィッククラス。 IPのDSCPフィヌルドのように、パケットの優先床を䌝えたす。

長さは3ビットです。 ぀たり、8぀の異なる倀を゚ンコヌドできたす。

たずえば、MPLSネットワヌクを介しおIPパケットを送信する堎合、DSCPフィヌルドの倀は特定の方法でTC倀に関連付けられたす。 したがっお、パケットは、玔粋なIPセクションずMPLSの䞡方で、パス党䜓に沿ったキュヌでほが均等に凊理できたす。

しかし、もちろん、この非可逆倉換-6 DSCPビットはTCの3ビットでタむトです64察8。したがっお、範囲党䜓が1぀の倀である特別な察応衚がありたす。

圓初、このフィヌルドはEXP実隓的ず呌ばれおいたしたが、その内容は芏制されおいたせんでした。 研究、新機胜の導入に䜿甚できるず想定されおいたした。 しかし、これは過去のものです。

このフィヌルドは実隓的であり、QoS機胜に぀いお正匏に承認されおいないず誰かが䞻匵した堎合、圌は 人生の裏偎でたずもなこずをしたせん 。





=======================

タスク番号1



単玔なQoSポリシヌがネットワヌク䞊で構成され、ホスト10.0.17.7からアドレス6.6.6.6に向かうIPパケットがマヌクされ、MPLSネットワヌクを介しお送信されたす。 EXP, 3.









R6 QoS, EXP.

, , R6 . , , EXP 3 class default.



: , R6 .



R7 . MPLS R7 R1 .



.

=====================





S-スタックの䞋郚-ラベルスタックの䞋郚のむンゞケヌタは1ビット長です。パケットには耇数のMPLSヘッダヌが存圚する堎合がありたす。たずえば、MPLSネットワヌクでのスむッチング甚の倖郚、および内郚は特定のVPNを瀺したす。 LSRが䜕を扱っおいるのかを理解させるため。 Sマヌクが最埌のマヌクスタックの最䞋郚に到達の堎合、Sビットに「1」が曞き蟌たれ、スタックに耇数のマヌクただ最䞋郚ではないが含たれる堎合、「0」が曞き蟌たれたす。぀たり、LSRはスタック䞊にあるラベルの合蚈数を知りたせんが、それが1぀以䞊かどうかは知っおおり、実際にはこれで十分です。結局のずころ、䞋にあるものに関係なく、最䞊䜍のラベルのみに基づいお決定が䞋されたす。しかし、ラベルを取り陀いお、圌はすでにパッケヌゞで次に䜕をすべきかを知っおいたす。MPLSプロセスを匕き続き䜿甚するか、他のプロセスIP、むヌサネット、ATM、FRなどに枡したす。



: “, , , ” — . MPLS, , ( Ethertype Ethernet' Protocol IP).

— — , , , ?

— , , , , — IP Ethernet -. . , Pop Label, ( ) , .









䞀般に、ここでの叀兞的な意味でのスタックは、最埌に配眮され、最初に取埗されたすLIFO-最埌の入力-最初の出力。



その結果、MPLSヘッダヌの長さが固定されおいるずいう事実にもかかわらず、倚くのヘッダヌ自䜓が存圚する可胜性があり、それらはすべお次々に配眮されたす。



TTL -Time To Live- IP TTLの完党な察応物。同じ長さでも-8ビットです。唯䞀のタスクは、ルヌプが発生した堎合にパケットがネットワヌク䞊を無限にさたようこずを防ぐこずです。 MPLSネットワヌクを介しおIPパケットを送信する堎合、IP TTL倀をMPLS TTLにコピヌしおから戻すこずができたす。たたは、カりントダりンは255から再び開始され、クリヌンなIPネットワヌクに入るず、IP TTL倀は入力する前ず同じになりたす。






ご芧のずおり、MPLSヘッダヌは、デヌタリンク局ず、それが運ぶデヌタIPの堎合はネットワヌクの間で圧瞮されたす。したがっお、比phor的に、MPLSは技術レベル2.5ず呌ばれ、芋出し-Shim-header-heading-wedgeず呌ばれたす。

ずころで、ラベルはMPLSヘッダヌにある必芁はありたせん。IETFによるず、ATM、AAL5、フレヌムリレヌヘッダヌに埋め蟌むこずができたす。





これは人生でどのように芋えるかです







ラベルスペヌス



䞊蚘のように、2 ^ 20個のタグが存圚できたす。



これらのうち、いく぀かが予玄されおいたす



0IPv4明瀺的NULLラベル。 「明瀺的な空癜ラベル。」ラベルテヌブルより正確にはLFIBを芋なくおもこのマヌク0を削陀できるこずを通知するために、最埌のMPLSスパン出力LSRの前で䜿甚されたす。

ロヌカル盎接接続で発信されたFECの堎合、出力LSRは0マヌクを遞択し、それを近隣の最埌から2番目のLSR最埌から2番目のLSRに枡したす。

デヌタパケットを送信するずき、最埌から2番目のLSRは珟圚のラベルを0に倉曎したす。

出力LSRはパケットを受信するず、トップラベルを単に削陀する必芁があるこずを確認したす。



. , 0 , LSR MPLS .

- , , .

0 () Pop Label , .





1ルヌタヌアラヌトラベルIPのルヌタヌアラヌトオプションに類䌌は、スタックの最䞋郚を陀く任意の堎所に配眮できたす。パケットは、ラベルが付属しおいた堎合、それはロヌカルナニットに匕き枡されなければならない、ず圌は䜎かったラベル、に応じお切り替え-再びラベル1に远加する必芁があり、スタックの最䞊䜍で、実際の亀通



2IPv6の明瀺的な文のNULLラベル -同じ0ずしお、IPプロトコルバヌゞョンに察しおのみ調敎されたす。



3暗黙のヌル。 MPLSパケットを出力LSRに送信するプロセスを最適化するために䜿甚されるダミヌラベル。このラベルはアドバタむズできたすが、実際にはMPLSヘッダヌで䜿甚されるこずはありたせん。埌で怜蚎しおください。



4-15予玄枈み。



ベンダヌによっおは、他のラベル倀を固定できたす。たずえば、Huawei機噚では、静的LSPにタグ16〜1023が䜿甚され、動的LSPの堎合はそれ以䞊のものが䜿甚されたす。シスコでは、利甚可胜なタグは16日から始たりたす。



======================

タスクNo. 2



次の図では、R5を陀くすべおのルヌタヌがHuaweiルヌタヌです。R5-シスコ。



スキヌム






以䞋のR5ルヌタヌ構成の堎合、ラベル倀の分垃がHuaweiず䞀臎するように構成する必芁がありたす。問題は、Huaweiの動的タグは1024から始たり、Ciscoでは16から始たるずいうこずです。



R5の構成
ip cef ! interface Loopback0 ip address 5.5.5.5 255.255.255.255 ip router isis ! interface FastEthernet0/0 description to R4 ip address 10.0.45.5 255.255.255.0 ip router isis mpls ip ! interface FastEthernet0/1 description to R2 ip address 10.0.25.5 255.255.255.0 ip router isis mpls ip ! interface FastEthernet1/0 description to R6 ip address 10.0.56.5 255.255.255.0 ip router isis mpls ip ! router isis net 10.0000.0000.0005.00 ! mpls ldp router-id Loopback0 force
      
      









タスクの詳现はこちらです。

=======================










䞀般に、トラフィックの送信方法ずMPLSタグの関係が明らかになりたした。

しかし、タグはブルドヌザヌから取られたものではありたせん。新幎の前倜に誰も远加の混乱を必芁ずしたせん。 特別なプロトコルは、出力LSRず入力LSRの間でラベルを配垃し、LSPを䜜成したす。





タグ配垃



たず、既に理解したように、䞀郚のデバむスでは、すべおを手動で行うこずができたす-熱意ず勀勉さを怍え付けおください

しかし、自動掗濯機の時代には、タグを配垃するための3぀の基本プロトコル、LDP、RSVP-TE、およびMBGPがありたす。



぀たり、LDP-最も簡単で最も盎感的な方法-は、ノヌドのルヌティング情報に䟝存しおいたす。 RSVP-TEは、か぀お開発されたが人気のないRSVPプロトコルの進化版であり、特定の条件を満たすLSPを構築するためにMPLS-TEで䜿甚されたす。 その䜜業には、トラフィック゚ンゞニアリングOSPF、ISISをサポヌトするIGPが必芁です。

MBGPはBGPの近瞁ですが、歎史が少し異なるプロトコルであり、他の目的のためにラベルを枡したす。 したがっお、LDPおよびRSVP-TEずは異なりたす。



それらのそれぞれに぀いお話したしょうが、その前に、LSRが䞀般的にラベルを凊理する方法に぀いおのいく぀かの蚀葉。



ラベル配垃方法



最初の明らかな事実は、ラベルがトラフィックの受信者から送信者、より正確には出力LERから入力LERに䌝播するこずです。 最初の非自明の事実-MPLSでは、ダりンストリヌムは送信者から受信者ぞ、アップストリヌムは受信者から送信者ぞです。 LSPは、ツリヌのようにFECからIngress LERに「成長」し、ブランチに沿った雚氎のように、LSPを介しお受信者にナヌザヌトラフィックが「䞋降」したす。 ぀たり、タグはトラフィックに向けお配信されたす。



圌らはたた、LSPはトラフィックを満たすために構築されおいるず蚀っおいたす。



ラベル配垃メカニズム自䜓は、プロトコル、蚭定、およびメヌカヌによっお異なりたす。





DU察DoD


たず 、ルヌタヌは䞍芁な質問をせずにタグをすぐにすべおの隣接ノヌドに配信でき、より高いものからの芁求に応じおそれらを発行できたすはい、どの方向がアップストリヌムず呌ばれたすか

最初のモヌドはDU- Downstream Unsolicitedず呌ばれたす。 LSRはFECに぀いお孊習するずすぐに、このFECのラベルをすべおのMPLSネむバヌに送信したす。

次のようになりたす。







すべおのLSRは、あらゆる可胜な方法ですべおのFECに぀いお孊習したす。 最初に、FECタグのマッチングは、PIM SMのBootStrapメッセヌゞのように、ネットワヌク党䜓でネむバヌからネむバヌに分岐したす。 そしお、各LSRは、ベストパスに沿ったものだけを遞択し、LSPに䜿甚したす。これは、同じPIM SMでReverse Path Forwardingが機胜するのず同じ方法です。



すぐに、簡単に、理解できるようになりたすが、すべおの人がすべおを知っおいる必芁は必ずしもありたせん。



2番目のモヌドはDoD- Downstream-on-Demandです。 LSRはFECを知っおおり、近傍を持っおいたすが、このFECのラベルを尋ねるたで、LSRは沈黙しおいたす。







この方法は、垯域幅など、LSPにいく぀かの芁件が課される堎合に䟿利です。 すぐにドロップした堎合、なぜそのようなタグを送信するのですか より良いこずに、より高いLSRはより䜎いものを芁求したす。このFECにはあなたからのラベルが必芁です。それは「OK、ON」です。



マヌキングのモヌドはむンタヌフェむスに固有であり、接続時に決定されたす。 どちらの方法もネットワヌク䞊で䜿甚できたすが、同じ回線では、ネむバヌは特定の1぀だけに同意する必芁がありたす。



順序制埡ず独立制埡


第二に、LSRは、このFECのラベルが出力LERから来るのを埅っおから、アップストリヌムネむバヌに通知できたす。 たたは、圌が自分のこずを知ったらすぐにFECにタグを送信できたす。



最初のモヌドは順序制埡ず呌ばれたす







デヌタが転送されるたでに、出力LERたでのパス党䜓が構築されるようにしたす。



2番目のモヌドはIndependent Controlです。







぀たり、タグは順䞍同で送信されたす。 パス党䜓が構築される前であっおも、トラフィックの送信を開始できるので䟿利です。 同じこずは危険です。





リベラルラベル保持モヌドず保守的ラベル保持モヌド


第䞉に 、LSRが枡されたラベルをどのように凊理するかが重芁です。

たずえば、このような状況では、R1は、R6に到達する最良の方法ではない、ネむバヌR3から受信したラベル20に関する情報を保存する必芁がありたすか







そしお、これはラベル保持モヌドによっお決たりたす。

リベラルラベル保持モヌド -ラベルが保存されたす。 R3が次のステップになる堎合たずえば、メむンパスの問題、ラベルが既に存圚するため、トラフィックはより早くリダむレ​​クトされたす。 ぀たり、反応率は高くなりたすが、䜿甚されるラベルの数は倚くなりたす。

保守的なラベル保持モヌド -䜙分なラベルは、受信するずすぐに砎棄されたす。 これにより、䜿甚するタグの数が枛りたすが、MPLSは、事故が発生した堎合の応答も遅くなりたす。





Php


いいえ、これはあなたが考えた皮類のPHPではありたせん。 最埌から二番目のホップポップに぀いおです。 すべおの゚ンゞニアは少しのオプティマむザヌであり、ここでは、MPLSヘッダヌを2回凊理する必芁がある理由を考えたした。最初に最埌から2番目のルヌタヌで、次に週末に。

そしお、最埌から2番目のLSRでラベルを削陀するこずを決定し、このアクションをPHPず呌びたした。

PHPには特別なラベルがありたす-3。

䟋に戻るず、FEC 6.6.6.6および172.16.0.2の堎合、R6はラベル3を遞択し、R5に報告したす。

パケットをR6に転送する堎合、R5はダミヌラベル-3を割り圓おる必芁がありたすが、実際には適甚されず、むンタヌフェむスにベアIPパケットが送信されたすPHPはIPネットワヌクでのみ動䜜するこずに泚意しおください-぀たり、Pop Label手順はR5で実行されたした。



私たちが今知っおいるこずすべおを考慮に入れお、パッケヌゞの寿呜を远跡したしょう。







トラフィックの送信方法に぀いおは、倚かれ少なかれ明らかです。 しかし、ラベルを䜜成し、テヌブルに蚘入するずいう巚匠の仕事を誰がしおいるのでしょうか





ラベル配垃プロトコル



それほど倚くはありたせん-3぀LDP、RSVP-TE、MBGP。

グロヌバルな目暙は2぀ありたす-トランスポヌトラベルの配垃ずサヌビスラベルの配垃です。

説明しおみたしょう。 トランスポヌトラベルは、MPLSネットワヌク経由でトラフィックを送信するために䜿甚されたす。 これらは私たちが問題党䜓に぀いお話しおいるものにすぎたせん。 LDPずRSVP-TEを䜿甚したす。



サヌビスタグは、異なるサヌビスを分離するために䜿甚されたす。 ここで、MBGPずLDPプロセスtLDPがアリヌナに入りたす。

特に、MBGPでは、たずえば、そのようなルヌトがそのようなVPNに属しおいるこずに泚意するこずができたす。 その埌、圌は、vpn-ipv4ファミリヌのようなこのルヌトをラベルで隣人に枡し、埌でパをカツレツから分離できるようにしたす。

それで、圌が分離できるように、圌はラベルFECに぀いお知らされる必芁がありたす。

しかし、これは別のプレむのアクションであり、6か月たたは1幎埌にプレむしたす。



すべおの動的ラベル割り圓おプロトコルの動䜜の前提条件は、IP接続の基本構成です。 ぀たり、IGPがネットワヌク䞊で実行されおいる必芁がありたす。






さお、私はあなたを完党に混乱させたので、あなたは解き明かすこずができたす。

それでは、タグを配垃する最も簡単な方法は䜕ですか 答えは、LDPを有効にするこずです。





LDP



非垞にわかりやすい名前のプロトコル-Labed Distribution Protocol-には、察応する動䜜原理がありたす。

linkmeupネットワヌクで怜蚎しおください。問題党䜓をカバヌしおいたす。







1. LDPをオンにした埌、LSRは、LDPがアクティブになっおいるアドレス224.0.0.2およびポヌト646ぞのすべおのむンタヌフェむスぞのUDPデヌタグラムのマルチキャスト送信を行いたす。これにより、近隣が怜玢されたす。

盎接接続されたノヌド間でLDP近隣が確立されるため、このようなパケットのTTLは1です。



䞀般的に蚀えば、これは垞にそうであるずは限りたせん。LDPセッションは、特定の目的のために、リモヌトホストを䜿甚しおむンストヌルできるため、tLDP- Targeted LDPず呌ばれたす。 他の問題で圌に぀いお話したす。



これらのメッセヌゞはHelloず呌ばれたす。



2.ネむバヌが怜出されるず、ポヌト646- 初期化でも、ネむバヌずTCP接続が確立されたす。 それ以降のメッセヌゞHelloを陀くは、既に255のTTLで送信されおいたす。



3.珟圚、LSRはTCPを介しおキヌプアラむブメッセヌゞを定期的に亀換し、Helloを䜿甚しお近隣の怜玢を詊み続けおいたす。



4.ある時点で、LSRの1぀が2番目のパヌ゜ナリティであるEgress LSRを発芋したす。぀たり、FECの週末です。 これは、䞖界に報告する必芁がある事実です。

モヌドに応じお、このFECのラベル芁求を埅぀か、すぐに送信したす。







この情報は、 ラベルマッピングメッセヌゞで送信されたす。 名前に基づいお、それ自䜓でFECずラベルの察応を保持しおいたす。



R5はFEC 6.6.6.6/32およびラベル3暗黙のヌルコンプラむアンス情報を受信し、ラベルテヌブルに曞き蟌みたす。 これで、6.6.6.6にデヌタを送信する必芁がある堎合、䞊䜍MPLSヘッダヌを削陀し、残りのパケットをFE1 / 0むンタヌフェむスに送信する必芁があるこずがわかりたす。



次に、指定されたFECの入力ラベルを遞択し、この情報を自分のラベルテヌブルに曞き蟌み、䞊䜍の近隣に送信したす。







これで、R5は、ラベル20のMPLSパケットが到着した堎合、ラベルを削陀するこずにより、぀たりPHPプロシヌゞャを実行するこずにより、FE1 / 0むンタヌフェむスに枡す必芁があるこずを認識したす。



R2は、R5 FECラベル6.6.6.6-20からコンプラむアンス情報を受け取り、それをテヌブルに入力し、その入力ラベル18を䜜成しお、さらに高く転送したす。 など、すべおのLSRが出力ラベルを取埗するたで。







したがっお、R1からR6にLSPを構築したした。 R1は、6.6.6.6 / 32にパケットを送信するずきに、ラベル18プッシュラベルを远加しお、ポヌトFE0 / 0に送信したす。 ラベル18のパケットを受信したR2は、ラベルを20スワップラベルに倉曎し、ポヌトFE0 / 0に送信したす。 R5は、ラベル20のパケットの堎合、PHPを実行する必芁があるこずを確認し出力ラベルは3-暗黙的なヌル、ラベルPop Labelを削陀し、デヌタをポヌトFE1 / 0に送信したす。



同時に、R2からR6、R5からR6、R4からR6などのLSPが䞊行しお構築されたした。 ぀たり、すべおのLSRから-私はそれをむラストに衚瀺したせんでした。



十分な匷床がある堎合は、䞋のGIFで、プロセス党䜓をダむナミクスで芋るこずができたす。







圓然のこずながら、R6が突然FECタグ通信を送信し始めただけでなく、他のすべお-R1 1.1.1.1/32、R2-2.2.2.2/32などに぀いおも理解したす。 これらのメッセヌゞはすべお、MPLSネットワヌク党䜓で高速に凊理され、倚数のLSPを構築したす。 その結果、各LSRは既存のすべおのFECを認識し、察応するLSPが構築されたす。



繰り返したすが、䞊蚘のgifでは、プロセスは最埌たで瀺されおいたせん。R1は情報をR3、R3からR4、R4からR5に転送したす。

たた、R5を芋るず、FEC 6.6.6.6/32の堎合、予想どおり1぀の出力ラベルはありたせんが、3







さらに、R6自䜓はR5から受信するFEC 6.6.6.6のラベルを蚘録したす。







Inuse-正しい-R6ぞのむンプヌル。 しかし、リングの他の2぀はR2ずR4からのものです。 これは間違いでもルヌプでもありたせん。R2ずR4だけが、既知のFEC 6.6.6.6/32ルヌティングテヌブル甚にこれらのラベルを生成したした。



2぀の質問が発生したす。

1圌はどのようにそれらを䜿甚する予定ですか 圌らは愚かです。 答え䜕もありたせん。 2.2.2.2たたは4.4.4.4が6.6.6.6ぞの途䞭の次のノヌドである堎合、ネットワヌクに状況はありたせん。IGPはこのようなルヌトを構築したせん。 ぀たり、ラベルは䜿甚されたせん。 それは、LDPが愚かであるずいうこずです-そのメッセヌゞはネットワヌク党䜓に散らばっおおり、あらゆる亀裂を突砎したす。 そしお、スマヌトLSRが䜿甚するものを決定したす。

2ルヌプはどうですか TTLが期限切れになるたで、LDPメッセヌゞはネットワヌク䞊で実行されたせんか

そしお、ここではすべおが単玔です-新しいラベルマッピングメッセヌゞを受信しお​​も、新しいラベルマッピングメッセヌゞの䜜成は開始されたせん-受信した通信はLDPテヌブルに単に曞き蟌たれたす。 ぀たり、私たちの堎合、R5はすでにFEC 6.6.6.6/32のラベルを䞀床䜜成し、それを䞊䜍の近隣に送信したした。LDPプロセスが再起動するたで、ラベルは倉曎されたせん。

LDPを蚭定するずきにルヌプ怜出機胜を有効にできるこずにすでに気づいおいるかもしれたせんが、安心させおください-これはTTLがないネットワヌクATMなどの堎合です。 この機胜は、LDPをDoDモヌドに切り替えたす。



これは、LDPの機胜に関する基本情報です。

実際、ここでのすべおはメヌカヌに倧きく䟝存しおいたす。 原則ずしお、LDPは、DoD / DU、Independent Control / Ordered Control、Conservative / Liberal Label Retentionのすべおの皮類のラベル付けモヌドをサポヌトしおいたす。 これは、RFCによっお芏制されおいないため、各ベンダヌは独自のパスを自由に遞択できたす。

たずえば、基本的に誰もがLDPにDUを䜿甚したすが、同時にゞュニパヌのラベルは敎然ず、シスコでは独立しお配垃されたす。

HuaweiずJuniperはLSRルヌプバックむンタヌフェむスのみをFECずしお遞択し、Cisco FECはルヌティングテヌブルのすべおの゚ントリに察しお䜜成されたす。



ただし、これらすべおが実際のネットワヌクに圱響を䞎えるこずはほずんどありたせん。



LDPに぀いお理解する最も重芁なこずは、その䜜業で動的ルヌティングプロトコルを䜿甚しないこずです。原則ずしおPIM DMず同様です。ネットワヌク党䜓にタグをフラッディングしたすが、LSRルヌティングテヌブルの情報に䟝存したす。 たた、異なるネむバヌからの1぀のFECの2぀のラベルがR1に到着した堎合、TMからの情報に埓っお、このFECの前に最適なむンタヌフェむスを介しお受信したラベルのみをLSPに遞択したす。

これは3぀のこずを意味したす。



䞀般的に、LDPを有効にするず、トラフィックはMPLSタグが衚瀺されるこずを陀いお、トラフィックがない堎合ず同じようになりたす。

IPず同様に、LDPを含むECMPは、ハッシュ蚈算アルゎリズムのみをサポヌトするため、バランスが異なる堎合がありたす。



LDPに関するIvan Pepelnyakの興味深い蚘事ず、プロトコルの仕組みに関するビデオ 。



LDPはRFC 5036で説明されおいたす 。



自民党の緎習



linkmeupネットワヌクに忠実です。







OSPFが実行されおおり、ルヌタヌはルヌプバックを確認し、MPLSはオフになっおいたす。



初期構成ファむル。



MPLSをグロヌバルに有効にするには、2぀のコマンドを指定する必芁がありたす。

 R1(config)#ip cef R1(config)#mpls ip
      
      





1぀目は、ほずんどすべおのネットワヌク機噚ですでに事実䞊の暙準であり、2぀目はMPLSずLDPをグロヌバルに開始したすデフォルトで指定するこずもできたす。



MPLSのルヌタヌIDおよびより䞀般的な非シスキア語LSR ID甚語は、明確に遞択されたす。

  1. 最倧ルヌプバックむンタヌフェむスアドレス
  2. そうでない堎合、ルヌタヌで構成されおいる最倧のIPアドレス。


圓然、自動化を信頌するべきではありたせん-LSR IDを手動で蚭定したす

 R1(config)# mpls ldp router-id Loopback0 force
      
      





「force」キヌワヌドを远加しない堎合、LDPセッションを再むンストヌルするずきにのみルヌタヌIDが倉曎されたす。 「匷制」は、ルヌタヌがルヌタヌIDを匷制的に倉曎するこずを匷制し、必芁に応じお倉曎されおいる堎合、LDP接続を再確立したす。



次に、必芁なむンタヌフェむスで、 mpls ipコマンドを実行したす。

 R1(config)#interface FastEthernet 0/0 R1(config-if)#mpls ip R1(config)#interface FastEthernet 0/1 R1(config-if)#mpls ip
      
      





シスコはここでも怠zyな゚ンゞニアの原則を䜿甚しおいたす-スタッフ偎の最小限の劎力です。 mpls ipコマンドには、垌望するかどうかにかかわらず、MPLSず同時にLDPむンタヌフェむスが含たれたす。 同様に、 マルチキャスト蚘事で説明したように、 ip pim sparse-modeコマンドはむンタヌフェむスでIGMPを有効にしたす。

LDPをアクティブにした埌、ルヌタヌはUDPを介しお土壌の調査を開始したす。





怜蚌は、マルチキャストアドレス224.0.0.2に送信されたす。



ここで、R2ですべお同じ操䜜を繰り返したす。

 R2(config)#ip cef R2(config)#mpls ip R2(config)# mpls ldp router-id Loopback0 force R2(config)#interface FastEthernet 0/0 R2(config-if)#mpls ip R2(config)#interface FastEthernet 0/1 R2(config-if)#mpls ip
      
      





結果をお楜しみください。

R2は隣人も探しおいたす。







圌らはお互いに぀いお孊び、R2はLDPセッションを䞊げたす







興味があれば、どのようにTCP接続を確立したすか








珟圚、それらはネむバヌです。これは、 show mpls ldp neighborコマンドで簡単に確認できたす。







そしお、お互いがFECラベルにその通信に぀いお䌝えたす。







ここで、すでに詳现を確認できたす-R1はすぐに12 FECを送信したす-ルヌティングテヌブルの各゚ントリに1぀です。 同じ状況で、Huaweiたたはゞュニパヌはルヌプバックむンタヌフェむスの6぀のFECアドレスのみを送信したす。これは、デフォルトで/ 32プレフィックスのみをFECず芋なすためです。

この点で、シスコはラベルリ゜ヌスに぀いお非垞に䞍経枈です。

ただし、この動䜜はどの機噚でも倉曎できたす。 この堎合、 mpls ldp advertise-labelsコマンドが圹立ちたす。



しかし、どのように、あなたは尋ねたすか ルヌプバックにのみタグを付ければ十分ですか



蚘事の冒頭で、BGPプレフィックスはラベルを受信せず、ラベルはネクストホップにのみ必芁であるず考えたこずを思い出すず、ルヌプバックに十分なラベルがあるこずが明らかになりたす。



AS内の他のネットワヌクにアクセスするには、IGPで十分です。





=======================

タスク番号3



CiscoがデフォルトですべおのネットワヌクBGP経由で受信したネットワヌクを陀くのラベルをアナりンスする堎合、Juniperでは、デフォルトでルヌプバックのみがアナりンスされたす。



スキヌム




R5を陀くすべおのルヌタヌはゞュニパヌのルヌタヌです。



以䞋のR5ルヌタヌ構成の堎合、Ciscoルヌタヌ蚭定がJuniperのデフォルト蚭定ず䞀臎するように構成したす。



R5の構成
 ip cef ! interface Loopback0 ip address 5.5.5.5 255.255.255.255 ip router isis ! interface FastEthernet0/0 description to R4 ip address 10.0.45.5 255.255.255.0 ip router isis mpls ip ! interface FastEthernet0/1 description to R2 ip address 10.0.25.5 255.255.255.0 ip router isis mpls ip ! interface FastEthernet1/0 description to R6 ip address 10.0.56.5 255.255.255.0 ip router isis mpls ip ! router isis net 10.0000.0000.0005.00 ! mpls ldp router-id Loopback0 force
      
      









タスクの詳现はこちらです。

=======================









したがっお、 R1は、 FEC 3.3.3.3のトラフィックを送信する堎合、ラベル17を䜿甚する必芁があるこずをR2に䌝えたす。



R3のLDPはただ提起されおいないこずに泚意しおください。぀たり、R1はR5からの埅機なしにFEC 3.3.3.3のラベルを発衚したした。これは、独立制埡が䜿甚されおいるこずを瀺したす。

そしお、このFECに察するR2からの明瀺的な芁求がなかったずいう事実は、モヌドがDownstrean未承諟であるこずを瀺唆しおいたす。



さらに、ノヌドはUDP䞊でLDP Helloを䜿甚しお新しいネむバヌを監芖し続け、すでにアドレス指定されおいるLDPキヌプアラむブを亀換したす。







これで、 show mpls forwarding-tableコマンドを䜿甚しお、各FECに割り圓おられたラベルを確認できたす。







2行目では、FEC 3.3.3.3が既に怜蚎されおおり、ロヌカルラベルは17です。぀たり、R1はFEC 3.3.3.3の堎合、ダンプにあったラベルは17であるこずを党員に䌝えたす。

ただし、発信タグたたは出力ラベル- タグなし -これは、パケットがクリヌンな IPで転送されるこずを意味したすスタックぞの予玄なし。 Untaggedは、R1ずR3の間にMPLSがたったくないこずを意味したす-そうです。R3で有効にしたせんでした。

しかし、R2最初の行では状況は異なりたす。 ロヌカルラベル16は、R1がすべおの人に送信するものです。 そしお週末はポップタグです。 ぀たり、パケットをR2に転送するずき、R1はチェックを解陀する必芁がありたす。 私たちの堎合、これは玔粋なIPが送信されるこずを意味したすただし、より䞀般的なケヌスでは、トップマヌクのみが削陀されたす。 FEC 3.3.3.3ずの違いは䜕ですか 違いは、R1ずR2の間にMPLSがあり、同じPHP最埌から2番目のホップポッピングがあるこずです。 2.2.2.2にアドレス指定されたパケットは匕き続きR2で凊理されるため、必芁な倀を超える゚ンティティを生成しないように、R1はマヌクを削陀したす。



そしお、ここで興味深い疑問が生じたす。R1はモヒカン族の最埌から2番目であるこずをどのように知るのでしょうか結局のずころ、LDPはルヌティングプロトコルを䜿甚しないため、アドレス2.2.2.2が盎接接続されたR2で構成されおいるこずすら知るこずはできたせん。2.2.2.2は10.0.12.2を介しおのみ利甚可胜です。



R2ずR1の間のトラフィックダンプは、この質問に答えるのに圹立ち







たす。ここでは、同じラベル3が衚瀺されたす-暗黙的ヌル。したがっお、R2は、MPLSパケットを送信するずきにR1がトップマヌクを削陀する必芁があるこずを報告したす。

ここで繰り返したす-R1はラベル3のパケットをR2に送信したせん-トップラベルなしで送信したす。私たちの堎合、それは単なるIPパケットになりたす。たた、ラベル3はMPLSヘッダヌに衚瀺されたせん。

そしお、このラベル3は、MPLSスむッチングテヌブルにPop Tagずしお衚瀺されたす。



ノヌドR5ずR6には、MPLSが含たれおいたせんが、ラベルがありたすが、これは、それらぞのルヌトがR2を経由し、R2がFECラベルの䞀臎を生成したためです。この堎合、R6䞊のパケットは、R1ずR2の間のMPLSヘッダヌを䜿甚し、それを䜿甚したせん。

順序制埡が䜿甚された堎合、R2はR5およびR6のラベルを送信できず、パケットはIPのみを通過するこずに泚意しおください。



控えめなネットワヌクのすべおの芁玠で、MPLS + LDPの構成を完了するこずを提案したす。プロセスには違いはありたせん-同じ近隣探玢、初期化、タグ亀換、PHP。



構成テンプレヌトは次のずおりです。

 <b>mpls ip</b> ! interface Loopback0 ip address 1.1.1.1 255.255.255.255 ip router isis ! interface FastEthernet0/0 description to R2 ip address 10.0.12.1 255.255.255.0 ip router isis <b> mpls ip</b> ! interface FastEthernet0/1 description to R3 ip address 10.0.13.1 255.255.255.0 ip router isis <b> mpls ip</b> ! router isis net 10.0000.0000.0001.00 ! <b>mpls ldp router-id Loopback0 force</b>
      
      







LDP構成ファむル。



そしお、䞊の衚を切り替えMPLSで再び芋おR1







すべおのFECすでに登堎したラベルに぀いお。

R1からR6にLSPを通過し、ラベルがパス



R2に 沿っおどのように倉化するかを芋おみたしょう。R5











だから

1. R1がラベル21の MPLSパケットを受信するず、Fa0 / 0むンタヌフェむスに枡しおラベルを18に倉曎する必芁がありたす。

2. R2がラベル18の MPLSパケットを受信するず、それをFa0 / 0むンタヌフェむスに枡し、ラベルを20に倉曎する必芁がありたす。

3. R5の堎合タグ20の MPLSパケットを受信した堎合、Fa1 / 0むンタヌフェむスに枡し、タグPHPを削陀する必芁がありたす。



この堎合、LSRはルヌティングテヌブルたたはip cefで䜕かを怜蚎するこずすら考えたせん。単にラベルを操䜜するだけです。show mpls forwarding table



コマンドですでに芋たスむッチングテヌブルはLFIBLable Forwarding Information Baseです。デヌタ転送のほずんどの䞀般的な真実はデヌタプレヌンです。しかし、コントロヌルプレヌンはどうでしょうか。自民党が同じくらい知っおいるこずはありそうにない確かに圌はただ袖に切り札を持っおいたすか

だから







各FECに぀いお、異なるラベルに関する情報がここに衚瀺されたす。

ロヌカルバむンディング -このLSRが

リモヌトネむバヌに枡すもの-このLSRがネむバヌから受信したもの。



䞊の図では、「tib」ずいう単語を芋るこずができたす。TIBは、ラベル情報ベヌス-LIBず正しく呌ばれるタグ情報ベヌスです。

これは、自民党の先駆者であるボヌズで亡くなったTDPの遺物です。



どこでも2぀のリモヌトバむンディングがタグを取埗する2぀の方法であるこずに泚意しおください。たずえば、R1から盎接、たたはR3-R4-R5-R2を介しおR2たで到達できたす。

぀たり、はい、わかりたすか圌はルヌティングテヌブルの各゚ントリからFECを䜜成するだけでなく、この悪党はラベルを保持するために自由保持モヌドも䜿甚したす。

芁玄するず、デフォルトでは、CiscoのLDPは次のモヌドで動䜜したす。



芁するに、圌の報奚金には限界がありたせん。show mpls ip binding



コマンドもありたす。同様のこずを瀺し、さらに、珟圚アクティブなパス、぀たりLSPの構築方法をすばやく芋぀けるこずができたすそしお最埌の、おそらく、これらすべおのLSPに関連しお生じる質問-ルヌタヌ自䜓がIngress LSRである堎合、どのようにそれを理解するのかパッケヌゞで行う必芁がある、LSPの遞択方法そのためには、IP CEFを調べる必芁がありたす。䞀般に、パケットの凊理、FECの決定、および正しいラベルの割り圓おのすべおの負担を負うのは入力LSRです。次に、あなたずNext Hopず出力むンタヌフェヌスず出力ラベル
























たた、LDPでは、LER、Ingress LSR、Egress LSRの抂念は特定のノヌドの圹割でも、ネットワヌク内のノヌドの堎所の特性でもないこずに泚意しおください。それらはFECおよびLSPずは切り離せたせん。぀たり、特定のFECごずに、LSPが導く1぀以䞊の出力LSRず倚くの入力LSR通垞はすべおのルヌタヌがありたす。

そうは蚀っおも、特定のLSPに぀いお話すずLERの抂念が生じ、誰がむングレスで誰がむヌグレであるかを蚀うこずができたす。





MPLSおよびBGP



これたで、MPLSがIGPプロトコルず盞互䜜甚する方法に぀いお説明しおきたした。耇雑なこずは䜕もないこずず、蚭定も非垞に簡単であるこずを確認したした。



しかし、最も興味深いのは、MPLSずBGPの盞互䜜甚です。この問題では、このトピックに぀いお少しだけ觊れたす。ただし、以䞋では、BGPが果たす圹割ず、BGPを䜿甚しおさたざたなタむプのVPNを線成する方法に぀いお詳しく説明したす。

次に、最も基本的なレベルでMPLSずBGPがどのように盞互䜜甚するかを理解する必芁がありたす。



BGPずIGPの䞻な違いは、MPLSがBGPルヌトのラベルを䜜成しないこずです。 BGPが送信するルヌトの数を思い出せば、これが非垞に良いアむデアであるこずが明らかになりたす。次に、MPLSずBGPを組み合わせる方法は

すべおが簡単です

  1. , next-hop , BGP ( next-hop-self IBGP-).
  2. Ingress LSR , BGP, next-hop, , .


珟圚、ASの各ルヌタヌでBGPを構成するために、クラむアントたたは他のプロバむダヌが接続されおいる境界ルヌタヌでのみ構成できたす。



ネットワヌクの䟋を芋おみたしょう





。R1からFilkin蚌明曞ネットワヌクにアクセスする必芁がある堎合、R6ず6.6.6.6のアドレスにMPLSを「フラむスルヌ」しおアクセスできるこずがわかりたす。そしお、私たちがR6に着いたずき、圌はすでにどこに行くべきかをすでに知っおいたす。 Balagan Telecomでも同様です。



この回路の構成ず情報出力があるいく぀かのコマンドはここで芋぀けるこずができたす。



=====================

№ 4



MPLS OSPF. MPLS , R7 R1.

R1-R2-R3-R4-R5-R6 MPLS.

BGP, R1 R6.



BGP .

R1 , BGP R6, MPLS IP-, next-hop BGP.



R7 , BGP R6.



:

, R7 100.0.0.1.



:

BGP.









.

=====================







RSVP-TE



自民党は良いです。簡単か぀明確に機胜したす。しかし、MPLS TE-Traffic Engineeringのようなテクノロゞヌがありたす。そしお、圌女は自民党が提䟛できる最良のルヌトを持っおいたせん。

トラフィック管理ずは、さたざたな制限がある堎合、ノヌド間でトラフィックを奜きなように転送できるこずを意味したす。

たずえば、このネットワヌクでは、クラむアントはR1ずR6の2぀のノヌド接続ポむントを持っおいたす。そしお、それらの間で、圌は100 Mb / sの保蚌されたチャネル幅でVPNを芁求したす。しかし同時に、私たちのネットワヌクでは、VKontakteの通垞のブロヌドバンドビデオドラむバヌず、VPNをレンタルする数十の他のクラむアントも䜿甚しおいたすが、垯域を予玄する必芁はありたせん。

この状況に介入しない堎合、R2のどこかで過負荷が発生する可胜性があり、高䟡なクラむアントの堎合は100 Mb / sになりたせん。



MPLS TEを䜿甚するず、送信者から受信者たでネットワヌク党䜓を通過し、各ノヌドでリ゜ヌスを予玄できたす。 IntServの抂念に粟通しおいる堎合は、そうです。各ルヌタヌが通過するパケットを決定するのではなく、パス党䜓に沿っおQoSを敎理するこずです。

実際、RSVPResource ReSerVation Protocolはもずもず1993幎であり、IPネットワヌクでIntServを線成するために考案されたした。特定のデヌタストリヌムのQoSに関する情報を各ノヌドに䌝え、リ゜ヌスを予玄する必芁がありたした。



最初の近䌌では、単玔に機胜したす。



1゜ヌスノヌドは、5 Mb / sの速床でデヌタストリヌムを送信したい。ただし、その前に、圌はRSVPリク゚ストを送信しお、受信者にパスを予玄したす-Path Message。このメッセヌゞにはいく぀かのストリヌム識別子が含たれおおり、これによりノヌドはストリヌムに察しお受信したIPパケットの所有暩ず必芁な垯域幅を識別できたす。

2Pathメッセヌゞは、ノヌドから受信機自䜓にノヌドから送信されたす。送信先は、ルヌティングテヌブルに基づいお決定されたす。

3Pathを受信した各ルヌタヌは、リ゜ヌスをチェックしたす。十分な空き垯域幅がある堎合、ストリヌムパケットが適切に凊理され、垞に十分な垯域幅があるように、内郚アルゎリズムを調敎したす。

4必芁な5 Mb / s他のスレッドによっお占有されおいるがない堎合、リ゜ヌスの割り圓おを拒吊し、察応するメッセヌゞを送信者に返したす。

5Pathパケットはストリヌムの受信者に到達し、Resvメッセヌゞを送り返し、パス党䜓に沿ったリ゜ヌスの割り圓おを確認したす。

6Resvを受け取った元の送信者は、すべおの準備が敎っおいるこずを理解し、デヌタを送信できたす。



実際、これらの4぀の単玔なステップの䞋にははるかに耇雑なプロセスがありたすが、興味はありたせん。



しかし、私たちが関心を持っおいるのは、Traffic EngineeringのRSVP拡匵機胜、たたはより簡単に蚀うず、MPLS TE専甚に開発されたRSVP TEです。

そのタスクはLDPのタスクず同じです。LSR間でラベルを配垃し、最終的に受信者から送信者にLSPをコンパむルしたす。しかし、今、すでに理解しおいるように、ニュアンスがありたす-LSPは特定の条件を満たす必芁がありたす。



RSVP TEを䜿甚するず、プラむマリLSPずセカンダリLSPを構築し、すべおのノヌドでリ゜ヌスを予玄し、ネットワヌククラッシュを怜出し、事前に回避策を構築し、高速トラフィックリダむレクションを行い、物理的に同じパスを通るチャネルを回避できたす。

ただし、これらすべおに぀いおは、MPLS TEに関する蚘事でいく぀かの問題を取り䞊げお説明したす。ただし、今日は、RSVP TEがLSPを構築する際の原則に焊点を圓おたす。

プロトコルの倉曎から、LSPはそれぞれ単方向であるこずに倉わりはなく、リ゜ヌスは䞀方向にのみ予玄されたす。他の䜕かが必芁な堎合-逆LSPを䜜成したす。





たず、リ゜ヌス予玄機胜を砎棄したす。タスクをLSPの䜜成のみ、぀たりLSR間のラベル配垃のみにしたす。



これを可胜にするために、暙準のRSVPはいく぀かのオブゞェクトを远加するこずにより拡匵されたす。最も単玔なオプションを怜蚎しおください。

0R1はFEC 6.6.6.6/32より前にLSPを必芁ずしたす6.6.6.6の宛先アドレスずタむプTraffic Engineeringを持぀R1のトンネルむンタヌフェヌスのように芋えたす。

16.6.6.6の方向にRSVP Pathメッセヌゞを送信したす。このメッセヌゞに新しいオブゞェクトが衚瀺されたす-Label Request。 Pathメッセヌゞは、ノヌドにこのFECのラベルを割り圓おるように呌びかけたす。぀たり、ラベル芁求です。

2次のノヌドは新しいPathメッセヌゞを圢成し、6.6.6.6に送信したす。等

3パスが出力LSRに到達したす。圌は、パケットが自分宛であるこずを確認し、ラベルを遞択しお、Resvメッセヌゞを送信元に送信したす。埌者は、新しいオブゞェクトLabelも远加したした。その䞭で、Egress LSRはこのFECのラベルを最埌から2番目、最埌から2番目の最埌などに枡したす。

4Resvは゜ヌスに到達し、パスに沿っおラベルを配垃したす。このようにしお、LSPが䜜成され、すべおの準備ができたこずが゜ヌスに通知されたす。



ラベルはダりンストリヌムで芁求され送信者から受信者ぞのパスメッセヌゞ、アップストリヌムで送信されたす受信者から送信者ぞのResvメッセヌゞ。

同時に、これが最もダりンストリヌムオンデマンド+オヌダヌドコントロヌルであるこずに泚意しおください。パスはラベル芁求ずしお機胜し、Resvは段階的に受信者から送信されたす。ラベルが䞋䜍LSRによっお送信されるたで、芪はそのラベルを近隣に送信できたせん。



やめおLDPずは異なり、RSVP TEを䜿甚するず、ルヌティングテヌブルやIGPに瞛られるこずなく、垌望どおりに構築できたすが、ここでは「6.6.6.6に向けお」だけです。

ここで、RSVP TEずLDPの根本的な違いに近づきたす。 RSVP TEは、動的ルヌティングプロトコルず非垞に密接に接続されおおり、䜜業の結果だけに䟝存するのではなく、文字どおりの意味で悪甚したす。

たず、リンクステヌトアルゎリズム、぀たりOSPFずISISに基づくプロトコルのみが適しおいたす。

第二に、OSPFずISISは、プロトコルに新しい芁玠を導入するこずで拡倧しおいたす。 OSPFには新しいタむプのLSA-Opaque LSAがあり、ISISには新しいTLV ISネむバヌずIP到達可胜性がありたす。

3番目に、入力LSRず出力LSRの間のパスを蚈算するために、SPFアルゎリズムの特別な倉曎-CSPFConstrained Shortest Path Firstが䜿甚されたす。



より詳现に。



Pathメッセヌゞは、原則ずしお、ナニキャストによっおアドレス指定しお送信されたす。぀たり、送信者のアドレスはR1、受信者のアドレスは6.6.6.6です。そしお、それはルヌティングテヌブルによっおもたらされた可胜性がありたす。







しかし実際には、FIBがすべおのノヌドの魂に眮かれるのではなく、Pathがネットワヌクを介しお送信されたす。これは、予玄を提䟛したり、バックアップルヌトを怜玢したりできないためです。いいえ、圌は特定の道をたどりたす。

このパスは、各ノヌドの粟床に応じお入力LSRで定矩されたす。

このパスを構築するには、RSVP TEはネットワヌクトポロゞを知る必芁がありたす。はい、私たちは䜕に近づいおいたすか RSVP自䜓は、OSPFたたはISISから取埗できる堎合、その理由ずその理由を怜蚎したせん。そしお、RIP、IGRP、EIGRPがここで適切でない理由が明らかになりたす。結局のずころ、圌らはトポロゞを研究せず、可胜な最倧倀はフィヌゞブルサクセサです。

ただし、入力の叀兞的なSPFアルゎリズムにはネットワヌクトポロゞがあり、出力ではメトリックずADを考慮した最速のルヌトしか提䟛できたせんが、可胜なすべおのパスを蚈算できたす。

そしお、ここにCSPFがありたす。少なくずも䜕らかの圢で䞭囜を経由するために、最適なパス、2番目に優先床の高いパス、および他のバックアップパスなどを蚈算できるのはこのアルゎリズムです。

぀たり、RSVP TEは、2぀のノヌド間の任意のパスを蚈算するための芁求でCSPFに連絡する堎合がありたす。

たあ、たあ、なぜこれのためにIGPプロトコル自䜓を倉曎するのですかブヌト。そしお、これが制玄-制限です。 RSVP TEは、垯域幅、利甚可胜な最小幅、回線タむプ、たたはLSPが通過する必芁があるノヌドでさえ、パス芁件を蚭定できたす。そのため、CSPFが制限を考慮するこずができるように、制限に぀いお、およびネットワヌク党䜓のノヌドで利甚可胜なリ゜ヌスに぀いお知る必芁がありたす。入力は、トンネルずネットワヌクトポロゞで指定された制限です。トポロゞに、プレフィックスずメトリックに加えお、利甚可胜なリ゜ヌスに関する情報が含たれおいる堎合は論理的です。

この目的のために、ルヌタヌはメッセヌゞOSPFおよびISISを通じお基本情報だけでなく、回線、むンタヌフェむスなどの特性も亀換したす。新しいタむプのメッセヌゞでは、この情報が送信されたす。

たずえば、OSPFでは、これのために3぀の远加LSAタむプが導入されたした。







䞍透明は䞍透明OSPFの堎合を意味したす。これらは、ルヌティングテヌブルの蚈算時にOSPFで考慮されない特別なLSAタむプです。必芁に応じお他のプロトコルを䜿甚できたす。したがっお、TEはそれらを䜿甚しおトポロゞを構築したす TED- Traffic Egineering Databaseず呌ばれたす。しかし、理論的には、それらはTEに割り圓おられたせん-トポロゞに関する情報の亀換を必芁ずするルヌタヌ甚のアプリケヌションを䜜成する堎合、Opaque LSAも䜿甚できたす。

ISISも同様に機胜したす。新しい投皿IS-IS TLV 22拡匵IS到達可胜性、134トラフィック゚ンゞニアリングルヌタヌID、135拡匵IP到達可胜性。



それでは、このプロセス党䜓を詳しく芋おみたしょう。



0R1では、MPLS TEを有効にし、TEをサポヌトするためにデヌタを送信するようにISISOSPFを構成したした。ルヌタヌは利甚可胜なリ゜ヌスに関する情報を亀換したした。このステップで、TEDが圢成されたす。 RSVPはサむレントです。







1トンネルむンタヌフェむスを䜜成し、そのタむプトラフィック゚ンゞニアリング、宛先アドレス6.6.6.6、および必芁なリ゜ヌス芁件を指定したした。 LSRはCSPFを開始したす。課された条件を考慮しお、R1から6.6.6.6ぞの最短経路を蚈算する必芁がありたす。このステップでは、最適なパスを取埗したす-゜ヌスから宛先ぞのノヌドのリストR2、R5、R6。



2前のステップの結果はRSVPによっお䟛絊され、EROオブゞェクトに倉換されたす。R1はRSPVパスをコンパむルしたす。これにより、圓然EROが远加されたす。パケットの宛先は6.6.6.6です。さらに、パケットを受信するず、このFEC6.6.6.6/32のラベルを割り圓おる必芁があるこずを通知するLabel Requestオブゞェクトもありたす。

ERO-明瀺的ルヌトオブゞェクト -特別なRSVPパスメッセヌゞオブゞェクト。これには、このメッセヌゞが通過するノヌドのリストが含たれおいたす。





3 RSVP Pathメッセヌゞは特別な方法で送信されたす-ルヌティングテヌブルではなく、EROリストに埓っお。この堎合、最良のIGPルヌトずEROが䞀臎するため、パケットはR2に送信されたす。



4 RSVPパスを受信したR2は、必芁なリ゜ヌスの可甚性をチェックし、もしあれば、FEC 6.6.6.6/32のMPLSラベルを割り圓おたす。叀いPathパッケヌゞが砎棄され、新しいパッケヌゞが䜜成され、EROオブゞェクトが倉曎されたす-R2自䜓が削陀されたす。これは、次のノヌドがパケットをR2に返そうずしないようにするためです。぀たり、新しいEROはすでに次のようになっおいたすR5、R6。それに応じお、R2は曎新されたパスをR5に送信したす。



5R5は同様の操䜜を実行したす。リ゜ヌスをチェックし、ラベルを遞択し、EROから自身を削陀し、Pathパケットを再䜜成しお、次のEROオブゞェクトが認識されおいるむンタヌフェヌスに枡したす-R6。





6パッケヌゞを受け取ったR6は、圌がすべおの混乱の犯人であるこずを理解しおいたす。これは、パスを砎壊するFEC 6.6.6.6のラベルを割り圓お、オブゞェクトずしお挿入ラベル応答メッセヌゞのResvに。

この手順の前に、ラベルは目立っただけで広がりたせんでしたが、ラベルを芁求したLSRに通知されるようになりたした。

7 RESVメッセヌゞはR1むングレスLSRに進み、LSPの増倧するテヌルを残したす。 Resvは、Pathず同じノヌドを逆順で通過する必芁がありたす。







8最終的に、R1から6.6.6.6ぞのLSPが圢成されたす。そのデヌタは、R1からR6にのみ送信できたす。反察方向のデヌタ転送を蚱可するには、R6に宛先アドレス1.1.1.1のトンネルむンタヌフェむスを䜜成する必芁がありたす。すべおのアクションはたったく同じです。







質問が発生したす-ノヌドごずに送信され、それらのアドレスがわかっおいる堎合、Path 6.6.6.6パケットの宛先はなぜですかこの質問は怠idleではありたせん。1぀の重芁な機胜に぀ながりたす。 EROには、入力LSRから出力LSRたでのすべおのノヌドが実際に含たれおいるわけではありたせん。䞀郚は省略されおいる堎合がありたす。したがっお、各LSRはメッセヌゞの最終的な送信先を知る必芁がありたす。たた、むングレスLSRが党䜓を蚈算するには遅すぎるため、これは発生しない可胜性がありたす。

問題はIGPゟヌンにありたす。ルヌティングを簡玠化するために、OSPFずISISの䞡方にこの抂念があるこずがわかっおいたす。倧芏暡なネットワヌク数癟および数千のノヌドでは、サヌビスパケットをブロヌドキャストする問題ず、SPFアルゎリズムによる膚倧な数の組み合わせの蚈算が発生したす。したがっお、1぀のグロヌバルドメむンはルヌティングゟヌンに分割されたす。

そしお、党䜓的な障害は、IGPゟヌン内がリンクステヌトプロトコルである堎合、それらの間で-ゟヌン内でのみ構築される実際の距離ベクトルネットワヌクトポロゞであり、内郚ルヌタヌは他の動䜜を知らないこずですゟヌン-特定のネットワヌクに入るために、特定のABRにパケットを送信する必芁があるこずのみが通知されたす。

぀たり、ネットワヌクがゟヌンに分割されおいる堎合、MPLS TEに問題がありたす。そのトポロゞでは、別のゟヌンからの宛先が特定のノヌドではなくクラりドであるため、CSPFはパス党䜓を蚈算できたせん。

そしおここで、明瀺的パスが助けになりたすEROオブゞェクトず混同しないでください。これは、LSPを構築しお管理する最も簡単な方法です。管理者は、LSPを敷蚭するノヌドを独立しお明瀺的に指定できたす。入力LSRは、これらのガむドラむンに正確に埓う必芁がありたす。これにより、CSPFアルゎリズムがさらに倚様になりたす。

明瀺的パスはどのようにゟヌンを突砎するのに圹立ちたすか䟋を芋おみたしょう。







䞭間点があるこずを明瀺しお瀺したす

明瀺的パスR1、R3、R5。



この明瀺的なパスにこのCSPFを䟛絊するず、R1からR3たでの゚リア0内で可胜なチャンクを構築したす。

圌が数えるものはEROに入力され、さらにExplicit-pathからの別のノヌドがR5に远加されたす。 R1、R2、R3。 EROに埓っおネットワヌクを介しおパスが送信され、R3に到達したす。圌は、䞀般に、自分が受取人ではなく、積み替えポむントに過ぎないこずを確認し、必芁なリ゜ヌスず受信ノヌドのアドレスに指定された条件を明瀺パスから取埗し、CSPFを開始したす。埌者は、EROに倉換される宛先R3、R4、R5ぞのノヌドの完党なリストを提䟛し、その埌すべおが暙準シナリオに埓っお発生したす。

぀たり、入力LSRず出力LSRが異なるゟヌンにある堎合、パス蚈算はゟヌンごずに個別に実行され、参照ポむントはABRです。



明瀺的パスはこの堎合に䜿甚されるだけでなく、LSPを配眮する必芁のないノヌドを介しおLSPを配眮する方法を明瀺的に指定できる、たたはその逆を明瀺的に指定できるため、䞀般に䟿利なツヌルであるこずを理解する必芁がありたす。

これに぀いおは、MPLS TE専甚の問題でさらに詳しく説明したす。



Link-State IGPはそれほど必芁ではないず蚀っお、圌らは私をwithに非難するこずができたす。たあ、私はEIGRPをmonocycネットワヌクで実行したいのですが、力はありたせん。たたは、RIPを掘り䞋げたいずいう奜䞭性的な衝動さえありたす。そしお今䜕TEをあきらめたすか

䞀般に、救いはありたすが、シスコの機噚でのみです-それはVerbatimず呌ばれたす。



結局、なぜLink-Stateプロトコルが必芁なのですかTEトポロゞ情報を収集し、CSPFは入力LSRから出力LSRぞのパスを構築したす。すごい玠晎らしい。 Explicit Path, ? .

, , CSPF.

. , .

:

 Router(config-if)# tunnel mpls traffic-eng path-option 1 explicit name <i>test</i> verbatim
      
      





CSPF.

, . , , .







RSVP TE









LDPが機胜するには、mpls ipコマンドが必芁でした。今ではもはや必芁ありたせん-それを削陀し、で始たる癜玙の状態。

ここで、mpls traffic-eng tunnelsが必芁です。TEトンネルずRSVP TE自䜓のサポヌトがグロヌバルに含たれおいたす。

 R1(config)#mpls traffic-eng tunnels
      
      





むンタヌフェむスでも同じように有効にする必芁がありたす。



 R1(config)# interface FastEthernet 0/0 R1(config-if)# mpls traffic-eng tunnels R1(config)# interface FastEthernet 0/1 R1(config-if)# mpls traffic-eng tunnels
      
      





ただ䜕も起きおいたせん。RSVPはサむレントです。



次に、TEデヌタを送信するためにIGPを拡匵したす。この䟋では、ISISを䜿甚したす。

 R1(config)#router isis R1(config-router)# metric-style wide R1(config-router)# mpls traffic-eng router-id Loopback0 R1(config-router)# mpls traffic-eng level-2
      
      





拡匵ラベルモヌドの有効化は必須です。そうでない堎合、TEは機胜したせん。

LSRで行ったように、LSR-ID

を蚭定したす。特定のISISレベルを蚭定する必芁がありたす。そうしないず、TEが機胜したせん。



突然OSPFを䜿甚する堎合
R1configmpls traffic-eng area 0

R1configroutermpls traffic-eng router-id Loopback0



これらの手順は、他のルヌタヌで繰り返す必芁がありたす。



その盎埌に、ISISはTEに関する情報の亀換を開始し







たす。ご芧のずおり、LSR-IDに関する情報が送信され、近隣TEをサポヌトするに関する拡匵情報、むンタヌフェむスに関する拡匵情報が送信されたす。



この時点で、TEDが圢成されたす。



ISISでトポロゞを確認できたす。show isisデヌタベヌスの詳现な



RSVPは、珟時点ではサむレントです。



次に、TEトンネルを構成したす。

 R1(config)# interface Tunnel1 R1(config-if)# ip unnumbered Loopback0 R1(config-if)# tunnel destination 6.6.6.6 R1(config-if)# tunnel mode mpls traffic-eng R1(config-if)# tunnel mpls traffic-eng path-option 10 dynamic
      
      





トンネルむンタヌフェむスは、ルヌタヌ䞊で非垞に甚途の広いものです。これらは、L2TP、GRE、IPIP、およびご芧のようにMPLS TEに䜿甚できたす。

ip unnumbered Loopback0は、トンネルの開始点がLoopback0むンタヌフェむスアドレスでなければならないこずを意味したす。

tunnel destination 6.6.6.6-トンネルむンタヌフェむスのナニバヌサルコマンドは、トンネルの終端である終端ポむントを決定したす。

トンネルモヌドmpls traffic-eng-タむプを蚭定したす。ここで、トンネル操䜜アルゎリズムが決定され、その構築方法が決たりたす。

tunnel mpls traffic-eng path-option 10 dynamic-このコマンドにより、CSPFは䞭間ノヌドを指定せずにパスを動的に構築できたす。



その前にすべおを正しく行った堎合、トンネルむンタヌフェむスは䞊昇するはずです。

 %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
      
      







どうしたの

R1はパスを送信したした。





行R1-R2でダンプが削陀されたした。



宛先アドレス、ERO、およびラベル芁求オブゞェクトに関心がありたす。トンネルで構成されおいる

宛先アドレスは6.6.6.6です。

明瀺的なルヌト

10.0.12.2- > 10.0.25.2- > 10.0.25.5- > 10.0.56.5- > 10.0.56.6。

぀たり、出力むンタヌフェむスのリンクアドレスず次のノヌドのリンクアドレスがそこに登録されたす。したがっお、各LSRは、Pathを送信するむンタヌフェむスを正確に認識しおいたす。

このEROには10.0.12.1はありたせん。これは、R1が送信前にすでに削陀しおいるためです。ラベルリク゚スト

があるずいう事実LSRがこのFECのラベルを割り圓おる必芁があるこずを瀺したす。

しかし、圌はこのパスに反応したせんでした長い -圌はさらに曎新送りたす。

以䞋のResvは、ResvがダりンストリヌムLSRから来た埌に送信されたす。



R5でも同じこずが起こりたす。





ダンプはR2-R5行で撮圱されたす。





行R2-R5でダンプが削陀されたした。



したがっお、PathはR6になりたす。圌はRSPV Resvを送り返したす。





ダンプはR5-R6行で取埗されたす。



ダンプは、Resvがノヌドからノヌドに送信されるこずを明確に瀺しおいたす。Label

オブゞェクトは、このFECに割り圓おられたラベルを枡したす。



R6がラベル0-Explisit Nullを割り圓おおいるこずに泚意しおください。䞀般に、これは通垞の状況です-これは、R5ずR6の間のMPLSラベルがたずえば、EXPフィヌルドの倀に埓っおパケットを凊理するために行われるように行われたすが、R6はすぐにラベル0をリセットし、その䞋にあるものを凊理する必芁があるこずを認識したした、ラベルテヌブルは怜玢したせんでした。

問題は、ラベルパケットVPNなどに耇数ある可胜性があるこずですが、RFC 3032および前述したようにに埓っお、R5はラベルスタック党䜓を削陀し、1぀でパケットを転送する必芁がありたすラベル0。この堎合、もちろんすべおが壊れたす。

実際、ラベル0がスタック䞊の唯䞀のものであるずいう芁件は正圓化されおいないようです。これに察するアプリケヌションはありたせん。したがっお、RFC 4182でこの制限は削陀されたした。スタック䞊のラベル0だけではない堎合がありたす。

興味深い機胜はPHPです。このための特別なラベルがあるずいう事実にもかかわらず、LSRはラベル0 を受け取ったずしおもPHPを実行したす。同じPepelnyakからの詳现。



R5はResvをR2に、R2をR1に転送したす。



行R1-R2でダンプが削陀されたした。



ここでわかるように、マヌクはすでに正垞です-16。



======================

タスク番号5



Resvを泚意深く芋おも、そこに行く必芁のあるパスは衚瀺されず、ノヌドのリストはタグを正垞に配垃し、LSPを構築するため。これはどのように解決されたすか



タスクの詳现はこちらです。

=======================





明瀺的なパス



パスを倉曎しおみたしょう-トラフィックはR1-R3-R4-R5-R6を通過する必芁がありたす。

それず同じくらい簡単明瀺的なパスを蚭定するだけです

 R1(config)# ip explicit-path name R1-to-R6-primary R1(cfg-ip-expl-path)# next-address 10.0.13.3 R1(cfg-ip-expl-path)# next-address 10.0.34.4 R1(cfg-ip-expl-path)# next-address 10.0.45.5 R1(cfg-ip-expl-path)# next-address 10.0.56.6
      
      





そしお、トンネルむンタヌフェむスに適甚したす。

 R1(config)# Interface Tunnel 1 R1(config-if)# tunnel mpls traffic-eng path-option 5 explicit name R1-to-R6-primary
      
      





前のルヌルよりも高い優先床5察10を蚭定しおいるこずに泚意しおください。぀たり、たずexplicit-pathが䜿甚され、問題がある堎合、R1はLSPをなんずか動的に構築しようずしたす。



トンネル構成は次のようになりたす。

 interface Tunnel1 ip unnumbered Loopback0 tunnel destination 6.6.6.6 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 5 explicit name R1-to-R6-primary tunnel mpls traffic-eng path-option 10 dynamic no routing dynamic
      
      





そしお、ここでEROの新しい運ぶPathメッセヌゞで







トンネルに関する情報を衚瀺するには、コマンドの実行MPLSトラフィック-ENGトンネルの堎合ショヌを







䞭間芋するこずが可胜である







LSPをFRR、ルヌスず厳しい資源の芁件の存圚䞋で圢成されおいる方法たた、MPLS TEの蚘事でいく぀かの問題を䞀通り読み、アフィニティなどを読みたす。



RSVP-TE最終構成ファむル。





QA



Q1 RSVP TE LSPずLDP LSPの違いは䜕ですか

厳密に蚀えば、䞊䜍プロトコルずMPLS自䜓の䞡方の芳点から、そのような抂念はたったくありたせん。LSP-それはLSPです-それは単なるラベルの切り替え方法です。

甚語CR-LSPConstRaintベヌスのLSPは区別できたす-RSVP TEによっお䜜成されたす。この点で、違いは、CR-LSPがトンネルむンタヌフェむスで指定された条件を満たすこずです。



Q2明瀺的パスずEROはどのように比范されたすか

トンネルに明瀺的パスが指定されおいる堎合、RSVPは明瀺的パスの芁件を考慮しおEROを生成したす。この堎合、各ノヌドをExplicit-Path to Egress LSRに登録しおも、RSVPは匕き続きデヌタをCSPFに送信したす。





Q3䞭間ノヌドの1぀がLDPRSVP TEをサポヌトしおいない堎合、たたはむンタヌフェむス/プラットフォヌムでプロトコルがオフになっおいる堎合、たずえば、このノヌドでIPに切り替えおから次のノヌドで再びMPLSに切り替えるようにLSPを構築したすか

RSVP TE Ingress LSR TED Egress LSR, Path, , LSP.

.



LDP, . , R2 LDP FE0/0 ( R5),

1) R1 FEC 6.6.6.6/32. 2: R2, — R3, — R2, LSP R2.

2) R2 , — 1.1.1.1. , . LSP R1 FEC 6.6.6.6/32 .

3) R5 FEC 6.6.6.6/32



぀たり、匕き裂かれたLSPを取埗したす{R1-R2、R5-R6}。しかし、実際にはそうではありたせん。そのためのLSPずラベルスむッチドにより、ラベルがずっず倉曎され、R1からR2 MPLS、R2からR5 IP、そしおR5からR6 MPLSに戻りたす。FEC 6.6.6.6/32のLSPはここにありたせん。通垞、通垞のトラフィックはここを通過したすが、たずえばVPNなどのMPLSアプリケヌションに぀いお話をするず、これは機胜したせん。





Q4さお、MPLSが必芁な理由は次の蚘事から明らかになりたす-これは䞀般に、゚ンゞニアの生掻を耇雑にするための䜕らかの人工的なナンセンスですが、なぜMPLS TEが必芁なのですか結局のずころ、IGPメトリックを䜿甚しお必芁な方法でトラフィックを誘導できたす。

たず、これは将来のリリヌスのトピックです。 しかし...

, , , , . , . , .

LSP , . TE .



たあ、䞀般的に、2぀のクラむアントに察しおそれぞれ40 Mb / sおよび50 Mb / sの保蚌されたチャネルが必芁な堎合、回線の䜿甚率をどのように远跡したすか䞀床、奇跡的な方法でルヌティングずQoSを蚈算しお蚭定し、目的のサヌビスレベルを提䟛したすが、突然3キロメヌトルの光孊系が䞀床に3か所で切断され、1週間修正するこずはできたせん。さらに、50 Mb / sの3぀のバックアップチャネルもありたすが、䞡方のクラむアントのトラフィックが1か所に飛び蟌み、すべおの正匏なSLAを吐き出したす。





Q5明瀺的ヌルず暗黙的ヌルのラベルの違いは䜕ですか私は本圓にそれらに぀いお知る必芁がありたすか

必芁です。 , MPLS LSR. «0», Egress LSR , . , TC MPLS, . .



ラベル「3」を䜿甚するコンセプトでは、Egress LSRで䞍芁なアクションを攟棄するこずにしたした。QoSを気にしない堎合たたはDSCPフィヌルドなどで優先床をコピヌした堎合、最埌のフラむトでトランスポヌトラベルを緊急に必芁ずするこずはありたせん。䞻なこずは、正しいラベルを送信するこずです。クリヌンなIPパケットがあった堎合、IPプロセスに枡し、E1があれば、ラベルスタックの堎合はストリヌムを目的のむンタヌフェむスに転送し、LFIBで怜玢し、さらにアクションを実行する必芁があるかどうかを確認したす。





Q6 1぀のFECに぀いお、LSRは垞に同じラベルをそのすべおのネむバヌに割り圓おたすか

ラベルスペヌスの抂念がありたす。

  • むンタヌフェむスラベルスペヌス
  • スロットラベルスペヌス
  • プラットフォヌムラベルスペヌス


, FEC .

— ( LSR), FEC .

, FEC , , . .








MPLSテクノロゞヌはラベル配垃プロトコルを芏制しないこずを理解するこずが重芁ですが、特定のネットワヌクでの最終結果は、異なるプロトコルを䜿甚するず倧きく異なる堎合がありたす。芪プロトコルおよびアプリケヌションは、LSPが誰であるか、たたはどのように構築されおいるかにかかわらず、LSPを䜿甚したす。

ずころで、TEを介したLPDシナリオは、珟代のネットワヌクでよく芋られたす。この堎合、たずえば、RSVP-TEを䜿甚しおトランスポヌトを線成し、トラフィック゚ンゞニアリングを実装し、LDPを䜿甚しおVPNタグを亀換したす。

MPLSヘッダヌの最初のラベルを曞き蟌む出力LSRは、パケットのパス党䜓を定矩したす。䞭間ルヌタヌは、単に1぀のラベルを別のラベルに倉曎したす。コンテンツは完党に䜕でもかたいたせん。このマルチプロトコルだけで、MPLSはさたざたなVPNサヌビスの基盀ずしお機胜できたす。





䟿利なリンク







蚘事の最埌の仕䞊げずしお、JDimaに感謝したす。Natasha Samoilenko

のタスクずこの蚘事の執筆を手䌝っおくれおありがずう。

KDPVは、プロゞェクトの玠晎らしいアヌティストであり友人であるNina Dolgopolovaによっお描かれたした。マキシム・ザ・グラックが

実斜した゚ラヌチェックず䞍正確な怜玢



All Articles