tym78さんの助け合いフォーラム投稿一覧
まず、ルートマップMAP1はRDからREへBGPのどの経路情報を伝達するかを決めるためのフィルタとして用意されています。
(もしかしたら、この点を何か誤解していて、混乱しているのではないでしょうか？違ったらすみません。)
ルートマップを適用すると、permitされている経路情報しかRDからREへ伝えられなくなるので、MAP1の設定において、「10.1.3.0」と「10.1.4.0」の経路情報は暗黙のdenyによってRDからREへ伝達されなくなります。
そのため、REはRDから「10.1.3.0」と「10.1.4.0」の経路情報を教えてもらえないため、RD(198.51.100.5)をネクストホップとするこれらの経路情報を持つことができなくなります。
(ルートマップ適用前はRDをネクストホップとするこれらの経路情報を持っていました。設問の図のREの「show ip bgp 」からわかります。)
つまり、ルートマップ適用後、REは「10.1.3.0」と「10.1.4.0」宛の経路情報をRCからしか学習しないので、ネクストホップがRC(192.0.2.9)の経路情報のみ知っています。
これは解説の図のルートマップを適用した後のREの「show ip bgp 」からわかります。
REから「10.1.3.0」と「10.1.4.0」に到達するには、RCを経由する経路しか知らないので、以下の選択肢が正解となります。
・「10.1.3.0/24」宛のパケットはRC経由で転送される
・「10.1.4.0/24」宛のパケットはRC経由で転送される
たしかに結果としてはいずれの設定でも「192.168.1.0/24」がRBのルーティングテーブルに載ることはないです。
ただ、①と②の設定では「192.168.1.0/24」はルートマップの暗黙のdenyによってフィルタリングされているといえます。
暗黙のdeny回避用のシーケンスを追加すると、「192.168.1.0/24」がRBのルーティングテーブルに載るようになります。
ここからは推測ですが、設問の空欄の位置的に、ルートマップMAP1のシーケンス10を使って「192.168.1.0/24」をフィルタリングしたいという意図があってこのような解答になっているのではないでしょうか。
しかしながら、設問文にそのような意図がはっきり書かれているわけでもなく、暗黙deny回避用のシーケンスが設定に入っているわけでもないので、問題の改善の余地がありそうですね。
検証を行ってみましたので、参考にどうぞ。
[解答の設定で暗黙のdeny回避用のシーケンスを追加した場合]
RA#show access-lists
Standard IP access list 1
10 permit 192.168.1.0, wildcard bits 0.0.0.255 (3 matches) ←ACL1を「permit」に設定
Standard IP access list 2
10 permit 192.168.2.0, wildcard bits 0.0.0.255 (24 matches)
Standard IP access list 3
10 deny 192.168.3.0, wildcard bits 0.0.0.255 (22 matches)
Standard IP access list 4
10 deny 192.168.4.0, wildcard bits 0.0.0.255 (22 matches)
RA#show route-map MAP1
route-map MAP1, deny, sequence 10 ←シーケンス10を「deny」に設定
Match clauses:
ip address (access-lists): 1
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map MAP1, permit, sequence 20
Match clauses:
ip address (access-lists): 2
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map MAP1, deny, sequence 30
Match clauses:
ip address (access-lists): 3
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map MAP1, permit, sequence 40
Match clauses:
ip address (access-lists): 4
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map MAP1, permit, sequence 50 ←暗黙のdeny回避用のシーケンスを追加
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
RB#sh ip route eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
D 192.168.2.0/24
[90/130816] via 192.168.100.1, 00:32:00, GigabitEthernet0/1 ←「192.168.1.0/24」が載っていない
D 192.168.3.0/24
[90/130816] via 192.168.100.1, 00:32:00, GigabitEthernet0/1
D 192.168.4.0/24
[90/130816] via 192.168.100.1, 00:32:00, GigabitEthernet0/1
D 192.168.5.0/24
[90/130816] via 192.168.100.1, 00:32:00, GigabitEthernet0/1
[①の設定で暗黙のdeny回避用のシーケンスを追加した場合]
RA#show access-lists
Standard IP access list 1
10 deny 192.168.1.0, wildcard bits 0.0.0.255 (6 matches) ←ACL1を「deny」に設定
Standard IP access list 2
10 permit 192.168.2.0, wildcard bits 0.0.0.255 (20 matches)
Standard IP access list 3
10 deny 192.168.3.0, wildcard bits 0.0.0.255 (18 matches)
Standard IP access list 4
10 deny 192.168.4.0, wildcard bits 0.0.0.255 (18 matches)
RA#
RA#show route-map MAP1
route-map MAP1, deny, sequence 10 ←シーケンス10を「deny」に設定
Match clauses:
ip address (access-lists): 1
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map MAP1, permit, sequence 20
Match clauses:
ip address (access-lists): 2
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map MAP1, deny, sequence 30
Match clauses:
ip address (access-lists): 3
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map MAP1, permit, sequence 40
Match clauses:
ip address (access-lists): 4
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map MAP1, permit, sequence 50 ←暗黙のdeny回避用のシーケンスを追加
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
RB#sh ip route eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
D 192.168.1.0/24
[90/130816] via 192.168.100.1, 00:21:47, GigabitEthernet0/1 ←「192.168.1.0/24」がフィルタリングされていない
D 192.168.2.0/24
[90/130816] via 192.168.100.1, 00:21:47, GigabitEthernet0/1
D 192.168.3.0/24
[90/130816] via 192.168.100.1, 00:21:47, GigabitEthernet0/1
D 192.168.4.0/24
[90/130816] via 192.168.100.1, 00:21:47, GigabitEthernet0/1
D 192.168.5.0/24
[90/130816] via 192.168.100.1, 00:21:47, GigabitEthernet0/1
[②の設定で暗黙のdeny回避用のシーケンスを追加した場合]
RA#show access-lists
Standard IP access list 1
10 deny 192.168.1.0, wildcard bits 0.0.0.255 (2 matches) ←ACL1を「deny」に設定
Standard IP access list 2
10 permit 192.168.2.0, wildcard bits 0.0.0.255 (26 matches)
Standard IP access list 3
10 deny 192.168.3.0, wildcard bits 0.0.0.255 (24 matches)
Standard IP access list 4
10 deny 192.168.4.0, wildcard bits 0.0.0.255 (24 matches)
RA#show route-map MAP1
route-map MAP1, permit, sequence 10 ←シーケンス10を「permit」に設定
Match clauses:
ip address (access-lists): 1
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map MAP1, permit, sequence 20
Match clauses:
ip address (access-lists): 2
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map MAP1, deny, sequence 30
Match clauses:
ip address (access-lists): 3
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map MAP1, permit, sequence 40
Match clauses:
ip address (access-lists): 4
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map MAP1, permit, sequence 50 ←暗黙のdeny回避用のシーケンスを追加
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
RB#sh ip route eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
D 192.168.1.0/24
[90/130816] via 192.168.100.1, 00:01:37, GigabitEthernet0/1 ←「192.168.1.0/24」がフィルタリングされていない
D 192.168.2.0/24
[90/130816] via 192.168.100.1, 00:39:05, GigabitEthernet0/1
D 192.168.3.0/24
[90/130816] via 192.168.100.1, 00:39:05, GigabitEthernet0/1
D 192.168.4.0/24
[90/130816] via 192.168.100.1, 00:39:05, GigabitEthernet0/1
D 192.168.5.0/24
[90/130816] via 192.168.100.1, 00:39:05, GigabitEthernet0/1
矛盾が生じてるとまでは言えない気がします。
「ルートブリッジのプライオリティ値」という表現では主語が「ルートブリッジ」なので、ブリッジプライオリティのことだとわかると思います。
ポートプライオリティはインターフェースごとに設定するので、主語が「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アドレスの制限とか)