On 4/8/16 10:00 AM, Gangadhar R Vegesana wrote: > HI Dustin, > > *Case 1)* External Gateway or External Host have IP and now VM is > assigned the same IP, > VM should decline or not use that IP (ie. Send DCHP Decline in case of > DHCP). The ARP probe that is sent by VM should reach the External > Gateway/Host to get response back. I added that new entry to flood that > ARP Probe. Without this entry, the OVN ARP res-ponder, responds back to > the VM and there is no way VM knowing that there exists some conflict. > Once the conflict is known, either CMS or DHCP Server have to fix this, > by assigning a new IP to the VM. > > *Case 2)* VM have IP and External Gateway or External Host is assigned > the same IP : > This issue should be resolved by Gateway or External Host Admin, as > he/she is the one who is configuring the conflicting IP in the second place. > > I agree with you, that this is job of CMS to not allocate this IP > address, but this ARP probe is one such way to know that there exists > some conflict. From my understanding, i assume that OVN ARP responder > table won't have External Gateway ARP entry in its table. If we start > learning provider network (localnet) ARP entries, they can be huge > number (i assume) and OVN won't have control on these external entries. > Please let me know your thoughts.
Let me try to break this into two separate topics: cost/benefit analysis of permitting ARP probes and learning provider network addresses for ARP responder. Regarding permitting ARP probes, my initial thought is that there is a higher than normal cost to broadcast/multicast traffic in OVN since traffic must be replicated and sent via unicast through each tunnel. I know there is work in progress to change this, but as I understand it this is the reasoning behind filtering ARP probes. But this is not the case in provider networks, since there is not a increased normal cost in handling broadcast and multicast traffic; this traffic is simply forwarded to the provider network interface and traffic is this replicated on the upstream network device. So performance impact of permitting ARP probes is not significant. Unfortunately the benefit of permitting ARP probes is rather low. Since ports in OVN are programmed with their L2 and L3 addresses and flows are created before an VM is connected to this port _the damage is already done_ (atleast to all the hosts connected via OVN) before the VM could perform an ARP probe to find out if its IP is in use. For this work as desired OVN would need to perform the ARP probe before creating the flows for the new IP address ARP responder. This would add a significant delay in flow creation. A learning ARP responder provides another option for managing duplicate IP addresses. While the number of address may be large, in conventional deployments it is only a small number of addresses with less churn than other OVN ports. With a mechanism to receive ARP responses from provider network devices and add them to the northbound database, OVN could return an error when a CMS attempts to provision a port with a duplicate address. This would not work well, if for example a user deployed a provider network connected to a campus wireless network or similar large L2 network with a high degree of address churn, but I don't think this is a use case we should design for. -Dustin _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
