Yes, you can use xconnect or bridge-domain (and then xconnect) under the dot1q evcs.
-- Tassos Eric Van Tol wrote on 21/8/20 19:29: > But is this in an EoMPLS xconnect? That is the issue - the entire circuit is > in an xconnect and the neighboring device needs to 'peer' with ours through > LACP. I, too, have no issues with plain LAG setups using LACP. > > -evt > > On 8/21/20, 12:21 PM, "cisco-nsp on behalf of Tassos Chatzithomaoglou" > <cisco-nsp-boun...@puck.nether.net on behalf of ach...@forthnet.gr> wrote: > > We haven't faced any issues with the following (ASR920 with 15.6(2)SP6): > > interface Port-channel1 > service instance 100 ethernet > encapsulation untagged > l2protocol peer cdp lacp udld > ! > service instance 501 ethernet > encapsulation dot1q x > ! > service instance 502 ethernet > encapsulation dot1q y > > -- > Tassos > > Eric Van Tol wrote on 20/8/20 21:12: > > Hi all, > > I’m trying to verify something here that is working, but also not > working. At some point, we built an LACP bundle to a customer device (2x1G > ports) and put it into an EoMPLS setup using xconnect to send it over to > another site where they have a 10G single circuit. While the LAG is ‘up’ and > passing traffic, the ports continuously get removed from the bundle and added > back in and there’s obviously a small amount of packet loss that occurs when > that happens. > > > > ‘l2protocol peer lacp’ is configured on the Po1 service-instance and > the behavior is the same whether that command is there or not. My inclination > is to say that this should not work at all, but given that the bundle was > operational and not flapping when someone turned it up, it was considered to > be working. > > > > To confuse matters even more, customer switch on the other side is > configured with native VLAN 2, but I’m not entirely sure that matters if the > overall config isn’t even supported. > > > > Hardware: ASR920-12CZ-A > > Version: 03.16.04.S > > > > Interface configs: > > > > interface GigabitEthernet0/0/0 > > mtu 1600 > > no ip address > > load-interval 30 > > negotiation auto > > channel-group 1 mode active > > ! > > > > interface GigabitEthernet0/0/1 > > mtu 1600 > > no ip address > > load-interval 30 > > negotiation auto > > channel-group 1 mode active > > ! > > interface Port-channel1 > > mtu 1600 > > no ip address > > load-interval 30 > > negotiation auto > > no keepalive > > service instance 1 ethernet > > encapsulation default > > l2protocol peer lacp > > xconnect x.x.x.x 1234 encapsulation mpls pw-class Raw-Mode-VC5 > > mtu 1600 > > ! > > > > If this is confirmed as unsupported, would I be correct in that we > would have to separate out the untagged native VLAN into its own, > non-xconnect EFP, so as to do proper ‘l2protocol peer’ configuration? My only > concern there is that the native VLAN needs to be transported along with all > other VLANs to the other end of the xconnect so I am not sure right now how > we do that, or if we even can. > > > > -evt > > _______________________________________________ > > 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/ > _______________________________________________ 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/
