わたしはルーティング設定を変更したり修正したりするときに show runをやって現在の設定を確認する。ルーティングに限らずほとんどの場合、sho runをやる。だが、configが膨大な場合はそうもいかない。
そこで私が最近使うようになったのは show ip protocolである。これによって現在設定されているルーティングプロトコルとそのAS番号あるいはプロセス番号が表示される。他にも情報は表示されるが、とりあえず今ある設定がわかる。これがわかればそのモードに入れるし、消すこともできる。
さらに最近(といってももう10年くらい前からかな)はconfigモードでも doをつけることでshow コマンドが実施できるので、conf tをしてしまった後でも「あっいけね、exit」としなくても、「do sho ip proto」でよいのである。ospfのnetworkコマンドをやるときなどは do sho ip int briでipアドレスを確認する。
私は基本的にどんな簡単な構成であっても、走り書き程度でも構成図を描いて、それを見ながら設定する。それはミスがないからとか記録に残すためとかではなく、そのやり方が「計画、デザイン、実装、フィードバック」という進め方となるからだ。
構成図を描かずにいきなり設定していき、ガンガンコマンドを打っていくのもある意味速かったり楽だったりするのだが、わたしはそういうやり方は暴走、いわゆる「ハマリ」を生むような気がしてならない。
紙にボールペンで丸や四角を描いて線で結んで名前を描いたり数字を振ったりする。
それだけで、さっき言った計画から実装までの一連の作業の全体が見えるのである。
もちろんそれはあくまでも「机上の空論」であるが、どんなことでもまずは空論で始まるのだ。
do sho ip int brie までいれないとダメだね。
このブログを検索
2010/09/11
BSCIの準備 BGPの再配送
ospf, isis, eigrp, bgp などの間でredstribute を設定しているが、なかなか思うように再配送されない。
まず、eigrpとospfでは、metricを明示的に設定しないとダメだ。デフォルトでは再配送されない。 デフォルト値でダメならエラーといって欲しい気もする。
metric指定はしかたないとしても、bgpからospfへの再配送ができない。
bgpとospfを有効にしたルータで、redistribute bgp 400 とやる。
ルーティングテーブルには Bのルートがあるのに、再配送されない。
metricやmetric typeやsubnet指定をつけてもダメだ。 なぜだ!?
router bgpで、
bgp redistribute-internal が必要。
ある人のブログに書いてあった。 今読んでいる黒本にも出てこない。
だが、私はgoogleで「bgp ospf 再配送」と調べているうちに、だんだん今やろうとしていることがどういうことなのかに気付き始めた。
「bgpで学習した経路を、ospfに再配送する」という例が見当たらない。逆はある。
おそらく、普通はbgp→ospf という再配送はしないのだろう。
なぜかは説明できないが・・・。
(2012/02/13追記 これはiBGPの経路をIGPにredistributeする場合の話です。eBGPの経路はこれがなくても再配送できます。)
まず、eigrpとospfでは、metricを明示的に設定しないとダメだ。デフォルトでは再配送されない。 デフォルト値でダメならエラーといって欲しい気もする。
metric指定はしかたないとしても、bgpからospfへの再配送ができない。
bgpとospfを有効にしたルータで、redistribute bgp 400 とやる。
ルーティングテーブルには Bのルートがあるのに、再配送されない。
metricやmetric typeやsubnet指定をつけてもダメだ。 なぜだ!?
router bgpで、
bgp redistribute-internal が必要。
ある人のブログに書いてあった。 今読んでいる黒本にも出てこない。
だが、私はgoogleで「bgp ospf 再配送」と調べているうちに、だんだん今やろうとしていることがどういうことなのかに気付き始めた。
「bgpで学習した経路を、ospfに再配送する」という例が見当たらない。逆はある。
おそらく、普通はbgp→ospf という再配送はしないのだろう。
なぜかは説明できないが・・・。
(2012/02/13追記 これはiBGPの経路をIGPにredistributeする場合の話です。eBGPの経路はこれがなくても再配送できます。)
2010/08/31
BSCIの準備 EIGRP
マルチキャストで盛り上がりすぎた。
EIGRPに戻る。
全然わからない。一回舐めたはずだが・・・K値の意味を調べた記憶はあるがすっかり忘れている。 FDとADの意味がさっぱりわからない。ADは何の略かすらわからない。
ADは Advertised Distanceだった。 「AdvertiseされたDistance」だから、next hopから宛先までの「距離」。なんとなくわかる。
FDはFeasible Distance。 Feasibleとは、「実行可能な」「もっともらしい」「適して、便利で」などの意味。 「ネクストホップルータと宛先間のコストとローカルルータとネクストホップルータ間のコストの合計」 ・・・。なんだこの日本語。怒りすら覚える。
よく読めば、ADとFDというのがどういう意味なのかはわかる。しかし、どうしてADとかFDという考えを持ち出してきたのか、それらを使って何をするのか、ということが知りたい。
そもそも、ルーティングというのはもっともコストの低いnext hopを探すことではないのか。つまり「FD」が最小となるnext hopを探せばよいのだ。しかし、どうしてEIGRPだけにFDという概念が登場するのか。OSPFやRIPにはどうして出てこないのか。
さらに、ADは何か。ADとFDの差は、自身とnext hopの間のコストである。ADが最小のnext hopが存在しても、そこへ至るまでのコストが膨大であればnext hopとしては採用しない。それは当然のことだ。
だったら最初からFDを計算して最小のnext hopを探せばよい。では、ADという概念はどういうときに必要となるのか。 ちなみにFDが最小となるnext hopはサクセサと呼ばれる。普通のルーティングでいう、next hopだ。 EIGRPでは、サクセサの代替としてフィージブルサクセサというものを選出する。 フィージブルサクセサは、ADがFDより小さいルータである。 だから、フィージブルサクセサが存在しないこともありえる。
「AD<FDでなければならない」というのはどこにでも書いてあるが、なぜそうなのか説明している人はほとんどいない。 「『AD<FD』でないルータをフィージブルサクセサ(代替経路)とすると、ルーティングループが発生する」と書いている人はちらほらいるが、それでも、「なぜループが発生するのか」を説明している人がいない。
たとえば下記のような構成があったとする。
Aから、Dが持っている 100.0.0.0/24 へ到達したい。
BからDまでのコストは100、CからDまでのコストは120。
AからBまでのコストは10で、サクセサはBで、FDは110となる。
CのADは120なので、フィージブルサクセサにならない。
では、Cがフィージブルサクセサになると、どんな不都合があるのか。 どうしてCはフィージブルサクセサにならないのか。
「AD>FDだから」ではなくて、「どうしてAD>FDだと困るのか」ということである。
答え。
ルータCからDへの経路は二つ存在する。すなわち図では略されているCからDへの経路と、C-A-B-(略)-Dという経路である。
C-(略)-Dのコストは120。そして、C-A-B-Dのコストもまた120なのである。
等コストの経路が2本あったらどうなるか。どうなるんだ?先に登録された経路が採用されるのか? とにかく、CがAにパケットを返してループが発生することがありうる。
C-(略)-Dのコストが130だったらもっとわかりやすい。 この場合はC-A-B-Dのコストが120だから、確実にCはAへパケットを返す。 かくしてループが発生する。
だから、 AD>FDとなるルータをフィージブルサクセサとして選択できない、というわけだ。
もっと正確に言うと、Cから見たAのADは、Aから見たDへのFDである。 だから、比較するのは「AにとってのFD」と「CにとってのAのAD」となる。 これをAから見ると「FDとAのAD」の比較になる。 「AのFD」はすなわち「CにとってのAのAD」となる。
さっきの図では、CのフィージブルサクセサがAになるから、 C---(略)の経路がダウンしたら、CはD宛のパケットをAに転送する。 同時にA---B間がダウンしたら、AもCへ転送する。 A-C間でループというかピンポンが発生する。
これは多分、「ちょっと考えればわかることだからわざわざ説明しない」だけなのに「何か理由があるんだ」と思い込まれてしまっただけだと思う。とくに資格試験の参考書やWEBページなら、「とりあえず受かればいい」となるから。
・・・こんな感じでやっていかないと、全然頭に入らない。
もう受験予約もしてしまったのに・・・間に合わないぞ・・。
全然わからない。一回舐めたはずだが・・・K値の意味を調べた記憶はあるがすっかり忘れている。 FDとADの意味がさっぱりわからない。ADは何の略かすらわからない。
ADは Advertised Distanceだった。 「AdvertiseされたDistance」だから、next hopから宛先までの「距離」。なんとなくわかる。
FDはFeasible Distance。 Feasibleとは、「実行可能な」「もっともらしい」「適して、便利で」などの意味。 「ネクストホップルータと宛先間のコストとローカルルータとネクストホップルータ間のコストの合計」 ・・・。なんだこの日本語。怒りすら覚える。
よく読めば、ADとFDというのがどういう意味なのかはわかる。しかし、どうしてADとかFDという考えを持ち出してきたのか、それらを使って何をするのか、ということが知りたい。
そもそも、ルーティングというのはもっともコストの低いnext hopを探すことではないのか。つまり「FD」が最小となるnext hopを探せばよいのだ。しかし、どうしてEIGRPだけにFDという概念が登場するのか。OSPFやRIPにはどうして出てこないのか。
さらに、ADは何か。ADとFDの差は、自身とnext hopの間のコストである。ADが最小のnext hopが存在しても、そこへ至るまでのコストが膨大であればnext hopとしては採用しない。それは当然のことだ。
だったら最初からFDを計算して最小のnext hopを探せばよい。では、ADという概念はどういうときに必要となるのか。 ちなみにFDが最小となるnext hopはサクセサと呼ばれる。普通のルーティングでいう、next hopだ。 EIGRPでは、サクセサの代替としてフィージブルサクセサというものを選出する。 フィージブルサクセサは、ADがFDより小さいルータである。 だから、フィージブルサクセサが存在しないこともありえる。
「AD<FDでなければならない」というのはどこにでも書いてあるが、なぜそうなのか説明している人はほとんどいない。 「『AD<FD』でないルータをフィージブルサクセサ(代替経路)とすると、ルーティングループが発生する」と書いている人はちらほらいるが、それでも、「なぜループが発生するのか」を説明している人がいない。
たとえば下記のような構成があったとする。
10 100 A---B---(略)--+--D-| 100.0.0.0/24 | | |10 120 | +---C---(略)--+
Aから、Dが持っている 100.0.0.0/24 へ到達したい。
BからDまでのコストは100、CからDまでのコストは120。
AからBまでのコストは10で、サクセサはBで、FDは110となる。
CのADは120なので、フィージブルサクセサにならない。
では、Cがフィージブルサクセサになると、どんな不都合があるのか。 どうしてCはフィージブルサクセサにならないのか。
「AD>FDだから」ではなくて、「どうしてAD>FDだと困るのか」ということである。
答え。
ルータCからDへの経路は二つ存在する。すなわち図では略されているCからDへの経路と、C-A-B-(略)-Dという経路である。
C-(略)-Dのコストは120。そして、C-A-B-Dのコストもまた120なのである。
等コストの経路が2本あったらどうなるか。どうなるんだ?先に登録された経路が採用されるのか? とにかく、CがAにパケットを返してループが発生することがありうる。
C-(略)-Dのコストが130だったらもっとわかりやすい。 この場合はC-A-B-Dのコストが120だから、確実にCはAへパケットを返す。 かくしてループが発生する。
だから、 AD>FDとなるルータをフィージブルサクセサとして選択できない、というわけだ。
もっと正確に言うと、Cから見たAのADは、Aから見たDへのFDである。 だから、比較するのは「AにとってのFD」と「CにとってのAのAD」となる。 これをAから見ると「FDとAのAD」の比較になる。 「AのFD」はすなわち「CにとってのAのAD」となる。
さっきの図では、CのフィージブルサクセサがAになるから、 C---(略)の経路がダウンしたら、CはD宛のパケットをAに転送する。 同時にA---B間がダウンしたら、AもCへ転送する。 A-C間でループというかピンポンが発生する。
これは多分、「ちょっと考えればわかることだからわざわざ説明しない」だけなのに「何か理由があるんだ」と思い込まれてしまっただけだと思う。とくに資格試験の参考書やWEBページなら、「とりあえず受かればいい」となるから。
・・・こんな感じでやっていかないと、全然頭に入らない。
もう受験予約もしてしまったのに・・・間に合わないぞ・・。
2010/08/24
BSCIの準備 マルチキャスト(1)
マルチキャストの原理的なものは、もう嫌と言うほど聞いた。動画の配信をするだとか、groupだとか、joinだとか。ちょっとした設定もしたことがある。
しかし、私はマルチキャストを設定したルータを介して、どこかのサーバから動画を配信してクライアントで受信する様子を一度も見たことがない。だから、マルチキャストなんて本当に使われているのかと、はなはだ疑問なのである。
pimって何? マルチキャスト用のルーティングプロトコルである。
RPって何? Rendez-vouz Point(ランデブーポイント)
なんでこんなロマンチックなフランス語を使うんでしょうか。 ときどきこういうくだらない冗談がありますね。RSVPとか。要は、何かが出会うところで、マルチキャストルータ群で形成されるツリーの中心となるルータ、というような意味のようです。
RPを自動設定するようにdynamipsでしてみたが、ダメ。 まさかdynamipsのバグかと思ったりしたらidlepcを設定してるのにCPU使用率100になってて、再設定とかできなくて再インストールしてxpでやろうかとかごちゃごちゃやって時間をムダにした。
マルチキャストに関する素朴な疑問。
ルーターからigmp queryが送信されて、PCで受信したとする。Queryというのはマルチキャストを受信する人を探すもの?joinというのは、Queryに対するレスポンスとして送信されるのか?またはクライアントから任意に送信されるのか? いずれにしても、クライアント側で、「マルチキャストを受信したい」という意志を示す必要があり、その設定をしなければQueryを無視するはずだ。 そうしないと見たくもない動画のデータを受信することになる。
普通に考えると、「あるサービスを受けたいから、そのサービスを提供しているサーバのアドレス宛にリクエストを送る」ということをクライアントがするはずだ。それがjoinであろう。サーバーのアドレスはユニキャストならIPアドレスもしくはホストネームだが、マルチキャストの場合はマルチキャストアドレスとなる。
今使っているPCのNICをキャプチャすると、PIMv2のhelloがv6で届いている。あと、Multicast listeneer queryが届いている。Multicast Listner Report Message v2 というのも見える。 これの送信者は複数あり、ひとつは自分自身で、もうひとつはPIMv2のhelloを送っているアドレス、おそらく光電話のルータだ。
ICMPv6はおいといて、PIMv2のhelloはなんだろう?
みんな、coLinuxとか、virtualPCとかvlcとか使って、ちゃんと実験してるようだ。 ちょっと手間ヒマかかりそうだが、俺もやってみる。
dynamips、なんかおかしくないか?いろいろめんどくさいので、秋葉で3台シスコかっちゃったよ。
とりあえず、vistaのdynamipsで3台のルータを作り、外へ通信できるようにした。 サーバとなるのはvistaのvirtual pcのwindows xpのvlc。
クライアントは、昨日買ってきたファンレスPC。 なんか、シスコの実機はいらなかった感じ。まあいいや。
紹介します、ファンレスPC、DNRH-001です。 藤沢のソフマップUなんとかで15000円くらいで買ったものです。 LANアダプタ2つ、UPSつきです。winxp homeがインストールされてました。 昨日一日がかりで大量のアップデートをし、sp2, sp3, IE8をインストールしました。 今日秋葉でPC3200の1GBメモリを買ってきました2000円くらいでした。 規格はPC2100なんですけど2100なんかどこにも売ってませんでした。 1Gは新品だと5000円くらいで売ってました。じゃんぱらで買いました。 ちなみに最初についているkingstonの256MBのメモリは、ある店で大量に1個300円で売られていました。 ついでに100円のキーボード買ってきました。で、DNRHでdynamips動かそうとしたんですが遅くて使い物になりませんでした。dynamipsはけっこうリソースを必要とするようですね。 DNRHはこれから何に使おうかな・・・
とりあえず今はvlcのクライアントになります。まずはunicastルーティングを設定して、サーバ・クライアント間で通信できるようにする。vlcを双方にインストールし、サーバでストリーミングの設定をする。
さて、それではマルチキャストルーティングの設定だ.....というほどの設定は無い。
ip multicast-routing と、IFでpimのモードを設定するだけ。
メンドクサイのはvlcの設定である。 結果からいうととりあえずクライアントで何らかの動画が表示された。しかしそれは「何かが動いている」程度のモノであり、それが何かは全くわからず、 しかもすぐに止まってしまう。
vlcの配信側は、メニューの「メディア/ストリーミング」を開き、再生するファイルを選択して、「ストリーム再生」をクリックする。 「出力先」をクリックして、「RTP/MPEG Transport Stream」を選択し、 いろいろ試したがこれのときだけ、とりあえず何かが表示された。
そしてその右の「追加」をクリックする。 アドレスに「239.255.1.1」を入力する。(某サイトを参考のマネ) ベースポートはデフォルトの「5004」のまま。 トランスコーディングオプションはデフォルトの「Video - H.264 + AAC(MP4)」 「次へ」→「ストリーム再生」をクリックする。
クライアント側は、「メディア」→「ネットワークストリームを開く」で、 「ネットワークURLを入力してください」のところに「udp://@239.255.1.1:5004」を入力し、「再生」をクリックする。 再生開始までに少し時間がかかる。 そして、30秒くらいかな、経つと再生が止まる。データ自体が止まる。
VLCのバージョンは1.1.3
うまく表示できない原因として考えられるのは、
・クライアント側のスペック不足
・サーバ側のビデオのレートが高すぎる(ムービーメーカーで低品質ビデオを作ってみたがダメ)
・サーバ側がRTPで受信側がUDPである(受信側もRTPにしたり送信側をUDPにしたりしてみたがダメ)
など。
ただ、肝心のルータの設定はさっきも書いたがごく単純で、joinやらleaveはサーバとクライアントが勝手にやるだけ。
マルチキャストというのは、あたり前なのだが、あくまでも配信方法である。 再生はサーバのアプリケーションでおこなう。それをユニキャストで配信することも可能だ。(やってないが)
明日、今日買ったciscoが届くので、
PC(client)---RT1---RT2---RT3---PC(server)
という物理構成を作って、もう一度やってみる。
後もうひとつ、今は上記の構成のRT1~PC(Server)までをvistaでシミュレートしているが、そのときにvistaのネットワークアダプタのアドレスを、論理構成で使用しているサブネットのアドレスにすると、うまく動かない。「同じにしなくてもよい」のではなく「同じにしてはいけない、違うサブネットのアドレスにする必要がある」。理由がよくわからないのだが。
vlsってのがあるな・・・ ttl=1でやってたけど1じゃダメだな・・・でも届いてはいたっぽいけどな・・・ また明日・・・ passwordの設定の仕方を忘れている。ccnaでシミュレーション問題だったところだ。
ciscoはデフォルトの状態ではtelnetできないようになっている。
マルチキャスト配信ができない。何も映らない。
まず、http配信をやってみる。とりあえずできる。だがこんなのはただ相手のhttpを見ているだけで配信とは言えない。さらに、こんなものでも再生が途中で止まったりする。 httpでwmvのムービーをasfで、またはmp3なら、オリジナルクオリティでOK。
動画は音声がわずかに遅れる。一回しか再生できないのは、キャッシュ動作のせいだろうか? 途中でケーブルを抜いてみると、再生は停止したが、クライアントの受信をいったんとめて再受信したら再開できた。
落ち着いて考え直す。
mp3のhttpによるstreamingなら問題ない。これの、配信方法をmulticastに変えればよいのだ。
配信側は"RTP / MPEG Transport Stream"にする。
そして、配信したPCでもう一個vlcプレイヤーを立ち上げ、"rtp://239.255.1.1:5004"のurlを開く。
聞こえる!
これでいいんだ。 やっと見れた・・・
一番の問題はvlcのGUIで設定したttlが反映していなかったこと。
なんとずっとttl=1でやっていたのだ。
それから、client側に 224.0.0.0 mask 240.0.0.0 nexthop のルーティングがなかったこと。
あー疲れた。 ちなみに配信したのは、笑点でやった麒麟のネタのwmvである。5分46秒。
一式、ぶちまけときましょうかね。 まずは、クライアントが繋がっているルータ。 なんていうんだっけ、なんか名前があるんだよな・・・
サーバ
クライアント
そうそう、vlcのコマンドね。
vlcのttlは、cliで動かすと変更できるんだって。
GUIで設定して、最後に表示される文字列を、vlc.exe kirin.wmv の後に貼り付け、さらにその後に"--ttl 10"というようにttlを指定する。
kirin.wmv というのが動画ファイル名。 239.255.x.x というのは、マルチキャストのプライベートアドレス。
あとは、rtp以外で、udpとか、できるかやってみるか。 ttlか・・・ mroute で 239.255.1.1 がないなあとは思っていたのだが・・・ joinが出ているのは見たが、ttlが変わっていなかったとは・・・
ちなみに帯域は10Mbpsのethernetです。 10Mbpsで、十分です。
マルチキャストアドレスはけっこう見ることは見る。ospfとか、ripとか、UPnPとか。 今もキャプチャしてみたら、239.255.255.250 あてのSSDPとかいうのが出ている。 これは何だろう? たしかこれがUPnPなのである。
たしかにこのアドレスはマルチキャストアドレスであるが、私が言っているのはルーティングされる、ルータを越えるマルチキャストのことである。同じサブネット内であるなら、ほとんどブロードキャストと同じである。 ブロードキャストは全ホストが受信し、箱を開ける。マルチキャストはどうなのだろう?おそらく、ブロードキャストほどは負荷をかけないはず。箱のラベルだけ見て、開けずに捨てる感じか。
マルチキャストというのはまず、「ひとつの相手ではないがすべてでもない」というのがあり、さらに、「ルーティングできる」というのがある。これがなかなか説明されない。
unicastとbroadcastとmulticastの違いを説明するけど、ここで、broadcastはルーティングできないが、multicastはルーティングできる、ということをもっと強調すべきではないか。
マルチキャストルーティングとユニキャストルーティングの違いは何か。
そもそも、ルーティングとはどういうことか。 それは、next hopの指定であった。ルーターが知っているのは次の出口だけである。最終目的地は知らない。右から来たものを左へ受け流すだけである。
そのパケットがどこから来てどこへ行くのか(最終的にどこへ行くのか、何をしにいくのか)は関知しない。(することもあるが、それには手間がかかる。)
そうそう、マルチキャストルーティングするには、ユニキャストルーティングが必要。これも大事な前提だ。
ユニキャストとマルチキャストは用途によってどちらかを選ぶようなものではないのだ。 ・・・かな?
さて、マルチキャストでのポイントは、特定の相手にだけ送信するということだ。「特定の相手」とは?誰が決めるのか?送信者?違う。受信者が、「私のところに送って欲しい」と申し出る。 この申し出をおこなった人に対してのみ、送信をおこなうのである。この申し出のことを、joinという。
黒本より
cisco推奨のモードは sparse-dence-mode
しかし、私はマルチキャストを設定したルータを介して、どこかのサーバから動画を配信してクライアントで受信する様子を一度も見たことがない。だから、マルチキャストなんて本当に使われているのかと、はなはだ疑問なのである。
pimって何? マルチキャスト用のルーティングプロトコルである。
RPって何? Rendez-vouz Point(ランデブーポイント)
なんでこんなロマンチックなフランス語を使うんでしょうか。 ときどきこういうくだらない冗談がありますね。RSVPとか。要は、何かが出会うところで、マルチキャストルータ群で形成されるツリーの中心となるルータ、というような意味のようです。
RPを自動設定するようにdynamipsでしてみたが、ダメ。 まさかdynamipsのバグかと思ったりしたらidlepcを設定してるのにCPU使用率100になってて、再設定とかできなくて再インストールしてxpでやろうかとかごちゃごちゃやって時間をムダにした。
マルチキャストに関する素朴な疑問。
ルーターからigmp queryが送信されて、PCで受信したとする。Queryというのはマルチキャストを受信する人を探すもの?joinというのは、Queryに対するレスポンスとして送信されるのか?またはクライアントから任意に送信されるのか? いずれにしても、クライアント側で、「マルチキャストを受信したい」という意志を示す必要があり、その設定をしなければQueryを無視するはずだ。 そうしないと見たくもない動画のデータを受信することになる。
普通に考えると、「あるサービスを受けたいから、そのサービスを提供しているサーバのアドレス宛にリクエストを送る」ということをクライアントがするはずだ。それがjoinであろう。サーバーのアドレスはユニキャストならIPアドレスもしくはホストネームだが、マルチキャストの場合はマルチキャストアドレスとなる。
今使っているPCのNICをキャプチャすると、PIMv2のhelloがv6で届いている。あと、Multicast listeneer queryが届いている。Multicast Listner Report Message v2 というのも見える。 これの送信者は複数あり、ひとつは自分自身で、もうひとつはPIMv2のhelloを送っているアドレス、おそらく光電話のルータだ。
ICMPv6はおいといて、PIMv2のhelloはなんだろう?
みんな、coLinuxとか、virtualPCとかvlcとか使って、ちゃんと実験してるようだ。 ちょっと手間ヒマかかりそうだが、俺もやってみる。
dynamips、なんかおかしくないか?いろいろめんどくさいので、秋葉で3台シスコかっちゃったよ。
とりあえず、vistaのdynamipsで3台のルータを作り、外へ通信できるようにした。 サーバとなるのはvistaのvirtual pcのwindows xpのvlc。
クライアントは、昨日買ってきたファンレスPC。 なんか、シスコの実機はいらなかった感じ。まあいいや。
紹介します、ファンレスPC、DNRH-001です。 藤沢のソフマップUなんとかで15000円くらいで買ったものです。 LANアダプタ2つ、UPSつきです。winxp homeがインストールされてました。 昨日一日がかりで大量のアップデートをし、sp2, sp3, IE8をインストールしました。 今日秋葉でPC3200の1GBメモリを買ってきました2000円くらいでした。 規格はPC2100なんですけど2100なんかどこにも売ってませんでした。 1Gは新品だと5000円くらいで売ってました。じゃんぱらで買いました。 ちなみに最初についているkingstonの256MBのメモリは、ある店で大量に1個300円で売られていました。 ついでに100円のキーボード買ってきました。で、DNRHでdynamips動かそうとしたんですが遅くて使い物になりませんでした。dynamipsはけっこうリソースを必要とするようですね。 DNRHはこれから何に使おうかな・・・
とりあえず今はvlcのクライアントになります。まずはunicastルーティングを設定して、サーバ・クライアント間で通信できるようにする。vlcを双方にインストールし、サーバでストリーミングの設定をする。
さて、それではマルチキャストルーティングの設定だ.....というほどの設定は無い。
ip multicast-routing と、IFでpimのモードを設定するだけ。
メンドクサイのはvlcの設定である。 結果からいうととりあえずクライアントで何らかの動画が表示された。しかしそれは「何かが動いている」程度のモノであり、それが何かは全くわからず、 しかもすぐに止まってしまう。
vlcの配信側は、メニューの「メディア/ストリーミング」を開き、再生するファイルを選択して、「ストリーム再生」をクリックする。 「出力先」をクリックして、「RTP/MPEG Transport Stream」を選択し、 いろいろ試したがこれのときだけ、とりあえず何かが表示された。
そしてその右の「追加」をクリックする。 アドレスに「239.255.1.1」を入力する。(某サイトを参考のマネ) ベースポートはデフォルトの「5004」のまま。 トランスコーディングオプションはデフォルトの「Video - H.264 + AAC(MP4)」 「次へ」→「ストリーム再生」をクリックする。
クライアント側は、「メディア」→「ネットワークストリームを開く」で、 「ネットワークURLを入力してください」のところに「udp://@239.255.1.1:5004」を入力し、「再生」をクリックする。 再生開始までに少し時間がかかる。 そして、30秒くらいかな、経つと再生が止まる。データ自体が止まる。
VLCのバージョンは1.1.3
うまく表示できない原因として考えられるのは、
・クライアント側のスペック不足
・サーバ側のビデオのレートが高すぎる(ムービーメーカーで低品質ビデオを作ってみたがダメ)
・サーバ側がRTPで受信側がUDPである(受信側もRTPにしたり送信側をUDPにしたりしてみたがダメ)
など。
ただ、肝心のルータの設定はさっきも書いたがごく単純で、joinやらleaveはサーバとクライアントが勝手にやるだけ。
マルチキャストというのは、あたり前なのだが、あくまでも配信方法である。 再生はサーバのアプリケーションでおこなう。それをユニキャストで配信することも可能だ。(やってないが)
明日、今日買ったciscoが届くので、
PC(client)---RT1---RT2---RT3---PC(server)
という物理構成を作って、もう一度やってみる。
後もうひとつ、今は上記の構成のRT1~PC(Server)までをvistaでシミュレートしているが、そのときにvistaのネットワークアダプタのアドレスを、論理構成で使用しているサブネットのアドレスにすると、うまく動かない。「同じにしなくてもよい」のではなく「同じにしてはいけない、違うサブネットのアドレスにする必要がある」。理由がよくわからないのだが。
vlsってのがあるな・・・ ttl=1でやってたけど1じゃダメだな・・・でも届いてはいたっぽいけどな・・・ また明日・・・ passwordの設定の仕方を忘れている。ccnaでシミュレーション問題だったところだ。
ciscoはデフォルトの状態ではtelnetできないようになっている。
line vty 0 4 password xxxxxxxx loginが必要。
マルチキャスト配信ができない。何も映らない。
まず、http配信をやってみる。とりあえずできる。だがこんなのはただ相手のhttpを見ているだけで配信とは言えない。さらに、こんなものでも再生が途中で止まったりする。 httpでwmvのムービーをasfで、またはmp3なら、オリジナルクオリティでOK。
動画は音声がわずかに遅れる。一回しか再生できないのは、キャッシュ動作のせいだろうか? 途中でケーブルを抜いてみると、再生は停止したが、クライアントの受信をいったんとめて再受信したら再開できた。
落ち着いて考え直す。
mp3のhttpによるstreamingなら問題ない。これの、配信方法をmulticastに変えればよいのだ。
配信側は"RTP / MPEG Transport Stream"にする。
そして、配信したPCでもう一個vlcプレイヤーを立ち上げ、"rtp://239.255.1.1:5004"のurlを開く。
聞こえる!
これでいいんだ。 やっと見れた・・・
一番の問題はvlcのGUIで設定したttlが反映していなかったこと。
なんとずっとttl=1でやっていたのだ。
それから、client側に 224.0.0.0 mask 240.0.0.0 nexthop のルーティングがなかったこと。
あー疲れた。 ちなみに配信したのは、笑点でやった麒麟のネタのwmvである。5分46秒。
一式、ぶちまけときましょうかね。 まずは、クライアントが繋がっているルータ。 なんていうんだっけ、なんか名前があるんだよな・・・
R1#sho run Building configuration... Current configuration : 917 bytes ! version 12.3 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname R1 ! boot-start-marker boot-end-marker ! enable password enable ! no aaa new-model ip subnet-zero ip cef ! ! no ip domain lookup ! ip multicast-routing ip audit po max-events 100 ! ! ! ! interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Ethernet0/0 ip address 192.168.100.99 255.255.255.0 ip pim dense-mode full-duplex ! interface BRI0/0 no ip address encapsulation hdlc shutdown ! interface Ethernet1/0 ip address 10.0.0.1 255.255.255.0 ip pim dense-mode full-duplex ! router ospf 100 log-adjacency-changes passive-interface Ethernet0/0 network 10.0.0.0 0.0.0.255 area 0 network 192.168.100.0 0.0.0.255 area 0 ! ip httq server ip classless ! ! ! line con 0 exec-timeout 0 0 password password line aux 0 line vty 0 4 password telnet login ! ! end
R1#sho ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.255.1.1), 00:13:44/stopped, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/0, Forward/Dense, 00:06:27/00:00:00 Ethernet1/0, Forward/Dense, 00:13:44/00:00:00 (192.168.200.240, 239.255.1.1), 00:07:43/00:02:53, flags: T Incoming interface: Ethernet1/0, RPF nbr 10.0.0.2 Outgoing interface list: Ethernet0/0, Forward/Dense, 00:06:28/00:00:00 (*, 224.0.1.40), 01:11:48/00:02:12, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/0, Forward/Dense, 01:11:39/00:00:00 Ethernet0/0, Forward/Dense, 01:11:48/00:00:00 (*, 239.255.255.250), 00:40:07/00:02:11, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/0, Forward/Dense, 00:40:07/00:00:00 Ethernet0/0, Forward/Dense, 00:40:07/00:00:00 R1#sh ip igmp membership Flags: A - aggregate, T - tracked L - Local, S - static, V - virtual, R - Reported through v3 I - v3lite, U - Urd, M - SSM (S,G) channel 1,2,3 - The version of IGMP the group is in Channel/Group-Flags: / - Filtering entry (Exclude mode (S,G), Include mode (*,G)) Reporter: - last reporter if group is not explicitly tracked / - reporter in include mode, reporter in exclude Channel/Group Reporter Uptime Exp. Flags Interface *,239.255.1.1 192.168.100.1 00:06:36 02:57 2A Et0/0 *,224.0.1.40 10.0.0.2 01:11:47 02:01 2A Et1/0 *,224.0.1.40 192.168.100.99 01:11:56 02:04 2LA Et0/0 *,239.255.255.250 192.168.100.1 00:40:15 02:03 2A Et0/0 R1#sho ip igmp interface Ethernet0/0 is up, line protocol is up Internet address is 192.168.100.99/24 IGMP is enabled on interface Current IGMP host version is 2 Current IGMP router version is 2 IGMP query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP max query response time is 10 seconds Last member query count is 2 Last member query response interval is 1000 ms Inbound IGMP access group is not set IGMP activity: 3 joins, 0 leaves Multicast routing is enabled on interface Multicast TTL threshold is 0 Multicast designated router (DR) is 192.168.100.99 (this system) IGMP querying router is 192.168.100.99 (this system) Multicast groups joined by this system (number of users): 224.0.1.40(1) Ethernet1/0 is up, line protocol is up Internet address is 10.0.0.1/24 IGMP is enabled on interface Current IGMP host version is 2 Current IGMP router version is 2 IGMP query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP max query response time is 10 seconds Last member query count is 2 Last member query response interval is 1000 ms Inbound IGMP access group is not set IGMP activity: 1 joins, 0 leaves Multicast routing is enabled on interface Multicast TTL threshold is 0 Multicast designated router (DR) is 10.0.0.2 IGMP querying router is 10.0.0.1 (this system) No multicast groups joined by this system
R1#sho ip pim interface Address Interface Ver/ Nbr Query DR DR Mode Count Intvl Prior 192.168.100.99 Ethernet0/0 v2/D 0 30 1 192.168.100.99 10.0.0.1 Ethernet1/0 v2/D 1 30 1 10.0.0.2 R1#sho ip pim neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,S - State Refresh Capable Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 10.0.0.2 Ethernet1/0 01:12:03/00:01:39 v2 1 / DR S
R1#sho ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set 1.0.0.0/32 is subnetted, 1 subnets C 1.1.1.1 is directly connected, Loopback0 20.0.0.0/24 is subnetted, 1 subnets O 20.0.0.0 [110/20] via 10.0.0.2, 01:11:08, Ethernet1/0 O 192.168.200.0/24 [110/30] via 10.0.0.2, 01:11:08, Ethernet1/0 10.0.0.0/24 is subnetted, 1 subnets C 10.0.0.0 is directly connected, Ethernet1/0 C 192.168.100.0/24 is directly connected, Ethernet0/0次は、真ん中のルータ。
R2#sho running-config Building configuration... Current configuration : 875 bytes ! version 12.3 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname R2 ! boot-start-marker boot-end-marker ! enable password enable ! no aaa new-model ip subnet-zero ip cef ! ! no ip domain lookup ! ip multicast-routing ip audit po max-events 100 ! ! ! ! interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface Ethernet0/0 ip address 10.0.0.2 255.255.255.0 ip pim dense-mode full-duplex ! interface BRI0/0 no ip address encapsulation hdlc shutdown ! interface Ethernet1/0 ip address 20.0.0.1 255.255.255.0 ip pim dense-mode full-duplex ! router ospf 100 log-adjacency-changes network 10.0.0.0 0.0.0.255 area 0 network 20.0.0.0 0.0.0.255 area 0 ! ip httq server ip classless ! ! ! line con 0 exec-timeout 0 0 password password line aux 0 line vty 0 4 password telnet login ! ! end
R2#sho ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.255.1.1), 00:16:26/stopped, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/0, Forward/Dense, 00:16:26/00:00:00 Ethernet0/0, Forward/Dense, 00:16:26/00:00:00 (192.168.200.240, 239.255.1.1), 00:16:26/00:02:50, flags: T Incoming interface: Ethernet1/0, RPF nbr 20.0.0.2 Outgoing interface list: Ethernet0/0, Forward/Dense, 00:09:09/00:00:00 (*, 224.0.1.40), 01:14:20/00:02:36, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/0, Forward/Dense, 01:13:51/00:00:00 Ethernet0/0, Forward/Dense, 01:14:20/00:00:00 R2#sh ip igmp membership Flags: A - aggregate, T - tracked L - Local, S - static, V - virtual, R - Reported through v3 I - v3lite, U - Urd, M - SSM (S,G) channel 1,2,3 - The version of IGMP the group is in Channel/Group-Flags: / - Filtering entry (Exclude mode (S,G), Include mode (*,G)) Reporter: - last reporter if group is not explicitly tracked / - reporter in include mode, reporter in exclude Channel/Group Reporter Uptime Exp. Flags Interface *,224.0.1.40 20.0.0.2 01:13:40 02:29 2A Et1/0 *,224.0.1.40 10.0.0.2 01:14:27 02:23 2LA Et0/0
R2#sh ip igmp interface Ethernet0/0 is up, line protocol is up Internet address is 10.0.0.2/24 IGMP is enabled on interface Current IGMP host version is 2 Current IGMP router version is 2 IGMP query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP max query response time is 10 seconds Last member query count is 2 Last member query response interval is 1000 ms Inbound IGMP access group is not set IGMP activity: 1 joins, 0 leaves Multicast routing is enabled on interface Multicast TTL threshold is 0 Multicast designated router (DR) is 10.0.0.2 (this system) IGMP querying router is 10.0.0.1 Multicast groups joined by this system (number of users): 224.0.1.40(1) Ethernet1/0 is up, line protocol is up Internet address is 20.0.0.1/24 IGMP is enabled on interface Current IGMP host version is 2 Current IGMP router version is 2 IGMP query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP max query response time is 10 seconds Last member query count is 2 Last member query response interval is 1000 ms Inbound IGMP access group is not set IGMP activity: 1 joins, 0 leaves Multicast routing is enabled on interface Multicast TTL threshold is 0 Multicast designated router (DR) is 20.0.0.2 IGMP querying router is 20.0.0.1 (this system) No multicast groups joined by this system
R2#sh ip pim neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, S - State Refresh Capable Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 10.0.0.1 Ethernet0/0 01:14:07/00:01:31 v2 1 / S 20.0.0.2 Ethernet1/0 01:14:07/00:01:25 v2 1 / DR S最後、サーバが繋がってるルータ。
R3#sho running-config Building configuration... Current configuration : 933 bytes ! version 12.3 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname R3 ! boot-start-marker boot-end-marker ! enable password enable ! no aaa new-model ip subnet-zero ip cef ! ! no ip domain lookup ! ip multicast-routing ip audit po max-events 100 ! ! ! ! interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! interface Ethernet0/0 ip address 20.0.0.2 255.255.255.0 ip pim dense-mode full-duplex ! interface BRI0/0 no ip address encapsulation hdlc shutdown ! interface Ethernet1/0 ip address 192.168.200.99 255.255.255.0 ip pim dense-mode full-duplex ! router ospf 100 log-adjacency-changes passive-interface Ethernet1/0 network 10.0.0.0 0.0.0.255 area 0 network 20.0.0.0 0.0.0.255 area 0 network 192.168.200.0 0.0.0.255 area 0 ! ip httq server ip classless ! ! ! line con 0 exec-timeout 0 0 line aux 0 line vty 0 4 password telnet login ! ! end
R3#sho ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set 3.0.0.0/32 is subnetted, 1 subnets C 3.3.3.3 is directly connected, Loopback0 20.0.0.0/24 is subnetted, 1 subnets C 20.0.0.0 is directly connected, Ethernet0/0 C 192.168.200.0/24 is directly connected, Ethernet1/0 10.0.0.0/24 is subnetted, 1 subnets O 10.0.0.0 [110/20] via 20.0.0.1, 01:15:38, Ethernet0/0 O 192.168.100.0/24 [110/30] via 20.0.0.1, 01:15:38, Ethernet0/0
R3#sho ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.255.1.1), 00:18:51/stopped, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/0, Forward/Dense, 00:18:51/00:00:00 (192.168.200.240, 239.255.1.1), 00:12:50/00:02:51, flags: T Incoming interface: Ethernet1/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/0, Forward/Dense, 00:11:33/00:00:00 (*, 224.0.1.40), 01:16:50/00:02:17, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/0, Forward/Dense, 01:16:50/00:00:00 (*, 239.255.255.250), 01:15:58/00:02:10, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/0, Forward/Dense, 01:15:58/00:00:00 Ethernet0/0, Forward/Dense, 01:15:58/00:00:00
R3#sho ip igmp membership Flags: A - aggregate, T - tracked L - Local, S - static, V - virtual, R - Reported through v3 I - v3lite, U - Urd, M - SSM (S,G) channel 1,2,3 - The version of IGMP the group is in Channel/Group-Flags: / - Filtering entry (Exclude mode (S,G), Include mode (*,G)) Reporter: - last reporter if group is not explicitly tracked / - reporter in include mode, reporter in exclude Channel/Group Reporter Uptime Exp. Flags Interface *,224.0.1.40 20.0.0.2 01:16:55 02:11 2LA Et0/0 *,239.255.255.250 192.168.200.240 01:16:04 02:04 2A Et1/0
R3#sho ip igmp interface Ethernet0/0 is up, line protocol is up Internet address is 20.0.0.2/24 IGMP is enabled on interface Current IGMP host version is 2 Current IGMP router version is 2 IGMP query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP max query response time is 10 seconds Last member query count is 2 Last member query response interval is 1000 ms Inbound IGMP access group is not set IGMP activity: 1 joins, 0 leaves Multicast routing is enabled on interface Multicast TTL threshold is 0 Multicast designated router (DR) is 20.0.0.2 (this system) IGMP querying router is 20.0.0.1 Multicast groups joined by this system (number of users): 224.0.1.40(1) Ethernet1/0 is up, line protocol is up Internet address is 192.168.200.99/24
IGMP is enabled on interface Current IGMP host version is 2 Current IGMP router version is 2 IGMP query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP max query response time is 10 seconds Last member query count is 2 Last member query response interval is 1000 ms Inbound IGMP access group is not set IGMP activity: 5 joins, 4 leaves Multicast routing is enabled on interface Multicast TTL threshold is 0 Multicast designated router (DR) is 192.168.200.99 (this system) IGMP querying router is 192.168.200.99 (this system) No multicast groups joined by this system
R3#sho ip pim interface Address Interface Ver/ Nbr Query DR DR Mode Count Intvl Prior 20.0.0.2 Ethernet0/0 v2/D 1 30 1 20.0.0.2 192.168.200.99 Ethernet1/0 v2/D 0 30 1 192.168.200.99
R3#sho ip pim neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, S - State Refresh Capable Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 20.0.0.1 Ethernet0/0 01:17:06/00:01:27 v2 1 / S R3#sho ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set 3.0.0.0/32 is subnetted, 1 subnets C 3.3.3.3 is directly connected, Loopback0 20.0.0.0/24 is subnetted, 1 subnets C 20.0.0.0 is directly connected, Ethernet0/0 C 192.168.200.0/24 is directly connected, Ethernet1/0 10.0.0.0/24 is subnetted, 1 subnets O 10.0.0.0 [110/20] via 20.0.0.1, 01:16:08, Ethernet0/0 O 192.168.100.0/24 [110/30] via 20.0.0.1, 01:16:08, Ethernet0/0あとは、サーバとクライアントのルーティングテーブル
サーバ
=========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.200.99 192.168.200.240 20 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.200.0 255.255.255.0 192.168.200.240 192.168.200.240 20 192.168.200.240 255.255.255.255 127.0.0.1 127.0.0.1 20 192.168.200.255 255.255.255.255 192.168.200.240 192.168.200.240 20 224.0.0.0 240.0.0.0 192.168.200.240 192.168.200.240 20 255.255.255.255 255.255.255.255 192.168.200.240 192.168.200.240 1 Default Gateway: 192.168.200.99 =========================================================================== Persistent Routes: None
クライアント
=========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.3 20 0.0.0.0 0.0.0.0 192.168.100.99 192.168.100.1 30 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.1.0 255.255.255.0 192.168.1.3 192.168.1.3 20 192.168.1.3 255.255.255.255 127.0.0.1 127.0.0.1 20 192.168.1.255 255.255.255.255 192.168.1.3 192.168.1.3 20 192.168.100.0 255.255.255.0 192.168.100.1 192.168.100.1 30 192.168.100.1 255.255.255.255 127.0.0.1 127.0.0.1 30 192.168.100.255 255.255.255.255 192.168.100.1 192.168.100.1 30 224.0.0.0 240.0.0.0 192.168.1.3 192.168.1.3 20 224.0.0.0 240.0.0.0 192.168.100.1 192.168.100.1 30 224.0.0.0 240.0.0.0 192.168.100.99 192.168.100.1 1 255.255.255.255 255.255.255.255 192.168.1.3 192.168.1.3 1 255.255.255.255 255.255.255.255 192.168.100.1 192.168.100.1 1 Default Gateway: 192.168.1.1 =========================================================================== Persistent Routes: None
そうそう、vlcのコマンドね。
vlcのttlは、cliで動かすと変更できるんだって。
GUIで設定して、最後に表示される文字列を、vlc.exe kirin.wmv の後に貼り付け、さらにその後に"--ttl 10"というようにttlを指定する。
C:\Program Files\VideoLAN\VLC>vlc kirin.wmv :sout=#transcode{vcodec=h264,vb=0,scale=0,acodec=mp4a,ab=32,channels=2,samplerate=8000}:rtp{dst=239.255.1.1,port=5004,mux=ts} :no-sout-rtp-sap :no-sout-standard-sap :sout-keep --ttl 10
kirin.wmv というのが動画ファイル名。 239.255.x.x というのは、マルチキャストのプライベートアドレス。
あとは、rtp以外で、udpとか、できるかやってみるか。 ttlか・・・ mroute で 239.255.1.1 がないなあとは思っていたのだが・・・ joinが出ているのは見たが、ttlが変わっていなかったとは・・・
ちなみに帯域は10Mbpsのethernetです。 10Mbpsで、十分です。
マルチキャストアドレスはけっこう見ることは見る。ospfとか、ripとか、UPnPとか。 今もキャプチャしてみたら、239.255.255.250 あてのSSDPとかいうのが出ている。 これは何だろう? たしかこれがUPnPなのである。
たしかにこのアドレスはマルチキャストアドレスであるが、私が言っているのはルーティングされる、ルータを越えるマルチキャストのことである。同じサブネット内であるなら、ほとんどブロードキャストと同じである。 ブロードキャストは全ホストが受信し、箱を開ける。マルチキャストはどうなのだろう?おそらく、ブロードキャストほどは負荷をかけないはず。箱のラベルだけ見て、開けずに捨てる感じか。
マルチキャストというのはまず、「ひとつの相手ではないがすべてでもない」というのがあり、さらに、「ルーティングできる」というのがある。これがなかなか説明されない。
unicastとbroadcastとmulticastの違いを説明するけど、ここで、broadcastはルーティングできないが、multicastはルーティングできる、ということをもっと強調すべきではないか。
マルチキャストルーティングとユニキャストルーティングの違いは何か。
そもそも、ルーティングとはどういうことか。 それは、next hopの指定であった。ルーターが知っているのは次の出口だけである。最終目的地は知らない。右から来たものを左へ受け流すだけである。
そのパケットがどこから来てどこへ行くのか(最終的にどこへ行くのか、何をしにいくのか)は関知しない。(することもあるが、それには手間がかかる。)
そうそう、マルチキャストルーティングするには、ユニキャストルーティングが必要。これも大事な前提だ。
ユニキャストとマルチキャストは用途によってどちらかを選ぶようなものではないのだ。 ・・・かな?
さて、マルチキャストでのポイントは、特定の相手にだけ送信するということだ。「特定の相手」とは?誰が決めるのか?送信者?違う。受信者が、「私のところに送って欲しい」と申し出る。 この申し出をおこなった人に対してのみ、送信をおこなうのである。この申し出のことを、joinという。
黒本より
cisco推奨のモードは sparse-dence-mode
2010/08/22
ストリームAPI
public_timelineは20tweetsずつしか取得できないのだが、実際にtweetされているのは600/secくらいあるそうだ。public_timelineではそのうちの20コだけを取得する。
しかしもっと多くのtweetを取得できるストリームapiというのがあるそうだ。それは取得できるtweetの量に応じて3種類に分かれていて、100%取得するにはtwitter社と契約する必要があるという。
まあ、誰も彼もが取得できるようになったらどうなるかは想像がつく。しかし、サービスを作ったらpublic_timelineのようなものは誰でもすべて表示するようにと考えるのが普通だろう。
それがないのは意図されたものか、パフォーマンス的に無理なのかは不明だが、twitterの大きな特徴のひとつである。
このために、アカウントを作った直後には何も表示されないという淋しいことになる。ところでそのstream APIだが、誰でも取得できるのは5%を表示するものだという。しかし、600tweets/secとしてその5%といったら、30コしかない。
しかしもっと多くのtweetを取得できるストリームapiというのがあるそうだ。それは取得できるtweetの量に応じて3種類に分かれていて、100%取得するにはtwitter社と契約する必要があるという。
まあ、誰も彼もが取得できるようになったらどうなるかは想像がつく。しかし、サービスを作ったらpublic_timelineのようなものは誰でもすべて表示するようにと考えるのが普通だろう。
それがないのは意図されたものか、パフォーマンス的に無理なのかは不明だが、twitterの大きな特徴のひとつである。
このために、アカウントを作った直後には何も表示されないという淋しいことになる。ところでそのstream APIだが、誰でも取得できるのは5%を表示するものだという。しかし、600tweets/secとしてその5%といったら、30コしかない。
2010/08/18
BSCIの準備 BGP
private ASは 64512-65535,
BGPはパスベクタ型(ディスタンスベクタではない)、
トランジットASとは通過するASでありこのASではBGPを使用すべきである、
BGPスピーカが持つテーブル
(1)ネイバーテーブル
(2)BGPフォワーディングテーブル
(3)routing table、
EBGPピアは原則として直接接続している必要がありTTL=1で送信され接続していないときはebgp-multihopコマンドを設定してTTLを増加させる
next hopは受信したnext-hop属性をそのまま転送するが、自身の出力IFのアドレスをnext hopにすることができる。
どういう場合にこれが必要になるか?黒本でも、あるサイトでも、EBGPネイバーから受け取った経路情報をiBGPネイバーに転送するときが紹介されている。
RTA(100)---RTB(200)---RTC(200)というような。
このとき、RTBからRTCにアップデートを送信するときに、next-hopがRTAのアドレスになり、RTCが到達できない、ということを防ぐために、RTBのアドレスをnext-hopとして通知する、と。
なんとなくわかったような気もするが、それくらい勝手にやってくんないかな、という気もする。
ということは、EBGPピアがいて、かつ、そのEBGPピアとネイバーになっていないiBGPピアとネイバーになっているときには必須の設定と言うことかな。つまりASBR(BGPでこう呼ぶのか知らないが)では必須の設定である、と。
マルチアクセスネットワークでは、勝手にやってくれるようだ。
IBGPスプリットホライズンとは、「IBGPピアから受信したルートをほかのIBGPピアにアドバタイズしない」というルールで、AS内でルートがループするのを回避する。これは設定しなくても勝手にやってくれる。
同期(synchronization);「BGPで取得したルートはIGPでも同じルートを取得しなければルーティングテーブルに反映せず、他のピアにアドバタイズもしない」
例
RTA(100)---RTB(200)---RTC(non BGP)---RTD(200)---RTE(300)
同期がない場合、RTEからの経路情報がRTAまで伝わるが、その情報に基づいて送信されたRTAからのパケットは、non BGPスピーカーのRTCが破棄してしまう。
同期をしなくても、RTCもBGPスピーカーにすればいい?もしくはRTBとRTCを直接接続する。
こんなケースはそんなにないとは思うが、あるAS内でIGPつまりOSPFとかRIPとかが動いてなくて、つまりAS内にあるルータ同士が通信できない状態があって、しかしiBGPはフルメッシュで有効になっていて、synchronizationが有効になっていると、ASBRのルータがEBGPピアから受け取った経路はAS内に転送されないことになる。(という問題が黒本にあった)
フルメッシュに接続すれば情報がもれなく行き渡るのはわかる。だが、それをやると通信量が増えるから、なるべくしたくない。
スリットホライズンは、フルメッシュでない状態でブラックホールが発生するのを防ぐための機能である。しかしそれはもれなくルーティングする機能ではない。
「通信できない経路だったら最初から伝えない」という機能であり、それによってアクセスできなかったルータにアクセスできるようになるわけではない。
そこでルートリフレクタ。やっぱりフルメッシュ接続というのは現実的な解決ではない。
ルートリフレクタという特別なルータを作って、そこから必要なルータ宛に経路情報を転送する。これだけ。転送先に設定は必要ない。EBGPピアから受け取ったら、とか、クライアントから受け取ったら、とか、非クライアントからだったら、とかを覚える必要はない。(そういう問題が黒本にあった)
リフレクタである以前にIGPルータでありIBGPルータでありEBGPルータなのだから、経路情報は転送するのが基本。ただし、スプリットホライズンの規則によりIBGPピアから受け取った経路情報はIBGPピアには転送されない。それだと困るので、ルートリフレクタで指定したクライアントには経路情報を転送する。
黒本には以下のように書いてある。
(2)は、いい。IBGPスプリットホライズンにより転送しないのが原則だがリフレクタを設定したのでクライアントには転送する。(3)も、いい。EBGPピアからのルートなので、スプリットホライズンの対象外だから転送する。問題は(1)だ。「クライアントのピア」というのは、IBGPピアである。IBGPピアからの経路情報は転送しないのがスプリットホライズンの原則であり、ルートリフレクタのクライアントには例外的に送信する。
ま、「こう書いてあるからこうなんだ」「やってみたらそうなったからそうなんだ」というのは嫌なんだけど。そういうのが嫌だから勉強してんだけど。まあ、いっか・・・
ピアのアドレスをloopbackにする場合は、マルチホップ扱いになる。ふーん・・・。これはやってみるべきだとは思うが、メンドクサイ・・・。
やってみた。loopbackなんだからupdate sourceも必要である。
BGPのnetworkコマンドはBGPを有効にするinterfaceを指定するのでは、ない。
networkコマンドで経路情報を送信するが、自分自身のルーティングテーブルにない経路情報は送信されない。
as-pathはpushされていく。最後のpathがリストの最上位にある。
(config-router)#bgp default local-preference 200
matchもsetもないルートマップは permit all を意味する。
MED(Multi-Exit-Discriminator)
show ip bgp では Metricと表示される(じゃあMetricと呼べよといいたい)
自ASに入ってくるトラフィックを制御することができる。
optional nontransitive attribute
(config-router)#default-metric xxxで設定する。
低い値が採用される。優先度は6番目で低い。
clear ip bgp * soft in
BGPセッションをリセットさせずに、ピアから受信したルートを一時的にメモリに格納する。
認証
R1(config-router)#neighbor 2.2.2.2 password unkotare
BGPはパスベクタ型(ディスタンスベクタではない)、
トランジットASとは通過するASでありこのASではBGPを使用すべきである、
BGPスピーカが持つテーブル
(1)ネイバーテーブル
(2)BGPフォワーディングテーブル
(3)routing table、
EBGPピアは原則として直接接続している必要がありTTL=1で送信され接続していないときはebgp-multihopコマンドを設定してTTLを増加させる
next hopは受信したnext-hop属性をそのまま転送するが、自身の出力IFのアドレスをnext hopにすることができる。
どういう場合にこれが必要になるか?黒本でも、あるサイトでも、EBGPネイバーから受け取った経路情報をiBGPネイバーに転送するときが紹介されている。
RTA(100)---RTB(200)---RTC(200)というような。
このとき、RTBからRTCにアップデートを送信するときに、next-hopがRTAのアドレスになり、RTCが到達できない、ということを防ぐために、RTBのアドレスをnext-hopとして通知する、と。
なんとなくわかったような気もするが、それくらい勝手にやってくんないかな、という気もする。
ということは、EBGPピアがいて、かつ、そのEBGPピアとネイバーになっていないiBGPピアとネイバーになっているときには必須の設定と言うことかな。つまりASBR(BGPでこう呼ぶのか知らないが)では必須の設定である、と。
マルチアクセスネットワークでは、勝手にやってくれるようだ。
IBGPスプリットホライズンとは、「IBGPピアから受信したルートをほかのIBGPピアにアドバタイズしない」というルールで、AS内でルートがループするのを回避する。これは設定しなくても勝手にやってくれる。
同期(synchronization);「BGPで取得したルートはIGPでも同じルートを取得しなければルーティングテーブルに反映せず、他のピアにアドバタイズもしない」
例
RTA(100)---RTB(200)---RTC(non BGP)---RTD(200)---RTE(300)
同期がない場合、RTEからの経路情報がRTAまで伝わるが、その情報に基づいて送信されたRTAからのパケットは、non BGPスピーカーのRTCが破棄してしまう。
同期をしなくても、RTCもBGPスピーカーにすればいい?もしくはRTBとRTCを直接接続する。
こんなケースはそんなにないとは思うが、あるAS内でIGPつまりOSPFとかRIPとかが動いてなくて、つまりAS内にあるルータ同士が通信できない状態があって、しかしiBGPはフルメッシュで有効になっていて、synchronizationが有効になっていると、ASBRのルータがEBGPピアから受け取った経路はAS内に転送されないことになる。(という問題が黒本にあった)
フルメッシュに接続すれば情報がもれなく行き渡るのはわかる。だが、それをやると通信量が増えるから、なるべくしたくない。
スリットホライズンは、フルメッシュでない状態でブラックホールが発生するのを防ぐための機能である。しかしそれはもれなくルーティングする機能ではない。
「通信できない経路だったら最初から伝えない」という機能であり、それによってアクセスできなかったルータにアクセスできるようになるわけではない。
そこでルートリフレクタ。やっぱりフルメッシュ接続というのは現実的な解決ではない。
ルートリフレクタという特別なルータを作って、そこから必要なルータ宛に経路情報を転送する。これだけ。転送先に設定は必要ない。EBGPピアから受け取ったら、とか、クライアントから受け取ったら、とか、非クライアントからだったら、とかを覚える必要はない。(そういう問題が黒本にあった)
リフレクタである以前にIGPルータでありIBGPルータでありEBGPルータなのだから、経路情報は転送するのが基本。ただし、スプリットホライズンの規則によりIBGPピアから受け取った経路情報はIBGPピアには転送されない。それだと困るので、ルートリフレクタで指定したクライアントには経路情報を転送する。
黒本には以下のように書いてある。
「クライアントのピアから受け取ったルートは、クライアントと非クライアントピアの両方に転送(1)」「非クライアントのピアから受け取ったルートは、クライアントだけに転送(2)」「EBGPピアから受け取ったルートは、クライアントと非クライアントピアの両方に転送(3)」
(2)は、いい。IBGPスプリットホライズンにより転送しないのが原則だがリフレクタを設定したのでクライアントには転送する。(3)も、いい。EBGPピアからのルートなので、スプリットホライズンの対象外だから転送する。問題は(1)だ。「クライアントのピア」というのは、IBGPピアである。IBGPピアからの経路情報は転送しないのがスプリットホライズンの原則であり、ルートリフレクタのクライアントには例外的に送信する。
だが、非クライアントピアにも転送する、とある。これは、「ルートリフレクタを設定するとそうする」ということなのだろうか?どうやら「ルートリフレクタはクライアントから受信した経路情報はIBGPスプリットホライズンの原則の例外で転送される」ということのようだ。
RFCの登場
5. OperationWhen a route is received by a RR, it selects the best path based onits path selection rule. After the best path is selected, it must dothe following depending on the type of the peer it is receiving thebest path from:1) A Route from a Non-Client peerReflect to all other Clients.2) A Route from a Client peerReflect to all the Non-Client peers and also to theClient peers other than the originator. (Hence theClient peers are not required to be fully meshed).3) Route from an EBGP peerSend to all the Client and Non-Client Peers.
ま、「こう書いてあるからこうなんだ」「やってみたらそうなったからそうなんだ」というのは嫌なんだけど。そういうのが嫌だから勉強してんだけど。まあ、いっか・・・
ピアのアドレスをloopbackにする場合は、マルチホップ扱いになる。ふーん・・・。これはやってみるべきだとは思うが、メンドクサイ・・・。
やってみた。loopbackなんだからupdate sourceも必要である。
BGPのnetworkコマンドはBGPを有効にするinterfaceを指定するのでは、ない。
networkコマンドで経路情報を送信するが、自分自身のルーティングテーブルにない経路情報は送信されない。
as-pathはpushされていく。最後のpathがリストの最上位にある。
(config-router)#bgp default local-preference 200
matchもsetもないルートマップは permit all を意味する。
MED(Multi-Exit-Discriminator)
show ip bgp では Metricと表示される(じゃあMetricと呼べよといいたい)
自ASに入ってくるトラフィックを制御することができる。
optional nontransitive attribute
(config-router)#default-metric xxxで設定する。
低い値が採用される。優先度は6番目で低い。
clear ip bgp * soft in
BGPセッションをリセットさせずに、ピアから受信したルートを一時的にメモリに格納する。
認証
R1(config-router)#neighbor 2.2.2.2 password unkotare
2010/08/07
BSCIの準備 再配送
デフォルトシードメトリック
RIPとEIGRP(IGRP):0(無限大)
OSPF:20(BGPからの再配送時は1)
IS-IS:0
BGP:IGPルーティングメトリック値を保持
RIPへの再配送
(config)#router rip
(config-router)#redistribute ospf metric 10 route-map 10
isisへの再配送
(config)#router ospf 1
(config-router)#redistribute isis level-1 metric-type 1 subnets
配送リストは特定のルートの送受信両方のフィルタリングに使える。
ルートマップはNATの変換対象のフィルタリングにも使える。
ルートマップはmatchとsetで定義する。
最後には暗黙のdenyがある。
ルートマップは適用されたIFの受信パケットが対象となる。
ルートマップが適用されているIFを表示するのはshow ip policy
debug ip policy
ripでneighborを指定するとunicastでupdateを送る。
選択式問題ばかりやっている人の思考法の欠陥。消去法で消していった結果、正しいかどうか自信がないがそれしか選択の余地がないので選択する。誤った確信にもとづきすべての選択を消去した場合、「設問がおかしいから解くに値しない」として自分で答えを出そうとしない。正しいと思っていることであっても、他に未知の用語や情報が存在するとそちらが正しいのではと確信が揺らぎ、自分が知らないことを選択する。
RIPとEIGRP(IGRP):0(無限大)
OSPF:20(BGPからの再配送時は1)
IS-IS:0
BGP:IGPルーティングメトリック値を保持
RIPへの再配送
(config)#router rip
(config-router)#redistribute ospf metric 10 route-map 10
isisへの再配送
(config)#router ospf 1
(config-router)#redistribute isis level-1 metric-type 1 subnets
配送リストは特定のルートの送受信両方のフィルタリングに使える。
ルートマップはNATの変換対象のフィルタリングにも使える。
ルートマップはmatchとsetで定義する。
最後には暗黙のdenyがある。
ルートマップは適用されたIFの受信パケットが対象となる。
ルートマップが適用されているIFを表示するのはshow ip policy
debug ip policy
ripでneighborを指定するとunicastでupdateを送る。
選択式問題ばかりやっている人の思考法の欠陥。消去法で消していった結果、正しいかどうか自信がないがそれしか選択の余地がないので選択する。誤った確信にもとづきすべての選択を消去した場合、「設問がおかしいから解くに値しない」として自分で答えを出そうとしない。正しいと思っていることであっても、他に未知の用語や情報が存在するとそちらが正しいのではと確信が揺らぎ、自分が知らないことを選択する。