[ovs-discuss] OVS sends ARP request to the controller also broadcasts ARP request

[Sh j]

Thank you very much for your helpful explanation.


I have another question.

When a ping packet is generated from node1 to node3 (the mentioned
topology), in the next step, OVS1 is supposed to check its own flow table
to see if there are any flow rules for this ICMP(IP) packet, and since the
default flow rules installed by the controller tells that send the packet
to the controller, the next packet_in message should include ICMP message.

But instead of that OVS1 forwards ARP request in the packet_in message. I
am confused about this part. When I trace the packet, the action is sending
to the controller. But somehow OVS1 skips this ICMP messages and goes to
the ARP.  I suppose sending ARP happens when nodes know they are in one-hop
neighbors. But in this case, nodes do not know the flow rules (routing path
and next hop) and have to send packet_in (ICMP) to the controller. I do not
know why these ARP are generating.

I am using CORE emulator to emulate this network. So I think I should check
the Linux Kernel.  Could you let me know if you have any suggestion about
the configuration?

Thank you

On Tue, Apr 10, 2018 at 6:27 PM, Ben Pfaff <blp at ovn.org> wrote:

> I think there's some confusion here.  OVS doesn't originate ARP
> requests.  It only forwards ARP requests generated by some other
> software, such as the Linux kernel.  If you don't want OVS to pass ARP
> requests to the controller via packet_in, then you can either configure
> the software that generates them not to do so, or you can configure OVS
> (via the controller) to forward them without generating a packet_in.
>
> On Tue, Apr 10, 2018 at 05:54:36PM -0400, Sh j wrote:
> > Thank you. I fixed the problem through the flow table installed by ONOS
> and
> > I do not see ARP broadcasts anymore.
> >
> >
> >
> >
> > I have another question about packet_in messages to the controller.
> Before
> > that, I will explain about my topology. I asked related questions before
> > but I still have a problem.
> >
> >
> > Usually, in the topology, OVS connected to hosts and they help hosts to
> > communicate with each other. I prefer not to have any host and all nodes
> in
> > my network acts as forwarding elements (running OVS) (especially in case
> of
> > wireless networks, it is easier to add mobility to nodes without hosts).
> >
> > After having this topology (OVS1--OVS2---OVS3), with the following
> > configuration:
> >
> > OVS1(eth0) ------- (eth0)OVS2
> >
> > ovs-vsctl add-br brx
> > ovs-vsctl add-port brx ethx
> > ip addr flush dev ethx
> > ip addr add 10.0.0.x/16 dev brx
> > ip link set brx up
> >
> >
> > when 10.0.0.1 (br1) pings 10.0.0.2(br2), node1 sends a packet_in
> > message(ICMP) to the controller(ONOS).
> >
> > But, when 10.0.0.1(br1) pings 10.0.0.3(br3), node1 sends a packet_in
> > message(ARP) to the controller.
> > While I do not except this ARP request to the controller. I am expecting
> > ICMP message as a packet_in to the controller in the first place, after
> > that based on the packet_out, node1 is supposed to send the ARP request
> for
> > the next hop. I do not know why OVS sends this ARP requests.
> >
> >  In this case, which part of the network needs to change? should I change
> > the configuration of OVS and how?
> >
> > Thank you in advance
> >
> >
> >
> >
> > On Tue, Apr 10, 2018 at 4:27 PM, Ben Pfaff <blp at ovn.org> wrote:
> >
> > > On Mon, Apr 09, 2018 at 01:09:37PM -0400, Sh j wrote:
> > > > Hello,
> > > >
> > > > I have the following topology:
> > > >
> > > > host1 ----openvswitch1 ----openvswitch2----host2
> > > >
> > > > and both openvswitches are connected to the ONOS controller.
> > > >
> > > > The problem is that when host1 ping host2, openvswitch1 sends the ARP
> > > > request as a packet_in to the controller, Also, it broadcasts the ARP
> > > > request so that openvswitch2 receives this broadcast.
> > > >
> > > > Do you have any suggestion how to avoid this ARP broadcast?
> > >
> > > I would guess that ONOS can control this behavior through the flow
> > > table.
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20180414/578d6915/attachment-0001.html>