MS350/MS425 -- Layer3 LAG

[whistleblower]

Hi,

I´ve a question about the possibility of using Link-Aggreation between a MS350 (HQ) and a MS425 Pair (Flexible Stack in two different DataCenters interconnected with DarkFiber) which should be used as a routed Connection, probably with static or dynamic Routing... So the question for me is, is it possible to configure a so called Layer3 Port-Channel on Meraki Switches and if so, how is this configured?

Another question for me is, how does/would the Load Balancing method look? And is it possible to change between methods e.g. src-ip, dst-ip, etc.?

[Bruce]

The Meraki devices don’t have a Layer 3 LAG, in the same way you can’t make a port a Layer 3 interface. The closest you can get is create an SVI (Layer 3 interface) for a specific VLAN on the switch at each end, and the use a LAG which contains only that VLAN. 

The Meraki LAG - which uses LACP - makes use of the IP addresses, MAC and port in its hashing algorithm to determine the member to use, and it not configurable. Please see here, https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Link_Aggregation_a....

[whistleblower]

Hi Bruce,

first - thanks for your response, I appreciate it very much!

---

@Bruce wrote:

The Meraki devices don’t have a Layer 3 LAG, in the same way you can’t make a port a Layer 3 interface. The closest you can get is create an SVI (Layer 3 interface) for a specific VLAN on the switch at each end, and the use a LAG which contains only that VLAN. 

---

maybe you or someone can point out, what would be the difference (advantage/disatvantage) between that suggested solution and a "classic" Layer3 LAG? Probably a better design would be to use no LAG and instead dynamic routing /w the same metric over both links?

---

The Meraki LAG - which uses LACP - makes use of the IP addresses, MAC and port in its hashing algorithm to determine the member to use, and it not configurable. Please see here, https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Link_Aggregation_a....

---

what does that mean exactly - so would e.g. a Server with the IP-Address 192.168.1.1, MAC: aaaa.aaaa.aaaa and Src. Port TCP-3389 always use the same link, without consindering the Destination Side?

[GIdenJoe]

@BruceI'll let you in on a secret.
A layer 3 port on a catalyst switch under the hood is a single port that has access to an internal VLAN and has an interface in that same internal VLAN.

Same for an L3 port-channel.  It are bonded ports that use an internal VLAN and the switch has a vlan interface on that internal VLAN.

So strictly speaking an L3 port-channel is technically the same as L2 with the restriction of single VLAN traffic.

@whistlebloweraccording to the linked document the algorithm uses both source AND destination L2,3 and 4 information.  So chances are very good you'll have an even distribution amongst channel members.

[Bruce]

@whistleblower from a practical perspective there is no difference between the LAG types, they both do the same thing and potentially both use the same control protocols - it’s more above how it’s configured. With regards to the traffic hashing, as @GIdenJoe noted, the document I referenced states both source and destination addresses are used, so a connection between the same client and server, on the same ports will always hash to the same path, but the minute one of the parameters change, source or destination addresses or ports the hash will change, and thus potentially the choice of path.

[whistleblower]

... OK guys, I think I`ve got it - I looked also over some official documents for Cisco Enterprise and I think I understood the basics about the Hashing topic now 🙂 - thank you very much!

may I ask you if you can give me your assessment of the planned design as well?

A MS350 Pair (physical stacked in the HQ) and a MS425 Pair (Flexible Stack, one of each devices in two different DataCenters interconnected with DarkFiber) should use both physical Lines at the same time (= Load-Balancing) for transfering IP-Traffic between the locations!

please have a look at the attached plans, what would you say is the better solution from your side of expirience? Please notice, for Plan-02 I´d like to use OSPF as dynamic Routing Protocol!

Plan-01

Plan-02

[Bruce]

@whistleblower personally I’d go with plan-1. For a network this size I’d try and keep dynamic routing out of it and if you can achieve your high availability goals using LACP then that’s likely to give you less problems. Dynamic routing has its place - where you expect to add or remove subnets and that would cause a lot of changes to static routes - but I probably wouldn’t use it here.

You’ll probably want to allow for a management VLAN too, which is the one the Meraki switches internal management interface will use to connect to the Dashboard. It is highly recommended (basically don’t do it) that the management interface VLAN for a switch doesn’t have a SVI on the switch itself. So your management VLAN will likely terminate on a router or firewall facing the internet, and would be a second VLAN between the head office and data centre - another reason to use plan-1 (unless you have internet access from both locations).

I’d also consider not using the 192.168.x.x subnets if you can. These are commonly used in home networks and if you start using remote access VPN then you can have issues if someones home IP addresses overlap with these. I’d stick with subnets in the 10.0.0.0/8 or 172.16.0.0/12 range if you can.

[whistleblower]

---

@Bruce wrote:

@whistleblower personally I’d go with plan-1. For a network this size I’d try and keep dynamic routing out of it and if you can achieve your high availability goals using LACP then that’s likely to give you less problems. Dynamic routing has its place - where you expect to add or remove subnets and that would cause a lot of changes to static routes - but I probably wouldn’t use it here..

---

OK, but there are no technical advantages or disadvantages, at least I don't have any obvious ones in mind...  🤔

---

You’ll probably want to allow for a management VLAN too, which is the one the Meraki switches internal management interface will use to connect to the Dashboard. It is highly recommended (basically don’t do it) that the management interface VLAN for a switch doesn’t have a SVI on the switch itself. So your management VLAN will likely terminate on a router or firewall facing the internet, and would be a second VLAN between the head office and data centre - another reason to use plan-1 (unless you have internet access from both locations).

---

that`s a really good and of course important point - thanks for the hint! 😅

Hm, but then I´ve to change the switchports from Access-Ports "untagged" to 802.1q Trunking... allowing the so called "transfer-lan" for Routing and as well the Layer2 Vlan for Management as well as the Native-Vlan1 for RSTP and so on...

[Bruce]

I’d have the native VLAN as the Meraki management network, which will also be the one that RSTP runs over (if the network is all Meraki, doesn’t need to be VLAN 1, RSTP just runs untagged on a trunk, technically it has no VLAN assigned). The management VLAN being native also makes things easier when the switch first boots, as it will look for connectivity to the Dashboard on an untagged network first. Then you just have one other VLAN for your transit network.

Just one other comment, in the Meraki network all switches pass all VLANs, and all trunks carry all VLANs initially, so if you really want to keep VLAN 10 and 20 out of your data centre you’ll need to prune them off of the trunk - same applies for VLAN 100 and 200 (keeping them out of head office).

[whistleblower]

hi all,

@Bruce just for my understanding I’d like to ask another question about that design approach in more detail...

Let‘s assume that I use instead of the static routing a dynamic routing protocol like OSPF!

please correct me if I’m wrong - but I think that in that case OSPF won’t use ECMP because it’s only a /30 Network and the two physical links will of course not be noticed in the Routing-table on each side! But because of the use of LACP Bundling on Layer2 some sort of load-balancing will happen... here‘s now the question - will the LACP Load-Balancing Algoritm be used in that case the same way as if I use a classic traffic flow inside a Vlan located on both sides over a Layer2 Etherchannel?

[Bruce]

You are correct there will be no ECMP as there is effectively only one Layer 3 path between the two switches. Even though there are two physical paths, they are effectively one logical path at Layer 3. If you’re using LACP, the LACP algorithm is always that same, and it’s based on source/destination IP address, MAC and port.