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 >> >> <mailto:jorge.raba...@alcatel-lucent.com>>> >> Subject: RE: [bess] ARP ND draft >> >> I’m also skeptical whether IP duplicate detection would be >> a good >> default thing. Especially in case of what I call ‘aliased >> default >> gateway’ which section 10.1 specifically allows, i.e. >> default GW >> IP address is same but each PE may use a different MAC when >> advertising it and consequently responses for same IP with >> different ARPs may be seen in the network. Yes, default GW >> ExtComm is there to differentiate so it can be called an >> exception >> but nevertheless. >> >> I also thought a tad about VRRP but I think the IP duplicate >> detection will not apply there, it’s all same IPx->MACx >> from all >> routers so if anything, it’s more of a MAC move thing. >> >> Generally I think someone who wants a secure, stable eVPN >> wants IP >> duplicate detection, someone who runs a very dynamic >> network with >> tons gateways, possibly anycast & floating IPs will >> probably not >> be too enamored with it. >> >> Thanks >> >> --- tony >> >> // >> >> /There are basically two types of people. People who >> accomplish >> things, and people who claim to have accomplished things. The >> first group is less crowded. >> <http://www.brainyquote.com/quotes/quotes/m/ >> marktwain393535.html>/ >> >> /~~~ Mark Twain >> <http://www.brainyquote.com/quotes/quotes/m/ >> marktwain393535.html>/ >> >> *From:*rras...@gmail.com <mailto:rras...@gmail.com> >> <mailto:rras...@gmail.com <mailto:rras...@gmail.com>> >> [mailto:rras...@gmail.com <mailto:rras...@gmail.com>] *On >> Behalf Of *Robert Raszuk >> *Sent:* Monday, March 30, 2015 1:19 AM >> *To:* Henderickx, Wim (Wim) >> *Cc:* Erik Nordmark; Antoni Przygienda; bess@ietf.org >> <mailto:bess@ietf.org> >> <mailto:bess@ietf.org <mailto:bess@ietf.org>>; Rabadan, >> Jorge (Jorge) >> *Subject:* Re: [bess] ARP ND draft >> >> Hi Wim, >> >> > There is anycast at IPv4 level for sure but I am not >> ware this is >> supported at arp level. >> >> Precisely right. It needs to be documented and addressed >> if anyone >> is up to proposing automated IP duplicate address >> detection and >> disabling. >> >> RFC1546 is rather too old to consider here as solution :) >> >> Cheers, >> >> R. >> >> On Mon, Mar 30, 2015 at 1:10 AM, 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>>> wrote: >> >> To be clear: RFC4861 section 7.2.7 explains the anycast >> behaviour >> in IPv6. >> >> I am not aware of such thing at IPv4/ARP level. Do you >> have a pointer? >> >> There is anycast at IPv4 level for sure but I am not ware >> this is >> supported at arp level. >> >> *From: *<Henderickx>, Wim Henderickx >> *Date: *Monday 30 March 2015 07:38 >> *To: *Robert Raszuk >> *Cc: *Erik Nordmark, Antoni Przygienda, "bess@ietf.org >> <mailto:bess@ietf.org> >> <mailto:bess@ietf.org <mailto:bess@ietf.org>>", Jorge Rabadan >> >> >> *Subject: *Re: [bess] ARP ND draft >> >> At interface level you get dad in most stacks I know. >> >> Sent from my iPhone >> >> >> On 30 Mar 2015, at 06:45, Robert Raszuk <rob...@raszuk.net >> <mailto:rob...@raszuk.net> >> <mailto:rob...@raszuk.net <mailto:rob...@raszuk.net>>> wrote: >> >> Hi Wim, >> >> What makes you say that in IPv4 there is no anycast ? All >> anycase I have played so far is IPv4 :) >> >> Cheers, >> >> r. >> >> On Sun, Mar 29, 2015 at 11:18 PM, 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>>> wrote: >> >> We will update the draft to highlight the IPv6 anycast >> behaviour better as pointed out by RObert. In IPv4 >> there is no >> anycast behaviour and as such there should be one >> option possible. >> >> >> >> >> On 30/03/15 04:59, "Antoni Przygienda" >> <antoni.przygie...@ericsson.com >> <mailto:antoni.przygie...@ericsson.com> >> <mailto:antoni.przygie...@ericsson.com >> >> <mailto:antoni.przygie...@ericsson.com>>> wrote: >> >> >Yes, but of course I brought it up to show that 'the >> last one >> simply wins' as suggested by the draft is not enough >> IMO. A >> good architecture should probably keep track of what >> it served >> as answer and when the answer is invalid or a new, >> better one >> exists, provide a GARP. >> > >> >As well, when PE2 sends a newer MAC it may not be a good >> strategy to serve a GARP if PE1's MAC has already been >> offered. That could lead IMO to e.g. gateway chasing >> problems. >> > >> >--- tony >> > >> > >> >There are basically two types of people. People who >> accomplish things, and people who claim to have >> accomplished >> things. The first group is less crowded. >> >~~~ Mark Twain >> > >> > >> >> -----Original Message----- >> >> From: Henderickx, Wim (Wim) >> [mailto:wim.henderi...@alcatel-lucent.com >> <mailto:wim.henderi...@alcatel-lucent.com> >> <mailto:wim.henderi...@alcatel-lucent.com >> <mailto:wim.henderi...@alcatel-lucent.com>>] >> >> Sent: Thursday, March 26, 2015 6:01 AM >> >> To: Antoni Przygienda; Erik Nordmark; Rabadan, >> Jorge (Jorge) >> >> Cc: bess@ietf.org <mailto:bess@ietf.org> >> <mailto:bess@ietf.org <mailto:bess@ietf.org>> >> >> Subject: Re: [bess] ARP ND draft >> >> >> >> For this case you should sent a GARP with the new >> MAC/IP >> >> >> >> >> >> >> >> >> >> On 25/03/15 18:56, "Antoni Przygienda" >> <antoni.przygie...@ericsson.com >> <mailto:antoni.przygie...@ericsson.com> >> <mailto:antoni.przygie...@ericsson.com >> <mailto:antoni.przygie...@ericsson.com>>> >> >> wrote: >> >> >> >> >> > b)It is worth explaining what is suggested >> behavior if >> eVPN >> >> >> > advertises the same IP with multiple MACs and what >> happens when >> >> >> > e.g. the served MAC vanishes >> >> >> > >> >> >> Doesn't the EVPN RFC already stating that the routes >> would be >> >> >> withdrawn in that case? >> >> > >> >> >The scenario I had in mind was when eVPN PE receives >> >> > >> >> >From PE2 IP1/M1 and later >> >> >From PE3 IP1/M2 >> >> > >> >> >while having answered with IP1/M1 per proxy alrady. >> Additionally, in >> >> >such situation ends up seeing >> >> > >> >> >From PE2 IP1/<no MAC> >> >> > >> >> >So the answer it gave is not valid anymore all of >> a sudden. >> >> > >> >> >--- tony >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org <mailto:BESS@ietf.org> <mailto:BESS@ietf.org >> <mailto:BESS@ietf.org>> >> https://www.ietf.org/mailman/listinfo/bess >> >> >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org <mailto:BESS@ietf.org> >> https://www.ietf.org/mailman/listinfo/bess >> >> >> > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
