Skip to content

Spike 3.11 — Veth-elimination (SO_PRIORITY / ingress-controller) to de-risk netkit #783

Description

@brunodam

Epic: #736 — BN traffic-shaper monitor

Design: v4 design §6.5, §10 headline risk H1 / risk 17.

Spike (planning note 7). The entire ingress mechanism attaches HTB to the host-side veth (lxc...). Cilium is migrating veth → netkit; when that lands, the veth attach point and the hostLegacyRouting flip both become invalid simultaneously (headline risk H1). The veth lifecycle also forces a per-pod-restart unprioritised-ingress window (risk 3) and the stale-qdisc problem (#749). Investigate alternatives that remove the veth dependency.

Goal: assess feasibility and produce a recommendation; no production code.

Investigate:

  • SO_PRIORITY-from-BN (§6.5): the BN process calls setsockopt(SO_PRIORITY) per connection (it already knows each connection's category). HTB classifies natively on priority, so the existing hierarchy is reused; the entire nft classification ruleset collapses to one socket option. Requires BN-team buy-in — frame the ask.
  • An ingress-controller container running alongside the BN pod (can it own ingress shaping without depending on the host-side veth, and without interfering with the BN Helm chart?).
  • IFB-on-NIC-ingress viability under Cilium tcx (§10 risk 17 notes it is invisible to classic tc filters on 1.16+).

Output: a written feasibility + recommendation comment, and any follow-up stories it warrants.

Fast-follow (de-risking; not MVP).

Metadata

Metadata

Assignees

No one assigned

    Labels

    BNBlock Node relatedStoryorder: polishPhase 2 work; no hard upstream dependencies

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions