tym78さんの助け合いフォーラム投稿一覧
矛盾が生じてるとまでは言えない気がします。
「ルートブリッジのプライオリティ値」という表現では主語が「ルートブリッジ」なので、ブリッジプライオリティのことだとわかると思います。
ポートプライオリティはインターフェースごとに設定するので、主語が「Gi0/0」とか「Gi0/1」になるのではないでしょうか？
また、ポートプライオリティ値の「128」は選択肢にないので、誤り選択肢が見方によっては正解になってしまうなどの不備も起きていませんし。
②だと思いますが、ENCORがないとENARSIの受験資格がないということにはならず、受ける順番はどっちが先でも大丈夫なはずです。
ただ、ENCOR→ENARSIの順が一般的だと思います。
ENCORとENARSIの2つを取得した時点でCCNP Enterpriseの認定となります。
参考になりそうな情報です↓
https://www.cisco.com/c/ja_jp/training-events/training-certifications/certifications/professional/ccnp-enterprise.html
https://www.cisco.com/c/ja_jp/training-events/training-certifications/recertification-policy.html#~how-to-recertify
https://www.infraeye.com/2020/08/17/ciscoexam027/#:~:text=CCNP%20Enterprise%E8%A9%A6%E9%A8%93%EF%BC%9A%E5%8F%97%E9%A8%93%E3%81%99%E3%82%8B%E9%A0%86%E7%95%AA%E3%80%81%E5%8B%89%E5%BC%B7%E6%96%B9%E6%B3%95%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6
過去の助け合いフォーラムに似たような質問があったので、こちらも参考になりそうです。
https://mondai.ping-t.com/g/posts/917
インターフェースに適用する場合、そのインターフェースを通過するトラフィック全てがフィルタリングの対象となります。
この問題ではACLでhostを指定していますが、anyで指定した場合など、他のルータ宛のトラフィックも予期せずブロックしてしまう可能性などが考えられます。
インターフェースへのACL適用は広範囲に影響を及ぼす可能性があるため、慎重になる必要があります。
一方でVTYラインへの適用ではこのルータに対する管理アクセスに絞ってフィルタリングが行われるためより局所的な制御となります。
他の通常のトラフィックに影響を与えることがなく、インターフェースへの適用に比べて運用も容易になるといえます。
おそらく、「OSPFよりもスタティックルートの方がAD値が高いために、」という部分が少し言葉足らずな感じになっていて、
「OSPFよりもスタティックルートの方がAD値 "の優先度" が高いために、」ということを言いたいのだと思います。
AD値の値は、小さい方が優先度が高く、大きい方が優先度が低いです。
変数dataは波括弧「{}」で囲まれた「key: value」の形式になっており、辞書型データとして定義しているように見えますが、なぜそのように思われたのでしょうか？
試しに変数dataのデータ型をtype()を使って確認すると、以下のようになります。
(dataの中身は長いので少し省略してますがご了承ください)
[test.py]
import json
data = {
"hostname": "RouterA",
"interfaces": {
"Loopback0": {
"ipv4-address": "1.1.1.1",
"subnet-mask": "255.255.255.255",
"shutdown": "no"
}
}
}
#変数dataのデータ型を出力
print(type(data))
#辞書型の変数dataを文字列型に変換して、変数data2に代入
data2 = (json.dumps(data, separators=(',', ':')))
#変数data2のデータ型を出力
print(type(data2))
#変数data2を出力
print(data2)
[実行結果]
C:\> python test.py
<class 'dict'>
<class 'str'>
{"hostname":"RouterA","interfaces":{"Loopback0":{"ipv4-address":"1.1.1.1","subnet-mask":"255.255.255.255","shutdown":"no"}}}
1行目の<class 'dict'>という出力から変数dataは辞書型だとわかります。
2行目の<class 'str'>という出力から変換後の変数data2は文字列型だとわかります。
これはそういうもんだと覚えるしかないのでしょうか？
はい、そうです。
RESTCONFでネットワーク機器の設定を変更するということは、YANGモデルのデータを操作するということです。
POSTで設定を追加する際に対象のネットワーク機器が対応しているYANGモデルを使ってデータを指定してあげないと、機器側は何を追加したいのか認識できません。
つまり、あらかじめ決められているデータ構造に従って設定を追加したり変更したりする必要があります。
あなたが「"source"」や「"destination"」の方がしっくりくるなと思っても、決められたデータ構造と異なる場合、機器側には通じないということです。
試しに「"source":"any"」を使ってリクエストしてみましたが、以下のようにエラーになりました。
"error-message"に「unknown element: source」と書かれています。これは機器側が「source」というキーを知らない(あらかじめ決められているデータ構造にはない)からです。
{
"ietf-restconf:errors": {
"error": [
{
"error-type": "application",
"error-tag": "malformed-message",
"error-path": "/Cisco-IOS-XE-native:native/ip/access-list",
"error-message": "unknown element: source in /ios:native/ios:ip/ios:access-list/ios-acl:extended[ios-acl:name='ACL4']/ios-acl:access-list-seq-rule[ios-acl:sequence='100']/ios-acl:ace-rule/ios-acl:source"
}
]
}
}
じゃあどうやってデータ構造を知ることができるのかという話になると思いますが、GETリクエストで実際にデータを取得したり、GitHubなどで公開されているYANGモデルを取得したりできます。
詳しくは以下のサイトが参考になると思います。
https://www.infrastudy.com/?p=1262
https://www.it-enjoy.com/entry/2021/01/26/190000#%E5%89%8D%E6%9B%B8%E3%81%8D
https://ccieojisan.net/post-2031/#RESTCONF
ネクストホップの情報=IPヘッダに含まれる宛先IPアドレス という勘違いをされているのではないでしょうか。
実際に、次のホップの宛先アドレスを示すのは、イーサネットヘッダの宛先MACアドレスです。
ネットワークデバイスがIPパケットを転送する際、ルーティングテーブルを参照して次のホップのIPアドレスを決定しますが、このIPアドレスは直接IPヘッダに含まれるわけではありません。(IPヘッダに含まれる宛先IPアドレスは最終的な目的地であるため)
そのため、ARPを使用して、その次のホップのIPアドレスに対応するMACアドレスを取得します。
そして、このMACアドレスが外部イーサネットヘッダの宛先MACアドレスとして設定されます。
なので、VXLANパケットの転送においてネクストホップの情報を示すのは、外部イーサネットヘッダの宛先MACアドレスです。
参考URLに載っている以下のサイトに詳しく説明されています。
https://milestone-of-se.nesuke.com/nw-basic/grasp-nw/ethernet-ip-address/#toc2
スタブエリアか、スタブエリアではないかを識別するフラグのことだと思います。
Ciscoの情報が載っているサイト：
https://www.cisco.com/c/ja_jp/support/docs/ip/open-shortest-path-first-ospf/7039-1.html#toc-hId-50449744
エリアがスタブとして設定されている場合、そのエリアに属するすべてのインターフェイスは、インターフェイスがスタブであることを示すフラグを付けてHelloパケットを交換します。
実際のところ、これは Hello パケット内の 1 ビット（E ビット）が 0 に設定されることで、実現されます。共通のセグメントを持つすべてのルータは、そのフラグに同意する必要があります。そうしないと、ネイバーにならず、ルーティングが有効になりません。
シスココミュニティ：
https://community.cisco.com/t5/switching/stub-area-flag-in-ospf/td-p/2672098
余談ですが、用語をネットで検索する時に「cisco stub area flag」や「cisco スタブエリアフラグ」のように英語にしたり「cisco」というキーワードを入れたりするとCisco公式の情報がヒットしやすくなり、試験勉強に役立つと思います。
コマンド構文の図にも記載されていますが、送信元セッションの設定と宛先セッションの設定で指定する宛先IPアドレスを一致させる必要があります。
宛先IPアドレス=対向ルータのIPアドレスではありません。
この例の場合、SwitchAが送信元、SwitchBが宛先となっているので、SwitchBのIPアドレスが宛先IPアドレスとして両方の設定で使用されます。
「ネイティブVLANをサポートしている」という表現に対して私は別に問題はないと思いました。
この問題はIEEE 802.1Q中の記載内容について問われている訳ではないと思います。
「untagged set」より「ネイティブVLAN」の方がネットワーク用語としては広く知られてるのでわかりやすいのではないでしょうか。
トランク接続によるネイティブVLANの動作を考えてみます。
トランクポートの設定で「switchport trunk encapsulation dot1q」を使ってトランキングプロトコルをIEEE802.1Qにします。
このポートにタグ無しのフレームが流れた場合、それらのトラフィックはネイティブVLANとして認識されます。
当然、IEEE802.1Qを使用しているトランクポートではネイティブVLANがサポートされています。
ネイティブVLANがサポートされていなければタグ無しのフレームが適切に処理されなくなってしまいます。
ちなみにCiscoの公式ガイドブックには、IEEE802.1Qで規定されているタグ無しトラフィックの扱いについて以下のような記載がありました。
In the 802.1Q standard, any traffic that is transmitted or received on a trunk port without the 802.1Q VLAN tag is associated to the native VLAN.
(802.1Q規格では、トランクポートで送受信される802.1Q VLANタグがない任意のトラフィックは、ネイティブVLANに関連付けられます。)
この文からも「IEEE 802.1QはネイティブVLANをサポートしている」といっても問題なさそうだと感じました。
設問のルータで設定されているルーティングプロトコルはeigrpのみ（複数のルーティングプロトコルが出てこない）であるにも関わらず、
再配送の設定が必要になるという点がいまいち理解できずにいます。
この問題のルーティングの設定にはEIGRPとスタティックルートが使用されています。
R2の設定には[ip route 3.3.3.3 255.255.255.255 10.1.2.3]があるので、
R2のルーティングテーブルに載っている[3.3.3.3]宛のルートはスタティックルートです。
(スタティックルートのAD値は1で、ルーティングテーブルに載る優先度が高い)
[redistribute static]コマンドはスタティックルートをEIGRPへ再配送するという意味で、
R2が持っている[3.3.3.3]宛のスタティックルートを再配送するための設定です。
R2はルーティングテーブルにEIGRPで学習した[3.3.3.3]宛のルートを持っているわけではないので、
EIGRP同士で再配送しているということにはなりません。
再配送とは、異なるルーティングプロトコル間でルート情報をやりとりするときに必要となる設定の認識なのですが、この認識が間違っているのでしょうか？
こちらのご認識は正しいです。
スタティックルートはEIGRPとは異なるルーティング方法なので、再配送が必要ということになります。
余談ですが、R2に対して以下の設定を行った場合でも問題の要件を満たせます。
[network 10.1.2.0 0.0.0.255]でGi0/2でEIGRPを有効にして、
[no ip route 3.3.3.3 255.255.255.255 10.1.2.3]でスタティックルートを削除すると、
R2のルーティングテーブルにはR3からEIGRPで学習した[3.3.3.3]宛のルートが載るようになるので、
再配送の設定がなくてもEIGRPによってR1へ[3.3.3.3]宛のルートが伝播されるようになります。
これはスタティックルートを削除して、3yamotさんがおっしゃっているeigrpのみ（複数のルーティングプロトコルが出てこない）の状況になった場合の話です。
問題としては破綻していないから誤植なのかは微妙な気がしました。
トータリースタブエリアはタイプ5（External LSA）、タイプ4（Summary ASBR LSA）、およびタイプ3（Summary LSA）を受け取りません。
しかしながら、ABRはトータリースタブエリアにデフォルトルートを注入するために特別なタイプ3のLSAを用いてデフォルトルートのみを送信します。
Pnt1205_004さんの意見も間違ってはいないと思います。
ただし、他の選択肢にはLSAタイプ4,5,7とかが入っているため明らかに間違いといえます。
トータリースタブエリア内の内部ルータが受信するLSAタイプとして「1,2」が最も正しい選択肢として適切なので、問題として成立していますし、別に誤植という訳でもない気がします。
「show lacp neighbor」の「Port」で表示されている番号は自分のポートのことですね。
なので、この問題で表示されているのはCatAのFa0/6とFa0/7のことです。
対向(CatB)の情報は「Flags」のところで確認しますが、ポートの番号は出力されていないです。
試しに以下のように2台を別々のポート番号で接続してみました。
・CatAのGi0/0とCatBのGi0/1を接続
・CatAのGi0/2とCatBのGi0/3を接続
CatA#sh run interface gi 0/0
Building configuration...
Current configuration : 101 bytes
!
interface GigabitEthernet0/0
media-type rj45
negotiation auto
channel-group 10 mode active ←イーサチャネルの設定
end
CatA#sh run interface gi 0/1
Building configuration...
Current configuration : 71 bytes
!
interface GigabitEthernet0/1
media-type rj45
negotiation auto
end
CatA#sh run interface gi 0/2
Building configuration...
Current configuration : 101 bytes
!
interface GigabitEthernet0/2
media-type rj45
negotiation auto
channel-group 10 mode active ←イーサチャネルの設定
end
CatA#sh run interface gi 0/3
Building configuration...
Current configuration : 71 bytes
!
interface GigabitEthernet0/3
media-type rj45
negotiation auto
end
CatA#show lacp neighbor
Flags: S - Device is requesting Slow LACPDUs
F - Device is requesting Fast LACPDUs
A - Device is in Active mode P - Device is in Passive mode
Channel group 10 neighbors
Partner's information:
LACP port Admin Oper Port Port
Port Flags Priority Dev ID Age key Key Number State
Gi0/0 SP 32768 5003.001a.0000 15s 0x0 0xA 0x2 0x3C ←CatAでイーサチャネルの設定を行ったGi0/0
Gi0/2 SP 32768 5003.001a.0000 18s 0x0 0xA 0x4 0x3C ←CatAでイーサチャネルの設定を行ったGi0/2
CatA#
CatB#sh run int gi 0/0
Building configuration...
Current configuration : 71 bytes
!
interface GigabitEthernet0/0
media-type rj45
negotiation auto
end
CatB#sh run int gi 0/1
Building configuration...
Current configuration : 102 bytes
!
interface GigabitEthernet0/1
media-type rj45
negotiation auto
channel-group 10 mode passive ←イーサチャネルの設定
end
CatB#sh run int gi 0/2
Building configuration...
Current configuration : 71 bytes
!
interface GigabitEthernet0/2
media-type rj45
negotiation auto
end
CatB#sh run int gi 0/3
Building configuration...
Current configuration : 102 bytes
!
interface GigabitEthernet0/3
media-type rj45
negotiation auto
channel-group 10 mode passive ←イーサチャネルの設定
end
CatB#sh lacp neighbor
Flags: S - Device is requesting Slow LACPDUs
F - Device is requesting Fast LACPDUs
A - Device is in Active mode P - Device is in Passive mode
Channel group 10 neighbors
Partner's information:
LACP port Admin Oper Port Port
Port Flags Priority Dev ID Age key Key Number State
Gi0/1 SA 32768 5003.0019.0000 5s 0x0 0xA 0x1 0x3D ←CatBでイーサチャネルの設定を行ったGi0/1
Gi0/3 SA 32768 5003.0019.0000 9s 0x0 0xA 0x3 0x3D ←CatBでイーサチャネルの設定を行ったGi0/3
CatB#
問題文に「以下のネットワークではPC4が他のPCと通信できない。」とあることから自分の認識では、
この問題の通りにネットワーク機器を設定したら「"絶対"にループが発生する」と思っていたのですが、
解説にも"ルーティングループが発生する危険性があります。"と書いてあるので、ループ発生の可能性はあり得ますが、絶対に発生するかどうかは別という感じかなと思います。
発生するかどうかは各ルータやプロセスの起動タイミングとかによって変わってきます。
複数のルーティングプロトコルを使用しているとプロトコルによって収束時間も異なる(OSPFやEIGRPに比べてRIPの収束時間は遅い)ので、このあたりもネットワークが不安定になる要因になったりします。
この問題では、もしタイミング的にうまいこといってループが発生しないパターンがあったとしても、このネットワーク構成でループが発生しうる原因は「distance eigrp 90 95」が設定されている点だからこの部分をフィルタリングした方が良いよねって感じですかね。
(問題文は「PC4が他のPCと通信できない。」となっているので、ループが発生しているパターンで問われているのは明らかですが)
もし最初はループが発生しないパターンで動作していても、運用中に何かしら障害が発生してルータやプロセスやインターフェースのダウン、再起動などを機にルーティングアップデートでループが発生するパターンでルーティングテーブルが更新されるかもしれません。
そうではなく、問題の通りの設定でもループが発生しないパターンもある、ということでよろしいでしょうか？
RCがもとは自分が発信した192.168.51.0の経路情報をRAやRBから受け取らなければループは発生しないはずなので、192.168.51.0の経路情報がRA-RB-RC間でループしないパターンは以下のような場合が考えられると思います。
・RA-RC間のEIGRPでスプリットホライズンの働きによって、ネクストホップがRAとなる192.168.51.0の経路情報をRCが受信しない
(RAはRCをネクストホップとする192.168.51.0の経路情報を受信しています)
・RA-RB間のEIGRPでスプリットホライズンの働きによって、ネクストホップがRAとなる192.168.51.0の経路情報をRBが受信しない
(RAはRBをネクストホップとする192.168.51.0の経路情報を受信しています)
・RB-RC間のOSPFでネクストホップがRBとなる192.168.51.0の経路情報をRCが受信しない
(OSPFではスプリットホライズンが働くわけではありませんが、LSDB、SPFアルゴリズムによってループが発生しないようになってます。RBはRCをネクストホップとする192.168.51.0の経路情報を受信しています)
このような状況になれば、RCは192.168.51.0の経路情報をRAやRBからは学習せずにRDからRIPで学習するので、RA-RB-RCのトライアングルでループすることはなくなるはずだと思います。
なので結局、RA→RCとRC→RA(またはRA→RBとRB→RA)のどっちが先に192.168.51.0の経路情報を学習して、どっちがスプリットホライズンで伝播されないようになるかのタイミングの問題なんじゃないでしょうか。
参考になりそうなサイトです↓
IOSルーティング編<第1回> 再配布の基礎
第32回再配布(3) ルーティングループ
EIGRPではもともとルーティングループを回避するためのメカニズムとしてスプリットホライズンが備わっています。
スプリットホライズンは「ルートを学習したインターフェイスから同じルートをアドバタイズしない」というものです。
この問題でループが発生している状況では、RCはRAからEIGRPで「192.168.51.0/24」の経路情報を学習しているので、スプリットホライズンが発動してRCからRAに「192.168.51.0/24」の経路情報は送られないというようなことが起こっていると考えられます。
なので、nishina_dnsさんがおっしゃっている「★RCが「192.168.51.0/24」の経路情報をRAへEIGRPで送信する」の動作はスプリットホライズンで回避されているということになります。
解説の2つ目の図にあるRAのtracerouteの結果を見ると、RAは192.168.51.100へRBを経由して到達しようとしていることがわかりますので、RCを経由するルートはRAのルーティングテーブルに載っていないはずです。(これはスプリットホライズンによってRCを経由するルートは学習できていないからです。)
スプリットホライズンの参考情報です。
Enhanced Interior Gateway Routing Protocol の理解および使用
ちなみにもし、RAがRCとRBの両方から等コストで宛先が同じ経路情報を受信していたとしたら、EIGRPでは等コストロードバランシングが行われるので、ルーティングテーブルには2つのパスが載ります。
ルーティングテーブルに2つのパスが載っていたら、tracerouteの結果は両方のパスを使っていることがわかるような結果になると思います。
ルーティングループは、ルータやプロトコルの起動タイミング、ネットワークの収束タイミングなどによって、同じ構成でも発生する場合としない場合があったりして結構複雑です。
以前の質問の回答でも記載してますが、この説明はあくまでもこの問題の設定において "ループが発生する原因となっている" 経路学習の順について説明しているという点を忘れないでくださいね。
自分の勝手な認識としても再配布されたルートはそのまま残り続ける認識
こちらのご認識が違っているのかと思います。
OSPFやEIGRPを使ったダイナミックルーティングはルーター同士が常にルート情報を交換しあって、ルーティングテーブルの最適化を動的に行うものです。
再配布されるルートも、ネットワークのトポロジが変わったり、設定が変更されたりした場合には更新されます。
経路情報が変更されてもルーティングテーブルに変化がないのであれば、ダイナミックルーティングのメリットがないですよね。。。
(手動でいちいち全部変更しないといけないスタティックルーティングと同じ)
OSPFはリンクステートデータベース(LSDB)、EIGRPはトポロジテーブルを持ち、各ルータがネットワーク全体のトポロジを保持しています。
ルーティングテーブルはLSDBやトポロジテーブルから最適な経路を選んで作成されます。
OSPFでは、ネットワーク内のすべてのOSPFルータが同じLSDBの情報を持ち、リンクの状態が変化するとLSDBが更新されます。
EIGRPでは、トポロジテーブルは隣接関係を持つルータ間で情報交換が行われ、トポロジの変更があれば、その変更情報が伝播されます。
LSDBやトポロジテーブルはほぼリアルタイムで更新され、これらをもとに作成されるルーティングテーブルにも古い経路情報が残り続けるということはありません。
参考になりそうなリンクをいくつか貼っておきます↓
【EIGRP】隣接テーブルとトポロジーテーブルの確認
ルータのプロトコル再配布の設定
Dynamic Routing
ルーティングテーブルを理解する
まず、経路学習のAD値についてのご認識が間違っていると思いますので、訂正させて頂きますね。
①RCではRIP⇔OSPF,RIP⇔EIGRP間で経路情報を再配送する設定がされていることから、RCは192.168.51.0/24の経路情報をRA,RBそれぞれに伝える。
(このとき、RA,RBが受け取るAD値は120)
・RC-RA間ではEIGRPで経路学習が行われるため、RAがRCから学習する192.168.51.0/24のAD値は170です。
(192.168.51.0/24の経路情報は、RIPエリアの情報なので外部EIGRPの170)
・RC-RB間ではOSPFで経路学習が行われるため、RBがRCから学習する192.168.51.0/24のAD値は110です。
(OSPFのAD値は外部、内部に関わらず110)
②RBは、受け取った192.168.1.0/24の経路情報をRAに伝える。
(このとき、RA,RBが受け取るAD値は110)
・RB-RA間ではEIGRPで経路学習が行われるため、RAが受け取る経路情報のAD値は170です。
次にこの問題の構成における経路学習について説明します。
解説の3つ目の図の水色の矢印が示しているような順で経路学習が行われて、ルーティングループが発生してしまいます。
ループが発生する経路学習の流れは以下のような感じです。
①RCが「192.168.51.0/24」の経路情報をRBへOSPFで送信する(RBが学習する情報のAD値はOSPFの110)
②RBが①で学習した「192.168.51.0/24」の経路情報をRAのEIGRPへ再配送する(RAが学習する情報のAD値は外部EIGRPの170)
③RAが②で学習した「192.168.51.0/24」の経路情報をRCのEIGRPへ送信する(RCが学習する情報のAD値は95)
※「distance eigrp 90 95」によってRCでは外部EIGRPで学習する経路情報のAD値を95にするよう設定しているため、RCが受け取る情報のAD値は95となります。
また、「distance」コマンドによるAD値の変更はローカルのみで有効なので、他のルータにこれが通知されることはありません。
RCがRDからRIPで受け取る情報(転送先がRDとなる経路)のAD値は120ですが、③でEIGRPで学習した情報(転送先がRAとなる経路)のAD値95の方が小さくなります。
このことから、RCは「192.168.51.0」宛のパケットをRAに転送してしまうので、ループが発生します。
この問題と同じような構成を作ってみたので参考までに、各ルータの「show ip route 192.168.51.0」の出力結果を載せておきます。
①RBは「192.168.51.0」の経路情報をRCからOSPFで学習
RB#sh ip route 192.168.51.0
Routing entry for 192.168.51.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1 ←OSPFで学習していて、AD値は110であることがわかります
Redistributing via eigrp 1
Advertised by eigrp 1 metric 1000000 1 255 1 1500
Last update from 172.16.1.3 on GigabitEthernet0/2, 00:20:37 ago
Routing Descriptor Blocks:
* 172.16.1.3, from 192.168.1.3, 00:20:37 ago, via GigabitEthernet0/2 ←ネクストホップはRCの172.16.1.3でRC(192.168.1.3)からこの経路を学習していることがわかります
Route metric is 20, traffic share count is 1
②RAは「192.168.51.0」の経路情報をRBからEIGRPで学習
RA#sh ip route 192.168.51.0
Routing entry for 192.168.51.0/24
Known via "eigrp 1", distance 170, metric 3072, type external ←EIGRPで学習していて、AD値は170であることがわかります
Redistributing via eigrp 1
Last update from 10.1.1.2 on GigabitEthernet0/0, 00:21:42 ago
Routing Descriptor Blocks:
* 10.1.1.2, from 10.1.1.2, 00:21:42 ago, via GigabitEthernet0/0 ←ネクストホップはRBの10.1.1.2でRB(10.1.1.2)からこの経路を学習していることがわかります
Route metric is 3072, traffic share count is 1
Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
③RCは「192.168.51.0」の経路情報をRAからEIGRPで学習
RC#sh ip route 192.168.51.0
Routing entry for 192.168.51.0/24
Known via "eigrp 1", distance 95, metric 3328, type external ←EIGRPで学習していて、AD値は95であることがわかります
Redistributing via eigrp 1, rip, ospf 1
Adve ospf 1 subnets
Last update from 10.1.2.1 on GigabitEthernet0/1, 00:20:47 ago
Routing Descriptor Blocks:
* 10.1.2.1, from 10.1.2.1, 00:20:47 ago, via GigabitEthernet0/1 ←ネクストホップはRAの10.1.2.1でRA(10.1.2.1)からこの経路を学習していることがわかります
Route metric is 3328, traffic share count is 1
Total delay is 30 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2rtised by rip metric 1
再配送とAD値について詳しく解説してくれているサイトがありましたので、良かったら参考に見てみてください。
https://hirotanoblog.com/cisco-administrative-distance/3068/
「正規のルータを全てのセカンダリVLANと通信可能なプロミスキャスポートに接続し、他のポートはプライマリVLANとしか通信できない独立ポートにします。」
の部分から空いている他のポートに不正なルータが接続されても通信できないように正規のルータを接続するポート以外のポートはプロミスキャスポートにせずにプライマリVLANとしか通信できない独立ポートにするということだと思います。
「不正なルータがプロミスキャスポートに接続された場合はほかのポートと通信できてしまうので」とおっしゃっていますが、例えば正規のルータを外して、もともと正規のルータが接続されていたプロミスキャスポートに対して不正なルータを繋ぐということを想定されていますか？
空いているポートに不正なルータが接続されてしまっても通信できないように独立ポートにしておくのがプライベートVLANを使ったファーストホップセキュリティの仕組みだと思うので、このような場合への対策は別の手段でセキュリティを確保する必要が出てくるんじゃないでしょうか。
(そもそも攻撃者を物理的に近づけないとか、RAガードとか、ポートに接続できるMACアドレスの制限とか)
EIGRPのメトリック = 256 ×～
と
帯域幅 = 10,000,000 ÷～
と
遅延 = ～ ÷ 10の式の値についてはデフォルトで決まっているものなのでしょうか
はい。メトリックを計算する際の公式の定数として覚えてしまって大丈夫です。
なぜこのような定数を使用するかというと、少し数学的な話になりますが、正規化して帯域幅や遅延を簡単な数字で表すことができるようになるためです。
例えば、帯域幅や遅延に（Kbps）とか（μ秒）のような単位接頭辞がついていますが、これを外して数字だけで表現すると、数字が大きくなりすぎたり小さくなりすぎたりしてわかりにくいですよね。
経路上の最小帯域幅（Kbps）= 100000 （Kbps）=100000000（bps）
経路上の遅延合計（μ秒）= 1110（μ秒）= 0.00111（秒）
[計算の例]
帯域幅 = 10000000÷100000（Kbps） = 100
遅延 =（1000（μ秒）+100（μ秒）+10（μ秒））÷10 = 111
EIGRPのメトリック = 256 ×（ 100 + 111 ） = 54016
上記は解説に載っている計算式の一例ですが、公式にあてはめて定数を使って計算することで帯域幅100、遅延111のように簡単な数字になっています。
もともと、100000000（bps）、0.00111（秒）のように全然異なる値だったものが、帯域幅=100、遅延=111のように近い値になって計算しやすくなっていることがわかります。
256の数値についてはwikiより
「複合メトリック値はIGRPでは24ビットの値だが、EIGRPでは32ビットの値になっている。
したがって、24ビットの値を256倍することで8ビット左へシフトしたのと同じことになり、
値が32ビットに拡張される。」とありますがいまいち理解できませんでした
IGRPはEIGRPの前に開発されたCisco独自のプロトコルで、複合メトリックの計算においてEIGRPとIGRPの後方互換性を保つ必要があったみたいですね。
内部的にIGRPの複合メトリックは24ビット、EIGRPでは32ビットとなっています。
EIGRPのメトリックは、内部的には32ビット値として表現されていますが、32ビットのうち実際にメトリック計算で使用されるのは上位24ビットだけです。(じゃあEIGRPも最初から24ビットにしとけば良かったんじゃないのと思ってしまいますが...)
なのでEIGRPでは上位24ビットを使用する32ビットのメトリック値(上位24ビットには値が入っていて使用しない下位8ビットは全部0)を用意するために、24ビットの値を8ビット左へシフト(2の8乗で256倍)する必要があるということになります。
シフト演算については以下が参考になると思います。
https://tech.pjin.jp/blog/developer/2022/09/28/kihonjoho_2_5/
参考になりましたら幸いです。
この設定の場合「distribute-list 10 in GigabitEthernet0/1」の意味は以下の通りです。
・RAからOSPFでアドバタイズされる「192.168.10.0/24」の経路情報をGi0/1でブロック
in GigabitEthernet0/1 となっているのでGi0/1のインバウンド方向（受信する経路情報）にディストリビュートリストが適用されていることを意識するといいと思います。
なので、
①RAからOSPFでアドバタイズされる「192.168.10.0/24」の経路情報を、RBとRDがOSPF側のインターフェースであるGi0/1でブロックする
②RBとRDがOSPFで受信時に「192.168.10.0/24」の経路情報をブロックしたので、この経路情報がOSPFエリアからRIPエリアへ再配送されることもなくなる
という流れでRIPへの再配送をブロックしています。