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 :))
Cheers, R. On Thu, Apr 16, 2015 at 10:35 PM, Erik Nordmark <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]> >> <mailto:[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]>> >> <mailto:[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]>> >> <mailto:[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]>> >> <mailto:[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]>> >> <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>>, >> "[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>" >> >> <[email protected] <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>>, Jorge Rabadan >> <[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>> >> <mailto:[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]> >> <mailto:[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]>> >> <mailto:[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]>> >> <mailto:[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]>> >> <mailto:[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]>> >> <mailto:[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]>> >> <mailto:[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]>> >> <mailto:[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]>> >> <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]>> >> <mailto:[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]>> >> <mailto:[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]>> <mailto:[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]> <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
