M4300 12x12f no vlans while stacking failover
Hi MasterPhil
Welcome to the Community!
Let me first understand your setup, by explaining its reference design. A stack of two M4300-12X12F is a great redundant "core switch" for small to midsize networks. Let's speak about 'left' switch and 'right' switch, should those two half-width M4300 10G switches are horizontally stacked and occupying same U in your rack:
Say the left switch is the Master management unit. In case of failure, the right switch will instantly take over as new Master management unit in the stack. So far he was the Backup management unit. With NSF (nonstop failover) there is no service interruption across this stack, including all LACP (distributed ling aggregation) links across both switches from rest of the network. This would imply your S3300 switches under the M4300 core stack should connect to both left and right switches using LACP connections (so dynamic LAGs). This way, no North-South service interruption for your access layer switches, should left or right switch at the core failover and failback again. Can you make sure you have LAGs properly configured on the core stack, and on your S3300 switches dual-homed to the core as well:
- On Fully Managed switches like M4300, LAGs are dynamic (LACP) by default
- On Smart Managed switches like S3300, LAGs are static by default, please enable Dynamic/LACP mode manually
Now, your VLAN issue. Thank you for reporting it. It shouldn't be any in case of failover (whole point of such High Availability installation). I can tell you this use case is heavily tested by us, and litterally by thousands of M4300 delighted customers, a few quarters only into its launch!
Let's understand the root cause of your VLAN discrepancy on the right switch. First of all, the right switch is active even when it's only the backup management unit, with the left switch up and running as Master management unit. In reading your explanations, I was under the impression you weren't sure of that. Of course we can test and remove power cord from left switch, in order to trigger accidental failover to right switch in terms of management, etc... but again, right switch is functional during normal stack operation. Moreover, the right switch configuration shouldn't change at all during the failover.
Why? Because there's only one configuration file for your entire stack. If you are using the Web GUI, you can open this configuration file by going Maintenance --> Export --> HTTP File Export and choose Text configuration in the drop menu:
Please do so and look at your Port VLAN configuration: say the left switch port and the right switch you are sequentially connecting your PC to.
- If this is the Port 15 on left switch, the port is called 1/0/15, meaning Unit=1 / Physical interface(so 0) / Port=15
- If this is the Port 15 on right switch, the port is called 2/0/15, meaning Unit=2 / Physical interface(so 0) / Port=15
If the VLAN behavior isn't the same between 1/0/15 and 2/0/15, it means the VLAN configuration isn't the same between 1/0/15 and 2/0/15. Again there's no configuration change during failover and failback: the configuration file is unique on both switches. Last, you don't need to force the failover from left switch to right switch, before testing your PC connection between 1/0/15 and 2/0/15. With the left switch up and running as Master management unit, please test your PC connected to 1/0/15, and then disconnect from left switch and connect your PC to right switch, port 2/0/15. If VLAN doesn't work, it means your configuration on 2/0/15 is the issue.
Can you control this? The Community will be happy to assist you further, please report the result.
Regards,
Hi MasterPhil
All good questions here, I'm sure it will be of fair interest for many other members in our Community.
Let me answer your questions the one after the other.
Yes your 'right' core switch is active, not in standby mode in terms of switch operation. When you go to System-->Stacking-->Basic-->Stack Configuration, please control it's like:
In my setup, left switch is unit 1 and right switch is unit 2.
- Left switch (unit 1) is Management unit, so the stack master
- Right switch (unit 2) is StackMember, so a member of the stack.
Next column Standby status shows right switch (unit 2) as 'Opr Standby'. This is normal, in a two-switch stack the second unit is meant to handle the Backup management role. For this, it is standby in terms of Management. But management only! Aside from this management role, the right switch (unit 2) is fully operational, all ports active and forwarding/routing traffic. Yes, NSF is very important, it is enabled by default, it lets the failover and failback happen without traffic disruption across the stack. Please check if your setup is similar to mine. If not, please fix that first.
I see you have S3300 stacks in your network: M4300 core stack is no different for that. Both switches are operational from a network operation standpoint. One switch is the Master (management unit), the other switch is a stack member handling backup management role (Opr Standby). What M4300 brings you on top, is Nonstop forwarding. This is unique to M4300 (no possible service interruption during failover and failback operations).
Yes, as much as you can, you should have your other network devices (servers etc..) and access layer switches dual-homed to your core stack using LACP link aggregation across two switches each time. Why? Because LACP LAGs will automatically handle failover and failback operations in your core - so in case of a switch problem at the core - without any service interruption. This is the whole point of a redundant core: dual-homed connections to that core using LACP for load-balancing and instant failover from one link to the other without breaking UDP/TCP sessions.
If your S3300 stacks at the access layer have one link from each S3300 switch to each M4300 switch at the core without LAG, this is not good. You are creating loops in your network all the way South to North. Hopefully M4300's are gentle enough to handle this automatically with RSTP enabled by default and shutting down the ports where loops are occuring in real time. But you must realize it is a problem, since you have ports shutdown by spanning tree at your core when it shouldn't be, right? With dual-home connections from your S3300 stacks at the edge to your redundant core, what you want is load-balancing, and automatic failover without possible outage. So yes, for that please disconnect your S3300s, and create LAGs on your S3300 stacks, and LAGs on your M4300 core stack. Please enable LACP (dynamic LAGs) on your S3300's since it is disabled by default on Smart managed switches.
LAGs you will not use your old current port configuration anymore, so please configure the new LAGs after they are created (VLAN membership). In general, LAGs carry all tagged VLANs as trunks, plus one untagged Native VLAN (PVID) if needed.
The VLAN problem: yes please check, it is very likely you have different configuration between 1/0/15 and 2/0/15 at this stage. Please make it the very same. Please download the configuration file as I said earlier to double-check that, it is sometimes easier to read a text configuration file all the way for spotting mistakes (at least for me).
Your last questions:
- Please refer to this other post in order to use built-in DHCP server pool on your M4300 core stack and 'attach' each DHCP server to each VLAN
- If your have one DHCP Server per VLAN in your M4300 core stack, you can use DHCP Relay agents on your S3300 edge switches. First please check all your LAGs can carry all VLANs properly as trunks for good North-South VLAN proliferation. Second please consult S3300 user manual starting page 93 for enabling L2 DHCP relays on your S3300's for each of your VLANs .
- When you use an external DHCP server on another subnet and where there's no active static route leading to it for a particular switch in your network, you need Layer 3 DHCP (UDP) Relays on each VLAN, which Smart managed switches like S3300s don't provide. Only M4300 Fully managed switches let you configure L3 DHCP UDP relays indicating the IP address of your external DHCP in another subnet using IP Helpers. So in your case, you should make sure your M4300 core stack properly route all VLANs to the subnet where your external DHCP server is; or configure L3 DHCP UDP Relay on your M4300 core stack for each VLAN, indicating the IP address of your external DHCP server. Please consult M4300 User Manual page 98.
- Is the DHCP active on both cores because of stacking? Again there is misunderstanding here, let's clearly explain it. You have only one core, which is a stack of two switches behaving like a unique, virtual big switch. When you configure it, you see it as a big switch. Other devices in the network also see it as a big switch. When you configure local DHCP server pool on it, you do it for the entire stack and for all switches. Your DHCP server is active everywhere across the stack, this is the whole point of such virtual chassis stacking architecture.
Leads me to indicate this is why M4300 spine and leaf stacking architecture is so popular for midsize networks: when you stack M4300 core 10G switches with all M4300 1G edge switches together - in same big switch - then your configuration (DHCP, VLANs, etc.) is very simple. You manage only one big switch - a real collapsed core from the core to the edge. You have only one configuration for the big switch. All VLANs have their embedded DHCP server locally etc.
- Yes, when activating Layer 3 routing, your VLAN Layer 2 boundaries remain for broadcast - that's why it's good network segmentation - but they are gone for all other inter-VLAN communications at L3. So either you restrict inter-VLAN communication using ACLs, either you deploy Private VLANs on top of your existing VLANs.
I would advise you deploy ACLs. For that, please refer to M4300 Software admin manual which is a collection of configuration examples. Please reproduce Use ACLs to Configure Isolated VLANs on a Layer 3 Switch starting page 184.
I hope it will be helpful for you, please let us know how it goes!
Regards,
