2

This is a really basic question, but I need a sanity check to make sure my expectations are not incorrect and that what I'm seeing isn't expected behavior.

The situation is: I've got a Mac Pro running MacOS/X, and an ARM-based Linux box. Both are connected to an 8-port Extreme Networks Gigabit switch (with no Internet uplink, this is a local LAN only).

On my Mac, I start a ping6 session running, pinging the Linux box:

$ ping6 fe80::21c:abff:fe00:55e5%en1

... and start getting pong-responses back, as expected.

Then I go over to the Ethernet switch, disconnect from the Ethernet switch the cable that leads to the Linux box, and reconnect that cable to another open port on the Ethernet switch.

At this point, my expectation is that (after a pause of a few seconds), the ping6 session on my Mac would resume seeing responses.

However, my observation is that sometimes the ping6 session stops receiving responses indefinitely -- or at least, until I return the Linux box's Ethernet connection back to the switch-port that it was originally connected to. (stopping and restarting the ping6 process doesn't help; waiting longer doesn't help)

My primary question, then, is: is the behavior I'm observing expected behavior? And if so, is there anything I can do (in software) to recover from this port-change? Or if not, do you have any idea what might be going wrong? (My suspicion is that it might be an NDP issue)

Jeremy Friesner
  • 197
  • 5
  • Not AFAICT (I did a "arp -a -d" which didn't seem to have any effect; AFAICT arp is an IPv4-specific thing and doesn't effect IPv6 lookups. Looking for an IPv6-equivalent action, I tried "npd -c" but that didn't seem to help either) – Jeremy Friesner Mar 07 '18 at 15:29
  • Do you get a response if you use the all nodes address `ff02::1` rather than `fe80::21c:abff:fe00:55e5`? Does it work if you then go back to the unicast address? – kasperd Mar 17 '18 at 10:34

2 Answers2

1

You are correct that you should continue receiving ping replies after reconnecting the target device, even after moving it to another switch port.

stopping and restarting the ping6 process doesn't help; waiting longer doesn't help

This is not normal. Something is preventing either the ping requests or the replies from being transmitted between the two devices after the port change. I'm not familiar with the specific firewall configuration possibilities on Linux, but on a Windows machine a change in network interface can result in different firewall rules being applied.

There's also the outside chance there's something wrong with the switch itself, though that can easily be ruled out by confirming that the Linux box can communicate with the network normally while connected to the new switch port.

I say Reinstate Monica
  • 25,487
  • 19
  • 95
  • 131
  • It appears the "outside chance" is confirmed: the misbehavior seems to be specific to the Ethernet switch I was using (an Extreme Networks Summit X440-8t). If I reconnect everything to another switch (an Extreme Networks Summit X440-24p) instead, I get the behavior I would expect. – Jeremy Friesner Mar 07 '18 at 20:05
  • @JeremyFriesner thanks for reporting back on the specific cause. Glad to know our sanity need not be doubted! – I say Reinstate Monica Mar 07 '18 at 20:09
  • @JeremyFriesner Maybe one of the ports on the switch is simply defective. – kasperd Mar 17 '18 at 10:36
  • @kasperd I've seen the problem on most (if not all) of the switch's ports, so I think the defect is more likely in the switch itself; perhaps in its firmware. – Jeremy Friesner Mar 17 '18 at 14:12
  • @JeremyFriesner It's quite plausible that there are switches where the firmware will take care of purging CAM table entries associated with ports that have lost link. And it is also plausible that there are switches which don't do it. So firmware difference can have something to say in what you observed. – kasperd Mar 17 '18 at 15:51
1

The switch has no way to know the port has been changed until the machine whose port was changed sends some traffic. If your Linux machine is quiet and not engaging in any network activity at the time you move its Ethernet cable to another port, then you will have to wait until it does send some traffic.

Once it does send traffic, the switch will pick up the fact that it has moved and update its internal tables appropriately.

Michael Hampton
  • 13,635
  • 4
  • 45
  • 76
  • Shouldn't under normal circumstances the simple act of disconnecting/reconnecting the Linux box's network connection trigger at least *some* traffic? Renewal of its DHCP lease comes to mind... – I say Reinstate Monica Mar 07 '18 at 14:48
  • @TwistyImpersonator Only if the machine gets its IP address through DHCP. – Michael Hampton Mar 07 '18 at 16:36
  • 1
    @MichaelHampton It's not quite true that the switch has no way of knowing. The switch will know that it lost link on the port, and dropping all CAM table entries related to a port when link is lost on the port would make sense. I have however never tested if switches do that. – kasperd Mar 17 '18 at 10:39
  • 1
    @kasperd Apparently some switches do that and some don't. – Michael Hampton Mar 17 '18 at 19:19