RE: Framerelay fragment map-class option

From: Scott Vermillion (scott_ccie_list@it-ag.com)
Date: Sun Mar 02 2008 - 21:47:22 ARST


Yes, exactly. Fragmentation is not a negotiated capability/configuration
between endpoints. If you apply it in your map-class on one end of the
link, and traffic is presented to the interface which exceeds the configured
byte limit, fragmentation will take place, fragmentation headers will be
applied, and the traffic sent. Without that same configuration on the
opposite end, a bunch of garble hits the bit bucket. Hence, in all
likelihood, the reason your RIP traffic encountered some troubles...

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Han
Solo
Sent: Sunday, March 02, 2008 5:00 PM
To: Scott Vermillion
Cc: 'Groupstudy RS'
Subject: RE: Framerelay fragment map-class option

Oh I see so if you have that map class applied on both ends of the pvc
then they can assemble / reassemble. But you have to have it on both sides
if you put it on one side and not the other and a packet comes in bigger
than 125 , the node sending puts a fragment header on , but if other side
doesnt have it he cannot interpret it so it gets dropped ?

On Sun, 2 Mar 2008, Scott Vermillion wrote:

> Hey Han,
>
> Were you applying 'frame-relay fragment 125' on both ends of the link? We
> had this discussion not too long back when somebody configured
fragmentation
> but only on one end. IIRC, no fragmentation header need be applied if the
> payload is less than the configured fragment size, so you'd be OK in that
> case. But once your payload exceeds the configured value, fragmentation
> headers are applied and must be interpreted for reassembly opposite the
> link. I couldn't really find a good DocCD link that I liked (who can
these
> days?), but you may find this of interest:
>
>
http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a00801142d
> e.shtml
>
> It doesn't specifically cover the case of misconfigured fragmentation and
> its impact on IGPs, but it's at least a nice overview...
>
> Regards,
>
> Scott
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Han
> Solo
> Sent: Sunday, March 02, 2008 4:28 PM
> To: Groupstudy RS
> Subject: Framerelay fragment map-class option
>
> Hi I was doing a lab this weekend and ran into a conflicting qos option
> that broke rip.
>
> map-class frame-relay udp8000
> frame-relay cir 100000
> frame-relay bc 1000
> frame-relay mincir 100000
> frame-relay fair-queue
> frame-relay fragment 125
>
>
> With the above map-class applied to a frame-relay interface rip updates
> also exiting this interface now do not get received at the remote
> destination. So I am assuming that cmd is saying dont allow frame encap
> packets larger than 125 , when I remove the map class from the interface
> then all is well.
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Tue Apr 01 2008 - 07:53:52 ART