[ovs-discuss] OVS-CONTROLLER(Faucet) what happens in a simple ping?

O'Reilly, Darragh darragh.oreilly at hpe.com
Wed May 23 11:03:28 UTC 2018


I’m not a Faucet expert. Did you see this tutorial? http://docs.openvswitch.org/en/latest/tutorials/faucet/<http://docs.openvswitch.org/en/latest/tutorials/faucet/#triggering-mac-learning> . Also the source https://github.com/faucetsdn/faucet/blob/master/faucet/valve.py



From: ovs-discuss-bounces at openvswitch.org [mailto:ovs-discuss-bounces at openvswitch.org] On Behalf Of Adrián a
Sent: 21 May 2018 13:37
To: ovs-discuss at openvswitch.org
Subject: [ovs-discuss] OVS-CONTROLLER(Faucet) what happens in a simple ping?


Hello everyone,



I am currently making my bachelor’s final project (networking engineering) about the running of OVS (Open vSwitch) and the controller “Faucet”. I have read lots of related information, including that included in Open vSwitch website. However, and aiming to learn MAC and IP, I still do not fully understand the interaction between: OpenFlow tables, Faucet and Switch.



Let us suppose the most basic scenario:



     #############
     #  Faucet       #
     #############
             | 192.168.1.3
             |
             |
             |    ################
              ----#        ovs          #
192.168.1.2 ################
                       |p1        |p2
                       |           |
                   ----            ---
                   |                  |
              ######          ######
              #  u1  #          #  u2 #
              ######          ######
            10.100.1.1      10.100.1.2
          LXC:Ubuntu      LXC:Ubuntu





Two hosts u1 and u2, in LXC containers running UBUNTU:16.04. The hosts belong to the same network, the controller is in an external physical machine. The connexion between these two elements is correct. However, the problem arises when analysing (through “Wiseshark”) the packages appearing at both the ports and the controller, when making a simple “ping” between u1 and u2.



@u1: ping 10.100.1.2



In Wireshark, the following temporal sequence is obtained:


- time 1: u1 send ARP_request: How is u2?



- time 2: ovs get ARP_request por el puerto 1, consulta su tabla OpenFlow y realiza un broadcast ARP_request.



- time 3: u2 get ARP_request, create and send ARP_reply: i am u2.



- time 4: ovs get the packet ARP_reply and forward to port p1



- time 5: u1 get ARP_reply and he learns the MAC address. Now send IP packet.



- time 4: u1 send ICMP: echo_request to u2



- time 5: ovs forward packet to port p2 (previously he has learned the position of u2)



- time 6: u2 get the packet and send ICMP: echo_reply to u1



- time 7: ovs forward the packet to p2



- time 8: u1 get the packet ICMP: echo_reply and ping is done.



- time 9: ovs send to controller ARP_request (OFPT_PACKET_IN)



- time 10: ovs send to controller ARP_request (OFPT_PACKET_IN)



- time 11: ovs send to controller ICMP: echo_request (OFPT_PACKET_IN)



- time 12: ovs sent to controller ICMP: echo_reply (OFPT_PACKET_IN)



- time 13: Controller send OFPT__FLOW_MOD to ovs



- time 14: Controller send OFPT__FLOW_MOD to ovs



- time 15: Controller send OFPT__FLOW_MOD to ovs

 The utility for tracing ovs-appctl ofproto/trace dont make effect on ovs openflow table...

How is possible that the Switch re-directs the packages without consulting the controller?

Is the Switch capable to modify its Openflow tables by itself? What would be the correct steps when pinging between two machines?

In my opinion, Wireshark does not capture the packages at the actual moment and disorganises them.




Find attached a link to .doc file where I explain all better. (sorry for my english)

"https://docs.google.com/document/d/1VRy2EBkFtYKITcCZuSn5Gq5jv75OQcYaoKXwh-NK6zI/edit?usp=sharing"

Thanks to everyone for the help,

Cheers,

Adrian







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20180523/34537344/attachment-0001.html>


More information about the discuss mailing list