NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
M4300 VLAN routing interface gets down with stack master
My simplified lab setup is two M4300-12X12F, stacked up. All ports, except stack ones, are set as follow:
interface x/x/x switchport mode trunk vlan acceptframe vlanonly vlan ingressfilter exit
There are couple VLAN's:
vlan database vlan 2,3,4 vlan name 2 "V2" ... and so on ... vlan routing 1 vlan routing 3 exit
And finally ip address on vlan interface:
configure interface vlan 3 routing ip address 192.168.5.6 255.255.255.192 exit
When stack is powered up, everything works fine.
I can ping ip address in vlan 3, and even can reach management web interface, despite not using "ip management vlan ...".
My problem is:
When stack master is turned off, ip interface on vlan 3 goes down, and only way to bring it back is to restart whole stack (the one remaining switch or event booth in any order). Everything else works fine - packets are forwarded through all VLANS in layer2.
But inter-VLAN routing becomes completely unusable, and also VLAN management interface, if was set up.
Am I doing/understanding something wrong, or is it some kind software/hardware error?
Im using newest 12.0.7.15 firmware.
I've have some issues on a mixed stack of 1x M4300-12X12F (same as yours) and a M4300-52G-PoE+ with this firmware version where initiating a failover between master and standby master (configure; stack; initiate failover) would render a stack management inaccessible. Although not exactly the same thing, a manual failover or a power off event on the master leads to the same situation where the standby master will take over the stack master role.
Could you check that when you initiate a failover like me that the new master has some ports in DETACH state when you issue the 'show port status all' command? If you lose access over SSH, try the serial console, it remained working in my situation.
I'm currently working with Netgear on an issue with this specific version and testing a beta release after they have done some preliminary testing internally. I don't do any inter-VLAN routing on the M4300's so my use case is not entirely compareable to yours, additionnaly this only happened on that mixed stack but not on another stack with 2 M4300-52G-PoE+'s.
If you see the same behaviour load 12.0.7.10 into the other firmware bank and start it. In my case failover was still rather slow and causing some packet loss, but overall working. If things are similar I could send you my case number in private so you could point the Netgear support to potentially give you access to that release. (I am not permitted to do so by the beta agreement which I had to accept for this support case)
12 Replies
When I've tried "reset" interface as follow:
configure interface vlan 3 no ip address exit exit vlan database no vlan routing 3 vlan routing 3
got message:
../../../../andl/hapi/esw/switching/broad_l2_std.c 3095: In hapiBroadAddrMacAddressEntryAdd call to 'bcmx_l2_addr_add' - FAILED : -6
Despite message I'm going on with:
configure interface vlan 3 ip address x.x.x.x /x
ending with interface set up properly, but still down.
Errata:
Desoite -> Despite
proberly -> properly.
Sorry, I'll try remember use spellchecker button next time.
Couple minutes after turning on former stack master:
Trying to attach more units..... RPC - Timeout to CPU: xx:xx:xx:xx:xx:xx. ATP: TX timeout, seq 7. xx:xx cli 778. to 1 tx cnt 21. ATP: TX timeout, seq 122. xx:xx cli 780. to 1 tx cnt 21. ATP: TX timeout, seq 59. xx:xx cli 8. to 1 tx cnt 21. ATP: TX timeout, seq 8. xx:xx cli 778. to 1 tx cnt 21. ATP: TX timeout, seq 124. xx:xx cli 780. to 1 tx cnt 21. RPC - Timeout to CPU: xx:xx:xx:xx:xx:xx. disc ERR: Timeout occurred l7_usl_bcmx_l3.c:369 : USL: error creating L3 interface for mac xx:xx:xx:xx:xx:xx vid 1: VrfId 0: hwRv=-8 dbRv = 0 L3 interface create failed because the MAC Address is already present. Please try again later l7_usl_bcmx_l3.c:369 : USL: error creating L3 interface for mac xx:xx:xx:xx:xx:xx vid 3: VrfId 0: hwRv=-8 dbRv = 0 L3 interface create failed because the MAC Address is already present. Please try again later
Despite that message both units work fine in layer 2, as far as I can verify.
But VLAN 3 ip interface is still down (VLAN 1 also, but I not use it, so dont care).
I've have some issues on a mixed stack of 1x M4300-12X12F (same as yours) and a M4300-52G-PoE+ with this firmware version where initiating a failover between master and standby master (configure; stack; initiate failover) would render a stack management inaccessible. Although not exactly the same thing, a manual failover or a power off event on the master leads to the same situation where the standby master will take over the stack master role.
Could you check that when you initiate a failover like me that the new master has some ports in DETACH state when you issue the 'show port status all' command? If you lose access over SSH, try the serial console, it remained working in my situation.
I'm currently working with Netgear on an issue with this specific version and testing a beta release after they have done some preliminary testing internally. I don't do any inter-VLAN routing on the M4300's so my use case is not entirely compareable to yours, additionnaly this only happened on that mixed stack but not on another stack with 2 M4300-52G-PoE+'s.
If you see the same behaviour load 12.0.7.10 into the other firmware bank and start it. In my case failover was still rather slow and causing some packet loss, but overall working. If things are similar I could send you my case number in private so you could point the Netgear support to potentially give you access to that release. (I am not permitted to do so by the beta agreement which I had to accept for this support case)
After powering off stack master (unit 1), all ports was fall into Detach link status, no matter connected or not.
After powering unit 1 back (is no longer stack mater of course), all ports on it was back to Up or Down status.
But on unit 2, now stack master, all ports are still in Detach link status, and still properly worked in layer2.
Interesting. In my case losing the L2 connectivity to the switch was not always happening, like more after the second or third failover in my case. Could do a 'initiate failover' instead of powering down a switch? (to be closer to what happened to me, this could help Netgear support*) and then try the same on 12.0.7.10 to see if it doesn't happen on that release?
At that point I can't tell 100% if 12.0.7.12 is affected as well, but Netgear and I were both able to confirm that failover, albeit rather slow, would definitely work on 12.0.7.10 but does have issues in certain combinations on 12.0.7.15. The beta release I'm testing looks like it improves both failover stability and failover time overall, but I have only enabled it since a couple of days.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
