Subject: Re: [bess] ARP ND draft

From: Erik Nordmark <[email-masked]>
Date: Wed, 15 Apr 2015 14:48:40 -0700

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 15 Apr 2015 23:53:05 +0200

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-masked]> wrote:

>> 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.
>>
>> _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.
>
> 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
>
>
>> 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-masked] <mailto:
>> [email-masked]>>
>> "Henderickx, Wim (Wim)" <[email-masked] <mailto:
>> [email-masked]>>
>> Cc: Erik Nordmark <[email-masked] <mailto:[email-masked]>>, "
>> [email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:
>> [email-masked]>>, Jorge Rabadan <[email-masked] <mailto:
>> [email-masked]>>
> [email-masked]

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Wed, 15 Apr 2015 22:39:43 +0000

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-masked]<mailto:[email-masked]>>
Date: Wednesday, April 15, 2015 at 2:53 PM
To: Erik Nordmark <[email-masked]<mailto:[email-masked]>>
Cc: Jorge Rabadan <[email-masked]<mailto:[email-masked]>>, Antoni Przygienda <[email-masked]<mailto:[email-masked]>>, "Henderickx, Wim (Wim)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
Date: Monday, March 30, 2015 at 12:12 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>, "Henderickx, Wim (Wim)" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
Cc: Erik Nordmark <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>, Jorge Rabadan <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
Subject: RE: [bess] ARP ND draft

    Thanks

    --- tony

    //

    /~~~ Mark Twain

    *From:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    [mailto:[email-masked]<mailto:[email-masked]>] *On Behalf Of *Robert Raszuk
    *Sent:* Monday, March 30, 2015 1:19 AM
    *To:* Henderickx, Wim (Wim)
    *Cc:* Erik Nordmark; Antoni Przygienda; [email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]<mailto:[email-masked]>>; Rabadan, Jorge (Jorge)
    *Subject:* Re: [bess] ARP ND draft

    Hi Wim,

    supported at arp level.

    Cheers,

    R.

    On Mon, Mar 30, 2015 at 1:10 AM, Henderickx, Wim (Wim)
    <[email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    *From: *<Henderickx>, Wim Henderickx
    *Date: *Monday 30 March 2015 07:38
    *To: *Robert Raszuk
    *Cc: *Erik Nordmark, Antoni Przygienda, "[email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]<mailto:[email-masked]>>", Jorge Rabadan

    Sent from my iPhone

    On 30 Mar 2015, at 06:45, Robert Raszuk <[email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

        Hi Wim,

        Cheers,

        r.

        On Sun, Mar 29, 2015 at 11:18 PM, Henderickx, Wim (Wim)
        <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

        On 30/03/15 04:59, "Antoni Przygienda"
        <[email-masked]<mailto:[email-masked]>

        >> From: Henderickx, Wim (Wim)
        [mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>]
        >> Cc: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
        <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>>
        eVPN
        happens when
        would be
        Additionally, in
        _______________________________________________
        BESS mailing list
        [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
        https://www.ietf.org/mailman/listinfo/bess

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 15 Apr 2015 15:44:31 -0700

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 
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

>         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,
>
>     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
>
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         To: Robert Raszuk <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>, "Henderickx, Wim (Wim)"
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         Cc: Erik Nordmark <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>,
>         "[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>, Jorge Rabadan
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>             [mailto:[email-masked] <mailto:[email-masked]>] *On
>         Behalf Of *Robert Raszuk
>         <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>; Rabadan,
>         Jorge (Jorge)
>         <mailto:[email-masked]>
>             <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>         <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>", Jorge Rabadan
>
>
>         <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>                 Hi Wim,
>
>         <mailto:[email-masked]>
>                 <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>         <mailto:[email-masked]>
>                 <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>         <mailto:[email-masked]>
>                 <mailto:[email-masked]
>         <mailto:[email-masked]>>]
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked]>
>                 <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>                 >> wrote:
>                 >>
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Apr 2015 08:25:37 +0200

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.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Apr 2015 13:35:42 -0700

On 4/15/15 11:25 PM, Robert Raszuk wrote:
> 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-masked] 
> <mailto:[email-masked]>> wrote:
>
>         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.
>
>
>     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-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>         <mailto:[email-masked]>>>>
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked]
>         <mailto:[email-masked]>>>>, "Henderickx, Wim (Wim)"
>         <mailto:[email-masked]>>>>
>                 Cc: Erik Nordmark <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>                 <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>>,
>                 "[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>>"
>         <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>                 <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>>, Jorge Rabadan
>         <mailto:[email-masked]>>>>
>                     I’m also skeptical whether IP duplicate detection
>         would be
>                 a good
>                     default thing. Especially in case of what I call
>         ‘aliased
>                 default
>                     ExtComm is there to differentiate so it can be
>         called an
>                 exception
>                     but nevertheless.
>
>                     detection will not apply there, it’s all same
>         IPx->MACx
>                 from all
>                     Generally I think someone who wants a secure,
>         stable eVPN
>                 wants IP
>                     *From:[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>                 <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>                     [mailto:[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>] *On
>                 Behalf Of *Robert Raszuk
>                     *Cc:* Erik Nordmark; Antoni Przygienda;
>         [email-masked] <mailto:[email-masked]>
>                     <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>; Rabadan,
>                 Jorge (Jorge)
>                     Precisely right. It needs to be documented and
>         addressed
>                 if anyone
>         <mailto:[email-masked]>>>> wrote:
>
>                     To be clear: RFC4861 section 7.2.7 explains the
>         anycast
>                 behaviour
>                     in IPv6.
>
>                     There is anycast at IPv4 level for sure but I am
>         not ware
>                 this is
>                     supported at arp level.
>
>                     *Cc: *Erik Nordmark, Antoni Przygienda,
>         "[email-masked] <mailto:[email-masked]>
>                     <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>", Jorge Rabadan
>
>
>                     On 30 Mar 2015, at 06:45, Robert Raszuk
>         <[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>                     <mailto:[email-masked]
>         <mailto:[email-masked]>>>> wrote:
>
>                         Hi Wim,
>
>         <mailto:[email-masked]>>>> wrote:
>
>         <mailto:[email-masked]>>>> 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
>                         offered. That could lead IMO to e.g. gateway
>         chasing
>                 problems.
>                         >
>                         >--- tony
>                         >
>                         >
>         <mailto:[email-masked]>>>]
>                 <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>                         >> For this case you should sent a GARP with
>         the new
>                 MAC/IP
>                         >>
>                         >>
>                         >>
>                         >>
>         <mailto:[email-masked]>>>>
>                         >> wrote:
>                         >>
>                         >> >So the answer it gave is not valid anymore
>         all of
>                 a sudden.
>                         >> >
>                         >> >--- tony
>         <mailto:[email-masked]>> <mailto:[email-masked]
>         <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Apr 2015 22:38:26 +0200

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-masked]> wrote:

> 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).
>
>

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Apr 2015 13:44:19 -0700

> Address overload in linux happens on single NIC (unlike in good 
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 <[email-masked] 
>         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
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>
>                         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
>                         given ipv4 is anycast. Even for default
>         gateways, if
>                 they are
>                         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
>                     instances deployed on different subnets and, in
>         the case
>                 of DNS
>                     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
>                         One of the reasons why we have lots of
>         “SHOULDs” in
>                 the draft
>                         flexible enough to be configured in a
>         different way
>                 depending
>                         on the use-case, which is one of the points
>         that Tony
>                 mentions
>                         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
>         <mailto:[email-masked]>>>>>
>         <mailto:[email-masked]>>>
>         <mailto:[email-masked]>>>>>, "Henderickx, Wim (Wim)"
>         <mailto:[email-masked]>>>>>
>         <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>                 <mailto:[email-masked] <mailto:[email-masked]>>>
>                         <mailto:[email-masked]
>         <mailto:[email-masked] <mailto:[email-masked]>>>>>,
>         <mailto:[email-masked] <mailto:[email-masked]>>>>"
>
>                 <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>>>, Jorge Rabadan
>         <mailto:[email-masked]>>>>>
>                             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
>                             I also thought a tad about VRRP but I
>         think the IP
>                 duplicate
>                             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
>         <mailto:[email-masked]>
>                         <mailto:[email-masked]
>         <mailto:[email-masked] <mailto:[email-masked]>>>>
>         <mailto:[email-masked]>
>                 <mailto:[email-masked]
>         <mailto:[email-masked]>>>] *On
>                         Behalf Of *Robert Raszuk
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>                             <mailto:[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>>>>; Rabadan,
>                         Jorge (Jorge)
>                             > There is anycast at IPv4 level for sure
>         but I am not
>                         ware this is
>                             supported at arp level.
>
>                             is up to proposing automated IP duplicate
>         address
>                         detection and
>                             disabling.
>
>         <mailto:[email-masked]>>>>> wrote:
>
>                             I am not aware of such thing at IPv4/ARP
>         level. Do you
>                         have a pointer?
>
>                             <mailto:[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>>>>", Jorge Rabadan
>
>
>         <mailto:[email-masked]>>>
>         <mailto:[email-masked]>>>>> wrote:
>
>                                 Hi Wim,
>
>                                 What makes you say that in IPv4 there
>         is no
>                 anycast ? All
>                                 On Sun, Mar 29, 2015 at 11:18 PM,
>         Henderickx,
>                 Wim (Wim)
>         <mailto:[email-masked]>>>>> 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.
>
>
>
>
>         <mailto:[email-masked]>>>>> wrote:
>
>                                 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
>                                 accomplish things, and people who
>         claim to have
>                         accomplished
>         <mailto:[email-masked]>>>>]
>                                 >> To: Antoni Przygienda; Erik
>         Nordmark; Rabadan,
>                         Jorge (Jorge)
>                                 >> Cc: [email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>>>>
>         <mailto:[email-masked]>>>>>
>                                 >> wrote:
>                                 >>
>                                 >> >> > b)It is worth explaining what
>         is suggested
>                         behavior if
>                                 eVPN
>                                 >> >> > advertises the same IP with
>         multiple
>                 MACs and what
>                                 happens when
>                                 >> >The scenario I had in mind was
>         when eVPN
>                 PE receives
>                                 >> >
>         <mailto:[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>                         <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>>