1. Home
  2. Cisco Systems
  3. Frame relay MTUs driving me nuts - what's going on???

Frame relay MTUs driving me nuts - what's going on???

I have a link running frame relay. If it is set up as a simple link only very small packets will pass across - circa 62 bytes. Any larger packets seem to be silently dropped. Found when EIGRP would only partially form neighborships then tested with ping packets until found the size permitted.

The puzzler is that if I enable frame relay fragmentation packets will pass OK even if the fragment sizes are larger - much larger - than 62 bytes.

Simple question: How can the link pass large fragments when it fails to pass large packets???

If anyone can tell me what FR does when fragmenting that allows large fragments to pass I'd be grateful. Our router interfaces and subinterfaces show MTUs as 1500. The telco advises their circuits are ignorant of packet size.......

Salient config at the ends (just one end shown):

interface Serial0/0/0 encapsulation frame-relay frame-relay traffic-shaping frame-relay lmi-type cisco ! interface Serial0/0/0.1 point-to-point ip address 10.1.1.1 255.255.255.252 frame-relay interface-dlci 100 class voice-data ! map-class frame-relay voice-data frame-relay cir 284000 frame-relay bc 1000 frame-relay mincir 128000 frame-relay fragment 64 frame-relay adaptive-shaping becn frame-relay fecn-adapt service-policy output Remote-WAN ! policy-map Remote-WAN class voice priority 96 class class-default fair-queue

Possibly relevant config on the telco's FR switch:

interface Serial0/0 encapsulation frame-relay no fair-queue frame-relay traffic-shaping frame-relay lmi-type cisco frame-relay intf-type dce frame-relay route 100 interface Serial0/1 100 ! interface Serial0/1 encapsulation frame-relay no fair-queue frame-relay lmi-type cisco frame-relay intf-type dce frame-relay route 100 interface Serial0/0 100 ! map-class frame-relay voice-data frame-relay adaptive-shaping becn frame-relay cir 384000 frame-relay bc 1000 frame-relay mincir 349000 frame-relay fair-queue frame-relay voice bandwidth 35000 frame-relay fragment 300

-- James

Reply to
groupstudy2001
Loading thread data ...

is this a typo?

map-class frame-relay voice-data frame-relay cir 284000 (should it be 384000?)

Reply to
garrisb

Hello James,

the BC values in your classes do not look right. The smallest value that you can configure is 10ms, which would be 1/100th of the CIR. Can you try and change the values as following:

map-class frame-relay voice-data frame-relay cir 284000

--> frame-relay bc 2840 frame-relay mincir 128000 frame-relay fragment 64 frame-relay adaptive-shaping becn frame-relay fecn-adapt service-policy output Remote-WAN

map-class frame-relay voice-data frame-relay adaptive-shaping becn frame-relay cir 384000 frame-relay bc 3840 frame-relay mincir 349000 frame-relay fair-queue frame-relay voice bandwidth 35000 frame-relay fragment 300

Regards,

snipped-for-privacy@solutionfinders.nl

formatting link
We=B4ve got answers !

Reply to
helpdesk

Isn't that the expected behaviour? When FR fragmentation on local end is disabled and on remote end is enabled then only frames with length less than fragment size can pass.

formatting link
FRF.12 stipulates that, when fragmentation is on for a data-link connection identifier (DLCI), there is fragmentation of only data frames that exceed the specified fragmentation size. This arrangement allows small VoIP packets, which are not fragmented due to the size, to be interleaved as frames between large data packets that have been fragmented into smaller frames.

Don't be mistaken by wordf "VoIP" here, in reality the router does not care if the frame is VoIP or not VoIP, it's the size that matters :-) HTH Cheers Alex

Reply to
Alex

Your comments and the quote seem to differ, if I follow correctly. I had read the Cisco information before but it doesn't seem to help.

What you said, however, seems to be key. I think the fragmentation may have been on only at one end. Are you saying that if fragmentation is set to, say, 64 bytes that that end will only /receive/ frames of that size or smaller as well as transmit frames of that size? That, I think, would explain it.

-- James

Reply to
groupstudy2001

The quote above says that small packets (less than configured fragment size) are not fragmented. So when fragmentation is enabled only on remote end, any packets that are bigger than configured fragment size are dropped by remote end because they don't have FRF.12 fragmentation header. When fragmentation is enabled on both ends small packets are sent "as-is" and big packets are sent fragmented (that is , they are split into smaller ones and have FRF.12 fragmentation header inserted). Makes sense? HTH Cheers Alex

Reply to
Alex

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.