You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:~$
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: