UARTのピンアサイン確認方法

◽️

The IoT Hacker's Handbook: A Practical Guide to Hacking the Internet of Things

Aditya Gupta Walnut, CA, USA

ISBN-13 (pbk): 978-1-4842-4299-5

https://doi.org/10.1007/978-1-4842-4300-8

Copyright © 2019 by Aditya Gupta

ISBN-13 (electronic): 978-1-4842-4300-8

という本だと、起動時に電圧が上がってすぐさがれば、Txピン

———————-

デバイスを再起動し、残りのパッドとGNDの間の電圧を測定します。 起動時の最初の大量のデータ転送により、最初の10〜15秒の間に電圧値の大きな変動に気付くでしょう。 このピンはTxピンになります。

———————-

◽️YouTubeで同じようなことしている動画も確認

https://youtu.be/6_Q663YkyXE

UARTを直接測ったときの抵抗値があり(Rgrnが30kΩ)、UART直接ではなくて上流の電源(Vcc)側から測って抵抗がない(Rvccが0Ω)になるのがVcc(電源)らしい。(下のYouTube のキャプチャの表一行目の話をしてます)

UARTで直接測ってるときの様子

赤い線を計測したいピンにつける

黒のグランド用の線はボードのどこかシールドになってるところに接続

上流の電源(Vcc)側から測ってるときの様子

赤い線をVcc、黒い線を計測したいピンにつける

YouTube の人は、電源(Vcc)とグランド(grn)をまず見つけるっていうのをやってるみたい。そのあと、Tx/Rxを見つける作業する。確かにまず電源見つけないと危ないからかな。

Vcc見つかった

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

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

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

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

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

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

下線⑤前後の文章は以下

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

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

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

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

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

IPAの回答

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

というものです。

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

R7のところです。

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

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

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

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

⑫以降は、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の設定がわかりそうな図は下図です。

◇　◇　◇

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

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

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

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はスゴイ小さい値だったけど理想の値ってこと？

普通に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できました。

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

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％でビビッて再起動してしまった。）

nmtuiでNICの名前をens192からもとのens160に書き換え

別の名前と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であることが確認できます。

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

確かに、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

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

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

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コマンド使ってみました。

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

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

■こちらの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 ~]$

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

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

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

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

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

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に行くのとはちょっと違うのかな？

ルートサーバ - Wikipediaより