JANOG20 Meeting Log. #1 (2007.07.12)

ちょっといまさらな感じが大きいですが、JANOG20 ミーティング 1日目 (7/12) のメモ

http://www.janog.gr.jp/meeting/janog20/program.html



1. Operators' Life with no-Sampling Flow Data (10:55- )

    • flow を扱う理由
    • コレクターの ASP モデル
      • 使ってみて...
        • sampling では出来ない攻撃検知に対応
        • 傾向分析の過程からフルキャプチャへ移行が可能
      • まとめ
        • PDCA (plan-do-check-act) サイクルに乗せていきたい
        • 箱モノ、自動化は人が循環型サイクルを運用するサプリメントのようなもの
        • ホスティングやサイト運営をしているハウジングユーザ向けのオプションサービスとして使えるのではないか...
        • データの受け渡しについては要検討
        • 利用性は ASP の形式でも気にならない
        • 対外接続のオプションのような感じだとうれしい


2. 高速な障害復旧に必要な思いやり (11:55- )

    • 極端な性能差のルータが網内にたくさんあったら、どういう障害検知の方法が良いのか
    • 極端な性能差の BGP ルータが暴れだしたら...
      • ピアダウン <-> ピアアップ を繰り返してしまう
      • keepalive/holdtimer は default で、経路がやさしく切り替わるルータがほしい
    • BFD は使わずに、icmp で断検知をする
      • icmp は、相手がサポートをしてなくても良い
      • icmp は、シングルホップであれば OK
    • RR にプローブをさせる
      • icmp で障害を検知したら、BGP に何をさせるか？
      • route-map で、attribute を変更して広告をする
      • keepalive/holdtimer は default のままにしておき、ピアを上げたままで BGP メッセージは最小にする
    • トラフィックの経路とプローブの経路
      • BGP ピアと icmp の経路はおなじにする必要がある。断が検知できなくなる。
      • far-end サイトの断は BGP で検出が出来ない
    • まとめ
      • RR で経路の attribute の変更をする事は面白い
        • 本来は RR で attribute の変更をする事はだめだけど...