WAN ルーティングについて (Ask the Expert)
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
2013-10-25 02:49 PM 2019-03-22 07:21 AM 更新
シスコの技術サポートエンジニアへ質問して疑問を解決できる「エキスパートに質問」へようこそ!
ここでは、シスコのエキスパートからのアドバイスや最新の情報が得られる場として気軽に質問してみてください。
担当エキスパート:掛橋 裕将 (Hiromasa Kakehashi)
Cisco Japan TAC のカスタマーサポートエンジニアとして、LAN スイッチ製品、ルータ製品のテクニカルサポートを行っています。
現在は主に、ルーティングプロトコルや、QoS 等のトラブルシューティングを担当しています。
ディスカッション開催期間: 2013年11月4日(月)~11月17日(日)
[質問の回答方法]
サポートコミュニティへCisco.comIDでログインすると、この説明の右下に「返信」ボタンが表示されます。クリックすると投稿欄が表示されますので、質問をご記入ください。最後に「メッセージの投稿」をクリックすると質問が送信され、完了となります。
もし1つの質疑応答が進行していても、他の新しい質問を同じスレッド内に投稿いただいて問題ありません。
この「エキスパートに質問」のディスカッションスレッドに届いた質問は担当のTACエキスパートが回答しますがすべての質問に返信できないかもしれません。
返信が得られずに開催期間が終了して残ってしまった質問については、サポートコミュニティ事務局が今回の技術カテゴリの通常のディスカッション フォーラムへ再掲載し、有用な情報の展開へとつなげていきます。
エキスパートから返信が得られた質問については、評価機能でその回答が適切であったかをエキスパートへぜひ伝えてください。
あなたからの質問だけでなく、他コミュニティのメンバーから寄せられた質問がどう発展したかをのぞきに、ぜひこのフォーラムへ再度訪問されることをお待ちしております!
[エキスパートからの回答について]
質 問の投稿から原則数日以内に回答できるよう努めます。内容によっては、検証や確認に時間がかかる場合もありますのでご了承ください。質問の内 容 によっては、エキスパートの担当範囲外の場合もございます。その際はサポートコミュニティ事務局、もしくは適切な担当から回答いたします。
ディスカッション期間を過ぎてからの投稿は、事務局より通常コミュニティへ投稿いただくようお願いさせていただくようになりますことも合わせてご理解ください。
- ラベル:
-
ルーティング
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
2013-11-08 05:52 PM
お世話になります。tanakaです。
当方、社内向けルータに、決まった設定をする程度の知識しかありませんがご了承ください。
現在、CISCO892FSPルータにて下記現象が発生しているのですが、原因が全く分かりません。
現象:LAN側からWAN側へのマルチキャストデータが途中で転送されなくなる。
詳細:下記システム構成にて、PC1からマルチキャストデータを(1024byteを100パケット)送信したとき、
PC2で12パケットしか受信できない。
(WAN側でキャプチャしてみても、12パケットしかキャプチャできませんでした。)
その後、すぐにデータを再送してみても、受信することはできず、
大分時間を空けてからデータを再送すると、また数パケット受信できたりします。
PC1 →(Ge0)CISCO892FSPルータ(Ge9)→ PC2
↑Vlan1 ↑WAN
ちなみに、同じテストプログラムを使用して、PC2(WAN側)からPC1(LAN側)へマルチキャストデータを送った場合は、
問題なく全て受信することができます。
全く転送されないなら、設定の問題かとも思うのですが、
一部のみ受信できたりできなくなったりするため全く分かりません。
マルチキャストの設定は下記で問題ないと考えてますが、(CISCO881ではこれで動いてました。)
これ以外に必要な設定があるのでしょうか?
一部のみ送信できないことから、何かバッファ領域を設定する必要があるのでしょうか?
ip multicast-routing
ip pim dense-mode ←各インターフェースにて設定。
宜しくお願いいたします。
以上

- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
2013-11-10 08:41 PM
tanaka さん
こんにちは。ご質問ありがとうございます。
PIM DM をご利用ですね。設定はご認識のとおりです。
PC1 →(Ge0)CISCO892FSPルータ(Ge9)→ PC2↑Vlan1 ↑WAN
この構成の場合、ip pim dense-mode は Vlan1 と Ge9 に設定します。
問題を切り分けるために、まずは show ip mroute count コマンドを使って
マルチキャストのパケットフローを確認してみるのがよいと思います。
以下、コマンドの出力例です。
この例では、192.168.1.1 のアドレスを持つマルチキャストソースから、
224.1.1.1 を宛先とするマルチキャストを送信しています。
Router#show ip mroute count
Use "show ip mfib count" to get better response time for a large number of mroutes.
IP Multicast Statistics
3 routes using 1696 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 224.1.1.1, Source count: 1, Packets forwarded: 6, Packets received: 953
Source: 192.168.1.1/32, Forwarding: 6/0/28/0, Other: 953/0/947
事象発生中に数回コマンド結果を取得して、カウンタの変化を確認します。
マルチキャストが正常に流れている場合は、
Packets received と Forwarding(Pkt Count)がカウントアップします。
お知らせ頂いた症状からあり得そうなシナリオについて記載します。
1) 結果に対象のマルチキャストのエントリが存在しない もしくは、Packets received のカウンタが変化しない
この場合は、マルチキャストパケットがルータに届いていない可能性があります。
show interface コマンドや、パケットキャプチャ等で PC1 と ルータ間の
パケットフローを確認してみてください。
2) Packets received と Other drops がカウントアップしている
この場合は、ルータと PC2 間の IGMP による問題である可能性が高いと思います。
show ip igmp groups コマンドを使ってルータがマルチキャストレシーバを認識しているか確認してください。
192.168.2.2 のアドレスを持つマルチキャストレシーバから
224.1.1.1 への IGMPメンバシップレポートが送信された後の出力例は以下のようになります。
Router#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
224.1.1.1 Ethernet0/1 00:00:06 00:02:53 192.168.2.2
対象のマルチキャストのエントリが存在していないようであれば、
IGMPの問題と判断してよいと思います。その場合は、パケットキャプチャでルータと
PC2 の間の IGMPパケットのシーケンスに異常が無いか確認してみてください。
何等かの原因で PC2 が IGMPメンバシップレポートを送信できない場合には、
ルータの Ge9 に下記設定を追加することで強制的にマルチキャストを転送させることも可能です。
(config-if) ip igmp static-group x.x.x.x
その他、マルチキャストが流れない症状の一般的な原因として RPF(Reverse Path Forwarding)による
パケットドロップがありますが、お知らせ頂いた構成で発生する可能性は低いと考えられますので割愛します。
マルチキャストのトラブルシューティングに関しては下記ページも参考にしてください。
PIM SM について記載された資料ですが、トラブルシューティングのポイントは PIM DM にも当てはまります。
IP マルチキャストのトラブルシューティング
http://www.cisco.com/cisco/web/support/JP/111/1116/1116147_mcast_trsh.html
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
2013-11-15 11:13 AM
お世話になります、
現在 Cisco ルータについて勉強している Ryouta Kawamitsu と申します。
OSPFのロードバランシングについて質問させてください。
ロードバランシングでは、使用するインターフェースをどのように決定しているのでしょうか。
インターネットなどで調べていると、ラウンドロビン方式で決定しているという情報はあったのですが、その他に決定方法はあるのでしょうか。
よろしくお願いいたします。

- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
2013-11-15 10:31 PM
Kawamitsu さん
ご質問ありがとうございます。
ロードバランシングは、ルーティングテーブル上に同じ宛先への経路が複数あると有効になります。
トラフィックが、それらの経路を使ってどのようにロードバランスされるかは、パケットの転送方式によって
異なります。
- プロセススイッチング パケットごとのロードバランス
- ファストスイッチング 宛先IPアドレスごとのロードバランス
- CEF 送信元IPアドレスと宛先IPアドレスペアごとのロードバランス
( 設定変更によりパケットごとのロードバランスも可 )
※ほとんどのプラットフォームではデフォルトで CEF が有効になっています。
ロードバランシングに使われる経路の数は、スタティックルートや、ルーティングプロトコルによって
ルーティングテーブルにインストールされた経路の数で決まります。
OSPF を含むほとんどのルーティングプロトコルは同じメトリック、同じ宛先の経路をデフォルトで
最大 4つインストールします。この経路数は maximum-paths コマンドにより変更可能です。
更に詳細な仕組みが知りたい場合は、以下のページが参考になると思います。
CEF を使用したパラレル リンクでのロード バランシングに関するトラブルシューティング
http://www.cisco.com/cisco/web/support/JP/102/1021/1021118_loadbal_cef-j.html
ロード バランシングの機能のしくみ
http://www.cisco.com/cisco/web/support/JP/100/1007/1007797_46-j.html
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
2013-11-17 09:23 AM
Kakehashi様、
回答、さらに紹介していただいたページを読み、ロードバランシグへの理解をさらに深めることができました。
ご回答いただきありがとうございました。
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
2013-11-15 12:15 PM
お世話になります。touharaと申します。
CHAPのチャレンジについて質問です。
CHAPのRFC(1994)で「At random intervals, the authenticator sends a new challenge to the peer」とありますが、
debugコマンドの出力では、最初の認証時の一度だけしか確認できませんでした。
ランダムな間隔で新しいチャレンジが送信されるタイミングを
確認できる方法はありますでしょうか。
よろしくお願いいたします。

- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
2013-11-18 09:00 AM
touhara さん
ご質問ありがとうございます。
RFC1994 を確認してみました。touhara さんが抜粋されている
CHAP の Re-authentication に関する動作は、任意の要求事項になっていますね。
2. Challenge-Handshake Authentication Protocol
The Challenge-Handshake Authentication Protocol (CHAP) is used to
periodically verify the identity of the peer using a 3-way handshake.
This is done upon initial link establishment, and MAY be repeated
anytime after the link has been established.
(省略)
4. At random intervals, the authenticator sends a new challenge to
the peer, and repeats steps 1 to 3.
IOS にはRe-authentication の動作は実装されていません。
( PPPセッション確立後の対向装置からのチャレンジには応答します )
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
2013-11-15 04:33 PM
お世話になります。Sagaと申します。
WAN側疑似MACアドレスについての質問です。
疑似MACアドレスはデフォルトで使用しないになっていると思います。
あまり使用することを薦められてないようですが、
疑似MACアドレスとはそもそも何の為にあるのでしょうか?

- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
2013-11-18 10:16 AM
Saga さん
ご質問ありがとうございます。
あまり聞いたことの無い機能だったのでネットで調べてみました(笑)
サービスプロバイダが特定のMACアドレスからの接続のみを許可しているような
場合に使用される機能みたいですね。
- サービスプロバイダから配られた機材の MAC アドレスのみ接続が許可されている
- 最初の接続で使用したルータや PC の MAC アドレスのみ接続が許可されている
このような場合、ルータの買い換えや、故障による交換等で MAC アドレスが変わると、
インターネットに接続できなくなってしまいます。WAN側疑似MACアドレスは、こういったときのために
機器交換前の MAC アドレスの設定を可能にすることを目的とした機能なんじゃないかと推測します。
Cisco のルータでも mac-address コマンドを使用することでMACアドレスを設定できます。
Router(config-if)#mac-address ?
H.H.H MAC address
同じネットワークセグメント上に重複する MAC アドレスがあると
正常に通信できませんので、特別な理由が無い限り使用しないほうがよいと思います。
