Subject: How handle multiple replies to an FARP-REQ?

From: Lansing Sloan <[email-masked]>
Date: Thu, 7 Jan 1999 16:15:33 -0800

Hi,

   When I looked at draft-ietf-fibre-channel-03.txt, I thought it might
be possible that an FARP-REQ with an IPv4 address could cause multiple
FARP-REPLY's.  Should "IP and ARP over Fibre Channel" say anything about how
a FARP-REQ Requester is supposed to handle multiple replies if they occur?

   I think such a case is just as possible with other broadcast media
(such as Ethernet) as with Fibre Channel; so if the situation is
discussed elsewhere, then I think this document ought to be consistent,
perhaps by referring to that other discussion.

   I've talked with Murali briefly, then glanced at a couple of references,
and now think that if there were multiple replies then there was probably a
configuration error (anyway, probably something was wrong).  For what it's
worth, here's a scenario I previously thought was legitimate.  If there are
multiple routers on a "broadcast" medium such as Ethernet or Fibre Channel,
if multiple routers are prepared to forward toward a
particular remote IP address, if a requester tries to resolve that IP
address, and if at least two of the multiple routers use proxy ARP to
respond to the ARP request, then at least two ARP replies occur.  What
should the ARP requester do upon receiving multiple replies?

-- Lansing Sloan (stating personal opinions)

---

From: "Infante, Jon" <[email-masked]>
Date: Thu, 7 Jan 1999 17:19:04 -0800

Lansing,

FARP-REQ and FARP-REPLY are two totally seperate
ELS commands. There is nothing that states there is any
corelation between the number of FARP-REPLYs and the
number of FARP-REQs sent. In theory, someone could send
a FARP-REPLY without recieving a FARP-REQ.  If multiple
FARP-REPLYs are recieved  I would vote to just use the 
information in the last one recieved.

The same holds true for FARP-REQ and PLOGI. If a PLOGI
is recieved, and you think your already logged in to that node
you should implicitly logout and use the payload parameters
in the last PLOGI recieved to login again.  The multiple PLOGI senerio
can also happen if a remote node in a fabric topology changes
its Port_ID.

For my specific implementation, I use FARP-REQ and PLOGI.
If someone sends me a FARP-REPLY, I'll send an ACC back, but
I don't make use of the information in the FARP-REPLY payload.

Jon Infante
Emulex

----------
From: 	Lansing Sloan
Sent: 	Thursday, January 07, 1999 4:15 PM
To: 	[email-masked]
Cc: 	[email-masked]
Subject: 	How handle multiple replies to an FARP-REQ?

Hi,

---

From: Bill Martin <[email-masked]>
Date: Fri, 8 Jan 1999 22:43:00 -0800

Jon:

I think that you are actually contradicting yourself between the first 
statement "I would vote to just use the information in the last one 
recieved." and your final statement, "but I don't make use of the 
information in the FARP-REPLY payload."  I think that what you really
are proposing is that any FARP-REPLY received after a FARP-REQ may be used.
This allows a device to take the first one only and discard all others,
while another device may update with every one received, thereby 
effectively accepting the last one received.

************************************************************************
Bill Martin    			email: [[email-masked]]
Sr. Principal Engineer		Phone: (916)-772-3658
Fibre Channel Standards		Fax:   (916)-771-5416
Gadzoox Networks, Inc.
************************************************************************

> -----Original Message-----
> From: Infante, Jon [mailto:[email-masked]]
> Sent: Thursday, January 07, 1999 5:19 PM
> To: [email-masked]; 'Lansing Sloan'
> Subject: RE: How handle multiple replies to an FARP-REQ?
> 
> 
> Lansing,
>

---

From: "Black, David" <[email-masked]>
Date: Sun, 10 Jan 1999 15:18:26 -0500

Recalling the original question:

> configuration error (anyway, probably something was wrong).

I agree with this.  At a minimum, if the requestor receives multiple replies
with different information, this ought to be logged so that the poor
sysadmin
who has to sort this out has some useful clue about where to start.

> For what it's
> respond to the ARP request, then at least two ARP replies occur.

Reasoning by analogy from the Ethernet example, this is a configuration
error,
although the error may be in the automatic rather than the manual portion of
the
configuration.  If multiple ARP responses with different data occur in the
Ethernet case, one of the following two things is going on:

(1) The "forwarding" is a layer 3 IP forwarding action.  In this case,
*neither*
router should have responded to the ARP, and the situation is resolved by
the
originator sending the packet(s) that were responsible for the original ARP
to its default IP gateway for further processing.  One wants to avoid having
the
layer 2 LAN understand the notion of multiple routes at layer 3.

(2) The "forwarding" is a layer 2 LAN or VLAN forwarding action.  In this
case,
the spanning tree algorithm that set up the logical LAN communication
structure
should have told the intermediate nodes (which aren't exactly routers in
this case)
what to do with the ARP.  Specifically, ARP propagation and response obeys
the
spanning tree, so the intermediate nodes forward only to the destinations
that
are logically "reachable" through them, and the ARP responder will be
logically
"behind" at most one of the forwarding nodes (because the spanning tree is a
tree).
[NB: "reachable" and "beyond" in the previous sentence are with respect to
the
current spanning tree, not the overall physical connectivity topology.]

Note that the underlying configuration error (2 routes/paths to same
destination)
is a serious problem, because if this happens to IP packets, the resulting
reordering can cause TCP to stumble (and then users wonder why the network
performance
stinks).

> What should the ARP requester do upon receiving multiple replies?

If the replies have the same information, nothing much ... somebody
somewhere probably
got confused and duplicated the reply in transit.  Support should be
available
to log this as an error (for performance tuning/debugging if nothing else),
but this
logging probably ought to be configurable (e.g., to avoid flooding the log
when there's
a known buggy device that can't be replaced right now).

If the replies have different information, I think the error logging is
mandatory
(something is broken and needs to be fixed, preferably sooner rather than
later).  The
requester ought to pick one of the responses and use it, but since this is
an error case,
I'm not sure that it's important to specify which one is chosen.

--David

David L. Black, Senior Technologist
EMC Corporation, 35 Parkwood Drive, Hopkinton, MA  01748
+1 (508) 435-1000 x76140, FAX: +1 (508) 497-6909
[email-masked]