ロフレームリレーにおけるーカルDLCとリモートIPアドレスの関連付がいまいちよくわかりません。
- フォーラムは新サイトへ移行しました。
- このフォーラムではゲスト投稿が禁止されています
ichirou3420
投稿数: 4
投稿数: 4
問題ID： 15298
問題ID： 12714
************************************************************
フレームリレーにおけるリモートとローカル間でのアドレス解決、→ローカルDLCとリモートIPアドレスの関連付がいまいちよくわかりません。
************************************************************
サブインターフェースにローカルDLCI番号を設定してポイント・ツー・ポイント接続設定を行う場合にローカルDLCI番号とリモートDTEのIPアドレスの関係をどの様にして紐付してているのでしょうか？
3 RA(config-if)#encapsulation frame-relayコマンドにて
Inverse ARPが有効になりInverse ARPがリモートにﾘﾓｰﾄDTEのIPｱﾄﾞﾚｽ問合せを行うと理解すればいいのでしょうか？
或いは・・・・・↓↓
そもそも、”ｻﾌﾞｲﾝﾀﾌｪｰｽ・ﾎﾟｲﾝ・ﾄﾂｰ・ﾎﾟｲﾝﾄ”のはPVCは一対一の接続なのでInverse ARPは機能しようと関係ない？？？
⇒ｻﾌﾞｲﾝﾀﾌｪｰｽ−・ﾎﾟｲﾝ・ﾄﾂｰ・ﾎﾟｲﾝﾄはﾛｰｶﾙとﾘﾓｰﾄが単一のｻﾌﾞﾈｯﾄで構成されるので宛先は一つです。従って、ﾛｰｶﾙのDLCIから送信されたﾊﾟｹｯﾄはPVCの行先固定の仮想線路を通って必然的にﾘﾓｰﾄの”ﾌﾚｰﾑﾘﾚーｽｲｯﾁのDLCI”に辿り着くのでInverse ARPによるｱﾄﾞﾚｽ解決は不必要と理解すればいいのでしょうか？？？？
★別の言い方をすれば、ﾛｰｶﾙとﾘﾓｰﾄ双方のDTE側にて出力ｲﾝﾀﾌｪｰｽと ﾛｰｶﾙDLCI番号が指定されておればいい。。
また、ﾛｰｶﾙDLCIからﾘﾓｰﾄのDLCI間のｱﾄﾞﾚｽ解決はﾌﾚｰﾑﾘﾚｰ網にお任 せなのでﾌﾞﾗｯｸ ボックスと考えてよい、と理解すればいいので しょうか？。
(config-if)#frame-relay map ip ﾘﾓｰﾄIPｱﾄﾞﾚｽ 100 broadcast
上記↑↑の場合はｽﾀﾃｨｯｸにﾘﾓｰﾄIPとDLCIを関連付けいるので静的に関連付されていると理解できるのでます。（この場合はInverse ARPは無効化されている）
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
設定例）：ﾘﾓｰﾄIPとﾛｰｶﾙDLCIとの関連付の痕跡が見当たりません。
1 RA(config)#interface Serial0/0
2 RA(config-if)#no ip address
3 RA(config-if)#encapsulation frame-relay
4 RA(config-if)interface Serial10/0.1 point-topoint
5 RA(config-subif)#ip address 10.0.0.0 255.255.255.0
6 RA(config-subif)#frame-relay intterface-dlci 120
3 ﾚｲﾔ2のｶﾌﾟｾﾙ化ﾀｲﾌﾟをﾌﾚｰﾑﾘﾚｰに指定
4 ｻﾌﾞｲﾝﾀﾌｪｰｽ"Serial10/0.1"のｱﾄﾞﾚｽを設定
5 ｻﾌﾞｲﾝﾀﾌｪｰｽ"Serial10/0.1"のﾀｲﾌﾟを"point-topoint"に設定
問題ID： 12714
************************************************************
フレームリレーにおけるリモートとローカル間でのアドレス解決、→ローカルDLCとリモートIPアドレスの関連付がいまいちよくわかりません。
************************************************************
サブインターフェースにローカルDLCI番号を設定してポイント・ツー・ポイント接続設定を行う場合にローカルDLCI番号とリモートDTEのIPアドレスの関係をどの様にして紐付してているのでしょうか？
3 RA(config-if)#encapsulation frame-relayコマンドにて
Inverse ARPが有効になりInverse ARPがリモートにﾘﾓｰﾄDTEのIPｱﾄﾞﾚｽ問合せを行うと理解すればいいのでしょうか？
或いは・・・・・↓↓
そもそも、”ｻﾌﾞｲﾝﾀﾌｪｰｽ・ﾎﾟｲﾝ・ﾄﾂｰ・ﾎﾟｲﾝﾄ”のはPVCは一対一の接続なのでInverse ARPは機能しようと関係ない？？？
⇒ｻﾌﾞｲﾝﾀﾌｪｰｽ−・ﾎﾟｲﾝ・ﾄﾂｰ・ﾎﾟｲﾝﾄはﾛｰｶﾙとﾘﾓｰﾄが単一のｻﾌﾞﾈｯﾄで構成されるので宛先は一つです。従って、ﾛｰｶﾙのDLCIから送信されたﾊﾟｹｯﾄはPVCの行先固定の仮想線路を通って必然的にﾘﾓｰﾄの”ﾌﾚｰﾑﾘﾚーｽｲｯﾁのDLCI”に辿り着くのでInverse ARPによるｱﾄﾞﾚｽ解決は不必要と理解すればいいのでしょうか？？？？
★別の言い方をすれば、ﾛｰｶﾙとﾘﾓｰﾄ双方のDTE側にて出力ｲﾝﾀﾌｪｰｽと ﾛｰｶﾙDLCI番号が指定されておればいい。。
また、ﾛｰｶﾙDLCIからﾘﾓｰﾄのDLCI間のｱﾄﾞﾚｽ解決はﾌﾚｰﾑﾘﾚｰ網にお任 せなのでﾌﾞﾗｯｸ ボックスと考えてよい、と理解すればいいので しょうか？。
(config-if)#frame-relay map ip ﾘﾓｰﾄIPｱﾄﾞﾚｽ 100 broadcast
上記↑↑の場合はｽﾀﾃｨｯｸにﾘﾓｰﾄIPとDLCIを関連付けいるので静的に関連付されていると理解できるのでます。（この場合はInverse ARPは無効化されている）
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
設定例）：ﾘﾓｰﾄIPとﾛｰｶﾙDLCIとの関連付の痕跡が見当たりません。
1 RA(config)#interface Serial0/0
2 RA(config-if)#no ip address
3 RA(config-if)#encapsulation frame-relay
4 RA(config-if)interface Serial10/0.1 point-topoint
5 RA(config-subif)#ip address 10.0.0.0 255.255.255.0
6 RA(config-subif)#frame-relay intterface-dlci 120
3 ﾚｲﾔ2のｶﾌﾟｾﾙ化ﾀｲﾌﾟをﾌﾚｰﾑﾘﾚｰに指定
4 ｻﾌﾞｲﾝﾀﾌｪｰｽ"Serial10/0.1"のｱﾄﾞﾚｽを設定
5 ｻﾌﾞｲﾝﾀﾌｪｰｽ"Serial10/0.1"のﾀｲﾌﾟを"point-topoint"に設定
arashi1977
居住地: 広島
投稿数: 1715
居住地: 広島
投稿数: 1715
うーん、質問がいろいろとんでるので、どう説明したらよいのやら… 
まず確認ですが
・ポイントツーポイントの意味合いはご存じですか？
・Inverse ARPの流れはご存じですか？
・フレームリレーでいうVC（Virtual Circuit）をどう理解されていますか？
まず1点目。
ポイントツーポイント接続、ということはそのままですが1対1接続なので、このインターフェースから出て行くパケットは必ず相手に到達するんですよね。
乱暴に言えば、「このインターフェースから送ったパケットはたとえネットワークアドレスが異なっていてレイヤ3的に到達性がなくても、レイヤ2的には到達する」わけです。
ですので
引用：この環境ではひも付けする意味って無いですよね？紐付けしなくてもパケットは届きますし、届いたパケットをどう扱うかは相手側の仕事ですので。
次にInverse ARP。
引用：Inverse ARPを誤解されているようです。Inverse ARP（逆向きARP）は相手にアドレスを問い合わせるのではなくて、自分のアドレスを通知します。もうちょっというと、LMIがActiveになったときにそのインターフェースから「俺のIPアドレスはXXだ」と通知すれば、VCをたどって接続した相手にIPアドレスの情報が到達するので、相手が「このローカルDLCIから送信すればこのIPアドレスに到達できる」ということを知ることができるわけです。
最後のVCについて。
ここは
引用：とおっしゃっているので大丈夫だと思いますが、ローカル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となっていれば、同一サブネットなのでパケットを正しく送信できます。
ご質問の意図を読み違えていないことを願って…
まず確認ですが
・ポイントツーポイントの意味合いはご存じですか？
・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ｱﾄﾞﾚｽ問合せを行うと理解すればいいのでしょうか？
最後のVCについて。
ここは
引用：
そもそも、”ｻﾌﾞｲﾝﾀﾌｪｰｽ・ﾎﾟｲﾝ・ﾄﾂｰ・ﾎﾟｲﾝﾄ”のはPVCは一対一の接続なのでInverse ARPは機能しようと関係ない？？？
ｻﾌﾞｲﾝﾀﾌｪｰｽ−・ﾎﾟｲﾝ・ﾄﾂｰ・ﾎﾟｲﾝﾄはﾛｰｶﾙとﾘﾓｰﾄが単一のｻﾌﾞﾈｯﾄで構成されるので宛先は一つです。従って、ﾛｰｶﾙのDLCIから送信されたﾊﾟｹｯﾄはPVCの行先固定の仮想線路を通って必然的にﾘﾓｰﾄの”ﾌﾚｰﾑﾘﾚーｽｲｯﾁの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となっていれば、同一サブネットなのでパケットを正しく送信できます。
ご質問の意図を読み違えていないことを願って…
