社員ブログ

みなさんこんにちは。ミライネット技術部 開発チームの篠田です。
前回のエントリーに続いて JANOG51で開催されましたNETCONの問題解説を書いていきます。

私の作成した問題は以下の2問です。

Level 2-3 NTPによる時刻同期問題 ※別記事にて解説

Level 2-4 OSPF経路調整問題 (本エントリー)

本エントリーでは Level 2-4 について解説を行いたいと思います。

問題

host1からhost2に対してpingによる疎通確認ができるように修正しなさい

コンフィグ
R1
R2
R3
R4

技術要素

• OSPF

制限事項

• コンフィグを修正できるのはR1/R3のみ
• R2/R4は設定変更不可(実行できるコマンドの制限あり)
• host1/host2のIPアドレス変更禁止

問題解説

本問題はR4がhost2の所属するネットワーク(192.168.3.0/24)をブラックホールルーティングする経路を広報している為host1/host2間の通信ができない状態になっています。

トポロジー内の機器のIPを確認すると下図の通り設定されています。

R1/R2/R3/R4ではOSPFが設定されており、OSPFで経路交換を行っています。

host1のルーティングテーブルを確認すると192.168.3.0/24宛のnext-hopがR1になっていることが分かります。

[host1]$ip r default via 172.20.20.1 dev eth0 10.0.0.0/8 via 192.168.1.1 dev eth1 172.20.20.0/24 dev eth0 proto kernel scope link src 172.20.20.4 192.0.2.0/24 via 192.168.1.1 dev eth1 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.100 192.168.3.0/24 via 192.168.1.1 dev eth1

R1のルーティングテーブルを確認すると192.168.3.0/24宛のnext-hopがR2になっていることが分かります。

R1#sh ip route | beg Gateway Gateway of last resort is not set (省略) C 192.168.1.0/24 is directly connected, Ethernet1 O E1 192.168.3.0/24 [110/31] via 10.1.2.2, Ethernet2

R2のルーティングテーブルを確認すると192.168.3.0/24宛のnext-hopがR4になっていることが分かります。

RP/0/RP0/CPU0:R2#sh ip ro | beg Gateway Thu Dec 29 04:12:27.323 UTC Gateway of last resort is not set (省略) O E2 192.0.2.1/32 [110/1] via 10.1.2.1, 00:30:51, GigabitEthernet0/0/0/0 L 192.0.2.2/32 is directly connected, 00:31:18, Loopback0 O E2 192.0.2.3/32 [110/0] via 10.2.3.3, 00:25:17, GigabitEthernet0/0/0/2 O E2 192.0.2.4/32 [110/20] via 10.2.4.4, 00:30:37, GigabitEthernet0/0/0/1 O E2 192.168.1.0/24 [110/1] via 10.1.2.1, 00:30:51, GigabitEthernet0/0/0/0 O E1 192.168.3.0/24 [110/21] via 10.2.4.4, 00:17:45, GigabitEthernet0/0/0/1

R3のルーティングテーブルを確認すると192.168.1.0/24宛のnext-hopがR2になっていることが分かります。また、192.168.3.0/24宛の経路が2つあることが分かります。

janoger@R3> show route inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden) + = Active Route, – = Last Active, * = Both 192.168.1.0/24 *[OSPF/150] 00:32:30, metric 1, tag 0 > to 10.2.3.2 via ge-0/0/0.0 192.168.3.0/24 *[Direct/0] 00:32:41 > via ge-0/0/1.0 [OSPF/150] 00:32:30, metric 22, tag 0 > to 10.2.3.2 via ge-0/0/0.0 192.168.3.3/32 *[Local/0] 00:32:41 Local via ge-0/0/1.0

R4のルーティングテーブルとコンフィグを確認すると192.168.3.0/24のブラックホールルーティング用経路をOSPFで再配布していることが分かります。

RP/0/RP0/CPU0:R4#sh ip ro | beg Gateway Thu Dec 29 04:17:25.203 UTC Gateway of last resort is not set (省略) O E2 192.168.1.0/24 [110/1] via 10.2.4.2, 00:35:35, GigabitEthernet0/0/0/0 S 192.168.3.0/24 is directly connected, 00:22:43, Null0

router ospf 1   redistribute connected   redistribute static metric-type 1   area 0      interface GigabitEthernet0/0/0/0      !    ! !

host2のルーティングテーブルを確認すると192.168.1.0/24宛のnext-hopがR3になっていることが分かります。

[host2]$ip r default via 172.20.20.1 dev eth0 10.0.0.0/8 via 192.168.3.3 dev eth1 172.20.20.0/24 dev eth0 proto kernel scope link src 172.20.20.7 192.0.2.0/24 via 192.168.3.3 dev eth1 192.168.1.0/24 via 192.168.3.3 dev eth1 192.168.3.0/24 dev eth1 proto kernel scope link src 192.168.3.100

各host、ルータのルーティングテーブルを見た結果、
R2で192.168.3.0/24のnext-hopがR3を向く様に調整してやれば題意を満たせそうです。

R2の経路調整を行う為、R2で192.168.3.0/24の経路をよく確認すると

RP/0/RP0/CPU0:R2#sh ip ospf database external 192.168.3.0 Type-5 AS External Link StatesLS Type: AS External Link Link State ID: 192.168.3.0 (External Network Number) Advertising Router: 192.0.2.3 Network Mask: /24               Metric Type: 2 (Larger than any link state path)               Metric: 0 Routing Bit Set on this LSA LS Type: AS External Link Link State ID: 192.168.3.0 (External Network Number) Advertising Router: 192.0.2.4 Network Mask: /24               Metric Type: 1 (Comparable directly to link state metric)               Metric: 20 ※長くなるので色々省略してます

R3はE2(Metric Type:2) 、R4はE1(Metric Type:1) で192.168.3.0/24を広報しているようです

このことから192.168.3.0/24の経路はE1のR4への経路が採用され、
192.168.3.0/24宛のパケットはR2からR4へと転送され、

R4でブラックホールルーティングされてしまっています。

R2/R4は設定変更ができない為、R1/R3の設定変更のみで何とかするしかありません。

もう一度R2のルーティングテーブルを確認すると、

192.168.3.0/24の経路はE1、メトリック21でR4がnext-hopとなっているので、
R3からE1 メトリック21より低いメトリックとなるように広報するか

OSPFのエリア内経路として広報することでR3の経路を優先させることができそうです。

RP/0/RP0/CPU0:R2#sh ip ro | beg Gateway Thu Dec 29 04:12:27.323 UTC Gateway of last resort is not set (省略) O E2 192.0.2.1/32 [110/1] via 10.1.2.1, 00:30:51, GigabitEthernet0/0/0/0 L 192.0.2.2/32 is directly connected, 00:31:18, Loopback0 O E2 192.0.2.3/32 [110/0] via 10.2.3.3, 00:25:17, GigabitEthernet0/0/0/2 O E2 192.0.2.4/32 [110/20] via 10.2.4.4, 00:30:37, GigabitEthernet0/0/0/1 O E2 192.168.1.0/24 [110/1] via 10.1.2.1, 00:30:51, GigabitEthernet0/0/0/0 O E1 192.168.3.0/24 [110/21] via 10.2.4.4, 00:17:45, GigabitEthernet0/0/0/1

ということで解答例は以下のようになります

解答例(1) R3で経路広報時のメトリックを調整する

janoger@R3# set policy-options policy-statement redist_ospf term t1 then external type 1 janoger@R3# set policy-options policy-statement redist_ospf term t1 then metric 19 janoger@R3# show | compare janoger@R3# commit

R2でR3から広報された192.168.3.0/24のメトリックが20になり、R3宛の経路が優先されるようになります。

RP/0/RP0/CPU0:R2#sh ip ro | beg Gateway Thu Dec 29 05:42:12.902 UTC Gateway of last resort is not set (省略) O E2 192.168.1.0/24 [110/1] via 10.1.2.1, 02:00:36, GigabitEthernet0/0/0/0 O E1 192.168.3.0/24 [110/20] via 10.2.3.3, 00:01:45, GigabitEthernet0/0/0/2

解答例(2) R3でOSPFエリア内経路として広報する

janoger@R3# set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 janoger@R3# show | compare janoger@R3# commit

ge-0/0/1.0(host2接続インターフェース)でOSPFを有効にすることで、192.168.3.0/24がエリア内経路として広報されます。

RP/0/RP0/CPU0:R2#sh ip ro | beg Gateway Thu Dec 29 05:32:26.292 UTC Gateway of last resort is not set (省略) O E2 192.168.1.0/24 [110/1] via 10.1.2.1, 01:50:50, GigabitEthernet0/0/0/0 O 192.168.3.0/24 [110/2] via 10.2.3.3, 00:02:42, GigabitEthernet0/0/0/2

以上2点が想定内回答でしたが、3名ぐらいの方から別解をいただいたので
なるほど！と思った別解を簡単に紹介させてもらいます。

別解(1) R3よりprefix長の長い経路を広報する

janoger@R3# set routing-options static route 192.168.3.100 next-hop 192.168.3.0 resolve janoger@R3# set policy-options policy-statement redist_ospf term t2 from protocol static janoger@R3# set policy-options policy-statement redist_ospf term t2 then accept janoger@R3# commit

ロンゲストマッチによりR2のルーティングテーブルを調整する(こういうやり方があるんですね。勉強になりました。ご解答ありがとうございました！)

最後

OSPFは非常に便利なプロトコルで個人的に好きということもありOSPFの問題を作ってみました。
エリア内経路として広報するか、メトリック調整するかどちらが多いか気になっていたんですが
メトリック調整される方が多く、エリア内経路として広報される方は少数でした。
制約をつけることで想定外回答が出ない様に問題を調整したつもりだったんですが、
見事にやられました。精進します。。。