Mailing List Archive

Best Practices for Transporting Layer-2 Services
I'm wondering what other providers are doing when they need to transport a
bunch of third-party layer-2 services?

For Example -- if another SP wants to hand you 3 vlans (for example
10,11,12) and have you transport them to a couple of sites. Vlan 10 (could
be Q-in-Q or not) needs to go to sites A and B, vlan 11 (again could be
Q-in-Q) needs to go to sites C and D, etc.

I'm specifically asking (in a cisco world) what do you do to protect
yourself from any funny business (spanning tree, whatever) that may happen
on the other provider's network or on the end-customer's network.

Thanks

Shawn
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Best Practices for Transporting Layer-2 Services [ In reply to ]
On 2023-01-12 16:45, Shawn L via cisco-nsp wrote:
> I'm wondering what other providers are doing when they need to
> transport a
> bunch of third-party layer-2 services?
>
> For Example -- if another SP wants to hand you 3 vlans (for example
> 10,11,12) and have you transport them to a couple of sites. Vlan 10
> (could
> be Q-in-Q or not) needs to go to sites A and B, vlan 11 (again could be
> Q-in-Q) needs to go to sites C and D, etc.
>
> I'm specifically asking (in a cisco world) what do you do to protect
> yourself from any funny business (spanning tree, whatever) that may
> happen
> on the other provider's network or on the end-customer's network.

The normal answer in Cisco land, even today, is to use Martini-draft P2P
pseudowires (either tag or port-based MPLS interconnects) which will use
tLDP for establishment, and should serve you very well (especially at a
port-based level) for a P2P service. In theory tLDP could run in concert
with SR-MPLS, but you might need to think carefully about label
allocation, or... [read on]

... use BGP EVPN, and pay very careful attention to the port security
options (e.g. bpduguard, BUM rate-limits) as well as the ARP/ND
sponging/proxy facilities therein. For multipoint L2VPN, this should be
replacing VPLS now.

Realistically though, protection from storms is hardware dependent, and
making sure that the config is correct is only half of the battle. I
would consider not building L2VPNs for third parties where you don't
control the CE, realistically. Do they really need L2?

Tom
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Best Practices for Transporting Layer-2 Services [ In reply to ]
On 1/14/23 04:40, Tom Hill via cisco-nsp wrote:

>
> The normal answer in Cisco land, even today, is to use Martini-draft
> P2P pseudowires (either tag or port-based MPLS interconnects) which
> will use tLDP for establishment, and should serve you very well
> (especially at a port-based level) for a P2P service. In theory tLDP
> could run in concert with SR-MPLS, but you might need to think
> carefully about label allocation, or... [read on]
>
> ... use BGP EVPN, and pay very careful attention to the port security
> options (e.g. bpduguard, BUM rate-limits) as well as the ARP/ND
> sponging/proxy facilities therein.  For multipoint L2VPN, this should
> be replacing VPLS now.
>
> Realistically though, protection from storms is hardware dependent,
> and making sure that the config is correct is only half of the battle.
> I would consider not building L2VPNs for third parties where you don't
> control the CE, realistically. Do they really need L2?

Tend to agree. We use Martini pw's in our network too. We have stayed
away from VPLS and EVPN, as we find out the most customers can
accomplish complex p2mp or mp2mp via IP instead of Ethernet.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Best Practices for Transporting Layer-2 Services [ In reply to ]
Others mentioned EVPN for ELAN/VPLS type services, but it?s not just for multipoint services. EVPN-VPWS is how we see most who do not have an existing Martini T-LDP deploying P2P L2VPN. P2P is going to be transparent to most of what the customer or 3rd party provider is sending. If they have switches connected everywhere and end up in a loop, that?s something they need to be aware of and mitigate.

Thanks,
Phil

From: cisco-nsp <cisco-nsp-bounces@puck.nether.net> on behalf of Shawn L via cisco-nsp <cisco-nsp@puck.nether.net>
Date: Thursday, January 12, 2023 at 11:46 AM
To: Cisco Network Service Providers <cisco-nsp@puck.nether.net>
Subject: [c-nsp] Best Practices for Transporting Layer-2 Services
I'm wondering what other providers are doing when they need to transport a
bunch of third-party layer-2 services?

For Example -- if another SP wants to hand you 3 vlans (for example
10,11,12) and have you transport them to a couple of sites. Vlan 10 (could
be Q-in-Q or not) needs to go to sites A and B, vlan 11 (again could be
Q-in-Q) needs to go to sites C and D, etc.

I'm specifically asking (in a cisco world) what do you do to protect
yourself from any funny business (spanning tree, whatever) that may happen
on the other provider's network or on the end-customer's network.

Thanks

Shawn
_______________________________________________
cisco-nsp mailing list cisco-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/