[c-nsp] me3600 : l2protocol forward stp on EVC

[BASSAGET Cédric]

Hello WIlliam, thanks for your reply.
I Guess STP frames are still tagged in the customer vlan. I'll try to
capture that and confirm.
Dou you have a sample configuration of your adva CPE which tunnel L2CP ?

Regards,
Cédric


Le lun. 14 déc. 2020 à 13:54, Jackson, William <william.jackson at gibtele.com>
a écrit :

> Hi Cedric
>
> The problem I see here is that on your Nexus port that needs to serve
> multiple customers, how does it treat the untagged STP frames.  Ie to which
> customer would they belong?
>
> What we did to get around this issue was to deploy a CPE at the customer
> site.
> We use Ciena 3903 or Adva FSP boxes.
>
> These will present the interface to the client, they will add the STAG to
> all VLANs and also tunnel the L2 control protocols by changing the well
> known MAC to a "DATA" MAC.
>
> Thus when the frames hit the cisco they are all data frames belonging to
> the customer.  At the other end we revert the tunneling and thus we get a
> transparent port service to the customer through an aggregation port on the
> cisco.
>
> Will
>
> -----Original Message-----
> From: cisco-nsp <cisco-nsp-bounces at puck.nether.net> On Behalf Of James
> Bensley
> Sent: 14 December 2020 11:55
> To: BASSAGET Cédric <cedric.bassaget.ml at gmail.com>; Cisco-nsp <
> cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] me3600 : l2protocol forward stp on EVC
>
> On Tue, 8 Dec 2020 at 10:39, BASSAGET Cédric <cedric.bassaget.ml at gmail.com>
> wrote:
> >
> > Hello,
> >
> > I need to interconnect two L2 domains. I was planning to use a me3600
> > for this :
> >
> > interface port-channel 1
> > ...
> >  service instance 1439 ethernet
> >   encapsulation dot1q 1439 second-dot1q 1-4094
> >   rewrite ingress tag pop 1
> >   bridge-domain 1439
> >  !
> >  service instance 1440 ethernet
> >   encapsulation dot1q 1440 second-dot1q 1-4094
> >   rewrite ingress tag pop 1
> >   bridge-domain 1439
> >  !
> >
> > Works fine, hosts on same C-VLAN on both sides of bridge-domain can ping.
> >
> > As I need my interconnection to be STP-transparent, I tried to add
> > "l2protocol forward stp" on these 2 EVCs.
> >
> > This resulted in side effects on my backbone, and I saw STP events on
> > the other side of my port-channel (n3k switch) :
> > 2020 Dec  8 06:32:37 N3K-eqx-pa3-1 %STP-2-BLOCK_PVID_LOCAL: Blocking
> > port-channel1 on MST0000. Inconsistent local vlan.
> >
> > Question : why is the port-channel affected by l2protocol forward on
> > an EVC ?
> >
> > I guess I'll have to remove the "second-dot1q 1-4094" to allow
> > untagged trafic on EVCs, and make L2CP work correctly.
> >
> > Is this the right way to do ?
> > Thanks for your help.
> > Regards,
> > Cédric
>
> Hi Cédric,
>
> STP frames aren't really supposed to be VLAN tagged so the STP frames
> won't match your encapsulation statements; "encapsulation dot1q 1439
> second-dot1q 1-4094" or "encapsulation dot1q 1440 second-dot1q 1-4094"
> unless you are VLAN tagging your STP frames.
>
> If you match untagged frames into the bridge domain that might work, but
> the error you have provided is on your Nexus device:
>
> > 2020 Dec  8 06:32:37 N3K-eqx-pa3-1 %STP-2-BLOCK_PVID_LOCAL: Blocking
> > port-channel1 on MST0000. Inconsistent local vlan.
>
> What does this mean; has the Nexus received no BPDUs so it's blocked the
> port, because it was expected BPDUs? Also it looks to me like your Nexus is
> running MSTP - where are the STP frames coming from on the
> ME3600 side, the ME3600 itself or another device? Are you mixing STP and
> MSTP, or is this because the Nexus only supports MSTP?
>
> My two pence is that you should try to re-design this solution. I don't
> know why you'd have STP frames being allowed through the port-channel, and
> S-VLANs 1439 and 1440 only, but then have other S-VLANs being bridged
> somewhere else. If everything that comes into the port-channel can go to
> the Nexus just relax the EVC encapsulations to capture everything. It
> sounds to me like the L2 topology is being split by this ME3600, so I'd
> definitely try and find another design instead.
>
> Cheers,
> James.
> _______________________________________________
> 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/
>