今週の検索ワード：プライベート系：2010年8月2日～8月8日

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

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

プライベート系では、「三浦海岸、海の家」といったあたりのワードで「三浦海岸：海の家：林屋」の記事参照が多かったです。

関東ITソフトウェア健康保険組合さんが発行している「TOCOTOCO」で使える海の家の利用券は「林屋」さんだけではなく、鎌倉の「一品香」さんもあります。JR鎌倉駅から京急急行バス小坪経由逗子行きに乗り、材木座で下車してすぐです。林屋さんに比べるとバスを使わないときびしい距離なので駅からのアクセスは不便かもしれませんが、遠浅でよい海でした。

我々はおととし一品香さんにお世話になりましたが、この日の帰りは江の島に行き、「たこ島」さんでおいしい海料理をいただきました。たこ島さん、テレビなどでも何度も紹介されています。土日祝日に江の島に行くと、群を抜いてたくさん人が待っているお店があるのがわかります。そこがたこ島さんです。また行きたいなぁ…行ったらこちらもレポートします。

あと、今回は検索語、というより、「浅羽由紀さん」のサイトでこんなことがありました。由紀さんのサイトでは「浅羽由紀に関するブログ記事」というのがあって、そこに10個ほど関連ブログが紹介される（自動的に取得している？）のですが、そこで一時、10個中7個がぢろーらもの記事、という異常事態が発生・・・（滝汗）。

一種のハイジャックではないか・・・（苦笑）、なんか申し訳がない気もしてしまう・・・。というか、由紀さんを応援するつもりで逆にぢろーらものほうがアクセス数稼がせてもらってるんだとしたら本末転倒じゃないか…

まあ、有効な情報を少しでも提供できるのであればそれはそれでよいのですが・・・。

では、今回もいくつかピックアップします。

clover 四葉のクローバー うんちく

ぢろーらもが最初に路上ライブをみたときの記事「浅羽由紀さん路上ライブ」が検索されました。ええ、こちらのうんちくは、四葉のクローバーをシンボルにしている浅羽由紀さんご本人から直接お聞きくださいな。きっときちんと説明していただけますよ。

浅羽由紀　評価　

「浅羽由紀さん関連活動レビュー」の検索です。おいおい、ぢろーらもは由紀さんのことを「評価」なんてできるわけないじゃないか・・・。その理由はプロデューサーのT-1さんがブログで書かれた記事、「才能を評価するということがどういうことか？」のとおり。というか、そもそもですが、「熱心なファンが多くいる」ということから察してくださいな・・・。それでもどうしても点数つけなきゃいけないんだったら、100点満点つけるわな・・・。

まあ、こちらの記事は「ぢろーらもが由紀さんを評価」という記事ではなく、「由紀さんを応援するぢろーらもの行動を自己評価」なんですけどねぇ・・・。

ipアドレス　アダルトサイト　振り込め詐欺

「振り込め詐欺、架空請求、ワンクリック詐欺」が検索されました。http://www.itmedia.co.jp/enterprise/articles/1008/04/news055.html　の記事にもあるように、ワンクリック詐欺の被害は全然減ってないみたいです。

あと、こちらはアダルトサイト関連ではないですが、http://sankei.jp.msn.com/affairs/crime/100807/crm1008072118017-n1.htm　のような中国を拠点とした振りこめ詐欺なんてのもありますし。

なにかがおかしいと感じたらまず疑い、インターネットでいろいろ調べてみれば、このブログだけでなくいろんなサイトに対処法が書いてあります。「基本は無視。連絡先を教えてしまったら最寄りの消費者センター（消費生活センター）や警察等に相談」というのが基本ですわね。

やはりそれでも被害があとを絶たない、というのは残念です。「人をみたら疑ってかかれ」というのは悲しい考え方かもしれませんが、ときにはそういう姿勢も必要だと思いますよ。

コムタンラーメン　蒲田

「焼肉山水苑：大田区：蒲田」の記事を検索していただきました。妻の実家「焼肉山水苑」では、コムタンラーメンもおいしいですよ。ディナーでも提供していますので、よろしければ一度ご賞味いただければ幸いです。

来週、けっこう多くの方がお盆休みですね・・・。だとすると、多少アクセス減るのかな・・・、そんな傾向も追っかけてみたいと思います。

---

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

---

今週の検索ワード：業務系（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」を使うこともできますが、ネットワーク機器だとそうはいかないでしょうし。

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

---

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

---