Cheers,
R.
On Thu, Apr 16, 2015 at 10:35 PM, Erik Nordmark <nordm...@acm.org
<mailto:nordm...@acm.org>> 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
<nordm...@acm.org <mailto:nordm...@acm.org>
<mailto:nordm...@acm.org <mailto: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>
<mailto:nordm...@acm.org <mailto:nordm...@acm.org>>
<mailto:nordm...@acm.org <mailto:nordm...@acm.org>
<mailto: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>>
<mailto:antoni.przygie...@ericsson.com
<mailto:antoni.przygie...@ericsson.com>
<mailto:antoni.przygie...@ericsson.com
<mailto:antoni.przygie...@ericsson.com>>>
<mailto:antoni.przygie...@ericsson.com
<mailto:antoni.przygie...@ericsson.com>
<mailto:antoni.przygie...@ericsson.com
<mailto:antoni.przygie...@ericsson.com>>
<mailto: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>>
<mailto:rob...@raszuk.net
<mailto:rob...@raszuk.net> <mailto:rob...@raszuk.net
<mailto:rob...@raszuk.net>>>
<mailto:rob...@raszuk.net <mailto:rob...@raszuk.net>
<mailto:rob...@raszuk.net <mailto:rob...@raszuk.net>>
<mailto: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>>
<mailto:wim.henderi...@alcatel-lucent.com
<mailto:wim.henderi...@alcatel-lucent.com>
<mailto:wim.henderi...@alcatel-lucent.com
<mailto:wim.henderi...@alcatel-lucent.com>>>
<mailto:wim.henderi...@alcatel-lucent.com
<mailto:wim.henderi...@alcatel-lucent.com>
<mailto:wim.henderi...@alcatel-lucent.com
<mailto:wim.henderi...@alcatel-lucent.com>>
<mailto: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>>
<mailto:nordm...@acm.org <mailto:nordm...@acm.org>
<mailto:nordm...@acm.org <mailto:nordm...@acm.org>>>
<mailto:nordm...@acm.org
<mailto:nordm...@acm.org> <mailto:nordm...@acm.org
<mailto:nordm...@acm.org>>
<mailto: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>>
<mailto:bess@ietf.org <mailto:bess@ietf.org>
<mailto:bess@ietf.org <mailto:bess@ietf.org>>>
<mailto:bess@ietf.org <mailto:bess@ietf.org>
<mailto:bess@ietf.org <mailto:bess@ietf.org>>
<mailto: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>>
<mailto:bess@ietf.org <mailto:bess@ietf.org>
<mailto:bess@ietf.org <mailto:bess@ietf.org>>>
<mailto:bess@ietf.org <mailto:bess@ietf.org>
<mailto:bess@ietf.org <mailto:bess@ietf.org>>
<mailto: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>>
<mailto:jorge.raba...@alcatel-lucent.com
<mailto:jorge.raba...@alcatel-lucent.com>
<mailto:jorge.raba...@alcatel-lucent.com
<mailto:jorge.raba...@alcatel-lucent.com>>>
<mailto:jorge.raba...@alcatel-lucent.com
<mailto:jorge.raba...@alcatel-lucent.com>
<mailto:jorge.raba...@alcatel-lucent.com
<mailto:jorge.raba...@alcatel-lucent.com>>
<mailto: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>
<mailto:rras...@gmail.com <mailto:rras...@gmail.com>>>
<mailto:rras...@gmail.com
<mailto:rras...@gmail.com> <mailto:rras...@gmail.com
<mailto:rras...@gmail.com>>
<mailto:rras...@gmail.com <mailto:rras...@gmail.com>
<mailto:rras...@gmail.com <mailto:rras...@gmail.com>>>>
[mailto:rras...@gmail.com
<mailto:rras...@gmail.com>
<mailto: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>>
<mailto:bess@ietf.org <mailto:bess@ietf.org>
<mailto:bess@ietf.org <mailto:bess@ietf.org>>>
<mailto:bess@ietf.org
<mailto:bess@ietf.org> <mailto:bess@ietf.org
<mailto:bess@ietf.org>>
<mailto: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>>
<mailto:wim.henderi...@alcatel-lucent.com
<mailto:wim.henderi...@alcatel-lucent.com>
<mailto:wim.henderi...@alcatel-lucent.com
<mailto:wim.henderi...@alcatel-lucent.com>>>
<mailto:wim.henderi...@alcatel-lucent.com
<mailto:wim.henderi...@alcatel-lucent.com>
<mailto:wim.henderi...@alcatel-lucent.com
<mailto:wim.henderi...@alcatel-lucent.com>>
<mailto: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>>
<mailto:bess@ietf.org <mailto:bess@ietf.org>
<mailto:bess@ietf.org <mailto:bess@ietf.org>>>
<mailto:bess@ietf.org
<mailto:bess@ietf.org> <mailto:bess@ietf.org
<mailto:bess@ietf.org>>
<mailto: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>>
<mailto:rob...@raszuk.net
<mailto:rob...@raszuk.net> <mailto:rob...@raszuk.net
<mailto:rob...@raszuk.net>>>
<mailto:rob...@raszuk.net
<mailto:rob...@raszuk.net>
<mailto:rob...@raszuk.net <mailto:rob...@raszuk.net>>
<mailto: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>>
<mailto:wim.henderi...@alcatel-lucent.com
<mailto:wim.henderi...@alcatel-lucent.com>
<mailto:wim.henderi...@alcatel-lucent.com
<mailto:wim.henderi...@alcatel-lucent.com>>>
<mailto:wim.henderi...@alcatel-lucent.com
<mailto:wim.henderi...@alcatel-lucent.com>
<mailto:wim.henderi...@alcatel-lucent.com
<mailto:wim.henderi...@alcatel-lucent.com>>
<mailto: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>>
<mailto:antoni.przygie...@ericsson.com
<mailto:antoni.przygie...@ericsson.com>
<mailto:antoni.przygie...@ericsson.com
<mailto:antoni.przygie...@ericsson.com>>>
<mailto:antoni.przygie...@ericsson.com
<mailto:antoni.przygie...@ericsson.com>
<mailto:antoni.przygie...@ericsson.com
<mailto:antoni.przygie...@ericsson.com>>
<mailto: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>>
<mailto:wim.henderi...@alcatel-lucent.com
<mailto:wim.henderi...@alcatel-lucent.com>
<mailto:wim.henderi...@alcatel-lucent.com
<mailto:wim.henderi...@alcatel-lucent.com>>>
<mailto:wim.henderi...@alcatel-lucent.com
<mailto:wim.henderi...@alcatel-lucent.com>
<mailto:wim.henderi...@alcatel-lucent.com
<mailto:wim.henderi...@alcatel-lucent.com>>
<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>>
<mailto:bess@ietf.org <mailto:bess@ietf.org>
<mailto:bess@ietf.org <mailto:bess@ietf.org>>>
<mailto:bess@ietf.org <mailto:bess@ietf.org>
<mailto:bess@ietf.org <mailto:bess@ietf.org>>
<mailto: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>>
<mailto:antoni.przygie...@ericsson.com
<mailto:antoni.przygie...@ericsson.com>
<mailto:antoni.przygie...@ericsson.com
<mailto:antoni.przygie...@ericsson.com>>>
<mailto:antoni.przygie...@ericsson.com
<mailto:antoni.przygie...@ericsson.com>
<mailto:antoni.przygie...@ericsson.com
<mailto:antoni.przygie...@ericsson.com>>
<mailto: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>> <mailto:BESS@ietf.org
<mailto:BESS@ietf.org>
<mailto:BESS@ietf.org <mailto:BESS@ietf.org>>>
<mailto:BESS@ietf.org <mailto:BESS@ietf.org>
<mailto:BESS@ietf.org <mailto:BESS@ietf.org>>
<mailto: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> <mailto:BESS@ietf.org
<mailto:BESS@ietf.org>> <mailto: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> <mailto:BESS@ietf.org
<mailto:BESS@ietf.org>>
https://www.ietf.org/mailman/listinfo/bess
