cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
349
Views
0
Helpful
10
Replies

Problem with lacp via attachment circuits

IBEngTeam
Level 1
Level 1

Hi all,

ASR 9K with the following configuration:

l2vpn
xconnect group lacp-p2p
p2p lacp-p2p-conf
interface TenGigE0/2/0/6.200
interface GigabitEthernet100/0/0/18
!

interface GigabitEthernet100/0/0/18.200
description switch1-g0/1
l2transport
!
interface TenGigE0/2/0/6.200 l2transport
description swtich2-port-10
encapsulation dot1q 200
rewrite ingress tag pop 1 symmetric
!

LACP packet are not passed between asr9k interfaces. Packets should come from GigabitEthernet100/0/0/18, switched to TenGigE0/2/0/6.200, and get tagged with dot1q 200. for all regular packets all works well - but lacp fails.

How can I solve this?

Thanks for all the help.

Adi.

 

1 Accepted Solution

Accepted Solutions

encapsulation dot1q 200, untag <<- try this way 

MHM

View solution in original post

10 Replies 10

M02@rt37
VIP
VIP

Hello @IBEngTeam 

The issue with LACP packets not being passed between the interfaces on your ASR9k likely arises because LACP packets are untagged Layer 2 control packets, and your configuration on `TenGigE0/2/0/6.200` with `rewrite ingress tag pop 1 symmetric` expects tagged traffic, which might cause the untagged LACP packets to be dropped or mishandled.

You need to ensure that untagged packets, such as LACP, can pass through the interface without being incorrectly tagged or dropped. This may involve allowing untagged traffic on the interfaces, adjusting the interface configurations to handle both tagged and untagged packets appropriately, or reconfiguring the bridge domain to allow for the proper forwarding of these control packets. If your setup requires VLAN tagging for data traffic, consider separating LACP traffic onto a different logical or physical interface that doesn't apply the same tagging rules, or ensure that the switch or router configuration allows untagged control packets like LACP to traverse without interference. Essentially, the configuration needs to account for the fact that while your data traffic may be VLAN-tagged, LACP packets will not be, and the network device must handle these packets correctly to maintain link aggregation functionality.

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

Hi, thanks for the fast reply.

Interface TenGigE0/2/0/6.200 is connected to an intermediate switch which is configured to perform qinq, so all packet coming into TenGigE0/2/0/6.200 are tagged with dot1q 200.

Interface GigabitEthernet100/0/0/18 is directly connected to the lacp switch, so interface is configured with l2transport.

I assume that there is some issue with tagging by asr9k, any advice?

Adi.

@IBEngTeam 

The issue you're experiencing with LACP packets not being passed correctly between `GigabitEthernet100/0/0/18` and `TenGigE0/2/0/6.200` on your ASR9K likely stems from the interaction between VLAN tagging and the handling of untagged LACP control packets. Since `TenGigE0/2/0/6.200` is connected to an intermediate switch performing QinQ, which tags all incoming packets with VLAN 200, and `GigabitEthernet100/0/0/18` is directly connected to an LACP switch, the ASR9K must ensure that untagged LACP packets received on `GigabitEthernet100/0/0/18` are appropriately tagged with VLAN 200 before being sent out on `TenGigE0/2/0/6.200`. The `rewrite ingress tag pop 1 symmetric` command on `TenGigE0/2/0/6.200` might be causing issues by expecting tagged traffic and not handling the untagged LACP packets properly, which could result in them being dropped or not forwarded correctly.

You should ensure that when LACP packets are forwarded from `GigabitEthernet100/0/0/18` to `TenGigE0/2/0/6.200`, they are correctly tagged with VLAN 200. You may need to adjust the bridge-domain or EVC configuration to map untagged packets on `GigabitEthernet100/0/0/18` to VLAN 200 and verify that the QinQ switch configuration is compatible with this setup.

Additionally, testing the configuration without the `rewrite ingress tag pop 1 symmetric` command might help determine if this is causing the interference with LACP traffic... 

 

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

The switch connected to GigabitEthernet100/0/0/18 is not configured for qinq, so double tagging is not expected, this is the config:
interface GigabitEthernet0/1
switchport trunk encapsulation dot1q
switchport mode trunk
load-interval 30
channel-group 1 mode active
!

So packets going to GigabitEthernet100/0/0/18 should not have tag 200, this is why we perform:

rewrite ingress tag pop 1 symmetric.

Switch connected to TenGigE0/2/0/6.200 is performing qinq and tag all traffic with double tag, outer tag being 200 - so we configured:

encapsulation dot1q 200.

Ant ideas?

@IBEngTeam 

You should ensure that LACP packets are tagged with VLAN 200 as they exit Te0/2/0/6.200, possibly by adjusting the tagging configuration or using a dedicated sub-interface or bridge-domain that handles this correctly.

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

Why end device send lacp (which is control packet of PO) ?

It seem that you connect PE to CE as single non PO

MHM

Hi, thanks for the reply.

The asr9k should only create a pseudowire between two switch's - they are configured for lacp and port channel.

Adi

friend are you sure client use PO with single link 
what I see is two single link local connect via EVPN 

MHM

hi,

please find attached topology.

sw1 and sw2 should establish lacp vi 1 switch that perform qinq and asr9k.

encapsulation dot1q 200, untag <<- try this way 

MHM