Skip to content

Backup nexthop design

Jump to bottom
Mark Stapp edited this page Jul 9, 2020 · 5 revisions

Backup nexthops for FRR

The concept of backup paths is used in several domains: IP-FRR, TI-LFA, BGP PIC, MPLS-FRR, etc. A backup path operates differently from an ECMP (or UCMP) path, in that the backup path is not used until some change in the preferred or primary path activates it. The exact details of "triggers" and "activation" are likely to be OS- and/or dataplane-dependent. The goal of this initial work is to offer these features:

  1. IP routes and MPLS LSPs will support backup paths.

  2. a list of nexthops can have an associated list of backup nexthops. an individual nexthop can refer to one or more backup nexthops in that list. an LSP can have a list of backup NHLFEs, and a primary NHLFE can refer to one or moer backups in that list.

  3. the nexthop structs

    1. the existing nhg_hash_entry struct is extended to include a backup nexthop list.

    2. the existing nexthop struct is extended to include a small array of backup indexes into such a list

    3. the LSP struct is extended to include a backup NHLFE list

    4. an NHLFE has an embedded nexthop, and uses the nexthop struct's backup indexes

  4. daemons who send routes to zebra via zapi can include a list of backup nexthops, and can include optional backup indexes with each primary nexthop.

  5. zebra's internal processing of nexthops and the nhg_hash_entry struct are extended to support backups. zebra's hash-entry computation includes the backup information if it's present. backup nexthops are resolved and checked for viability (ACTIVE or "installable" status) just as primary nexthops are. backup nexthops are included in nexthop-tracking/reachability processing also.

  6. the zebra dataplane framework captures backup information if it's present, and makes that info available for installation if the actual forwarding plane supports backups.

    1. TODO: would the netlink users like to see some support for backups? currently, that's TBD. it might be possible to add second instance of the primary route, using an inferior metric value, and specifying the backup nexthops.

  7. the nexthop-group cli command is extended to support backup indexes for nexthops, and to support a reference to a backup group (by name).

  8. for testing, sharpd understands the nexthop-group changes, and can use them to exercise the zapi and zebra changes for routes and LSPs.

Clone this wiki locally