[ovs-dev] in-band.c: fix for ARP requests and replies for in-band mode

[andreas at brinner.de]

When trying to cascadate an OpenFlow switch behind an Open vSwitch
like this:
   OF Switch <-> Open vSwitch <-> OF Controller
with in-band controll mode the OF Switch is unable to obtain the
controllers MAC address to setup a connection.

To find out the controller's MAC address the switch has to send an
ARP request to and receive an ARP reply from the controller.
That means for the Open vSwitch in between it has to forward an ARP
request from the switch to the controller (dst mac = MAC of controller,
type=ARP request) and an ARP reply from the controller (src mac = MAC of
controller, type=ARP reply).

In the DESIGN guide the rules (d) and (e) are specified as follows:
   (d) ARP replies to the next hop's MAC address.
   (e) ARP requests from the next hop's MAC address.

In this case "the next hop" is the controller (or maybe a gateway
inbetween). That means, rules (d) and (e) are setting up the rules just
the wrong way around! With this rules the OpenFlow switch
can't figure out the controller's MAC address and thus may never
contact it. The rules would have to be:
   (d) ARP _requests_ to the next hop's MAC address.
   (e) ARP _replies_ from the next hop's MAC address.

Signed-off-by: Andreas Brinner <andreas at brinner.de>

>From 41ba828422cc9201620a3b0dc2847c5f09da89c5 Mon Sep 17 00:00:00 2001
From: Andreas Brinner <andreas at brinner.de>
Date: Wed, 10 Jul 2013 15:02:24 +0200
Subject: [PATCH] Fixes ARP requests and replies for in-band mode

Rules (d) and (e) for in-band control need to allow ARP requests to and
ARP replies from the next hop. Only then an OpenFlow switch on the other
side of the Open vSwitch can find out the controller's MAC address.
---
 DESIGN            |    4 ++--
 ofproto/in-band.c |    8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/DESIGN b/DESIGN
index d36b025..adbe056 100644
--- a/DESIGN
+++ b/DESIGN
@@ -716,8 +716,8 @@ In-band also sets up the following rules for each
unique next-hop MAC
 address for the remotes' IPs (the "next hop" is either the remote
 itself, if it is on a local subnet, or the gateway to reach the remote):

-   (d) ARP replies to the next hop's MAC address.
-   (e) ARP requests from the next hop's MAC address.
+   (d) ARP requests to the next hop's MAC address.
+   (e) ARP replies from the next hop's MAC address.

 In-band also sets up the following rules for each unique remote IP address:

diff --git a/ofproto/in-band.c b/ofproto/in-band.c
index 265dcb2..a880cc5 100644
--- a/ofproto/in-band.c
+++ b/ofproto/in-band.c
@@ -301,18 +301,18 @@ update_rules(struct in_band *ib)
             continue;
         }

-        /* (d) Allow ARP replies to the next hop's MAC address. */
+        /* (d) Allow ARP requests to the next hop's MAC address. */
         match_init_catchall(&match);
         match_set_dl_type(&match, htons(ETH_TYPE_ARP));
         match_set_dl_dst(&match, remote_mac);
-        match_set_nw_proto(&match, ARP_OP_REPLY);
+        match_set_nw_proto(&match, ARP_OP_REQUEST);
         add_rule(ib, &match, IBR_TO_NEXT_HOP_ARP);

-        /* (e) Allow ARP requests from the next hop's MAC address. */
+        /* (e) Allow ARP replies from the next hop's MAC address. */
         match_init_catchall(&match);
         match_set_dl_type(&match, htons(ETH_TYPE_ARP));
         match_set_dl_src(&match, remote_mac);
-        match_set_nw_proto(&match, ARP_OP_REQUEST);
+        match_set_nw_proto(&match, ARP_OP_REPLY);
         add_rule(ib, &match, IBR_FROM_NEXT_HOP_ARP);
     }

-- 
1.7.10.4