cloretsblackのテクニカルノート

言葉の意味はよくわからんがとにかくすごい自信だ

JTF2017で発表しました

昨年に引き続き、今年もJTF2017で発表させていただきました。 当日は過去最高の参加人数だったとのことで、運営の皆様は非常に大変だったかと思いますが、おかげさまで気持ちよく発表や交流を行う事ができました。 このようなすばらしい機会を与えてくださった皆様に、心より感謝申し上げます。

今回のテーマは「情シスのひみつ」という事で、16年勤務した情報システム部門で得た様々な経験についてお話しました。
申し遅れましたが、黒ブラはこの8月に部署異動をしており、情報システム部門を離れ、ソフトウェア開発部門に配属されています。

www.slideshare.net

今回の発表は、個人的には「卒業研究」と位置づけています。 退職エントリとかではないのですが、すこし、自分の話をしてみたいと思います。

黒ブラは新卒でユーザー企業の情シス部門でインフラチームに配属され、パソコンのヘルプデスク業務からキャリアをスタートさせました。 たまたま、新システムの開発の手が足りないという事で、Oracleデータベースの夜間バッチ開発を手伝う事になり、割と早いうちからデータベースを覚えました。 その後、本格的にサーバ、ネットワークの管理を担当し、LinuxやDBA業務を覚えていく事になります。

ちなみに、経験ゼロで入ったヘルプデスク時代に、部署にあった、当時誰も触っていなかったSniffer Basic（商用のパケットキャプチャツール）を見よう見まねで弄り倒していた経験が入社4年目辺りから徐々に形になりだし、サーバ、DBなどの構築や操作は素人の癖に、何故かトラブルシューティングの精度だけ高いという不思議な覚え方をしました。

今にして思えば、分からない事に対し、分からないなりに取り組む時の姿勢として、

  • エビデンスを探し、Factを積み上げる
  • 正常と異常をI/Oレベルで見比べ、切り分ける

を習慣化していたことが、壁に突き当たってくじけたりする事もなく、長期間学習を継続できたポイントだったのかもしれません。

このスキルはその後、WEBプログラミング等、新しい技術を学ぶ際に幾度となく黒ブラを助けてくれ、 今ではデータベースのデバッグや監視すらもパケットキャプチャを応用する事ができるようになりました。

この辺りの事は以前ハンズオンセミナーをやったときに興味をもたれていた方がいらっしゃったので、少しノウハウとして書き残しておきたいと考えています。 今後何らかの形で皆様のお目に触れる事があるかも知れません。 そのときにはどうかよろしくお願いします。

IoTシステムのトポロジの話

ネットワーク IoT アイデア トラブルシューティング

ネットワークのトラブルシューティングのためのIoTを作っています。
先日発表した勉強会資料で、参加者から質問が出ていました。

www.slideshare.net

時間の関係でうまく説明できていなかったかもしれないと思いましたので、ブログ記事にします。

前置きとして、IoTシステムという文脈で語られる典型的な例として、デバイスによるセンシングとそれを集積するクラウドという構成があります。
このような構成はネットワークをはじめとするインフラの運用監視システムとしてはおなじみのもので、監視対象機器を設定し、トラフィック量、サーバのCPU使用率、DISK負荷、サービス応答時間、各種ログ等々を収集します。
勉強会ではインフラの運用管理システムがIoTシステムに、非常によく似ており、IoTデバイス=ネットワーク機器という図式が成り立ち、機器から集めたデータを可視化する運用管理システムは、すなわちIoTシステムではないかという所から話がスタートします。

頂いたご質問は、
「一般的なIoTシステムとして、デバイスで採取したデータをクラウドなどのサーバに集積して見せる形態が多く取られているが、今回の発表は同様のものではないのか？」
という趣旨のものでした。

両者の比較

一般的なトポロジ
f:id:cloretsblack:20170304095434p:plain

今回発表したトポロジ
f:id:cloretsblack:20170304095458p:plain

ご指摘の通り、IoTシステムの構成としては少し変わった形ではないかと思います。
トポロジが特徴的な理由としては色々あるのですが、黒ブラは普段システムを使う側の人間なので、ユーザー（黒ブラ）が本質的に何を望んでおり、どの様なシステムがマッチするのか、という問いに対する一つの結論だと思っています。
要点は以下の通りです。

・本来の目的
・やりたいこと
・データの解像度の問題
・最適なトポロジ

本来の目的

ネットワークやサーバの運用監視に用いられるシステムはOSS含め大量に存在し、日々しのぎを削っています。

これらの製品の目的は「継続的にサービスを提供すること」です。

安定してサービスを提供するためには
1.システムトラブルをいち早く発見すること
サービスの停止前に問題を発見できたらラッキーです。ユーザーが気づく前に修正できれば問題は起きていないのと同じです。

2.素早く復旧すること
不運にもサービスが停止してしまったら、素早く復旧することでビジネス損失を最小化できます。極端な話、利用ユーザーの少ない深夜に5分だけの停止で済めば、ビジネス上の問題は少ないケースがあり得るでしょう。

3.再発防止に取り組むこと
再発防止に取り組むことで問題そのものの発生頻度を減らすことができます。

サービスやプロダクトの安定性というものは、こうした問題解決のプロセスを数多く回し、それぞれの問題にきちんと対策が取られることにより向上するものです。
f:id:cloretsblack:20170304153043p:plain
集英社ジャンプコミックス 車田正美著 聖闘士星矢より引用

やりたいこと

これらの製品を使う上でユーザーが知りたい情報は下記の二つに集約されます。

・監視対象機器に問題が起きていないか
・問題が起きていたらその原因は何か

監視チームとデバッグ担当者が分かれている場合には、監視チームが担当者に通知して終わり、というケースがあり得ますが問題の解決には不十分です。

最低でも問題解決の糸口になる、欲を言えば問題個所の切り分けと、再現条件が得られるレベルの情報を集めることが理想です。

データの解像度の問題

どのような情報を集めるべきかというのはアプリケーションの作りによっても違いますが、従来の運用監視システムにおいてサーバのログや稼働情報を集めたとしても、問題の解決につながらないケースがわりと存在します。
これはデータの解像度の問題です。

実例を挙げて考えてみましょう。
f:id:cloretsblack:20170304100856p:plain

「A」という業務WEBシステムでは、データの参照、登録、削除機能に加え、クライアントPCからのファイルアップロード機能を備えています。アップロードされたExcelファイルの内容を読み込み、データベースに反映し、後続処理を行います。

あるとき、Aシステムで夜間バッチのメールが飛んでいないという問題がありました。
調べてみると、アプリケーションサーバがハングアップしていました。
サーバ再起動によって問題は解消し、リカバリー処理も完了しましたが、原因が分かりません。
ログを調べると夜間バッチ処理が起動していないことが分かったので、おそらく夜間処理前にアプリケーションサーバに何らかの障害があったのだと推測されました。

たいていのシステム障害はログに残っていなければ何もわかりません。この例ではアプリケーションサーバに問題があることは明白なので、まだだいぶマシですが、サポートに問い合わせても対策できない可能性はかなり高いでしょう。

次の手としては、
・ログの詳細度をデバッグレベルまで高め、一時的な負荷と引き換えに、問題の再現条件を探す
・とりあえずベンダーから出ているパッチを全部当ててみる（スクラッチ開発の場合は難しい）
ということになり、完全に出たとこ勝負のトライアンドエラーになります。

この例では、あるユーザーが深夜にアップロードしたファイルのデータバグが原因でした。
ログの詳細度を上げていれば発見可能だったかもしれませんが、厳密にはプログラムは異なる分岐を通りますし、負荷の状態も異なりますので、解決までのリードタイムは確実に伸びていたと予想されます。

結果として、この障害はSonarmanで解決しました。
・パケットキャプチャでログに残った時刻より、問題の通信とユーザーを特定
・発生時のサーバレスポンスから、処理負荷によるタイムアウトである可能性を排除
・その場でユーザーに電話して、問題のファイルを取得し、検証用としてベンダーに引き渡し
・証跡としてパケットキャプチャを添えた上で、開発環境での検証と修正を依頼
復旧作業完了後に原因究明を始めて、一時間以内に対応できました。
あまりにもサクサク進んだためか、この一連のやり取りでベンダーの担当者がちょっと引いていましたが…。

Sonarmanは、サーバに一切の変更を加えることなく、最大の解像度で障害に関する情報を取得するというコンセプトで開発されました。 解像度の低いデータをクラウドに集積してざっくりと全体を把握するのではなく、一撃で解決につながる濃い情報を現地に持つというイメージです。
ちなみに高解像度情報をクラウドに持つのは容量の問題で現実的ではないです。（そういった間を取るソリューションがNetflowコレクタです）

最適なトポロジ

それでは、ネットワーク機器をIoTとしてとらえた時に、トラブルシューティングを目的としたIoTでは、どのようなトポロジが最適なのでしょうか。
誤解してほしくないのは、従来のSNMPをはじめとする運用監視ツールは依然として必要だということです。
私自身も運用監視ツールは使っていますし、どちらが優れているというというよりは、ケースによりどのような情報が見たいかというユーザー要求の問題だと思っています。
様々なレイヤの異なる解像度の情報を組み合わせて分散して持っておいて、困ったときはちゃんと調べられる状態にしておくのが良い、というのが私の結論です。

f:id:cloretsblack:20170304154203p:plain

この記事を読んで下さった方のご参考になればうれしく思います。
最後に、手前味噌で大変恐縮ですが、IoT パケットレコーダー「Sonarman-R」Amazonにて発売中です！
この手のパケットキャプチャ装置としては業界に激震が走るレベルのコストパフォーマンスです。

Sonarman-R

Sonarman-R

Npstudy#11で発表しました。

ネットワーク IoT

発表内容

以下資料です。

www.slideshare.net

要約すると、パケットキャプチャを集積しておくことで、ビッグデータのように扱えるので、保守運用に必要な各種データが任意のタイミングで同じ手順で取り出せるようになりますよというお話です。

同じ手順とは言いましたが、簡単とは言ってません。
ある程度ネットワークの知識がないと難しいのではないかと思いますが、手法としてはそれなりに使えます。

本番稼働中のサーバに置いてあるデータ収集用のスクリプトを変更するなどの作業は現場の人間にとって非常にやりにくい作業の一つです。
その点、Sonarmanは一旦設置してしまえば、稼働中のサーバやネットワークに一切の変更を与えることなくデータを取得できるので、安心感があります。

情シスというポジション

情シスというポジションについても触れました。ITのエキスパートであるベンダと、業務のエキスパートであるユーザーの間に挟まれ、ある意味最も理解されづらいポジションではないかと思う時があります。

情シスにおけるインフラ担当者としての価値、すなわち自社での利用状況や課題を把握し、ユーザー価値を最大化するための施策を立案、実行する事ですが、そういった活動の元となる各種数値を効率よく正確に把握するためにはどうすれば良いかという問いに対する、私なりのアイデアと実行結果についてお話しました。

重要な事は2つ。
・何かを検討する際に正確な数字を持っている
・問題発生のときにエビデンスを持っている
これらの条件を満たす事は、話し合いの主導権を握るという事です。
このアドバンテージは非常に大きく、対人交渉や重要な判断の際に必ず役に立ちます。
事実、私自身過去に何度も助けられました。
私の経験が皆様のお役に立てばうれしく思います。

ご興味があれば、お気軽にTwitterでお声掛けください。

ジョジョの奇妙なケーススタディ【ネットワーク遅延】

テクニカル ネットワーク トラブルシューティング

きっかけ

ネットワーク遅延について書かれた資料を拝見し、インスパイアされてしまいました。
本記事とは異なり、大変真面目な内容です。

はじめに

一言にネットワーク遅延と言っても多くのケースが想定されます。 ネットワークを構成する様々な要素、例えば、サーバやクライアントPC、アプリケーションなどに原因が潜んでいる可能性があり、比較的難易度の高い障害ではないかと思います。
ただし、私の経験上、遅延の原因は解決してみればごく当たり前の現象であることがほとんどなので、ケーススタディを充実させるよりもネットワークの原理原則を理解したエンジニアに都度対応させるほうが理にかなっている一面もあり、遅延問題について具体的な事例と解説があまりインターネット上に存在しないように思います。

そのため、初心者がどれだけ検索しても問題事例に行き当たらないという現象が発生しており、ユーザー企業の情報システム部門などではユーザーとサポートベンダの板挟みにあい、苦しんでいる人々がいます。かくいう私もその一人でした。かつての私のような人々に少しでもご参考となればと思い、この記事を書きました。

f:id:cloretsblack:20170103113521p:plain
大体こんなテンションで進んでいきます
集英社ジャンプコミックス 荒木飛呂彦著 ジョジョの奇妙な冒険 より引用

注意
本記事ではネットワークのスループットが断続的に低下する事象を「遅延」と定義します。 具体的には理論値よりも明らかに速度が出ていない、以前よりも遅くなったなどの問題を扱います。
また、基本的にLANを中心に解説します。
パケットキャプチャを表示するソフトウェアにはWiresharkを使用しました。

私が今まで現場で見たことのあるネットワーク遅延とその検出方法、解決手法を具体的に書いてみたいと思います。

  • すべての「遅延」問題の調査に共通する基本
  • ネゴシエーション不一致
  • ケーブル不良
  • アプリケーションの問題
  • ネットワーク容量
  • サーバレスポンス遅延
  • ポート/セッション数枯渇
  • ジャンボフレームとフラグメント

すべての「遅延」問題の調査に共通する基本

もし、あなたの手元で問題が再現するなら、まずパケットキャプチャを取得するところから始めてください。

なぜパケットキャプチャを取らなければならないのですか？

ネットワークでは様々な機器が連携して動いています。サーバ、クライアントPC、スイッチ、ルータ、それらを繋ぐケーブルなどです。
これら全てをしらみつぶしにチェックすることは手間がかかり、さらに必要な情報が必ずしも取得できるとは限りません。
一方、パケットキャプチャには解析に有用な情報が非常に多く含まれており、またパケットキャプチャにしか現れない情報も存在するからです。

パケットキャプチャは非常に読みづらいのですが、読まなければなりませんか？

パケットキャプチャの解析はネットワークのデバッグ行為に相当します。ソフトウェアと同様に、動作を理解し、原因を突き止めなければ問題を正しく修正することはできません。
しかし、必ずしも解析のスキルを身に着ける必要はありません。パケットキャプチャは問題の状況を伝える最も有効な手段の一つです。
つまり、原因究明のアウトソースが容易になるという利点もありますので積極的に活用していきましょう。

f:id:cloretsblack:20170103093234p:plain
思わず納得
集英社ジャンプコミックス 荒木飛呂彦著 ジョジョの奇妙な冒険 より引用

それでは具体的にネットワーク遅延のケーススタディをみていきましょう

ネゴシエーション不一致

ケーブルの両端にあるネットワークインタフェースでネゴシエーションの不一致が発生するとパケットのドロップが発生しスループットが著しく低下します。
パケットのドロップが発生するとTCPの再送が起きるので、パケットキャプチャの再送の数をカウントするのはネットワークの品質をチェックするのによい方法です。ただし、無線の場合は様々な条件で再送が発生するので、この方法は有線限定です。
Wiresharkで再送を検出するフィルタには以下のものを使います。
tcp.analysis.flags
f:id:cloretsblack:20170102175107p:plain
ちなみにもし様々な事情でWiresharkを使うことができない場合は、端末上で
netstat -s
コマンドにより再送数を簡易的に把握することができます。

再送が多い場合、まず疑うべきはネゴシエーションの不一致です。 GigabitEthernetの普及にともない、古い100Mのスイッチを使用している場合、ネゴシエーション不一致が起こりやすいです。現在では端末のインタフェースもほぼ全てGigabitEthernetになっているのでネットワーク上の100Mのスイッチには要注意です。
ネゴシエーションの状態を知るには接続しているスイッチのランプを確認するか、インテリジェントL2スイッチやルータなどで、インタフェース情報を見てください。

f:id:cloretsblack:20170102180719p:plain

Half-duplexなどになっていた場合はネゴシエーションに失敗している可能性が高いです。 このあたりの不一致にはインタフェース同士の相性も出ます。あまり深追いせずに古いスイッチは交換しましょう。

なお、ネゴシエーション不一致の場合、後述するケーブル不良と同様に runts, giants, CRCなどのカウンタが記録されていることがあります。 これらの項目は深刻なエラーです。必ずゼロにしなければなりません。

GigabitEthernetでは基本的に自動（オートネゴシエーション）で対抗のlinkを識別します。その際、対抗の設定が自動でない場合は半二重でリンクしてしまいます。
一般的にネットワークの管理ではLAN内の機器のスペックやlink状態を把握しておくことは非常に重要です。

f:id:cloretsblack:20170103115046p:plain
オートネゴはオートネゴでしか倒せない。それがイーサネットのルールッ！
集英社ジャンプコミックス 荒木飛呂彦著 ジョジョの奇妙な冒険 Part7 スティール・ボール・ランより引用

余談ですが、回線業者に依頼してルータのLAN側のインタフェースを10M固定に設定させた同僚がいました。理由を聞くとWANの帯域が10M以下だったので、10Mがふさわしいと思ったそうです。
その結果、周囲の機器が10Mというレガシー規格にうまく対応できず、パケットドロップが頻発するという事態が発生しました。 当該ルータは業者しか触れない契約だったため、最終的に全部のリンク設定をオートネゴシエーションに戻すのに結構なお金と時間がかかったというオチでしたが、 緊急の回避方法として、10Mのスタティックモードを設定できる、懐かしのNetscreen-5GTを5000円で仕入れ、ルータとスイッチの間に設置するという荒技を使ったことがあります。
というか、業者さんも止めてほしいです。そういうときは。

まとめ
  • 有線ネットワークの品質は再送数でチェック
  • リンクの状態を確認し、ネゴシエーションの設定をチェック
  • 解決策：すべてのスイッチをGigabitEthernetのオートネゴシエーションに統一する
  • 打ち合わせ中に業者さんが変な顔をしたら、自分が間違っているかもしれないので聞いてみる

ケーブル不良

メーカー製のケーブルを使用する限り、日本ではほとんど起きないのですが、海外や自作のケーブルを使用していたり、UTPのカテゴリが合っていないなどの場合でまれに発生します。
このケースも前項と同様に再送数のチェック、確実には機器のインタフェース統計で判別します。
大前提として、ローカルエリア内の有線ネットワークにおけるTCP再送はゼロにできます。
少量の再送はスループットに大きな影響を与えないのですが、がんばってゼロにしておくと、異常時に気が付きやすくなるのでおススメです。

f:id:cloretsblack:20170103082337p:plain
伝われ、このスッキリ感
集英社ジャンプコミックス 荒木飛呂彦著 ジョジョの奇妙な冒険 より引用

ケーブル不良のうち、銅線の「より」が少ないことが原因でノイズが乗りやすい状態になっている場合があります。不定期に通信品質が悪化する現象が発生しますので、インタフェース統計の runts, giants, CRCのカウンタは最低でも敷設時、理想的には定期的にチェックするとよいでしょう。
f:id:cloretsblack:20170102180907p:plain

ちなみにCRCエラーが出ると、スイッチによってはCRCチェックの負荷によりpingのRTTに数ミリ秒の遅延が出る場合があります。同一拠点内でのpingに遅延がみられる場合には上記のカウンタを確認すべきです。

まとめ
  • ケーブル不良はインタフェース統計でチェック
  • runts, giants, CRCのカウンタがゼロでない場合は要注意
  • 解決策：ケーブル交換

アプリケーションの問題

アプリケーションの使い方によって、以下の例のように非効率的な通信が発生してしまうケースがあります。

  1. ネットワーク上の共有フォルダにインストーラーを置いて、端末から直接実行する

  2. 巨大なパワーポイントを共有フォルダに置いて直接開く

1.のケースではファイルの読み込みだけでなく圧縮ファイルの展開、解凍などで共有フォルダに大量の読み書きが発生しがちです。 インストール作業を自動化するためにパスを固定したい場合もありますが、一旦ローカルへファイルをコピーしてから実行するよう変更するべきです。

2.のケースではMS Officeがカレントディレクトリにキャッシュを作るという動作を行うために、非効率な読み書きが発生する場合があります。 参照用途で、かつ容量の大きい場合にはWEBなどから配布するなどの工夫をすると幸せになれるかもしれません。

ネットワークにおけるアプリケーションの挙動を詳細に解析するのは比較的難しいので、ネットワークの存在を意識した上でアプリケーションの使い方をトライアンドエラーするのがいいかもしれません。その際パケットキャプチャはトラフィックを定量化したり、レスポンスを正確に計測する用途にも使えますので、積極的に活用してみてください。

まとめ
  • ネットワーク特性を意識したアプリケーションの使い方をすることが大切
  • トライアンドエラーの効果測定にパケットキャプチャを使うと便利

ネットワーク容量

単純にネットワークに大きなデータが流れているために他の通信が送れないという現象です。
解決策としてはスイッチやルータの流量を収集してトラフィックを可視化するのが良いと思います。
具体的にはSNMPを使って流量のカウンタを収集するZabbixやCacti、MRTG、またはSNMPよりも多くの情報が得られるCiscoのNetFlowコレクタなどの可視化ツールの導入を検討してください。
手前味噌で大変恐縮ですが弊社のSonarmanもおススメです。

私の個人的な観測ですが、ユーザー企業の現場では意外なほどトラフィック可視化が行われていません。
トラブルシューティングにおいては、障害が起きた時のために普段から準備をしておくことがとても大切です。

問題の具体例として、WindowsUpdateやiPhoneの更新が集中するケースの他に、WSUS等の分散配布システムを使用する場合に、多人数の出張などで予期しないトラフィックパターンが生じるケース、クラウド等への大容量バックアップ、P2Pアプリケーションによる巨大ファイルのダウンロードなどが挙げられます。

まとめ
  • トラフィックの可視化を検討する
  • 人為的ミスが多い
  • 発生状況をヒアリングし個別に検討が必要

サーバレスポンス遅延

サーバそのものの反応が遅い場合があります。WiresharkではSMB2やDNS、LDAPなどのレスポンスタイムを可視化する機能がありますので、そういった機能を使ってもよいですし、WEBサーバであればブラウザの開発ツールがダウンロードに要した時間や処理のレスポンスを可視化してくれます。
注意点として、ファイル共有等でDISKのI/Oタイムアウトがエラーとして返される場合があります。パケットキャプチャでしか見つけられませんが、もし見つけたら絶対に無視してはいけません。DISKが壊れかけています。

まとめ
  • ブラウザの開発ツールやパケットキャプチャで遅延を計測できる
  • 解決策：サーバ増強

ポート/セッション数枯渇

ルータやプロキシサーバを長期間入れ替えていない、利用者が急激に増えたなどの場合にはセッション数やポートの枯渇を疑ってみるとよいかもしれません。
まずnetstatで機器のコネクション数を確認してください。
さらにパケットキャプチャで不自然な待ち時間やコネクションの切断が発生していないか、ルータのログにNATのセッションテーブルの枯渇が記録されていないか等もチェックポイントです。

最近のブラウザでは表示速度の向上を目的とした分散ダウンロードが一般的になっています。CSSや画像、スクリプトなどは異なるTCPコネクションを利用して並列にダウンロードすることで速度を出しており、それらは一つずつ異なるコネクションを使ってルータやファイアーウォールを通過します。
また、ブラウザの動きに合わせて、サイズの小さな部品をたくさん配置するデザインのWEBサイトも増えています。トップページの表示だけで数百のコネクションを使用するWEBサイトも存在しますので、注意が必要です。
ダウンロードが完了したコネクションは破棄され、ソケットは再利用されますが再利用の際に発生する負荷や、純粋なNATセッション数が上限に達してしまうことが原因で、待ち時間が生じてしまうことがあります。ネットワーク上でコネクションが集中する箇所は常時監視や定期的に点検してみることが大切です。
大量のセッションを消費するアプリケーションの具体例として、Bittorrent等のP2Pアプリケーションのフラッディングや、Bitcoinのマイニングツールなど、特殊なものも存在します。

f:id:cloretsblack:20170103095748p:plain
間違いない
集英社ジャンプコミックス 荒木飛呂彦著 ジョジョの奇妙な冒険 より引用

まとめ
  • ルータやプロキシサーバなどトラフィックが集中する箇所はコネクション数を監視する
  • 解決策：機器のアップグレードや分散配置

ジャンボフレームとフラグメント

通常のイーサネットフレームは1500バイト程度ですが、ジャンボフレームの普及により、LAN内で高速にデータ通信ができる環境が整いつつあります。しかしVPN等でWANに流れる通信の場合、パケットの分割すなわちフラグメントが問題になるケースがあります。問題の把握にはパケットキャプチャを取得する必要があります。
ジャンボフレームの分割に際し再送が発生していないか、PathMTUで発生するICMPのDestination Host Unreachable　メッセージが端末まできちんと返っているかなどがチェックポイントです。

パケットキャプチャではTCPのシーケンスナンバーを条件にフィルタすることで再送が発生する元のパケット（到達しなかったパケット）がどのような状態であったかがわかります。元のパケットがジャンボフレームだった場合には設定を変更してパケットのサイズを小さくしてみると状況が変化する可能性があります。
f:id:cloretsblack:20170102175120p:plain
(5446バイトのジャンボフレームが分割して再送されている)

f:id:cloretsblack:20170103111351p:plain
ちょっと違いますが

集英社ジャンプコミックス 荒木飛呂彦著 ジョジョの奇妙な冒険 より引用

まとめ
  • パケットキャプチャで再送やICMP、フレームの長さをチェックする
  • 解決策：ジャンボフレームの設定解除

最後に

非常にダラダラと読みにくい記事だったと思います。お疲れ様でした。

黒ブラとしてはコラを貼りたかっただけなので、説明はだいぶ端折っています。もしご質問などがあればTwitterでリプください。

Sonarman-Rを発売しました

テクニカル トラブルシューティング ネットワーク

Amazonにて発売中です。

Sonarman-R

Sonarman-R

いやーAmazonに置くまでが長かったです。 製品バーコード（JANコード）を取らないといけない等、知らないことばかりで黒ブラ的にもいい経験（？）になりました。
初期設定とデプロイ・テストを自動化したり、梱包資材を買ったり、挙句の果てにはバーコードが貼ってないとかで納品できず、返品食らったりもしました。 そんなこんなで、箱の中には黒ブラの年末年始がたっぷり詰まっています！

もともとこの製品は遠隔で海外のエンドユーザーをサポートをするために開発されました。 RTT400ms越えが当り前の拠点で「聞いたこともないようなメーカーのプリントサーバから印刷が出ない」みたいなクラクラするようなトラブルを解決するためのツールです。

黒ブラはインフラ担当として、そのような環境を10年以上サポートしており、実務から得られたノウハウもしっかり搭載しております。 ソフトウェアの開発には2年以上かかっていますし、お値段以上の価値があるのは間違いありません！
違いの分かる方にぜひお手に取っていただきたいと思います。

develup-japan.co.jp

今後とも黒ブラとSonarmanをよろしくお願いします。

エンジニアの報連相について

学び テクニカル

先日、後輩君と一緒に会議に出まして、 そこで後輩君の報告を聞きながらちょっと思ったので書いてみることにします。

まあ、後輩君が要領を得ない説明をするというのは、非常にありがちで自分もそうだったなーと思い出しました。
恥をさらすようですが、昔自分がやっていたことと、今気を付けていることを整理してみたいと思います。

昔の自分

上司「黒ブラくん、進捗はどうですか？」
ぼく「えっと、いまプログラムを書いていて、コンパイルエラーがやっとなくなりました」
上司「コンパイルエラーが無くなるのは当り前でしょ」
ぼく「あっはい」
上司「どうなの？」
ぼく「これから流してみます」
上司「間に合いそうなの？」
ぼく「大丈夫だと思います」

今思うと、だいぶアチャーな感じですね。。
このようなやり取りをしていたのは、ぼくが商社の情報システム部門で入社2年目くらいのころでした。
非コンピュータ系の学部を卒業した状態で、1年目はPCヘルプデスクをやり、2年目の後半からは基幹システムの新規開発プロジェクトに参加し、プログラム製造を担当していました。
初めてのプログラミングはPLSQLで、SQLの文法を理解するところからでしたが、商社の新人として入社したので、情報処理の教育はほぼ受けていません。
「SQLを覚えて」と言われて本を渡される感じの現場です。
当時、基本情報処理試験には3回落ちており、受験自体をやめてしまったので、基礎はだいぶ抜けていたと思います。 （今ではさすがに受かると思いますが。。）
なので、非常に聞いていて不安を感じる報告ですね。これからの工程とか理解してんのかという感じです。
もちろん当時は理解せずに報告しており、後で大変な目に合うのですが。。

どうすれば良かったか？

  1. その場にいる人のレベルや会議の趣旨を理解した上で質問の意図と求められるレベルを想定する

  2. 想定するレベルに合わせて報連相する

  3. 具体的に進捗確認であれば、現在の状態、今後の予定、スケジュールとの差異、問題が発生しているか、等を簡潔に述べる

  4. 必要であれば、ホワイトボードに図を書く（積極的に）

報連相の常として結論から先に言うというのも大事だと思います。 あと、上司から質問が何回も出るというのは「こいつ本当にわかっているのか？」という疑問を払しょくするためでもあります。
そこで4に挙げたように、図を描くと「わかっている感」が生まれるので、聞いているほうに安心感が出てきます。 会議の時間を使ってしまうという問題はあるのですが、積極的に使っていきたいテクニックです。

製造工程の理解とマイルストーンの設置、スケジュールの感覚などは基礎的な教育と経験で得られるものなのですが、進捗の報告をする前に理解しておかないとそもそも話が通じないので、そこは上司や先輩とかがフォローしてほしいですね。

ちなみに後輩君はぼくと比べて基礎が非常にしっかりしており、「おまえこの年齢でこのスキルって、無敵じゃね？」ってぐらいの逸材なので、この手のテクニックを積極的に伝授してパーフェクト超人にパワーアップしてもらおうと思っています。

f:id:cloretsblack:20161217053931j:plain
だいぶ待っていたよ　　

集英社 ジャンプコミックス ゆでたまご著 キン肉マンより引用

ハンズオン体験記

学び ネットワーク テクニカル

試してわかるSDN　～Tremaではじめるパケット生成ハンズオン～ で講師を務めました。

www.slideshare.net

ハンズオンは難しい

私にとっても初めてのハンズオンだったので、様々な学びがありました。
参加者のレベルやペースも様々ですし、フォローが難しいです。 Tech-Circleの皆様のご協力で何とか形にできた感じです。 本当にありがとうございました。

参加者の環境がマチマチ

やはりプラットフォームの差異を甘く見てはいけないですね。 当初VMでやれば大丈夫だろうと思っていましたが、インポート時にネットワーク周りで予想しなかった挙動があり、一瞬戸惑いました。
Windows10での予行演習はしていたのですが、私の環境とは違う動作をしていたことと、ハンズオン中に出てくるとアナウンスが難しいというのは貴重な経験でした。

お一人、Windows7の32bit環境でおそらく64bitのVMを動かすのが初めてという方がいて、インポートのエラーで躓き、実質放置状態になってしまいました。
BIOSのVT-x拡張を調整してみてもらえますかと言ったのですが、ハンズオンに来てBIOSの設定変えるの嫌ですよね。。
予め案内等に書いておけばよかったです。ごめんなさい。

それ以外は比較的スムーズに進捗しましたので、至らない点は少々あったものの、 VMで環境をまとめておいたのは良いアイデアだったと思います。

ちなみに資料中、後半のCMが長いのは尺の関係です。。

このハンズオンをご自宅ででもやってみたいという方がいらっしゃれば、 VMをご提供いたしますのでtwitterまでお知らせください。