The problem is that OVS first forwards ARP request(packet_in) to the controller and all packet_in messages include (ARP). it seems that node is waiting for the ARP reply and then it will send ICMP to the controller.
But I think in the mentioned topology, the first packet_in must include ICMP and then the controller must install rules via flow_mod, then since OVS has the flow rules and the next hop, it will broadcast ARP to get the MAC of next hop. On Mon, Apr 16, 2018 at 2:28 PM, Ben Pfaff <b...@ovn.org> wrote: > The way you describe the problem confuses me. As I read your > description, when OVS processes an ICMP packet, it forwards an ARP > packet to the controller. OVS processes one packet at a time in an > almost-stateless way, so this is not really possible: as OVS processing > an ICMP packet, it only chooses how to deal with that ICMP packet; it > cannot easily influence the processing of ARP packets. > > On Sat, Apr 14, 2018 at 01:50:12PM -0400, Sh j wrote: > > 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 <b...@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 <b...@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. > > > > > > > > >
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
