bgpd: modify route install/withdraw logic for evpn type-5 routes in vrf

We install type-5 routes as ipv4/ipv6 unicast routes in the vrf table.
along with these routes, we also install the RMAC
and the nexthop Neigh entries.
There might be scenarios were the bestpath has changed and
we are now pointing to a new nexthop with a different RMAC.
As per BGP logic, we just send an update for the route and the nexthop
is replaced. However, this causes problem because the RMAC and neigh entry
corresponding to the previous nexthop are still lingering in the system.
We need to clear those entries for proper functoning.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
This commit is contained in:
Mitesh Kanjariya 2018-04-11 02:29:46 -07:00 committed by Donald Sharp
parent 7e4ed18ef5
commit 2b659f3329

View File

@ -2336,10 +2336,18 @@ static void bgp_process_main_one(struct bgp *bgp, struct bgp_node *rn,
if (new_select && new_select->type == ZEBRA_ROUTE_BGP
&& (new_select->sub_type == BGP_ROUTE_NORMAL
|| new_select->sub_type == BGP_ROUTE_AGGREGATE
|| new_select->sub_type == BGP_ROUTE_IMPORTED))
|| new_select->sub_type == BGP_ROUTE_IMPORTED)) {
/* if this is an evpn imported type-5 prefix,
* we need to withdraw the route first to clear
* the nh neigh and the RMAC entry.
*/
if (old_select &&
is_route_parent_evpn(old_select))
bgp_zebra_withdraw(p, old_select, bgp, safi);
bgp_zebra_announce(rn, p, new_select, bgp, afi, safi);
else {
} else {
/* Withdraw the route from the kernel. */
if (old_select && old_select->type == ZEBRA_ROUTE_BGP
&& (old_select->sub_type == BGP_ROUTE_NORMAL