cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1081
Views
0
Helpful
7
Replies

IP Packets Larger Than Fragmentation Size Get Dropped in FR

Devildoc007
Level 4
Level 4

Hello,

Has anyone seen this problem before or know how to configure fragmentation on FR properly? Any help is greatly appreciated.

I have 3 offices with FR links through my ISP MPLS networks. The central office has 1536 kbps link and the other 2 remote offices each has a 512 kbps link.

I am doing VoIP over the FR links with policy-based fragmentation on the subinterface. I configured the fragmentation size to be 640 bytes (the recommended size for 512 link) for each FR link. The central office also has the fragmentation size of 640 bytes even though it has a 1536 kbps link because i needed to keep the fragmentations size consistent with all my FR links.

The problem is when sending packets that are larger than the fragmentation size (>640 bytes), the packets get dropped. When i removed the fragmentation configuration, then everything works fine.

Does anyone have any idea how i can configure fragmentation correctly on FR links? Any help is appreciated. Thanks.

JD

----------

Here is a partial sample of my config.

class-map match-all VoIP_Traffic

match access-group name Voice_Traffic

class-map match-all VoIP_Signalling

match access-group name Voice_Signalling

!

!

policy-map VoIP_Priority

class VoIP_Signalling

bandwidth 8

class VoIP_Traffic

priority 500

class class-default

fair-queue

random-detect dscp-based

interface Serial0/0/0

description <<Link to NVPN Networks>>

no ip address

no ip redirects

no ip unreachables

no ip proxy-arp

encapsulation frame-relay IETF

no ip mroute-cache

load-interval 30

no fair-queue

service-module t1 timeslots 1-8

frame-relay traffic-shaping

frame-relay lmi-type ansi

!

interface Serial0/0/0.1 point-to-point

description <<Point-to-Point FR>>

bandwidth 512

ip address 10.10.10.1 255.255.255.252

frame-relay interface-dlci 123

class VOIPovFR

map-class frame-relay VOIPovFR

frame-relay fragment 640

frame-relay cir 512000

frame-relay bc 5120

frame-relay be 0

frame-relay mincir 512000

service-policy output VoIP_Priority

7 Replies 7

pmajumder
Level 3
Level 3

Hi,

Wonder if the DF (Dont fragment) bit is being set in the packet and thus >640 bytes packets are being dropped - Could rung a sniffer or debug packets to verify.

Also do an extended ping, and set bytes to >640 and try with DF bit off and then on? Does the ping work if the DF bit is not on?

Regards

Pradeep

Yes, i have tried the extended ping with packets larger than 640 bytes and DF bits off and on. In either cases, packets larger than 640 still got dropped.

JD

Hi,

Can you do the following:

Set -- debug ip icmp, Then do an extended ping >640 with df bit off.

Do you see a "frag needed" and DF set messages in the debug (please post it)

Also can you paste the output of "sh frame frag int s0/0/0.1 123"

Regards

Pradeep

Because the FR link is the production line, with fragmentation on, i cannot send traffics across the link so i had to disable fragmentation. I'll try to enable fragmentation again tonight and post the results for you. Thanks for your help.

JD

I tried setting debug ip icmp and performed an extended ping but nothing happened with the debug. No message or anything.

Here is the outputs of the show frame frag.

This output is for the router at the remote site.

fragment size 640 fragment type end-to-end

in fragmented pkts 0 out fragmented pkts 43

in fragmented bytes 0 out fragmented bytes 19536

in un-fragmented pkts 268 out un-fragmented pkts 244

in un-fragmented bytes 13538 out un-fragmented bytes 25637

in assembled pkts 268 out pre-fragmented pkts 260

in assembled bytes 13538 out pre-fragmented bytes 44947

in dropped reassembling pkts 0 out dropped fragmenting pkts 0

in DE fragmented pkts 0 out DE fragmented pkts 0

in DE un-fragmented pkts 0 out DE un-fragmented pkts 0

in timeouts 0

in out-of-sequence fragments 0

in fragments with unexpected B bit set 0

in fragments with skipped sequence number 0

out interleaved packets 0

And this output is from the router at the central site.

fragment size 640 fragment type end-to-end

in fragmented pkts 0 out fragmented pkts 79

in fragmented bytes 0 out fragmented bytes 32637

in un-fragmented pkts 2930 out un-fragmented pkts 3016

in un-fragmented bytes 170661 out un-fragmented bytes 146748

in assembled pkts 2930 out pre-fragmented pkts 3049

in assembled bytes 170661 out pre-fragmented bytes 178977

in dropped reassembling pkts 0 out dropped fragmenting pkts 0

in DE fragmented pkts 0 out DE fragmented pkts 0

in DE un-fragmented pkts 0 out DE un-fragmented pkts 0

in timeouts 0

in out-of-sequence fragments 0

in fragments with unexpected B bit set 0

in fragments with skipped sequence number 0

out interleaved packets 0

I noticed that in either output, there is no "in fragmented packets or bytes". Does this mean the routers on the ISP end that are connected to these routers are not configured for fragmentation?

JD

yes, it does seem to indicate that a device in the middle is dropping the fragmented packets.

However, please try the extended ping again but this time after removing the statement no ip unreachables from your serial interfaces (s0/0/0). Anything now in the debug or in the tramsmission of regular >640 byte packets?

I debugged the icmp packets and it showed the ping packets were received by the other end of the router when the packets were less the fragment size of 640 bytes. When the ping packets were more than the fragment size of 640 bytes, there was no output of the icmp debug. So it seemed the ping packets were dropped in transit by the ISP routers.

I'll call SBC and talk to them and see what they say. I'll keep you posted. Thanks for your help.

JD

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card