出張日記 栃木県矢板

転職後初の出張は地方の配送センターのようなとこへの設置作業。場所は栃木県矢板。

矢板駅からタクシーで10分弱で現場到着。敷地広い・・・別の部屋に移動するのに10分歩いた。オイオイこれ自宅から駅までの距離と同じじゃん、、などと思いながら都心じゃこの土地は得られないんだなと実感。

ある部署にお邪魔したがその部屋だけで20人くらいひしめき合って、さも忙しくもなさそうに座っている。しかも平均年齢かなり高め。これが地方雇用と言うやつか、、、と実感。

ホテルはすげーきたねーと言うより古すぎていろいろガタが来てる。ユニットバスは壊れて資材剥き出しだし、ドライヤーないし、ホント寝るだけ。

ホテルまでの間に判子屋、美容院などの前を通ったけど人通りの全く無い通りなので、どうやって生計立ててるんだろうと妙に心配というか、1日何人店にくればやってけるもんなんだろうと興味が湧く。

ちゃんとお金が回ってるからこそ、こんな田舎町にもお店があり続けることが出来るんだろうけど。

ヘビメタさん復活(ROCK FUJIYAMAとして)

惜しまれつつ終了してしまった愛すべき番組”ヘビメタさん”。

知らないうちに復活。

最近ヴィンセントのBLOG*1も見れてなったし、どうなっているか分からなかった。。。たまたま夜更かししてチャンネル回していたらどう見ても”ヘビメタさん”メンバーに”べビメタさん”的なノリ。「復活してたのか・・・」学生のように心の中で熱いものが走る・・・

番組名こそ変わっているけど、これはまさしく復活。いやー良かった良かった。GyAOで裏番組やっているし、ヴィンセントのコーナーも増えてるしコンテンツ的にはTV以外も見るもの一杯で充実している。

番組HP(テレビ東京内)
http://www.tv-tokyo.co.jp/fujiyama/
大人のロック!推進計画(ヴィンセントのコーナー満載)
http://www.tv-tokyo.co.jp/otona/

毎週チェックしちゃうよ。

あぁ、なんかこんなことに熱くなっちゃうなんて・・・まだまだ若いな俺。。。

駅からの帰り道にて

駅から自宅に向かう途中、あまりに天気が良かったから鶴見川沿いに歩いた途中に見つけた。

f:id:d_sea:20060430121248j:image:w150 f:id:d_sea:20060506233509j:image:w100

アスファルトだらけの上を歩くよりいつもと違った道をちょっと歩くだけで新鮮なものを見つけることが出来る。

ちょっと得した気分。

MXTV テクノポリス東京スペシャル を見て

最近TVからはニュースを聞ければいいくらいに思っているので、何か期待しているわけではないけど、今偶然にも出会えた番組を見て軽く興奮している。

内容は伊東穣一の話/取り組んでいること/私生活を描いているけども、確かこの人 ICANN の報告会で一度話を聞いたことがあってその話方とかが縛られてなくっていいなぁと思ったことを思い出した。で、この中で紹介している Creative Commons の考え方は結構いいなぁ。

今ネット上でコンテンツを見ることがあまり流行らないのは間違いなく著作権で縛られている/縛っているから(特に日本はひんどい)、と思っている。

そこでコンテンツの製作者が著作権を持った上で一番軽い扱い方にして、内容の一部を利用したり加工したりしてもいいよと意思表示して提供する。そのコンテンツにはCreative Commons(CC)マーク付けますよということらしい。

Joi Ito’s Web
伊東穣一 個人ページ。今番組のコンテンツが丸々見れる
Creative Commons
CCの意思表示をしたコンテンツが集まっている。まだ少ない

まだ、提供コンテンツは少ないけど、これによってネット上ではプロ/アマチュア区別なく上質なコンテンツが流通しやすくなるということ。

“放送と通信の融合”が流行り言葉ですが、言葉尻はどうでもよくってネット上でどれだけ日常化したものが流れるかだと思うので、そのための仕組みはいつか作られなきゃいけないと思っている。

ひさびさにネットの可能性とか自由な精神とかに触れられて触発されたなぁ。少し業界を離れてしまったのでちょっと飢えていたのかもしれない。危ない危ない・・・(汗

今さらながらにお礼

転職して3週間があっという間に経過してしまった。。。

この間結構バタバタとして来てしまったが、前職の方々に御礼をちゃんと言えなかったなぁと、、、

プレゼントをもらったりメッセージをもらったりして、ホントにありがたかった。

この落ち着かない環境とまだ安定することのない気持ちの中で、これらのモノがかなり励みになるとつくづく思ったりする。

だからなおさらお礼と感謝。。。ありがとう!これからもよろしゅく!

下の歯器具付け

器具を付けてから上の前歯が結構動いてきた。前歯の重なり合ってたところが並んでいるし、約1ヶ月でこのペースなら1年くらいで終わってくれるんじゃないかと甘い期待をしてみたりする。

さて、4週間ぶりに行った。今回は下の歯4箇所(前から3番目、4番目)にメタルの器具を接着剤のようなもので歯の上に固定した。まだワイヤーは張らず。

上の歯のワイヤーは一回はずして、着色した部分の研磨をしてまたワイヤーを張り直した。テンションは変えておらず、ただ、抜いた部分の間はテンションを強くしているらしい。

ん~、どういう構造しているのかやっぱり気になる。。。

次回も4週間後、次は下の歯のワイヤー張りなのかしら?次やることは意図的に聞かないと教えてくれないな。。。

本日の清算:チェック代¥5,000

今日この頃・・・

いやぁー、なんと言うか忙しい。。。というより慌しいというのと落ち着かないという感じ。

人数の少ない会社になると色々な方面でやることがあるようで、、、

とは言っても、技術的にはこれから覚えることがほとんどだしある程度まで行かないとやりたいことも出来ないと思っているので、こういう世界を見ておくのも事前の経験としてはかなり貴重と思っている。

技術的にも一筋縄では行かない現象が見れているので、折をみてメモって行こうと思う。

その前に忘れていかないうちに Knowledge of~ 運用編も書かなきゃ。

企業参謀


企業参謀 (講談社文庫)

誰かの本を読んでいてその中で薦められていた本。

この本自体は1985年に書かれていて結構言い回しとかが小難しい古い感じだが、個人的にはそれもまた考えさせるポイントになるので懐かしくって良い。

内容は企業のコンサルティング(その当時はそんな言い回しは流行ってないようだが)においてまたは自社内の課題に対して戦略的なアプローチを取るというのはどういうことか。ということを具体例もはさみながら説明してくれる。

具体的には市場規模と成長性などのデータから分析してアクションに落とし込む一連の流れの解説言った感じ。

“戦略的”という言葉は実際何?思っている/考えている方にはお勧め。自分自身もイメージできたと同時に、実践の現場ではなかなか見られない要素だということに気付く。

20年以上経った今でも十分に通じるという点ではビジネスにおける課題というのは普遍的なものなのかもしれないと感じる。

Knowledge of Internet Routing Protocols ~設計~

執筆中・・・

設計

BGP

  • iBGP ではフルメッシュ peering が必要だが、複数台存在する時点でルートリフレクタ(RR)を用いる</p>
    • peerの本数が減らすことが出来るのでルータの負荷軽減につながる
    • 複数 RR を置いている場合は同じ Cluster ID を付ける*1
      • 同一 Cluster ID は同一経路情報を破棄するため、RR 同士は差分の経路情報のみをやり取りできるので負荷軽減につながる?
  • eBGP 受信経路への LP/MED は接続形態に沿って
    • LPで大まかに優先度を決めて、同じ LP のもので AS-path 長で比較したい時に MED で差をつけるなど、大まかな優先度は以下</p>
      1. private peer
      2. public peer
      3. upstream
    • 実際には複数本存在したりその間での優先度の決定やトラフィック量の調整のために prefix 単位で制御する場合もある
  • nexthop-self の活用
    • iBGP に対して行う時は peering アドレスがどのルータに接続されている分かりづらいので、見やすくするために有効
    • nexthop が peering address のままだとそこまでの到達性が BGP のみになるので、loopback address にして IGP で到達性を確保する意味もあり
      • 実際は peering アドレスは OSPF に載せて、IGP としても保持しておく
    • eBGP では1ルータで複数 peering している時に peer 先に対して誤った nexthop を広報しないようにする意味で有効*2
  • MD5 password の活用
    • セキュリティの観点から全ての peer に適用するように推奨されている

OSPF

  • Area0 にいくつまでルータが置けるか</p>
    • ルータのスペックにもよるが、厳密な推奨台数は無いためやってみてが多い</p>
      • 1996年の文献では40~50台のルータが経験上、上限だといっている*3
    • LSDB がどこまで大きく出来るかにつながるので無駄な肥大化は避けたい
    • 地方拠点/edge 部分など役割と拡張性もみてAreaを切ることか可能なことが明確な部分にはには設ける
  • DR/BDR への意識
    • 複数ネットワークをルータが接続している場合、DR/BDRがかぶらないように、prorityで調整(実際には neighbor を張る順番にも依存するので必ずしも有効ではない)
    • メンテナンスの少ない or 上位ルータを DR/BDR にする
  • cost
    • interface の帯域や NW構成の階層でシンプルに決める
    • 距離感をそのまま反映したい場合は type1 を用いる
    • type 1/2 の混合は混乱しやすいので避けたい
  • default route の広報
    • 障害時を想定して上位のルータから default route を OSPF にて広報する
    • 広報するルータは全ての宛先がわかるという意味でフルルートを保持しているものにする

全般的に、、

  • 設計ポリシーはシンプルに、例外はなるべく少なく
  • protocol distance/route preference の意識を常にもつ
    • メーカごとに異なるので注意する。OSPFとBGPの優先度など
    • BGP経路に乗せていても広報できていない場合があり
  • 障害時のトラフィック迂回時を想定する
    • このポイントが切れたらここに回るを把握する</p>
      • eBGP と IGP 両方の場合について
    • 2次障害を加味してはきりが無いのである程度であきらめる

Knowledge of Internet Routing Protocols ~概要~

今後ルーティングプロトコルをガシガシ使うことがなくなると思うので、忘れていかないうちに自分のナレッジのメモ

あまり運用上使わない部分は削ってしまうことにする。

追加項目/ご指摘大歓迎

現在執筆中・・・

ルーティングプロトコル概要

BGP
AS間で用いるルーティングプロトコル、社外ISPと共通して用いる唯一用いるプロトコル
IGP
AS内部で用いるルーティングプロトコル
    • OSPF
    • RIP
    • static
    • etc.
BGPとIGPの関係
IGPのルーティングテーブルを用いてBGPセッションが成り立つ。具体的にはリカーシブルックアップのようにBGP経路のNexthopへ到達するためにはIGPのルーティングテーブルを参照することが通常であるため

BGP

eBGP
  • interface address 同士でのダイレクトな peering が通常
  • AS 間には peering を行う小さなネットワークが存在 (private peer なら /30、IX peering なら /24)
  • AS 間における BGP 運用責任はtransit 提供などのサービス提供形態以外は対等、損害賠償もない緩やかな覚書を結ぶ程度(覚書を結ばないISPもあり)
iBGP
  • loopback address にて peering</p>
    • バックボーン内は複数ネットワークにて冗長性を確保している場合が通常であり、interface address に依存しない peering が可能

BGP のトラフィック制御方法

上りトラフィック制御方法(origin AS から external 行き:出し)
  1. Local Preference
  2. AS-path長
  3. MED (上書き)
下りトラフィック制御方法(external AS から origin AS 行き:入り)
  • Prepend (AS-path長)
  • MED (external からの経路情報より)
その他の制御方法
  • community</p>
    • 色づけ(それ自身では制御は行わない)、fliterで引っ掛けて LP/MED などの制御を実施する
    • origin AS の経路、border ルータ、customer AS、external AS などを識別するために経路情報に付与する
  • eBGP multi hop
    • 複数ネットワークをはさんだ状態でpeerを張る
    • neighbor address への到達性は static を切って確保する必要がある
    • 同一ルータで複数回線接続する場合にはロードバランスが可能
      • この時ループバックアドレス同士のpeerが通常
  • multi path
    • best path 選択の際、最後のクラスターIDまで落ちずに手前の段階で同コストとして選定する
    • 複数本peerを張っている場合にはロードバランスが可能