Skip to main content

Packets bigger than 548 bits are dropped...why ?

More
18 years 2 months ago #13164 by bimmer
5 networks are going through a Catalyst 3550. Between two of them packets of 549 bits and up are dropped. 548 and lower are passing fine. There is a CheckPoint firewall also, running on a Nokia appliance between the two networks, on which I don't know how to change the MTU - which is 1514 to make it equal to Cisco's 1500 (which is max). Can this be an issue? Can interfereces from other devices cause this? The Nokia appliance is built in a plastic enclosure and sits in a rack, close to other devices. Thanks in advance for any ideea.
More
18 years 2 months ago #13240 by TheBishop
Replied by TheBishop on topic Dropped Packets
On the face of it this does sound like an MTU size problem but then again it might not be. Am I right in assuming that the firewall is effectively the router between the two networks you're having trouble with?
If so, try using the Ping command with various packet sizes (e.g. -l 1400) and the don't fragment bit set (-f) to confirm the effective MTU size of the path. Basically, start with a low value and keep increasing it until the replies stop. Once you've found it, try sending a packet bigger than the maximum size but with the -f option left unset. If it doesn't come through then the router might have the don't fragment option set which is preventing reassembly of fragmented packets

Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
[-r count] [-s count] [-k host-list
[-w timeout] target_name

Let us know if the above is of any help
More
18 years 2 months ago #13288 by bimmer
Thanks for the reply Bishop.

As soon as I increase the packets to 549 bits and up, I don't have a reply, regardless of the -f switch. Packets of 548 and lower are passing just fine, with average round trip times of around 1ms.

*************************

C:\>tracert 172.21.134.50

Tracing route to 172.21.134.50
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 10.166.1.1 <-- this is the Catalyst
2 1 ms <1 ms <1 ms 172.21.148.100 <-- this is the fw
3 1 ms 1 ms 1 ms 172.21.134.50

Trace complete.

*************************

C:\>ping -l 548 172.21.134.50

Pinging 172.21.134.50 with 548 bytes of data:

Reply from 172.21.134.50: bytes=548 time=3ms TTL=126
Reply from 172.21.134.50: bytes=548 time=1ms TTL=126
Reply from 172.21.134.50: bytes=548 time=1ms TTL=126
Reply from 172.21.134.50: bytes=548 time=1ms TTL=126

Ping statistics for 172.21.134.50:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 3ms, Average = 1ms

*************************

C:\>ping -l 549 172.21.134.50

Pinging 172.21.134.50 with 549 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 172.21.134.50:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

I used the Ping Plotter and I can see packets above 549 bits are lost at the Catalyst switch.

I will report back the result, once the problem is fixed.
More
18 years 2 months ago #13390 by nleong
Hi Bimmer,

I am currently experiencing exactly the same problem as you.

Was wondering if you have managed to resolve this issue ?

I have tried looking at the various related solution at Technet, and still in vain.
More
18 years 1 month ago #13815 by bimmer

Hi Bimmer,

I am currently experiencing exactly the same problem as you.

Was wondering if you have managed to resolve this issue ?

I have tried looking at the various related solution at Technet, and still in vain.


Well I have found who caused my problems. It was the Nokia firewall appliance running CheckPoint FW-1 which in turn contains also whatever they call SmartDefense. It was in this module that the ICMP limit was set to 548.
More
18 years 1 month ago #13852 by TheBishop
Replied by TheBishop on topic MTU
Yep, there had to be something in ther that was limiting the maximum packet size, and you found it. Well done!
Time to create page: 0.149 seconds