1.タイトル　「最近のBGP ○○編」　

2.発表者
　吉田 友哉 [NTTコミュニケーションズ株式会社]
  松崎 吉伸 [株式会社インターネットイニシアティブ]

3.ロガー　NTT-Com新井 沙知音

4.発表日　2004年1月30日（金）13:00〜14:00
 
5.発表の焦点・論点・議論
　　現場で発生した不可解な事象について対応策を踏まえ情報共有を図る。
    BGPオペレータが増加したことにより、それぞれが抱えている悩み等につい
    ても共有化し解決策を見出せることが目的。

6.発表の流れ
�@「そりゃないよ編」
- 経路が聞こえてこない理由は何故か？(担当：吉田)
  - ユーザやPeer、Upstream等の経路の使い分け
  - ユーザは最優先させ、他についてはポリシー次第である
  - 優先度を間違えると経路が広告されず、特にユーザ兼Peerしてると、
    トラブル時にCommunityを利用の場合にユーザ経路がベストのはずだが
    Peerがベストになっていると，広告されなくなってしまう
    - 会場に質問「communityを利用している人？」
      - 1割程度が挙手（聴講者の割合から約3割程度？が利用と想定）
  - Peer経路は広告しない設定をしているため、ベストパスという広告が
    なされない

- 経路が聞こえ過ぎる(担当：吉田)
  - 勝手に流れてしまう
  - PrefixFilterのみでOutboundポリシーを記述していてTransitでなく
    Peerが優先されてしまうと、設定により勝手に意図せず経路を
    出してしまうことがある

- /32はご勘弁(担当：松崎)
  - おかしな経路が来る＝/32、/31、/30
  - プライベートやデフォルトルートを投げてくる・・・
    おまえは世界の中心か！？
    - 対策としてはIngressFilterでデフォルト、プライベートや
      細かい経路（/25など）をフィルタと良いだろう
    - 未割り当てをフィルタするという手段もああるが，運用負荷と天秤
　  - RFCを参考に自分のブロックやIX等もフィルタする方法もある
　- Next-hop-selfをやりましょう
　　- Ether上でトラフィックがピンポンするのを防いでくれる
　　- IX上では特に！しないと、AS-PathとNext-Hopの食い違いが起こる
　　- 実際のNext-HopのMACが変わると、Unreachableになってしまう可能性が
      ある為、防ぐ仕組みはあるけれど是非ともNext-Hop-Selfを
    - これについて「自分のことですか？」という反響がかなりあった(吉田)

- Dynamic!(担当：松崎)
  - インターネットはダイナミックなもの
　　- 経路変更やトラフィックの変動はメンテナンス上や契約、解約でも
      変わるもの
      ＝当たり前に起こりうるものだと思って下さい皆さん！
　　- ベストAS-Path上のどこかで変動が起これば、それだけである個所からの
      トラフィックが別AS経由となる可能性もある

「そりゃないよ編」まとめ
  - 変な経路が見える
　　- Egressで変な経路を絞る　∩　不足なく広告　＝　過不足無く
　　- Ingressで不要な経路を受け取らない、自分のASは自分で守る
　　●素直なポリシーで接続しましょう●


�A「きもい編」
- 「MED」が無視される？(担当：松崎)
  - MEDの大きいほうの経路が選択されるのは何故か？
　　- 同一ルータで別ASに接続されており別ASがベストパスの場合、
      DeterministicMEDをやっているとMEDの無視が生じる。
　　- 全て1Peer、1ルータで行えば大丈夫だけど・・・

- 「MED」がぱちぱち(担当：吉田)
  - マルチベンダが引き金に2つのPeerとたすきがけのようにBGPセッション、
    その下に別ASが存在し、マルチホームの構成 ＝ この構成は増えている
    - ベストパス選択の過程で，ベンダ実装の差異
　  - Ciscoの場合eBGPにてRouter IDの比較をしない為、本構成でも落ち着く
      →フラップ対策を考慮した実装
　  - Juniperの場合は比較をする為更に経路が変わり比較することを繰り返し
　- 対策としてはLocal-Preferenceか、always-compare-med
    - Local-Preference
      - MEDではなく，LoPreで優先度をそれぞれつけてあげる方法
　　- Always-Compare-MED
　　　- R2まで落ちてきた場合、MEDを比較するためRouter-IDまでいかない
　　- 最近はLoPreで何とかしたい！という話もちらほら出ている

「きもい編」まとめ
  - 実際に起こり得ます！MEDは思わぬ挙動があるので気をつけて！


�B「こりゃどうだ編」
- iBGPを実アドレスで張るとどう？(担当：吉田)
  - iBGPのPeerをループバック同士ではなく、を物理アドレスでやると
    どうなるのか？
　　- iBGPが起動しなくともセッションが上がるがIFが落ちると落ちる為、
　　　管理が大変かも。
　　- RCの再起動時、先にIFが上がるためIFが上がると同時にセッション
      が始まる

- 便利なSoftReconfiguration(担当：松崎)
　- 最近のルータは、RouteRefresh機能をサポートしている箱が増えている
    ＝ Cababilityが確立されていれば、Inputポリシーの変更が可能
　- 怪しいPeerのルートを、適用前に確認することも可能


�Cアンコール 「つぶやき編」
- 今の AS-PATH Filter はそろそろ止めよう！(担当：松崎)
　- 昔はユーザ経路を伝える手段だったが、スケールが異なって作業負荷
    が増加
  - 立て続けに更新メールを送ってくるのはきつい
　- 会場に質問「対策としてIRRを使う」
　　- （会場の挙手を見て）使っている人は結構居るのかも
　- AS-Setオブジェクトを伝えておき、それを見てフィルタを書きAS-Setから
    自動生成
　　- 登録者がIRRさえきちんとしてくれれば良い

- Prefixを数千行生成するのは現実的ではない(担当：吉田)
　- AS-PathフィルタとMaxPrefixを併用し、IRRからの生成は楽なのでは？
    - ご意見下さい！



■質疑応答

- 広告する経路が同じポリシーなら良いけど、プロバイダに依存するのでPeer
  ごとに広告するのを変える必要があるのでは？(MEX:石田さん)
  - 広告するのをASごとにセットするのはいかがだろうか？(松崎)

　- 相手に知られたくない場合は？
  　GLOBALに公開されると不安があるので、安全な情報しか出せない
    (MEX:石田さん)
  　- P2Pでしかしたくない場合にGLOBALになるのは引っかかる(吉田)

　- AS-Setを公開してFilterの自動生成は可能だと思うが，
  　Peer先によっては広告する経路自体が異なるケースがあるので，
  　そういった場合にはどう対処するのか？(MEX:石田さん)
  　- 相手に参照してもらうAS-Setを複数用意しておけばよい。(吉田)

  - AS-SETを見せて気にしない人が多いのでは？
　　全部公開すると運用が楽ではある。(フランステレコム：前村さん)
　　- 特定の人から特別なアナウンスを依頼されることがある。
　　　ユーザ希望の場合あり。(MEX:石田さん)
  　　- AS-SETを登録して無いと、そもそもやらせてもらえないところもある
    　　そういうのが増えれば広がる可能性もあるのか？(吉田)

  - 海外線を持ってるISPからの経路をフィルタしていた事がある。
    (フランステレコム：前村さん)

　- Peer to Peerで特別なお願いをするのはインターネット的ではない。
　　もっと公開するべきではないか？(三井情報開発：仲西さん)
  　- 経路の振り分けはビジネス、それを公開するのはどうか。
      (MEX:石田さん)

　- IRRを使う話は前からあり、プライベートASやPeerの話もある。
　　GLOBALなオブジェクトをやり、プライベートなものだけ個別でやるのは
  　ありだという話はある。
　　問題は実装が無い。
　　IRR側で見せるものを限定できればインプリ可能ではないか？
    (iNetCore：近藤さん)
  　- IRRの階層化のような実装について検討したことがある。(吉田)



- 今後のBGPに対する要望は？
　PeerとかPrifixのスケール、Convergence速度、Stability、マルチプロト
  コルへの機能拡充等(Cisco:河野さん)
  - Convergenceが遅い原因はCiscoのBGPウォーカーが
    30秒だからじゃないのか？(iNetCore：近藤さん)
  - Ciscoの場合には1分毎にスキャンプロセスが走っており、
    それに合わせてやるため12.0（29s）からトリガーで出来る
    (Cisco:河野さん)
  - EGPとして考えた場合、他のプロトコルを考えたほうが良いのでは？(松崎)
  - 今のBGPは色んな事をやらせ過ぎているかも、元はシンプルなもの
　　経路を細かくとかCommunityとか･･･Convergenceを考えると
    もっとシンプルにやりたい(吉田)



- ぱちぱちの話でF社は？
　ASがもうひとつあった場合、2つの違うルートが見えるのか？
  (@東京：吉野さん)
  - FはCよりの実装か？詳細は不明。
　　マルチホームの先が3つになった場合、アップデートの順に比較する
　　DiterministicMEDが前提にシーケンスに依存するのでどうなのか･･･
　　収束の可能性が高いが、実際にやってみないと解らない(吉田)



- 新しいASからの経路の見え方はどうか？
  同じASから2つの経路は来ないのか？(@東京：吉野さん)
  - かも知れない(吉田)
  - そのような現象を見たことがある。(@東京：吉野さん)
  - ただ単にアップデートをトリガにして似たような見え方もある。(松崎)



- RFC3330はどの程度きちんと実装されているか？
  細かい経路は実際にどれ位の長さのPrefixでフィルタしているのか？
  (IIJ：山口さん)
  - RFC3330はきちんとなされているのだろうか？
    一般的に/24でかけている場合は多い
    ユーザは落とす訳にはいかない為、通すようにフィルタを書く等が
    あるのでは？
    セキュリティ的にも有用なフィルタをする方法もあり、
    もらっても優先されないようなポリシーという手段もある(吉田)
  - RFC3330はフィルタをすると良いアドレスのガイドラインはなくて、
　　特別な用途として定義されてアドレスブロックである。
    有効なフィルタ例のHPがある、資料に添付する(松崎)


7.感想
　吉田さんのコメントにもあったとおりBGPオペレータが多いのか、注目度の
  高いセッションに感じた。
　しかし目的の情報共有になるべき質疑応答に対する会場からの意見が少なく
 （時間的な問題なのかも知れないが）、より活発な議論がなされることを期待
  する。