DM: Enable restricted proxy-arp for external VNs
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Juniper Openstack | Status tracked in Trunk | |||||
R2.20 |
Won't Fix
|
Medium
|
Suresh Balineni | |||
R3.0 |
Won't Fix
|
Medium
|
Suresh Balineni | |||
R3.1 |
Won't Fix
|
Medium
|
Suresh Balineni | |||
Trunk |
Fix Committed
|
Medium
|
Suresh Balineni |
Bug Description
In order to support the use-cases detailed below, proxy-arp (restricted) should be enabled on the IRB interface for external VNs. With the restricted keyword in place, MX will proxy-arp for local destinations only if it owns the IP via a NAT-pool configuration. So, intra-VN BMS to BMS traffic will not go via MX.
The command is:
[edit groups __contrail__]
root@cmbu-tasman# set interfaces irb unit 31 proxy-arp restricted
Use-cases:
1. VM/BMS behind SNAT wants to reach BMS FIP, when the FIP has been
assigned from the SNAT GW VN.
The flow details are explained with an example below:
BMS1 behind SNAT has IP 1.1.1.3. SNAT public GW subnet is 7.1.1.0/24.
netns GW IP is 7.1.1.5. BMS2 IP is 1.1.2.3 and FIP is 7.1.1.10.
When BMS1 pings BMS2 FIP, the following happens:
- BMS1 resolves its default g/w and sends the ICMP request to the
MX.
- MX has a default route in this VRF pointing to SNAT instance
(contrail netns) and so fwds the packet to the right compute.
- Seeing that the destination is on the same subnet as the GW
interface, netns will flood an ARP request for 7.1.1.10 (to
- If proxy-arp is not configured, no arp response comes back and so
traffic is dropped. If proxy-arp is configured on the MX, MX
responds with its own MAC address and gets the ICMP echo request.
MX then knows how to translate the FIP to BMS private IP
and forwards the packet to BMS2.
- Response from BMS2 goes to netns and from there to MX and then to
BMS1.
2. BMS with FIP from an external VN, VN1, wants to reach BMS that has been
directly assigned an IP from VN1 (same external VN as FIP).
External VN subnet is 7.1.1.0/24. BMS1 private IP 1.1.2.8 and FIP is
7.1.1.5. BMS2 IP 7.1.1.20.
When BMS1 pings BMS2:
- BMS1 resolves its default g/w and sends the ICMP request to the
MX.
- MX does source NAT on the packet and changes the source IP to
7.1.1.5 (FIP for BMS1) and forwards the packet to inet.0.
- inet.0 has a policy to handle destination subnet 7.1.1.0/24 which
re-directs traffic to the external VN VRF.
- MX resolves the ARP and sends the packet to BMS2.
- BMS2, sees the packet coming from 7.1.1.5, and sends out an ARP
request which hits the TSN. TSN inturn floods to evpn/MX,
other TORs and fabric node.
- if proxy-arp is not configured, no arp response comes back and so
traffic is dropped. If proxy-arp is configured on the MX, MX
responds with its own MAC address and gets the ICMP echo
response. MX then knows how to translate the FIP to BMS private IP
and forwards the packet to BMS1.
In these scenarios, since MX is doing bi-dir static NAT from FIP<->BMS-IP, it 'owns' the FIP and so should respond to ARP requests for FIP.
description: | updated |
description: | updated |
tags: | added: device-manager |
information type: | Proprietary → Public |
summary: |
- DM: Enable restricted proxy-arp on external VNs + DM: Enable restricted proxy-arp for external VNs |
description: | updated |
tags: | added: blocker |
tags: | removed: blocker |
Review in progress for https:/ /review. opencontrail. org/23259
Submitter: Suresh Balineni (<email address hidden>)