[rbridge] duplicate-arp equivalence.

[Radia Perlman]

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:

>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
>
>
>
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>  
>