diff options
| author | vivek <vivek@cumulusnetworks.com> | 2019-02-27 12:54:24 +0000 |
|---|---|---|
| committer | vivek <vivek@cumulusnetworks.com> | 2019-02-27 12:54:24 +0000 |
| commit | 2b83602b24a76dee76b96d63758d9e4455a9cc86 (patch) | |
| tree | 75c2f135621b1d4d780602e1ca3110ca99ed3ecc /lib/pqueue.h | |
| parent | e1e71450a046b9661d1e7e58d5e3c9f43fefa5ff (diff) | |
*: Explicitly mark nexthop of EVPN-sourced routes as onlink
In the case of EVPN symmetric routing, the tenant VRF is associated with
a VNI that is used for routing and commonly referred to as the L3 VNI or
VRF VNI. Corresponding to this VNI is a VLAN and its associated L3 (IP)
interface (SVI). Overlay next hops (i.e., next hops for routes in the
tenant VRF) are reachable over this interface. Howver, in the model that
is supported in the implementation and commonly deployed, there is no
explicit Overlay IP address associated with the next hop in the tenant
VRF; the underlay IP is used if (since) the forwarding plane requires
a next hop IP. Therefore, the next hop has to be explicit flagged as
onlink to cause any next hop reachability checks in the forwarding plane
to be skipped.
https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement
section 4.4 provides additional description of the above constructs.
Use existing mechanism to specify the nexthops as onlink when installing
these routes from bgpd to zebra and get rid of a special flag that was
introduced for EVPN-sourced routes. Also, use the onlink flag during next
hop validation in zebra and eliminate other special checks.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Diffstat (limited to 'lib/pqueue.h')
0 files changed, 0 insertions, 0 deletions
