Hi all, I'd like to contribute Seamless BFD (S-BFD) support to VPP, starting with the reflector. It is on Gerrit as a series of 5 changes:
https://gerrit.fd.io/r/c/vpp/+/47423 bfd: add S-BFD reflector configuration https://gerrit.fd.io/r/c/vpp/+/47424 udp: add S-BFD port 7784 to the UDP port lists https://gerrit.fd.io/r/c/vpp/+/47425 bfd: add S-BFD reflector datapath https://gerrit.fd.io/r/c/vpp/+/47426 bfd: reflect S-BFD requests sent over MPLS paths https://gerrit.fd.io/r/c/vpp/+/47427 bfd: document the S-BFD reflector Background S-BFD (RFC 7880, with the IPv4/IPv6/MPLS encapsulation in RFC 7881) drops the classic BFD handshake: an initiator sends to a provisioned discriminator and a stateless reflector answers. It is mostly used to check SR-MPLS / SR-TE paths. An earlier attempt (Change-Id Ibbeb9328129ac094457ed051f4a9c71cbb094d2a, 2017) did not progress, and this design follows Klement's review of it: - no global mode: S-BFD is configured per reflector discriminator - classic BFD on UDP 3784/4784 is untouched; the reflector has its own nodes on UDP 7784 - CLI and API are part of the existing BFD ones: "bfd udp sbfd reflector add|mod|del", "show bfd sbfd-reflectors", and bfd_udp_sbfd_reflector_add_del/_mod/_dump (marked in_progress) - tests extend test/bfd.py and test/test_bfd.py, including classic BFD and S-BFD running side by side What the reflector does - Answers requests for a configured discriminator as in RFC 7880 section 7.2 and RFC 7881 section 6: state Up (or AdminDown with Diag 7), discriminators swapped, Detect Mult and Desired Min TX copied, Poll answered with Final, TTL/hop limit 255, routed back in the receiving interface's table. - IPv4 and IPv6, single-hop and multihop, any worker thread. - Requests sent over MPLS paths (RFC 7881 section 5.1, to 127/8 or ::ffff:127.0.0.0/104), arriving as plain IP after PHP, with an Explicit NULL label, or on a local label. While at least one discriminator is configured, 127.0.0.0/8 and ::ffff:127.0.0.0/104 are added to the default tables under a new FIB source, with a small DPO that passes UDP/7784 to ip4-local/ip6-local and drops everything else. The reply comes from a per-discriminator src-address, or else from an address of the receiving interface. - Drops what the RFCs say to drop (authentication, Demand bit clear, source port 7784, martian addresses, TTL/hop limit 0, ...), with a counter per reason. One behaviour change worth your review: while a reflector exists, non-S-BFD traffic to 127/8 and ::ffff:127.0.0.0/104 in the default tables is dropped, even if a covering route would have forwarded it. These ranges are not forwardable (RFC 1122, RFC 6890). An operator route to exactly 127/8 is overridden until the last discriminator is deleted. Not in this series (listed as limitations in the docs): authentication, tables other than the default for the MPLS-path entries, the RFC 7881 section 5.1.1 TTL-expiry path, IPv4 Router Alert, and a Poll sequence started by the reflector. The initiator would follow as a separate series. Testing - make test TEST=bfd,udp passes; existing classic BFD tests are unchanged. 186 S-BFD test runs (IPv4/IPv6, single-hop/multihop, API, CLI, coexistence), also with 2 worker threads. - About 98% line coverage of the new code; hand-written mutation testing (about 160 mutants) was used to find and close test gaps. - An ASan/UBSan build, and about 160,000 fuzzed requests across all three arrival paths, with no reports in the new code. - Interop with a hardware router's S-BFD initiator over an SR-MPLS policy (IPv4): session up, AdminDown, wrong discriminator, VPP restart, and a 24-hour run (on an earlier revision) with no session failures. Questions 1. Neale: is a special-DPO entry under a new FIB source the right way for the reflector to receive 127/8 and ::ffff:127.0.0.0/104, or would you prefer another mechanism? 2. Should the MPLS-path entries cover all IP tables? The first cut keeps them to the default tables. 3. Is a source allowlist or rate limit wanted inside the reflector, or is pointing to the ACL plugin and the policer (as the docs do) enough? 4. For the initiator I plan to add S-BFD as a session type inside the existing BFD session model. Does that sound right? Thank you, Idris Jafarov DriveNets Idris Jafarov Delivery Team Leader +13025595952 [email protected] follow us on Linkedin www.drivenets.com
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#27325): https://lists.fd.io/g/vpp-dev/message/27325 Mute This Topic: https://lists.fd.io/mt/122079714/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
