SG-3100 switch weird behavior (resolved)

mcury

@johnpoz Exactly, its so weird, that packet should never go to pfsense's LAN1 ..

I'll try to fix it tonight by reinstalling my pfsense from scratch..
Then, if the problem happens again, I'll replace this switch..

stephenw10

Yeah, it's a pretty basic switch and there's no control over things like the MAC table. That's the only thing I could imagine causing that though.

If you haven't already try power cycling the 3100 entirely. That should completely reset the switch if it's somehow managed to toggle some flag.

Steve

mcury

@stephenw10 hm, I'll try it now a shutdown, remove the power cable, one sec, let me see who is here using the Internet

mcury

Done, the problem persists..

Halt system and once the shutdown process ended, removed the power cable for a few seconds.

stephenw10

Hmm, the only other thing I could imagine causing this is if something feeding bad data into the switch MAC table. That would have to be the desktop machine.

If you run a continuous ping from the RasPi to somewhere that has to be accessed through the 3100 switch, does that prevent the issue?

If it does I'd try to find something sending the RasPi MAC from the desktop. Hard to say what that might be.... something reflected perhaps?

If you run a pcap on the desktop and filter by the RasPi MAC address whilst the problem is not happening and wait for it to start. The first thing that happens there might be the offending packet.

Steve

mcury

@stephenw10 said in SG-3100 switch weird behavior:

If you run a continuous ping from the RasPi to somewhere that has to be accessed through the 3100 switch, does that prevent the issue?

Testing now, ping is running from RPI4 to pfsense.
It seems to have stopped, but it may start again soon, so I'll wait a little longer this time.

Packet capture set:

Edit:

This is my ARP table (desktop)

$ cat /proc/net/arp
IP address       HW type     Flags       HW address            Mask     Device
192.168.255.252  0x1         0x2         00:11:32:9f:ee:93     *        enp7s0
192.168.255.249  0x1         0x2         00:08:a2:0c:c4:1c     *        enp7s0
192.168.255.250  0x1         0x2         b8:27:eb:ea:f8:65     *        enp7s0
192.168.255.253  0x1         0x2         dc:a6:32:a5:47:19     *        enp7s0

mcury

40 minutes pinging from raspberry pi 4b (192.168.255.253) to pfsense (192.168.255.249) and no problem so far.

I have two wireshark windows opened, one monitoring:
eth.src == dc:a6:32:a5:47:19 and not tcp.port == 22 and not tcp.port == 9000

And the second one monitoring:
ip.addr == 192.168.255.253 and not tcp.port == 9000 and not tcp.port == 22

mcury

Dropped the ping and one minute later (or less), the problem starts again:

desktop ARP table:
$ cat /proc/net/arp
IP address HW type Flags HW address Mask Device
192.168.255.252 0x1 0x2 00:11:32:9f:ee:93 * enp7s0
192.168.255.249 0x1 0x2 00:08:a2:0c:c4:1c * enp7s0
192.168.255.250 0x1 0x2 b8:27:eb:ea:f8:65 * enp7s0
192.168.255.253 0x1 0x2 dc:a6:32:a5:47:19 * enp7s0

stephenw10

Hmm, so nothing from the RasPi MAC address at the desktop that might be inserting invalid entries into the switch.

It might be worth re-running that test using the RasPi MAC as destination in the filter (or as either).
You might catch something arriving using that but a different IP address.

Also when this happens do you see traffic being sent only to the desktop? Or is the syslog traffic sent to all the 3100 switch ports? Does it also arrive at the RasPi?

Steve

mcury

@stephenw10 It seems that its only going to LAN1..

raspberry pi 3 in which you see the tcpdump above is connected to the switch unifi mini.

Let me perform this test again, but in the NAS which is connected to LAN2 of pfsense, one sec.

mcury

Hmmm, its going to port LAN2 of pfsense too:
NAS IP is 192.168.255.252 (tcpdump) (LAN2 of pfsense)

On the right, wireshark running on desktop (LAN1 of pfsense)

stephenw10

Aha, interesting. You wouldn't expect so see it on one of the other Unifi swtch ports because it should only send it out of the port that MAC is connected to. So to the RasPi4 there.

The same should be true of the switch in the 3100 The fact it seems to be sending it to all ports implies that it no longer has a an entry for the MAC address in it's table. If it was an incorrect entry as I speculated earlier then it would only send from port 1.
Because that traffic is UDP with no replies it never sees any traffic from the RasPi4 to repopulate the table. Is the RasPi configured with a static IP?

It seems unexpected that the table entry has expired though. How long does it take to fail after sending some pings approximately?

Steve

johnpoz

@stephenw10 said in SG-3100 switch weird behavior:

How long does it take to fail after sending some pings approximately?

the default cache in pfsense is like 20 minutes, but maybe not for the switch mac table? Is there anyway to view the switches mac address table?

mcury

@stephenw10 said in SG-3100 switch weird behavior:

Because that traffic is UDP with no replies it never sees any traffic from the RasPi4 to repopulate the table. Is the RasPi configured with a static IP?

raspberry pi 4b its on dhcp, no services running on it, only graylog, which means that the device only receives UDP data.

It seems unexpected that the table entry has expired though. How long does it take to fail after sending some pings approximately?

I'll try to get that info right now.

mcury

@johnpoz said in SG-3100 switch weird behavior:

the default cache in pfsense is like 20 minutes, but maybe not for the switch mac table? Is there anyway to view the switches mac address table?

I'm really missing my old Cisco days, show mac-address table vlan x :)

johnpoz

@mcury hehe - yeah would be easy to see then.. Why I like my routers with interfaces, leave the switch ports to the actual switches ;)

mcury

@johnpoz said in SG-3100 switch weird behavior:

@mcury hehe - yeah would be easy to see then.. Why I like my routers with interfaces, leave the switch ports to the actual switches ;)

:) Yes, you have a point there ehhe

tcpdump in pfsense during the DHCP negotiation with raspberry pi 4b

stephenw10

Yeah the pfSense ARP cache expiry time is completely independent of the switch MAC table. I don't believe there's any way to query the switch IC for the table or for the expiry time.

Steve

mcury

@stephenw10 said in SG-3100 switch weird behavior:

Yeah the pfSense ARP cache expiry time is completely independent of the switch MAC table. I don't believe there's any way to query the switch IC for the table or for the expiry time.

Steve

3 minutes exactly.

mcury

I recorded, not sure if its going to be useful..
arp_problem.zip