| 2015-09-01 16:28:27 |
Nischal Sheth |
bug |
|
|
added bug |
| 2015-09-01 16:28:44 |
Nischal Sheth |
nominated for series |
|
juniperopenstack/trunk |
|
| 2015-09-01 16:28:44 |
Nischal Sheth |
bug task added |
|
juniperopenstack/trunk |
|
| 2015-09-01 16:28:44 |
Nischal Sheth |
nominated for series |
|
juniperopenstack/r2.20 |
|
| 2015-09-01 16:28:44 |
Nischal Sheth |
bug task added |
|
juniperopenstack/r2.20 |
|
| 2015-09-01 16:28:52 |
Nischal Sheth |
juniperopenstack/r2.20: milestone |
|
r2.22 |
|
| 2015-09-01 16:29:00 |
Nischal Sheth |
juniperopenstack/r2.20: assignee |
|
Divakar Dharanalakota (ddivakar) |
|
| 2015-09-01 16:29:02 |
Nischal Sheth |
juniperopenstack/r2.20: importance |
Undecided |
Medium |
|
| 2015-09-01 16:32:13 |
Nischal Sheth |
description |
Agent programs a 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. The net result is that proxy ARP code in the
vRouter is effective only if the /32 route for the target IP is learnt via inet and evpn.
This results in 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. Once bug 1420513 is addressed is fixed, TOR agent will advertise BMS's IP and
MAC via evpn.
However the vRouter will be unable to perform proxy ARP for VM/BMS to BMS
ARP requests since there's no inet route for the BMS IP.
A possible fix would be to install a /32 route for IP address in evpn routes into the inet table.
Note that the agent may receive an ECMP nexthop for the GW IP in scenario 1.
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. |
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. Once bug 1420513 is addressed is fixed, TOR agent will advertise BMS's
IP and MAC via evpn. However vRouter will be unable 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. |
|
| 2015-09-01 16:33:57 |
Nischal Sheth |
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 |
|
| 2015-09-01 18:04:43 |
Nischal Sheth |
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-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. Once bug 1420513 is addressed is fixed, TOR agent will advertise BMS's
IP and MAC via evpn. However vRouter will be unable 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. |
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. |
|
| 2015-10-16 08:56:33 |
Manish Singh |
juniperopenstack/r2.20: assignee |
Divakar Dharanalakota (ddivakar) |
Manish Singh (manishs) |
|
| 2015-10-16 08:56:37 |
Manish Singh |
juniperopenstack/trunk: assignee |
Divakar Dharanalakota (ddivakar) |
Manish Singh (manishs) |
|
| 2015-11-05 07:00:50 |
Vinay Mahuli |
juniperopenstack/trunk: status |
New |
In Progress |
|
| 2015-11-25 13:52:37 |
Hari Prasad Killi |
juniperopenstack/r2.20: status |
New |
Won't Fix |
|
| 2016-03-21 17:23:28 |
Nischal Sheth |
bug task deleted |
juniperopenstack/r2.20 |
|
|
| 2016-03-21 17:23:32 |
Nischal Sheth |
juniperopenstack/trunk: milestone |
r3.0-fcs |
|
|
| 2016-04-25 05:51:19 |
Nischal Sheth |
juniperopenstack/trunk: importance |
Medium |
Wishlist |
|
| 2016-05-18 22:39:18 |
vivekananda shenoy |
tags |
vrouter |
blocker ves vrouter |
|
| 2016-05-24 15:23:08 |
vivekananda shenoy |
tags |
blocker ves vrouter |
ves vrouter |
|
| 2016-07-07 05:59:15 |
OpenContrail Admin |
juniperopenstack/trunk: status |
In Progress |
Fix Committed |
|
| 2016-07-07 05:59:16 |
OpenContrail Admin |
juniperopenstack/trunk: milestone |
|
r3.1.0.0-fcs |
|
