linux-cp: T9243: VPP VLAN interface keeps A/D when it's not disabled

[canoziia]

Change Summary

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Code style update (formatting, renaming)
• Refactoring (no functional changes)
• Other (please describe):

Related Task(s)

https://vyos.dev/T9243

Related PR(s)

Proposed changes

This change fixes Linux-originated VLAN synchronization in VPP linux-cp.

It prevents the reverse auto-subinterface callback from running while Linux netlink messages are being processed, avoiding duplicate LCP pair creation.

It also uses the triggering RTM_NEWLINK timestamp as the pair creation boundary, ensuring queued MTU and administrative-state updates are not incorrectly discarded as early messages. This prevents enabled VLAN interfaces from remaining admin-down or retaining MTU 0 after boot.

How to test

set vlan on vpp interface and observe vif states.

vyos@vyos# show interfaces ethernet eth103
 mtu 9216
 offload {
     gro
     gso
     sg
     tso
 }
 vif 1021 {
     address x.x.x.x/xx
     mtu 1500
 }
 vif 1051 {
     address x.x.x.x/xx
     mtu 9000
 }
 vif 1052 {
     address x.x.x.x/xx
     mtu 9000
 }

Checklist:

• I have read the CONTRIBUTING document
• I have linked this PR to one or more Phabricator Task(s)
• My commit headlines contain a valid Task id
• My change requires a change to the documentation
• I have updated the documentation accordingly

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited), Organization UI (inherited)

Review profile: CHILL

Plan: Pro Plus

Run ID: bf5a9bc8-c37a-4a5b-a0cd-6f100fef0cc2

Warning

Your free Security trial is over. An organization admin can activate Security or dismiss this notice.

---

_{Comment @coderabbitai help to get the list of available commands.}

[sever-sever]

@ritika0313 could you take a look?

[ritika0313]

@ritika0313 could you take a look?

yes, i am on it.

[ritika0313]

Hi @canoziia, I tried several times but the interface A/D problem did not reproduce on my setup as it is a timing dependent issue. But here is my analysis:

I see 2 fixes in the PR -
The first fix seems to be based on incorrect interpretation. On my setup, no duplicate LCP pair gets created by the callback path. The already created parent LCP pair is fetched from the sub-interface to create the Linux TAP sub-interface.
Do you have any logs/outputs confirming that duplicate LCP pair got created?

Suppressing the execution of the VNET_SW_INTERFACE_ADD_DEL_FUNCTION callback is incorrect as it will prevent the creation of Linux tap interface which is done via lcp_netlink_add_link_vlan().

Moreover, the "failed create vlan" log is not a failure of the intended flow — it is the expected outcome after VNET_SW_INTERFACE_ADD_DEL_FUNCTION callback finishes its work. The failure log is an info log and is observed because there is nothing left to do on the host side (because its already taken care of in the callback flow).

The second fix for backdating the timestamp is based on the correct root cause of the problem where queued UP event has a timestamp earlier than the LIP (Linux Interface Pair) creation timestamp, which will lead to discarding of the message. Ultimately the interface will stay in the down state as the message could not be processed.
On my setup, UP event ts > LIP creation ts, hence the dequeued UP event message got processed successfully to bring the interface to state u/u.

Another possible cause of the problem can be - the main execution flow returns early due to “failed vlan create” i.e. ‘Tap sub-interface already exists’ case and IFFF_UP is set in create RTM_NEWLINK itself instead of a separate UP event.
In this scenario of early return, the interface is not being brought up explicitly nor there is any UP event message to be dequeued.

So in early return case:

1. We need to adjust the LIP creation timestamp as the second fix is not reachable in this case and
2. Need to bring the interface admin up.

Along with the second fix, I propose the below fix instead of adding a guard to suppress the add-del callback code execution flow. Can you please test it on your setup to confirm if the issue gets resolved?

src/plugins/linux-cp/lcp_router.c: lcp_router_link_add()

if (vnet_create_sub_interface (lip->lip_host_sw_if_index, vlan, ...))
  {
    lcp_itf_pair_t *sub_lip =
      lcp_itf_pair_get (lcp_itf_pair_find_by_phy (sub_phy_sw_if_index));
    if (sub_lip)
      {
        sub_lip->lip_create_ts = ((nl_msg_info_t *) ctx)->ts;
        /* Needed if IFF_UP was set in the create RTM_NEWLINK itself instead of
            a separate UP event */
        if (up)   
          vnet_sw_interface_admin_up (vnet_get_main (), sub_phy_sw_if_index);
        vnet_sw_interface_admin_up (vnet_get_main (),
                                    sub_lip->lip_host_sw_if_index);
      }
    else
      LCP_ROUTER_INFO ("failed create vlan: %s on %U", ...);
    return;
  }

In case your observation is different from mine, please share the output of below commands with and without fix:

show interfaces
sudo vppctl show lcp
sudo vppctl show interface
sudo vppctl "show logging" | grep -i "lcp\|linux\|nl\|router"

[ritika0313]

@canoziia :
Patch file to test the combined changes (suggested + timestamp related Fix # 2)
T9243-vpp-int-dn.patch

CLI to enable VPP debug logging before capturing logs:
set vpp settings logging default-level 'debug'

Scenario to be verified on the setup where the issue gets manifested:
Upon receiving an UP event before the LIP creation, "Early message received" logs are not observed for the interface up event messages and the interface state is appropriately set as enabled (u/u)
Also, the misleading log "linux-cp/router: failed create vlan: " should not appear now.

[canoziia]

@canoziia : Patch file to test the combined changes (suggested + timestamp related Fix # 2) T9243-vpp-int-dn.patch

CLI to enable VPP debug logging before capturing logs: set vpp settings logging default-level 'debug'

Scenario to be verified on the setup where the issue gets manifested: Upon receiving an UP event before the LIP creation, "Early message received" logs are not observed for the interface up event messages and the interface state is appropriately set as enabled (u/u) Also, the misleading log "linux-cp/router: failed create vlan: " should not appear now.

Hello, becasuse the router is working in production now, I couldn't test new changes the other day. I'll have a new machine of the exact same model, so I'll run the tests on that these days.