Core Switch to MX Trunking Best Practice

[DevinM]

Hi everyone,

I've inherited full responsibility for a network I didn't set up.

I know that the MX products don't support LAG, this has resulted in a configuration in the environment I've inherited that seems like it might be wrong to me.

Relevant to my question, we have two MX250s in an HA arrangement and then two MS425-16 core switches that are in a stack configuration.

Basically, my predecessor, upon realizing that the MX doesn't support LAG, decided to make a single all-VLAN trunk link from each of the MX250 units in our HA set up to one of the MS425-16 core switches (MX1 <-> MS1 and MX2 <-> MS2).

For redundancy, his solution was to access links from each MX to each switch (MX1 <-> MS1 + MX1 <-> MS2) for each VLAN.

This is the current MX VLAN setting.

I've blocked out VLAN names so as not to distract.

Looking at one of the core switches, I see that the access ports are a mix of forwarding and blocking.

This tells me that the configuration is at least sort of working as intended. But I've added new VLANs to the all-VLAN trunk in the past and they don't work until I add an access link as well, which doesn't seem right to me.

So, I'm wondering if this practice of combining access and trunk links for redundancy on an MX is recommended or not, because it seems very unconventional to me. How do people usually handle the lack of LAG support on the MX products?

I appreciate any guidance with respect to cleaning this if up if necessary.

Thanks you.

[Ryan_Miles]

Hey @DevinM,

This doc has two of the commonly used and supported designs. You're correct in that MX doesn't support LAG today. So, the common practice is connect each MX in a HA pair to a set of LAN switches (be it a physical stack or not).

These links would typically be trunks with the native and allowed VLAN list matching on the MX and switch side. Of course the MX could just have a single transit network to a L3 core switch as well. But in your case it does sound like all your L3 interfaces (or at least many of them) live on the MX - which is very common.

You may also want to check out the Meraki Campus LAN Planning, Design Guidelines and Best Practices doc which goes deeper into recommended designs and config details. 

[DevinM]

Thank you for the reply, Ryan. I'll certainly take a look at the documentation you've linked.

Would you mind weighing-in on the conventionality of the trunk + access link configuration I've mentioned?

I'm wondering if it's maybe contributed to some of the odd behavior and difficulty (which I'll keep out of this post) that we've had with the network.

Thanks, again.

[cmr]

@DevinM they should all be the same, trunk if you have more than one VLAN that needs to go from MS to MX, access if only one.

[Ryan_Miles]

A common approach for your network would look something like this.

- No direct link between MXs

- Lowest physical port(s) of "Active" stack member switch become root port(s), port(s) on the member switch in the stack would be in STP blocking under normal conditions

- All LAN ports on the MXs and MSs would be trunks, allow all VLANs (or you can specify the exact VLANs in use if you like), and have matching native VLANs

- The native VLAN can be whatever you want. Often that could be the mgmt VLAN for the Switches for config simplicity. 

- Use link aggregation groups between the MS425 stack and the downstream Switches

@DevinM what issues are you currently seeing with the deployment today?