[c-nsp] Dual Homed Site with L2 Backup

[Richard Clayton]

Thanks for the replies

In the current topology the customer connects the L2 circuit directly to
their core L2/L3 switches which I have no control over.  When the L2 is
connected and the tunnel is up a L2 loop forms and because spanning-tree is
not forwarded over VXLAN or OTV tunnels, it can't be used to detect and
block loops.  To counter this I enabled spanning-tree on the two 4431 (MST)
and gave them both the lowest bridge priorities in the tree.  I also
enabled root guard on 4431-2 LAN interface.  When all is connected 4431-2
sees a superior root advertised into its LAN interface (from 4431-1),
4431-2 then blocks this interface and as a result blocks the loop.  When
the L2 p2p is dropped 4431-2 stops seeing the superior root and unblocks
the port allowing the tunnel path to be the new L2 path between the sites.
I tested this with different customer spanning tree modes and with both
VXLAN and OTV, both worked well and failed over consistently using the root
guard feature.

Observations - Configurations
* Even though VXLAN isn't officially supported on the 4431 it works
flawlessly.
* With the throughput license enabled I was pushing 900Mb/s over the tunnel
and the 4431 CPUs were running at 2%.
* Spanning-tree can't be used to detect and block loops but root guard can
be used to detect a superior root and in practice blocks the loop.
* I costed out the link from customer core L2 to 4431-2.
* I always used MST on the 4431s but tested MST and Rapid PVST on the
customer side.

It would be interesting to test the other suggestions you guys have made.

Thanks
Rick

gamma.co.uk


On Sun, 23 Dec 2018, 17:46 Hunter Fuller <hf0002 at uah.edu wrote:

> Yes, this is what we are planning. We are landing the L2 circuit (in our
> case, it's over DWDM) on the VTEPs directly. But they also have access to
> an L3 path through the IGP. The tunnel is always in use.
>
> --
> Hunter Fuller
> Network Engineer
> VBH Annex B-5
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Systems and Infrastructure
>
>
> On Sun, Dec 23, 2018 at 11:03 AM Arie Vayner <arievayner at gmail.com> wrote:
>
>> One approach I can see to make it work consistently regardless what path
>> it
>> takes is to use the overlay at all times, even when the primary path is
>> up.
>>
>> Basically you just make the layer 2 link routed (i.e. terminate it with
>> layer 3 ports on both ends), and run the VXLAN one hop before (or anywhere
>> it makes sense).
>>
>> This way you just run a vxlan extension over a layer 3 redundant path.
>>
>> On Sun, Dec 23, 2018, 02:48 Richard Clayton <sledge121 at gmail.com wrote:
>>
>> > Hi Arie
>> >
>> > I did encounter the MTU requirement and configured the lab to allow for
>> > it.  VXLAN may be the future but this topology isn't really what it was
>> > intended for, due to the loop it creates (same with OTV).  I was still
>> able
>> > to ceate a working design for both protocols regardless.
>> >
>> > Would interesting to see how others would meet the requirement with this
>> > particular set of constraints.
>> >
>> > Thanks
>> > Rick
>> >
>> > gamma.co.uk
>> >
>> >
>> >
>> > On Sat, 22 Dec 2018, 20:29 Arie Vayner <arievayner at gmail.com wrote:
>> >
>> >> Vxlan is the future... 😉
>> >> Be very careful with the mtu implications.
>> >>
>> >> Tnx, Arie
>> >>
>> >> On Sat, Dec 22, 2018, 03:25 Richard Clayton <sledge121 at gmail.com
>> wrote:
>> >>
>> >>> Hi Guys
>> >>>
>> >>> Scenario
>> >>>
>> >>> Customer has dual homed geographically seperated site into mpls wan.
>> >>> They
>> >>> also have a single layer 2 circuit running between the two.  The
>> >>> requirement is to backup the layer 2 over the wan circuits.  The wan
>> >>> hardware at both sites is cisco 4k ios xe.
>> >>>
>> >>> I'm interested to know how you guys would achieve this.  I've had the
>> >>> luxury of 4 days in the lab testing VXLAN, OTV and L2TPV3 xconnect
>> >>> between
>> >>> the two 4k routers, also did JDSU throughout testing over the tunnel,
>> was
>> >>> quite interesting.
>> >>> _______________________________________________
>> >>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> >>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> >>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>> >>>
>> >>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>