Add sonic_fib_init plugin

[lolyu]

sonic_fib_init: new VPP plugin to strip built-in 240.0.0.0/4 SPECIAL drop

VPP installs a FIB_SOURCE_SPECIAL drop entry for 240.0.0.0/4 (class E
reserved) into every IPv4 FIB at table creation time (see
ip4_fib_hash_load_specials). FIB_SOURCE_SPECIAL is the highest-priority
source in the FIB, so any route SONiC programs that covers this range
(e.g. an IP-in-IP decap tunnel destination, or a default route) is
silently pre-empted by the drop and the traffic is black-holed. This
breaks decap test cases that target 240.0.0.0/4.

fib_table_entry_special_remove() is the supported way to remove the
entry, but it is a C-only API with no .api binding, so it cannot be
invoked from the SAI shim directly.

This plugin bridges that gap:

• VLIB_MAIN_LOOP_ENTER_FUNCTION strips 240/4 from fib 0 (the default
  VRF, created during VPP startup) exactly once, after all
  VLIB_INIT_FUNCTIONs have run and before the main packet poll loop
  begins.

• sonic_fib_strip_specials { vrf_id } binary API lets the SAI shim
  request the same cleanup for VRFs created at runtime
  (SAI virtual_router create -> ip_table_add_del). The handler
  resolves vrf_id -> fib_index via fib_table_find() and applies the
  strip; missing tables are reported via the autoreply status.

Plugin layout:
vppbld/plugins/sonic_fib_init/
sonic_fib_init.c - init + main-loop-enter hooks, API handler
sonic_fib_init.h - sonic_fib_init_main_t (msg_id_base)
sonic_fib_init.api - sonic_fib_strip_specials autoreply
CMakeLists.txt - add_vpp_plugin(sonic_fib_init ...)
FEATURE.yaml - feature documentation

Both startup.conf templates (docker-sonic-vpp, docker-syncd-vpp) are
updated to load sonic_fib_init_plugin.so.

Verification:

vpp# show ip fib 240.0.0.0
ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] epoch:0 flags:none locks:[adjacency:1, recursive-resolution:8, default-route:1, ]
0.0.0.0/0 fib:0 index:0 locks:3
  API refs:1 src-flags:added,contributing,active,
    path-list:[242] locks:12798 flags:shared,popular, uPRF-list:168 len:4 itfs:[65, 66, 67, 68, ]
      path:[406] pl-index:242 ip4 weight=1 pref=0 recursive:  oper-flags:resolved,
        via 10.0.0.57 in fib:0 via-fib:111 via-dpo:[dpo-load-balance:112]
      path:[407] pl-index:242 ip4 weight=1 pref=0 recursive:  oper-flags:resolved,
        via 10.0.0.59 in fib:0 via-fib:120 via-dpo:[dpo-load-balance:121]
      path:[408] pl-index:242 ip4 weight=1 pref=0 recursive:  oper-flags:resolved,
        via 10.0.0.61 in fib:0 via-fib:128 via-dpo:[dpo-load-balance:129]
      path:[409] pl-index:242 ip4 weight=1 pref=0 recursive:  oper-flags:resolved,
        via 10.0.0.63 in fib:0 via-fib:137 via-dpo:[dpo-load-balance:138]

  default-route refs:1 entry-flags:drop, src-flags:added,
    path-list:[0] locks:1 flags:drop, uPRF-list:0 len:0 itfs:[]
      path:[0] pl-index:0 ip4 weight=1 pref=0 special:  cfg-flags:drop,
        [@0]: dpo-drop ip4

 forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:1 buckets:4 uRPF:168 to:[0:0]]
    [0] [@13]: dpo-load-balance: [proto:ip4 index:112 buckets:1 uRPF:116 to:[0:0]]
          [0] [@5]: ipv4 via 10.0.0.57 BondEthernet101: mtu:9100 next:38 flags:[] 3e9050e769a12259d0d519a90800
    [1] [@13]: dpo-load-balance: [proto:ip4 index:121 buckets:1 uRPF:125 to:[0:0]]
          [0] [@5]: ipv4 via 10.0.0.59 BondEthernet102: mtu:9100 next:39 flags:[] 06b48ba124242259d0d519a90800
    [2] [@13]: dpo-load-balance: [proto:ip4 index:129 buckets:1 uRPF:133 to:[0:0]]
          [0] [@5]: ipv4 via 10.0.0.61 BondEthernet103: mtu:9100 next:40 flags:[] 12390ac1a90c2259d0d519a90800
    [3] [@13]: dpo-load-balance: [proto:ip4 index:138 buckets:1 uRPF:142 to:[0:0]]
          [0] [@5]: ipv4 via 10.0.0.63 BondEthernet104: mtu:9100 next:41 flags:[] 663457500c622259d0d519a90800

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[yue-fred-gao]

hi @lolyu , is it too much to use a plugin to remove a route? is there a light weight option? For example, can we remove the route from vpp sai? Or can we add binary AP for fib_table_entry_special_remove?

[lolyu]

hi @lolyu , is it too much to use a plugin to remove a route? is there a light weight option? For example, can we remove the route from vpp sai? Or can we add binary AP for fib_table_entry_special_remove?

Hi @yue-fred-gao, fib_table_entry_special_remove is a internal VPP function, this plugin is to:

1. expose this internal function and allow our sairedis to call when creating new vrfs. (this will be another sairedis PR covering this)
2. remove the vrf 0 special route when vpp main loop starts.

Actually there are three options in my mind:

1. add a plugin to expose fib_table_entry_special_remove
2. add a binary API for fib_table_entry_special_remove
3. patch ip4_fib.c directly to remove those extra routes.

The main reason to choose option 1 is 2 and 3 requires touching the upstream vpp codes, this is a specific sonic domain requirement to clean up the fib.

[yue-fred-gao]

I think we should take an approach that is generic and can be upstreamed to fdio. I know there are extra steps but in the long run it is worth it with lower maintenance cost and can benefit the community.
For the 3 options, I would say 2 is better. It is backward compatible. The other option is adding a config (startup or one to be set via api) to skip the installation of special route.