PPPoE plugin session-table (“pppoe fib”) entries never deleted

[pr0c4]

Hi folks,

I’m testing the PPPoE plugin and noticed that the PPPoE “FIB” (shown via show pppoe fib) appears to retain stale (client-mac, session-id) entries after disconnects. When clients reconnect and negotiate a new PPPoE Session-ID, new keys accumulate rather than reusing/removing the old ones. Over time this causes unbounded growth in the PPPoE session table, which is undesirable even if the underlying hash can expand on the heap.

Observed behavior

1. With an active session:

• vppctl show pppoe fib contains one entry for the client MAC + current PPPoE Session-ID with a valid session_index.
• vppctl show pppoe session shows Number of PPPoE sessions: 1.

2. After disconnect / session deletion:

• vppctl show pppoe session becomes empty.
• but vppctl show pppoe fib still contains the old entry, now with session_index = -1 (unused).

3. After reconnect (same client MAC) where the client gets a new PPPoE Session-ID:

• show pppoe fib now contains the old (mac, old-session-id) entry with session_index=-1 plus a new (mac, new-session-id) entry with a valid session_index.

So reconnects with changing session-ids produce growing numbers of stale keys.

Why this matters

• The PPPoE session-table is keyed by (client-mac, session-id). Many clients will reconnect over time with new session-ids, so stale keys can grow indefinitely.
• In this build, the underlying bihash is heap-backed and can allocate additional chunks as it grows, so it may not “fill at 8MB” and stop immediately. However:
  • memory use can grow without bound under churn,
  • lookup performance can degrade as buckets overflow (potentially leading to more linear-search buckets),
  • worst-case failure becomes heap exhaustion rather than a clean “table full” error.

Supporting evidence

• vppctl show bihash verbose shows:
  • pppoe session table exists as a bihash_8_8 heap-backed table and reports heap: N chunk(s) allocated
  • The table has a non-trivial baseline allocation even with few active elements, and will allocate additional chunks as needed.

Question
Is keeping (mac, session-id) keys around with session_index=-1 intentional (e.g. for learning/cache reasons), or should the PPPoE plugin delete/age out these keys on session teardown?

Potential improvements (if this is unintended)

- On session delete, remove the (client-mac, session-id) entry from the PPPoE session-table rather than leaving it with session_index=-1, OR
- add an aging/GC mechanism to purge entries with session_index=-1 after some time.

vppctl show version
vpp v25.06.0-30~vyos20251230173410.0635a9a90 built by root on vpp-bng at 2026-01-18T14:58:36