Re: [c-nsp] ASR920 LACP and xconnect
We have seen that as well. We had that recently with a new international carrier. Turns out when they set up the circuit on their optical switching equipment (whether it be Ciena, ECI, Infinera, Cisco or whoever), there are some knobs that need to be adjusted to allow through all types of packets. After having our NOC staff eat 4 hours in the wee hours of the morning trying to debug why the LACP bundle would not come up, a simple change by the carrier the next day had the new circuits up in a matter of seconds. Regards, Hank Caveat: The views expressed above are solely my own and do not express the views or opinions of my employer ___ 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: [c-nsp] ASR920 LACP and xconnect
Hi, On Thu, Aug 20, 2020 at 06:12:29PM +, Eric Van Tol wrote: > 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. I've been there, and could not make it work (we tried with 2x 10G as well as 2x 1G). I have the feeling that it's eating the/some LACP packets. [..] > 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. There's an "encapsulation untagged" or something - it can be done :) I have not tried to find out whether it's officially supported or unsupported - ASR920 "what is supported and what not?" documentation is not exactly satisfactory. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ 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/
[c-nsp] ASR920 LACP and xconnect
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/
