Re: [bess] ARP ND draft

[Erik Nordmark <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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
>         <[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>> 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
>         <[e-mail]
>         <mailto:[e-mail]>
>                 <mailto:[e-mail]
>         <mailto:[e-mail]>>
>                 <mailto:[e-mail]
>         <mailto:[e-mail]>
>                 <mailto:[e-mail]
>         <mailto:[e-mail]>>>>
>                 Date: Monday, March 30, 2015 at 12:12 AM
>                 To: Robert Raszuk <[e-mail]
>         <mailto:[e-mail]>
>                 <mailto:[e-mail] <mailto:[e-mail]>>
>         <mailto:[e-mail] <mailto:[e-mail]>
>                 <mailto:[e-mail]
>         <mailto:[e-mail]>>>>, "Henderickx, Wim (Wim)"
>                 <[e-mail]
>         <mailto:[e-mail]>
>                 <mailto:[e-mail]
>         <mailto:[e-mail]>>
>                 <mailto:[e-mail]
>         <mailto:[e-mail]>
>                 <mailto:[e-mail]
>         <mailto:[e-mail]>>>>
>                 Cc: Erik Nordmark <[e-mail]
>         <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>
>                 <mailto:[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>>>,
>                 "[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>
>         <mailto:[e-mail] <mailto:[e-mail]>
>                 <mailto:[e-mail] <mailto:[e-mail]>>>"
>         <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>
>                 <mailto:[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>>>, Jorge Rabadan
>                 <[e-mail]
>         <mailto:[e-mail]>
>                 <mailto:[e-mail]
>         <mailto:[e-mail]>>
>                 <mailto:[e-mail]
>         <mailto:[e-mail]>
>
>                 <mailto:[e-mail]
>         <mailto:[e-mail]>>>>
>                 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:*[e-mail]
>         <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>
>                 <mailto:[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>>
>                     [mailto:[e-mail]
>         <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>] *On
>                 Behalf Of *Robert Raszuk
>                     *Sent:* Monday, March 30, 2015 1:19 AM
>                     *To:* Henderickx, Wim (Wim)
>                     *Cc:* Erik Nordmark; Antoni Przygienda;
>         [e-mail] <mailto:[e-mail]>
>                 <mailto:[e-mail] <mailto:[e-mail]>>
>                     <mailto:[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>>; 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)
>                     <[e-mail]
>         <mailto:[e-mail]>
>                 <mailto:[e-mail]
>         <mailto:[e-mail]>>
>                     <mailto:[e-mail]
>         <mailto:[e-mail]>
>                 <mailto:[e-mail]
>         <mailto:[e-mail]>>>> 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,
>         "[e-mail] <mailto:[e-mail]>
>                 <mailto:[e-mail] <mailto:[e-mail]>>
>                     <mailto:[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>>", 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
>         <[e-mail] <mailto:[e-mail]>
>                 <mailto:[e-mail] <mailto:[e-mail]>>
>                     <mailto:[e-mail]
>         <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>>> 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)
>                         <[e-mail]
>         <mailto:[e-mail]>
>                 <mailto:[e-mail]
>         <mailto:[e-mail]>>
>                         <mailto:[e-mail]
>         <mailto:[e-mail]>
>                 <mailto:[e-mail]
>         <mailto:[e-mail]>>>> 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"
>                         <[e-mail]
>         <mailto:[e-mail]>
>                 <mailto:[e-mail]
>         <mailto:[e-mail]>>
>                         <mailto:[e-mail]
>         <mailto:[e-mail]>
>
>                 <mailto:[e-mail]
>         <mailto:[e-mail]>>>> 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:[e-mail]
>         <mailto:[e-mail]>
>                 <mailto:[e-mail]
>         <mailto:[e-mail]>>
>                         <mailto:[e-mail]
>         <mailto:[e-mail]>
>                 <mailto:[e-mail]
>         <mailto:[e-mail]>>>]
>                         >> Sent: Thursday, March 26, 2015 6:01 AM
>                         >> To: Antoni Przygienda; Erik Nordmark; Rabadan,
>                 Jorge (Jorge)
>                         >> Cc: [e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>
>                 <mailto:[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>>
>                         >> 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"
>                         <[e-mail]
>         <mailto:[e-mail]>
>                 <mailto:[e-mail]
>         <mailto:[e-mail]>>
>                         <mailto:[e-mail]
>         <mailto:[e-mail]>
>                 <mailto:[e-mail]
>         <mailto:[e-mail]>>>>
>                         >> 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
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>> <mailto:[e-mail]
>         <mailto:[e-mail]>
>                 <mailto:[e-mail] <mailto:[e-mail]>>>
>         https://www.ietf.org/mailman/listinfo/bess
>
>
>             _______________________________________________
>             BESS mailing list
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>
>         https://www.ietf.org/mailman/listinfo/bess
>
>
>
>     _______________________________________________
>     BESS mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/bess
>
>