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" <[email protected] on behalf of [email protected]> 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 [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
