ネットワーク

こんにちは。酔っ払い系ツチノコです。

今回は、先月 IRS26  で話して来た内容です。ハイ、すんません。書くのすっかり忘れてました。

今回の話はよりネットワークよりの話です。特定層以外には全く通じない話の様な気もしますが、せっかくなので記事にしておきます。

すんごくすんごくはしょって大雑把にいうと、世の中のISPやアカデミックな組織、大規模な企業等のある程度の規模のネットワーク同士はBGP ( https://www.nic.ad.jp/ja/newsletter/No35/0800.html ) という仕組みを使って相互に接続しています。BGP では各ネットワークの塊を AS という番号を用いて識別していまして、例えば DMM.com であれば AS23620 というのが識別子になっています。

そして、AS間での相互接続のうち、対等に接続し、御互いに直接所属するネットワーク情報のみを交換する事を Peering といいます。(単にBGPに接続そのものを Peering という場合もありますが今回は詳細は省略…)

はい、ここまでは長い長い前置きです。

で、Peering している AS 同士では御互いに経路情報を交換するわけですが、本来意図していない経路情報が来た場合に拒否する為に、一定の経路フィルタをかけます。さて本題。

AS間の接続では少ない場合では数経路ですが、多い場合では数千〜数十万の経路を交換します。90年代後半からの歴史的経緯で日本では比較的細かい単位で厳密な経路情報をフィルタに書く習慣があります。「ひとつお客さんASがついたからみんなフィルタあけてね!」「ひとつPrefix(ネットワーク)が増えたからフィルタあけてね!」と言った具合です。

これがもう、大手ISPのお客さんが引っ越しした、ネットワークがひとつ加わった、なんてイベントは日常茶飯事なので、場合によっては毎日文字通り spam の様な数で送られてくるわけです。もう大変。

本来の目的は「異常な経路によりトラフィックが意図しない方向に引っ張られるのを防ぐ為に適切なフィルタをかけたい」ということなので、日本以外の国では「Private Address、Default route 等あきらかに異常な経路を拒否する」+「フルルートが流れてくると困るので一定の経路数までしか受け入れない」等の比較的運用が軽く、実用的なフィルタを適用する事が殆どです。

というわけで、日本でも歴史的経緯で細かなフィルタをかけてコミュニケーションコストをかけて自己満足するのはやめようぜ、というセッションだったのでした。

以上、長文の割に特定層にしかヒットしかしない記事、失礼しました。。。

DNS, ネットワーク

こんにちわ。またエライ間隔があいてすんません。
酔っ払い系ツチノコです。

今回はロードバランサーとか ADC ( Application Delivery Controller ) とか呼ばれているもののお話です。

私は元々 L2/L3 のネットワークが専門で最近は仮想基盤なんかも扱っている感じのエンジニアなんですが、久々にロードバランサーに関わる事になりました。

過去にもある程度ロードバランサーについても構築・運用経験はあり、それなりに理解しているつもりだったのですが、実はロードバランサーを通る「パケットの気持ち」になりきれてない事がわかってきました。

同時に、この領域には体系化された教科書的な資料が少ないんだな、ということが見えてきまして、せっかくなのでカンファレンスでしゃべっちゃえ、ついでに同僚向けの研修用資料にしちゃえ、ということで書いちゃいました。

御自由にお使いください。

尚、パケットのウォークスルーを PowerPoint のアニメーションで書いている関係上、ダウンロードしてご覧頂いた方がいいかもしれません。

また、あわせて去年の Internet Week でしゃべったこちらの資料もご覧頂けると幸いです。GSLB なんかと多少からんできます。

 

P.S. 最近は業界の先輩におそわった上野せんべろライフを楽しんでおります。

それでは、よい酒ライフを。

ICTSC, イベント, コラム, ネットワーク

こんにちは、saiです。
「NTT西日本杯」第6回 ICTトラブルシューティングコンテスト(以下、トラコン)にて運営委員を務めさせて頂きました。

第6回トラコンでは15問の問題が学生の手によって出題されました!

今回は、私が担当した問題の内一つを紹介していきます。

タイトル:調子が悪いんでしょうか?

問題文

ある日、AWS内で弊社のWebサーバを稼動させることになりました。
ただしネットワークに割ける予算が少なかったために古いネットワーク機材を使用しています。
先日、本格稼動をする前に複数人で確認したところ、どうにも「見れるページ」と「見れないページ」が存在するようです。
また、状況によっては「見れないページ」も「見れる」場合があるそうです。
早急に原因を解明し、誤った設定内容を修正してください。修正後、報告もお願いします。
尚、変更するのはサーバのみでお願い致します。

見れないページ : URL

ServerIPaddress : ****
認証情報 【ID】: ****
【Password】: ****

FirewallIPaddress : ****
認証情報 【ID】: ****
【Password】:****


** 補足
問題を起こしている箇所を修正し、原因と修正内容を報告できれば対策を行えたものとします。*1

 *1  どういう状態になるとゴールなのかを記載していなかった為。又、全ての環境でMTUキャッシュクリアの方法をMTUというワードを出さずに周知できなかった為、補足させていただきました。

 

問題解説

この問題は、問題文と各種設定から原因を見つけていく問題でした。
AWS関連の情報やMTUについて詳しく知っていればピンとくるかもしれない問題ですが、そうでない場合難しい問題となったかもしれません。
また、解く際にWiresharkを用いたりすれば、MSS値周りの情報からヒントを見つける事が可能でした。

 

キーポイント

  • AWSのデフォルトMTU値が9001である
  • FW(vyosA)でicmpが全て拒否されている為、PathMTUDiscoveryまで拒否されている(PathMTUDiscoveryBlackhole問題)
  • 経路上のルータ(vyosB)のMTU値が800になっている
  • 結果、サイズが800byte*2を越えるWebページだけが見れなくなってしまう

  *2 実際には約600byte〜700byteくらい

 

解説

この問題では、一部Webページが見れない状況にありました。
その原因は、PathMTUDiscoveryが拒否されている事(PathMTUDiscoveryBlackhole)とMTUによってパケットがドロップしてしまう事でした。

まず前者についてですが、PathMTUDiscoveryはICMP type3 code4を用いMTUの低いルータ側から送信されます。
しかし、その先にあるファイアウォールがICMP全てをドロップしてしまう為、PathMTUDiscoveryが届かずデータの再送信が行われません。
その為、PCとAWS間のMSSが設定されたままパケットが送信され、途中経路のルータでパケットがドロップしてしまう状況が生まれます。

また、sshをすると通信の始めにクライアント側が大きいパケットを流すため、PathMTUDiscoveryがクライアント側に流れます。
そうすると、一時的にクライアント側のMTU値が800になるため、Webページを見れる状態になります。
しかし、これは恒久的な対策ではないため、これだけを解決策として報告した場合は間違いとなります。

今回、ファイアーウォールではなくサーバの設定を変更する問題となっているので、
サーバのMTU値を恒久的に800にあわせる設定を入れた事と、PathMTUDiscoveryBlackHoleについて触れていれば正解となります。
ただし、今回の状況から800というMTU値を推察するのは難しいだろうという事から、サーバのMTU値の設定はどの値にしていても間違いはないものとし、修正箇所と原因に気づければ正解としました。

 

解法

上記で大まかな解説は行っていますが、詳しい解き方については以下をご参照ください。

問題文からヒントを探す

この問題では、「一部見れないページがある」という現象が発生していました。
しかし、そのままではMTUが原因だとなかなか見つけられないかと思います。
なので、「AWS」や「古いネットワーク機材を使っている」というワードを文面に盛り込む事で、環境の違いを強調していました。
この文面から、環境によって引き起こされているトラブルではないか?と考えると解きやすかったかもしれません。

 

手元にある情報から探す

では、本当にページが見れないのか実行してみましょう。
(ブラウザでも確認はできますが、今回はcurlで実行してみました)

# curl -v http://hogehoge/
* About to connect() to hogehoge port 80 (#0)
*      Trying hogehoge ... connected
* Connected to hogehoge ( hogehoge ) port 80 (#0)
> GET / HTTP/1.1
> User-Agent : curl/~~~
> Host :  ipaddress
> Accept :  */*
>

上の結果から、コネクションは張れるけれどページが見れないという状態を確認できます。
また、この時のパケットをwireshark等で確認すると、3WAYHandshake時にMSSで9001という値が交換されています。
(これはWebServerへsshしifconfigする事でもわかります。)
そして、ssh時に帰ってきているパケットを見ると

「ネクストホップのmtuは800だよ」

というicmpパケット(PathMTUDiscovery)が来ているため経路上のMTU値も判断できるのです。
ここまで来ると、なんだかMTU怪しいなと感じませんか?

 

原因を特定する

さて、経路上のMTU値が低い事がわかりましたが、果たしてそれが原因なのでしょうか?
それを特定するためにはFWのコンフィグを見る必要があります。
FWには以下のような設定が入っていました。

・firewallをeth0にセット
・デフォルトアクションはドロップ
・許可するポート番号は80番と22番

つまり、HTTP(80/tcp)とssh(22/tcp)以外は通過できない状態にあったのです。
では整理も兼ねて、現状分かっている情報でトポロジ図を作ってみましょう。

このようになりますね。
それでは、これによってどのような事が起きるのでしょうか?
名前から先にお伝えすると、PathMTUDiscoveryBlackholeという現象が起きています。

PathMTUDiscoveryBlackholeとは・・・
経路上に異なるMTU値が存在していても、 Path MTU Discovery によって通信することができるようになりますが、適正なMTU値を伝達するためのICMP(type3 code4)パケットを送信元に送信しない設定や、途中の経路でICMPがフィルタリングされている場合には、以下のような問題が発生します。以下のような状態の事をPath MTU Discovery Black Holeといいます。

詳しくは以下のリンクへ
引用元 : http://www.infraexpert.com/info/5.2adsl.htm – ネットワークエンジニアとして

 

では以上の事を踏まえ、Webページを参照しようとした場合の流れを考えていきましょう。

Webページを参照する時の流れ

1.ユーザがWebページをサーバにリクエスト
2.3WAYHandshake時に交換したMSSに合わせてサーバがWebページを送信
3.通信経路上にあるネットワーク機器のMTU値が低いため、Webページを受け取れない
4.通信経路上のネットワーク機器(MTU800)がPathMTUDiscoveryをサーバに向かって送信する
5.FWによってPathMTUDiscoveryが拒否される
6.PathMTUDiscoveryBlackholeが発生し、Webページが読み込まれない

通信の流れを文章で書くと、このような形になっていたわけですね。
つまりここを解決できればなんとかなりそうですね!

対処する

そうなると、対処方法としては以下の二つが挙げられます。

・FWでicmpを通すように設定変更を行う (PathMTUDiscoveryのみ許可する場合はtype3code4のみ指定)
・サーバ側のMTUを経路上の最小MTU値に合わせる

このどっちかを行えば、今回の現象を回避できそうです。
ただし、問題文には以下のような記述があります。

尚、変更するのはサーバのみでお願い致します。

ということは、今回はサーバ側のMTUを変更すればよさそうですね。
それではサーバのMTU値ですが

今回の環境だと、このファイルに追加記述する事で変更できます。
追加する内容は以下になります。

これで保存した後に、インタフェースをアップし治す事でMTU値が反映されます。

以上で、対応完了となります。

尚、以上のMTU設定に加え、PathMTUDiscoveryBlackholeについて触れていると完答となっていました。

 

 

まとめ

「PathMTUDiscovery問題」如何だったでしょうか?
序盤の方では「よく見る事」と「気づき」が重要になっていたので、難しい問題になったかもしれません。
そもそもこの問題自体、問題作成や検証にものすごく時間がかかった問題なので、私自体苦労して作っていました。
「MTUは暗黒大陸」なんて言われる事もあるようなので、この問題を通じてMTUの重要さとめんどくささが伝わればと思います!

CDN, IPv6, ネットワーク

前回、DNSサーバを利用した名前解決と利用するIPバージョンの組み合わせに関して紹介しました。今回は、IPv4とIPv6を別々のISPで接続しているような場合、DNSを利用するCDNとの相性が問題になる可能性について紹介します。

問題が発生するのは、以下の図のようにIPv4とIPv6で別々のISPを利用しつつ、キャッシュDNSサーバはどちらか片方のISPを利用しているような環境です。たとえば、フレッツでIPv4とIPv6を別々のISPにするような設定をしていたり、IPv4しか提供されていない環境で、Hurricane Electricなどが提供しているようなIPv6 over IPv4トンネルを使っているようなときに発生する可能性があります。

この図では、家庭に対してIPv4はISP Aによって提供され、IPv6はISP Bによって提供されます。ユーザが利用しているPCに設定されているキャッシュDNSサーバは、IPv4を利用しているISP Aのものを利用しています。

このような環境で、CDNによって負荷分散が行われているコンテンツをユーザが取得するときの流れをみます。

まず、最初にユーザがISP AにあるキャッシュDNSサーバを利用して名前解決を行います(1)。このとき、ユーザはIPv4とIPv6の接続性を両方持っているので、AAAAレコードの問い合わせを先に行っているものとします。また、AAAAレコードの問い合わせに使われるキャッシュDNSサーバまでのトランスポートはIPv4とします。

ISP AにあるキャッシュDNSサーバは、権威DNSサーバにAAAAレコードの問い合わせ行い、回答を得ます。ISP AとISP Bは、双方ともにIPv4とIPv6両方で運用されており、IPv6で運用されたCDNキャッシュが両方のISP内にあるものとします。

このような環境下では、権威DNSサーバは問い合わせを行ったキャッシュDNSサーバの最寄りコンテンツキャッシュであるCDNキャッシュAを、キャッシュDNSサーバへと返答します(2)。

キャッシュDNSサーバからの名前解決結果を受け取ったユーザは、CDNキャッシュAからコンテンツを取得します。このとき、コンテンツ取得に利用されるトランスポートはIPv6となるため、ユーザはISP Bを経由してCDNキャッシュAにあるコンテンツを取得します。

しかし、ISP BにもCDNキャッシュBというコンテンツキャッシュがある場合、ユーザは遠回りをしてコンテンツを取得していることになってしまいます。このような遠回りが発生するのは、CDNによる負荷分散機能の一部である権威DNSサーバが「ユーザはISP Aにいる」と認識しているために発生しています。

ISP BのキャッシュDNSサーバを利用すれば、ユーザはCDNキャッシュBからIPv6トランスポートを利用してコンテンツを取得できるようになりますが、今度は逆にIPv4でのCDNキャッシュコンテンツ取得が遠回りになってしまいます。

DNSのリソースレコードごとに、利用するキャッシュDNSサーバを設定できれば、このような問題は軽減できると推測されます。たとえば、IPv4のAレコードを取得するときと、IPv6のAAAAレコードを取得するときに利用するキャッシュDNSサーバをそれぞれ設定することによって、キャッシュDNSサーバとのトランスポートとリソースレコードをマッチさせることができれば回避可能です。しかし、現時点では、そういった使い分けが行われることは稀であるため、このような問題が発生していると思われます。

ただし、このような状況に陥ったとしても、単に遅くなるだけでユーザが気がついていない可能性も考えられます。そもそも、CDNとの相性を追求するような設定をユーザ側が行うことが正しいのかどうかという問題もあります。

この話は多少マニアックではありますが、IPv4とIPv6のデュアルスタック環境において発生する課題発見や運用ノウハウの蓄積は、まだまだこれからかも知れません。

IPv6, ネットワーク

インターネットは、IPパケットを利用した通信です。IPパケットの宛先や、そのIPパケットの送信元はIPアドレスという固定長の識別子によって示されています。しかし、IPアドレスだけだと人間がわかりにくいので、www.example.comのような「名前」が利用されます。

名前のままでは通信ができないので、名前に対応するIPアドレスを調べる「名前解決」が行なわれます。この名前解決を行うためにDNSが使われる場合、ユーザはDNSサーバに対してIPv4アドレスやIPv6アドレスを問い合わせます。

DNSへの問い合わせは1回に1つだけ

DNSプロトコルの基本は、1987年に発行されたRFC 1034RFC 1035が基本となり、その後各種変更が別途RFCとして発行されています。

RFC 1034には、基本的なDNSの仕組みとして、UDPデータグラムかTCPコネクションを通じた問い合わせに対して、回答するか、エラーを通知するか、他のネームサーバを参照するといった返答が行なわれるとあります。

このときやりとりされるDNSメッセージは、RFC 1035に以下のように記載されています。DNSメッセージは、Header、Question、Answer、Authority、Additionalの5つのセクションに分かれています。

DNS message format

Questionセクションは、問い合わせの内容を記述するために使われます。Questionセクションに含まれる”question”は、以下のようになっています。

Question Section

この”question”は問い合わせを行う文字列が含まれます。RFC 1035に記載されている仕様上は同時に複数の”question”をQuestionセクションに含むことが可能と読めますが、現在は事実上単一のレコードに対してしか問い合わせは行えません。

そのため、IPv4とIPv6の両方のIPアドレスをDNSサーバに問い合わせる場合には、DNSサーバに対する問い合わせは、Aレコード(IPv4アドレス)の問い合わせと、AAAAレコード(IPv6アドレス)の問い合わせが別々にそれぞれ1回ずつ、合計2回発生します。

DNSサーバへの問い合わせとトランスポート

さて、さらに話がややこしくなるのですが、DNSサーバに対する問い合わせのトランスポートと、問い合わせの内容は全く独立です。

たとえば、上記図のようにDNSサーバへのトランスポートはIPv4 UDPで行い、IPv6を示すAAAAレコードを問い合わせることが可能です。逆に、IPv6 UDPをトランスポートとして利用し、IPv4を示すAレコードを問い合わせることも可能です。

組み合わせとしては、以下の4パターンが可能です。

  • IPv4トランスポート、Aレコードを問い合わせ
  • IPv4トランスポート、AAAAレコードを問い合わせ
  • IPv6トランスポート、Aレコードを問い合わせ
  • IPv6トランスポート、AAAAレコードを問い合わせ

このように、IPv4でもIPv6の名前解決が行えるようにすることで、IPv6が整備されていない環境においても、IPv6に関連する名前解決が可能とするためという意味合いもあります。もし、IPv6でのみAAAAの検索可能という仕様であれば、特定の名前解決を行う際に関係する全てのDNSサーバがIPv6対応している必要が生じます。

13系統あるDNSルートサーバのうちの6系統にIPv6アドレスが設定され、IPv6トランスポートによるDNSルートサーバへの問い合わせが可能になったのが2008年2月4日です。もし、IPv6トランスポートでしかAAAAレコードの問い合わせができない仕様であったのであれば、2008年2月以前はAAAAの名前解決が全て不可能であったと予想できます。

RFC 3901(DNS IPv6 Transport Operational Guidelines)には、すべてのDNSゾーンはIPv4のみか、IPv4とIPv6のデュアルスタックで運用されるべきであると書かれています。IPv6のみでDNSゾーンを運用すべきではないとあるのです。

このように、IPv4とIPv6は直接的な互換性がない別々のプロトコルでありながら、名前空間は共有しているのです。

次回はCDNとの相性の話です

次回は、DNSサーバに対するトランスポートとしてIPv4とIPv6のどちらを使うのかと、CDNとの相性に関して紹介します。

PAGE TOP