【第2回 CCNP CAMP ENARSI】スタティックルートのIF指定はダメ?

【第2回 CCNP CAMP ENARSI】スタティックルートのIF指定はダメ?

2020年12月06日(日)
CCNP CAMP

みなさんこんにちは。Smart Innovation株式会社です。

昨日(12/5)にNP CAMP第1回目が無事終了しましたので、その様子をお伝えします!

▼NP CAMPの詳細はコチラからどうぞ!

【毎週土曜日/3ヵ月でCCNP取得】CCNP CAMPを開催します。

みなさんこんにちは。Smart Innovation株式会社です。 今回は【毎週…
smart-innovation.tech

おかげ様で9名の方にご参加頂きました!

今回のクールは9名の方にご参加頂きました。7名の方が教室での参加、2名の方がリモートでの参加となります。まずは講師の経歴紹介から、参加者の方同士での自己紹介を行いました。

来年からITインフラ業界にIT未経験で就職する方も参加されていて、非常に意欲高い方々の参加となりました。

お互い初対面の方もいらっしゃいましたが、ネットワークエンジニアとして頑張っていく思いは皆同じ、1回目が終わる頃には和やかな雰囲気となっていましたね。

第1回目のCCNP ENARSI取得講座の内容は?

第1回目の講座内容は以下のとおりです。

■Part1.IPv4/IPv6 Addressing
・Chapter 1 IPv4/IPv6 Addressing
 DHCPの復習
 IPv6アドレッシング
 SLAAC(スラーク)、ステートフルDHCPv6、ステートレスDHCPv6
 パケット転送プロセス(CEF、FIB、Ajacencyテーブル)
 ルーティング情報源(AD値など)
 スタティックルート(プロキシARP、IPv6)
 
■Part2.EIGRP
・Chapter 2 EIGRP
 EIGRPの基礎
 パスメトリックの計算
 障害検出とタイマー
 ルート集約

・Chapter 3 Advanced EIGRP
 障害検出とタイマー
 ルート集約
 WANに関する考慮事項
 ルート操作
 
・Chapter 4 Troubleshooting EIGRP for IPv4
 ネイバー隣接関係のトラブルシューティング
 IPv4ルートのトラブルシューティング
 その他のトラブルシューティング
 IPv4 トラブルチケット

・Chapter 5 EIGRPv6
 EIGRPv6の基礎
 ネイバー問題のトラブルシューティング
 ルートのトラブルシーティング
 名前付きEIGRPのトラブルシューティング

■実機演習
・EIGRPのネイバー正常性確認
・EIGRPの冗長性確認
・AS番号変更、K値変更によるネイバーダウンの確認
・メトリック変更によるルート学習ソースの変更

スタティックルートのIF指定はダメ?

今回は以下の範囲の中から、プロキシARPについてご紹介します。

■Part1.IPv4/IPv6 Addressing
・Chapter 1 IPv4/IPv6 Addressing

皆さんは以下の設定がなぜダメなのか分かりますでしょうか。

iproute 10.1.3.0 255.255.255.0 gigabitEthernet 1/0

これは単純に、ルータが10.1.3.0/24のネットワークを直接接続しているとみなすことで、不要なARPがバンバン発生し、CPUのリソースを無駄に消費することから通信効率が悪くなるからです。

どういうことかというと、まず以下の出力を見てください。トポロジも載せておきます。

R1# show ip route static
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
S 10.1.3.0/24 is directly connected, GigabitEthernet1/0

違和感を感じた方もいたことでしょう。なんと、スタティックで学習しているのにdirectly connectedという表記があります。

これ、実はR1が10.1.3.0/24を直接接続していると認識する設定なのです。

そうするとどうなるかというと、R1が例えば10.1.3.0/24へ通信したいときに、不要なARPがバンバン発生するのです。

例えば、10.1.3.0/24に通信しようとしたら、R1と別セグメントになるので、通常はネクストホップ宛て(R2の左側のIFである10.1.12.2)にアドレス解決しに行きます。そしてR2の左側のIFのMACを手に入れて、ARPテーブルに格納し、無事R2にパケットを渡すことが出来ます。

ただし、今回はR1が、10.1.3.0/24が直接接続していると認識しているので、10.1.3.0/24のセグメントの端末宛てのパケットは全てアドレス解決しようとします。例えば10.1.3.1へ通信したい場合はその端末のMACアドレスを解決しようとするわけです。

※因みに10.1.3.1自身はMACアドレスを返せない(別セグだから)ので、通信は失敗するのでは?と思った方。
 実は通信は出来ます。R2がプロキシARP(個人的にはプロキシARPリプライと呼びたいですが)を返すからです。

従って、10.1.3.0/24のネットワークに存在する端末宛ての通信は、その端末の台数分ARPリクエストとリプライが発生してくるので、非効率になってくるというわけです。

結論としては、素直にスタティックルートでネクストホップを指定するのが良いですね。

CCNP Enterprise認定についてなんでも相談に乗ります!

当社はCCNP Enterprise認定に関する相談をなんでも受け付けています!もしご相談したい方は、以下LINE宛にご質問ください。

友だち追加