トップ > 助け合いフォーラム >CCNA/CCNP関連 >最強WEB問題集CCNA >ロフレームリレーにおけるーカルDLCとリモートIPアドレスの関連付がいまいちよくわかりません。

Re: ロフレームリレーにおけるーカルDLCとリモートIPアドレスの関連付がいまいちよくわかりません。

この質問の投稿一覧へ

なし Re: ロフレームリレーにおけるーカルDLCとリモートIPアドレスの関連付がいまいちよくわかりません。

msg# 1.1
depth:
1
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2016-8-20 0:15
arashi1977  長老 居住地: 広島  投稿数: 1715
うーん、質問がいろいろとんでるので、どう説明したらよいのやら…

まず確認ですが
・ポイントツーポイントの意味合いはご存じですか？
・Inverse ARPの流れはご存じですか？
・フレームリレーでいうVC（Virtual Circuit）をどう理解されていますか？

まず1点目。
ポイントツーポイント接続、ということはそのままですが1対1接続なので、このインターフェースから出て行くパケットは必ず相手に到達するんですよね。
乱暴に言えば、「このインターフェースから送ったパケットはたとえネットワークアドレスが異なっていてレイヤ3的に到達性がなくても、レイヤ2的には到達する」わけです。
ですので
引用：
ローカルDLCI番号とリモートDTEのIPアドレスの関係をどの様にして紐付してているのでしょうか？
この環境ではひも付けする意味って無いですよね？紐付けしなくてもパケットは届きますし、届いたパケットをどう扱うかは相手側の仕事ですので。

次にInverse ARP。
引用：
3 RA(config-if)#encapsulation frame-relayコマンドにて
Inverse ARPが有効になりInverse ARPがリモートにﾘﾓｰﾄDTEのIPｱﾄﾞﾚｽ問合せを行うと理解すればいいのでしょうか？
Inverse ARPを誤解されているようです。Inverse ARP（逆向きARP）は相手にアドレスを問い合わせるのではなくて、自分のアドレスを通知します。もうちょっというと、LMIがActiveになったときにそのインターフェースから「俺のIPアドレスはXXだ」と通知すれば、VCをたどって接続した相手にIPアドレスの情報が到達するので、相手が「このローカルDLCIから送信すればこのIPアドレスに到達できる」ということを知ることができるわけです。

最後のVCについて。
ここは
引用：
そもそも、”ｻﾌﾞｲﾝﾀﾌｪｰｽ・ﾎﾟｲﾝ・ﾄﾂｰ・ﾎﾟｲﾝﾄ”のはPVCは一対一の接続なのでInverse ARPは機能しようと関係ない？？？

ｻﾌﾞｲﾝﾀﾌｪｰｽ−・ﾎﾟｲﾝ・ﾄﾂｰ・ﾎﾟｲﾝﾄはﾛｰｶﾙとﾘﾓｰﾄが単一のｻﾌﾞﾈｯﾄで構成されるので宛先は一つです。従って、ﾛｰｶﾙのDLCIから送信されたﾊﾟｹｯﾄはPVCの行先固定の仮想線路を通って必然的にﾘﾓｰﾄの”ﾌﾚｰﾑﾘﾚーｽｲｯﾁのDLCI”に辿り着く
とおっしゃっているので大丈夫だと思いますが、ローカルDLCIから送信すると、フレームリレー網がその送信元DLCIを基にして宛先までリレーしていくのです。そして最終的には網から出て相手に接続したインターフェースに、宛先DLCI番号をつけて渡すわけです。こうすると受け取った側はどのDLCIで受ければいいかわかりますので、サブインタフェースだろうが問題なくフレームを識別できるんですね。

となれば、やはりVCの両端がポイントツーポイントで接続されているのであれば、相手のアドレスをしる意味は無いですよね？

R1 s0/0.12 DLCI:102 --- FR網 --- DLCI:201 s0/0.12 R2

という構成で、
R1 s0/0.12: 192.168.12.1/30
R2 s0/0.12: 192.168.12.6/30
とアドレス割り当てしているのをイメージしてもらうと、R2は192.168.12.1からのパケットを受け取っても、自分のルーティングテーブルには192.168.12.4/30の直接接続経路しか存在せず、192.168.12.1（192.168.12.0/30）宛の経路が存在しないため、ルーティング不能として破棄します。
逆に、R2のアドレスが192.168.12.2/30となっていれば、同一サブネットなのでパケットを正しく送信できます。

ご質問の意図を読み違えていないことを願って…

投稿ツリー

  >フォーラム検索へ

Copyright (c) 2020 Ping-t All rights reserved.