大國魂(ITブログ)の17日目です。ネットワークスペシャリストの試験を5年ぐらい受験しているのですが、なかなか受かりませんが、過去問を結構勉強して知見がたまってきたので、公開したいと思います。設問3(4)めちゃくちゃピンポイントですが、この問題を取り上げてみます。以下(4)の問題分だけ引用してみます。本文中の下線5について、経路のループを防止するために必要な経路制御を40字以内で述べよ。下線5前後の文章は以下I主任:そうですね。いえば一点注意が必要です。経路情報の再配布を行うときは、経路のループを防止しなければいけませんOさん:わかりました。5経路のループを防止する経路制御を行います。再配布されるときの状態としては以下画像のような感じです。R2とR3が同じASで、R4とR5が同じASです。下図だとちょっとわかりずらいので、念のため。3と6が再配布している場所です。6の再配布をしてしまうことで問題がおきてしまうというのがIPAの回答でした。IPAの回答eBGPからOSPFへ再配布された経路を再びeBGPへ再配布しないというものです。ループが実際におきるところはR7のところです。R7がR8から受け取ったサーバの経路情報(7.7.7.7)とR5から再配布で戻ってきたサーバの経路情報(7.7.7.7)を比べて、R5のほうが勝ってしまいます。深く考えないでいるとR8からきたルートのほうが強いんじゃないかと思ってしまいますが、OSPF→BGPに再配布された入ってきたルート(最初の図の6)のメトリックが、R8からきたルートのメトリックより高いことがあるというのがポイントだと思います。(たぶん高くなると思います。すいません、たぶんで。R5のルートのほうがメトリック高くないとループがおきない→つまり、問題の条件が起きえない。)R5とR8で動いているのがどんなIGP(ripv2、EIGRP、OSPF)でも起こりえるようなループなのではないかと思われます。そのため、下図のようなループがおきます。12以降は、R1、R2、R4、R7、R5、R3のルータでループし続けます。(TTLがなくなるまで)IPAの回答を実際の機器設定まで落とし込めるか?OSPFからBGPに再配布してきたルートのメトリック設定する方法をちゃんと探してみました。上のほうで、たぶんと言ってしまいましたが、以下設定とかがありそうな設定かと思います。ネイバーにアドバタイズされます。このシナリオでは、次のネットワーク構成を使用しています。両方が実行されています。なっていることに気付きます。出力結果は、次のとおりです。値に基づいてネットワークがアドバタイズされています。値がアドバタイズされます。これは、次の出力結果で確認できます。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の回答のもとになった設定かもしれないです。挿入されたルートのメトリックが...とcisco公式サイトに書いてあるので、netwrokコマンドか再配布(redistribute)かは気にしなくてもいいのかもしれないです。(以下の引用参照して下さい。0.0.0.0https://docs.aws.amazon.com/ja_jp/vpc/latest/adminguide/Cisco.htmlazureとかのbgp接続もnetworkコマンドで設定しているので、問題作成した人はどのようにこの問題を作ったかが気になります。100https://qiita.com/yotan/items/367be1a8390713306b5e過去問のBGPの設定がわかりそうな図は下図です。◇ネットワークスペシャリストの試験でルーティングの問題は、ちょっと珍しい気がするのでとりあげてみました。この問題は、色々そぎ落としすぎてよくわからない感じになってしまっている気がしますが、、ネットワークスペシャリストの試験のIPsecの問題とかはすごく勉強になるので、勉強してみるのもいいかもしれません。06:49ネットワークスペシャリスト試験過去問Tweetもっと読むコメントを書く2019-06-21パケットの遅延とか損失の話Uber、モバイルアプリの通信をHTTP/2からQUICに変更して表示速度改善。TCPとUDPの違いによるQUICのメリットは大きい。2019のニュース中身読んでみたeng.ubeQUICの話まで理解できなかったけど、パケットの遅延とかRTTが気になってしまった。ワイヤレス上のTCPパフォーマンスTCPはもともと有線ネットワーク用に設計されていました。有線ネットワークには、予測可能なリンクがあります。ワイヤレスネットワークには独自の特性と課題があります。第1に、無線ネットワークは干渉および信号減衰による損失を受けやすい。WiFiネットワークは、マイクロ波、ブルートゥース、およびその他の種類の電波からの干渉を受けやすいです。セルラネットワークは、建物などの環境内のものによる反射/吸収、および近隣の基地局からの干渉による信号損失(または経路損失)の影響を受ける。これらの結果、有線のものよりもはるかに長く(例:4~10倍)可変ラウンドトリップタイム(RTT)およびパケット損失が発生します。携帯とかは有線の4~10倍のラウンドトリップタイム(RTT)パケット損失らしい。RTTについては、説明省略(https://jehupc.exblog.jp/15349359/の図がわかりやすかった。)さらに高いRTT値と、中央値のほぼ6倍のテールエンド値があり、平均分散は1秒を超えています。ほとんどの接続は損失が多く、TCPは総パケット数の3.5%を再送していました。駅や空港などの混雑した場所では、ネットワークによってパケットが廃棄されるのは最大7%でした。これらの結果は、セルラーネットワークの高度な再送信方式がトランスポート層での損失を大幅に減らすという共通の概念に挑戦しています。以下に、モックアプリケーションでテストを実行した結果の概要を示します。7%÷10=0.7%パケット損失(有線の損失率が1%前後ってことらしい。)前雑誌の付録でついていたRTTはスゴイ小さい値だったけど理想の値ってこと?普通にPINGしてみたら、30ミリ秒ぐらいだった。28msニュースの中のリンクで面白いのがあって*1なぜオーバーバッファリングが問題なのかバッファが大きすぎると、いっぱいになり遅延が発生し、インターネットの多くの用途が破壊されます。株式トレーダーやゲーマーは、競合相手に1msの優位性さえも持たせたくありません。音楽を再生するには、ジッタ(遅延の変動)とレイテンシを制御し、100ミリ秒未満に保つ必要があります。何かを手に「感じる」ようにするために(完璧なラバーバンディング)、レイテンシは30ミリ秒の範囲を下回る必要があります。IP)が光速度による遅延を支配しているため、エンドツーエンドの遅延を150ミリ秒(長距離電話のメトリック)未満に抑えるには、アクセスの遅延が重要になります。System)検索に失敗する可能性があります。ARP、DHCP、RA、NDなどの重要なネットワークプロトコルはすべてタイムリーな応答を想定しており、それなしでは失敗する可能あります。遅延は数百ミリ秒から数秒に及ぶため、Webブラウジングは困難になります。遅延の許容の話が書いてあった。回線が遅いなと思ったときの判断の基準にできるかもしれない。なかったので、まとめてみます。DMVPNのインターフェースを色々設定しても意味ないです。NHRPについて上の2.NHRPについて考えます。networksつまり、NHRPは、NBMAネットワークの環境でつかう技術ということ。)の3種類のうちのひとつ。キャスト機能のないネットワークです。手動で設定する必要があります。正確に言うとNBMAモードの種類により自動接続されるモードもあります。https://www.infraexpert.com/study/ospfz8.htmlよりNBMAは、ブロードキャストっぽいけど、ブロードキャストしてくれないインターフェス。変更する必要があります。tunnelをphaseごとに設定を変える<例>point-to-pointからbroadcastに変更する最後の赤字のところが今回考えるところです。OSPFでは、Spokeをpoint-to-pointに設定する。EIGRPは、スプリットホライズンを止める。インターフェースで折り返しの通信ができるようになる。必要なし解説Phase2は、通信がHUBを経由せず、SPOKEが直接SPOKEどうしで通信する。OSPFでは、SpokeをbroadcastにすることでSPOKEどうしの通信を実現する。SPOKEどうしの通信を実現する。よると、以下コマンドで削除のflannel削除の必要あり。cni0うまくいきました。bootcampできました。実はダッシュボードの設定とかうまくいってないので、もうちょっと頑張ります。11:53Kubernetesでpodが起動しない_controllerがおかしいTweetもっと読むコメントを書く2019-04-05Kubernetesでpodが起動しない_CrashLoopBackOffもう少しで完成しそうなのにうまくいかないccie-go.comこのURLを参考にKubernetes自宅に作っていました。(このサイトなかったらkubernetesやろうと思わなかったです。ありがとうございます。~]#でbootcampが動いているnodeのflannelの動作がおかしい...というところまでは突き止めました。~]#CrashLoopBackOffというのが起きている。対応するflannelの名前を確認。nodesでどのノードと紐づいているか確認。nodesのnode2に対するエラーの内容を見てもよくわからなかったです。検索して出てきた結果flannelまわりがおかしいっぽいのはわかるのですが、不明。node2だけ、NICのインターフェースがens192になってしまっていた。forevernode2で負荷高いのが原因か!とか思って再起動とかしてしまっていてNICの名前が変わってしまったみたいです。(下図の192.168.52.82でCPUが49%になっているところ。49%でビビッて再起動してしまった。)nmtuiでNICの名前をens192からもとのens160に書き換え別の名前とIPでNICが上がってきてしまったため、断念。やってみたのですが、うまくens160にならなかったです。