MACs Not Passed Between Ports v1.5.5 - Verified TWICE

[kennedy101]

MAC Addresses not sent to Cisco Router (multiple sub interfaces) – Resolved in 1.5.3 DOWNGRADE

We ran into an issue yesterday with a WS-12-250-DC (Firmware 1.5.5 & 1.5.6, Board Rev F, Power Supply Firmware 70, Power Supply Rev B, MAC ec:13:b2:84:27:14). We have the following Vlan configuration.
Vlan ID Name 1 12
1 MGMT E U
2020 Radio U T
2021 PIPE T T

Port 1= Ceragon 820 Radio. MGMT was untagged on both service points.

Port 12=Cisco router
Physical interface on same subnet as Netonix MGMT.
Subinterface dot1q 2020 = Same subnet as Cergaon radios (both ends)
Subinterface dot1q 2021=PIPE that links Cisco routers (routing protocol in play)

The A end of the radio hop had a similar vlan setup, but was a different Netonix model (WS-26-400-IDC). Thankfully we had LTE out of band management to the Z end where the problem exists on the WS-12-250-DC v1.5.5. The Z end did NOT have ARP entries for vlans 2020 and 2021 at the Cisco router, but it did have an ARP entry for MGMT vlan so we could manage the switch. Note, we did have out of band LTE connectivity to the Cisco router hence we were able to connect to the Z end Netonix. Again, no ARP entries for the Radio MGMT (2020) or the PIPE connecting the A & Z routers (2021).

During troubleshooting I moved the vlan 2020 SVI on the Z end over to the A end and I COULD mange the radio that was connected to the Z end switch. At this point the Cergaon management service point configuration was determined to be good (pretty simple, untagged management on the radios). Also, we noted the MAC address for BOTH the A and Z end radios WERE PRESENT on the Z end switch port #1. Still no ARP entry on the Z end.

Note, the A end of this scenario has a total of FIVE P2P radio pairs planned. One of the five was already working with a very similar vlan setup (vlan 2026 Ceragon radio management and 2027 for the PIPE). It was commissioned last week (Thursday 10 Sept 2020). A second P2P off the A end tower was activated while troubleshooting the Z end issue and it worked great. We noted the newly commissioned site was also a 12 port Netonix at the far end, but was running firmware 1.5.2 (Board Rev F, Power Supply Firmware 70, Power Supply Rev B, MAC ec:13:b2:83:9b:92). To be clear, at this point we had two working P2P paths from the A end tower and one non-working P2P path – all 3 using Netonix switches at the far end.

Back at the problematic Z end site we threw in a NIB 8 port Netonix we had on hand and the path worked as expected. We now had ARP entries for sub interfaces 2020 and 2021 on the Cisco router (we now have adjacency between the two routers). We now know and trust the radio and router configurations end to end. We put the 12 port v1.5.5 back in play – same issue. We upgrade to version 1.5.6 – same issue. We attempt to downgrade to v1.5.2 (matching the newly commissioned site that’s working) and an error that the temperature sensor wasn’t compatible was returned. Thankfully the error message told us the oldest version we could run was 1.5.3. Finally, we moved to version 1.5.3 and the issue was resolved.
Justin Kennedy

[kennedy101]

Same issue today. Much simpler setup.

Port 1, untagged vlan 2004
Port 3, untagged vlan 2004

Port 1 is a Force 200 P2P, no vlan configuration.
Port 3 is a Windows 10 PC

The tech on location at the Windows 7 PC has 169.254.1.100. He cannot ping the Force 200 default IP 169.254.1.1

Downgrade from version 1.5.5 to version 1.5.3 and he is now able to login to the Force 200 default IP .

[mayheart]

There's a bug with 1.5.5 preloaded on switches. If you reflash 1.5.5 or upgrade to 1.5.6 it will fix the issues.

[kennedy101]

Upgrading to 1.5.6 did NOT resolve my issue. Odds are we're set to stay on 1.5.3 for a LONG time. Not going to retest anytime soon.