[c-nsp] Help with MAC control on redundant L2 links.

[Saku Ytti]

How would you imagine it works, in a world without any limitations?
This seems like a day1 building ethernet LANs question, unless I'm
missing something.

Comcast learns the 1701 now from every site.
Frame comes in with DMAC 1701
Where does Comcast send it? Should it balance between three sites? And
re-receive then if it happened to send it to B or C?

My imagination doesn't stretch how this could possibly work. And this
is exactly why Radia invented STP, to automatically remove all
redundancy until such time that it is needed.

What I would do is run MPLS point-to-point  A<->B, A<->C, B<->C (not
use any comcast or zayo provided multipoint service). And then run
EVPN on my edge ports. EVPN will allow you to even ECMP.

If that is not an option, run standard MSTP with two topologies. One
topology blocks on Zayo another on Comcast. Put half VLANs on
Zayo-first half vlans on Comcast-first. Now because STP blocks
redundant ports, you'll learn [BC] MAC from a single port guaranteed.
You will lose RST convergence benefits because your 'core' port is
facing >1 other 'core', basically you have a 'hub' between your core
ports. So even this topology would be better if you don't buy
multipoint service from a vendor, but point-to-points (w/o mac
learning).

I would very strongly encourage not to go the STP route, and look towards EVPN.


On Sat, 12 Nov 2022 at 23:54, Howard Leadmon via cisco-nsp
<cisco-nsp at puck.nether.net> wrote:
>
>
>   I have an issue I am trying to sort out that I haven't run into
> before, and figured someone might be able to give me a few pointers.
>
>   I have three sites lets say A, B and C, and they all have redundant
> connectivity via two Layer 2 fiber loops with two different carriers.
>
>   We use Comcast and Zayo to reach the various sites, but realized that
> I was having connectivity issues, but after talking with Comcast, they
> are informing me the issue is the MAC being presented from different
> locations at the same time.
>
> So say at Site-A I am presenting a mac ending in 1701, I of course
> present this to both Comcast and Zayo, as expected.   Now at Site-B, I
> am being informed that when my switch receives that 1701 down the loop
> from Zayo, it is of course presenting it back to Comcast as a valid
> MAC.  As such they say they are learning this MAC from multiple
> locations at the same time, and they can only support learning it from
> one point, so they drop the MAC.   Of course Site-C has the same issue,
> also presenting what it knows from the other points.
>
> I thought setting 'spanning-tree link-type shared' allowed it to handle
> this, but I am guessing not well enough.  Well it might let the Cisco
> handle it, but apparently is playing havoc with the Ciena switches that
> Comcast is using.
>
> I looked at setting a mac filter (maybe I am looking at this wrong) to
> say if you saw this coming in, don't resend it back out to any other
> place. The issue I saw, was it only allowed it to be an ingress filter,
> which means I would discard the address completely which doesn't seem
> good either.
>
> I am sure there is a right way to handle this, but honestly not
> something I have encountered before.  If anyone could give me any hints,
> or point me to something that might help it would be appreciated..
>
>
> ---
> Howard Leadmon - howard at leadmon.net
> PBW Communications, LLC
> http://www.pbwcomm.com
>
> _______________________________________________
> 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/



-- 
  ++ytti