Mailing List Archive: ASR920 LACP and xconnect

ASR920 LACP and xconnect

Aug 20, 2020, 11:12 AM

Post #1 of 12 (2318 views)

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/

Re: ASR920 LACP and xconnect [ In reply to ]

gert at greenie

Aug 20, 2020, 12:07 PM

Post #2 of 12 (2318 views)

Permalink

Hi,

On Thu, Aug 20, 2020 at 06:12:29PM +0000, 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 gert@greenie.muc.de

Re: ASR920 LACP and xconnect [ In reply to ]

hank at interall

Aug 20, 2020, 10:34 PM

Post #3 of 12 (2313 views)

Permalink

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: ASR920 LACP and xconnect [ In reply to ]

jwbensley+cisco-nsp at gmail

Aug 21, 2020, 7:37 AM

Post #4 of 12 (2311 views)

Permalink

On Thu, 20 Aug 2020 at 19:16, Eric Van Tol <eric@atlantech.net> wrote:
> 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

What happens if you change each interface to be "channel-group 1 mode
on" and remove "l2protocol peer lacp" to disable LACP and remove it
from the equation?

Cheers,
James.
_______________________________________________
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: ASR920 LACP and xconnect [ In reply to ]

eric at atlantech

Aug 21, 2020, 8:05 AM

Post #5 of 12 (2311 views)

Permalink

James,
The same behavior, but there is no 'on' option for the ASR (in this XE version, anyway). Only options are 'active' and 'passive'. I think 'channel-group 1<enter>' is a valid config, but I have not tried it. Given some of the responses I've received already, I'm going to assume this is just not officially supported.

-evt

?On 8/21/20, 10:38 AM, "James Bensley" <jwbensley+cisco-nsp@gmail.com> wrote:

What happens if you change each interface to be "channel-group 1 mode
on" and remove "l2protocol peer lacp" to disable LACP and remove it
from the equation?

Cheers,
James.

_______________________________________________
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: ASR920 LACP and xconnect [ In reply to ]

achatz at forthnet

Aug 21, 2020, 9:18 AM

Post #6 of 12 (2311 views)

Permalink

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/

Re: ASR920 LACP and xconnect [ In reply to ]

eric at atlantech

Aug 21, 2020, 9:29 AM

Post #7 of 12 (2311 views)

Permalink

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-bounces@puck.nether.net on behalf of achatz@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/

ASR920 LACP and xconnect [ In reply to ]

cnsp at marenda

Aug 21, 2020, 10:49 AM

Post #8 of 12 (2311 views)

Permalink

Sorry, i think the behaviour is explainable.
You have (I think, on both sides equivalent config)
Two Gig Ports bundled with LACP to that prot-channel.
For that, the switch speak link-local pakets to the neighbor device.
Now , yo build that xconnect and ask to forward link-local pakets to the
remote.
OK, device does this.
Recieving device does some fancy load blancing an therfor, LACP starts to
fail since .
Either let the local switch handle the LACP Bundle and do not forward the
LACP packets
Thru that xconnect,
or build _two_ transparent xconnects/Eline/Epipe servicesso A-1 sees B-Side
1 and A-2 sees B-2
and the LACP Pakets from A1 and A2 do not go all to B1 or mixed/loadbalaced
to B1 and B2 (end vice-versa).
and _do_not_ bundle locally.
Just my 0.01 $
Mit freundlichen Gr??en
Kind regards
Veuillez agr?er mes salutations distingu?es
Met vriendelijke groet
J?rgen Marenda.
> -----Urspr?ngliche Nachricht-----
> Von: cisco-nsp <cisco-nsp-bounces@puck.nether.net
<mailto:cisco-nsp-bounces@puck.nether.net> > Im Auftrag von James
> Bensley
> Gesendet: Freitag, 21. August 2020 16:38
> An: Eric Van Tol <eric@atlantech.net <mailto:eric@atlantech.net> >;
cisco-nsp@puck.nether.net <mailto:cisco-nsp@puck.nether.net>
> Betreff: Re: [c-nsp] ASR920 LACP and xconnect
>
> On Thu, 20 Aug 2020 at 19:16, Eric Van Tol <eric@atlantech.net
<mailto:eric@atlantech.net> > wrote:
> > 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
>
> What happens if you change each interface to be "channel-group 1 mode on"
> and remove "l2protocol peer lacp" to disable LACP and remove it from the
> equation?
>
> Cheers,
> James.
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
<mailto: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/

Re: ASR920 LACP and xconnect [ In reply to ]

gert at greenie

Aug 21, 2020, 10:53 AM

Post #9 of 12 (2311 views)

Permalink

Hi,

On Fri, Aug 21, 2020 at 08:34:14AM +0300, hank@interall.co.il wrote:
> 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.

LACP bundles *through* two ASR920s actually work nicely.

Just LACP *to* an ASR920, and then forwarding said bundle via EoMPLS
(not individual VLANs, but "all of the poX interface") fails.

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 gert@greenie.muc.de

Re: ASR920 LACP and xconnect [ In reply to ]

eric at atlantech

Aug 21, 2020, 11:30 AM

Post #10 of 12 (2311 views)

Permalink

Problem is essentially resolved. I got one direct response telling me to try configuring a pseudowire interface and using l2vpn context, then add the Po1 and PW interfaces as members. While I believe that would have worked, I discovered the customer wasn't even using their untagged VLAN2 for anything, so I pulled that VLAN out of the EFP and rebuilt it:

interface Port-channel1
mtu 1600
no ip address
load-interval 30
negotiation auto
no keepalive
service instance 1 ethernet
encapsulation dot1q 1,3-4094
xconnect x.x.x.x 1234 encapsulation mpls pw-class Raw-Mode-VC5
mtu 1600
!
service instance 2 ethernet
encapsulation untagged
l2protocol peer lacp
!
end

This seems to have stopped the removal and re-insertion of the member ports from/into the LAG. I had assumed the customer was using this untagged VLAN, as it was specifically configured on their trunk port as one of two allowed VLANs. Thanks to all.

-evt

?On 8/21/20, 1:55 PM, "cisco-nsp on behalf of Gert Doering" <cisco-nsp-bounces@puck.nether.net on behalf of gert@greenie.muc.de> wrote:

Hi,

On Fri, Aug 21, 2020 at 08:34:14AM +0300, hank@interall.co.il wrote:
> 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.

LACP bundles *through* two ASR920s actually work nicely.

Just LACP *to* an ASR920, and then forwarding said bundle via EoMPLS
(not individual VLANs, but "all of the poX interface") fails.

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 gert@greenie.muc.de

_______________________________________________
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: ASR920 LACP and xconnect [ In reply to ]

achatz at forthnet

Aug 21, 2020, 12:04 PM

Post #11 of 12 (2311 views)

Permalink

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-bounces@puck.nether.net on behalf of achatz@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/

Re: ASR920 LACP and xconnect [ In reply to ]

tim.wall07 at gmail

Aug 24, 2020, 4:19 AM

Post #12 of 12 (2274 views)

Permalink

please remove me from this mailing list.

On 21/08/2020 18:49, cnsp@marenda.net wrote:
> Sorry, i think the behaviour is explainable.
> You have (I think, on both sides equivalent config)
> Two Gig Ports bundled with LACP to that prot-channel.
> For that, the switch speak link-local pakets to the neighbor device.
> Now , yo build that xconnect and ask to forward link-local pakets to the
> remote.
> OK, device does this.
> Recieving device does some fancy load blancing an therfor, LACP starts to
> fail since .
> Either let the local switch handle the LACP Bundle and do not forward the
> LACP packets
> Thru that xconnect,
> or build _two_ transparent xconnects/Eline/Epipe servicesso A-1 sees B-Side
> 1 and A-2 sees B-2
> and the LACP Pakets from A1 and A2 do not go all to B1 or mixed/loadbalaced
> to B1 and B2 (end vice-versa).
> and _do_not_ bundle locally.
> Just my 0.01 $
> Mit freundlichen Grüßen
> Kind regards
> Veuillez agréer mes salutations distinguées
> Met vriendelijke groet
> Jürgen Marenda.
>> -----Ursprüngliche Nachricht-----
>> Von: cisco-nsp <cisco-nsp-bounces@puck.nether.net
> <mailto:cisco-nsp-bounces@puck.nether.net> > Im Auftrag von James
>> Bensley
>> Gesendet: Freitag, 21. August 2020 16:38
>> An: Eric Van Tol <eric@atlantech.net <mailto:eric@atlantech.net> >;
> cisco-nsp@puck.nether.net <mailto:cisco-nsp@puck.nether.net>
>> Betreff: Re: [c-nsp] ASR920 LACP and xconnect
>>
>> On Thu, 20 Aug 2020 at 19:16, Eric Van Tol <eric@atlantech.net
> <mailto:eric@atlantech.net> > wrote:
>>> 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
>> What happens if you change each interface to be "channel-group 1 mode on"
>> and remove "l2protocol peer lacp" to disable LACP and remove it from the
>> equation?
>>
>> Cheers,
>> James.
>> _______________________________________________
>> cisco-nsp mailing list cisco-nsp@puck.nether.net
> <mailto: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/

Mailing List Archive

Attached Files:

Attached Files: