From: Scott Vermillion (scott_ccie_list@it-ag.com)
Date: Sun Mar 02 2008 - 21:57:48 ARST
Not when you just have the one DLCI pulled down to that one subinterface...
-----Original Message-----
From: Han Solo [mailto:hansolo@ccieunix.com]
Sent: Sunday, March 02, 2008 5:13 PM
To: Scott Vermillion
Cc: 'Groupstudy RS'
Subject: RE: Framerelay fragment map-class option
Good one thanks Scott. I have busting over that one all day (even sad to
say I thought my dte/dce cable was bad and swapped out ( how embarrasing }
the other thing related to this is there a diff when you apply a frame
relay map class via these methods:
interface Serial 0/0.1
frame-relay interface-dlci 101
class stuff
or
interface Serial 0/0.1
frame-relay class stuff
On Sun, 2 Mar 2008, Scott Vermillion wrote:
> 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
>
> _______________________________________________________________________
> 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 : Tue Apr 01 2008 - 07:53:52 ART