叙情的な紹介

管理者が予期しない問題（以前は動作していたが、更新後に突然停止した）に遭遇した場合、戦闘または飛行という2つの可能な動作アルゴリズムがあります。 つまり、問題を最後まで理解するか、その本質を掘り下げることなく問題から脱出するかのいずれかです。 ソフトウェア更新のコンテキストでは、ロールバックします。



アップグレードが失敗した後にロールバックする-これは悲しいベストプラクティスと言えます。 ロールバックの準備方法、ロールバックの実行方法、およびロールバックに失敗した場合の対処方法に関するマニュアル全体があります。 industry病な行動の業界全体。



別の方法は、最後を理解することです。 これは誰も成功を約束しない非常に難しい方法であり、費やされる労力の量は結果と比較できず、出力は何が起こったのかを少しだけ理解するだけです。

ドラマのプロット

Webzillのインスタントサーバークラウド。 nova-computeホストの定期的な更新。 新しいライブイメージ（PXEローディングを使用）、フルフィルメントシェフ。 すべて順調です。 突然、クライアントからの苦情：「仮想マシンの1つが奇妙に動作し、動作しているように見えますが、実際の負荷が始まると、すべてがフリーズします。」 クライアントインスタンスを別のノードに転送すると、クライアントの問題は解決します。 問題が始まります。 このノートでインスタンスを起動します。 写真：Cirrosでのsshログインが成功し、Ubuntuではフリーズしました。 ssh -vは、すべてが「debug1：SSH2_MSG_KEXINIT sent」ステージで停止することを示します。



すべての可能な外部デバッグ方法が機能します-メタデータが取得され、DHCPリースがインスタンスによって更新されます。 インスタンスがMTUでDHCPオプションを受信しないという疑いがあります。 Tcpdumpは、オプションが送信されていることを示しますが、インスタンスがそれを受け入れるかどうかは不明です。



本当にインスタンスに到達したいのですが、取得できるCirrosではMTUが正しく、UbuntuではMTU問題について疑念があるため、取得できません。 しかし、本当にしたい。



これがMTUの問題である場合、突然のヘルパーがいます。 これはIPv6です。 「白い」IPv6を割り当てないという事実にもかかわらず（申し訳ありませんが、openstackではまだ実稼働に対応していません）、リンクローカルIPv6は機能します。



2つのコンソールを開きます。 ネットワークノードごとに1つ。 ネットワーク名前空間に侵入します。

 sudo stdbuf -o0 -e0 ip net exec qrouter-271cf1ec-7f94-4d0a-b4cd-048ab80b53dc / bin / bash

（stdbufを使用すると、ip netのバッファリングを無効にすることができます。これにより、画面の出力がリアルタイムで表示され、遅延は発生しません。ipnet execは、指定されたネットワーク名前空間でコードを実行します。bashはシェルを提供します）。



2番目のコンソールで、compute-nodeを開いて、tcpdumpをubuntuのタップにtcpdump -ni tap87fd85b5-65



ます： tcpdump -ni tap87fd85b5-65







内部名前空間から、すべてのノードのリンクローカルマルチキャストを要求します（この記事はipv6に関するものではありませんが、何が起こっているかの本質です：各ノードには、FE80 ::で始まるipv6アドレスが自動的に生成され、さらに、各ノードはマルチキャストアドレスをリッスンして応答しますノードの役割に応じて、マルチキャストのリストは異なりますが、各ノードは少なくとも、すべてのノード、つまりアドレスFF02 :: 1）に応答します。 そのため、マルチキャストpingを実行します。

 ping6 -I qr-bda2b276-72 ff02 :: 1
 PING ff02 :: 1（ff02 :: 1）from fe80 :: f816：3eff：fe0a：c6a8 qr-bda2b276-72：56データバイト
 fe80から64バイト:: f816：3eff：fe0a：c6a8：icmp_seq = 1 ttl = 64 time = 0.040 ms
 fe80から64バイト:: f816：3eff：fe10：35e7：icmp_seq = 1 ttl = 64 time = 0.923 ms（DUP！）
 fe80から64バイト:: f816：3eff：fe4a：8bca：icmp_seq = 1 ttl = 64 time = 1.23 ms（DUP！）
 fe80から64バイト:: 54e3：5eff：fe87：8637：icmp_seq = 1 ttl = 64 time = 1.29 ms（DUP！）
 fe80から64バイト:: f816：3eff：feec：3eb：icmp_seq = 1 ttl = 255 time = 1.43 ms（DUP！）
 fe80から64バイト:: f816：3eff：fe42：8927：icmp_seq = 1 ttl = 64 time = 1.90 ms（DUP！）
 fe80から64バイト:: f816：3eff：fe62：e6b9：icmp_seq = 1 ttl = 64 time = 2.01 ms（DUP！）
 fe80から64バイト:: f816：3eff：fe4d：53af：icmp_seq = 1 ttl = 64 time = 3.66 ms（DUP！）

疑問が生じます-誰が誰ですか？ 順番に、入力しようとすると、不便で長いです。



次のウィンドウの横にあるtcpdumpは、関心のあるインスタンスのインターフェイスをリッスンしています。 そして、その中に、私たちが興味を持っているIPである1つのIPからの答えがあります。 これはfe80 :: f816：3eff：feec：3ebであることが判明しました。



次に、sshを介してこのノードに接続します。 しかし、 ssh fe80::f816:3eff:feec:3eb



を試してみた人は誰でも驚きます-「無効な引数」。



その理由は、リンクローカルアドレスは「そのように」使用することはできず、リンク（インターフェイス）内でのみ意味があるためです。 ただし、sshには「このような発信IP /インターフェイスなどを使用する」オプションはありません。 幸いなことに、IPアドレスにインターフェイス名を指定するオプションがあります。



ssh fe80::f816:3eff:feec:3eb% qr-bda2b276-72



を実行します。 はい、はい、私はあなたのinりと当惑を理解しています（あなたがそれを持っていない場合-あなたは本当のオタクではないか、IPv6で長年仕事をしています）。 「Fe80 :: f816：3eff：feec：3eb％qr-bda2b276-72」はそのような「IPアドレス」です。 これらの引用符で皮肉の程度を伝えるのに十分な言語がありません。 パーセントおよびインターフェース名を含むIPアドレス。 誰かがhttp：// [fe80 :: f816：3eff：feec：3eb％eth1] /secret.fileのようなものをWebサーバーロケールのサーバーからいくつかのWebサイトにアップロードするとどうなるかは興味深い...



...そして、私たちは仮想マシン上にいます。 なんで？ 必須のPMTUDのおかげで、IPv6はIPv4よりも悪いMTU状況を処理するのに優れているためです。 したがって、仮想マシン上にいます。



間違ったMTU値が表示され、cloud-initログにアクセスして、その理由を突き止めることを期待しています。 しかし、ここに驚きがあります-MTUは正しいです。 おっと

デバッグの荒野で

突然、ローカルで理解可能な問題が完全に理解不能になります。 MTUは正しいが、パケットはドロップしている... ...慎重に考えれば、問題は最初からそれほど単純ではなかった-インスタンスの移行によってMTUが変更されるべきではなかった。



苦しいデバッグが始まります。 tcpdump、ping、および2つのインスタンス（およびネットワークノードのネットワーク名前空間）を使用して、次のことがわかります。

• ローカルでは、同じ上の2つのインスタンスが、最大サイズのpingで相互にpingを計算します。
• ネットワークノードからのインスタンスが応答しません（以降-最大サイズのpingで）
• 他のコンピューターのネットワークノードインスタンスping。
• インスタンス内のtcpdumpに細心の注意を払うと、ネットワークノードがインスタンスにpingを送信すると、pingが表示されて応答することがわかります。

おっと 大きな荷物が到着しますが、帰りに迷子になります。 非対称ルーティングと言いますが、隣接するスイッチポートにある場合のルーティングは何ですか？



回答に細心の注意を払ってください。回答はインスタンスに表示されます。 答えはタップで表示されます。 しかし、答えはネットワーク名前空間では見えません。 そして、ネットワークノードとコンピューターの間のmtuとパケットの状況はどうですか？ （内部的には、私はすでに勝利を収めている、と彼らは言う、私は問題を見つけた）。 Rraz-および（大）pingが実行されます。



なに？ （そして長い間困惑した休止）。



次に何をすべきかは明らかではありません。 元の問題に戻ります。 MTUは悪いです。 どのMTUが良いですか？ 実験を開始します。 分割：前の値からマイナス14バイト。 マイナス14バイト。 一体どうして？ ソフトウェアのアップグレード後？ 私はvimdiffをパッケージのリストにしました。カーネル、ovs、libcなどを含む約80個の更新されたパッケージを扱う見込みがあると思います。 そのため、退却するには2つの方法があります。MTUを14バイト下げるか、更新をロールバックして震えます。



クライアントが監視ではなく問題を報告したことを思い出させてください。 MTUはクライアント設定であるため、「DFフラグで大きなパケットを渡さない」ことは、完全なインフラストラクチャの問題ではありません。 それはインフラストラクチャの問題ではありません。 つまり、アップグレードが原因ではなく、次の日食と昨日の雨が原因である場合、誰かが苦情を申し立てるまで、問題が戻ってくることすらわかりません。 更新について震え、未知のものを恐れます。これは事前にはわかりませんか？ ありがとう、プロとしての人生を夢見てきた見通し。 そして、MTUを下げても、なぜ14バイトなのでしょうか？ 明日が20だったらどうなりますか？ または、石油の価格が45に下がりますか？ それと一緒に暮らすには？



ただし、確認します。 実際、MTUはDHCPオプションでわずかに低く、再起動したインスタンスは正常に機能します。 しかし、これはオプションではありません。 どうして？



最初からやり直します。 古いMTUであるtcpdumpトレースパッケージを再度返します。答えは、インスタンスのインターフェイス、tap'eに表示されます...ノードのネットワークインターフェイスでtcpdumpを確認します。 たくさんの小さな迷惑な洪水ですが、grepを使用すると、リクエストが（GRE内で）発生することがわかりますが、答えは戻りません。



うん！



少なくとも、プロセスのどこかで失われていることがわかります。 しかし、どこに？ 動作をライブノードと比較することにしました。 しかし問題は、「ライブ」ノードでtcpdumpがパッケージを表示することです。 数千人。 ミリ秒で。 tengigabitethernet時代へようこそ。 Grepを使用すると、この洪水から何かをキャッチできますが、通常のダンプを取得することはできなくなり、この設計のパフォーマンスには疑問が生じます。



私達は問題に焦点を合わせます：tcpdumpを使用してトラフィックをフィルタリングする方法がわかりません。 送信元、宛先、ポート、プロトなどでフィルタリングする方法は知っていますが、GRE内でIPアドレスでパケットをフィルタリングする方法はわかりません。 さらに、グーグルはそれを非常によく知らない。



ある時点まで、私はこの問題を無視しました。修理がより重要であると信じていましたが、知識の不足が非常に痛々しく噛み始めました。 同僚（私が質問に答えたkevitが対処しました。リンクtcpdump -i eth1 'proto gre and ( ip[58:4] = 0x0a050505 or ip[62:4] = 0x0a050505 )'



。



うわー 私のwebdwanolクラウドの特異点におけるハードコア0xhex。 じゃあ あなたは生きることができます。



残念ながら、ルールは正しく機能しなかったか、正しく機能しませんでした。 ブルートフォース法を使用してアイデアをつかみ、必要なオフセットを取得しました：送信元および宛先IPアドレスの54および58。 ケビットは、彼がオフセットを得た場所を示しましたが、それは非常に説得力がありました。 IPヘッダー、GRE、IPヘッダー。



重要な成果：数ギガバイトの洪水で単一のパケットを正確に見るためのツールを得ました。 パッケージを見る...とにかく、何も明確ではありません。



Tcpdumpは私たちの友人ですが、wiresharkの方が便利です。 （私はtsharkについて知っていますが、それも不便です）。 パケットダンプを実行し（tcpdump -w dump、実行可能になりました）、マシンにドラッグして整理し始めます。 私は（一般的な腐食性から）バイアスに対処することに決めました。 Wiresharkで開いて、参照してください...







ヘッダーのサイズを調べて、IPパケットの先頭の正しいオフセットが46ではなく42であることを確認します。このエラーを誰かの不注意に書き留めて、翌日、それを把握し続けることに決め、帰宅しました。



すでに家の近くのどこかで、それが私に現れました。 ヘッダーの構造に関する最初の仮定が正しくない場合、これはトンネリング時のGREからのオーバーヘッドが異なることを意味します。



イーサネットヘッダー、VLAN、IPヘッダー、GREヘッダー、カプセル化されたIPパケット...



やめて しかし、写真の見出しはまったく異なります。 neutronのGREはIPパケットをカプセル化しませんが、イーサネットフレームをカプセル化します。 言い換えれば、MTU GREのどの部分がそれ自体を食べるかについての最初の仮定は間違っています。 GREは、予想よりも14バイト多く「受け取り」ます。



neutronは、GREを使用してIP経由でオーバーレイネットワークを構築します。これはL2ネットワークです。 もちろん、カプセル化されたイーサネットヘッダーが必要です。



つまり、MTUは14バイト少なくする必要があります。 最初から。 ネットワークを計画したとき、GREによるMTUの削減についての仮定が間違っていました。 パケットの断片化を引き起こすため、かなり深刻です。



さて、エラーは明らかです。 しかし、更新後に機能しなくなったのはなぜですか？ 以前の研究によると、問題はMTU、GREヘッダーの誤ったカウント、GREパケットのフラグメンテーションに関連していることが明らかになりました。 断片化されたパケットの通過が停止したのはなぜですか？



慎重かつ綿密なtcpdumpで答えが示されました。GREはDNF（断片化しない）フラグとともに送信され始めました。 フラグは、内部にDNFフラグを含むIPパケットをカプセル化したGREパケットにのみ表示されました。つまり、フラグはペイロードからGREにコピーされました。



確かに、私は古いノードを見ました-それらはGREを断片化しました。 メインパケットと、14バイトのペイロードを持つテールがありました。 これは失敗です...



アップグレード後に開始された理由を調べることは残っています。

ドキュメントを読む

最も疑わしい回帰パッケージはLinuxとOpenvswitchでした。 Readme / changelog / newsは特別なことを明確にしませんでしたが、gitインスペクション（答えはここにあります。なぜドキュメントにアクセスするためにオープンソースコードが必要なのか）は非常に興味深いことを明らかにしました。

コミットbf82d5560e38403b8b33a1a846b2fbf4ab891af8
作成者：Pravin B Shelar <pshelar@nicira.com>
日付：月10月13日02:02:44 2014 -0700

    データパス：compat：コンパイル3.11を修正
    
    カーネル3.11はGRE APIが利用可能なカーネルのみですが、
     vxlanではありません。 このケースを検出するには、vxlan xmitのチェックを追加します。

パッチ自体は興味深いものを表しておらず、問題の本質には適用されませんが、ヒントを提供します：カーネルのGRE API。 そして、3.8から3.13へのアップグレードが行われました。 Google in bing ...カーネルのgit.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=aa310701e787087dbfbccf1409982a96e16c57a6のopenvswitch（データパスモジュール）にパッチがあります。 つまり、カーネルがGREサービスの提供を開始すると、openvswitchカーネルモジュールはgre処理をip_greカーネルモジュールに渡します。 私たちはip_gre.cコードを研究しています。その中のコメントに感謝します。はい、私たちは皆、tsiskaを「愛しています」。



切望されたラインはここにあります：

 static int ipgre_fill_info(struct sk_buff *skb, const struct net_device *dev) { struct ip_tunnel *t = netdev_priv(dev); struct ip_tunnel_parm *p = &t->parms; if (nla_put_u32(skb, IFLA_GRE_LINK, p->link) || .... nla_put_u8(skb, IFLA_GRE_PMTUDISC, !!(p->iph.frag_off & htons(IP_DF))))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、カーネルはカプセル化されたパケットのヘッダーからIP_DFをコピーします。



（突然興味深い興味深いトピック：Linuxは元のパッケージからTTLもコピーします。つまり、GREトンネルはカプセル化されたパッケージからTTLを「継承」します）

ドライスクイーズ

地球が飛行方向に向いたため、飛行機がcrash落しました。



インストールの初期セットアップ中に、誤った仮定の一部として仮想マシンのMTUを設定します。 フラグメンテーションメカニズムにより、パフォーマンスがわずかに低下しました。 カーネルを3.8から3.13にアップグレードした後、OVSはip_gre.cカーネルモジュールに切り替え、元のIPパケットからフラグメント化しないフラグをコピーします。 ヘッダーを追加した後にMTUに「適合」しなかった大きなパケットは、断片化されなくなりましたが、ドロップされました。 GREがドロップされ、その中にパケットが含まれていなかったため、TCPセッションの参加者（パケットの送信）はICMP「妨害」アラートを受信しませんでした。つまり、より小さいMTUに適応できませんでした。 次に、IPv6はフラグメンテーションを予期せず（IPv6にはない）、大きなパケットの損失を正しい方法で処理し、パケットのサイズを縮小しました。

誰が責任を負い、何をすべきか？

私たちのせいです-誤ってMTUを設定します。 ソフトウェアのほとんど目立たない動作は、エラーがIPv4の動作を混乱させ始めたという事実につながりました。



どうする dnsmasq-neutron.conf設定のMTUを修正し（オプションdhcp-option-force=26,



）、クライアントに「スタンド」を与えました（オプションと共にDHCP経由でアドレスのリースを更新します）。問題は完全に解決しました。



これを監視することで予防的に検出できますか？ 正直なところ、合理的なオプションはありません-診断は非常に繊細で複雑であり、クライアントインスタンスからの極端な協力が必要です（これに頼ることはできません-突然、誰かが、彼自身のニーズに応じて、iptablesを使用して奇妙なことを書きますか？） 。

叙情的な結論

ソフトウェアの前のバージョンにco病にロールバックし、「動作する-触らない」、「更新すると何が変わるかわからないので、再び更新されることはありません」という立場を取る代わりに、デバッグに1日約2人がかかりました。しかし、ローカル（可視）回帰が解決されただけでなく、既存の構成でエラーが検出および修正され、ネットワークからのオーバーヘッドが増加しました。 問題の解消に加えて、使用されている技術の理解が大幅に向上し、ネットワークの問題をデバッグする技術が開発されました（GRE内のフィールドによるtcpdumpのトラフィックのフィルタリング）。

コメント-パワー

突然、コメントの中で、 ildarzはこのようなものを見つける方法について素晴らしいアイデアを提案しました-IP統計を見て、増加するフラグメント（/ proc / net / snmp、netstat -s）に反応します。 この問題についてはまだ調査していませんが、非常に有望です。