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で同じようなことしている動画も確認
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
のニュース中身読んでみた
QUICの話まで理解できなかったけど、パケットの遅延とかRTTが気になってしまった。
ワイヤレス上のTCPパフォーマンス
TCPはもともと有線ネットワーク用に設計されていました。
有線ネットワークには、予測可能なリンクがあります。
ただし、ワイヤレスネットワークには独自の特性と課題があります。
第1に、無線ネットワークは干渉および信号減衰による損失を受けやすい。
たとえば、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=51183.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%前後
回線が遅いなと思ったときの判断の基準にできるかもしれない。
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どうしの通信を実現する。
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 28mnodelb 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 nodelbspeaker-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
もう少しで完成しそうなのにうまくいかない
この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 7d21hnode2 [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検索をして確認してみます。
日本に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に行くのとはちょっと違うのかな?