Robert, Does that mean that the EVPN PE/NVE network will never get an ARP-request/reply with duplicate sender's MAC/IP? If so and I understood you, the proxy-arp function will have to learn the IP->MAC bindings for the next-hops, and reply to requests for those next-hops but no the anycast loopbacks themselves. If that is the case, there won’t be duplicate IPs unless the NIC changes MAC (as Erik mentions), there is a human error or there is an ARP spoofing attack. Those cases are/will be covered in the draft.
As discussed and mentioned by Erik below, IPv6 anycast can be identified by the O flag in the NA messages. We’ll add that to the draft. Thank you both. Jorge From: Robert Raszuk <[email protected]<mailto:[email protected]>> Date: Wednesday, April 15, 2015 at 2:53 PM To: Erik Nordmark <[email protected]<mailto:[email protected]>> Cc: Jorge Rabadan <[email protected]<mailto:[email protected]>>, Antoni Przygienda <[email protected]<mailto:[email protected]>>, "Henderickx, Wim (Wim)" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [bess] ARP ND draft 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. It does not need to be ARP resolved .. the resolution is indirect via connected next hops. Cheers, R. On Wed, Apr 15, 2015 at 11:48 PM, Erik Nordmark <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>> Date: Monday, March 30, 2015 at 12:12 AM To: Robert Raszuk <[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>>, "Henderickx, Wim (Wim)" <[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>> Cc: Erik Nordmark <[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>>, "[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>" <[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>>, Jorge Rabadan <[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>> 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:*[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> [mailto:[email protected]<mailto:[email protected]>] *On Behalf Of *Robert Raszuk *Sent:* Monday, March 30, 2015 1:19 AM *To:* Henderickx, Wim (Wim) *Cc:* Erik Nordmark; Antoni Przygienda; [email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>; 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) <[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>> 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, "[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>", 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 <[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>> 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) <[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>> 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" <[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>> 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:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>] >> Sent: Thursday, March 26, 2015 6:01 AM >> To: Antoni Przygienda; Erik Nordmark; Rabadan, Jorge (Jorge) >> Cc: [email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> >> 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" <[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>> >> 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 [email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/bess
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
