Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PortsOrch] portchannel: packets are still received when portchannel is oper_status down #3507

Open
baorliu opened this issue Feb 10, 2025 · 1 comment

Comments

@baorliu
Copy link
Contributor

baorliu commented Feb 10, 2025

In the case that portchannel operational status down caused by some of its members are down and min_link (other members are up), ingress packet can still be received. this cause a few other issues.
1, ingress arp packet cause neighbor and nexthop created, even the related interface (portchannel here) is operational down
2, other packets, e.g. bfd packets, cause packet be processed and waste CPU cycles.
The test result is based on 202405, but the behavior should be same for other branches.

sonic@sfd-t2-lc0:~$ show int po -d all | grep PortChannel01
   01  PortChannel01    LACP(A)(Up)  Ethernet-BP236(S) Ethernet-BP232(S)
cisco@sfd-t2-lc0:~$ date; sudo config interface -n asic0 shutdown Ethernet-BP232
Mon Feb 10 16:27:10 UTC 2025
sonic@sfd-t2-lc0:~$  grep GRESS /var/log/swss/sairedis.asic0.rec|tail
2025-02-10.16:27:11.647415|s|SAI_OBJECT_TYPE_LAG_MEMBER:oid:0x1b00000000082c|SAI_LAG_MEMBER_ATTR_EGRESS_DISABLE=true
2025-02-10.16:27:11.649230|s|SAI_OBJECT_TYPE_LAG_MEMBER:oid:0x1b00000000082c|SAI_LAG_MEMBER_ATTR_INGRESS_DISABLE=true
sonic@sfd-t2-lc0:~$ show int po -d all | grep PortChannel01
   01  PortChannel01    LACP(A)(Dw)  Ethernet-BP236(S) Ethernet-BP232(D)
sonic@sfd-t2-lc0:~$ sudo ip netns exec asic0 tcpdump --direction=in -i PortChannel01
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on PortChannel01, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C16:31:30.183061 IP6 2603:10e2:400:1::6 > ff02::1:ff00:8: ICMP6, neighbor solicitation, who has 2603:10e2:400:1::8, length 32
16:31:30.248761 IP6 2603:10e2:400:1::6 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2603:10e2:400:1::1, length 32
16:31:30.655178 IP6 2603:10e2:400:1::6 > ff02::1:ff00:4: ICMP6, neighbor solicitation, who has 2603:10e2:400:1::4, length 32
16:31:30.857476 ARP, Request who-has 20.0.1.8 tell 20.0.1.6, length 46
16:31:30.921974 ARP, Request who-has 20.0.1.1 tell 20.0.1.6, length 46
16:31:31.262070 IP6 2603:10e2:400:1::6 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2603:10e2:400:1::1, length 32
16:31:31.309529 ARP, Request who-has 20.0.1.4 tell 20.0.1.6, length 46
16:31:31.934592 ARP, Request who-has 20.0.1.1 tell 20.0.1.6, length 46
16:31:32.289683 IP6 2603:10e2:400:1::6 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2603:10e2:400:1::1, length 32
16:31:32.962121 ARP, Request who-has 20.0.1.1 tell 20.0.1.6, length 46
16:31:35.473975 ARP, Request who-has 20.0.1.1 tell 20.0.1.6, length 46
16:31:36.477785 ARP, Request who-has 20.0.1.1 tell 20.0.1.6, length 46
16:31:37.502428 ARP, Request who-has 20.0.1.1 tell 20.0.1.6, length 46

13 packets captured
13 packets received by filter
0 packets dropped by kernel
sonic@sfd-t2-lc0:~$ 
@baorliu
Copy link
Contributor Author

baorliu commented Feb 10, 2025

pull request #3508 for 202405 branch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant