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?

[RaphaelL]

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

Is there a proper way to provision a stack without placing the "Active" stack member on top ? In your example MS425-16-1 has to have a lower MAC than MS425-16-2 if you want to have the "correct" ports in blocking. It is a bit annoying because even if you place the lowest switch MAC on top , after a RMA you have to rebuild the stack according to the MAC. Selecting the "Active" stack member from dashboard would solve that , but no idea if there are any plans for that

[DevinM]

Yeah, this is, more or less how it's setup. The big part I'm wondering about is the combination of trunk and access links. I get that it's unconventional, but is it possible that it's actually problematic?

[cmr]

Unless you are only trunking 1 VLAN then the access links will cause issues.  Either way, they should 100% all be the same.

[DevinM]

Would you mind elaborating on that a bit?

There are MX1 <-> MS1 and MX2 <-> MS2 all-VLAN trunk links and MX1 <-> MS1/2 + MX2 <-> MS1/2 access links for each VLAN.

So, if I'm understanding what you said properly, if we're only trunking a single VLAN but using access for the other VLANs, we should be okay, but it still wouldn't align with the best practice of keeping things consistent. Otherwise, having a trunk link and access configured for the same VLAN (or many in our case) would cause problems.

In that case, the recommendation would be that I remove all of these extraneous access links and only leave the trunk links, right?

I just want to be clear so that I don't schedule downtime for maybes. Is it certain that combining an trunk link and access link for the same VLAN on an MX would cause problems? If so, do you know if there's any documentation for reference when I submit my planned maintenance window?

Thank you for your input, I appreciate it. I'm savvy with networking, but the Meraki ecosystem is sometimes a thing unto itself.

[PhilipDAth]

> 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).

I personally like this approach the most, and no other LAN-based links.