Strange ping response..?
June 7, 2012 7:48 PM Subscribe
I have a home networking question! About my home network! Read more about it, after the break.
I will try to be brief!
My internet goes out, sometimes, up here in my office. It is sporadic and it is irritating, because it makes me die in Diablo. So, I'm trying to figure out why this is happening and fix it, but the problem is intermittent so it's particularly irritating.
I have my router do the static DHCP thing for hosts in the house. For example, my desktop PC is 192.168.1.105. Our media server is 192.168.1.100. The router is 192.168.1.1. There are no wireless devices involved here - this is all run through cat5.
Here is my specific question!
As part of troubleshooting this issue, I have opened a command prompt on my desktop and run the command..
ping -n 10000 192.168.1.100
in the background and then gone off to do something like play Diablo. Then, after an outage, I'll come back and look at the output file from ping.
I see things like this:
Reply from 192.168.1.100: bytes=32 time=1ms TTL=128
Reply from 192.168.1.100: bytes=32 time<1ms TTL=128
Request timed out.
Request timed out.
Request timed out.
Reply from 192.168.1.100: bytes=32 time=1599ms TTL=128
Reply from 192.168.1.100: bytes=32 time<1ms TTL=128
Reply from 192.168.1.100: bytes=32 time<1ms TTL=128
Reply from 192.168.1.100: bytes=32 time<1ms TTL=128
Request timed out.
Reply from 192.168.1.101: Destination host unreachable.
Reply from 192.168.1.101: Destination host unreachable.
Reply from 192.168.1.101: Destination host unreachable.
Reply from 192.168.1.101: Destination host unreachable.
Reply from 192.168.1.101: Destination host unreachable.
Reply from 192.168.1.100: bytes=32 time=1000ms TTL=128
Reply from 192.168.1.100: bytes=32 time<1ms TTL=128
That's obviously bad. But the thing I'm particularly curious about - why are the destination host unreachable messages coming from 192.168.1.101 ...?!
I will try to be brief!
My internet goes out, sometimes, up here in my office. It is sporadic and it is irritating, because it makes me die in Diablo. So, I'm trying to figure out why this is happening and fix it, but the problem is intermittent so it's particularly irritating.
I have my router do the static DHCP thing for hosts in the house. For example, my desktop PC is 192.168.1.105. Our media server is 192.168.1.100. The router is 192.168.1.1. There are no wireless devices involved here - this is all run through cat5.
Here is my specific question!
As part of troubleshooting this issue, I have opened a command prompt on my desktop and run the command..
ping -n 10000 192.168.1.100
in the background and then gone off to do something like play Diablo. Then, after an outage, I'll come back and look at the output file from ping.
I see things like this:
Reply from 192.168.1.100: bytes=32 time=1ms TTL=128
Reply from 192.168.1.100: bytes=32 time<1ms TTL=128
Request timed out.
Request timed out.
Request timed out.
Reply from 192.168.1.100: bytes=32 time=1599ms TTL=128
Reply from 192.168.1.100: bytes=32 time<1ms TTL=128
Reply from 192.168.1.100: bytes=32 time<1ms TTL=128
Reply from 192.168.1.100: bytes=32 time<1ms TTL=128
Request timed out.
Reply from 192.168.1.101: Destination host unreachable.
Reply from 192.168.1.101: Destination host unreachable.
Reply from 192.168.1.101: Destination host unreachable.
Reply from 192.168.1.101: Destination host unreachable.
Reply from 192.168.1.101: Destination host unreachable.
Reply from 192.168.1.100: bytes=32 time=1000ms TTL=128
Reply from 192.168.1.100: bytes=32 time<1ms TTL=128
That's obviously bad. But the thing I'm particularly curious about - why are the destination host unreachable messages coming from 192.168.1.101 ...?!
What device is 101? Usually, if I remember right, you'll get the destination host unreachable from your gateway. Which, if it is really .1, then you have a device at .101 that is acting like a gateway. Perhaps a computer with ICS configured?
You should try the continuous ping on the router and see if anything changes.
And is your subnet mask 255.255.255.0? That's what it should be.
Also, pings aren't guaranteed. If the other end machine is busy, it will also not send them back.
posted by gjc at 8:22 PM on June 7, 2012
You should try the continuous ping on the router and see if anything changes.
And is your subnet mask 255.255.255.0? That's what it should be.
Also, pings aren't guaranteed. If the other end machine is busy, it will also not send them back.
posted by gjc at 8:22 PM on June 7, 2012
Like gjc said, it sounds like something is deciding to proxy your pings to 192.168.1.100 through itself, where its address is .101. When this happens, it might be helpful to look at the arp cache to see what MAC addresses are associated with .100 and .101. On a windows box "arp -a" should give you the local arp table. You could compare that with the MAC address on the media server (usually visible in the network properties of the NIC).
I'd do something like this to track it down:
arp -a when everything is fine. Write down the list of MAC/IP associations.
Start your ping, wait for a timeout.
arp -a again. Check the list against the previous one.
Go looking for .101's MAC address on whatever you are using as your switch (if it's a dumb enough hub you're out of luck, but if it's a switch built into your router, say, it should have a MAC table that will tell you which port is associated with which addresses.)
Trace the cable on that port and it should be the offending device.
posted by five toed sloth at 8:47 PM on June 7, 2012
I'd do something like this to track it down:
arp -a when everything is fine. Write down the list of MAC/IP associations.
Start your ping, wait for a timeout.
arp -a again. Check the list against the previous one.
Go looking for .101's MAC address on whatever you are using as your switch (if it's a dumb enough hub you're out of luck, but if it's a switch built into your router, say, it should have a MAC table that will tell you which port is associated with which addresses.)
Trace the cable on that port and it should be the offending device.
posted by five toed sloth at 8:47 PM on June 7, 2012
101 is probably the gateway.
Is this a trendnet router (or perhaps other small-brand)? If so, replace it. I've seen this exact issue (even worse) with Trendnet routers.
posted by Sonic_Molson at 9:56 PM on June 7, 2012
Is this a trendnet router (or perhaps other small-brand)? If so, replace it. I've seen this exact issue (even worse) with Trendnet routers.
posted by Sonic_Molson at 9:56 PM on June 7, 2012
Did you disable wireless on the router (if it does wireless)? Since you assigned static addresses did you disable DHCP on the router completely? 192.168.1.101 smells like the first DHCP address handed out when DHCP is configured with a range like 192.168.1.101 - 192.168.1.254 or even starting at 192.168.1.100 and the host getting assigned the .100 by DHCP is interfering by trying to use it or NAKing and asking for the .101 and getting things all confused.
I'd put machines at .10, .11, ... and make sure there's no DHCP enabled on the router at all. And that any wireless is disabled. (it could be random wifi connection from neighbor or something).
The rest everybody says is pretty much it, something is thinking it's a gateway and responding with the Unreachable messages and/or stealing MAC addresses.
posted by zengargoyle at 1:51 AM on June 8, 2012
I'd put machines at .10, .11, ... and make sure there's no DHCP enabled on the router at all. And that any wireless is disabled. (it could be random wifi connection from neighbor or something).
The rest everybody says is pretty much it, something is thinking it's a gateway and responding with the Unreachable messages and/or stealing MAC addresses.
posted by zengargoyle at 1:51 AM on June 8, 2012
Response by poster: *punches self in face*
Ok. I forgot that I re-did the DHCP assignments recently.
My desktop is 192.168.1.101.
So, essentially, those destination unreachable messages are coming from "localhost" where I'm sending the pings from... 192.168.1.101 -> 192.168.100.
In that context, does that make the message more appropriate?
posted by kbanas at 4:42 AM on June 8, 2012
Ok. I forgot that I re-did the DHCP assignments recently.
My desktop is 192.168.1.101.
So, essentially, those destination unreachable messages are coming from "localhost" where I'm sending the pings from... 192.168.1.101 -> 192.168.100.
In that context, does that make the message more appropriate?
posted by kbanas at 4:42 AM on June 8, 2012
Response by poster: So, from my desktop, I get this:
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
Physical Address. . . . . . . . . : 00-24-8C-37-A1-9C
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::2971:cebb:38c:eba8%11(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.1.101(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Friday, June 08, 2012 2:40:40 AM
Lease Expires . . . . . . . . . . : Saturday, June 09, 2012 2:40:39 AM
Default Gateway . . . . . . . . . : 192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DHCPv6 IAID . . . . . . . . . . . : 234890380
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-17-25-FF-6E-00-24-8C-37-A1-9C
DNS Servers . . . . . . . . . . . : 192.168.1.1
NetBIOS over Tcpip. . . . . . . . : Enabled
C:\Users\Kyle>arp -a
Interface: 192.168.1.101 --- 0xb
Internet Address Physical Address Type
192.168.1.1 20-4e-7f-b4-86-12 dynamic
192.168.1.100 00-1a-70-14-aa-85 dynamic
192.168.1.106 1c-6f-65-74-ba-50 dynamic
192.168.1.107 00-26-18-fa-54-40 dynamic
192.168.1.108 00-1b-a9-2d-9f-80 dynamic
192.168.1.109 00-09-b0-c4-cf-fb dynamic
192.168.1.111 00-24-2b-53-c8-ff dynamic
192.168.1.255 ff-ff-ff-ff-ff-ff static
224.0.0.22 01-00-5e-00-00-16 static
224.0.0.252 01-00-5e-00-00-fc static
224.0.0.253 01-00-5e-00-00-fd static
239.255.255.250 01-00-5e-7f-ff-fa static
255.255.255.255 ff-ff-ff-ff-ff-ff static
.... Just out of curiosity, why doesn't *my* machine - the one at 192.168.1.101 - show up in the ARP table?
posted by kbanas at 4:45 AM on June 8, 2012
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
Physical Address. . . . . . . . . : 00-24-8C-37-A1-9C
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::2971:cebb:38c:eba8%11(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.1.101(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Friday, June 08, 2012 2:40:40 AM
Lease Expires . . . . . . . . . . : Saturday, June 09, 2012 2:40:39 AM
Default Gateway . . . . . . . . . : 192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DHCPv6 IAID . . . . . . . . . . . : 234890380
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-17-25-FF-6E-00-24-8C-37-A1-9C
DNS Servers . . . . . . . . . . . : 192.168.1.1
NetBIOS over Tcpip. . . . . . . . : Enabled
C:\Users\Kyle>arp -a
Interface: 192.168.1.101 --- 0xb
Internet Address Physical Address Type
192.168.1.1 20-4e-7f-b4-86-12 dynamic
192.168.1.100 00-1a-70-14-aa-85 dynamic
192.168.1.106 1c-6f-65-74-ba-50 dynamic
192.168.1.107 00-26-18-fa-54-40 dynamic
192.168.1.108 00-1b-a9-2d-9f-80 dynamic
192.168.1.109 00-09-b0-c4-cf-fb dynamic
192.168.1.111 00-24-2b-53-c8-ff dynamic
192.168.1.255 ff-ff-ff-ff-ff-ff static
224.0.0.22 01-00-5e-00-00-16 static
224.0.0.252 01-00-5e-00-00-fc static
224.0.0.253 01-00-5e-00-00-fd static
239.255.255.250 01-00-5e-7f-ff-fa static
255.255.255.255 ff-ff-ff-ff-ff-ff static
.... Just out of curiosity, why doesn't *my* machine - the one at 192.168.1.101 - show up in the ARP table?
posted by kbanas at 4:45 AM on June 8, 2012
Your machine doesn't show up because it doesn't have to. Your machine won't be sending packets to itself.
Anyway, getting back to the original problem, you need to do the continuous pings from your machine to the router. First, when you are doing nothing. If you still get drops, you need to figure out whether it is your computer's fault, your router's fault or some kind of cabling issue in between. You might do this by then doing a continuous ping from another machine to the router. If that ping also times out, you can probably rule out your machine as the problem, and look at the router and the switch if you have a separate switch.
If it is fine when you are doing nothing, but starts to drop when you are doing stuff, one of the devices is getting overloaded. If there is a switch, it might be that. But probably the router.
posted by gjc at 5:53 AM on June 8, 2012
Anyway, getting back to the original problem, you need to do the continuous pings from your machine to the router. First, when you are doing nothing. If you still get drops, you need to figure out whether it is your computer's fault, your router's fault or some kind of cabling issue in between. You might do this by then doing a continuous ping from another machine to the router. If that ping also times out, you can probably rule out your machine as the problem, and look at the router and the switch if you have a separate switch.
If it is fine when you are doing nothing, but starts to drop when you are doing stuff, one of the devices is getting overloaded. If there is a switch, it might be that. But probably the router.
posted by gjc at 5:53 AM on June 8, 2012
Response by poster: Your machine doesn't show up because it doesn't have to. Your machine won't be sending packets to itself.
Anyway, getting back to the original problem, you need to do the continuous pings from your machine to the router. First, when you are doing nothing. If you still get drops, you need to figure out whether it is your computer's fault, your router's fault or some kind of cabling issue in between. You might do this by then doing a continuous ping from another machine to the router. If that ping also times out, you can probably rule out your machine as the problem, and look at the router and the switch if you have a separate switch.
If it is fine when you are doing nothing, but starts to drop when you are doing stuff, one of the devices is getting overloaded. If there is a switch, it might be that. But probably the router.
Ok. So, the reason I did the ping tests to my media server (192.168.1.100) as opposed to my router (192.168.1.1) is because... well, nothing is plugged into the router, really - I mean, everything is pretty much fed by a D-Link 24-port switch. The router plugs into that. My computer plugs into that. The home server plugs into that. So, I figured if I couldn't ping something on the internal network when I lose connectivity, then that would tell me something - because aside from handing out DHCP addresses, the router isn't doing anything, right? I mean, when I ping 192.168.1.100 from my PC, it's not touching the router, right?
So that would suggest that perhaps something is wrong with the 24-port switch. Which is funny because it's totally over-kill. I've got 5 or 6 PCs here? But, yeah, so, I've gone to work and left a ping test running and come back to find 32,000 consecutive flawless pings... while the network is doing nothing. It's Thursday night and my wife and I are both in the office playing Diablo and all of a sudden packets start to drop like snow flakes...
posted by kbanas at 7:37 AM on June 8, 2012
Anyway, getting back to the original problem, you need to do the continuous pings from your machine to the router. First, when you are doing nothing. If you still get drops, you need to figure out whether it is your computer's fault, your router's fault or some kind of cabling issue in between. You might do this by then doing a continuous ping from another machine to the router. If that ping also times out, you can probably rule out your machine as the problem, and look at the router and the switch if you have a separate switch.
If it is fine when you are doing nothing, but starts to drop when you are doing stuff, one of the devices is getting overloaded. If there is a switch, it might be that. But probably the router.
Ok. So, the reason I did the ping tests to my media server (192.168.1.100) as opposed to my router (192.168.1.1) is because... well, nothing is plugged into the router, really - I mean, everything is pretty much fed by a D-Link 24-port switch. The router plugs into that. My computer plugs into that. The home server plugs into that. So, I figured if I couldn't ping something on the internal network when I lose connectivity, then that would tell me something - because aside from handing out DHCP addresses, the router isn't doing anything, right? I mean, when I ping 192.168.1.100 from my PC, it's not touching the router, right?
So that would suggest that perhaps something is wrong with the 24-port switch. Which is funny because it's totally over-kill. I've got 5 or 6 PCs here? But, yeah, so, I've gone to work and left a ping test running and come back to find 32,000 consecutive flawless pings... while the network is doing nothing. It's Thursday night and my wife and I are both in the office playing Diablo and all of a sudden packets start to drop like snow flakes...
posted by kbanas at 7:37 AM on June 8, 2012
If I were troubleshooting this, I would take the switch out of the equation, create heavy network load, and see if you experience the same behavior.
posted by lholladay at 8:57 AM on June 8, 2012
posted by lholladay at 8:57 AM on June 8, 2012
Response by poster: If I were troubleshooting this, I would take the switch out of the equation, create heavy network load, and see if you experience the same behavior.
You mean just plug the computer directly into the router? And if it's all good I know something is somehow overloading super switch? And if it still breaks I know somehow that Mr. Routerstein can't handle the network traffic in the house?
posted by kbanas at 8:58 AM on June 8, 2012
You mean just plug the computer directly into the router? And if it's all good I know something is somehow overloading super switch? And if it still breaks I know somehow that Mr. Routerstein can't handle the network traffic in the house?
posted by kbanas at 8:58 AM on June 8, 2012
Basically, yep. Assuming you have enough ethernet ports free on the router to plug a few computers in, you should be able to fire up Diablo and see if you still get dropped packets. If you do, then I would suspect issues with the router. But the switch is the easiest thing to test, so that's why I suggest starting there.
posted by lholladay at 9:07 AM on June 8, 2012
posted by lholladay at 9:07 AM on June 8, 2012
In your situation, when you're not actively trying to troubleshoot and you just want to play Diablo, I would plug your and your wife's computers directly into the router -- removing the switch from the path between you and Diablo -- and keep everything else on your network plugged into the switch.
This allows two things: first, if the problem is activity between other systems on your network, they can chat with each other over the switch without impacting you, and second, if the problem persists, you can simply unplug the switch (and so all of those components) while you're playing Diablo, which will (among other things) make it clear whether the problem is with the components on the switch or with your computer or your wife's computer.
Incidentally: is there any chance your switch is overheating? Sometimes just bringing it out into the room instead of in a desk or closet makes a big difference, especially for such a large switch.
posted by davejay at 9:10 AM on June 8, 2012
This allows two things: first, if the problem is activity between other systems on your network, they can chat with each other over the switch without impacting you, and second, if the problem persists, you can simply unplug the switch (and so all of those components) while you're playing Diablo, which will (among other things) make it clear whether the problem is with the components on the switch or with your computer or your wife's computer.
Incidentally: is there any chance your switch is overheating? Sometimes just bringing it out into the room instead of in a desk or closet makes a big difference, especially for such a large switch.
posted by davejay at 9:10 AM on June 8, 2012
Response by poster:
In your situation, when you're not actively trying to troubleshoot and you just want to play Diablo, I would plug your and your wife's computers directly into the router -- removing the switch from the path between you and Diablo -- and keep everything else on your network plugged into the switch.
This allows two things: first, if the problem is activity between other systems on your network, they can chat with each other over the switch without impacting you, and second, if the problem persists, you can simply unplug the switch (and so all of those components) while you're playing Diablo, which will (among other things) make it clear whether the problem is with the components on the switch or with your computer or your wife's computer.
Incidentally: is there any chance your switch is overheating? Sometimes just bringing it out into the room instead of in a desk or closet makes a big difference, especially for such a large switch.
posted by davejay at 9:10 AM on June 8 [mark as best answer] [+] [!]
I concede the point. This is going to be exceedingly difficult, as the router is at one end of the house and the computer is upstairs in the exact opposite part of the house, but I understand the purpose behind troubleshooting it in this way.
However! I have one question that maybe someone could answer...
In general terms, if, say, I'm pinging 192.168.1.100 from 192.168.1.105.... and they are connected to a switch together... they don't even talk to the router, do they? On a LAN aren't the machines just communicating with each other directly through the switch?
posted by kbanas at 10:43 AM on June 8, 2012
In your situation, when you're not actively trying to troubleshoot and you just want to play Diablo, I would plug your and your wife's computers directly into the router -- removing the switch from the path between you and Diablo -- and keep everything else on your network plugged into the switch.
This allows two things: first, if the problem is activity between other systems on your network, they can chat with each other over the switch without impacting you, and second, if the problem persists, you can simply unplug the switch (and so all of those components) while you're playing Diablo, which will (among other things) make it clear whether the problem is with the components on the switch or with your computer or your wife's computer.
Incidentally: is there any chance your switch is overheating? Sometimes just bringing it out into the room instead of in a desk or closet makes a big difference, especially for such a large switch.
posted by davejay at 9:10 AM on June 8 [mark as best answer] [+] [!]
I concede the point. This is going to be exceedingly difficult, as the router is at one end of the house and the computer is upstairs in the exact opposite part of the house, but I understand the purpose behind troubleshooting it in this way.
However! I have one question that maybe someone could answer...
In general terms, if, say, I'm pinging 192.168.1.100 from 192.168.1.105.... and they are connected to a switch together... they don't even talk to the router, do they? On a LAN aren't the machines just communicating with each other directly through the switch?
posted by kbanas at 10:43 AM on June 8, 2012
In general terms, if, say, I'm pinging 192.168.1.100 from 192.168.1.105.... and they are connected to a switch together... they don't even talk to the router, do they? On a LAN aren't the machines just communicating with each other directly through the switch?
No, they don't talk to the router. Addresses in your subnet aren't routed via the gateway (that's why you see them in
Assuming you just booted your desktop up (i.e., it doesn't know anything about who's on the network yet), when you try to ping 192.168.1.100, the computer will figure out how to get to the address in question by first deciding whether it's on the same subnet (it is), then resolving the address to a link-layer (MAC) address via ARP, then sending some frames out over ethernet addressed to that machine. Assuming you're using a switch (not a hub), those frames are never even 'heard' by your router.
posted by axiom at 12:56 PM on June 8, 2012
No, they don't talk to the router. Addresses in your subnet aren't routed via the gateway (that's why you see them in
arp -a output). Do route print in a command prompt to see your machine's routing table.Assuming you just booted your desktop up (i.e., it doesn't know anything about who's on the network yet), when you try to ping 192.168.1.100, the computer will figure out how to get to the address in question by first deciding whether it's on the same subnet (it is), then resolving the address to a link-layer (MAC) address via ARP, then sending some frames out over ethernet addressed to that machine. Assuming you're using a switch (not a hub), those frames are never even 'heard' by your router.
posted by axiom at 12:56 PM on June 8, 2012
You should also add to the list of things to do. Check your cables. Swap them between machines and see if problems follow. In university network land a large percentage of connection problems are bad cables. Less common now than previously is check the duplex settings on the NICs / switch. They should be auto-negotiate at all ends, in the past it was more common to find things locked to manual full-duplex 100M on one end but not the other. Both of these problems present themselves as things working fine under light load and then crapping out under heavier load. Along the same lines you want to ping with large packets, your default is 32 byte pings, try using the -s (or appropriate Windows option) to crank the ping size up to 1500 bytes. You can also grab iperf for Windows or some similar tool to let you blast a measurable stream of data between a pair of machines, when used while watching the error counters on your NIC you may be able to narrow down where the problem is.
Generally things communicating over IP on the same subnet don't touch the router. The switch has a forwarding table that maps MAC addresses to ports so an incoming ethernet frame will be sent out the correct port. This can change though, if a machine spoofs a MAC address the switch will update the forwarding table to associate that MAC with the port that it came in on. Some switches if link goes down the forwarding information for that port is lost. If a switch sees an incoming packet destined for a MAC address that is not in the forwarding table it will flood it out every port except the one it came in on. A computer with multiple interfaces plugged into multiple ports on a switch can cause storms. A packet to an unknown destination hits the switch and is forwarded out all ports, the machine with 2 NICs is set to bridge mode and receives the packets and dutifully sends them back out the other interface where the switch sees them again and forwards them out all ports again, repeat until the switch croaks.
Most recent NICs of the 1gig variety can plug directly into each other without a special cross-over cable. I'd put iperf on two machines, set them up statically, and test a couple of cables to make sure the NICs and cables were in good working condition. Then move to 2 ports on the switch with everything else removed and confirm again, and then between the other ports, then between machine plugged into router (testing against an internet speed test or NDT or NPAD server) and somewhere along this pain in the ass testing a point of failure would show itself. If it turns out to be a cable you'll hate yourself. :P
posted by zengargoyle at 4:45 PM on June 8, 2012
Generally things communicating over IP on the same subnet don't touch the router. The switch has a forwarding table that maps MAC addresses to ports so an incoming ethernet frame will be sent out the correct port. This can change though, if a machine spoofs a MAC address the switch will update the forwarding table to associate that MAC with the port that it came in on. Some switches if link goes down the forwarding information for that port is lost. If a switch sees an incoming packet destined for a MAC address that is not in the forwarding table it will flood it out every port except the one it came in on. A computer with multiple interfaces plugged into multiple ports on a switch can cause storms. A packet to an unknown destination hits the switch and is forwarded out all ports, the machine with 2 NICs is set to bridge mode and receives the packets and dutifully sends them back out the other interface where the switch sees them again and forwards them out all ports again, repeat until the switch croaks.
Most recent NICs of the 1gig variety can plug directly into each other without a special cross-over cable. I'd put iperf on two machines, set them up statically, and test a couple of cables to make sure the NICs and cables were in good working condition. Then move to 2 ports on the switch with everything else removed and confirm again, and then between the other ports, then between machine plugged into router (testing against an internet speed test or NDT or NPAD server) and somewhere along this pain in the ass testing a point of failure would show itself. If it turns out to be a cable you'll hate yourself. :P
posted by zengargoyle at 4:45 PM on June 8, 2012
I agree. When you are losing pings, it could mean that the receiving machine isn't receiving them, isn't sending them back, or IS, but they aren't making it back.
My limited experience is that it is more likely that the cabling is going to be the issue than the switch.
But since you had no problems with extended pinging when there was no load, especially because of that one ping return of 1500ms, I'm going to say that the problem exists in your computer. It might be over-taxed and dropping packets.
posted by gjc at 7:40 PM on June 8, 2012
My limited experience is that it is more likely that the cabling is going to be the issue than the switch.
But since you had no problems with extended pinging when there was no load, especially because of that one ping return of 1500ms, I'm going to say that the problem exists in your computer. It might be over-taxed and dropping packets.
posted by gjc at 7:40 PM on June 8, 2012
This thread is closed to new comments.
posted by Dipsomaniac at 7:59 PM on June 7, 2012