OSPFの復習
最近CCNPの復習をしているのでアウトプットも兼ねてOSPFについて記述する。
OSPFとは
OSPFとは言わずもがなダイナミックルーティングの1つで、インターフェースの情報を相互にやり取りするためリンクステート型なんて言われたりもする。
メトリックにコスト（IF毎の帯域幅から算出）を用いるルーティングプロトコルで、一般にLAN環境でダイナミックルーティングを利用するならまず使われるプロトコル（な気がする）。
ちなみに現在はOSPFv3まであるがv3はIPv6用なので普通のIPv4環境ならOSPFv2が一般的に使われていると思う。
CCNPのテキストをもとに勉強すると項目が多すぎて吐きそうになるのだが、簡単に項目をまとめるとこんな感じ。
・OSPFでは5種類のパケットを使う
Hello,DBD,LSR,LSU,LSAckの5つ。
Helloパケットでネイバー関係になる→LSAを送りあってLSDBを同期→完全な隣接関係（アジャセンシー）で覚えればいいと思う。
ちなみに、定期的にHelloパケットをマルチキャスト宛に送信してネイバーの生存確認を行っており、定期的にルーティングアップデートを送信してるディスタンスベクタ型と比べるとトラフィック量が軽減されているらしい
・ネットワークタイプも5種類あり、ネットワークタイプによってHelloパケットの送信間隔やネイバーの自動検出有無が変わる（でも普通ブロードキャスト以外使わなくない？とテキストを読んでて思った）
・セグメント毎にDR（代表ルータ）BDR（バックアップ代表ルータ）を選出し、他のDROther同士ではルータの情報（LSA）を送信せずネイバー関係とだけなる
※ネイバーになってからLSDBの同期が完了した状態がアジャセンシ―なので注意。お互いの存在は知ってるけど情報を交換し合わないみたいな。
※DRとBDRはルータプライオリティ→ルータIDの順に選出
・OSPFには認証機能が3つある
NULL認証、シンプルパスワード認証、暗号化認証の3つ。
OSPFの認証って何？って思ったけど、要はOSPFの設定を入れた知らないルータをLANに接続してもそいつとはネイバー関係にならないよということだと思う。
そんな状況あるのか謎だけど、、、
デフォルトはNULL認証＝認証しないなので意識して使ってるケースは少ないのかも？
・定期的にHelloパケットを送りあってるものの、関係ないIFからHelloパケットを出したくない場合はパッシブインターフェースにすればOK
・機器をエリアにわけることができる
大量のルータでOSPFを組むとLSDBの情報が多くなってしまうため、ネットワークをエリアにわけて管理できる
→エリア内の情報だけLSDBに格納すればよく、他エリアの情報は要約されたものだけLSDBに格納すればOK
この時注意点が、バックボーンエリア（エリア0）を必ず作成し、他エリアはバックボーンエリアと接続している必要がある（バーチャルリンクを用いれば例外）
エリアは標準エリアやスタブエリアなど色々種類はあるが、上手く設計することでルート情報を効率的に集約できるようになる。
※エリアは6種類（バックボーンエリア、標準エリア、スタブエリア、トータリースタブエリア、NSSA、トータリーNSSA）
実際、今回の構成ではバックボーンエリア＋標準エリアにしているので手動でエリア間ルート（inter-areaルート）を集約しているが、トータリースタブエリアを使うことで自動でデフォルトルートの形に集約することもできる。
今回の構成
ごちゃごちゃしているが、要はスイッチ6台を通ってPC1からPC2までpingが通るようにOSPFの設定を入れる。
右のSW7はデフォルトルートの宛先として設定しており、デフォルトルートの伝播設定を入れるために追加している。
#default-information originate
※バックボーンエリアや標準エリア以外なら上記コマンドは不要
またエリアの種類で言うとエリア０がバックボーンエリアで、エリア１が標準エリアにあたる。
パケットトレーサー上だとこんな感じ。
設定
多すぎるので割愛するが例えばSW1のOSPFの設定は下記の通り。
#router ospf 1
#network 192.168.10.0 0.0.0.255 area 0
#network 192.168.20.0 0.0.0.255 area 0
#network 192.168.50.0 0.0.0.255 area 0
#passive-int g1/0/1
結果
PC1からPC2（192.168.80.1）へのpingは無事に通った。
面白いなと思ったのはtracertで打った時に経由しているルータが上側と下側で混ざっていたこと。これはいわゆる等コストロードバランシングなのかなと勝手に推測してる（tracertはTTL値を変えて何度もパケットを送り出しているので上側と下側をどちらも経由していると思われる）
実際にルーティングテーブルを確認してみると、192.168.80.0/24宛のルートが2つ登録されていることがわかる。
この「O IA」と書かれているのがinter areaルート、つまり他のエリアから伝播してきたルートのことで、全てのスイッチをエリア０にした場合はここがO（intra areaルート）のままだったはず。
またデフォルトルートもSW6から無事に伝播していてよかった。
「O E2」とあるがEはexternalルートのことで、OSPF以外から取得したルートを表している。
ここで下側の経路のコストを重くしてみる。
#int vlan 50
#ip ospf cost 5
すると192.168.80.0/24宛の経路がvlan20を経由するルート（つまり上側）しか表示されなくなっていることがわかった。
次に上側のケーブルを断線させてみた。
結果、ルーティングテーブルには上側の経路(vlan20)がなくなり下側の経路(vlan50)が再度表示されていた。
この際ping -tで切り替わりのタイミングを調べていたのだが、秒で切り替わった。早すぎませんか、、、
調べたところ、OSPFが有効なIF同士が接続されている場合はリンクダウンによってすぐに切り替わるものの、間にL2スイッチのような機器が挟まっている場合は片側の機器のリンクダウンがしないため、Helloパケットが届かなくなってから40秒ほどで切り替わるとのこと。（＝Deadインターバル）
とは言えリンクがダウンした機器から速やかにリンクダウンの情報がOSPF内で伝播されるため、ルータの両側にL2スイッチが挟まってるような状態でない限りは40秒もかからず切り替えが行われるみたい。
間にL2スイッチを挟んでケーブル断したところ、たしかに40秒はかかっていないが先ほどよりも切り替えに時間を要した。
切り替わりを早くしたい場合はHelloインターバルとDeadインターバルを短くすればいいと思うが、切り替わりを1秒以内に行いたい場合はBFDを利用するとよい。
（CEFが有効であることが前提なのでCisco機器以外は難しい）
ちなみにパケトレで使えるCatalyst3650はBFDに未対応だったので残念ながら検証はできず。
次に経路の手動での集約をやってみる。
※経路の集約ができるのはABRとASBRのみ＝inter-areaルートとexternalルートのみ
まず現在のSW2のルーティングテーブルは下記の通り。
192.168.40、70、80へのルート（inter-areaルート）がそれぞれ登録されている。
そこでABRであるSW3に下記の設定を入れてみる。
#area 1 range 192.168.0.0 255.255.128.0
無事に192.168.0.0/17の経路に集約されていることが確認できた。
ちなみに、この時ABRであるSW3にはループ防止のため転送先がNullのルートが追加されるので気になる人は集約によるループとか不連続サブネットについて調べてみるといいかも。
確認コマンド
ospfに関する確認コマンドもまとめると下記の通り。
#show ip ospf
そのスイッチが属しているエリアの数と種類、認証の有無などがわかる
#show ip ospf database
LSDBの情報がわかる（一番使わなそう？）
#show ip ospf interface
OSPFが有効になってるインターフェースの情報がわかる。ルータIDやネットワークタイプ、DR/BDRか否かやネイバー・アジャセンシーの数などかなり詳細な情報が手に入る。
#show ip ospf neighbor
ネイバーとして認識している機器の情報がわかる。StateがFULLとなっているものがアジャセンシー。
#show ip protocols
OSPFに限らず動作しているルーティングプロトコルが確認できる。
基本的にキャプチャを貼った3種類だけ使えれば困らなそう。
OSPFはここまで。
勉強しては忘れてを繰り返してたけどやっぱりアウトプットって大事だなあと実感。
今後も投稿します（使命感）
別セグメントを経由して同セグメント間通信を実現させる方法を検証してみた
本記事の趣旨
同セグメント間通信は通常L2処理で実現させることができるが、別拠点にそれぞれ同じネットワーク帯を持っている場合、別セグメントを経由してどのように疎通できるかをCisco Packet Tracerを用いて検証する。
構成図
PC1とPC2が同一セグメント上(192.168.1.0/24)に存在し、その間に192.168.2.0/24という別セグメントが存在している。
条件
①ルータにデフォルトルートのみを設定した場合
同じセグメント間であるにもかかわらず、PC1→PC2へのpingは通らない。
これがなぜ通らないかというと、ロンゲストマッチの法則に基づいているからだと推測できる。
ルータ1のルーティングテーブルを参照すると、Connectedルートとして192.168.1.0/24宛ての経路が記載されている。
PC2へ到達するためにはルータ2へ到達＝デフォルトルートを通る必要があるが、ロンゲストマッチの法則により192.168.1.2宛ての通信はデフォルトルートよりもConnectedルートが優先され、ルータ1とConnectedの端末に192.168.1.2のアドレスが存在しないためパケットが破棄されていると考えられる。
ちなみに、ルータ2のアドレスである192.168.2.254にもpingは通らない。
PC1(192.168.1.1)→ルータ2(192.168.2.254)の行きの通信はデフォルトルートの処理で問題なく到達できるが、帰りのパケットの宛先アドレスとなる192.168.1.1はルータ2側でConnectedルートとして処理され、ルータ1へは戻らないためである。
②ルータに/32のスタティックルートを追加した場合
ロンゲストマッチの法則でConnectedルートが優先されるならば、Connectedルートよりも当てはまるビット数が長い/32でスタティックルートを設定した場合はどうなるのかを検討する。
ルータ1
#ip route 192.168.1.2 255.255.255.255 192.168.2.254 を追加
ルータ2
#ip route 192.168.1.1 255.255.255.255 192.168.2.1 を追加
PC1→PC2への疎通が成立した。このことから、ロンゲストマッチの法則でConnectedルートを上回るようスタティックルートを設定すれば別セグメントを経由しても同セグメント間通信は成立することがわかる。
しかしデメリットとして、実環境では各端末（サーバ）毎のスタティックルートをそれぞれのルータに1本ずつ追加する必要があるので、数十行数百行というおびただしい数の設定追加が必要になる。
③ルータにTwice NATの設定を追加した場合
NATには3つ種類が存在する。
・Source NAT
送信元IPを変換する。いわゆる普通のNAT。
・Destination NAT
宛先IPを変換する。主にサーバをインターネット上に公開する際に用いる。
・Twice NAT
送信元/宛先IPをどちらも変換する。
Twice NATで使う主なconfigとしては下記の2つ。
#ip nat inside source static 内部ローカルIP 内部グローバルIP
・Inside側から着信してくるパケットの送信元IPを変換
・Outside側から着信してくるパケットの宛先IPを変換
#ip nat outside source static 外部グローバルIP 外部ローカルIP
・Outside側から着信してくるパケットの送信元IPを変換
・Inside側から着信してくるパケットの宛先IPを変換
送信元IPと宛先IPを変換するTwice NATの設定を入れて、そもそも同セグメント間通信にしなければ疎通ができるのか検証してみる。
なお、ここではNATの変換後のアドレスはすべてルータの物理IFに紐づいているアドレスを指定している。
ルータ1
#ip nat inside source static 192.168.1.1 192.168.2.1
#ip nat outside source static 192.168.2.254 192.168.1.254
#ip route 192.168.1.254 255.255.255.255 g0/1
#int g0/0
#ip nat inside
#int g0/1
#ip nat outside
ルータ2
#ip nat inside source static 192.168.1.2 192.168.2.254
#ip nat outside source static 192.168.2.1 192.168.1.253
#ip route 192.168.1.253 255.255.255.255 g0/1
#int g0/0
#ip nat inside
#int g0/1
#ip nat outside
※ルータのパケット処理の順序は下記の通り。
・Inside→Outsideへの通信
ルーティングテーブル参照→NAT変換→ACLチェック
・Outside→Insideへの通信
NAT変換→ルーティングテーブル参照→ACLチェック
このようにInside側からのパケットはNAT変換が後に来る関係で、/32のスタティックルートを1行追加する必要がある。
show ip nat translationsコマンドでNATテーブルが作成されているのは確認できたが、debug ip natコマンドを打ちPCでpingを打ってもNAT変換が確認できない。なぜ。。。
トラブルシューティングしたところ、ルーティングテーブル上に192.168.1.254が/24ではなく/32でローカルルートとして登録されていることに気づいた。
#ip route 192.168.1.254 255.255.255.255 g0/1
のコマンドが反映されていなかったのである。/24ではなく/32で登録されるのはおそらくパケトレ上のCiscoルータの仕様の問題だと思われる。(Catalystスイッチなら/24で登録される)
このためパケットはNAT変換される前にローカルルートとして識別され、宛先不明で破棄されていたことがわかる。
ここで下記のように修正を試みたが、ルータがadd-routeコマンドに対応しておらず入力も不可。
ルータ1
#no ip route 192.168.1.254 255.255.255.255 g0/1
#no ip nat outside source static 192.168.2.254 192.168.1.254
#ip nat outside source static 192.168.2.254 192.168.1.254 no-alias add-route
ルータ2
#no ip route 192.168.1.253 255.255.255.255 g0/1
#no ip nat outside source static 192.168.2.1 192.168.1.253
#ip nat outside source static 192.168.2.1 192.168.1.253 no-alias add-route
NAT変換後のアドレスが物理IFのアドレスだったためローカルルートと被ってしまったことから、変換後のアドレスは物理IFのアドレスとは違うものを別途用意する必要があると推測した。
※今回は172.16.0.1~3を使用
ルータ1
#ip nat inside source static 192.168.1.1 172.16.0.1
#ip nat outside source static 192.168.2.254 172.16.0.2
#ip route 172.16.0.2 255.255.255.255 g0/1
ルータ2
#ip nat inside source static 192.168.1.2 192.168.2.254
#ip nat outside source static 172.16.0.1 172.16.0.3
#ip route 172.16.0.3 255.255.255.255 g0/1
ルータ1でdebug ip natコマンドを打ちPC1でping(宛先172.16.0.2)を打つと無事に送信元・宛先どちらも変化され、疎通も成功した。
show ip nat translationsコマンドを打っても確かにNAT変換された跡が残っていることが確認できた。（今回はpingで確認したためプロトコルはicmp）
パケットの宛先・送信元の変遷を図にするとこのようになる。
結論
以上の結果から、別セグメントを経由して同セグメント間通信を実施する方法は2つあることがわかった。
１．ロンゲストマッチの法則に基づき、/24で登録されているConnectedルートよりも当てはまるビット数の多い/32のスタティックルートを追加する
⇒実環境ではかなりの数のスタティックルートを記載する必要がある。
２．Twice NATの設定を用いて送信元/宛先IPを変化させる
⇒設定が複雑なため事故の要因になる。また、結局スタティックNATとして1対1で変換アドレスの組みを用意する必要があるので、こちらも現実的ではない。
どちらを使っても面倒な設定が必要になるので結論、別拠点やサーバセグメントはおとなしく別セグメントで設計しましょうねという学び。
今回の勉強はここまで。
〜参考にしたサイト〜
・ネットワークエンジニアとして(双方向NAT)
https://www.infraexpert.com/study/natz7.html
・Cisco公式ドキュメント(NATのトラブルシューティング)
https://www.cisco.com/c/ja_jp/support/docs/ip/network-address-translation-nat/8605-13.html
・Cisco公式ドキュメント(NATの処理順序)
https://www.cisco.com/c/ja_jp/support/docs/ip/network-address-translation-nat/6209-5.html
フローティングスタティックルートについて勉強してみた
本記事の趣旨
フローティングスタティックルートが機能する場合・機能しない場合の条件をCisco Packet Tracerを用いて検証する。
特に出力インターフェースにVLANを割り当てた場合で条件分けを行い、細部の条件を確認する。
フローティングスタティックルートとは
簡単に言えばバックアップ経路みたいなもの。
スタティックルートのAD値は通常1であるが、それを2以上に設定することでメインのプライマリルートがダウンした場合のバックアップルートとしてルーティングテーブルに記載することができる。
(通常時はshow ip routeを打っても出てこず、メイン経路がダウンした時のみ現れる)
構成図
PC1-PC2間の疎通に際し、上側192.168.2.0/24を通る経路をメイン経路とし、下側192.168.3.0/24を通る経路にはAD値をつけサブ経路として設定する。
条件
①メインサブ(G1,G3)どちらもルーテッドポートにアドレスを振った場合
上側が正常時で下側はメイン経路を遮断した状況でのtracert。
メイン経路(ネクストホップ192.168.2.254)を切断した場合、サブ経路(ネクストホップ192.168.3.254)を経由して疎通可能
⇒フローティングスタティックルートとして成立
②メイン経路(G1)はルーテッドポートに、サブ経路(G3)はSVIにアドレスを振った場合
192.168.3.0/24をVLAN30とし、ルーテッドポートではなくSVIとしてCatalyst3650#1に192.168.3.1を、#2に192.168.3.254を割り振る。
こちらもサブ経路を通して疎通可能
⇒フローティングスタティックルートとして成立
③メインサブ(G1,G3)どちらもSVIにアドレスを振った場合
192.168.2.0/24をVLAN20とし、ルーテッドポートではなくSVIとしてCatalyst3650#1に192.168.2.1を、#2に192.168.2.254を割り振る。
こちらもサブ経路を通して疎通可能
⇒フローティングスタティックルートとして成立
念のためCatalyst3650#1のルーティングテーブルを見てみる。
正常時は192.168.4.0/24宛ての経路のNHは192.168.2.254になっている。
一方で、メイン経路遮断時のNHは192.168.3.254に変化しており、フローティングスタティックルートが反映されていることがわかる。
⇒物理インターフェースにVLANが紐づいていても、ダウンした物理インターフェースにのみそのVLANが割り当てられているならば問題なくフローティングスタティックルートが機能すると推測
④メインサブ(G1,G3)どちらもSVIとしてアドレスを振り、メイン経路のVLANを他のポートにも持たせた場合
メイン経路(VLAN20)を遮断してポートをダウンさせる一方で、VLAN20が別のアップしているポートに割り当てられていた場合はフローティングスタティックルートが機能するのか検証する。
イメージとしては上図の感じで、VLAN20がメイン経路のポートだけでなく、他のアップしているポート(=上のCatalystと接続しているポート)に割り当てられていてもメイン経路がダウンしたとみなされるのかを確認した。
結果、メイン経路を遮断してもNHが192.168.2.254(=VLAN20)のままであり、フローティングスタティックルートが機能していないことがわかる(=疎通できない)
結論
以上の結果から、次のことが読み取れる。
１．フローティングスタティックルートが機能するためにはAD値の低い経路(＝メイン経路)の物理インターフェースがダウンする必要がある。
２．ただしその物理インターフェースにVLANを割り当てた場合、そのVLANが割り当てられている全てのポートがダウンしている必要がある。
今回の勉強はここまで。
