Proxy ARP with MAC from evpn route even if there's no inet route

[Nischal Sheth]

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-gateway-address for their irb interface, they advertise the GW IP
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.

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/14446
Submitter: Manish Singh (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/14446
Committed: http://github.org/Juniper/contrail-controller/commit/40c8571b783cfe10d260607d0a91f11819f2b4d0
Submitter: Zuul
Branch: master

commit 40c8571b783cfe10d260607d0a91f11819f2b4d0
Author: Manish <email address hidden>
Date: Wed Jun 29 12:25:25 2016 +0530

Use Inet component from Evpn routes for IP mac binding.

Whenever EVPN route is received from CN, IP was not being used.
With the current changes IP will be installed with a new peer known as
inet_evpn_peer. This path will be lesser in priority w.r.t. local_vm path and
BGP peer received inet path. For nexthop and label this path will use
parent subnet rt. Nexthop and label and other path parameters will be same as of
subnet route. (Note: subnet route can be many and the best match will be
selected).
On subnet route going off it will fallback to next best available subnet and so
on. If nothing is available then its discard. Similar thing happens on addition
of better subnets.

Some more notes w.r.t. these changes:
- For IPAM gateway if EVPN route is received with MAC from remote peer,
stitching is done only on TSN and not on any other type of compute node.
This forces non TSN compute to do proxy always for gateway.
- If VN does not have layer3 forwarding enabled then stitching is done for
whatever is available. It breaks the above point as well.

Also from route_ksync.cc remove the check of ipam_subnet_route for marking arp
flags to flood. Now composite will always have proxy flags. Flood flag was
present to handle ECMP NH received for gateway route. Now when arp was issued
for baremetal behind gateway it will get flooded. With this fix all EVPN routes
from external router will be used to program IP and add mac stitching. So any
arp for baremetal will be resolved by vrouter itself using mac binding. There
will be no need to flood arp on ECMP NH received.

Closes-bug: 1491047

Conflicts:
src/vnsw/agent/oper/agent_path.cc
src/vnsw/agent/oper/inet_unicast_route.cc

Change-Id: I113e3c46d0e63441878a7e007dd5240bef7a339f