Showing results for 
Search instead for 
Did you mean: 

Joining Switches via OSPF, with LAGs / MLAG, Configuration Best Practice

Valued Contributor

Just creating a configuration and wondered what would be deemed the proper way to do it.

I'm currently joining a legacy network with a new Extreme network, and would like to do it over layer 3 using ospf.

The legacy core network is a stack, and the new Extreme are two separate cores joined via MLAG, and I am also utilising fabric routing on all my VLANs

The link between the legacy and new Extreme is via a LAG, so I'm essentially running a single router on the legacy network via a single layer 2 logical link that is split between two different routers core 1 and core 2 on the Extreme side that is running MLAG.

I also have a /30 subnet configured between Extreme Core 1 and Core 2 to share dynamic route information, and is configured as a point-to-point. All other VLANs have been configured as passive.

So I'm thinking I have two ways of doing this:


Create VLAN-A /30 on Extreme Core1
Create VLAN-B /30 on Extreme Core2
Create VLAN-A /30 on Legacy Core
Create VLAN-B /30 on Legacy Core
Add both VLANs tagged to LAG between Legacy and Extreme
Configure both VLANs as point-to-point in OSPF


Create VLAN-A /29 on Extreme Core1
Create VLAN-A /29 on Extreme Core2
Create VLAN-A /29 on Legacy Core
Add VLAN to LAG between Legacy and Extreme
Configure OSPF as broadcast for VLAN

My thoughts are to go with the second option, predominantly because I'm then adding the same VLAN information to each leg of the LAG / MLAG config on both cores, which seems to me the proper way to do it... not sure if 1st option would even work.

Maybe there is a different way to do?

Many thanks in advance

Valued Contributor
Thanks Erik for going to the trouble of answering this for me, much appreciated.

I had used the 2nd option previously on a different scenario, but was interested in what the response would be for this example, and make sure I wasn't doing anything wildly wrong in comparison.

In my other installation I had pairs of cores in different sites that where MLAG'd together, and connected to each other via a single LAG. My first instinct would have been to connect them separately at layer 3, in exactly the same fashion given in your example.... but the problem was the customer wanted to span VLANs between the buildings.

Appreciate I could have used VXLANs but I instead opted for creating a VRRP VRID for each building, say VRID10 for building A & VRID 20 for building B, and VRID 100 that was common between both buildings that the same VLANs would then be available for both.

In this scenario I also used fabric routing mode and option 2 with OSPF link type set to broadcast.

It worked and seemed the most logical implementation for that scenario...but wanted to check.

Hopefully this thread will help others, certainly helped me loads in the process.

Many thanks

Contributor II
Hi Martin,

from your two options, I'd prefer the 2nd one, because that more closely follows the abstraction of MLAG as one logical link. The OSPF link type needs to be broadcast with this setup (this is the default).

I do not like your 1st option, because the MLAG setup does not provide two independent links to the stack. Thus the layer 3 configuration does not follow the layer 2 model built using MLAG. I am not sure if this would work reliably (simple tests would probably succeed).

Anyway, to have a pure layer 3 interconnect, I'd rather not use MLAG at all. Just create three (3) transfer VLANs with a /31 (or /30 if the stack does not support /31) IP network. One VLAN between stack member 1 and new core 1, one between stack member 2 and new core 2, one between the two new core switches (that can be a /31 . The OSPF link type should be point-to-point for all VLANs. You might want to enable iproute sharing on the Extreme core switches. You might want to extend the topology to use two additional VLANs between stack member 2 and core 2, and stack member 1 and core 2, if this is feasible (available ports, available fiber links, ...).