免責事項 トピックを書くとき、読者はルーティングの概念に精通しており、静的ルートを作成する方法を知っており、「ARP」という言葉を虐待しているとは考えていないと思います。 ただし、経験豊富な信号機でさえも、きっとここで新しいものを見つけるでしょう。
すべての例は、iOS 15.2Mラインでテストされています。 他のオペレーティングシステムの動作は異なる場合があります。
そして、ここには動的ルーティングはありません。
次のトポロジを使用します。
静的ルートはどのように表示されますか？
まず、誰もが知っているコマンドを実行し、何が起こるかをデバッグで確認します。
R00(config)#ip route 3.1.1.0 255.255.255.0 10.0.0.3
IP-ST(default): updating same distance on 3.1.1.0/24 IP-ST(default): 3.1.1.0/24 [1], 10.0.0.3 Path = 8, no change, not active state IP-ST(default): 3.1.1.0/24 [1], 10.0.0.3 Path = 2 3 7 RT: updating static 3.1.1.0/24 (0x0): via 10.0.0.3 RT: add 3.1.1.0/24 via 10.0.0.3, static metric [1/0], add succeed, active state IP ARP: creating incomplete entry for IP address: 10.0.0.3 interface GigabitEthernet0/1 IP ARP: sent req src 10.0.0.1 30e4.db16.7791, dst 10.0.0.3 0000.0000.0000 GigabitEthernet0/1 IP ARP: rcvd rep src 10.0.0.3 0019.aad6.ae10, dst 10.0.0.1 GigabitEthernet0/1
IOSはルートを作成し、すぐにネクストホップを探してarp要求を送信しました。これは10.0.0.3です。 そしてすぐに質問：ルーターは、Gi0 / 1インターフェイスにリクエストを送信する必要があることをどのようにして知ったのでしょうか？ きっと誰かが「ローカルインターフェースのリストから」と言って、ひどい間違いをするでしょう。 ルーティングはそのようには機能しません。 実際、iOSはルーティングテーブルで再帰クエリを行い、次のホップに到達する方法を見つけました。
R00#show ip route 10.0.0.3 Routing entry for 10.0.0.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Routing Descriptor Blocks: * directly connected, via GigabitEthernet0/1 Route metric is 0, traffic share count is 1
そして、ここに、Gi0 / 1があります。 IOSは、RIBへの再帰的な要求では、「直接接続」フラグを持つルートを見つけたらすぐに終了する必要があることを学習します。 しかし、10.0.0.3への最初の要求に応答して、返されたルートがまったく接続されておらず、別のネクストホップを参照する中間ルートに接続されている場合はどうでしょうか。 少し後でこれに戻りますが、今のところCEFとは何かを思い出してください。
ほぼすべての初心者中心のドキュメントには、各パケットがルーティングテーブルに従って移動することが記載されています。 実際、ルーティングテーブル（以降-RIB）は高速データ転送用に最適化されていないため、多かれ少なかれ最新のプラットフォームでは、これはもはや当てはまりません。 このテーブルを使用すると、災害の規模を推定できます（ただし、プロセスの切り替えには、最適でないクエリに加えて多くの欠点があります。たとえば、コンテキスト間でCPUスケジューラを絶えず切り替えるため、非常にコストがかかります）。 CEFは深刻な最適化です。 現在の実装では、FIB（Forwarding Information Base、パケット転送テーブル、それに基づくひどい名前256-way mtrieの接続グラフ）と隣接テーブル（隣接テーブル）の2つのテーブルを作成します。 最初のものはルーティングテーブルに基づいて構築され、1回のパスですべての必要な情報を取得できます。 それに対応する最初のパッケージが表示される前であっても、事前にビルドされています。
静的ルートに戻ります。 ルーティングテーブルのエントリは次のとおりです。
R00#show ip route 3.1.1.0 Routing entry for 3.1.1.0/24 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 10.0.0.3 Route metric is 0, traffic share count is 1
パッケージの送付先は？ 10.0.0.3の検索場所 明確ではありません。 今回は10.0.0.3についてルーティングテーブルを再度クエリする必要があります。必要に応じて、接続されたインターフェイスが見つかるまで、さらに数回繰り返します。 この方法については、実際にルーターのパフォーマンスを数回低下させます。
そして、ここにCEFの言うことです：
R00#show ip cef 3.1.1.0 detail 3.1.1.0/24, epoch 0 recursive via 10.0.0.3 attached to GigabitEthernet0/1
シンプルで簡潔。 インターフェイスがあり、ネクストホップがあり、そこにパケットを送信する必要があります。 彼らは隣接テーブルについて何と言いましたか？
R00#show adjacency 10.0.0.3 detail Protocol Interface Address IP GigabitEthernet0/1 10.0.0.3(10) 0 packets, 0 bytes epoch 0 sourced in sev-epoch 2 Encap length 14 0019AAD6AE1030E4DB1677910800 ARP
最後から2番目の行の長いシーケンスに注目しましょう。 それが思い出させる何か...私たちはmac 10.0.0.3を見ます：
R00#show arp | in 10.0.0.3 Internet 10.0.0.3 1 0019.aad6.ae10 ARPA GigabitEthernet0/1
gi0 / 1のMACアドレスを確認します。
R00#show int gi0/1 GigabitEthernet0/1 is up, line protocol is up Hardware is CN Gigabit Ethernet, address is 30e4.db16.7791 (bia 30e4.db16.7791)
うん。 この恐ろしい行は、カプセル化の段階でイーサネットヘッダーに置き換える必要がある2つのポピーと、ethertype 0x0800、つまり ありふれたIPv4。 また、2つのCEFテーブルには、パケットをチェーンのさらに下に正常に送信するために必要なすべての情報が絶対にあります。
誰かが質問がある場合、なぜ鉄片が1つではなく2つのテーブルを一度に保持する必要があるのか、私は明白な答えを出します：通常、ルータには少数のインターフェース（および同時に近隣）と多くのルートがあります。 FIBで同じポピーを何千回も複製する意味は何ですか？ 特にハードウェアプラットフォームでは、新しいASRであっても、CatalystラインのL3スイッチであっても、多くのメモリはありません。 それらはすべて、パケットの送信時にCEFを使用します。
ところで、少しの間、元のデバッグに戻りましょう。 no ip cefコマンドでCEFを無効にし（これを実行しないでください）、結果を比較します。
IP-ST(default): updating same distance on 3.1.1.0/24 IP-ST(default): 3.1.1.0/24 [1], 10.0.0.100 Path = 8, no change, not active state IP-ST(default): 3.1.1.0/24 [1], 10.0.0.100 Path = 2 3 7 RT: updating static 3.1.1.0/24 (0x0): via 10.0.0.100 RT: add 3.1.1.0/24 via 10.0.0.100, static metric [1/0], add succeed, active state
ルートが追加されました。 Arp要求はありませんでした。 そして当然のことですが、RIBはなぜMACアドレスに降伏したのですか？ たとえば、3.1.1.1をpingすると、次のようになります。
R00#ping 3.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3.1.1.1, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/4 ms
最初のパケットは破棄され、ルーターはarp要求を送信して、MACアドレス10.0.0.3が以前に知られていないかどうかを調べます。 CEFは常にネクストホップのMACアドレスを事前に知っています。
私たちはそれを理解しました。 次に、静的ルートのネクストホップが直接接続されたインターフェイス上にまったくない場合にどうなるかという質問に戻ります。 次の手順に進みます。
R00(config)#ip route 10.0.0.3 255.255.255.255 100.100.100.101
Gi0 / 2のアドレスは100.100.100.100/24です。
R00#show ip cef 3.1.1.0 detail 3.1.1.0/24, epoch 0 recursive via 10.0.0.3 recursive via 100.100.100.101 recursive via 100.100.100.0/24 attached to GigabitEthernet0/2
それがどれほど悪いのか...しかし、スーパーネット全体へのルートがある場合はどうでしょうか？
R00(config)#no ip route 10.0.0.3 255.255.255.255 100.100.100.101 R00(config)#ip route 10.0.0.0 255.0.0.0 100.100.100.101 R00#show ip cef 3.1.1.0 detail 3.1.1.0/24, epoch 0 recursive via 10.0.0.3 attached to GigabitEthernet0/1
ルーティングテーブルは次のようになります。
R00#show ip route 10.0.0.0/8 is variably subnetted, 2 subnets, 3 masks S 10.0.0.0/8 [1/0] via 100.100.100.101 C 10.0.0.0/24 is directly connected, GigabitEthernet0/1 L 10.0.0.1/32 is directly connected, GigabitEthernet0/1 100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 100.100.100.0/24 is directly connected, GigabitEthernet0/2 L 100.100.100.100/32 is directly connected, GigabitEthernet0/2
良いようです。 100.100.100.101の新しいルートは10.0.0.3には適用されません。マスク/ 8は接続されたインターフェイスの/ 24よりもはるかに短いためです。 しかし、突然3.1.1.0/24のネクストホップを含むGi0 / 1が何らかの理由でダウンし、その接続ルートがRIBから消失しました。
%LINK-5-CHANGED: Interface GigabitEthernet0/1, changed state to administratively down %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down RT: interface GigabitEthernet0/1 removed from routing table RT: del 10.0.0.0 via 0.0.0.0, connected metric [0/0] RT: delete subnet route to 10.0.0.0/24 RT: del 10.0.0.1 via 0.0.0.0, connected metric [0/0] RT: delete subnet route to 10.0.0.1/32 IP-ST(default): updating GigabitEthernet0/1
起こったことは次のとおりです。
R00#show ip cef 3.1.1.0 detail 3.1.1.0/24, epoch 0 recursive via 10.0.0.3 recursive via 10.0.0.0/8 recursive via 100.100.100.101 recursive via 100.100.100.0/24 attached to GigabitEthernet0/2
痛い。 これで、ネットワーク3.1.1.0/24上のパケットがどこか間違った方向に進みます。 静的ルートの予想される動作が別のインターフェイスに切り替わるというシナリオは想像できません。 そのインターフェースの背後にバックアップパスがある場合、別の静的ルートを作成する必要があります...
どうする ルート内のインターフェイスをすぐに示します。 ルートを再作成します。
R00(config)#no ip route 3.1.1.0 255.255.255.0 10.0.0.3 R00(config)#ip route 3.1.1.0 255.255.255.0 Gi0/1 10.0.0.3
Gi0 / 1.を上げる ルートが現在3.1.1.0/24に至る場所を確認します。
R00#show ip route 3.1.1.0 Routing entry for 3.1.1.0/24 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 10.0.0.3, via GigabitEthernet0/1 Route metric is 0, traffic share count is 1
インターフェイスはすでにここに示されています。 したがって、ルーティングテーブルに再帰クエリはありません。 FIBの確認：
R00#show ip cef 3.1.1.0 3.1.1.0/24 nexthop 10.0.0.3 GigabitEthernet0/1
はい、「再帰的」ではありません。 そして、再びgi0 / 1を完済したら？ ルートが消えました。
R00#show ip route 3.1.1.0 % Network not in table R00#show ip cef 3.1.1.0 0.0.0.0/0 no route
そして、これは10.0.0.3へのルートがまだあったという事実にもかかわらず：
R00#show ip cef 10.0.0.3 10.0.0.0/8 nexthop 100.100.100.101 GigabitEthernet0/2
しかし、ネクストホップへのパスがデフォルトルートを提供し、3.1.1.0 / 24へのルートがインターフェイスを参照しない場合はどうなりますか？
R00(config)#no ip route 10.0.0.0 255.0.0.0 100.100.100.101 R00(config)#ip route 0.0.0.0 0.0.0.0 100.100.100.101 R00(config)#no ip route 3.1.1.0 255.255.255.0 Gi0/1 10.0.0.3 R00(config)#ip route 3.1.1.0 255.255.255.0 10.0.0.3 R00#show ip route 3.1.1.0 % Network not in table R00#show ip cef 3.1.1.0 detail 0.0.0.0/0, epoch 0, flags default route recursive via 100.100.100.101 recursive via 100.100.100.0/24 attached to GigabitEthernet0/2
「show ip cef」の後の最初の行は「3.1.1.0/24」ではなく「0.0.0.0/0」であることに注意してください。 正式にネクストホップがあるという事実にもかかわらず、実際にはルーティングテーブルのポーリングのすべての反復（最初を除く）は論理的なデフォルトルートを無視します。そうでなければ、ルーティングテーブルへのクエリはほとんど常に解決されます（「解決済み」は、パッケージを送信する必要があります）。 したがって、静的ルートは欠落していますが、パケットはまだGi0 / 2に飛んでいます。 すべてが明示的なインターフェイスなしと同じように見えますか？ そうでもない。 ルーティングプロトコルが「静的再配布」と言われたとします。 静的ルートがなくなった場合、アナウンスも応答します。 そうでない場合、ルーターは全員に「そこへ行く」ように伝え続け、ほとんど確実に、どこからでもアクセスできるプレフィックス3.1.1.0/24のL3リングに変わります。 しかし、やめて、動的ルーティングに手を触れないことに同意しました...
しかし、スタティックルートでインターフェイスを指定し、ネクストホップのIPアドレスを指定しないとどうなりますか？ 回答：イーサネットの場合、プロキシarpがネクストホップで無効になっていない場合、接続は切断されませんが、ルーターは大失敗する可能性があります。 詳細 「ip route 3.1.1.0 255.255.255.0 gi0 / 1」と言うと、ひどいことは何も起こらず、arpテーブルの数百のエントリでさえルーターによってダイジェストされます（そして、そのような松葉杖が最適な解決策である回避スクリプトがあります） ）、しかし、ここでは、境界ルーター上の「ip route 0.0.0.0 0.0.0.0 gi0 / 1」はおそらく彼を殺します。 したがって、一般的なルールを覚えておいてください。イーサネットインターフェイス上のネクストホップで静的ルートが作成される場合、そのIPアドレスは常に示される必要があります。 例外は、自分が何をしているのか、なぜそれをしているのか、なぜそうしないのかを非常によく知っているときだけです。
最後に、非常に悪いことを1つ行います。
R00(config)# ip route 3.1.1.0 255.255.255.0 10.0.0.3 R00(config)#ip route 10.0.0.3 255.255.255.255 3.1.1.1
最初のルートは、100回のテストで問題ありません。 しかし、2番目は奇妙です。最初の2つを経由します。 そして今、最初のものは2番目のものを指し、無限再帰を持っています。 起こったことは次のとおりです。
IP-ST(default): updating same distance on 3.1.1.0/24 IP-ST(default): 3.1.1.0/24 [1], 10.0.0.3 Path = 8, no change, not active state IP-ST(default): 3.1.1.0/24 [1], 10.0.0.3 Path = 2 3 7 RT: updating static 3.1.1.0/24 (0x0): via 10.0.0.3 RT: add 3.1.1.0/24 via 10.0.0.3, static metric [1/0], add succeed, active state IP-ST(default): updating same distance on 10.0.0.3/32 IP-ST(default): 10.0.0.3/32 [1], 3.1.1.1 Path = 8, no change, not active state IP-ST(default): 10.0.0.3/32 [1], 3.1.1.1 Path = 2 3 7 RT: updating static 10.0.0.3/32 (0x0): via 3.1.1.1 RT: add 10.0.0.3/32 via 3.1.1.1, static metric [1/0], add succeed, active state
正常に追加されました。 しかし、それはデバッグで強調されました：
RT: recursion error routing 3.1.1.1 - probable routing loop RT: recursion error routing 10.0.0.3 - probable routing loop
また、重大度3のログエントリがありました。
%IPRT-3-RIB_LOOP: Resolution loop formed by routes in RIB
R00#show ip cef 10.0.0.3 detail 10.0.0.3/32, epoch 0 Adj source: IP adj out of GigabitEthernet0/1, addr 10.0.0.3 359503C0 Dependent covered prefix type adjfib cover 10.0.0.0/24 1 RR source [no flags] recursive via 3.1.1.1, unresolved recursive-looped R00#show ip cef 3.1.1.0 detail 3.1.1.0/24, epoch 0, flags cover dependents Covered dependent prefixes: 1 notify cover updated: 1 recursive via 10.0.0.3, unresolved recursive-looped
ただし、RIBは犯罪を見ません。
Routing entry for 3.1.1.0/24 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 10.0.0.3 Route metric is 0, traffic share count is 1 R00#show ip route 10.0.0.3 Routing entry for 10.0.0.3/32 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 3.1.1.1 Route metric is 0, traffic share count is 1
結論-絶対にしないでください。
静的ルートがルーティングテーブルに入らないのはなぜですか？
すべてのネットワーク担当者は、IOSのルートのソースに関する説明の1つをすぐに提供する必要があります。同じプレフィックスへの別のルートがありますが、ADが低くなります（誰でも管理距離を覚えていますか？）。 ソースが「接続」されているルートは常にAD = 0であり、他のルートソースは、明示的なインターフェイスを持つ静的ルートであっても、「1」より低いものをもたらすことはできません。 接続例：
R00# show ip route C 10.0.0.0/24 is directly connected, GigabitEthernet0/1
つまり Gi0 / 1インターフェイスがアップ状態であり、サブネット10.0.0.0/24からのアドレスを持っている限り、このプレフィックスへの静的ルートはルーティングテーブルに表示されません。
「異なるルートソースが同じADの同じプレフィックスにルートを追加する」オプションもあります。 この場合のIOSの動作は文書化されていません。一般的な推奨事項は「これを実行しない」です。
しかし、それほど明白ではない他の例を見てみましょう。 たとえば、静的ルートは「パーマネント」という単語で作成できます。これは「パーマネント」と解釈され、ルーティングテーブルで常にハングします。 そうだね いや
それを追加して見てください：
R00(config)#ip route 3.1.1.0 255.255.255.0 10.0.0.3 permanent R00#show ip cef 3.1.1.0 3.1.1.0/24 nexthop 10.0.0.3 GigabitEthernet0/1
Gi0 / 1を入れて、以下を参照してください。
R00#show ip cef 3.1.1.0 3.1.1.0/24 unresolved via 10.0.0.3
RIBに存在し、他のルーティングプロトコルで使用できます。
R00#show ip route 3.1.1.0 Routing entry for 3.1.1.0/24 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 10.0.0.3, permanent Route metric is 0, traffic share count is 1
そして今、Gi0 / 1を上げることなく：
R00(config)#no ip route 3.1.1.0 255.255.255.0 10.0.0.3 permanent R00(config)#ip route 3.1.1.0 255.255.255.0 10.0.0.3 permanent
彼らは何も変更せずにそれを再作成しました。 そして、ここで何が起こったのですか：
IP-ST(default): updating same distance on 3.1.1.0/24 IP-ST(default): 3.1.1.0/24 [1], 10.0.0.3 Path = 8, no change, not active state IP-ST(default): cannot delete, PERMANENT R00#show ip route 3.1.1.0 % Network not in table R00#show ip cef 3.1.1.0 0.0.0.0/0 no route
永続的な、話す？ いや 微妙な違いが1つあります。永続的なルートがルーティングテーブルに永久に収まるようにするには、少なくとも1秒間は解決する必要があります。 「永遠」とは何ですか？ インターフェイスを解決せずに宙に浮いたままになっている場合は、「clear ip route *」または「reload」と言うだけで十分で、RIBから消えます。
しかし続けましょう。 このようにしましょう：
R00(config)#ip route 3.1.1.0 255.255.255.0 Gi0/1 10.0.0.3 R00(config)#ip route 3.1.1.10 255.255.255.255 3.1.1.1
通常のルートのようです。 どうなるの？ 第二に-絶対に何もない。
IP-ST(default): 3.1.1.10/32 [1], 3.1.1.1 Path = 8, no change, not active state IP-ST(default): 3.1.1.10/32 [1], 3.1.1.1 Path = 2 3 6 8, no change, not active state
ポイントはこれです。 YYYY経由でXXXXへのルートがあるとします。X2.X2.X2.X2経由でX1.X1.X1.X1（このプレフィックスはXXXXで完全にカバーされます）にルートを追加します（XXXXでもカバーされます）。 IOSは論理的な結論を下します。2番目のルートは新しい情報を伝達せず、まったく役に立たないため、RIBにインストールできません。
そして今、耳をかすめる。
R00(config)#no ip route 3.1.1.10 255.255.255.255 3.1.1.1 R00(config)#ip route 3.1.1.10 255.255.255.255 Gi0/1 3.1.1.1 IP-ST(default): updating same distance on 3.1.1.10/32 IP-ST(default): 3.1.1.10/32 [1], GigabitEthernet0/1 Path = 1 RT: updating static 3.1.1.10/32 (0x0): via 3.1.1.1 Gi0/1 RT: network 3.0.0.0 is now variably masked RT: add 3.1.1.10/32 via 3.1.1.1, static metric [1/0], add succeed, active state IP ARP: creating incomplete entry for IP address: 3.1.1.1 interface GigabitEthernet0/1 IP ARP: sent req src 10.0.0.1 30e4.db16.7791, dst 3.1.1.1 0000.0000.0000 GigabitEthernet0/1 R00#show ip cef 3.1.1.10 3.1.1.10/32 nexthop 3.1.1.1 GigabitEthernet0/1
そして、これは別の重要なポイントに私たちをもたらします。 静的ルートでインターフェイスを指定すると、次のホップへのパスを検索するために静的ルートがRIBへの再帰クエリを実行する必要がなくなり、追加されても他のルートのトリガーに影響を与えないため、多くのチェックをバイパスできます。 ただし、これは主な要件を無効にするものではありません。ネクストホップは特定のインターフェイスに解決する必要があり、そのインターフェイスは稼働している必要があります。 RIBへの再帰的な要求がなくなるという事実は、ネクストホップのIPアドレスがインターフェイスのすぐ後ろにあり、おそらく（ルーターの観点から）arp要求に応答することを意味します。 Gi0 / 1に隣接するルーターでプロキシarpが有効になっている場合、おそらくarpに応答してmacアドレスが返され、すべて正常に動作します。 それはarpテーブルの追加エントリですか...
しかし、まだ、これを行うべきではありません。
別の重要な点に言及する必要があります。 理論的には、静的ルートは解決が停止するとすぐにルーティングテーブルから消えます。 しかし実際には、ネクストホップが消える多くの状況がありますが、同時に静的ルートはしばらく残ります。 たとえば、ネクストホップが動的ルーティングプロトコルから受信したルートを介して解決される場合。 問題は、RIBのネクストホップの存在を監視するプロセスは、ルートの消失に関する通知を常に受信できるわけではなく、すべてが正常かどうかを定期的に（デフォルトでは60秒ごとに）チェックすることを強制されることです。 これにより、ネットワークコンバージェンスで顕著な遅延が発生します。
次のコマンドを使用して、検証間隔を、たとえば10秒ごとに変更できます。
ip route static adjust-time 10