01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
バスで秋保温泉まで移動。
移動中に車内でビール。
料理はとても豪華。
AS番号カラオケ。
自分の組織のAS番号を入れて出てきた曲を歌う。
アイディアは良かったけど不発。
露天風呂最高。
書きなぐったメモを吐き出し。
これもちょっとずつリライトする予定。
2日目の午後は眠かったのであんまりメモれてないっす。
○前説
開始10分前の橘さんのトーク。定番。
○BGPの更新情報による障害検出
経路更新情報の通知は1日に20万回
BGPルータから得られる情報のみを使って運用上有用な情報を抽出してみる
Peer に着目
ツールには BGPView を使用。
経路情報を2次元テーブルに落として、その2次元テーブルを
時系列に沿って比較することで、経路の変化を見る。
インパクトの高いASやPeerから大きい影響を受けた
BGPの経路図が作られる。
場所がわかれば回避が可能になるかもしれない
[課題]
更に多くの具体例の解析が必要
リアルタイム性が欲しい
パケットの遅延情報を指標に加えてみる
[Q&A、コメント]
指標は面白い。
オペレータ的には実トラフィックに目が行きがち。
NANOGとかでもやっていることとの違いは？
3回に1回ぐらいはそういう発表がある
スラマーのときのデータは解析すると面白いかもしれない。
停電のときの解析は始めてきいた。
なんで自分達でやっていなかったのか、と思った。
リアルタイム性ということだが、
今はどのぐらい時間がかかるのか？
--> その日の情報を読みこんで、、、、
半日ぐらいかけてまとめて計算する。
--> 1日分をまとめて、なので細かく計算すればもうちょっと速いかも。
パケットの遅延は、ランディがハッピーパケット、とかで調べてた。
ウイルスネタで。
影響がある場合もない場合もある、とか。
--> ランディがハッピーパケットでは、
あんまり影響ないって言ってるけど実は結構変動する
ASがリルートするときの影響かな。
ASの持っているネットワークの大きさ、というのも指標になるかもしれない。
ちなみに持っているネットワークとトラフィックの相関はない。
直近では経路変動による負荷が処理に与える影響もある。
ASの重み付けを単純に prefix の数で見るだけでも良いかも。
アドレスの数ではなく、経路情報の数がインパクトに与えているのかな、
と思った。
ベスト経路への切り替わりという例もあるので、
切り替わった ＝ インパクトでもない。
経路情報は他のところのデータもあるので、活用してみれば？
観測点を増やすと精度が上がるか？
--> もっと多くする予定だったが、進行の都合で2点になってしまった。
エンドユーザーへのインパクトという視点も必要かもしれない。
重み付けに工夫をするのも面白いかも。
Google とかは重くするとか
DNSが動いているところとかを重みを付けるのも良いのかな。
--> Mとかなら重みを付けるのはできる。
--> 今回の研究では重みはあまり考えていない。
--> 現実的には重み付けはすぐできそうなのでやっていこうね
BGP anycast をやっているところとかは見えるのか？
--> 多分見えないんじゃないか？
--> 1つの観測点でしか見ていない
--> AS Path が変わらないと検知できない。Path が変われば見えてくる
BGP anycast がほんとうに動いているか気になっている。
解析してみると面白いのかな、と。
○Ethernet LAN の憂鬱
Ethernet で作るといろいろ問題が起きる。
VLANを使う大規模LAN
VPI(Vlan Port Instance)の上限が以外と厳しい
Cisco だと必ず考慮する
VPI = Trunkポート数× Trunk内のVLAN数 + Non-Trunkポート数
MSTIの割り当ては十分に検討する
IEEE802.1sでは64MSTIまで
機器によっては、16程度になってるのもある
エッジポートの挙動などが規格と違っていたり
MSTIに対するVLANの割り当てを後から変更するのは大変
ハートビート用VLANに注意
MSTIを分けないとモジュールフェールオーバーで
MSTI内VLAN全体のトポロジーチェンジが起こる
インスタンスを食うのはやめて欲しい
MST以外のベンダー独自多重化プロトコルの問題、仕様に注意
リンクアグリゲーションの問題
スイッチ以外も考えないといけない。LACPを実装していない機器とか。
セッションテーブルを作る機器とか。
IPチェックサムなんかが問題になることもある。へぇー。
箱への要望
キャパシティ
CPUを高速化して欲しい
相互接続をもうちょっと
Ethernet への要望
誰かTTLをください
BPDU性善説というのもどうなのか？
いつまで STP なの？
IEEE802.1ah、ITU-T Y-17、etthoam?
早く Ethernet Ping が打ちたい
最近気になっているのは？
TRILL (Transparent Interconnection of Lots of Links)
IS-ISベース？でトポロジ管理をする
GMPLS for Ethernet
自由にパスが張れるようになると面白い
Ethernetは大変
考えないといけないことが多い
原因救命が大変
トラブルを避けるために冗長を止めようかな、みたいな
[Q&A、コメント]
TTLには大拍手
Ethernet の装置なのに L4 まで見る装置なんてものもある。
トラブルシュートのときにとても困る。
余分なところまで見ないで欲しいな、みたいな。
憂鬱プラス1、みたいな。
Ethernet Ping はやっぱり欲しいなあ。
--> どんなルータでも ICMP Ping が入っている。
--> 安いスイッチにも入るようになって欲しい。
パケットリオーダーの話を聞くたびに思うけど、
パケットリオーダーがどのぐらい必要？
あんまり気にしなくても良いんじゃないか？
--> テレビ会議システムの過去の例。突然落ちちゃうってことがあった
--> 世の中が TCP や UDP だけじゃない場合もある。
ポート何番だけとか
--> そういうのを見るとリオーダーありえないよね、とかなっちゃう。
IETFはL3の規格を作るところ。
そこが Ether に介入してくる動きなのかな。
変に上位層が介入するのは問題があるのか？
--> 憂鬱が解消されるならなんでも良い。
--> ステートフルにして欲しい
Ethernet の Plug & Play を考えないといけない。
そのために犠牲にしなきゃいけないことは多い。
IPはわけわかんないのは捨てられるけど、Ether は通さないといけない
IPでいいじゃん、とか言いたい
--> 現実的には Ethernet しかない。
--> iLink？ IP over IEEE1394。C社さん出してくれないかな。
○.JPアップデート
中国が100万ドメイン。
アジアのトップじゃなくなった。
大きく水をあけられた。
日本語ドメインも増えている。
JP DNS の更新間隔が大幅短縮
15〜30分間隔での更新へ変更
2006年4月頃開始目標
in-addr.arpa. の変更はなし
JP DNSは、すべて BIND 9 に変更
jp のみのシングルゾーン化
現在は、64ゾーン
BIND9化は3月中にやる。
そのときにシングルゾーン化も行なわれる
SOA を UNIX epoch からの秒数へ変更
YYYYMMDDNN の10桁 --> UNIX epoch
minimum値を900秒(＝15分)に短縮予定
現在は86400秒(＝1日)
実装の関係でそれほどインパクトはない
TTLは変更なし86400秒(＝1日)
BIND 9化の影響
JP DNSの XXX.in-addr.arpa が100% グルー無しになる
DNSサーバーの不適切な設定に対する措置
ドメインハイジャック問題
危険なDNSサーバを削除している
機械的に月1回やっている。
ただしJPドメイン名以外だと無力
すでに乗っとられているものとかも無力
Root DNS サーバ、いわゆる M を WIDE と共同運用することになった。
[Q&A、コメント]
SOAのタイムの短縮は大歓迎
現在は手遅れになってから相談されることも多い。
シングルゾーン化はどうありがたい？
--> BIND 8 と挙動を合わせるため
○インターネットガバナンスアップデート
[キーワード]
WSIS - World Summit on the Information Society
ITU管轄の国連世界サミット
WGIG - Working Group for Internet Governance
国連事務総長直轄の検討部会
[チュニス会合で何があったか？]
Issue Papers のとりまとめ
--> 良い整理ができた
IPv6アドレス管理
中国がRIRシステムに加えて、ITU-主権国家による管理の併用を主張
--> 特に何か起こる気配なし
ICANNの統治
米国商務省契約をどう変えるのか？
Zone ファイルの編集権を米国商務省が握っているのはどうするのか
外交カードとして使われる可能性がある
--> もつれた
Issue Papers
インターネット？というのものもある。
それだけ広範囲になっている。
チュニスサミットのコメントは総務省に和訳がある
国際連合管轄でインターネットガバナンスフォーラム(IGF)を設立し、
5年間維持。
--> WGIGの発展的延長
ICANNは当面現状のまま維持する。
決議日の前日までもつれていた。
チュニスアジェンダ35項
技術的側面、公共政策的側面がある
ブレイクダウンして良くかけている
[10年ぐらい前と比較してみる]
10年前
名著「インターネット参加の手引き」
作り手 ＝ 動かし手 ＝ 使い手、の名残を噛み締めながら
ユーザーが当事者意識を持って動かしていた。
現在
インターネットは縁の下の力持ち。
つながってあたりまえ。
[チュニス会合の意味]
インターネットが政策課題、外交カードの一つになった
政府には政府の「インターネットの意味」
国際的な公共政策議論にはまだ時間がかかる
米国支配体制をどうするか
発展途上国に理解してもらうまでにはもっと時間が必要
技術課題、技術政策は民間セクターに託された
○プロバイダーエッジ2重化
構成2パターン
VLAN + VRRP
BGP2セッション
2重化のモチベーション
- 故障交換
- バージョンアップ
- 他者(メーカー)のせいにしない
よくなかったことは机上では出てこないけどやるといろいろ出てくる。
技術的な問題もそれなりに。
対外的な問題もある
まあいろいろ。
2重化すると、、
運用性、運用レベルは上がる。
でもコストも上がる。
市場の評価は上がる。多分上がっている。
[Q&A、コメント]
metric は Type2 でやっている？
--> 2でやっている
static が消えない問題。銀色の箱で問題があった。
トポロジによってはルーティングの問題になる可能性がある。
--> PE1とPE2のリンクがない場合にループになるかもしれない
メイン側を再起動しているときに OSPF が安定せずに、
問題が起きることがある。
どうやっているのか？
--> 壊れるときはどうしようもない
--> メンテナンスのときは、寄せてからやっているので大丈夫
/29で余ってしまう、という問題があったけど、
お客さん側でルータを2台用意する、というケースもある。
--> そういうお客さんもいる。ただし個別相談。
VRRPではなくHSRPで提供していたときに、
keep-alive が別のソリューションとぶつかって流れずに、
うまく動かなかったことがあった。
ユーザーさんも2重化すれば良いんじゃないかという話は
ああそうだなあ、と思う。
ただしキャリアだけが嬉しいのはアンフェアな気がする。
お客さんから見て嬉しくなるように見せないと。
まとめる箱をどこが用意するのか？。
キャリアが用意するのは大変だし、まとめるとシングルポイントになるし。
static が消えない問題だが、
インターフェイスで指定すれば消えるのではないか、と。
destination を IP address と Interface にすれば良い。
メンテナンスの時は、戻すのか？
倒しっぱなし、というのもありでは？
--> 戻している
PE1とPE2は同じラックにあるのか？
--> 地域分散はしていない。
--> 要望があったらもう1つソリューションをかぶせている
2重化したので、24時間保守を止めたりするようなことはあったか？
--> あったりなかったり
狙っているのは顧客満足。かなり上がっていると思う。
客観的にも結果が出ている。見習っていこうと思っている。
--> お声をいただければ検討する
○NSP-SEC-JP
メンバー
現在 25名
Vender 3社
Team Cymru 1名
bogon route-server を東京に設置、世界で5台目
IRCで発表者と雑談をしながら聞いていたので、
このセッションはちゃんとメモをしてない。
でもまあこのセッションは仕方ないよね。
かなりゆるーくやってる感じなのに、予定どおり進むのは、すごいわ。
さすがだよなあ。
[Q&A、コメント]
bogon route-server に誰が登録しているのか？
--> 5台あるので、IANA が登録するときのタイミングで登録される。
bogon のフィルターは世界的にはやる方向なのか？
--> まだ現実的にはそういう段階ではない
--> スタティック等、それぞれでフィルターをかけている。
--> みんな困っているので、ダイナミックにやりたい、
という思いはみんな共通
アドレスが止められてるときに、ベンダーさんの
サンプルコンフィグを見て、過去の情報が
流通するようなことがある。それへの対応は？
確認する方法は？
--> 情報をなるべく早く公開することは考えている。
uRPFのVRFモードというのを検討している。
uRPF 対応はアクセスライン業者のほうでも対応をお願いしたい。
[まとめ]
エッジでフィルターをやっていきたいと思っているので、
ベンダーへの対応をお願いしたい。
どういうパケットがドロップしているか、等も取得したい。
○JPIRR、IRRセキュリティ
吉田さんとICカードをランディにかざしていた木村さんのセッション。
登録オブジェクト数は着実に増えている。
大手ISPが登録したので昨年末に一気に増えた。
個人情報保護対応をした
Mail-From 認証を廃止
CRYPT-PW または PGPKEY の利用に移行
inet6num オブジェクトの登録を2/1に開始予定
CRISPのRFC化にむけた提案活動
どこかのWHOISを1つ叩くと、そこから再帰的に検索して結果を出力
ごみオブジェクト問題
オブジェクトに有効期限を設ける
更新期限日移行、一定期間を経過したオブジェクトは
IRRデータベースから除去
経路情報が存在していれば、更新されていると
見なされるような仕様はどうか
正式サービスへの移行を検討中(2006年7月予定)
信頼性の高いIRRへ向けた取り組みを続けていく
日本の経路台帳としての役割を担うようにしていく
route authorization
IP指定事業者が管理下のprefixの経路広告をAS管理者に対して認可すること
なにが嬉しいのか？
フィルターが正確に書ける
経路ジャックの検出・防止ができる
Secure BGP の実現
IP指定業者の証明書利用「認証強化実験」を実施中
ICカードで認証
普段は見えないメニューも見えるようになる。
[Q&A、コメント]
JPNICから割り当てられたアドレスについては、
指定事業者が許可しないと世の中に出ていかない。
正確には IRR に登録できない。
マーケットが納得するかどうか。
ごみオブジェクトの本質的な問題は、権限を持っている人の
問題のような気がする。
--> 忘れないようにリマインダを送るという意味もある
あまり縛りをきびしくするとビジネスをする人と
技術の人でやりあいが発生するんじゃないか、という気がする。
--> なるべく縛りをゆるくするために、この範囲内で、
というふうにしている
--> 担当者が違うという問題はたしかにある。
他から発行してもらった認証局の鍵を使いたい。そういうことは可能か？
--> 今のところ JPNICの鍵を使う
IRRが完全でない場合は、ORIGINのチェックに使えない、
とすると効用がない。
ニワトリと卵になりそうなんだけど。
--> すべてやろうではなく、この仕組みをうまく使って
経路情報を作れれば、と思っている。
--> JPNICで作っていく情報はいろいろ使えると思う。
--> 日本で経路情報をきちんとまとめていくことをしたい。
有償化、という動きはどうなっているか？
有償になった場合には参加するモチベーションは低くなりそう。
登録ではなく、見るために利用するわけだし。
--> JPIRR の有償化は、JPIRRに登録すればOKってことなら
なんとかなるけどそんなことはないので、、、、
そのラインではあきらめた。
--> IRRもちゃんとしなきゃいけないしユーザーも
ちゃんとやらなきゃいけない。
--> JPIRR の活動は、高機能化というのと、
ユーザーへのフィードバックという方向で
やっていこうかと思っている。
○高速ネットワーク切り替え
最近のインターネット
- リアルタイムトラフィックの増加
- ミッションクリティカルなサービス
いかに切断を検知するか。
IGPやBGPの正常性確認機能が使える。
Hello とか Keepalive とか
デフォルトだと時間が長い
短くして試してみました。
最短時間
Cisco : インターバル 1秒、ホールド 3秒
Juniper : インターバル 2秒、ホールド 6秒
※20秒以下だとフラップするから良くないよ、とか言われる
相互接続の問題はあるがそれなりにうまく機能した。
1秒以下の切り替わりってできない？
--> BFDというのがある
Bidirectional Forwarding Detection
障害を検知することのみを目指したもの
IPレイヤ上で動作する
かなりうまく機能した。
[Q&A、コメント]
update が来たときに CISCO と Juniper で実装が違う。
keepalive を短くしたときに悪影響はないか？
-->正直わからない。ご存知のかたは？
BFDにグっときた。
実環境でやったときに問題になることは？。予測とか。
-->ラボの中ではちゃんと動きました。
BFDで障害を検知したときに BGP のセッションを
切るというけどインターフェイスは上がっている。
reconnect とかの変なことにならないのか？
--> retry は行なっている。装置によって違う。
○高速光切替素子による信頼性向上
今の JPNAP のトラフィック。--> 100Gbits/sec!!
Layer1 による切り替えをする
MTTRに焦点。平均回復時間。
Layer2 以上は頑張ってるけど Layer1 はいまいち。
光スイッチで切り替えると障害が早く回復できる。
802.1abでトランクする装置が欲しくなった
2ch は作ったけど 4ch、8ch は密度的にきびしいかも。
[Q&A、コメント]
サブ側に光が出てなかったら切り替わらないの？
--> そうなっている。光が出てなかったらトラップが出るので修理に行く
組み合わせたときにどうなるか。たとえばさっきの BFD とか
--> 調べてみたところ 50ms 以下であれば link-down を検知しない。
光のレベルはなんともないのにリンクダウンするということが
多発している。
光のレベルを見ているということだけどそういう事故はどうなるか。
--> レベルは変更できるけど波形は見ていない。
--> その場合はスイッチで検知
NTT-ATさんのものはそんなに安くない気がする。ペイできてるの？
--> 10Gならコストに見合う
--> G でも2、3年で償却ならなんとかなる。
--> 簡単なスイッチは今は実は意外と簡単に作れてしまう。
産総研あたりは良いスイッチが作っている
--> 箱にしてください。それならうれしい。
この手のスイッチでメタル対応のものはあるか？
--> メタルのソリューションは聞いたことはない
--> メタルは一社だけある。実は試してない。
光のデバイスを作ってるの後で相談させてください。
切り替わったときのリスクはあるか？
--> MACアドレスを忘れてしまうので若干fludする。
--> ただ IX の場合はトラフィックがすごいのですぐに学習する
JANOGでは WG という仕組みがある。
こういう実験ネタがありましたらよろしくお願いします。
光スイッチのIX以外での使い方。他の用途とかは？
--> ヨーロッパのアムジックスでグリマーグラスという
3DMEMSのスイッチを使っている。
3DMEMSは遅いけど複雑な制御ができる。
光スイッチがシングルポイントになるのが気になる。2重化との葛藤は？
--> IXのトラフィックは多いので、10Gの機器を2個買ってください、
とは言えない。
同時に切り替えたときに問題はないか？
--> シャシーごとに切り替える機能はある。特に問題はない
シングルポイントフェイラーになる、という話があるけど、
そういう話が出るのは日本だけじゃないか？
アメリカ人なんかは、うちが壊れたら隣がある、とか平気で言う。
リングが2つあるから同時に繋げ、とか、
自助努力を大切にするのが世界的な流れ。
-->回線が高いのでは？
-->機器も高い
-->民族性だと思う
○クロージング
参加率が異常に高い。
次回は東京開催。
パナソニック石油ファンヒーターを持ってたら型番を調べてね。
2021 : 01 02 03 04 05 06 07 08 09 10 11 12
2020 : 01 02 03 04 05 06 07 08 09 10 11 12
2019 : 01 02 03 04 05 06 07 08 09 10 11 12
2018 : 01 02 03 04 05 06 07 08 09 10 11 12
2017 : 01 02 03 04 05 06 07 08 09 10 11 12
2016 : 01 02 03 04 05 06 07 08 09 10 11 12
2015 : 01 02 03 04 05 06 07 08 09 10 11 12
2014 : 01 02 03 04 05 06 07 08 09 10 11 12
2013 : 01 02 03 04 05 06 07 08 09 10 11 12
2012 : 01 02 03 04 05 06 07 08 09 10 11 12
2011 : 01 02 03 04 05 06 07 08 09 10 11 12
2010 : 01 02 03 04 05 06 07 08 09 10 11 12
2009 : 01 02 03 04 05 06 07 08 09 10 11 12
2008 : 01 02 03 04 05 06 07 08 09 10 11 12
2007 : 01 02 03 04 05 06 07 08 09 10 11 12
2006 : 01 02 03 04 05 06 07 08 09 10 11 12
2005 : 01 02 03 04 05 06 07 08 09 10 11 12
2004 : 01 02 03 04 05 06 07 08 09 10 11 12
最終更新時間: 2021-03-02 14:20