summaryrefslogtreecommitdiff
path: root/lib/pqueue.h
diff options
context:
space:
mode:
authorvivek <vivek@cumulusnetworks.com>2019-02-27 12:54:24 +0000
committervivek <vivek@cumulusnetworks.com>2019-02-27 12:54:24 +0000
commit2b83602b24a76dee76b96d63758d9e4455a9cc86 (patch)
tree75c2f135621b1d4d780602e1ca3110ca99ed3ecc /lib/pqueue.h
parente1e71450a046b9661d1e7e58d5e3c9f43fefa5ff (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