• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 776
  • Last Modified:

Some devices wont anser PING on high buffer size! why?

In my house,

I have a network with a primary router and from there, I have devices connected and other GIG switches connected and from there other devices, just like a normal network, my problem is that if I ping from a computer to all devices, I will get a normal response, but if I increase the value of the buffer I won´t get a answer on some devices...

For example, I ping an Airport Express with a low and high value, I get a response, but then I ping another Airport Express and I will only get a response on a low value...

What can cause this?????
0
marpanet
Asked:
marpanet
  • 4
  • 3
  • 2
2 Solutions
 
giltjrCommented:
Is the connectivity path exactly the same between the two?  

Some routers are configured to drop ICMP ECHO requests that are above a specific size.

Are the configured, as much as possible, exactly the same?

You can configure some devices to drop ICMP ECHO requests that are above a specific size.
0
 
marpanetAuthor Commented:
They are almost exact...
They pass through the same switch (can a simple switch can drop CMP ECHO?), but then they pass into another different switch each one...
0
 
unfragmentedCommented:
If you are pinging with large buffer sizes, and you exceed the MTU of any of the transit links, something will have to fragment the packet.  It maybe your host, a router, a firewall etc etc.

If its successfully fragmented it continues.  If not, it dies here.  Note, if you set the 'do not fragment' flag in ping, fragmentation will not be attempted, and it will die.

If it continues, the packet, and all its fragments need to get to the target.  THere are lots of devices like firewalls that don't like passing on fragments.  If this is the case, it dies here.

If it gets to the target and the reply gets all the way back, you have a successful ping!  Is there a bigger story as to why you are pinging with large buffer sizes?
0
A Cyber Security RX to Protect Your Organization

Join us on December 13th for a webinar to learn how medical providers can defend against malware with a cyber security "Rx" that supports a healthy technology adoption plan for every healthcare organization.

 
marpanetAuthor Commented:
ok, let me explain... I have one Access Point in one of my rooms, this one is connected via ethernet, but sometimes it fails and restarts the connection....
I did the ping test, but, does this tell me something?, I think that one ethernet connector was broken (like a short circuit), I changed the ethernet connector and I think that is working fine now, still I can´t ping....   not able to get an answer from pinging with large buffer is not telling me something´s wrong? right? hehehe
0
 
giltjrCommented:
Can you ping the device at all?  If so that means there is connectivity.

What do you hope to accomplish by ping'ing with a large payload (a.k.a large buffer)?

As I have stated, some devices are configured to drop ICMP packets that have a large payload as this can be considered an attack.

As for your simple switch, most "simple" switches will not drop ICMP packets as they don't do L3.  However, how "simple" is your simple switch?  Is it non-manged?   If it is manged, does is it a L2 switch only or is it a L3 switch.  Even some L2 switches can be configured with TCP/UDP/IP access control lists to block/drop traffic.
0
 
marpanetAuthor Commented:
Yes, I can PING de device...
The weird thing is that I am pinging to similar devices (apple tv), each one passing through different simple switches, and only one will not respond only to large buffer.... I do have connectivity, I just wanted to know if this means that something might be wrong...

I know that a large buffer (65500) it´s still a small size, but it was the only different between two apple tv that I could come up, but I see it has nothing to do with performance....... Really, I was going crazy because I was having a hard time with my Apple tv........ apple stuff... hate them.
0
 
unfragmentedCommented:
Its not normal to send devices ping payloads substantially larger than the MTU, so I don't think you can draw any solid conclusions from your test, apart from 'something is different'.

When turning up a new link, I test with frame sizes of 64 bytes, 512 bytes 1024 bytes and 1518 bytes.  If all get through (ie 0% loss) without too much variance in delay, then I consider the link good.

Sending a buffer with 65500 bytes is possible, but with an MTU of 1518 bytes, this is going to need 45 fragments.  Normal applications don't do this - they discover the MTU or use TCP to set an appropriate MSS so that each frame does not exceed the MTU.

So again, I don't think you can make any conclusions about the device or network being broken from that test alone.
0
 
giltjrCommented:
Some devices just will not respond to large ICMP echo requests.  

If you have two devices that are exactly the same with the same network path, they should act the same.

But by the same they need to be the same model, have the same firmware level, be configured as much as possible the same and have the same current level of workload going on.  If one device has more network traffic than another it may have less available memory for buffers.

Typically people ping with large payloads for two reasons.  To try and crash the remote device or as a simple check for throughput between two devices, generally on a WAN.

Back when WAN links were low speed you could use ping to look at through-put, but with high speed WAN links, 65K is really not enough to test.
0
 
marpanetAuthor Commented:
Sorry for the long delay... I got married and completely forgot of this issue!!..
The problem was not the network at all, it has something to do with the AppleTv software, after Apple made the upgrade, and the issue was gone.

Still I learned from you guys, thank you very much!
0

Featured Post

Microsoft Certification Exam 74-409

Veeam® is happy to provide the Microsoft community with a study guide prepared by MVP and MCT, Orin Thomas. This guide will take you through each of the exam objectives, helping you to prepare for and pass the examination.

  • 4
  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now