ネットワークスペシャリスト試験過去問

このブログは、Advent Calendar 2019 大國魂（ITブログ）の17日目です。

ネットワークスペシャリストの試験を5年ぐらい受験しているのですが、なかなか受かりませんが、過去問を結構勉強して知見がたまってきたので、公開したいと思います。

平成29年午後1 問3 設問3(4)

めちゃくちゃピンポイントですが、この問題を取り上げてみます。以下(4)の問題分だけ引用してみます。

本文中の下線⑤について、経路のループを防止するために必要な経路制御を40字以内で述べよ。

下線⑤前後の文章は以下

I主任：そうですね。そういえば一点注意が必要です。経路情報の再配布を行うときは、経路のループを防止しなければいけません

Oさん：わかりました。⑤経路のループを防止する経路制御を行います。

再配布されるときの状態としては以下画像のような感じです。

R2とR3が同じASで、R4とR5が同じASです。下図だとちょっとわかりずらいので、念のため。

f:id:TKCman:20191121135412p:plain

③と⑥が再配布している場所です。⑥の再配布をしてしまうことで
問題がおきてしまうというのがIPAの回答でした。

IPAの回答

eBGPからOSPFへ再配布された経路を再びeBGPへ再配布しない

というものです。

ループが実際におきるところは

R7のところです。

R7がR8から受け取ったサーバの経路情報(7.7.7.7)とR5から再配布で戻ってきたサーバの経路情報(7.7.7.7)を比べて、R5のほうが勝ってしまいます。

f:id:TKCman:20191121140857p:plain

特に深く考えないでいるとR8からきたルートのほうが強いんじゃないかと思ってしまいますが、OSPF→BGPに再配布された入ってきたルート(最初の図の⑥)のメトリックが、R8からきたルートのメトリックより高いことがあるというのがポイントだと思います。（たぶん高くなると思います。すいません、たぶんで。R5のルートのほうがメトリック高くないとループがおきない→つまり、問題の条件が起きえない。）

R5とR8で動いているのがどんなIGP(ripv2、EIGRP、OSPF)でも起こりえるようなループなのではないかと思われます。

そのため、下図のようなループがおきます。

f:id:TKCman:20191121141350p:plain

⑫以降は、R1、R2、R4、R7、R5、R3のルータでループし続けます。（TTLがなくなるまで）

IPAの回答を実際の機器設定まで落とし込めるか？

OSPFからBGPに再配布してきたルートのメトリック設定する方法をちゃんと探してみました。上のほうで、たぶんと言ってしまいましたが、以下設定とかがありそうな設定かと思います。

シナリオ 2

（network コマンドか redistribute コマンドのいずれかによって）BGP に挿入されたルートが IGP（RIP または EIGRP、もしくは OSPF）を使用している場合、MED のメトリック値は IGP のメトリックから受け継ぎ、ルートはこの MED を使用して eBGP ネイバーにアドバタイズされます。

このシナリオでは、次のネットワーク構成を使用しています。

～途中のconfigとか省略～

R2 では RIP と BGP の両方が実行されています。 show ip bgp コマンドを実行すると、プレフィックス 10.0.0.0 ネットワークのメトリックは 1 になっていることに気付きます。この値は、RIP から受け継いだものです。

R2 の出力結果は、次のとおりです。

しかし、eBGP を実行中の R3 には、IGP から受け継いだ MED 値に基づいてネットワークがアドバタイズされています。この例では RIP です。プレフィックス 10.0.0.0 には、RIP のメトリック値 1 の IGP MED 値がアドバタイズされます。

これは、次の出力結果で確認できます。

https://www.cisco.com/c/ja_jp/support/docs/ip/border-gateway-protocol-bgp/112965-bgpmed-attr-00.html

ここで、再度IPAの回答を確認してみます。

eBGPからOSPFへ再配布された経路を再びeBGPへ再配布しない

別解としては、シスコのサイトの方法を応用した「OSPFからeBGPへ再配布するときメトリックをもとルートよりも大きい値にする。」とかでもよいきがします。

あと、ルートにタグをつけてタグ付いているルートは再配布で戻さないとかがシスコのルータの技とかでありますが、それだとシスコonlyっぽくなってしまうので、ちょっと違う感じがします。

タグつける方法

https://www.infraexpert.com/study/routecontrol16.html

回答の「再び…再配布しない」に含まれるといえば含まれるので、タグつける方法がIPAの回答のもとになった設定かもしれないです。

あとAWSと接続するときの実際のciscoのconfigは、networkコマンドで渡していて、再配布ではないですが、network コマンドか redistribute コマンドのいずれかによってBGP に挿入されたルートのメトリックが…とcisco公式サイトに書いてあるので、netwrokコマンドか再配布（redistribute）かは気にしなくてもいいのかもしれないです。（以下の引用参照して下さい。networkコマンドのところ、デフォゲ渡しているが、細かく渡したいルート指定したかったら、network 192.168.・・・とか書けばよい）

router bgp YOUR_BGP_ASN
neighbor 169.254.255.1 remote-as 7224
neighbor 169.254.255.1 activate
address-family ipv4 unicast
neighbor 169.254.255.1 remote-as 7224
neighbor 169.254.255.1 default-originate
neighbor 169.254.255.1 activate
network 0.0.0.0

https://docs.aws.amazon.com/ja_jp/vpc/latest/adminguide/Cisco.html

azureとかのbgp接続もnetworkコマンドで設定しているので、問題作成した人はどのようにこの問題を作ったかが気になります。

set protocol bgp <Edit>65521</Edit>
set enable
set hold-time 30
set neighbor <Edit>192.168.10.142</Edit> remote-as <Edit>65516</Edit>
set neighbor <Edit>192.168.10.142</Edit> enable
set neighbor <Edit>192.168.10.142</Edit> hold-time 30
set neighbor <Edit>192.168.10.142</Edit> ebgp-multihop 2
set ipv4 neighbor <Edit>192.168.10.142</Edit> activate
set ipv4 network <Edit>192.168.127.0/24</Edit> weight 100

https://qiita.com/yotan/items/367be1a8390713306b5e

過去問のBGPの設定がわかりそうな図は下図です。

f:id:TKCman:20191219160735p:plain

◇　◇　◇

ネットワークスペシャリストの試験でルーティングの問題は、ちょっと珍しい気がするのでとりあげてみました。

この問題は、色々そぎ落としすぎてよくわからない感じになってしまっている気がしますが、、ネットワークスペシャリストの試験のIPsecの問題とかはすごく勉強になるので、勉強してみるのもいいかもしれません。

2019-06-21

パケットの遅延とか損失の話

Uber、モバイルアプリの通信をHTTP/2からQUICに変更して表示速度改善。TCPとUDPの違いによるQUICのメリットは大きい。 / “Employing QUIC Protocol to Optimize Uber's App Performance | Uber Engineering Blog” https://t.co/3gOzL3x1wP
— アロハのmatsuu🐧 (@matsuu) June 2, 2019

のニュース中身読んでみた

eng.ube

QUICの話まで理解できなかったけど、パケットの遅延とかRTTが気になってしまった。

ワイヤレス上のTCPパフォーマンス
TCPはもともと有線ネットワーク用に設計されていました。
有線ネットワークには、予測可能なリンクがあります。
ただし、ワイヤレスネットワークには独自の特性と課題があります。
第１に、無線ネットワークは干渉および信号減衰による損失を受けやすい。
たとえば、WiFiネットワークは、マイクロ波、ブルートゥース、および
その他の種類の電波からの干渉を受けやすいです。
セルラネットワークは、建物などの環境内のものによる反射／吸収、および
近隣の基地局からの干渉による信号損失（または経路損失）の影響を受ける。
これらの結果、有線のものよりもはるかに長く（例：4～10倍）
可変ラウンドトリップタイム（RTT）
およびパケット損失が発生します。

携帯とかは有線の4～10倍の

ラウンドトリップタイム（RTT）
パケット損失

らしい。

RTTについては、説明省略（https://jehupc.exblog.jp/15349359/の図がわかりやすかった。）

さらに

高いRTT値と、中央値のほぼ6倍のテールエンド値があり、平均分散は1秒を超えています。
さらに、ほとんどの接続は損失が多く、TCPは総パケット数の3.5％を再送していました。
駅や空港などの混雑した場所では、ネットワークによってパケットが廃棄されるのは最大7％でした。
これらの結果は、セルラーネットワークの高度な再送信方式がトランスポート層での損失を
大幅に減らすという共通の概念に挑戦しています。
以下に、モックアプリケーションでテストを実行した結果の概要を示します。

以下の表もニュースの中にあったが

ネットワークメトリクス	値
ミリ秒単位のRTT [50％、75％、95％、99％]	[350、425、725、2300]
RTT差異（秒）	平均〜1.2秒
損失の多い接続でのパケット損失率	平均約3.5％（渋滞地域では7％）

50％が350ミリ秒
75％425ミリ秒(パケットの25%が425ミリ秒のRTT)
95％725ミリ秒(パケットの20%が725ミリ秒のRTT)
99％2300ミリ秒(パケットの4%が2300ミリ秒のRTT)

つまり、有線は

350÷4=87.5ミリ秒のRTT
総パケット数の7％÷4=1.75% or 7％÷10=0.7%パケット損失（有線の損失率が1%前後ってことらしい。）

前雑誌の付録でついていたRTTはスゴイ小さい値だったけど理想の値ってこと？

f:id:TKCman:20190621113911j:plain

普通にPINGしてみたら、30ミリ秒ぐらいだった。

yahoo.co.jp [183.79.135.206]に ping を送信しています 32 バイトのデータ:
183.79.135.206 からの応答: バイト数 =32 時間 =29ms TTL=51
183.79.135.206 からの応答: バイト数 =32 時間 =20ms TTL=51
183.79.135.206 からの応答: バイト数 =32 時間 =37ms TTL=51
183.79.135.206 からの応答: バイト数 =32 時間 =26ms TTL=51

183.79.135.206 の ping 統計:
パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンドトリップの概算時間 (ミリ秒):
最小 = 20ms、最大 = 37ms、平均 = 28ms

ニュースの中のリンクで面白いのがあって*1

なぜオーバーバッファリングが問題なのか

バッファが大きすぎると、いっぱいになり遅延が発生し、インターネットの多くの用途が破壊されます。

株式トレーダーやゲーマーは、競合相手に1msの優位性さえも持たせたくありません。

音楽を再生するには、ジッタ（遅延の変動）とレイテンシを制御し、100ミリ秒未満に保つ必要があります。

何かを手に「感じる」ようにするために（完璧なラバーバンディング）、レイテンシは30ミリ秒の範囲を下回る必要があります。

キーボードエコーが知覚できないほど50ms

長距離ネットワークではVoIP（Voice over IP）が光速度による遅延を支配しているため、エンドツーエンドの遅延を150ミリ秒（長距離電話のメトリック）未満に抑えるには、アクセスの遅延が重要になります。

bufferbloatによる過度のパケット損失は、DNS（Domain Name System）検索に失敗する可能性があります。

ARP、DHCP、RA、NDなどの重要なネットワークプロトコルはすべてタイムリーな応答を想定しており、それなしでは失敗する可能

あります。

遅延は数百ミリ秒から数秒に及ぶため、Webブラウジングは困難になります。

とか遅延の許容の話が書いてあった。

まとめ

無線（QUICなし）

350ミリ秒のRTT
損失率が平均約3.5％

有線

87.5ミリ秒のRTT（実測30ミリ秒くらい）
損失率が1%前後

回線が遅いなと思ったときの判断の基準にできるかもしれない。

*1:https://queue.acm.org/detail.cfm?id=2071893

2019-05-30

DMVPNのインターフェース設定

やりたいこと

IPsecやNHRPの解説はよく見るけど、インターフェース設定の話はあまりなかったので、まとめてみます。

ちなみに

1.IPsec

2.NHRP

3.DMVPNのインターフェース

の順番で通信が確立されていくので、IPsecができて、NHRPも設定できていないと DMVPNのインターフェースを色々設定しても意味ないです。

NHRPについて

上の2.NHRPについて考えます。

https://blog.ine.com/2008/08/02/dmvpn-explained に以下記述があります。

The protocol has been defined quite some time ago in RFC 2332 (year 1998) to create a routing optimization scheme inside NBMA (non-broadcast multiple-access) networks

つまり、NHRPは、NBMAネットワークの環境でつかう技術ということ。

NBMAとは

①　ブロードキャストマルチアクセス

②　ポイントツーポイント

③　NBMA（ Non Broadcast Multi Access )

の3種類のうちのひとつ。

フレームリレーやATM接続などのWANリンクでセグメント上に2台以上のルータが接続できますが、ブロード　キャスト機能のないネットワークです。このネットワークではDR/BDRの選出がされますが、OSPFネイバーは　手動で設定する必要があります。※ 正確に言うとNBMAモードの種類により自動接続されるモードもあります。

https://www.infraexpert.com/study/ospfz8.htmlより

NBMAは、ブロードキャストっぽいけど、ブロードキャストしてくれないインターフェス。そして、DMVPNを設定するtunnelインターフェースは、NBMAの一種でデフォルトpoint-to-pointなので、DMVPNのフェーズごとにインターフェスの設定を変更する必要があります。また、今回は、phase3は範囲外

DMVPNのインターフェースの位置づけ

NBMA

1-1. インターフェスの種類（ATM,Tunnelとか）

1-2. インターフェスのタイプを変更するコマンド

non-broadcast/broadcast/point-to-point/point-to-multipoint /point-to-multipoint nonbroadcast

1-3. DMVPN

1-3-1. tunnelはデフォルトpoint-to-point

1-3-2. tunnelをphaseごとに設定を変える　
<例>point-to-pointからbroadcastに変更する

最後の赤字のところが今回考えるところです。

Phase1のとき

OSPF

-- HUB “ip ospf network point-to-multipoint”

-- SPOKE point-to-point(デフォルト)

■設定例

interface Tunnel0

ip address 10.0.0.1 255.255.255.0

～略～

ip ospf network point-to-multipoint

https://blog.ine.com/2008/08/02/dmvpn-explained

EIGRP

-- HUB no ip split-horizon eigrp 110

-- SPOKE 特に必要なし

■設定例

　Cisco(config)# interface Serial0/0

　Cisco(config-router)#no ip split-horizon eigrp 10

https://www.infraexpert.com/study/eigrpz14.html

解説

Phase1は、通信が絶対HUBを経由するため OSPFでは、Spokeをpoint-to-pointに設定する。 EIGRPは、スプリットホライズンを止める。スプリットホライズンをとめるとインターフェースで折り返しの通信ができるようになる。

Phase2のとき

OSPF

“ip ospf broadcast”

-- HUB 特に必要なし

--SPOKE ip ospf priority 0（DRにならないように設定）

EIGRP

-- HUB no ip split-horizon eigrp 110+no ip next-hop-self eigrp 110

-- SPOKE 特に必要なし

解説

Phase2は、通信がHUBを経由せず、SPOKEが直接SPOKEどうしで通信する。 OSPFでは、SpokeをbroadcastにすることでSPOKEどうしの通信を実現する。 EIGRPは、スプリットホライズンを止めるのプラス、HUBのインターフェースを経由しないようにする（no ip next-hop-self eigrp 110）ことで SPOKEどうしの通信を実現する。

2019-04-08

Kubernetesでpodが起動しない_controllerがおかしい

node2がCrashLoopBackOffするのが治ったと思ったら今度は、controllerがおかしい

[root@master ~]# kubectl get pod -n metallb-system -o wide
NAME                          READY   STATUS              RESTARTS   AGE   IP              NODE     NOMINATED NODE
controller-567586546b-dvn9b   0/1     ContainerCreating   0          28m             nodelb   
speaker-6trpq                 1/1     Running             0          28m   192.168.52.83   nodelb   
speaker-8rlqr                 1/1     Running             0          28m   192.168.52.81   node1    
speaker-rrg68                 1/1     Running             0          28m   192.168.52.82   node2    
[root@master ~]#
[root@master ~]#

kubectl describe nodesでcontrollerの確認

  Normal   SandboxChanged          102s (x12 over 113s)  kubelet, nodelb    Pod sandbox changed, it will be killed and re-created.
  Warning  FailedCreatePodSandBox  101s (x4 over 104s)   kubelet, nodelb    (combined from similar events): Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "352e9ae06a6fac420c26173d34e551323ba6d1a88a6073304ce7b2fe2a221f63" network for pod "controller-567586546b-dvn9b": NetworkPlugin cni failed to set up pod "controller-567586546b-dvn9b_metallb-system" network: failed to set bridge addr: "cni0" already has an IP address different from 10.244.2.1/24

failed to set bridge addr: "cni0" already has an IP address

IPをすでに持っていると、、このエラー内容で検索 qiita.com によると、以下コマンドで削除のflannel削除の必要あり。 ip link delete flannel.1 , ip link delete cni0

うまくいきました。

[root@master ~]# kubectl get pod -n metallb-system -o wide
NAME                          READY   STATUS    RESTARTS   AGE   IP              NODE     NOMINATED NODE
controller-567586546b-vfkpg   1/1     Running   0          44s   10.244.2.98     nodelb   
speaker-9fckf                 1/1     Running   0          44s   192.168.52.82   node2    
speaker-ckhjp                 1/1     Running   0          44s   192.168.52.81   node1    
speaker-z49bl                 1/1     Running   0          44s   192.168.52.83   nodelb

bootcampできました。

f:id:TKCman:20190408114935p:plain

ちょっと感動した。実はダッシュボードの設定とかうまくいってないので、もうちょっと頑張ります。。

2019-04-05

Kubernetesでpodが起動しない_CrashLoopBackOff

もう少しで完成しそうなのにうまくいかない

ccie-go.com

このURLを参考にKubernetes自宅に作っていました。（このサイトなかったらkubernetesやろうと思わなかったです。大変ありがとうございます。m(__)m）最後のbootcampのところでなぜかRunningにならず、、

[root@master ~]# kubectl get pod -o wide
NAME                                   READY   STATUS              RESTARTS   AGE     IP       NODE    NOMINATED NODE
kubernetes-bootcamp-598f57b95c-5mg5g   0/1     ContainerCreating   0          7d21h      node2   
[root@master ~]#

でbootcampが動いているnodeのflannelの動作がおかしい…というところまでは突き止めました。

[root@master ~]# kubectl get pod -n kube-system
NAME                             READY   STATUS             RESTARTS   AGE
coredns-576cbf47c7-59nqg         1/1     Running            0          48m
coredns-576cbf47c7-95hv2         1/1     Running            0          48m
etcd-master                      1/1     Running            0          41m
kube-apiserver-master            1/1     Running            0          41m
kube-controller-manager-master   1/1     Running            0          41m
kube-flannel-ds-gx9jc            1/1     Running            0          39m
kube-flannel-ds-hzvs2            1/1     Running            0          39m
kube-flannel-ds-k9gnc            0/1     CrashLoopBackOff   7          40m
kube-flannel-ds-l9wbd            1/1     Running            0          41m
kube-proxy-4csbj                 1/1     Running            0          40m
kube-proxy-gfr8w                 1/1     Running            0          48m
kube-proxy-lzqxw                 1/1     Running            0          39m
kube-proxy-nsfvf                 1/1     Running            0          39m
kube-scheduler-master            1/1     Running            0          41m
[root@master ~]#
[root@master ~]#

CrashLoopBackOffというのが起きている。。対応するflannelの名前を確認。（kube-flannel-ds-k9gnc）

kubectl describe nodesでどのノードと紐づいているか確認。（以下kubectl describe nodesコマンド抜粋）

Addresses:
  InternalIP:  192.168.52.82
  Hostname:    node2
Capacity:
 cpu:                1
 ephemeral-storage:  8178Mi
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             1958400Ki
 pods:               110
Allocatable:
 cpu:                1
 ephemeral-storage:  7717729063
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             1856000Ki
 pods:               110
System Info:
 Machine ID:                 1a22a7e8e4d64bc2b854d23256618274
 System UUID:                564D51B1-33E9-8F98-0C5A-E7288C59C38C
 Boot ID:                    bed998a1-0378-46c8-b068-e5562b499bb0
 Kernel Version:             3.10.0-957.el7.x86_64
 OS Image:                   CentOS Linux 7 (Core)
 Operating System:           linux
 Architecture:               amd64
 Container Runtime Version:  docker://17.6.0
 Kubelet Version:            v1.12.3
 Kube-Proxy Version:         v1.12.3
PodCIDR:                     10.244.1.0/24
Non-terminated Pods:         (2 in total)
  Namespace                  Name                     CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ---------                  ----                     ------------  ----------  ---------------  -------------
  kube-system                kube-flannel-ds-k9gnc    0 (0%)        0 (0%)      0 (0%)           0 (0%)
  kube-system                kube-proxy-4csbj         0 (0%)        0 (0%)      0 (0%)           0 (0%)
Allocated resources:

同じコマンドkubectl describe nodesのnode2に対するエラーの内容を見てもよくわからなかったです。

Name:               node2
Roles:              
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/hostname=node2
Annotations:        kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
                    node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Wed, 03 Apr 2019 23:20:01 -0400
Taints:             node.kubernetes.io/not-ready:NoSchedule
Unschedulable:      false
Conditions:
  Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----             ------  -----------------                 ------------------                ------                       -------
  OutOfDisk        False   Wed, 03 Apr 2019 23:32:04 -0400   Wed, 03 Apr 2019 23:20:01 -0400   KubeletHasSufficientDisk     kubelet has sufficient disk space available
  MemoryPressure   False   Wed, 03 Apr 2019 23:32:04 -0400   Wed, 03 Apr 2019 23:20:01 -0400   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure     False   Wed, 03 Apr 2019 23:32:04 -0400   Wed, 03 Apr 2019 23:20:01 -0400   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure      False   Wed, 03 Apr 2019 23:32:04 -0400   Wed, 03 Apr 2019 23:20:01 -0400   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready            False   Wed, 03 Apr 2019 23:32:04 -0400   Wed, 03 Apr 2019 23:20:01 -0400   KubeletNotReady              runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

node2でkubeadm resetしたり、masterでkubeadm initしたりしましたが、解消せず、、検索して出てきた結果flannelまわりがおかしいっぽいのはわかるのですが、不明。。

なんかひらめいた

kube-flannel.ymlの command: [ "/opt/bin/flanneld", "--ip-masq", "--kube-subnet-mgr", "--iface=ens160" ]あたりがあやしい。

node2だけ、NICのインターフェースがens192になってしまっていた。

node2

[root@node2 ~]# ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens192:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:59:c3:8c brd ff:ff:ff:ff:ff:ff
    inet 192.168.52.82/24 brd 192.168.52.255 scope global noprefixroute ens192
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe59:c38c/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

node1

[root@node1 ~]# ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens160:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:88:68:cd brd ff:ff:ff:ff:ff:ff
    inet 192.168.52.81/24 brd 192.168.52.255 scope global noprefixroute ens160
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe88:68cd/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

node2で負荷高いのが原因か！とか思って再起動とかしてしまっていてNICの名前が変わってしまったみたいです。（下図の192.168.52.82でCPUが49％になっているところ。49％でビビッて再起動してしまった。） f:id:TKCman:20190405172851p:plain

nmtuiでNICの名前をens192からもとのens160に書き換え f:id:TKCman:20190405163339p:plain

別の名前とIPでNICが上がってきてしまったため、断念。色々やってみたのですが、うまくens160にならなかったです。node2のVMのスナップショットでyumでk8s設定入れる前まで戻しました、、

うまくいくかはわからないがcommand: [ "/opt/bin/flanneld", "--ip-masq", "--kube-subnet-mgr", "--iface=ens160", "--iface=ens192" ] で試してみました。

[root@master ~]#
[root@master ~]# kubectl get pod -n kube-system
NAME                             READY   STATUS    RESTARTS   AGE
coredns-576cbf47c7-hq4k9         1/1     Running   0          4m38s
coredns-576cbf47c7-xh8h8         1/1     Running   0          4m38s
etcd-master                      1/1     Running   0          3m41s
kube-apiserver-master            1/1     Running   0          3m51s
kube-controller-manager-master   1/1     Running   0          3m37s
kube-flannel-ds-9cdlv            1/1     Running   0          58s
kube-proxy-29b6k                 1/1     Running   0          4m38s
kube-scheduler-master            1/1     Running   0          3m51s
[root@master ~]#
[root@master ~]#
[root@master ~]#
[root@master ~]# kubectl get pod -n kube-system
NAME                             READY   STATUS    RESTARTS   AGE
coredns-576cbf47c7-hq4k9         1/1     Running   0          5m41s
coredns-576cbf47c7-xh8h8         1/1     Running   0          5m41s
etcd-master                      1/1     Running   0          4m44s
kube-apiserver-master            1/1     Running   0          4m54s
kube-controller-manager-master   1/1     Running   0          4m40s
kube-flannel-ds-9cdlv            1/1     Running   0          2m1s
kube-flannel-ds-jbnrs            1/1     Running   0          8s
kube-proxy-29b6k                 1/1     Running   0          5m41s
kube-proxy-vdnmv                 1/1     Running   0          8s
kube-scheduler-master            1/1     Running   0          4m54s
[root@master ~]#
[root@master ~]#
[root@master ~]#
[root@master ~]# kubectl get pod -n kube-system
NAME                             READY   STATUS              RESTARTS   AGE
coredns-576cbf47c7-hq4k9         1/1     Running             0          6m28s
coredns-576cbf47c7-xh8h8         1/1     Running             0          6m28s
etcd-master                      1/1     Running             0          5m31s
kube-apiserver-master            1/1     Running             0          5m41s
kube-controller-manager-master   1/1     Running             0          5m27s
kube-flannel-ds-8vt88            0/1     Init:0/1            0          8s
kube-flannel-ds-9cdlv            1/1     Running             0          2m48s
kube-flannel-ds-jbnrs            1/1     Running             0          55s
kube-flannel-ds-kdkww            1/1     Running             0          19s
kube-proxy-29b6k                 1/1     Running             0          6m28s
kube-proxy-4m7ks                 0/1     ContainerCreating   0          8s
kube-proxy-ktklf                 1/1     Running             0          19s
kube-proxy-vdnmv                 1/1     Running             0          55s
kube-scheduler-master            1/1     Running             0          5m41s
[root@master ~]#
[root@master ~]#
[root@master ~]# kubectl get pod -n kube-system
NAME                             READY   STATUS     RESTARTS   AGE
coredns-576cbf47c7-hq4k9         1/1     Running    0          6m35s
coredns-576cbf47c7-xh8h8         1/1     Running    0          6m35s
etcd-master                      1/1     Running    0          5m38s
kube-apiserver-master            1/1     Running    0          5m48s
kube-controller-manager-master   1/1     Running    0          5m34s
kube-flannel-ds-8vt88            0/1     Init:0/1   0          15s
kube-flannel-ds-9cdlv            1/1     Running    0          2m55s
kube-flannel-ds-jbnrs            1/1     Running    0          62s
kube-flannel-ds-kdkww            1/1     Running    0          26s
kube-proxy-29b6k                 1/1     Running    0          6m35s
kube-proxy-4m7ks                 1/1     Running    0          15s
kube-proxy-ktklf                 1/1     Running    0          26s
kube-proxy-vdnmv                 1/1     Running    0          62s
kube-scheduler-master            1/1     Running    0          5m48s
[root@master ~]#

kubectl joinで無事上がってきました！！（赤字のflannel）続きます。

2018-12-05

IP anycast

Advent Calendar 2018 大國魂（ITブログ）の9日目です。

JPNICのサイト（https://www.nic.ad.jp/ja/newsletter/No45/0800.html）にあるようにDNSのルートサーバは

いくつかの組織は、信頼性や応答性能の向上、ハードウェア障害への対策などの理由から、
IPエニーキャスト※4技術などを利用して地理的分散や冗長化を行い、同じルートサーバ名（IPアドレス）で複数のサーバを運用しているからです。

同じルートサーバ名（IPアドレス）で複数のサーバ

…

同じIPアドレスで複数のサーバで地理的分散もされているっぽいのでその確認をしてみました。

■http://www.root-servers.org/index.htmlに接続

下のほうのRoot Serversを見る。
a.root-servers.netのIPアドレスが198.41.0.4であることが確認できます。

f:id:TKCman:20181205160326p:plain

もう少し拡大してみると...

f:id:TKCman:20181205160422p:plain

確かに、a.root-servers.netのIPアドレスが198.41.0.4でロケーションが複数（フランクフルト：ドイツ、ロンドン：イギリスなど）あり、地理的分散されている模様。

■自分のパソコンからtracertしてみる。

----------------------------------------------------------------------------------------------

C:\Users\hogehoge>tracert 198.41.0.4

a.root-servers.net [198.41.0.4] へのルートをトレースしています
経由するホップ数は最大 30 です:

1 1 ms 6 ms 5 ms 192.168.0.254
～中略～

13 * 108 ms 108 ms i-0-0-0-1.paix-core02.telstraglobal.net [202.84.143.210]
14 107 ms * 107 ms i-92.paix02.telstraglobal.net [202.84.247.41]
15 108 ms 108 ms 108 ms xe-1-1-0.r1.bb-fo.sfo1.vrsn.net [198.32.176.30]
16 134 ms 117 ms 107 ms 209.131.156.127
17 112 ms 112 ms 109 ms a.root-servers.net [198.41.0.4]

トレースを完了しました。

----------------------------------------------------------------------------------------------

トレースがうまくいっていることが確認できました。

■宛先198.41.0.4の一つ前209.131.156.127がどこにあるか？

whois検索をして確認してみます。

tech-unlimited.com

f:id:TKCman:20181205171620p:plain

日本にa.root-servers.netあるのに、アメリカ行ってしまってるっぽい…です。

■Cloudのサーバをアメリカに作成する_1

f:id:TKCman:20181205162128p:plain

Pingはできるけど、tracertができない。。

azureuser@myVM:~$ ping 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=1.25 ms

64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=1.24 ms

64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=1.39 ms

--- 8.8.8.8 ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2002ms

rtt min/avg/max/mdev = 1.245/1.297/1.394/0.074 ms

azureuser@myVM:~$ tracepath 8.8.8.

gethostbyname2: Resolver Error 0 (no error)

azureuser@myVM:~$ tracepath 8.8.8.8

1?: [LOCALHOST] pmtu 1500

1: no reply

2: no reply

azureuser@myVM:~$

トレースコマンドがOS上になかったので、mtrコマンド使ってみました。

f:id:TKCman:20181206115713p:plain

f:id:TKCman:20181206115738p:plain

あきらめた、、次にAWSで試してみます。

■Cloudのサーバをアメリカに作成する_2

f:id:TKCman:20181205172054p:plain

■こちらのOSも、トレースコマンドがOS上になかったので

mtrコマンド使ってみました。

[ec2-user@ip-172-31-87-238 ~]$
[ec2-user@ip-172-31-87-238 ~]$
[ec2-user@ip-172-31-87-238 ~]$ mtr 198.41.0.4
[ec2-user@ip-172-31-87-238 ~]$

f:id:TKCman:20181205172232p:plain

■宛先198.41.0.4の一つ前217.30.85.127がどこにあるか？

同じくwhois検索してみると…

f:id:TKCman:20181205172814p:plain

以下のサイト（https://www.janog.gr.jp/meeting/janog34/doc/janog34-acast-matsuzaki-1.pdf）に書いてある内容からすると、クライアントから見ると、近くの198.41.0.4に行っているのかと思ったんですが違いました。

→日本の端末（パソコンなど）は、日本の198.41.0.4

→アメリカの端末（パソコンなど）は、アメリカの198.41.0.4

f:id:TKCman:20181205173103p:plain

https://www.janog.gr.jp/meeting/janog34/doc/janog34-acast-matsuzaki-1.pdf

頑張れIP anycastより

一応、IP anycastが地理的分散されているっぽいのは確認できました。

a.root-servers.netはVerisignが管理してるっぽいので近くの198.41.0.4に行くのとはちょっと違うのかな？

f:id:TKCman:20181206120150p:plain

ルートサーバ - Wikipediaより

2018-11-30

sparse-modeのSPT switchover～トラブルシュート～

Advent Calendar 2018 大國魂（ITブログ）の7日目です。

前回は、SPT switchoverの基本的な動作を確認してみました。

構成図は同じままで、１つだけ設定を変更してみます。

経路の途中にあるルートでip pim sparse-modeをとる…という設定です。

f:id:TKCman:20181130095408p:plain

前回の記事ではサラッと書いてしまいましたが、全部のルータのインターフェイスにip pim sparse-modeの設定が入っています。

R2とR3がつながっているインターフェイスのR2側だけip pim sparse-modeを削除してみます。senderからreceiverにいく(S,G) にツリーができる（pim joinがsenderまで送られる）(*,G)→(S,G) にツリーがかわるSPT switchoverがうまくいかないことが期待される動作です。

■R2からip pim sparse-modeの設定を削除しておきます。
R2#sho run int e 0/1
Building configuration...

Current configuration : 68 bytes
!
interface Ethernet0/1
ip address 192.168.23.2 255.255.255.0
end

■このときのこの時の共有ツリー（今回も225.1.1.1が使用するマルチキャストグループです。）
R4#sho ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 225.1.1.1), 10:00:42/00:02:26, RP 100.0.0.2, flags: SJCL
Incoming interface: Ethernet0/0, RPF nbr 192.168.34.3
Outgoing interface list:
Loopback0, Forward/Sparse, 10:00:42/00:02:26

(*, 224.0.1.40), 10:05:50/00:02:18, RP 100.0.0.2, flags: SJPCL
Incoming interface: Ethernet0/0, RPF nbr 192.168.34.3
Outgoing interface list: Null

R3#sho ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 225.1.1.1), 10:01:18/00:02:32, RP 100.0.0.2, flags: S
Incoming interface: Ethernet0/1, RPF nbr 192.168.23.2★R3からR2には行けないのにR2側を向いてしまっている！！
Outgoing interface list:
Ethernet0/2, Forward/Sparse, 10:01:18/00:02:32

(*, 224.0.1.40), 10:08:24/00:02:47, RP 100.0.0.2, flags: SJCL
Incoming interface: Ethernet0/1, RPF nbr 192.168.23.2
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 05:37:36/00:02:30
Ethernet0/2, Forward/Sparse, 10:06:26/00:03:07

R3#

前回は(*, 225.1.1.1)：共有ツリーや(192.168.25.5, 225.1.1.1)送信元ツリーだけ確認していましたが、今回は通るルートが重要です。

どのルートを通るかは、ツリーのRPF情報を確認します。（上記例だと192.168.23.2がRPF(Reverse Path Fowarding)）

現状をもう一度図にすると…

f:id:TKCman:20181130201649p:plain

となるはずです。（R3で(*, 225.1.1.1)のグループでRPFが192.168.23.2になっているからなりそう）。

■ここで、前回と同じくR5から
ping 225.1.1.1 repeat 100
します。

pingしても今回は失敗
R5#ping 225.1.1.1 repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 225.1.1.1, timeout is 2 seconds:
......................................................................
..............................
R5#

■R4とR3が共有ツリー(*,G)のまま（赤字の(*, 225.1.1.1)が共有ツリー）
R4#sho ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 225.1.1.1), 10:11:23/00:02:45, RP 100.0.0.2, flags: SJCL
Incoming interface: Ethernet0/0, RPF nbr 192.168.34.3
Outgoing interface list:
Loopback0, Forward/Sparse, 10:11:23/00:02:45

(*, 224.0.1.40), 10:16:31/00:02:37, RP 100.0.0.2, flags: SJPCL
Incoming interface: Ethernet0/0, RPF nbr 192.168.34.3
Outgoing interface list: Null

(*, 225.1.1.1), 00:07:49/00:02:36, RP 100.0.0.2, flags: S
Incoming interface: Ethernet0/1, RPF nbr 192.168.23.2
Outgoing interface list:
Ethernet0/2, Forward/Sparse, 00:07:49/00:02:36

(*, 224.0.1.40), 00:07:49/00:02:53, RP 100.0.0.2, flags: SJCL
Incoming interface: Ethernet0/1, RPF nbr 192.168.23.2
Outgoing interface list:
Ethernet0/2, Forward/Sparse, 00:07:15/00:03:05
Ethernet0/0, Forward/Sparse, 00:07:49/00:02:42

R2#

SPT switchoverが起きなかったことが確認できました。

◇　◇　◇

マルチキャストは前提として、IGPが動作している必要があります。

マルチキャストルーティングを行う前提として、ユニキャストルーティングが完成していることが必要なので注意してください。

マルチキャストルーティングの仕組みその3 (ネットワークのおべんきょしませんか？ Cisco CCNA/CCNP/CCIE、ネットワークスペシャリスト試験の勉強にピッタリ) より

IGPが通るルートにマルチキャストが一緒に通る…というイメージです。

IGPとマルチキャストが同じルートを通っていることは

・IGPはtraceroute

・マルチキャストはmtrace

それぞれのトレースルートコマンドで確認できます。

R4#
R4#trace
R4#traceroute 192.168.25.5
Type escape sequence to abort.
Tracing the route to 192.168.25.5
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.34.3 0 msec 1 msec 0 msec
2 192.168.23.2 0 msec 1 msec 0 msec
3 192.168.25.5 0 msec 0 msec *

R4#mtrace 192.168.25.5
Type escape sequence to abort.
Mtrace from 192.168.25.5 to 192.168.34.4 via RPF
From source (?) to destination (?)
Querying full reverse path...
0 192.168.34.4
-1 192.168.34.4 ==> 192.168.34.4 PIM [192.168.25.0/24]
-2 192.168.34.3 ==> 192.168.23.3 PIM [192.168.25.0/24]
-3 192.168.23.2 ==> 192.168.25.2 PIM_MT Multicast disabled [192.168.25.0/24]
R4#

今回の場合、解決方法は、R2とR3がつながっているインターフェイスのR2側にip pim sparse-modeが入っていないことを発見する以外に

IGPに向いてしまっているマルチキャストのルート（R3-R2）を
マルチキャストが通れる側のルート（R3-R1-R2）に変更する…という方法もあります。変更するコマンドがip mrouteコマンドです。

ip mroute 0.0.0.0 0.0.0.0 192.168.13.1

また、図にすると…

今度は、R3-R1-R2を通るルートで送信元ツリーができるはずです。

f:id:TKCman:20181203093633p:plain

■R3に設定を入れてみます。

R3(config)#ip mroute
R3(config)#ip mroute 0.0.0.0 0.0.0.0 192.168.13.1
R3(config)#
R3(config)#end
R3#
R3#sho ip
*Nov 22 17:34:32.301: %SYS-5-CONFIG_I: Configured from console by console
R3#sho ip mroute
R3#sho ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 225.1.1.1), 02:25:40/00:03:20, RP 100.0.0.2, flags: S
Incoming interface: Ethernet0/0, RPF nbr 192.168.13.1, Mroute★ルートがR1側を向いた。
Outgoing interface list:
Ethernet0/2, Forward/Sparse, 02:25:40/00:03:20

(*, 224.0.1.40), 02:26:25/00:02:49, RP 100.0.0.2, flags: SJCL
Incoming interface: Ethernet0/0, RPF nbr 192.168.13.1, Mroute
Outgoing interface list:
Ethernet0/2, Forward/Sparse, 02:26:17/00:02:49

■この状態でpingをうつと成功します。
※R4で227.1.1.1の別のマルチキャストのグループを登録していますが
初期化的な意味あいで行っています。
そのまま、225.1.1.1だとclear ip mroute *を複数ルータで行って
さらに、225.1.1.1で共有ツリーが再度作成されるまで時間がかかるので
227.1.1.1を追加で同じ動作を行っています。

R4(config)#int lo 0
R4(config-if)#ip gim
R4(config-if)#ip igm
R4(config-if)#ip igmp jo
R4(config-if)#ip igmp join-group 227.1.1.1
R4(config-if)#
R4(config-if)#end
R4#

R5#ping 227.1.1.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 227.1.1.1, timeout is 2 seconds:

Reply to request 0 from 100.0.0.4, 22 ms
R5#ping 227.1.1.1 re
R5#ping 227.1.1.1 repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 227.1.1.1, timeout is 2 seconds:

Reply to request 0 from 100.0.0.4, 1 ms
Reply to request 1 from 100.0.0.4, 1 ms
Reply to request 2 from 100.0.0.4, 1 ms

R4#
*Nov 22 17:48:01.715: %SYS-5-CONFIG_I: Configured from console by console
R4#

R4#
R4#sho ip mroute
R4#sho ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 227.1.1.1), 00:01:17/stopped, RP 100.0.0.2, flags: SJCL
Incoming interface: Ethernet0/0, RPF nbr 192.168.34.3
Outgoing interface list:
Loopback0, Forward/Sparse, 00:01:17/00:02:26

(192.168.25.5, 227.1.1.1), 00:00:38/00:02:21, flags: LJT
Incoming interface: Ethernet0/0, RPF nbr 192.168.34.3
Outgoing interface list:
Loopback0, Forward/Sparse, 00:00:38/00:02:26

(*, 225.1.1.1), 13:42:40/00:02:26, RP 100.0.0.2, flags: SJCL
Incoming interface: Ethernet0/0, RPF nbr 192.168.34.3
Outgoing interface list:
Loopback0, Forward/Sparse, 13:42:40/00:02:26

(*, 224.0.1.40), 13:47:48/00:02:17, RP 100.0.0.2, flags: SJPCL
Incoming interface: Ethernet0/0, RPF nbr 192.168.34.3
Outgoing interface list: Null

SPTスイッチオーバーが起きて(192.168.25.5, 227.1.1.1)の送信元ツリーができました。

■マルチキャストはIGPでルートを学習しているルートを通るのですが
RPFがおかしいと正しく動作しないことが確認できました。

マルチキャストがおかしくなり始めるルータのR3にとっては、IGPが通るルートは、R2側なのに（R2が最短ルート）マルチキャストは、R1側を向くなんておかしい！となっていると言えます。そこをip mrouteコマンドで無理やりR1側に向かせるとうまくいくというのが面白いですね。

■マルチキャストは、すべてのルータでip pim sparse-modeが入っているのがいい設計といえるみたいです。

■その他（ip mrouteコマンドの使い方）

----------
▼tunnel
→マルチキャスト受信しているのが、tunnel0
しかし、RPFはE0/0

▼NBMA
→マルチキャストは受信インターフェースを送信にできない。
→ip pim nbma-modeで回避

-------------

これら状態のときもIGPが通るルートにマルチキャストがうまくのっていない状態になってしまうため、ip mrouteコマンドが必要になることが

「詳解IPマルチキャスト概念からCisco製品での設定例まで (NETWORK 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

に載っています。

今回の機器のコンフィグは以下にあります。

github.com

平成29年 午後1 問3 設問3(4)