Hatena::ブログ(Diary)

mmasudaのはてな日記 このページをアンテナに追加 RSSフィード

[告知]

月曜深夜-火曜の(日本時間)ESPN Sports Center USA を元にもどしてくれ!という呼びかけを行っています。NFLファン・アメフトファンの方是非 J Sportsの問い合わせ窓口より適宜抗議&要望を送信しましょう!

[注意]

  • こんな チラシの裏 みたいな ページに有益な情報がある訳がありません。2次3次情報に頼らず、まずはマニュアル/ソースコード/規格書/RFC/代理店/メーカ等に問い合わせしましょう。
  • 当日記は個人的な見解を述べものに過ぎず筆者の所属・勤務している団体の見解とは一切関係ありません。
  • 当日記の内容を実行したことによる損害等に関しては筆者は責任を負いませんので、読者自身でご判断願います。
  • 当日記は、筆者の日常の全てが記述されているわけではありません。また予定は全て未定です。
  • リンク・コメント・トラックバックはご自由にどうぞ。但しコメントおよびトラックバックは当日記の筆者が適切でないと判断したものは適宜事前事後の通告なしに削除します。また"自動化ツールによるトラックバックスパム"と思われるものに付いては削除した上で晒し上げますので、晒し上げられても問題ない方だけどうぞ。
  • 当日記には「linkを張っているだけ」という記事が多々ありますが「linkを張っているだけ」と言う状態はあくまで「linkを張っているだけ」というだけでそれ以上でも以下でもありません。勘違いしないでください。
  • リンク先にはまれに職場等で開くには不適切なリンクがある場合がありますのであらかじめご注意ください。
  • NFLの試合結果等は国内TV放映のスケジュールを配慮せずにどんどん書き込む方針ですので、「結果をいち早く知りたくない人」はお気をつけください。 っつーかNFL GAME PASS HDで高画質ネット生中継ぃぇぃ。
  • "たのみこむ"でNFL国内放送の充実!というリクエストをやっております。NFL GAMEPASSで要望の大部分は満たされつつありますが、まだ完全に満たされていない点も多いので是非投票のほどよろしくお願いします。
  • Kevin Matthews(matthews@artifice.com)氏がFlash Player のFreeBSD 対応について 署名を募集 しているようです。
  • "これはひどい" アイコン を導入しました。[これはひどい]というエントリがありましたら容赦なく"これはひどい" 追加アイコン width=をクリックしてください(参考link その1,その2)。
  • "これはひどい" アイコン は"スター"でも"拍手" でもありませんので、そのような使い方は止めてください。あくまで[これはひどい]と思われるものだけクリック願います(特にひどい箇所を範囲指定してからクリックすると参考になります)。
  • イスラエル・パレスティナ及び関係諸国は今一度オスロ合意の原則に立ち戻り、対話・和平・和解のプロセスへ立ち戻るべきである。
  • パケットの気持ちになって考えよう。:-)

2009-07-05 秋葉原散歩したりする週末

[] 現在契約しているISPと関係なく使えるIPv6トンネルサービス(有償・無償)まとめ  現在契約しているISPと関係なく使えるIPv6トンネルサービス(有償・無償)まとめ - mmasudaのはてな日記 を含むブックマーク  現在契約しているISPと関係なく使えるIPv6トンネルサービス(有償・無償)まとめ - mmasudaのはてな日記 のブックマークコメント

この情報はかなり古い可能性があります(2013/12追記)

2013年になってSNS/Twitter などでたまに拡散しているようなのでこの項目追加しました。

2013年の今ではすでにNTTやKDDIでIPv6サービスを正式提供しているのでそちらを使うほうがいいと思います。

はじめに

テキトーにまとめただけ、追加情報・訂正情報歓迎。

ちなみに個人的にはOCN IPv6 とFreeBit Feel6 を現在利用中です。

OCN IPv6

Tokyo6to4.net

FreeBit Feel6

Freenet6

(7/6追記) SixXS

(追加情報希望)

(7/6追記) Hurricane Electric Free IPv6 Tunnel Broker

(追加情報希望)

(7/6追記)Wikipedia にまとまっている件について

http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers

(2010/8/6追記)

ソフトイーサ株式会社及び筑波大学システム情報工学研究科産学間連携推進室によるグローバル・固定 IPv6 アドレス割当型トンネル接続実験サービス

PacketiX VPN Client を用いたトンネル接続Linux いけるらしい。

tomochatomocha 2009/07/06 02:31 http://wiki.tomocha.net/ipv6_tunnel.html

こういうのもつくってたりするすよ。

1981032219810322 2009/07/23 02:16 Feel6というかDTCPについてはYamahaのネットボランチ系が対応してます。ご参考まで。

v6難民v6難民 2009/09/02 17:11 SixXSはRTT:100ms以上だとPOP割り当てないよんと途中でポリシ変更されたので、もう日本から申し込むのは実質不可能かも

2009-05-26 思わず更新してしまった一日

[][] "「IPv6家庭用ルータガイドライン(0.9版 2009年5月22日発行)」パブリックコメント開始" に脊髄反射  "[http://www.v6pc.jp/jp/entry/wg/2009/05/ipv609_2009522.phtml:title=「IPv6家庭用ルータガイドライン(0.9版 2009年5月22日発行)」パブリックコメント開始]" に脊髄反射 - mmasudaのはてな日記 を含むブックマーク  "[http://www.v6pc.jp/jp/entry/wg/2009/05/ipv609_2009522.phtml:title=「IPv6家庭用ルータガイドライン(0.9版 2009年5月22日発行)」パブリックコメント開始]" に脊髄反射 - mmasudaのはてな日記 のブックマークコメント

なにこれ。

NAT(IPv6toIPv6 & IPv4toIPv6)の類がまったく触れられていないのはなぜ?

IPv4しかしゃべれない家電とか世の中にどれくらい出回っていると思っているんだ。

あと"ISPが変わったら or ISPが配るアドレス変えたら宅内LANのアドレスも変わる"なんてポリシーを全員に押し付けられると思っているとかもうね。

このSWGでは、インターネット利用者がスムーズにIPv6環境の利用が可能になるように

っていう看板をもう一度見直した方がいいんじゃね?

というわけで、家帰ったらもう一度見直してパブコメ出す。

お断り(あるいは標準エチケットペーパー)

あまり深く読んでないので読み間違い・勘違いの類があるかも知れず。ご指摘頂ければ助かります。

5/27追記

以下内容で出した。

=================================================
「IPv6家庭用ルータガイドライン(案)」への意見

所属:notwork.jp
氏名: =禁則事項です=
連絡先(E-mailアドレス):mmasuda@以下省略

※意見については、対象の箇所毎に下記のフォームに
 則ってお送り下さい。
※締切は2009年6月3日(水)になります。
※提出先アドレス</a> v6hgw-comment@v6pc.jp
------------------------------------------------
        意 見 内 容
対象ページ:全般にわたって

該当文言:全般にわたって

意見:
理由:(分離して書くと論旨が分かりにくくなりそうなのでまとめます)

その1)
IPv4でしか通信できない機器(特に家電など)の対応についての不備が
著しい。
暗黙で家庭内LAN環境が
"IPv4/IPv6デュアルスタックネットワーク"
あるいは
"IPv6で通信する機器しかない前提"
であるのであればそのことを明記すべき。
もちろん私個人の意見としてはIPv4でしか通信できない機器(特に家電など)
をIPv6経由で何らかの技術を用いて通信出きるような実装を当文書において
推奨すべきであると考える。


その2)
NAT(IPv6toIPv6 & IPv4toIPv6)の類がまったく触れられていない。

- IPv4ネットワークでのNATの効能にユーザの大多数がなれている
- 特に現在では家庭内LANにおいてサーバの役割を行う機器(家庭内NASや家電等)も増えている

上記2点から
"ISPが変わったら or ISPが配るアドレス変えたら宅内LANのアドレスも変わる"
という"ポリシー" を全ての家庭内LANユーザが受け入れられるとは考えにくい
と考える。
また経済的理由で家庭内LAN環境をIPv4のまま留めておきたいユーザもいるだろう
(現在のWindows9x/2000,Classic MAC ユーザの割合を想起せよ)。

"ISPが変わっても"あるいは"ISPが配るアドレスが変わっても" 宅内LANのアドレス
体系を固定できるような仕組みの実装(おそらくNATだと思うが)を当文書において
推奨すべきであると考える。


/以上

当該SWGのメンバー眺めていたら面識ある人いるのよねぇ……。これくらいのことは分かっていて、しかし入れられなかった「何か」があるのかと勘ぐってしまう。どうしても。

User unknown

The original message was received at Wed, 27 May 2009 08:30:20 +0900 (JST)
from *.notwork.jp [2**.***.***.***]

   ----- The following addresses had permanent fatal errors -----
<v6hgw-comment@v6pc.jp>
    (reason: 550 5.1.1 <v6hgw-comment@v6pc.jp>... User unknown)

   ----- Transcript of session follows -----
... while talking to mx.v6pc.jp.:
>>> DATA
<<< 550 5.1.1 <v6hgw-comment@v6pc.jp>... User unknown
550 5.1.1 <v6hgw-comment@v6pc.jp>... User unknown
<<< 503 5.0.0 Need RCPT (recipient)

もうね(ry。

5/29追記

メール出し直した。とりあえずエラーメールが即跳ね返るというのは無い模様。

うめのうめの 2009/05/30 02:30 うめのともうします。
確かに本文中にはNATの話は出てこないのですが、
リファレンスに
[12] NAT66 IPv6-to-IPv6 Network Address Translation
が出てくるところが気になります。

2009-01-17 RSS未読消化するだけの一日

[] yimg.jpをつかうたった一つの理由  yimg.jpをつかうたった一つの理由 - mmasudaのはてな日記 を含むブックマーク  yimg.jpをつかうたった一つの理由 - mmasudaのはてな日記 のブックマークコメント

答え: トラフィック削減

img.yahoo.jp とかにするよりも

  • yahoo.co.jp のコンテンツ内にかかれているイメージソースを示すURL の文字数がimg.yahoo.co.jp なんかよりyimg.jp の方が圧倒的に少なくなり数バイトとはいえコンテンツ量の削減になる
  • 負荷の高くなるイメージサーバのhttp リクエスト中のHost: 文字数が7bytes で済む

巨大サイトだと数bytes でも削れるとチリも積もれば何とやらで、効果は出るんでこういう地道な削減でも意味がある。多分Yahoo 担当者は本当は最短の3文字ドメインにしたいんじゃないかと妄想。当然下のリンクの方々が語っている効果もあると思うけど、トラフィック削減のために別ドメインにするための、おもにコンテンツ製作サイドを納得させるための、方便の一つでしょう。

まぁ本気出すなら、2ch.net がやっているようにCR+LFも極限まで削除とかやればいいとは思うがまぁ多分現場が泣くからなぁきっと。

関連)

2008-12-06 某方面焼肉忘年会な一日

[][] IPv4アドレス不足で起きる嫉妬  IPv4アドレス不足で起きる嫉妬 - mmasudaのはてな日記 を含むブックマーク  IPv4アドレス不足で起きる嫉妬 - mmasudaのはてな日記 のブックマークコメント

おまえら本当に6万5000個ものグローバルIPアドレスが必要なの?使ってるの?

年に/8 を10個以上IANAプールから払い出している現状でたかが/17位返却して何の役に立つの? 時間と人的資源は有限なんだからもっと別の問題に使わない?あとまさか/22-24 あたりの細切れでもいいから返却しろとか言わないよね?CIDR理解してる?

まぁIPv4アドレスの問題は"資源配布の最適化問題"なので"たくさん持っているように見える"人・団体に対してなにか言いたくなるのは分かるけど、記事中にあるように「適切な運用ルールに基づいて配布されているもの」だし、なんか「あいらたくさん持っていやがって」という持たざる者が持っている者に対する羨望・嫉妬・やっかみにしか見えない(言い過ぎ?なんというか「嫌儲厨」とかぶるものを感じるのは私だけですかね。

あと個人的には、昔にクラスレスルーティングできないようなルータをいじったこともある経験もあるので/16で配布してもらわざるを得なかったという時期は確かにあったのを経験しているというのもあるかもしれん。

クラスフル前提で設計したネットワークを、アドレス利用的に最適化したネットワークに再デザインし直して実装しなおすとかあまり考えたくないね。まぁ3-5年がかりでゆっくり移行するっていうのなら不可能じゃないだろうけど。

ちなみに私が過去にネットワーク管理者していた某社がクラス/16持っているという風にリストに出ているけど、ワシが当該企業のネットワーク管理者だった頃は/22 しかなかった*1ので、おそらくわしが退社した後に合併とかあったのでそれで合併した会社から継承したのだと思われ。

まぁ本当に真面目にここらへんの「問題」を議論したいなら、最低限IP USERS MLに入ってオープンポリシーミーティングにも参加してね(はあと。できればAPNIC Meetingで直接議論出来るくらいに問題に精通して政治力発揮できるようになってください(爆笑。あ、あとJANOGで騒ぐのは不可な(藁。

*1ちなみにNAPT導入する直前にはかなりアドレス不足気味に陥ったという記憶がある。個人的直感だが、端末台数の5-10倍くらいのアドレスレンジが無いと余裕のあるネットワークデザインは困難じゃ無いかという気がする。

2008-11-04 日程調整とかしている一日

[][] フォローアップ:いい配線工事業者と仲良くしましょうマジで  フォローアップ:いい配線工事業者と仲良くしましょうマジで - mmasudaのはてな日記 を含むブックマーク  フォローアップ:いい配線工事業者と仲良くしましょうマジで - mmasudaのはてな日記 のブックマークコメント

いい配線工事業者と仲良くしましょうマジで - mmasudaのはてな日記 がそれなりの反響をいただいたようなので、いくつかフォローアップがてら少し書くつもりが長くなってしまった(滝汗。

はてブより(その1)

id:kurihara99 さんより

ケーブリング関係の書籍ってほんと無いので、紹介されてる本は助かります。原著「Premises Cabling」は2005年版があるのか…、買うか。

この手のケーブリングのベストプラクティスの載っている本って見かけない&評判を聞かないのでノウハウが勢い口伝になりがちですよね。

Amazon をたぐってみたら、比較的最近出版された本では

LAN設計施工マニュアル (現場実務シリーズ)

LAN設計施工マニュアル (現場実務シリーズ)

こんなのがあるみたいですが、どんな感じなんでしょうね。流石にバンバン何も考えずに本を買えるほどお金持ちじゃないので出来が知りたいところ。

はてブより(その2)

id:Harnoncourt さんより

パッチパネルって絶対に必要ですかね?ラックごとにSW-HUB搭載しちゃえばパッチパネル要らずだし、何かと便利。ラック単位でネットワークセグメントを振り分けると、綺麗に管理できます。

サーバー群収容ラック-ネットワーク機器収容ラック間のことと仮定します。

ラック単位でネットワークセグメントを綺麗に分けられ続けられればいいんですけどね。個人的経験から言えば必ず"例外的なサーバ" というのが入ってくるもので、その時に"これは確かに一台だけだけど、別のセグメントだから別のラック建てないと" と上司に主張することできますか?(遠い目。多分"このラックのこのスペース開いているだろ"と突っ込まれて発注願いを握りつぶされるのがオチだと思います*1

ということで、サーバー群収容ラックには複数のセグメントが収容できるように事前にサーバー群収容ラック-ネットワーク機器収容ラック間に数本配線してしまって構成変更・追加に柔軟に対応できるようにしておいた方がいいと思います。

UTPケーブル6本(24ペア)をまとめられるバルクケーブル*2というのがありますから、この手のケーブルを1本できれば2本つかって6-12ポートのパッチパネルを事前配線するという感じでしょうか。こうしておくことで"ケーブルがおかしいのか一応切り分けなければいけない状況"のときにパッチを弄るだけですぐに切り分けが出来るという利点も手に入れることができます。

はてブより(その3)

id:morihachitoraya さんより。

良記事。島Hubはほんと無くしたい。セキュリティリスクと工事費用を天秤にかける愚かな経営陣は(以下ry

"島Hub 使用=セキュリティ低い" ではないと思います。例えば

  • 1-2Uの機器が入って鍵のかかる配線BOX*3に島HUBスイッチを入れる.
  • 上記配線BOX の鍵は適切に管理する
  • 上記配線BOX をテーブルの島ごとに配置
  • 島HUBスイッチの未使用ポートは明示的にShutdown する
  • 認証LANなどの機構を使い認証されない端末の接続をされないような設計にする

これだけやっておけばそんなにおかしいことにはならないでしょう。

島HUB 使用で一番問題なのはメンテナンスの面です。フロア向けパッチパネルとハブが集約されている環境(スター型配線としましょうか)であれば、例えば特定のLANの口がおかしいときに、別の口につなぎ替えて対処することは容易ですが、島HUB使用時には"島HUBのところまで行って対処しなければいけない" でしょうし、もしHUBが一つ故障になったときには、前述のスター型であれば、他のHUBの未使用ポートに緊急につなぎ替えて対処した上で代替機と交換が必要かどうかゆっくり調査することもできますが、島HUB環境ではいきなりとっかえる他に手がありません。

むろん島HUBにも利点が無いわけではなくて使用するケーブル量が圧倒的に少なくて済むという利点があります。あとは100m のLANケーブル制限に引っかかりにくくなるという設計上の利点もあります。

そこで、技術的なテクニックというよりは政治的なテクニックですが、引越しフロア移転新設などの時には必ず内線電話の工事も入るはずです。そこでフロア向けLAN工事(ついでにマシンルーム内工事も)を一緒にやってもらうようにしてしまうのです。その際に統合配線にしてしまうように工事屋さんと共謀しましょう。これに限ります。:D

はてブより(その4)

id:omayaさんより

関連: LAN配線をきわめる 日経NETWORK 00.06より http://b.hatena.ne.jp/entry/10518412

タレコミありがとうございます。個人的にはここにかかれていること常識だと思いたいですね*4

LANケーブルの色分けについて

私の記事に対するレスポンスでは無いでしょうが、いいタイミングの記事だったので取り上げたいと思います。

私はセグメント別というかセグメントの重要度別ですね。

  • 重要なケーブル: サービスに供されていて基本的に弄れないセグメント
  • 重要じゃないケーブル: メンテ用の裏セグメント等別にどうにかしてもいいセグメント

を分けるという感じ。上にプラス "クロス用ケーブルの色" を用意するという感じか。

あまりケーブルの色使うようにすると大量に発注する時にメーカー在庫が足り無くて入荷待ち*5とかになって馬鹿らしいのであまり分けない方が実務上はいいと思う。その意味では

上記三つは "使用する色の数の爆発" がおきかねないのでやらないという感じ。

以下他についてコメント。

  • 【5. LANケーブルの品質別】

CAT5/5eベースでやってきていて10GbE の導入を部分的にやらなきゃいけないとかそういう時には、古いグレードのケーブルを流用されないようにやる意味はあるのかな。

ただ品質を気にするならそもそもパッチケーブルとかあまり使いまわすものじゃないと思う。本質的には。

  • 【6. LANケーブルの長さ別】

"施工されたケーブルがどんな長さのケーブルか後から一目で分かるようにしなければいけない"ということ事態が、パッチパネル/ローゼットを全然活用できてない配線になっている可能性が高い。

ラック間をパッチパネル=バルクケーブル=パッチパネルで接続するようにして、ラック間を跨ぐケーブルをわざわざ引っ張らなくてもいいようにすれば使うケーブルは精々1m〜4m のものくらいで済むはず。ってことは2種類-4種類くらいのケーブル種類があればいいわけで色分けする必要まで歩かね?という感じ。

ぶっちゃけ"LANケーブルの長さ別" 管理しているところは配線設計ミスの可能生高いんじゃねって気がする(断言。

いや一度本当にこの管理手法やっている組織で働いたことがあったんだけど、アレはひどかった。配線設計おかしいんじゃないかという旨をそれとなーく上申したら「お前は何も分かっていない」的に言われたしなぁ

  • 【7. あえて色分けしない】

実はこれでもいいだろうというのが私の立場。以前も書いたように

いい配線設計の最低条件は、ケーブル/パッチパネル/ローゼットの番号を追っかけるだけで物理的接続がどうなっているか追える設計だと思う。むろんケーブル接続台帳みたいな管理も必要だけど"(命名規則等に)慣れればケーブル/パッチパネル/ローゼットの番号を見れば行き先がどこになるのか分かる"というのが理想。

ということなのでケーブル/パッチパネル/ローゼットの番号付けをしっかりやることが肝要だということで。

その意味では"ケーブルの色分けなんて大して意味は無い" ということかもしれない。大胆な結論かもしれないけれども、ケーブルたぐらなきゃいけない時にはケーブルの色なんてメタ情報を活用する・役に立つ機会があるのかというという気がするので。

コメントより

id:hikitaさんより。

運用を考えずに、なんでもやる人が多すぎます…

この分野においては "LAN配線なんて宅内LANとたいしてかわらんだろ?量が多いだけで" という無知とどう闘っていくかそれが一番大きいのだと思います。

規模が大きくなれば別のノウハウが必要になるということをまずは理解させないと。これはIT分野全般に言えることかもしれません

どうでもいいけど

AMPとかのケーブル・パッチパネル業者のカタログみてると楽しくてしょうが無いのは俺だけじゃないですよね。BlackBoxのカタログとかも"こんな変態コンバータあるんだ"とかおもしろいよね(ぉ。

*1:そうじゃなくて"よしじゃラック建てるか!" という上司がいたらそれはそれでコスト感覚を疑います。私ならば

*2:例: カテゴリー6 24ペア UTPケーブルのようなケーブル。

*3:例: こういうのとか。

*4常識だと思っているので前の記事でもわざわざ書かなかったという

*5:とはいえ昔と違ってケーブルメーカ様も頑張ってラインナップ揃えていらっしゃいますが。

2008-10-21 フットボールの神様の気まぐれに戦慄した一日

[] いい配線工事業者と仲良くしましょうマジで  いい配線工事業者と仲良くしましょうマジで - mmasudaのはてな日記 を含むブックマーク  いい配線工事業者と仲良くしましょうマジで - mmasudaのはてな日記 のブックマークコメント

"LAN配線は意外に奥が深いものです。"を観てだらだらと思うところを書いてみたら長くなったので、ちょっと個別記事にしてみる。まとまってないけど。

マシンルーム・データセンタ内

ラック間を跨ぐケーブルの本数をパッチパネルとバルクケーブルを駆使して相対的に本数が少なくするように設計するのが鉄板です。ラックに機器を入れる前にラック間を跨ぐ本数を(予備+増強分含め)割り出して、パッチパネル&バルクケーブル敷設工事することが肝要。

間違ってもラック間を跨ぐケーブルが数十本単位になって床にケーブルをとぐろを巻く何ていう事態は発生させないように。それは敗北を意味します。

大抵混乱を生み出すのはラック間を跨ぐケーブルなので、一応サーバ収容ラックのラック内で完結するケーブル配線は別と考えていいのかな、と。メタルなLANケーブルを電力ケーブルと一定の距離をとるとか、ケーブルのせいでラックのドアが閉められないのを防ぐとかその程度のことはまぁ当たり前のことだと思いたいです。ラック内配線管理についてはラック管理図なりラック内配線管理図を作っておくのはまぁ言うまでもないかと。

フロア向け

フロア向け配線に関しては、まぁVLAN使えるスイッチとパッチパネル/バルクケーブル/ローゼットを駆使すればパッチケーブルをぐちゃぐちゃやらんで済むでしょ?でファイナルアンサー。引越などで新設するのであれば、どうせ内線電話の配線もやらなきゃいけないはずなんだから統合配線の導入も検討しましょうね。:D

へ?島ハブ?そんなメンテナンスが面倒くさくなる概念は窓の外に放り投げてください。マシンルームの中に置く余地が無いなら鍵かけたラックを配線ボックスというかたちで部屋のどっかに置くという策で一つ(停電と冷却対策に注意)。

あとはケーブル事故(断線)や不意の増設に備えて、未使用のローゼットをいくつか床の中に埋めておきましょうね。絶対に役に立つときが来ます。

……面倒くさいから全部無線LANにしたぜ!という豪快ソリューションをとろうと思うときは

  • そもそも使用アプリケーションが無線の細い帯域に耐えるのか
  • 1APにぶら下がる最大端末数と想定帯域を見越したAP配置&電波強度設定
  • 無線区間の暗号強度と認証
  • 混信対策*1
  • 電波漏洩に対する考え方*2

等々という点に留意。

まぁなんというか

いい配線設計の最低条件は、ケーブル/パッチパネル/ローゼットの番号を追っかけるだけで物理的接続がどうなっているか追える設計だと思う*3。むろんケーブル接続台帳みたいな管理も必要だけど"(命名規則等に)慣れればケーブル/パッチパネル/ローゼットの番号を見れば行き先がどこになるのか分かる"というのが理想。というかこれが出来てないと物理系トラブルシューティングに苦労するので手を抜くべからず。

バルクケーブル&パッチパネル駆使するということで配線工事業者に払うコストが出るけれども、そこをケチらないこと肝要。

……まぁ何社か転職しているけど、上記がきちんとできているところも多いけど出来ていないところもまた多い。規模がある程度でかいところでいい加減だとまぁ最悪ね。

上記で何を言っているか理解できない"ネットワーク管理者"の方々へ

えーっと物理配線工事関連の勉強した方がいいですよ。真面目な話。ジョブセキュリティ確保のためにあえてやっていないというなら別にいいですが。

わしが勉強した頃にはリックテレコムの『LANケーブリング ベーシックマニュアル』(ISBN:4897974364)くらいしかまともな書籍*4が無かったと思うけど今なら上記ノウハウくらいを網羅している本はあるんじゃないか?ないかもしれんが。いい本あったら教えて(これが一番書きたかったらしい)。

まぁノウハウはあっても実際に詳細設計と工事するのは配線業者だという話もあるけど、業者にいい仕事をさせるためにはやっぱり発注側があるていどは知識を持つことが(どの分野でも)重要だよねってことで。

追記(10/22)

複数のUTPケーブルを製線する際は別のケーブルからのエイリアンクストークノイズの影響受けやすくので実は綺麗に水平に製線しないほうがいいとか端子部分での反射ノイズの影響があるのでパッチケーブルは2m未満にしてはいけない*5とか、GbE/10GbE時代の規格上の制限とかがあるはずなのでそこら辺まとまっている本無いですかねぇという感じ。WEBでもいいけど。

*1:量販店で買ってきた無線LAN AP を同一or隣接チャンネルの設定で電源on した瞬間にスループットが落ちる原因になる。それをやるのが社内の馬鹿野郎なのか隣のフロア・建物の赤の他人なのかは知らんが、そういうリスクもあるということをどう考えるかということ。

*2:いくら暗号をかけようが、フロアを簡易電波暗室並に改造でもしない限り"あのフロアで無線LANを使っているらしいという情報"は漏れると考えるべき。そのリスクをどう考えるか組織として結論を出しておくべき。

*3関係ないけどADSLの導入に当初NTTが頑強に反発した一つの原因は局舎内配線管理が煩雑になるという点が絶対あったと思う。

*4:それでもまだ足りない部分はあった。

*5: 参考: パッチコードの長さ

hikitahikita 2008/10/24 12:40 よくわかります!
私も、現在社内SEでファシリティ関係も担当していますが、
私が入社したときは、えらい状態でした…。
発注側も絶対に知識をもつべきだと思いますね。
物理セキュリティが弱かったら何も意味ないですし、
運用を考えずに、なんでもやる人が多すぎます…

2008-07-31 デジカメ持って駆けずり回っていた一日

[][] Proxy負荷分散とか  Proxy負荷分散とか - mmasudaのはてな日記 を含むブックマーク  Proxy負荷分散とか - mmasudaのはてな日記 のブックマークコメント

■アクセスごとにIPアドレスの変化するISPは存在するのか

はてブでコメントしたけど一応捕足。

(企業ネットワーク等で)proxy複数台で何らかの手段で負荷分散しているケースならいまでも普通にありうる。

何らかの手段の一例

(参考: 2ch通信技術板:プロバイダ各社の proxy auto config を比較してみる)

あとは似たような処理をL4-7スイッチつかってやるか。まぁまともなネットワーク設計者がいればproxy への負荷分散振り分けをsession by session でラウンドロビンとか別々のキャッシュサーバに振り分けるとかそういうことは極力しない*1でしょうがね。そうとは言いきれないのが(ry。

あとは余談だけど。

あとは今話題のCarrier Grade NAT とかが導入されたりしたら以下略

Carrier Grade NATISP が導入するとしたら全Protcol をNAPT するのではなくてL4-7スイッチ使うなどしてHTTPだけは透過的キャッシュを通過するような実装を選ぶところもあるんじゃないかと思う*2

*1:何のためのキャッシュだか分からなくなるから。もっともクライアント台数が莫大に大きい組織だと分散度合いを増やすために苦渋の選択として選ぶ可能性もあると思う。

*2:というか機器をたくさん売りつけるために色々理由をつけてそういう提案をする業者が以下略