RE: FR Encap

From: Luca Hall (lhall@setnine.com)
Date: Tue Apr 15 2008 - 13:39:34 ART


Thanks, I was going crazy trying to figure that out.

> Hi Luca,
> It is surely possible to have two different encapsulations between 2 ends
> of the routers and still they can talk because of the Rotuers' behavior
> that they support both of the Encapsulations and when they see the packet
> coming with different encapsulation they understand that packet and
> process according to the incoming 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'
>
> http://cciepursuit.wordpress.com/2007/09/14/frame-relay-encapsulation-mismatches/
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Luca Hall
> Sent: Tuesday, April 15, 2008 19:53
> To: ccielab@groupstudy.com
> Subject: FR Encap
> Importance: Low
>
> r4 and r5 connected to the frame-relay switch:
>
> r4(s0/0) -- fr-sw -- (s0/0)r5
>
> r4 uses fr encapsulation of cisco:
>
> r4#sh int s0/0 | in Encap
> Encapsulation FRAME-RELAY, loopback not set
> r4#sh run int s0/0
>
> interface Serial0/0
> ip address 45.1.1.4 255.255.255.0
> encapsulation frame-relay
> no ip route-cache cef
> no ip route-cache
> ip ospf network non-broadcast
> ip ospf priority 0
> frame-relay map ip 45.1.1.5 405
> no frame-relay inverse-arp
> end
>
> r4#sh ip int brie | i up
> Serial0/0 45.1.1.4 YES manual up up
>
> r5 uses frame-relay encapsulation of ietf:
>
> r5#sh int s0/0 | in Encap
> Encapsulation FRAME-RELAY IETF, loopback not set
> r5#sh run int s0/0
>
> interface Serial0/0
> ip address 45.1.1.5 255.255.255.0
> encapsulation frame-relay IETF
> no ip route-cache cef
> no ip route-cache
> ip ospf network non-broadcast
> frame-relay map ip 45.1.1.4 504 IETF
> no frame-relay inverse-arp
> end
>
> r5#sh ip int brief | in up
> Serial0/0 45.1.1.5 YES manual up up
>
> From everything I have ever read these two shouldn't be able to talk
> as encapsulation must match between cpe's, but they can:
>
> r4#ping 45.1.1.5
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 45.1.1.5, timeout is 2 seconds:
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 60/60/64 ms
>
> I have shut the interfaces in every way I can think of and then saved and
> reloaded them both and I still have the same result. I cant figure out why
> they can still talk.
>
> Also anyone know a command similar to `debug ip packet dump` for frame
> so you could put the frame into a analyzer?
>
> Thanks
>
>
> Pass the CCIE in six weeks, Guaranteed!
> http://www.certscience.com/CCIE
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Pass the CCIE in six weeks, Guaranteed!
http://www.certscience.com/CCIE



This archive was generated by hypermail 2.1.4 : Thu May 01 2008 - 08:25:51 ART