Re: [bess] ARP ND draft
Ok I think there are two scenarios. The original scenario I had in mind was indeed the loopback anycast which would really not have any issues with arp. The other scenario is NIC overload with multiple addresses some of them would be anycast. It is in fact not that uncommon to have an identical VMs with same IP for robustness without LB. I am not sure if we need to *solve* it at ARP, but we do need to consider it as a valid case and not react as far as duplicate address detection is concerned. Again here depending on the implementation if you put both such VMs say in different VRFs you have no ARP issue, but anycast works fine. I think to proceed I would be happy to see those cases just documented in deployment section of the draft and we move on. I do not think that solving or even touching IPv4 ARP is needed here at this point. Or perhaps a different comment to add to the draft would be to mention that duplicate IPv4 address detection is scoped to the same ARP table (which may not be the same as same subnet :). Cheers, r. On Thu, Apr 16, 2015 at 12:44 AM, Erik Nordmark nordm...@acm.org wrote: On 4/15/15 2:53 PM, Robert Raszuk wrote: Erik, How about /32 IPv4 anycast addresses with multiple subnet per linux NIC ? It is typical to be able to overload host networking with same anycast loopbacks. I guess same subnet isn't sufficient as criteria - same subnet which corresponds to a connected route would be one way to phrase the constraint. It does not need to be ARP resolved .. the resolution is indirect via connected next hops. Yes, that is the key issue. For instance host routes (/32) and an anycast address on a loopback interface works fine in IPv4 and IPv6. Erik Cheers, R. On Wed, Apr 15, 2015 at 11:48 PM, Erik Nordmark nordm...@acm.org mailto:nordm...@acm.org wrote: On 3/31/15 1:10 PM, Rabadan, Jorge (Jorge) wrote: Hi Robert and Tony, As Wim mentioned, ipv6 anycast is something that we will add to the draft in the next rev. There is an easy way to know if a given proxy-ND entry belongs to an anycast address or not and disable the duplicate IP detection for those. The challenge for IPv4 is that I don’t see an easy way to learn _dynamically_ from access attachment circuits that a given ipv4 is anycast. Even for default gateways, if they are integrated in the EVPN PE, we are good, but if they are external and connected to a MAC-VRF, it is not so clear how to learn that (unless you learn those entries from the management interface). Jorge, IPv4/ARP doesn't have any support for anycast address on the same subnet. While IPv6/ND has such support (using the O-flag) the common anycast deployment for both is to have the anycast instances deployed on different subnets and, in the case of DNS servers, in different ISPs. Thus for IPv4 I think you can assume that the same IP address appearing with different MAC addresses is either a duplicate IP address or a case of a host having changed the MAC address on its NIC. (I don't know if NIC bonding can be configured in a way where it looks like an IP-MAC change each time there is a failure; if so that would be a third case.) Erik One of the reasons why we have lots of “SHOULDs” in the draft and not “MUST” is because the implementation has to be flexible enough to be configured in a different way depending on the use-case, which is one of the points that Tony mentions below. In the use-case described at the moment there is no anycast and duplicate IP detection is very important. We will add the DC use case in the next rev as suggested by Robert and others. Thanks. Jorge From: Antoni Przygienda antoni.przygie...@ericsson.com mailto:antoni.przygie...@ericsson.com mailto:antoni.przygie...@ericsson.com mailto:antoni.przygie...@ericsson.com Date: Monday, March 30, 2015 at 12:12 AM To: Robert Raszuk rob...@raszuk.net mailto:rob...@raszuk.net mailto:rob...@raszuk.net mailto:rob...@raszuk.net, Henderickx, Wim (Wim) wim.henderi...@alcatel-lucent.com mailto:wim.henderi...@alcatel-lucent.com mailto:wim.henderi...@alcatel-lucent.com mailto:wim.henderi...@alcatel-lucent.com Cc: Erik Nordmark nordm...@acm.org mailto:nordm...@acm.org mailto:nordm...@acm.org mailto:nordm...@acm.org, bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org, Jorge Rabadan jorge.raba...@alcatel-lucent.com mailto:jorge.raba...@alcatel-lucent.com mailto:jorge.raba...@alcatel-lucent.com
Re: [bess] ARP ND draft
On 4/16/15 1:38 PM, Robert Raszuk wrote: Hi Erik, Just to clarify .. none of my comments where about dual NIC servers. Address overload in linux happens on single NIC (unlike in good routers :)) Ah - I need more coffee even at this time of day. Thanks, Erik Cheers, R. On Thu, Apr 16, 2015 at 10:35 PM, Erik Nordmark nordm...@acm.org mailto:nordm...@acm.org wrote: On 4/15/15 11:25 PM, Robert Raszuk wrote: Ok I think there are two scenarios. The original scenario I had in mind was indeed the loopback anycast which would really not have any issues with arp. The other scenario is NIC overload with multiple addresses some of them would be anycast. It is in fact not that uncommon to have an identical VMs with same IP for robustness without LB. I am not sure if we need to *solve* it at ARP, but we do need to consider it as a valid case and not react as far as duplicate address detection is concerned. Again here depending on the implementation if you put both such VMs say in different VRFs you have no ARP issue, but anycast works fine. Robert, The case of a dual-NIC server is typically solved locally (using e.g., multi-chassis LAG for redundancy), and AFAIK the same MAC address is used (but I haven't looked at all the flavors of Linux NIC bonding and VmWare options). I think to proceed I would be happy to see those cases just documented in deployment section of the draft and we move on. I do not think that solving or even touching IPv4 ARP is needed here at this point. Agreed. Or perhaps a different comment to add to the draft would be to mention that duplicate IPv4 address detection is scoped to the same ARP table (which may not be the same as same subnet :). That seems like a useful addition (if it isn't already in this or some other document). Erik Cheers, r. On Thu, Apr 16, 2015 at 12:44 AM, Erik Nordmark nordm...@acm.org mailto:nordm...@acm.org mailto:nordm...@acm.org mailto:nordm...@acm.org wrote: On 4/15/15 2:53 PM, Robert Raszuk wrote: Erik, How about /32 IPv4 anycast addresses with multiple subnet per linux NIC ? It is typical to be able to overload host networking with same anycast loopbacks. I guess same subnet isn't sufficient as criteria - same subnet which corresponds to a connected route would be one way to phrase the constraint. It does not need to be ARP resolved .. the resolution is indirect via connected next hops. Yes, that is the key issue. For instance host routes (/32) and an anycast address on a loopback interface works fine in IPv4 and IPv6. Erik Cheers, R. On Wed, Apr 15, 2015 at 11:48 PM, Erik Nordmark nordm...@acm.org mailto:nordm...@acm.org mailto:nordm...@acm.org mailto:nordm...@acm.org mailto:nordm...@acm.org mailto:nordm...@acm.org mailto:nordm...@acm.org mailto:nordm...@acm.org wrote: On 3/31/15 1:10 PM, Rabadan, Jorge (Jorge) wrote: Hi Robert and Tony, As Wim mentioned, ipv6 anycast is something that we will add to the draft in the next rev. There is an easy way to know if a given proxy-ND entry belongs to an anycast address or not and disable the duplicate IP detection for those. The challenge for IPv4 is that I don’t see an easy way to learn _dynamically_ from access attachment circuits that a given ipv4 is anycast. Even for default gateways, if they are integrated in the EVPN PE, we are good, but if they are external and connected to a MAC-VRF, it is not so clear how to learn that (unless you learn those entries from the management interface). Jorge, IPv4/ARP doesn't have any support for anycast address on the same subnet. While IPv6/ND has such support (using the O-flag) the common anycast deployment for both is to have the anycast instances deployed on different subnets and, in the case of DNS servers, in different ISPs. Thus
