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

 

 

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

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

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のインターフェースの位置づけ

  1. 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どうしの通信を実現する。

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

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

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） 続きます。

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

^C

--- 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

^C

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より

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


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), 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

sparse-modeのSPT switchover～基本動作～

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

マルチキャストのsparse-modeが途中でツリーが切り替わる動作確認をしてみました。

SPT switchoverというそうです。

今回は普通にSPT switchoverが起きている状態を確認し、次にトラブルシュート的な内容にしたいと思います。

 

■構成図

f:id:TKCman:20181129200153p:plain

R5がサーバっぽく見えますがルータです。（アイコン変えてるだけ）

R2をランデブーポイント（以下、RP）としています。

 

▼マルチキャストのトラフィック配信もとのサーバ（以下、sender）から
まず、RPへの送信元ツリーが作成されます。

senderからRP
sender -- > RP
(S,G)
→送信元ツリー

f:id:TKCman:20181129200554p:plain

▼同じタイミングでもそれより前でもいいのですが、multicast_R4の下にPCがぶら下がっている
状態があり、multicast_R4のようなルータをラストホップルータ（LHR）やreceiverなど
といったりします。（以下、receiver）
流れてくるトラフックの向きは、RP -- > recieverですが

共有ツリーが作成されるときはrecieverがigmp joinメッセージをRPに向けて送信し、共有ツリーが作成されます。

receiverからRPに向けて、共有ツリーというツリーが作成されます。
receiverからRP
reciever -- > RP
(*,G)
→共有ツリー

f:id:TKCman:20181129200740p:plain

▼最終的にsenderからreceiverにいく(S,G) にツリーができる（pim joinがsenderまで送られる）(*,G)→(S,G) にツリーがかわります。SPT switchoverという。
共有ツリーが送信元ツリーに変わるのが、switchoverなのだと思います。

 

f:id:TKCman:20181129201832p:plain

 

◇　◇　◇

 

ここから設定投入を開始。

（全部のルータのconfigは、トラブルシュートが終わった最後にどこかにおいておきます。IGP（OSPF）が動いていて、すべてのインターフェイスにip pim sparse-modeの設定が入っている…のが前提）

 

■R4をreciever（レシーバー）にする。
適当なマルチキャストのグループをR4のlo0に設定します。
（lo0にマルチキャストのトラフィックを受信するPCが接続されているイメージ）
igmp-joinの225.1.1.1がマルチキャストのグループ

interface Loopback0
ip address 100.0.0.4 255.255.255.255
ip pim sparse-mode
ip igmp join-group 225.1.1.1
end

■ここで、R5から
ping 225.1.1.1 repeat 100
します。（pingがマルチキャストのトラフィックを流している状態を再現）

（S,G）
RP -- > sender
→送信元ツリー

ができて、そのあと


（S,G）
RP -- > sender
→送信元ツリー

 

R5はまだ何もない状態

R5#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

(*, 224.0.1.40), 00:19:38/00:02:46, RP 100.0.0.2, flags: SJPCL
Incoming interface: Ethernet0/0, RPF nbr 192.168.25.2
Outgoing interface list: Null


pingが成功すると

R5#ping 225.1.1.1 re
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:

Reply to request 0 from 100.0.0.4, 21 ms
Reply to request 1 from 100.0.0.4, 1 ms
Reply to request 2 from 100.0.0.4, 1 ms
Reply to request 3 from 100.0.0.4, 1 ms
R5#


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), 00:13:04/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:13:04/00:02:05

(192.168.25.5, 225.1.1.1), 00:00:19/00:02:40, flags: LJT
Incoming interface: Ethernet0/0, RPF nbr 192.168.34.3
Outgoing interface list:
Loopback0, Forward/Sparse, 00:00:19/00:02:40

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

R4#

先ほどまでR4になかった、(S,G)のツリー（赤字の(192.168.25.5, 225.1.1.1)）ができていることが確認できます。

 

R5はpingをうってからしばらくすると
mrouteから(S,G)：(192.168.25.5, 225.1.1.1)が消えます。

pingした直後は、(192.168.25.5, 225.1.1.1)があるけど

R5#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), 00:03:26/stopped, RP 100.0.0.2, flags: SPF
Incoming interface: Ethernet0/0, RPF nbr 192.168.25.2
Outgoing interface list: Null

(192.168.25.5, 225.1.1.1), 00:03:26/00:00:06, flags: PFT
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0, Registering
Outgoing interface list: Null

(*, 224.0.1.40), 00:30:37/00:02:44, RP 100.0.0.2, flags: SJPCL
Incoming interface: Ethernet0/0, RPF nbr 192.168.25.2
Outgoing interface list: Null

 

しばらくすると(192.168.25.5, 225.1.1.1)がなくなる。

R5#
R5#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), 00:03:45/00:02:47, RP 100.0.0.2, flags: SP
Incoming interface: Ethernet0/0, RPF nbr 192.168.25.2
Outgoing interface list: Null

(*, 224.0.1.40), 00:30:56/00:02:25, RP 100.0.0.2, flags: SJPCL
Incoming interface: Ethernet0/0, RPF nbr 192.168.25.2
Outgoing interface list: Null

R5#

 

トラブルシュートに続く