Proxy ARP with MAC from evpn route even if there's no inet route
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Juniper Openstack | Status tracked in Trunk | |||||
Trunk |
Fix Committed
|
Wishlist
|
Manish Singh |
Bug Description
Agent programs stitched MAC for /32 IPv4 routes using the info received in
evpn routes. However, the /32 route itself is programmed into the vRouter
only if it's learnt in the inet table. Net result is that proxy ARP code
in vRouter is effective only if the /32 route for the target IP is learnt
via inet and evpn.
This causes unnecessary flooding of ARP requests in the following cases:
1. If one of more MXs are programmed with the subnet's GW address as the
virtual-
with a VRRP MAC using evpn, but they don't advertise the GW IP via l3vpn.
Hence the vRouter is unable to take advantage of the information in the
evpn route and respond with the stitched MAC.
2. After bug 1420513 is addressed, TOR agent will advertise BMS's IP and
MAC via evpn. However, vRouter will not be able to perform proxy ARP for
VM/BMS to BMS ARP requests since there's no inet route for the BMS IP.
A possible solution would be to install a /32 route for IP address in evpn
routes into the inet table.
Note that agent may receive an ECMP nexthop for the GW IP in case 1 above.
It should still be able to perform proxy ARP and respond with the stitched
MAC since only the nexthops (i.e. VTEP addresses) are different - there's only 1 MAC address for the GW IP.
description: | updated |
summary: |
- Send proxy ARP response with stitched MAC from EVPN even if there's no - L3VPN route + Proxy ARP with MAC from evpn route even if there's no inet route |
description: | updated |
no longer affects: | juniperopenstack/r2.20 |
tags: | added: blocker ves |
tags: | removed: blocker |
Review in progress for https:/ /review. opencontrail. org/14446
Submitter: Manish Singh (<email address hidden>)