Bug ID 1601985: F5OS unable to transmit frames out to external interface, even though link is reported as UP

Last Modified: Jun 03, 2025

Affected Product(s):
F5OS F5OS, F5OS-A(all modules)

Known Affected Versions:
F5OS-A 1.8.0

Opened: Jun 27, 2024

Severity: 2-Critical

Symptoms

Intermittently, one of the external links on the appliance reports a link 'UP' status. However, the system will receive ingress frames on the interface, but no frames will egress the interface. - An F5OS packet capture will show frames being sent on that link, but they will not egress the interface. - If the port is a member of an LACP LAG, the LAG status will be reported as LACP_DOWN / OUT_SYNC, and lacpd may log messages similar to the following repeatedly: lacpd[13]: priority="Info" version=1.0 msgid=0x3401000000000088 msg="Mux_disable_colldist" port_state="Intf=5.0 partnerDefaulted:1 rxState:3 selected:0 txState:0 actorChurn:0 partnerChurn:1 muxState:0 periodicTxState:1 actorState:10000111 partnerState:01000111". - The interface 'out' counters will not increment. - The tmctl 'gbx_stat' counters will show incrementing egress packet counters ('egr_pkt_cnt'). - Platform.log may report the transmit direction for the interface MAC as being disabled, although this can occur even if the interface is working properly: fpgamgr[15]: priority="Info" version=1.0 msgid=0x309000000000016 msg="Configured Interface MAC." INTERFACE="10.0" Tx="Disabled" Rx="Enabled".

Impact

After a link comes up, the system is unable to transmit frames.

Conditions

-- r5000, r10000, or r12000-series appliance. -- The first time an interface links up after a system reboot.

Workaround

This issue is intermittent, and should not occur after rebooting the appliance. Use the following procedure if the rebooting does not resolve the issue. === Collecting data to determine which interface is in an unexpected state. On an r5000: for i in nw_{0..9}; do echo $i; docker exec system_fpga fpgatool -c "mac enable asw $i"; echo; done On an r10000 or r12000: for j in asw nso; do for i in nw_{0..9}; do echo $j $i; docker exec system_fpga fpgatool -c "mac enable $j $i"; echo; done; done For example: nw_7 target is up on 127.0.0.1:1060 TX Enable state: 0 ===> (!!!) RX Enable state: 1 === To map the output of one of those to a named interface, see `tmctl gbx_cfg` r5000: interface_name link chip -------------- -------------- ---- 1.0 f5sw_link_nw_0 asw 2.0 f5sw_link_nw_1 asw 3.0 f5sw_link_nw_2 asw 4.0 f5sw_link_nw_3 asw 5.0 f5sw_link_nw_4 asw 6.0 f5sw_link_nw_5 asw 7.0 f5sw_link_nw_6 asw 8.0 f5sw_link_nw_7 asw 9.0 f5sw_link_nw_8 asw 10.0 f5sw_link_nw_9 asw r10000/r12000: interface_name link chip -------------- -------------- ---- 1.0 f5sw_link_nw_0 nso 2.0 f5sw_link_nw_1 nso 3.0 f5sw_link_nw_2 nso 4.0 f5sw_link_nw_3 nso 5.0 f5sw_link_nw_4 nso 6.0 f5sw_link_nw_5 nso 7.0 f5sw_link_nw_6 nso 8.0 f5sw_link_nw_7 nso 9.0 f5sw_link_nw_8 nso 10.0 f5sw_link_nw_9 nso 11.0 f5sw_link_nw_0 asw 12.0 f5sw_link_nw_1 asw 13.0 f5sw_link_nw_2 asw 14.0 f5sw_link_nw_3 asw 15.0 f5sw_link_nw_4 asw 16.0 f5sw_link_nw_5 asw 17.0 f5sw_link_nw_6 asw 18.0 f5sw_link_nw_7 asw 19.0 f5sw_link_nw_8 asw 20.0 f5sw_link_nw_9 asw (Note that interfaces 1-10 are on *different chips* when comparing an r5000 and r10000/r12000.) === Run the following command to manually enable the affected interface docker exec system_fpga fpgatool -c "mac enable asw <INTFERACE> 1 1" For example, the following command will enable interface 8.0 on r5000 docker exec system_fpga fpgatool -c "mac enable asw nw_7 1 1" === Wait for 10 second and check the state again. docker exec system_fpga fpgatool -c "mac enable asw <INTERFACE>" === Assuming both RX and TX were enabled in the last step, check the LACP LAG status.

Fix Information

None

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips