From: CCIE 4 Me (ccie4me@inbox.lv)
Date: Sat Mar 11 2006 - 20:50:59 GMT-3
typo.... I meant to sate jus as you noticed in the debugs tha....
"R2 is encapsulating all outgoing IP packets with 'CISCO' noticed the
etherType 0x800 and it is decapsulating all incoming packets with 'IETF'
(0x3CC) because R1 sent those packets using IETF encapsulation."
----- Original Message -----
From: "CCIE 4 Me" <ccie4me@inbox.lv>
To: "Victor Cappuccio" <cvictor@protokolgroup.com>; "CCIE LAB"
<ccielab@groupstudy.com>
Sent: Saturday, March 11, 2006 6:35 PM
Subject: Re: Encapsualtion Frame-relay
> 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
>
> _______________________________________________________________________
> 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