From: Luis Rueda (luis.rueda@comsat.com.co)
Date: Sun Apr 30 2006 - 19:29:23 GMT-3
Godswill,
What I'm trying to understand is, what happens if this situation appears
at the CCIE lab, most likely if the encapsulation per dlci mapping is
not done correctly, you will loose the points for the setting up of the
frame-relay cloud, don't you think so ? The question is.... Since R2 is
communication with R3 through R1, does R1 de-encapsulate packets and
then encapsulate them again ? If this is the case, R2 - R1 mapping
should be done with cisco's encapsulation and only the mapping towards
R3 should be done with ietf. If R1 just switches (layer2) packets, then
you have to correctly configure the encapsulation for every packet sent
to R3 on R2 (this means put the ietf at the end of the frame-relay map
on R2 for R3's ip address.
So which one will be ? 1st or 2nd option ?
Regards,
Luis
-----Mensaje original-----
De: CCIE 4 Me [mailto:ccie4me@inbox.lv]
Enviado el: Sunday, April 30, 2006 5:24 PM
Para: Luis Rueda; ccielab@groupstudy.com
Asunto: Re: FRAME-RELAY ENCAPSULATION QUESTION
Luis,
I am trying hard to understand what you are looking to achieve here.
A Cisco Router will understand both IETF and Cisco encapsulation, it
will not make any different what encapsulation, you are using to send
the frame packets to it.
However, if the other end is non-Cisco, then you have to use IETF for it
to understand what your Cisco Router is sending, on the flip side, your
Cisco router will understand what the non-cisco router is sending to it,
because it can de-encapsulate IETF packets, but the frame relay link
will not come up, because a complete bidirectional handshake have not be
taken place.
In these days of autosensing, if there is no restriction or requirement
indicating otherwise, 'encapsulation frame-relay' is enough and if you
are required to do manual mapping or exclude 'Inverse-ARP, 'frame relay
map ip n.n.n.n <dlci> broadcast' will be good enough.
Both options you stated below should work fine on a Cisco plateform.
HTH
Godswill Oletu
----- Original Message -----
From: "Luis Rueda" <luis.rueda@comsat.com.co>
To: <ccielab@groupstudy.com>
Sent: Sunday, April 30, 2006 2:24 PM
Subject: FRAME-RELAY ENCAPSULATION QUESTION
> Hi all,
>
> I have a question for the following scenario, let's say we have 3
> routers, R1, R2, R3.
>
> The following topology is used (Hub-Spoke) R1 is the hub, and R2 and
R3
> area spokes. If R3 is set with the following config:
>
> Interface serial0/0
> encapsulation frame-relay ietf
>
> How should I configure R2 and R1 with frame-relay map statements in
> order to match the correct encapsulation for R3 ?
>
> Should I set the following config:
>
> R1 (HUB)
> Interface serial0/0
> encapsulation frame-relay
> ip address 200.200.200.1 255.255.255.0
> frame-relay map ip 200.200.200.3 103 broadcast ietf
> frame-relay map ip 200.200.200.2 102 broadcast
>
> R2 (SPOKE -CISCO ENCAPSULATION-)
> Interface serial0/0
> encapsulation frame-relay
> ip address 200.200.200.2 255.255.255.0
> frame-relay map ip 200.200.200.1 201 broadcast
> frame-relay map ip 200.200.200.3 201 broadcast
>
> R3 (SPOKE -IETF ENCAPSULATION-)
> Interface serial0/0
> encapsulation frame-relay IETF
> ip address 200.200.200.3 255.255.255.0
> frame-relay map ip 200.200.200.1 301 broadcast
> frame-relay map ip 200.200.200.2 301 broadcast
>
> Or should I set it up this way:
>
> R1 (HUB)
> Interface serial0/0
> encapsulation frame-relay
> ip address 200.200.200.1 255.255.255.0
> frame-relay map ip 200.200.200.3 103 broadcast ietf
> frame-relay map ip 200.200.200.2 102 broadcast
>
> R2 (SPOKE -CISCO ENCAPSULATION-)
> Interface serial0/0
> encapsulation frame-relay
> ip address 200.200.200.2 255.255.255.0
> frame-relay map ip 200.200.200.1 201 broadcast
> frame-relay map ip 200.200.200.3 201 broadcast ietf
>
> R3 (SPOKE -IETF ENCAPSULATION-)
> Interface serial0/0
> encapsulation frame-relay IETF
> ip address 200.200.200.3 255.255.255.0
> frame-relay map ip 200.200.200.1 301 broadcast
> frame-relay map ip 200.200.200.2 301 broadcast
>
> Regards,
>
> Luis
>
>
This archive was generated by hypermail 2.1.4 : Mon May 01 2006 - 11:41:59 GMT-3