From: CCIE 4 Me (ccie4me@inbox.lv)
Date: Sat Mar 11 2006 - 20:35:54 GMT-3
Victor,
The main reason why one will use the 'IETF' encapulation is because the
third party vendor do not understand Cisco's 'CISCO' encapsulation so they
would not be able to decapsulate packets sent to them with 'CISCO'
encapsulation.
Cisco went a mile further and as such Cisco routers understands both 'IETF'
and 'CISCO' encapsulations. When this near-end router uses 'CISCO'
encapsulation, it merely means that at layer 2, it is going to encapsulate
all out going packets with "CISCO encapsulating Language engine" incoming
packets can be decapsulated even if they are coming as 'CISCO' or 'IETF' .
The same logic applies when the far end router have 'IETF' as its
'encapsulating language'
In essence, 'frame-relay encapsulation CISCO' or 'frame-relay encapsulation
IETF' only applies to how this router will encapsulate its outgoing packets
and not decapsulating incoming packets. Since third party routers do not
have the Cisco's proprietary 'CISCO encapsulation engine' in their products,
hence one have to use 'IETF' encapsulation when talking to them.
This is my lab results
R2 is using CISCO and R1 is using IETF. I did 'debug frame-relay packet' on
both routers...
http://www.cisco.com/warp/public/121/frf8modes.html#undframe
Rack1R2#
*Mar 1 02:55:53.611: Serial0(o): dlci 201(0x3091), pkt type 0x800(IP),
datagramsize 84
*Mar 1 02:56:19.327: Serial0(i): dlci 201(0x3091), NLPID 0x3CC(IP),
datagramsize 84
*Mar 1 02:56:23.615: Serial0(o): dlci 201(0x3091), pkt type 0x800(IP),
datagramsize 84
*Mar 1 02:56:38.911: Serial0(i): dlci 201(0x3091), NLPID 0x3CC(IP),
datagramsize 63
*Mar 1 02:56:38.923: Serial0(o): dlci 201(0x3091), pkt type 0x800(IP),
datagramsize 63
*Mar 1 02:56:39.171: Serial0(i): dlci 201(0x3091), NLPID 0x3CC(IP),
datagramsize 44
Rack1R1#
Mar 1 02:57:52.483: Serial0(i): dlci 102(0x1861), pkt type 0x800,
datagramsize 84
*Mar 1 02:58:18.147: Serial0(o): dlci 102(0x1861), NLPID 0x3CC(IP),
datagramsize 84
*Mar 1 02:58:22.487: Serial0(i): dlci 102(0x1861), pkt type 0x800,
datagramsize 84
*Mar 1 02:58:37.535: Serial0(i): dlci 102(0x1861), pkt type 0x800,
datagramsize 63
*Mar 1 02:58:37.547: Serial0(o): dlci 102(0x1861), NLPID 0x3CC(IP),
datagramsize 63
*Mar 1 02:58:37.791: Serial0(i): dlci 102(0x1861), pkt type 0x800,
datagramsize 44
*Mar 1 02:58:48.151: Serial0(o): dlci 102(0x1861), NLPID 0x3CC(IP),
datagramsize 84
You will notice that:
R1 is encapsulating all outgoing IP packets with 'CISCO' noticed the
etherType 0x800 and it is decapsulating all incoming packets with 'IETF'
(0x3CC) because R2 sent those packets using IETF encapsulation.
You will notice further that R2 is doing the complete opposite of what R1 is
doing.
Read that link I included above, lab this up and set your debugs loose and
you will come to the same conclusion.
HTH
cce4me.
----- Original Message -----
From: "Victor Cappuccio" <cvictor@protokolgroup.com>
To: "CCIE LAB" <ccielab@groupstudy.com>
Sent: Saturday, March 11, 2006 4:27 PM
Subject: Encapsualtion Frame-relay
> Hello people..
>
> Please, I wish to understand the frame-relay encapsulation command
> parameters.
> I know that this could affect me in Layer 2 Framming, Compression, LFI
> in QoS, etc..
>
> In doing IETF mode we move from the default Cisco frame-relay
> configuration, if the remote end is a non cisco device,
>
> But, why in this configuration the PVC is up?
>
> R1 ---- (FR SW) ---- R5
>
> Rack1R5#show run interface serial 0/0
> Building configuration...
>
> Current configuration : 81 bytes
> !
> interface Serial0/0
> no ip address
> encapsulation frame-relay
> cdp enable
> end
>
> Rack1R1#show run interface serial 0/0
> Building configuration...
>
> Current configuration : 74 bytes
> !
> interface Serial0/0
> no ip address
> encapsulation frame-relay IETF
> end
>
> As you can see
> Rack1R1#fr pvc | in ACTIVE
> DLCI = 105, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
>
> The DLCI to R5 is UP, and you can see that the encap in R5 is a Cisco
> Encapsualation
> Is there any link or any debug command that could help me understand a
> little bit better this?
>
>
> Thanks
> Victor.
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Apr 01 2006 - 10:07:38 GMT-3