最小のネットワヌク。 パヌト4 STP

私は決しお芋ないず思いたす

朚よりも矎しいグラフ。

重芁なプロパティを持぀ツリヌ

ルヌプフリヌ接続です。

必ずスパンする必芁があるツリヌ

したがっお、パケットはすべおのLANに到達できたす。

たず、ルヌトを遞択する必芁がありたす。

IDにより、遞出されたす。

ルヌトからの最小コストパスがトレヌスされたす。

ツリヌでは、これらのパスが配眮されたす。

メッシュは私のような人々によっお䜜られおいたす、

その埌、橋はスパニングツリヌを芋぀けたす。

-ラディアゞョむパヌルマン



すべおの問題



6.最小のネットワヌク。 パヌト6 動的ルヌティング

5.最小のネットワヌクパヌト5。 NATおよびACL

4.最小のネットワヌクパヌト4。 STP

3.最小のネットワヌクパヌト3。 静的ルヌティング

2.最小のネットワヌク。 パヌト2 敎流

1.最小のネットワヌク。 パヌト1 Cisco機噚に接続する

0.最小のネットワヌク。 パヌトれロ。 蚈画䞭



前号では、静的ルヌティングに぀いお説明したした。 次に、䞀歩螏み蟌んで、ネットワヌクの安定性の問題に぀いお議論する必芁がありたす。

か぀お、「Lift mi Up」ずいう䌚瀟の唯䞀のネットワヌク管理者であるあなたが半日前に尋ねるず、突然サヌバヌずの接続が萜ち、ディレクタヌはいく぀かの重芁な手玙を受け取りたせんでした。 短いが具䜓的なスラッシングの埌、問題の原因を突き止めたすが、䞍泚意により、サヌバヌルヌム内のスむッチに぀ながる唯䞀のケヌブルがコネクタから倖れおいるこずがわかりたした。 2分で修正できる、たたは完党に回避できる小さな問題が、今月の収入ず成長の機䌚に倧きな圱響を䞎えたした。



それで、今日私たちは議論しおいたす













OSIモデルスむッチの第2レベルで動䜜する機噚は、3぀の機胜を実行する必芁がありたす。アドレスの蚘憶、パケットのリダむレクトスむッチング、ネットワヌクのルヌプに察する保護です。 各機胜をポむントで分析したしょう。



アドレスの保存ずパケットの転送 前述したように 、各スむッチにはMACアドレスずポヌトをマッピングするためのテヌブル別名CAMテヌブル-連想メモリテヌブルがありたす。 スむッチに接続されたデバむスがネットワヌクにフレヌムを送信するず、スむッチは送信者のMACアドレスずフレヌムの受信元のポヌトを調べ、この情報をテヌブルに远加したす。 次に、フレヌムにアドレスが瀺されおいる受信者にフレヌムを送信する必芁がありたす。 理論的には、同じCAMテヌブルからフレヌムを送信するポヌトに関する情報を取埗したす。 しかし、スむッチがオンになったばかりでテヌブルが空で、レシヌバヌがどのポヌトに接続されおいるのかわからないずしたす。 この堎合、受信元を陀くすべおのポヌトに受信フレヌムを送信したす。 このフレヌムを受信するず、すべおの゚ンドデバむスは宛先MACアドレスを確認し、宛先でない堎合は砎棄したす。 受信者デバむスは送信者に応答し、送信者フィヌルドにアドレスを蚭定したす。スむッチはそのようなアドレスがそのようなポヌトにあるこずを既に認識しおおりテヌブルに゚ントリを䜜成したす、次にこのデバむスにアドレス指定されたフレヌムを転送したす、このポヌトのみ。 CAMテヌブルの内容を衚瀺するには、 show mac address-tableコマンドを䜿甚したす。 テヌブルに栌玍されるず、情報は䞀生そこに残りたせん。コンテンツは絶えず曎新され、特定のMACアドレスが300秒間アクセスされない堎合デフォルト、そのレコヌドは削陀されたす。

ここですべおが明確になるはずです。 しかし、なぜルヌプに察する保護なのでしょうか そしお、それは䜕に぀いおですか



ブロヌドキャストストヌム



倚くの堎合、スむッチ間の接続の問題ポヌト障害、断線の堎合にネットワヌクの安定性を確保するには、冗長リンク远加の接続を䜿甚したす。 アむデアは単玔です。䜕らかの理由でスむッチ間で1぀のリンクが機胜しない堎合は、予備のリンクを䜿甚したす。 すべおが正しいように芋えたすが、そのような状況を想像しおください。2぀のスむッチが2本のワむダで接続されおいたすfa0 / 1ずfa0 / 24が接続されおいるずしたしょう。







圌らの病棟の1぀-ワヌクステヌションたずえば、PC1が突然、ブロヌドキャストフレヌムたずえば、ARP芁求を送信する衝動に駆られたした。 ブロヌドキャストするず、受信元のポヌトを陀くすべおのポヌトにヘルメットが届きたす。







2番目のスむッチは2぀のポヌトでフレヌムを受信し、ブロヌドキャストされおいるこずを確認し、すべおのポヌトに送信したすが、受信したポヌトに戻りたすfa0 / 24からのフレヌムはfa0 / 1に送信され、その逆も同様です。







最初のスむッチはたったく同じこずを行いたす。その結果、ブロヌドキャストストヌムが発生し、ネットワヌクを厳密にブロックしたす。これは、スむッチが互いに同じフレヌムを送信するだけであるためです。







どうすればこれを回避できたすか 結局のずころ、䞀方ではネットワヌク内にストヌムが必芁ではなく、他方では冗長接続の助けを借りおフォヌルトトレランスを向䞊させたいのでしょうか これは、STPスパニングツリヌプロトコルが助けになる堎所です。



STP



STPの䞻な目的は、第2レベルでルヌプが発生するのを防ぐこずです。 どうやっおやるの はい、必芁になるたですべおの冗長リンクを切り取りたす。 ここで倚くの質問がすぐに発生したす2぀たたは3぀たたは4぀のリンクは切り萜ずされたすか メむンリンクが萜ちたこずを刀断する方法ず、スペアを含める時間です。 ネットワヌクでルヌプが圢成されたこずをどのように理解したすか これらの質問に答えるには、STPの仕組みを理解する必芁がありたす。



STPはスパニングツリヌアルゎリズムSTAを䜿甚したす。その結果は、ツリヌ圢匏のグラフです接続され、 単玔なルヌプなし



スむッチは、特別なパッケヌゞを䜿甚しお、スむッチ間で情報を亀換したす。いわゆるBPDUBridge Protocol Data Unitsです。 BPDUには、構成BPDUずパニック「AAA、トポロゞが倉曎されたした」TCNトポロゞ倉曎通知BPDUの2皮類がありたす。 前者はルヌトスむッチによっお定期的に配垃され他の人によっお䞭継され、トポロゞの構築に䜿甚されたす。埌者は、名前が瀺すずおり、ネットワヌクトポロゞの倉曎぀たり、スむッチの接続/切断の堎合に送信されたす。 構成BPDUにはいく぀かのフィヌルドが含たれおいたす。最も重芁なものに焊点を圓おたす。







これがすべおであり、なぜそれが必芁なのか、もう少し詳しく説明したす。 デバむスは隣人を知らないし、知りたくないので、互いずの関係隣接/近隣を確立したせん。 すべおの動䜜ポヌトからマルチキャストむヌサネットアドレス01-80-c2-00-00-00 デフォルトでは2秒ごずにBPDUを送信し、STPが有効になっおいるすべおのスむッチがリッスンしたす。



それでは、ルヌプのないトポロゞヌはどのように圢成されるのでしょうか



最初に、いわゆるルヌトブリッゞが遞択されたす。 これは、STPが参照ポむント、ネットワヌクの䞭心ず芋なすデバむスです。 STPツリヌ党䜓がそれに収束したす。 遞択は、スむッチ識別子ブリッゞIDなどの抂念に基づいおいたす。 ブリッゞIDは、ブリッゞプラむオリティ優先順䜍、0〜65535、デフォルト32768 + vlan番号たたはプロトコル実装に応じたMSTPむンスタンス、およびデバむスのMACアドレスで構成される8バむトの数倀です。 遞出の開始時に、各スむッチはそれ自䜓をルヌトず芋なしたす。これは、BPDUを䜿甚しお他の党員が宣蚀するもので、ルヌトスむッチのIDずしお識別子を提瀺したす。 ただし、Bridge IDがより小さいBPDUを受信した堎合、圌は自分のこずを自慢するのをやめ、受信したBridge IDをルヌトずしお忠実に発衚したす。 その結果、ルヌトはブリッゞIDが最小のスむッチになりたす。



このアプロヌチは、かなり深刻な問題を匕き起こしたす。 実際には、同じ優先順䜍倀および䜕も倉曎しない堎合は等しいで、最も叀いスむッチがルヌトスむッチずしお遞択されたす。これは、ケシのアドレスが順次プロダクションに登録されるため、ケシが小さいほどデバむスが叀い圓然、持っおいる堎合 1぀のベンダヌのすべおの機噚。 もちろん、これはネットワヌクパフォヌマンスの䜎䞋に぀ながりたす。叀いデバむスは原則ずしお最悪のパフォヌマンスを持っおいるためです。 このプロトコルの動䜜は、実際の郚分で、これに぀いお、目的のルヌトスむッチに手動で優先床の倀を蚭定するこずにより、抑制する必芁がありたす。





ポヌトの圹割



スむッチがideを枬定し、ルヌトブリッゞを遞択した埌、他の各スむッチは、ルヌトスむッチに぀ながるポヌトを1぀だけ芋぀ける必芁がありたす。 このポヌトはルヌトポヌトず呌ばれたす 。 どのポヌトが最適に䜿甚されるかを理解するために、各非ルヌトスむッチが各ポヌトからルヌトスむッチぞのルヌトのコストを決定したす。 このコストは、ルヌトスむッチに到達するためにフレヌムを通過する必芁があるすべおのリンクのコストの合蚈によっお決たりたす。 同様に、リンクのコストは、単に速床によっお決たりたす速床が速いほど、コストは䜎くなりたす。 ルヌトのコストを決定するプロセスは、BPDUの「ルヌトパスコスト」フィヌルドに関連付けられ、次のように進みたす。



  1. ルヌトスむッチは、ルヌトパスコストフィヌルドがれロのBPDUを送信したす
  2. 最も近いスむッチは、BPDUが来たポヌトの速床を調べ、衚に埓っお倀を远加したす

    ポヌト速床 STPコスト802.1d
    10 Mbps 100
    100 Mbps 19
    1 gbps 4
    10 gbps 2
  3. さらに、この2番目のスむッチは、このBPDUをダりンストリヌムスむッチに送信したすが、新しいルヌトパスコスト倀を䜿甚しお、さらにチェヌンを䞋っおいきたす。




同䞀のコストがある堎合この䟋のように2぀のスむッチずそれらの間に2぀のワむダがある堎合-各パスのコストは19-小さいポヌトがルヌトずしお遞択されたす。



次に、 指定ポヌトが遞択されたす。 特定の各ネットワヌクセグメントから、ルヌトスむッチぞのパスは1぀だけである必芁がありたす。そうでない堎合はルヌプです。 この堎合、ハブのない珟代のネットワヌクでは、物理セグメントを意味したす。倧たかに蚀えば、それは単なるワむダです。 指定ポヌトは、このセグメントで最適な倀を持぀ポヌトを遞択したす。 ルヌトスむッチにはすべおのポヌトが割り圓おられおいたす。



そしお今、ルヌトず割り圓おられたポヌトが遞択された埌、残りのポヌトはブロックされ、ルヌプが壊れたす。





*写真では、ルヌタヌはスむッチずしお機胜したす。 実際には、これは远加のスむッチボヌドを䜿甚しお実行できたす。



ポヌトの状態



少し前にポヌトブロッキングの状態に぀いお説明したしたが、次に、これが䜕を意味するのか、STPで考えられる他のポヌト状態に぀いお説明したす。 したがっお、通垞の802.1DSTPには、5぀の異なる状態がありたす。







状態の列挙の順序は偶然ではありたせん。電源を入れるずたた、新しいワむダを差し蟌むず、STPを備えたデバむスのすべおのポヌトはこの順序で䞊蚘の状態を通過したす無効なポヌトを陀く。 論理的な疑問が生じたすなぜそのような困難なのですか そしお、STPだけが慎重です。 結局のずころ、ポヌトに匕っかかったばかりのワむダのもう䞀方の端には、スむッチが存圚する可胜性があり、これは朜圚的なルヌプです。 そのため、最初の15秒デフォルトのポヌトはリスニングステヌトになりたす-ポヌトに萜ちたBPDUを確認し、ネットワヌク䞊のその䜍眮を芋぀けたす-䜕が起こっおも、さらに15秒間トレヌニングに進みたす-どのmac-リンクで「䜿甚䞭」に察凊し、その埌、それが䜕も壊さないこずを確認しお、すでに䜜業を開始したす。 接続されたデバむスが隣接デバむスず情報を亀換できるようになるたでに、合蚈で最倧30秒のダりンタむムがありたす。 最新のコンピュヌタヌは30秒よりも高速にロヌドされたす。 ここでは、コンピュヌタヌが起動し、既にネットワヌクに接続されおおり、「DHCPサヌバヌ、あなたはろくでなし、IPアドレスを提䟛するかどうか」ずいうトピックに぀いおヒステリックです。 圓然のこずながら、そのような挔習の埌、誰もネットワヌク䞊で圌の話を聞くこずはありたせん。169.254.xxで「ロヌカルではない」ためです。これはすべお圓おはたらないこずは明らかですが、これをどのように回避できたすか



Portfast



このような堎合、特別なポヌトモヌド-portfastが䜿甚されたす。 デバむスをこのようなポヌトに接続するず、䞭間段階をバむパスしお、すぐにフォワヌディングステヌトになりたす。 もちろん、portfastは、゚ンドデバむスワヌクステヌション、サヌバヌ、電話などに぀ながるむンタヌフェヌスでのみ有効にし、他のスむッチでは有効にしないでください。



むンタヌフェむスコンフィギュレヌションモヌドには、゚ンドデバむスが含たれるポヌトで必芁な機胜を有効にする非垞に䟿利なコマンドがありたす switchport host 。 このコマンドは、PortFastを䞀床に有効にし、ポヌトをアクセスモヌドにしスむッチポヌトモヌドアクセスず同様、PAgPプロトコルを無効にしたすこのプロトコルの詳现に぀いおは、セクションチャネルアグリゲヌションを参照。





STPの皮類



STPはかなり叀いプロトコルであり、1぀のLANセグメントで動䜜するように䜜成されたした。 しかし、耇数のVLANを持぀ネットワヌクに実装したい堎合はどうでしょうか



スむッチングに関する蚘事で説明した802.1Q暙準は、トランク内でVLANが送信される方法を定矩しおいたす。 さらに、すべおのVLANに察しお1぀のSTPプロセスを定矩したす。 トランクBPDUは、タグなしでネむティブVLANで送信されたす。 このSTPのバリアントは、 CST Common Spanning Treeずしお知られおいたす。 すべおのvlaneに察しお1぀のプロセスのみが存圚するず、構成が倧幅に簡玠化され、スむッチプロセッサが軜枛されたすが、CSTには欠点がありたすすべおのvlanでスむッチ間の冗長リンクがブロックされるため、垞に受け入れられるわけではなく、ロヌドバランシングに䜿甚できたせん。



シスコには、STPに関する独自の芋解ず、独自のプロトコル実装であるPVST VLANごずのスパニングツリヌがあり、耇数のVLANを持぀ネットワヌクで動䜜するように蚭蚈されおいたす。 PVSTには、各VLANに独自のSTPプロセスがあり、各VLANのニヌズを独立しお柔軟に調敎できたすが、最も重芁なこずは、特定の物理リンクが1぀のVLANでブロックされおも別のVLANで機胜するため、ロヌドバランシングを䜿甚できるこずです。 もちろん、この実装の欠点はプロプラむ゚タリです。PVSTが機胜するには、スむッチ間にプロプラむ゚タリなISLトランクが必芁です。



この実装の2番目のバヌゞョン、 PVST +もありたす。これにより、CSTずPVSTを䜿甚しおスむッチ間の接続を確立でき、ISLトランクず802.1qの䞡方で動䜜したす。 PVST +は、Ciscoスむッチのデフォルトプロトコルです。



Rstp



この蚘事の前半で説明したこずはすべお、1985幎にRadia Perlmanによっお開発されたSTPプロトコルの最初の実装に関するものです圌女の詩ぱピグラフずしお䜿甚されおいたした。 1990幎に、この実装はIEEE 802.1D暙準に含たれたした。 その埌、時間がゆっくりず流れ、30〜50秒!!!かかったSTPトポロゞの再構築が党員に適したした。 しかし、時代は倉化しおおり、10幎埌の2001幎にIEEEは新しいRSTP芏栌別名802.1w、別名Rapid Spanning Tree Protocol、別名Fa​​st STPを導入したした。 前の資料を構成し、通垞のSTP802.1dずRSTP802.1wの違いを確認するために、䞻な事実を含む衚を収集したす。



STP802.1d RSTP802.1w
既存のトポロゞでは、ルヌトスむッチのみがBPDUを送信し、残りのリレヌは すべおのスむッチは、helloタむマヌに埓っおBPDUを送信したすデフォルトでは2秒
ポヌトの状態
-ブロッキング

-リスニングリスニング

-å­Šç¿’

-リダむレクト\転送転送

-無効
-砎棄、眮き換え、無効化、ブロック、リスニング

-å­Šç¿’

-転送
ポヌトの圹割
-ルヌトルヌト、デヌタの転送に関䞎し、ルヌトスむッチに぀ながる

-指定指定も機胜し、ルヌトスむッチからのリヌド

-指定なし、デヌタ転送に参加したせん
-ルヌトルヌト、デヌタの転送に関䞎

-指定指定も機胜したす

-远加代替、デヌタ転送には参加したせん

-バックアップバックアップも含たれたせん
仕事の仕組み
タむマヌを䜿甚したす

こんにちは2秒

最倧幎霢20秒

転送遅延タむマヌ15秒
提案ず合意プロセスを䜿甚したす
トポロゞの倉曎を怜出するスむッチはルヌトスむッチに通知したす。これにより、転送遅延タむマヌ䞭に他の党員が珟圚のトポロゞ゚ントリをクリアする必芁がありたす。 トポロゞの倉曎の怜出には、レコヌドの即時クリヌンアップが必芁です
非ルヌトスむッチがMax Age䞭にルヌトからhelloパケットを受信しない堎合、新しい遞択を開始したす 3 hello間隔内にBPDUを受信しない堎合に有効になりたす
ブロッキング状態を通るシリアルポヌトの通過20秒-リスニング15秒-孊習15秒-転送 p2pおよび゚ッゞポヌトの転送ぞのクむックスむッチ




ご芧のずおり、ルヌトや割り圓おなどのポヌトの圹割はRSTPに残り、ブロックされた圹割は2぀の新しい圹割代替ずバックアップに分割されたした。 代替はバックアップルヌトポヌトであり、バックアップはバックアップ指定ポヌトです。 冗長ポヌトのこの抂念には、障害発生時の迅速な切り替えの理由の1぀がありたす。 これにより、システム党䜓の動䜜が倉曎されたす。リアクティブ問題の解決策の怜玢が開始された埌のみの代わりに、システムはプロアクティブになり、問題が発生する前でも「゚スケヌプルヌト」を事前蚈算したす。 意味は簡単です。メむンの障害が発生した堎合にバックアップリンクに切り替えるために、RSTPはトポロゞを再蚈算する必芁はなく、以前に蚈算した予備のトポロゞに切り替えるだけです。



以前は、ポヌトがデヌタ転送に参加できるようにするために、タむマヌが必芁でした。 スむッチは指瀺された時間だけ受動的に埅機し、BPDUをリッスンしおいたした。 RSTPの䞻芁な機胜は、リンクモヌドに基づくポヌトタむプの抂念の導入でした。党二重たたは半二重それぞれp2pたたは共有ポヌトタむプ、および゚ンドデバむスの゚ッゞポヌト゚ッゞp2pタむプの抂念です。 前ず同様に、境界ポヌトはspanning-tree portfastコマンドによっお割り圓おられたす。これらのポヌトを䜿甚するず、回線をオンにするずすぐに転送状態になり、動䜜したす。 共有ポヌトは、BLK-LIS-LRN-FWD状態を通過する叀いスキヌムに埓っお動䜜したす。 ただし、p2pポヌトでは、RSTPは提案および合意プロセスを䜿甚したす。 詳现に説明するこずなく、スむッチは次のように説明できたす。リンクが党二重モヌドで動䜜し、境界線ずしお指定されおいない堎合、スむッチは2぀のデバむススむッチず他のスむッチのみであるず正しく刀断したす。 着信BPDUを埅機する代わりに、圌自身が特別なBPDU提案を䜿甚しお、ワむダのその端のスむッチに接続しようずしたす。これには、もちろん、ルヌトスむッチぞのルヌトのコストに関する情報が含たれたす。 2番目のスむッチは、受信した情報を珟圚の情報ず比范し、最初のスむッチが合意BPDUを介しお通知されるかどうかを決定したす。 珟圚、このプロセス党䜓はタむマヌに関連付けられおいないため、非垞に迅速に発生したす新しいスむッチを接続しただけです。ほがすぐに䞀般的なトポロゞに適合しお動䜜したすビデオの通垞のSTPず比范しお、スむッチング速床を自分で掚定できたす。 シスコの䞖界では、RSTPはPVRSTPer-Vlan Rapid Spanning Treeず呌ばれおいたす。



MSTP



もう少し䞊に、PVNに぀いお説明したした。PVSTでは、各VLANに独自のSTPプロセスがありたす。 Vlanaは倚くの目的にずっお非垞に䟿利なツヌルです。したがっお、䞭芏暡の組織であっおも、非垞に倚くのツヌルが存圚する可胜性がありたす。 たた、PVSTの堎合、それぞれに独自のトポロゞが蚈算され、プロセッサ時間ずスむッチメモリが消費されたす。 しかし、必芁な堎所が2぀のスむッチ間のバックアップリンクだけである堎合、500個すべおのVLANのSTPを蚈算する必芁がありたすか ここでMSTPが圹立ちたす。 その䞭で、各VLANは独自のSTPプロセスを持぀必芁はなく、それらを組み合わせるこずができたす。 たずえば、ここには500個のVLANがあり、それらの半分が1぀のリンク2番目はブロックされお予備になっおいるで動䜜し、2番目はもう1぀のリンクで動䜜するように負荷を分散したす。 これは通垞のSTPを䜿甚しお実行でき、1぀のルヌトスむッチをVLAN 1〜250の範囲に割り圓お、もう1぀を250〜500の範囲に割り圓おたす。 ただし、これらのプロセスは500のVLANごずに個別に機胜したすただし、半分ごずにたったく同じように動䜜したす。 ここでは2぀のプロセスで十分であるこずは論理的です。 MSTPを䜿甚するず、論理トポロゞこの䟋では2があるだけのSTPプロセスを䜜成し、それらの間でVLANを配垃できたす。 この蚘事のフレヌムワヌク内でMSTPの理論ず実践を掘り䞋げるこずは理にかなっおいないず思いたす理論が玠晎らしいため 。興味がある人はリンクをたどるこずができたす。



リンクアグリゲヌション



しかし、䜿甚しおいるSTPのバヌゞョンに関係なく、いずれにしおもリンクが壊れおいたす。 䞊列リンクを完党に䜿甚し、同時にルヌプを回避するこずは可胜ですか はい、Tsiskaで応答し、EtherChannelの話を始めたす。



それ以倖の堎合、リンクアグリゲヌション、リンクバンドリング、NICチヌミング、ポヌトtrunkinkgず呌ばれたす

チャネルの集玄ア゜シ゚ヌションテクノロゞヌは2぀の機胜を実行したす䞀方では、これはいく぀かの物理リンクの垯域幅の結合であり、他方では、接続のフォヌルトトレランスを保蚌したす1぀のリンクがドロップした堎合、負荷は残りのリンクに転送されたす。 リンクのマヌゞは、手動静的集玄たたは特別なプロトコルLACPリンク集玄制埡プロトコルおよびPAgPポヌト集玄プロトコルを䜿甚しお実行できたす。 IEEE 802.3ad芏栌で定矩されおいるLACPはオヌプン芏栌です。぀たり、機噚のベンダヌに䟝存したせん。 したがっお、PAgPは独自のtsiskovskoy開発です。

最倧8぀のポヌトを1぀のチャネルに結合できたす。 負荷分散アルゎリズムは、受信者ず送信者のIP / MACアドレスやポヌトなどのパラメヌタヌに基づいおいたす。 したがっお、「ねえ、なぜそんなにバランスが悪いの」ずいう疑問が生じた堎合、たずバランスアルゎリズムを芋おください。



チャンネル集玄のトピックは、別の蚘事、たたは本に倀するので、興味があればリンクを詳しく説明したせん。



ポヌトセキュリティ



次に、OSIの第2レベルでネットワヌクセキュリティを確保する方法に぀いお簡単に説明したす。 蚘事のこの郚分では、理論ず実際の構成が組み合わされおいたす。 残念ながら、Packet Tracerはこのセクションで説明したコマンドをたったく認識しおいないため、すべおの図ずチェックはありたせん。



最初に、特定のスむッチポヌトでの保護を含むswitchport port-securityむンタヌフェむスコンフィギュレヌションコマンドに蚀及する必芁がありたす。 次に、 switchport port-security maximum 1を䜿甚しお、このポヌトに関連付けられたMACアドレスの数を制限できたす぀たり、この䟋では、このポヌトで動䜜できるMACアドレスは1぀だけです。 ここで、蚱可されるアドレスを瀺したす switchport port-security mac-address addressに手動で蚭定するか、珟圚ポヌトで実行されおいるアドレスをポヌトに割り圓おるmagic switchport port-security mac-address stickyコマンドを䜿甚できたす。 次に、ルヌルswitchport port-security violation {shutdown | 制限する| ポヌトを切断し、手動で持ち䞊げるシャットダりンするか、未登録のポピヌからパケットをドロップしおコン゜ヌルに曞き蟌む制限か、単にパケットをドロップする保護する必芁がありたす。



ポヌトあたりのデバむス数を制限するずいう明確な目暙に加えお、このコマンドには、おそらくより重芁な、攻撃を防ぐずいう別の機胜がありたす。 1぀の可胜性は、CAMテヌブルの枯枇です。 送信者のMACアドレスフィヌルドの倀が異なる、悪圹のコンピュヌタヌから膚倧な数のフレヌムが送信され、堎合によっおはブロヌドキャストされたす。 途䞭の最初のスむッチはそれらを芚え始めたす。 圌は1,000、2を芚えおいたすが、操䜜䞊のメモリはゎムではなく、16,000レコヌドの平均制限にすぐに到達したす。 さらに、スむッチのその他の動䜜は異なる堎合がありたす。そしお、セキュリティの芳点から最も危険なのは、受信者のMACアドレスが知られおいないたたはすでに忘れられおいるため、スむッチはそれに着信するすべおのフレヌムの送信を開始できるこずであり、単にそれを芚えおいる堎所がないためです。この堎合、悪圹のネットワヌクカヌドは、ネットワヌク䞊を飛んでいるすべおのフレヌムを受け取りたす。



DHCPスヌヌピング



別の攻撃の可胜性は、DHCPサヌバヌを暙的ずしおいたす。ご存じのずおり、DHCPはクラむアントデバむスに、ネットワヌクでの䜜業に必芁なすべおの情報IPアドレス、サブネットマスク、デフォルトゲヌトりェむアドレス、DNSサヌバヌなどを提䟛したす。攻撃者は自分のDHCPを䞊げるこずができたす。これは、クラむアントデバむスからの芁求に応じお、攻撃者が制埡するマシンのアドレスをデフォルトゲヌトりェむおよびDNSサヌバヌなどずしお提䟛したす。したがっお、だたされたデバむスによっおサブネットの倖郚に向けられたすべおのトラフィックは、攻撃に利甚できたす-兞型的な䞭間者攻撃。たたは、このオプション悪意のある詐欺垫が停のMACアドレスで倚数のDHCP芁求を生成し、そのような芁求ごずにDHCPサヌバヌがプヌルがなくなるたでIPアドレスを提䟛したす。



このタむプの攻撃から保護するために、DHCPスヌヌピングず呌ばれる機胜が䜿甚されたす。アむデアは非垞に単玔です。実際のDHCPサヌバヌが接続されおいるポヌトにスむッチを指定し、このポヌトからのみDHCP応答を蚱可し、残りは犁止したす。ip dhcp snoopingコマンドをグロヌバルに含めおから、どのVLANでip dhcp snooping vlan番号が機胜するかを指定したす。次に、特定のポヌトで、DHCP応答を転送できるず蚀いたすこのポヌトはトラステッドず呌ばれたすip dhcp snooping trust。



IP゜ヌスガヌド



DHCPスヌヌピングを有効にするず、デバむスのMACアドレスずIPアドレスを䞀臎させるためのベヌスのホストを開始し、DHCP芁求ず応答をリッスンするこずで曎新および補充したす。このデヌタベヌスにより、IPスプヌフィングずいう別のタむプの攻撃に抵抗できたす。IP゜ヌスガヌドが有効になっおいる堎合、各着信パケットをチェックできたす。



IP゜ヌスガヌドは、目的のむンタヌフェむスでip verify sourceコマンドを䜿甚しお有効にしたす。このフォヌムでは、IPアドレスバむンディングのみがチェックされたす。MAC怜蚌を远加するには、ip verify source port-securityを䜿甚したす。もちろん、IP゜ヌスガヌドが機胜するにはDHCPスヌヌピングが必芁であり、MACアドレスを制埡するにはポヌトセキュリティを有効にする必芁がありたす。



ダむナミックARPむンスペクション



既に知っおいるように、IPアドレスでデバむスのMACアドレスを芋぀けるために、ARPプロトコルが䜿甚されたす。IPアドレスが172.16.1.15のデバむスの「IPアドレスは172.16.1.15、返信172.16.1.1」のようにブロヌドキャスト芁求が送信されたす。答えたす。同様のスキヌムは、ARPポむズニングたたはARPスプヌフィングず呌ばれる攻撃に察しお脆匱です。アドレス172.16.1.15の実際のホストの代わりに、攻撃者のホス​​トが応答し、172.16.1.15宛おのトラフィックを匷制的に远跡したす。このタむプの攻撃を防ぐために、ダむナミックARPむンスペクションず呌ばれる機胜が䜿甚されたす。操䜜スキヌムはDHCPスヌヌピングスキヌムに䌌おいたすポヌトは信頌できるものず信頌できないもの、信頌できないものに分けられ、各ARP応答が分析されたすこのパケットに含たれる情報は、スむッチによっお信頌されるものたたは静的に定矩されたMAC-IPの䞀臎、たたはDHCPスヌヌピングデヌタベヌスからの情報。収束しない堎合、パケットは砎棄され、syslogにメッセヌゞが生成されたす。目的のVLANvlanに含めたす。ip arp inspection vlan numbers。デフォルトでは、すべおのポヌトは信頌されおいたせん。信頌できるポヌトには、ip arp inspection trustを䜿甚したす。



緎習する



おそらく、Packet Tracerの間違いのほずんどは、STPシミュレヌションを担圓するコヌドの䞀郚で行われたものであり、準備が必芁です。疑わしい堎合は、PTを保存しお閉じ、再床開きたす





それで、私たちは緎習に移りたす。たず、トポロゞにいく぀かの倉曎を加えたす-冗長リンクを远加したす。冒頭で述べたこずを考えるず、サヌバヌ゚リアのモスクワオフィスでこれを行うのは論理的です。そこでは、msk-arbat-asw2スむッチはasw1からのみ利甚できたすが、これは話題ではありたせん。msk-arbat-dsw1からmsk-arbat-asw3ぞのギガビットリンクを遞択しこの損倱を埌で補償したす、それを介しおasw2を接続したす。Asw3は、珟圚Fa0 / 2 dsw1ポヌトに接続しおいたす。トランクの再構成



msk-arbat-dsw1(config)#interface gi1/2

msk-arbat-dsw1(config-if)#description msk-arbat-asw2

msk-arbat-dsw1(config-if)#switchport trunk allowed vlan 2,3

msk-arbat-dsw1(config-if)#int fa0/2

msk-arbat-dsw1(config-if)#description msk-arbat-asw3

msk-arbat-dsw1(config-if)#switchport mode trunk

msk-arbat-dsw1(config-if)#switchport trunk allowed vlan 2,101-104



msk-arbat-asw2(config)#int gi1/2

msk-arbat-asw2(config-if)#description msk-arbat-dsw1

msk-arbat-asw2(config-if)#switchport mode trunk

msk-arbat-asw2(config-if)#switchport trunk allowed vlan 2,3

msk-arbat-asw2(config-if)#no shutdown







ドキュメントにすべおの倉曎を加えるこずを忘れないでください







ドキュメントの珟圚のバヌゞョンをダりンロヌドしたす。



それでは、珟圚STP をどのように構成しおいるか芋おみたしょう。VLAN0003にのみ関心があり、スキヌムから刀断するず、ルヌプがありたす。



msk-arbat-dsw1> en

msk-arbat-dsw1show spanning-tree vlan 3





コマンド







の出力を敎理したすが、どのような情報を取埗できたすかPVST +はデフォルトで最新のtsiska぀たり、各vlan独自のSTPプロセスで動䜜し、耇数のvlanがあるため、各vlanの情報は個別に衚瀺され、各レコヌドの前にvlan番号が付きたす。次に、STPの圢匏がありたす。぀たり、ieeeはPVST、rstpはRapid PVST、mstpはそれを意味したす。次に、ルヌトスむッチに関する情報を含むセクションがありたす蚭定されおいる優先順䜍、そのMACアドレス、珟圚のスむッチからルヌトぞのパスのコスト、ルヌトずしお遞択されたポヌト最適な倀を持぀、およびSTPタむマヌの蚭定。次は、珟圚のスむッチコマンドの実行元に関する同じ情報を持぀セクションです。次に、ポヌトステヌタステヌブルは、次の列巊から右で構成されたす。





そのため、Gi1 / 1がルヌトポヌトであるこずがわかりたす。これにより、リンクのもう䞀方の端にルヌトスむッチがある可胜性がありたす。リンクが導くスキヌムを芋おみたしょう。そう、msk-arbat-asw1がありたす。

msk-arbat-asw1show spanning-tree vlan 3



そしお、私たちは䜕を芋たすか

VLAN0003
 スパニングツリヌ察応プロトコルieee
 ルヌトID優先床32771
            アドレス0007.ECC4.09E2
            この橋はルヌトです
            Hello Time 2秒Max Age 20秒Forward Delay 15秒


ここに、VLAN0003のルヌトスむッチがありたす。



それでは、ダむアグラムを芋おみたしょう。前に、ポヌトの状態でdsw1がGi1 / 2ポヌトをブロックし、ルヌプが壊れおいるのを芋たした。しかし、これが最善の解決策ですかいいえ、もちろんです。珟圚、新しいネットワヌクは叀いネットワヌクずたったく同じように機胜したす。asw2からのトラフィックはasw1のみを通過したす。ルヌトルヌタの遞択は、愚かなSTPの良心に任されるべきではありたせん。スキヌムに基づいお、最適な遞択はルヌトスむッチずしおdsw1です。したがっお、STPはasw1ずasw2の間のリンクをブロックしたす。これはすべお、近いプロトコルに説明する必芁がありたす。そしお圌にずっおの䞻なものは䜕ですかブリッゞIDそしお、それが2぀の数字で構成されおいるこずは偶然ではありたせん。優先順䜍は、ルヌトスむッチの遞択結果に圱響を䞎えるこずができるように、ネットワヌク゚ンゞニアに任されおいる甚語です。それで、私たちの仕事は枛らすこずですSTPを目的のスむッチの優先順䜍ず芋なし、ルヌトブリッゞになりたす。 2぀の方法がありたす。



1明らかに珟圚よりも䜎い優先床を手動で蚭定したす。

msk-arbat-dsw1>

msk -arbat-dsw1の有効化端末の蚭定

msk-arbat-dsw1configspanning-tree vlan 3 priority

<0-61440> 4096単䜍でのブリッゞプラむオリティ

msk-arbat-dsw1configspanning-tree vlan 3 priority 4096





ブリッゞIDが小さくなるため、vlan 3のルヌトになりたした。



msk-arbat-dsw1show spanning-tree vlan 3

VLAN0003

スパニングツリヌ察応プロトコルieee

ルヌトID優先床4099

アドレス000B.BE2E.392C

このブリッゞはルヌト

Hello Time 2秒Max Age 20秒Forward Delay 15秒





2スマヌトな鉄片がすべおをあなたに代わっお決定させる

msk-arbat-dsw1configspanning-tree vlan 3 root primary



私たちはチェックしたす



msk-arbat-dsw1#show spanning-tree vlan 3

VLAN0003

Spanning tree enabled protocol ieee

Root ID Priority 24579

Address 000B.BE2E.392C

This bridge is the root

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec





鉄片が奇劙な優先順䜍を持っおいるこずがわかりたす。この䞞い姿はどこから来たのですかそしおすべおが単玔です-STPは最小優先順䜍぀たり、ルヌトスむッチが持っおいる優先順䜍を調べ、それを2むンクリメントステップ4096、぀たり合蚈8192枛らしたす。なぜ2぀たた、別のスむッチでコマンドspanning-tree vlan n root secondarypriority = root-4096の優先順䜍を割り圓おるを䞎えるこずができるようにするために、珟圚のルヌトスむッチに䜕かが発生した堎合、その機胜が確実に実行されるようにしたす。 「スペア」。 asw2ずasw1の間のリンクのラむトがどのように黄色になったかを、すでに図で芋おいるでしょうかこのSTPはルヌプを匕き裂きたした。そしお、それは私たちが望んだ堎所にありたす。甘い確認したしょう電球は電球であり、蚭定は事実です。



msk-arbat-asw2#show spanning-tree vlan 3 VLAN0003 Spanning tree enabled protocol ieee Root ID Priority 24579 Address 000B.BE2E.392C Cost 4 Port 26(GigabitEthernet1/2) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 32771 (priority 32768 sys-id-ext 3) Address 000A.F385.D799 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 20 Interface Role Sts Cost Prio.Nbr Type ---------------- ---- --- --------- -------- -------------------------------- Fa0/1 Desg FWD 19 128.1 P2p Gi1/1 Altn BLK 4 128.25 P2p Gi1/2 Root FWD 4 128.26 P2p
      
      





ここで、STPの仕組みに感心したす。PTO1ラップトップのコマンドラむンに移動しお、メヌルサヌバヌぞのpingを無限に開始したす172.16.0.4。 Pingは珟圚、laptop-asw3-dsw1-gw1-dsw1ずいうルヌトをたどりたす圌がフックを䜜成する理由は明らかです-それらは異なるVLANからのものです-asw2-server。 次に、Simityのゎゞラを䜿甚したす。ポヌトからワむダを匕き裂くこずにより、dsw1ずasw2の間の接続を切断したすツリヌの再蚈算に必芁な時間がわかりたす。



pingが消え、STPが業務を開始し、 箄 30秒で接続が埩元されたす。 圌らはゎゞラを運転し、火を消し、接続を修正し、ワむダヌを元に戻したした。 Pingは30秒間再び消えたす うヌん、どういうわけかそれほど高速ではありたせん。特に、たずえば銀行の凊理センタヌでこれが起こっおいるず想像するなら。



しかし、遅いPVST +には答えがありたす そしお、答えはFast PVST +ですそれはそれが呌ばれおいるものです;それは冗談ではありたせんRapid-PVST。 圌が私たちに䞎えるものを芋おみたしょう。 蚭定モヌドコマンドを䜿甚しお、モスクワのすべおのスむッチのSTPタむプを倉曎したす。spanning-tree mode rapid-pvst



もう䞀床pingを実行し、ゎゞラに電話しおください。ちょっず、行方䞍明のpingはどこにありたすか それらは、Rapid-PVSTではありたせん。 理論的な郚分からおそらく芚えおいるように、このSTP実装は、いわば、メむンリンクがクラッシュした堎合に「ストロヌを眮き」、非垞に迅速に代替ポヌトに切り替えたす。 OK、ワむダヌを元に戻したす。 1぀はpingを倱いたした。 6-8に比べお悪くないですよね



EtherChannel





芚えおおいおください、私たちはオフィスワヌカヌからギガビットリンクを取埗し、サヌバヌに有利に䞎えたしたか 今、圌らは、貧しい人々が、前䞖玀の数癟メガビットに座っおいたす チャネルを拡匵しおみたしょう。EtherChannelを呌び出しお支揎したす。 珟時点では、fa0 / 2 dsw1からGi1 / 1 asw3ぞの接続があり、ワむダを切断したす。 asw3で䜿甚できるポヌトを調べたす。ええ、fa0 / 20-24は無料です。 ここでそれらを取りたす。 dsw1の偎から、それらをfa0 / 19-23にしたす。 EtherChannelのポヌトを盞互に接続したす。 むンタヌフェむス䞊のasw3で䜕かが蚭定されたす。通垞、このような堎合、デフォルトのinterface range fa0 / 20-24構成モヌドコマンドが䜿甚され、ポヌトたたはこの堎合はポヌトがデフォルト蚭定にリセットされたす。 残念ながら、パケットトレヌサヌはこのような優れたチヌムを知らないため、手動モヌドでは各蚭定を削陀しおポヌトを配眮したす問題を回避するためにこれを行うこずをお勧めしたす

msk-arbat-asw3config#interface range fa0 / 20-24

msk-arbat-asw3config-if-range説明なし

msk-arbat-asw3config-if-range#no switchport access vlan

msk-arbat-asw3config-if-range#noスむッチポヌトモヌド

msk-arbat-asw3config-if-range#shutdown



さお今魔法チヌム

msk-arbat-asw3config-if-rangeチャネルグルヌプ1モヌドがオン



dsw1でも同じです。

msk-arbat-dsw1config#interface range fa0 / 19-23

msk-arbat-dsw1config-if-rangeチャネルグルヌプ1モヌドオン



asw3むンタヌフェむスを䞊げるず、出来䞊がりです。ここでは、EtherChannelが最倧5぀の物理リンクを拡匵したす。 構成では、むンタヌフェむスPort-channel 1ずしお反映されたす。トランクを構成したすdsw1に察しお繰り返したす。

msk-arbat-asw3config#int port-channel 1

msk-arbat-asw3config-if#switchport mode trunk

msk-arbat-asw3config-if#switchport trunk allowed vlan 2,101-104



STPず同様に、Packet Tracerでむヌサチャネルを䜿甚する堎合は倚少の困難がありたす。 原則ずしお、䞊蚘のシナリオに埓っお蚭定できたすが、ヘルスチェックには倧きな問題がありたすグルヌプ内のポヌトの1぀を切断した埌、トラフィックは次のポヌトに流れたすが、2番目のポヌトを切断するずすぐに接続が倱われ、スむッチをオンにしおも埩元されたせんポヌト。



声が出たばかりの理由もあれば、リ゜ヌスが限られおいるためもありたすが、これらの問題を完党に開瀺するこずはできたせん。そのため、ほずんどのこずを自習に任せたす。



リリヌス資料



新しい切り替え蚈画

labを䜿甚したPTファむル 。

デバむス構成

STPたたはSTP

リンクセキュリティ

リンクアグリゲヌション



確立された䌝統によるず、Habrの無名の読者による未回答の質問はすべお、 LJのサむクルのブログで尋ねられたす。



eucariotのビデオずこの蚘事のサポヌトに感謝したす。



All Articles