- Posts: 8
- Thank you received: 0
Packets bigger than 548 bits are dropped...why ?
18 years 9 months ago #13164
by bimmer
Packets bigger than 548 bits are dropped...why ? was created 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.
18 years 8 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
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
18 years 8 months ago #13288
by bimmer
Replied by bimmer on topic Re: Packets bigger than 548 bits are dropped...why ?
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.
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.
18 years 8 months ago #13390
by nleong
Replied by nleong on topic Re: Packets bigger than 548 bits are dropped...why ?
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.
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.
18 years 7 months ago #13815
by bimmer
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.
Replied by bimmer on topic Re: Packets bigger than 548 bits are dropped...why ?
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.
Time to create page: 0.128 seconds