Switch - blocking access to radios

[eomedia]

Just happened again - reboot switch and problem resolved

[sirhc]

Please post up screen grabs of the following Switch TABs:
Status
Ports
VLANs
Device/Config
Device/Status

To upload screen grabs follow instructions in my post footer

[mike99]

I am NOT a network guru so this is a bit of a guess on my side but seems relevant. When the issue is happening doing "show vrrp summary" on R1 and R2 shows that the VRRP state on both routers is backup - no master. After reboots of both routers there is no change - then after rebooting the netonix swtich one of the routers will show VRRP state master as expected and now things are working.

It's a strange beavior since, if the backup fail to see the master, it then become master. If it's was a communication problem in VRRP, both should be master, not slave.

Have you tryed this:
https://supportcenter.checkpoint.com/su ... d=sk119212

Else it could be multicast related problem on the switch. A network capture could help try to find out what going on. You can capture those via the port mirroing option and with wireshark or tcpdump on a *nix system.

[eomedia]

Okay, so it just happened again and it looks like a router (R1) just rebooted and in doing so both R1 and R2 are showing VRRP in backup state - neither is master. I went ahead and took a screen capture of all the tabs requested and attached.

At this moment for Example - the radio on Port 5 is NOT accessible - connected directly to the switch. I can login to the radio at the remote site and it shows that the link is operational and passing 127 Mbps of traffic.
The thing is once I reboot the switch the VRRP states of active/backup will likely start working just fine and I'll be able to access all the radios without any other action taken.

I also included the port detail for Port 5 as a reference.

[eomedia]

I read the article on the link but as I'm not sure how to run cpconfig to test that theory - not an option for ERX-SFP as far as I can tell.

[mike99]

I read the article on the link but as I'm not sure how to run cpconfig to test that theory - not an option for ERX-SFP as far as I can tell.

Since VRRP is a standard, I was thinking maybe the're a similar option.

[mike99]

At this moment for Example - the radio on Port 5 is NOT accessible - connected directly to the switch. I can login to the radio at the remote site and it shows that the link is operational and passing 127 Mbps of traffic.
The thing is once I reboot the switch the VRRP states of active/backup will likely start working just fine and I'll be able to access all the radios without any other action taken.

You should also have a primary address for test, somethink like
192.168.1.1/24 for VRRP sharred address
192.168.1.2/24 primary for router A
192.168.1.3/24 primary for router B
Can those ping primary address ping each other ?

If you change a setting in VRRP or unplug and plug back the port, does it also fix the problem ? Does a reboot of the VRRP service fix the problem ? It can probably be done via CLI with something like this (if keepalived is use for VRRP but it's probably the case):

Code: Select all

 sudo sh
service keepalived restart

[eomedia]

The VRRP shared addresses will NOT show up in either router because they are both in the backup state - so no shared IP is listed. Keep in mind however that I can reach each router on it's primary IP and the switch itself - just not the radios connected to the switch.

Off of this site I also have 1 AP/client connection (switch <--> AP <--> CPE) and when this happens that client cannot access the internet.

I can reboot either router and it does not fix the problem - I am not able to plug/unplug a cable in the router or switch as the location is a 90 minute drive and fixing the connection with a switch reboot has to take place fairly quickly.

[mike99]

If possible, you could try to disable both ports connected to both router at the same time and after, enable back both ports at the same time. That would let you know if it's port down / up that fix problem or switch reboot.