何をしたのか？

早速なんですが、これまでの構成図がこちら。

基本的には外側(Homenoc/HETB/IHANet)に対してはBGP+やStaticで経路制御をしています。そして、内部の経路制御は基本的にRIPngで行っています。コレを以下の通りに変更したのです。

コレで何が変わるかというと

• Homenocのアドレス体系を使ってるところと、HETBアドレス体系を使ってるところの境界を明確にできる
  • つまりは、必ずRTX-3000が境界となって、アドレス体系間の通信が行われる
• 複数の動的制御プロトコルを流すことで、色々お勉強になるかもしれない。
  • RIPngはIPv4のRIPと同様と言っていいほど設定が簡単です。
  • ただ、状態の確認などを行おうとすると、OSPFv3の方が色々情報を取り出しやすかったりして便利だと感じました。

ということで、今回一部のRIPngで制御している箇所をOSPFv3に切り替えました。

各種機器の設定変更

今回、以下の機器に設定変更を行います。

• Routerboard：Homenoc外接ルーター
• SEIL/x86：Homenoc IPv6専用ルーター
• RTX：HETBコアルーター兼Mastodon等収容ルーター
• Cisco：IHAnet用ルーター

本来、IHAnet用ルーターは触る必要が無いように思えましたが、あとで必要に迫られ、設定変更の対象になりました。詳しくは後述します。

SEILの設定変更

まず、OSPFの設定を行います。

route6 dynamic ospf router-id 192.168.100.15
route6 dynamic ospf enable
route6 dynamic ospf area add 0.0.0.0
route6 dynamic ospf area add 0.0.0.1
route6 dynamic ospf link add lan0 area 0.0.0.1
route6 dynamic ospf link add lan1 area 0.0.0.0

で、RIPngを無効化します。

route6 dynamic ripng disable

現状のフィルタ設定だとOSPFのパケットがRouterboardに届かないため、許可する設定を追加します。リンクローカルだけ許容することにより、同一ブリッジに接続された機器にしか接続を許可しないようにしています。

filter6 add seil_ctl_lan1 interface lan1 direction in action pass protocol 89 src fe80::/10 state disable logging off enable top

後はflashromにセーブしたら一旦完了。

Routerboardの設定変更

• 管理画面にログイン後、「Routing」⇒「OSPFv3」を選択します。
• 「Instances」タブをクリックして、「Add New」をクリックします。

• Router IDに管理用IPv4アドレスを一応適用しておきます。
• 併せて、ルート再配送設定をします。
  • Default Routerは再配送対象とします。
  • 接続インタフェースルートは再配送対象とします。
  • 固定ルートは再配送対象とします。
  • それ以外は再配送対象にしません。
    • なお、BGPを再配送対象にしたら大変なことになりました。それは後述します。

• 「Interfaces」タブをクリックして「Add New」をクリックします。

• Areaはデフォルトで定義されている「backbone」でOK。
• InterfaceにはSEILと接続されているブリッジを指定します。
• 後は基本的にデフォルト値でOKです。
• 最後に「Enabled」にチェックをつけて「OK」をクリックします。

以上で、Routerboard側のOSPF設定は完了です。

RTXの設定変更

OSPFv3関連の設定を行います。

ipv6 ospf use on
ipv6 ospf router id 192.168.100.1
ipv6 ospf import from static
ipv6 ospf import from rip
ipv6 ospf area 0.0.0.1

内部インタフェースに対してOSPFのエリアへ組み込みをします。

ipv6 lan1/1 ospf area 0.0.0.1

RTXは設定するだけでは反映されないため、以下コマンドを実行して反映します。

ipv6 ospf configure refresh

Ciscoルーターの設定変更

本来はここまでで一通り設定が完了するんですが、RTX側にRIPngに対するルート再配送設定の機能がないため、スタティックルートの設定と、スタティックルート再配送の解除を実施しました。

スタティックルートの設定をします。

KUNUGI(config)#ipv6 route 2403:BD80:****:100::/64 2001:470:****:100::1
KUNUGI(config)#ipv6 route 2403:BD80:****:220::/64 2001:470:****:100::1
KUNUGI(config)#ipv6 route 2403:BD80:****:105::/64 2001:470:****:100::1
KUNUGI(config)#ipv6 route 2403:BD80:****:ffff::/64 2001:470:****:100::1

スタティックルート再配送の解除(RIPngのみ)を行います。コレを忘れると、RTX側にRIPngを通じてHomeNOCアドレス体系のルーティング先がCiscoルーターとなってしまいます。これはOSPF側の情報と競合し、結果としてOSPF側が勝利するため、表面的には問題ないのですが、基本そういう情報は流さないほうが良いのだろうと思い、当手順を踏んでいます。

KUNUGI(config)#ipv6 router rip P1
KUNUGI(config-rtr)#no redistribute static

以上で一通りの設定が完了です。

状態を確認する

SEILの状態確認(neighbor確認)

kaede# show status route6 dynamic ospf neighbor
Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
192.168.100.6 1 00:00:39 Full/DR 01:20:30 lan1[BDR]
192.168.100.1 1 00:00:37 Full/BDR 01:00:48 lan0[DR]

Routerboardの状態確認

RTXの状態確認(neighbor確認)

YOMOGI# show ipv6 ospf neighbor
Neighbor ID Pri State Dead Time Interface Instance ID
192.168.100.15 1 Full/DR 00:00:31 LAN1/1 0

SEILの状態確認(ルーティングテーブル確認：一部割愛)

kaede# show status route6
Flags: C - Connected, M - Miscellaneous, O - OSPFv3, R - RIPng, S - Static
 * - System route, ! - inconsistent
Destination Gateway Interface Flags Dist.
default 2403:bd80:****:****::fffe lan1 S* 1
::1/128 loopback loopback C* 0
2001:470:**:***::/64 fe80::2a0:****:****:43ac lan0 O* 110
2001:470:****:100::/64 lan0 lan0 O* 110
2001:470:****:230::/64 fe80::2a0:****:****:43ac lan0 O* 110
2001:470:****:239::/64 fe80::2a0:****:****:43ac lan0 O* 110
2001:470:****::/48 fe80::2a0:****:****:43ac lan0 O* 110
2403:bd80:****:***::/56 fe80::2a0:****:****:43ac lan0 O* 110
2403:bd80:****:100::/64 lan0 lan0 C* 0
2403:bd80:****:105::/64 2403:bd80:****:100::3 lan0 S* 1
2403:bd80:****:220::/64 2403:bd80:****:100::3 lan0 S* 1
2403:bd80:****:ffff::/64 lan1 lan1 C* 0
2602:****:af2::/48 fe80::2a0:****:fe3a:43ac lan0 O* 110
2a0b:****:60::/44 fe80::2a0:****:fe3a:43ac lan0 O* 110

fe80から始まり43acで終わっているリンクローカルアドレスは、RTXのことを指しています。

Routerboardの状態確認(ルーティングテーブル確認)

OSPFv3で経路が受信できていることを確認できます。

RTXの状態確認(ルーティングテーブル確認：一部割愛)

YOMOGI> show ipv6 route
Destination Gateway Interface Type
default - TUNNEL[6] static
2001:380:***:***::/64 fe80::21b:***:****:48ba LAN1/1 RIPng
2001:470:**:***::/64 - TUNNEL[6] implicit
2001:470:**:***::/64 fe80::21b:***:****:48ba LAN1/1 RIPng
2001:470:****:100::/64 - LAN1/1 implicit
2001:470:****:230::/64 fe80::2a0:****:fe35:e2c TUNNEL[1] RIPng
2001:470:****:239::/64 fe80::2a0:****:fe35:e2c TUNNEL[1] RIPng
2001:470:****::/48 fe80::21b:***:****:48ba LAN1/1 RIPng
2403:bd80:****:a203::/64 fe80::250:****:****:2e14 LAN1/1 OSPFv3 E2 c=20 m=20
2403:bd80:****:600::/56 fe80::21b:***:****:48ba LAN1/1 RIPng
2403:bd80:****:100::/64 - LAN1/1 implicit
2403:bd80:****:105::/64 fe80::250:****:****:2e14 LAN1/1 OSPFv3 E2 c=20 m=20
2403:bd80:****:220::/64 fe80::250:****:****:2e14 LAN1/1 OSPFv3 E2 c=20 m=20
2403:bd80:****:ffff::/64 fe80::250:****:****:2e14 LAN1/1 OSPFv3 c=2
2602:****:af2::/48 fe80::21b:***:****:48ba LAN1/1 RIPng
2a0b:****:60::/44 fe80::21b:***:****:48ba LAN1/1 RIPng

• RIPngで受信してる経路(LLAがfe80:から始まり48baに終わる)はCiscoルーターに対する経路です。
• OSPFv3で受信してる経路(LLAがfe80から始まり2e14に終わる)はSEILに対する経路です。

ハマった所

今回もご多分に漏れず色々ハマりました。全部かけてないような気がしますがまぁいいか、取り敢えず頭に残ったものを記載しておきます。

ハマった所1:誤ってBGP+経路を再配送し、インターネットフルルート(IPv6)が内部ルーターに直撃

RouterboardでOSPF設定をしている際、うっかりBGPを経路再配送対象に指定しました。実はこの設定を突っ込む時点で、Routerboardにはインターネットフルルートが埋まってることをすっかり失念していたのです。(IPv6フルルートの経路数、凡そ43000プレフィックス)

SEILに関してはなんとか生きてました(CPU使用率が100%張り付いたけど)が、RTX-3000とCisco1812Jがやられました。疎通途絶&応答なし。慌ててRouterboard側の設定を修正し、再配送設定を修正しましたが後の祭りと言うやつで、内部ルーター3台敢え無く電源リセットと相成りました。

不幸中の幸いで、実家ルーター(RTX-1100)には影響ありませんでした。

ハマった所2:RTXにRIPngに対する経路再配送設定コマンドが「ない」

先述していますが、Cisco側の設定変更で対処しました。結構redistribute設定は普通にあるもんだと思っていたのですが、RTXにはどうもその設定が中途半端な形で実装されているようで、おそらくはOSPFだとimport/exportコマンドが該当すると思われるのですが、RIPngにはもう実質「使う/使わない/受信する/送信する」の設定ぐらいしかないんじゃないかと。予想外過ぎてやられました。

ここ最近思うこと

こう、ネットワークを勉強しながら色々機器を触ってみてるわけなんですが、メーカーごとで特色ってあるんだなぁと。私自身が今まで主に触ってきたルーターはYAMAHAのRTXシリーズなんですが、良いところもあるにはあるんだけど、今回のように微妙に柔軟性に欠ける部分もあるのだなぁと。他のメーカー製品についても、もしかしたらハードが世代変わって問題ないかもしれないんですが、「あの機能がない、この機能がない」ってなことになりかねないんだなぁ・・・って意味で勉強になりました。

実は、ホントの本当の目的は、UTMの経路を動的制御したかった(現状スタティックルート配送)んです。が、UTMの動的経路制御はIPv4に限定されていることが判明しガックリ・・・・何のためにOSPF化したと思ってんねん・・・と思いつつ、でもやり遂げてしまったので、今回こうしてTipsにしました。

参考になれば幸いです。