Subject: [rbridge] duplicate-arp equivalence.

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Mon Aug 2 20:42:25 2004

I've looked at rbridges a little bit from the perspective of a host
implementor..

A very desirable property of an rbridge ARP proxy would replicate the
existing arp conflict detection behavior you see on a broadcast
network -- both nodes see both arp replies, and a common response is
to generate a log message along the lines of:

	WARNING: IP: Hardware address '00:90:96:xx:yy:zz' trying to be
	our address 130.129.a.b!

(quoted from a log entry from earlier today on my laptop; edited to
protect the guilty from embarassment).

A collection of rbridges would have to do something special in this
case to notice the address collision -- so, in addition to generating
the duplicate arp replies it could also generate a log message/audit
event/management trap indicating that something odd is going on.

In addition, an rbridge could be in a position to "resolve" the clash
by enforcing its own policy.

(I'd appreciate it if section 7 of the draft could be enhanced to
mention this case..)

						- Bill

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Tue Aug 3 10:07:31 2004

Ah. This is an interesting issue. First let me ask...you are describing 
the case where
there are two IP nodes with different MAC addresses but the same L3 
address, right?

Is this because you genuinely want a node to have multiple interfaces 
and have the
same layer 3 address on multiple interfaces (with different layer 2 
addresses on
each interface)? Or is this misonfiguration?

The way the RBridge design is now, you may or may not like
its behavior. Let me explain what happens.

Suppose IPa is looking for IPx, and nobody has looked for IPx yet. IPa will
do an ARP. There will be a flooded ARP request. Some designated RBridge R1,
will be locally connected to the target, and hear the ARP reply (IPx, MACy).

R1 will flood (IPx, MACy) in its link state information. Now when anyone is
looking for IPx, their local RBridge will respond "MACy". There will not
be a conflict detected because the ARP is answered locally.

However, if the "other" IPx does an ARP reply (a gratuitous
ARP reply), then RBridges would be able to
detect the conflict.

This behavior will be very efficient in the usual case, however, I can 
imagine someone
being unhappy about not detecting this. So there are a couple of 
alternatives off the
top of my head:

a) learn (IPx, MACy) from received data traffic (like a bridge learns 
MACy from received
data, an RBridge could proactively learn from both the layer 3 and layer 
2 header). This
way they would detect if the same IP address is in multiple locations, 
with different layer
2 addresses. If (IPx, MACy) is in your link state information, and a 
designated RBridge R2
receives an unencapsulated packet from IPx with MACz, then R2 could 
either also advertise
(IPx, MACz) in its link state information so that all RBridges will know 
there are two
answers for IPx (either MACy or MACz), or R1 (who heard MACy) and R2 could
each do a gratuitous ARP reply to alert their local node of the 
existence of the other
node. (i.e., is this a failure case to be noticed, or a path splitting 
case to be handled?)

b) periodically have all RBridges do ARP queries for all (l3, l2) info 
in the link state database
to make sure there are no conflicts (I don't like this solution).

c) when I started this list I thought I had other ideas, but can't think 
of them now.  But
it would help to know if this is an error case you're worried about 
detecting or something
you'd like to work for path splitting.

Radia

Bill Sommerfeld wrote:

>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Tue Aug 3 10:58:30 2004

Ah. This is an interesting issue. First let me ask...you are
   describing the case where there are two IP nodes with different MAC
   addresses but the same L3 address, right?
 
   Is this because you genuinely want a node to have multiple interfaces
   and have the same layer 3 address on multiple interfaces (with
   different layer 2 addresses on each interface)? Or is this
   misconfiguration?

My first note was specifically worrying about the misconfiguration
case from a "first, do no harm" perspective.

   But it would help to know if this is an error case you're worried about 
   detecting or something you'd like to work for path splitting.

But in the long run I'm also interested in the multihoming case..

Potentially both, but path-splitting/multipathing/redundancy is a
harder nut to crack; in addition, if you're multihoming for (local)
performance, a multihomed leaf node would also want some way to learn
the topology..

						- Bill