From: Scott Vermillion (scott_ccie_list@it-ag.com)
Date: Sun Mar 02 2008 - 21:35:02 ARST
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.
This archive was generated by hypermail 2.1.4 : Tue Apr 01 2008 - 07:53:52 ART