ポリシーを先に決めてからネットワークを設計すると良いぞ

この記事のモチベーション

ここのところいろいろなNOCに召喚されることが多い。
こんな風に誘われる。

• 見に来てくれるだけでいいよ

• 手を動かす必要はないよ

• なにかあったときに助けてね

• あやまるのも頼む

最後のはどうかと思うし、お金は出ないんだけど、以下のような特典があるのでホイホイ行ってしまうんだよなあ。まあ暇だしな。

• 余った弁当とかを貰えたりする

• 懇親会とかに出れたりする

• 若者が苦しむ顔を見てニマニマできる

最近は全然トラブルが起きないNOCも増えてきた。
そういうところに行くと暇すぎるので、ネットワーク図や配線図等を眺めるんだけど、わりとしっかり作っているんだよね。
ただ、なんか生真面目に丁寧に書きすぎてて、もうちょっと手を抜いたほうが良いんじゃないのか？時間は有限だぞ？、みたいに思うこともある。

ただ、今だにそもそも設計がちゃんとできてないNOCもそこそこある。
トラブルが発生したり、バタバタしてたり、見てるだけなら楽しいんだけど、そういう所に行くと、一緒に汗をかく羽目になったりもする。
本番数日前にあわててVLAN設計したり、みたいなことも実際にあったしなあ。

若者は、設計をしてみんなで情報共有する、ということがとても大事なことだ、ってのががわかってないんだろうなあ。
一人で作ってれば情報共有は不要だしね。
そして一人だと設計しなくても、なんとなく作れてしまうんだ。
共同作業って難しいよね。

いろいろ苦しんだほうが学べることは多いので、あんまり口出しせずに見てるだけ、にしてるんだけど、私だったらこうやる、みたいなことを雑にアウトプットしておこうかな、とちょっと思った。

まずポリシー(基本方針)を決めよう

若者はなぜか最初にネットワーク図とかを書きはじめるんだよね。まあ夢を絵にするのは楽しいし、それを見ながらワイワイやるのは楽しいよ。
でもその前にポリシーは作っておいたほうが良いぞ。誰かがエイヤで決めても良いし、みんなでワイワイしながら決めても良い。

このへんは作っておくべき。

• ドキュメント管理ポリシー

• ネーミングポリシー

• 配線収容ポリシー

• VLANポリシー

• IPアドレス利用ポリシー

• ルーティングポリシー

• マネジメントネットワークポリシー

• 冗長化ポリシー

• セキュリティポリシー

• アカウントポリシー

• 監視ポリシー

• ログ管理ポリシー

ポリシーを作っておかないと、担当者ごとに判断がバラバラになってしまって、組み上げたときに全然繋らなかったり、障害対応に時間がかかってしまったりするんだ。
作っておけば、全体の構造も理解しやすくなって設計も楽になる。メンバー間でもコミュニケーションが取りやすくなるし、外部にも説明しやすくなる。

お仕事でネットワークを作る場合には、上記に加えて以下も作っておくべきなんだろうけど、臨時のネットワークの場合はいらないかな。

• 障害対応

• バックアップ

• 機材管理

• ライフサイクル管理

• QoS

• クラウド連携

ちなみにJANOG52のときは、アーキテクトが不在だったので、みんなで相談してポリシーはまとめたよ↓

ポリシーの書き方

こんな風に書こう。

• わかりやすい日本語で書く

• 具体的に書く

• 短く書く

• 目的、理由もちゃんと書く

• してはいけないことも書く

• 図や表も必要に応じて使う

• 手順とかは書かない、別の文書にする

ポリシーで楽をする

こういうポリシーを書いとくと設計とか運用で楽ができるぞ、みたいもことも吐き出しておく。

VLANポリシー

実際に利用する範囲と、使っちゃダメな範囲はちゃんと書いておいたほうが良い。
使っちゃダメなのを使っちゃうとほんとに危険なこともある。

あと、VLANのIDとIPアドレスブロックは紐付けて表にまとめておくべきなんだけど、IDとIPアドレスのどこかの数字を合わせておくと、現場で混乱が減る。
たとえば、VLAN ID が xxx だったら、IPアドレスは、192.168.xxx/24 にするとかね。

イベント用のネットワークだと、以下のような複数のネットワークセグメントを利用するんだけど、

• ユーザー提供用(複数あることもある)

• サーバ用

• 機器管理用

• グローバル接続用

これらに対して、わかりやすい VLAN IDをマッピングできればしといたほうが良いかな。
ユーザー向けは100番台、サーバ用は200番台、とかね。

IPアドレス利用ポリシー

IPアドレスをどう使うか、はみんな宗教が違うので、ちゃんと明文化しておいたほうが良い。
デフォルトゲートウェイを、1にする宗教と最後にする宗教がある。
設計の前に宗教戦争は済ませておこう。

• デフォルトゲートウェイは先頭？末尾？

• DHCPは使う？使う場合には範囲は？

• ネットワーク機器が使うアドレスはどのへん？前のほう後の方？

• 参照するDNSサーバはどこ？

• 参照するNTPサーバはどこ？

• ログサーバ、監視サーバはどこ？

• DHCPサーバを置く場合のアドレスはどこ？

• IPv6を使うか

  • 使う場合にはIPv4と同じようなこと + アドレス配布方法等

このへんをちゃんと決めておくと個々のアドレス設計をするときに楽ができるよ。

配線収容ポリシー

スイッチへの配線をどうするか、も明文化しておくと良い。
これも宗教があるしね。

• 上流への接続ポートはどこ？最初？最後？

• トランクポートはどこ？

• アクセスポートはどこ？

みたいなことを決めておけば、現場で配線したりトラブルシュートするときに便利。
APを臨時で追加するようなときには、トランクポートに差す必要があるんだけど、どこに差せば良いの？、みたいなのが防げる。
まあでも実際の運用中には安全のために使ってないポートをshutdownしたりすることもあるので、どこに差せば良いの、みたいなのは完全にはなくせないけどね。

ネーミングポリシー

機材の名前付けもそこそこ宗教があるのでちゃんと決めとくべきかな。
通し番号を付けたい派閥、場所やフロア毎に番号を付けたい、機材名をわかりやすくしたい、でも短い名前にしたい、とかいろいろ考えることはある。
まあわかりやすく統一できてれば個人的にはなんでも良いと思ってる。

セキュリティポリシー

これもわかりやすい日本語で書いておいたほうが良いかな。
ユーザーからは管理ネットワークに入れないようにしておくとか、そういうのを箇条書きしておくと、メンバーへのセキュリティ意識共有にもなる。
データの取り扱いについても書いとくと良いと思うよ。

他のポリシー

最低限ここまで書いたものだけあれば、共同作業はできると思う。
まあ他のは必要なら記述でも良いんじゃないかな。

ポリシー作りや設計のために参考になりそうな資料

探したんだけど、これをまず見れば良いよ、みたいなのはなさそうなんだよね。
RFCも探したけど見付からない。
IPv4のネットワークの運用自体はもうある程度確立されてしまってるのでわざわざドキュメント化されてないのかなあ。

Ciscoがすごく沢山良いドキュメントを出してるんだけど、膨大すぎてねえ。
イベント用のWi-Fiネットワークを作るにはこのへんを読むのが一番良いのかもだけど、これも長いよねえ。

ただまあ、他のベンダのドキュメントは、ログインしないと出てこなかったりするので、やっぱりCiscoさんは大好きだ。

ちなみに、IPv6でネットワーク設計をする際には、まずこれを読め、みたいなRFCはある。

でも、まあ、長いし、むずかしいよ、、、、
とりあえずAIに突っ込んでから、、、、

アドベントカレンダー

12日目。
昨日行ったカンファレンスであれこれした技術的な雑談がとても楽しかった。そのときに、デキるエンジアから、アドベントカレンダー自由でいいですね、と言われたのよねえ。
見られてるのかあ、たまには技術的なことをアウトプットしとくかあ、と思ったので書いたよ。私もエンジニアを長くやってるけど知らないことだらけなのよねえ。なにか面白いことがあればいろいろ教えて欲しいなあ。