JPNICのサイト(https://www.nic.ad.jp/ja/newsletter/No45/0800.html)にあるようにDNSのルートサーバはいくつかの組織は、信頼性や応答性能の向上、ハードウェア障害への対策などの理由から、IPエニーキャスト※4技術などを利用して地理的分散や冗長化を行い、同じルートサーバ名(IPアドレス)で複数のサーバを運用しているからです。同じルートサーバ名(IPアドレス)で複数のサーバ...同じIPアドレスで複数のサーバで地理的分散もされているっぽいのでその確認をしてみました。Serversを見る。a.root-servers.netのIPアドレスが198.41.0.4であることが確認できます。拡大してみると...確かに、a.root-servers.netのIPアドレスが198.41.0.4でロケーションが複数(フランクフルト:ドイツ、ロンドン:イギリスなど)あり、地理的分散されている模様。■自分のパソコンからtracertしてみる。[198.41.0.4]トレースを完了しました。----------------------------------------------------------------------------------------------トレースがうまくいっていることが確認できました。■宛先198.41.0.4の一つ前209.131.156.127がどこにあるか?whois検索をして確認してみます。tech-unlimited.com日本にa.root-servers.netあるのに、アメリカ行ってしまってるっぽい...です。■Cloudのサーバをアメリカに作成する_1Pingはできるけど、tracertができない。reply^Cazureuser@myVM:~$トレースコマンドがOS上になかったので、mtrコマンド使ってみました。あきらめた、、次にAWSで試してみます。■Cloudのサーバをアメリカに作成する_2■こちらのOSも、トレースコマンドがOS上になかったのでmtrコマンド使ってみました。~]$■宛先198.41.0.4の一つ前217.30.85.127がどこにあるか?同じくwhois検索してみると...以下のサイト(https://www.janog.gr.jp/meeting/janog34/doc/janog34-acast-matsuzaki-1.pdf)に書いてある内容からすると、クライアントから見ると、近くの198.41.0.4に行っているのかと思ったんですが違いました。anycastが地理的分散されているっぽいのは確認できました。switchoverの基本的な動作を確認してみました。構成図は同じままで、1つだけ設定を変更してみます。sparse-modeをとる...という設定です。sparse-modeの設定が入っています。sparse-modeを削除してみます。switchoverがうまくいかないことが期待される動作です。sparse-modeの設定を削除しておきます。255.255.255.0end■このときのこの時の共有ツリー(今回も225.1.1.1が使用するマルチキャストグループです。225.1.1.1)送信元ツリーだけ確認していましたが、今回は通るルートが重要です。どのルートを通るかは、ツリーのRPF情報を確認します。Fowarding))現状をもう一度図にすると...となるはずです。225.1.1.1)のグループでRPFが192.168.23.2になっているからなりそう)。switchoverが起きなかったことが確認できました。◇マルチキャストは前提として、IGPが動作している必要があります。ーティングが完成していることが必要なので注意してください。IGPが通るルートにマルチキャストが一緒に通る...というイメージです。IGPとマルチキャストが同じルートを通っていることは・IGPはtraceroute・マルチキャストはmtraceそれぞれのトレースルートコマンドで確認できます。sparse-modeが入っていないことを発見する以外にIGPに向いてしまっているマルチキャストのルート(R3-R2)をマルチキャストが通れる側のルート(R3-R1-R2)に変更する...という方法もあります。mrouteコマンドです。192.168.13.1また、図にすると...今度は、R3-R1-R2を通るルートで送信元ツリーができるはずです。■R3に設定を入れてみます。Mroute★ルートがR1側を向いた。02:26:17/00:02:49■この状態でpingをうつと成功します。※R4で227.1.1.1の別のマルチキャストのグループを登録していますが初期化的な意味あいで行っています。*を複数ルータで行ってさらに、225.1.1.1で共有ツリーが再度作成されるまで時間がかかるので227.1.1.1を追加で同じ動作を行っています。227.1.1.1)の送信元ツリーができました。■マルチキャストはIGPでルートを学習しているルートを通るのですがRPFがおかしいと正しく動作しないことが確認できました。マルチキャストがおかしくなり始めるルータのR3にとっては、IGPが通るルートは、R2側なのに(R2が最短ルート)マルチキャストは、R1側を向くなんておかしい!となっていると言えます。mrouteコマンドで無理やりR1側に向かせるとうまくいくというのが面白いですね。sparse-modeが入っているのがいい設計といえるみたいです。mrouteコマンドの使い方)----------▼tunnel→マルチキャスト受信しているのが、tunnel0しかし、RPFはE0/0▼NBMA→マルチキャストは受信インターフェースを送信にできない。PROFESSIONAL)」https://www.amazon.co.jp/%E8%A9%B3%E8%A7%A3IP%E3%83%9E%E3%83%AB%E3%83%81%E3%82%AD%E3%83%A3%E3%82%B9%E3%83%88-%E6%A6%82%E5%BF%B5%E3%81%8B%E3%82%89Cisco%E8%A3%BD%E5%93%81%E3%81%A7%E3%81%AE%E8%A8%AD%E5%AE%9A%E4%BE%8B%E3%81%BE%E3%81%A7-Gene-ebook/dp/B06XZY37XFに載っています。今回の機器のコンフィグは以下にあります。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。