今週の検索ワード：業務系（ITなど）：2010年8月2日～8月8日

今週も検索を取り上げてみます。今週から「IT系」「非IT系」という区分から「業務系（ITなど）」「プライベート系」という区分に変更します。

「今週の検索ワード：非IT系：2010年7月26日～8月1日 」にも書いたとおり、「IT系」「非IT系」だと、ITではないがプライベートな話とは言い難い内容について書きにくいのでこんなふうにわけてみます。まあ、もうちょっといい分け方思いついたら逐次変更します。まあ、今回はまだ「IT系」「非IT系」でもかわりはありませんが。

今週は「開設3カ月にして・・・」にあげたとおり、1日の訪問者数がはじめて100人を超えた日がありました。そして、その大部分がIT系用語の検索によるものでした。ありがとうございます。

今週も資格（「情報セキュリティスペシャリスト試験」、「テクニカルエンジニア（ネットワーク）：ネットワークスペシャリスト」）、「パケットキャプチャ：Tshark　＆　Wireshark」、「サーバのNICチーミング」「Path MTU Discovery」といった記事の検索が多いようです。また、「開設3カ月にして・・・」にあげたとおり、小ネタでの検索も多かったです。

では、今週もいくつか取り上げてみましょう。

WANアクセラレータ　複数拠点間

「WANアクセラレータ」の記事が検索されました。基本的には拠点間、もしくはモバイル端末からのアクセスに対して使うものですし、当然のことながら複数拠点間での高速化となります。もちろん対向にWANアクセラレータがない場合には「普通にL2スイッチとしてふるまう。（インラインではなくWCCPでのリダイレクトを行う場合、実データはそもそもWANアクセラレータを経由しない）」という動きになるはずですから、必要な拠点から、あるいは影響度の低い拠点から段階的に導入することも可能です。

RSTP　マルチベンダー

当然のことながら、どのネットワーク機器ベンダーもIEEE802.1wをベースに開発、Ciscoなどメジャーな機器と連携できるように検証を行う、といったことは行なっているはずなので、マルチベンダーでも連携は可能なはずですが、どういうわけかうまくいかなくてループになってしまう、という話を聞くこともあります。RSTPのパラメータ自体が適切でない場合、最適なルートブリッジは選べないかもしれませんが、RSTPが動いていて途中でBPDUを止めるものがないのであれば、基本的にループは起こらないはずです。ただ、それでもループは起こっているようです。

まあ、プロトコルを理解して１つ１つ動きを追っていけばどっちの動作がおかしいか、という検討はつくのですが、それも慣れない人にとっては面倒です。機器の不具合が明らかであればメーカーも対応は可能でしょうけど、どっちの機器が原因かが微妙・・・という場合、まともに対応していたら事態が長期化する、ということもあるかもしれません。

もちろん、「RSTPの高速化切り替えが必要」ということであれば調査が必要ですが、「とりあえず復旧すればいい」というのであれば、場合によっては同一ベンダーのスイッチのみでRSTP/STPを動かし、ほかのスイッチ（あるいはL3以上のネットワーク機器）についてはBPDUが通過できるようにだけする、というほうがいいかもしれません。もちろんこの場合、RSTPを動かしている機器でリンクダウンの検知ができない個所ができてしまうケースがあるので、障害の個所によってはSTPと同じ扱い（30秒程度停止）になってしまうこともありますが、「調査に時間をかけるよりはこの状態でも稼働させたい」という状況もあるかとは思います。

vrrp 異機種

これはさすがにメーカーが「サポートできない」といったら仕方ないようにも思いますがね・・・。
同じメーカーの機器でも、「性能は違うけど機能的には全く同じ」という場合なら、アクティブ機ダウンの場合に（よりスペックの低い）スタンバイ機に切り替え、というのもありでしょうけど、機能的に違ってしまうと厳しい場合もあるのかな、と。もちろん、VRRP機能そのものに差があるんであれば、まず難しいと思います。

まあ、VRRP自体、RFC3768などの規格では決められてますが、実装はメーカーごとに異なり、RFCそのままでの実装、というほうが少ないかもしれません。パケットのフォーマット自体はRFCに準拠させるケースが多いです（そうしないとたとえば、Wiresharkなどの解析ソフトで”VRRP”として認識できなくなってしまうことが予想されます、解析する側としては不便です）が、VRRPの優先順位をどのように決めるか（ポートリンクダウン等を優先順位に反映させるか否か）など、実際の動作についてはメーカー次第でしょうし。

cisco ルータ　arp エージング

「Cisco　ルータ　ARPキャッシュ　クリア」などほかのワードでも調べてみました。
　http://www.cisco.com/JP/support/public/ht/tac/100/1008459/arp-cam-tableissues-j.shtml
　などにあるように、Ciscoルータの場合（すべてではないかもしれませんが）、デフォルトのARPキャッシュ保持時間は4時間のようです。たとえば下位側のファイアウォール等のネットワーク機器をリプレイスするような場合、注意が必要になります。そのままほっとくとまるまる4時間通信ができない場合もあるでしょう。

このあたり、機器のリプレイスのときには避けて通れない話ですね。もちろん、ルータ側のオペレーションが可能であれば、ARPキャッシュのクリアもできますし、キャッシュ保持時間を短くすることも可能です。ただし、「ルータは別業者なのでこの部分は触れない」というケースは割とあります。いつだったか「とあるISPでどういうわけか半日近くキャッシュを持っているところがあった」という話も聞いたことがあります。

この場合には、リプレイス後の機器からpingを打つなどして、上位機器にMACアドレスを学習させる、などのオペレーションが必要になります。Windowsサーバとかであれば「Gratuitous ARP」を使うこともできますが、ネットワーク機器だとそうはいかないでしょうし。

さてと、では「プライベート系」のワードも見直していきます。

---

この記事が気に入りましたら、また、お役に立ちましたら、以下のアイコンをクリックしていただけると嬉しいです(^^)

---