Murphy Thanks for your suggestion and will dig further into it. But I like to get thr right understaning on the behavior of Normal.
When apps wants to install its own flow with 5 tuplets and let this packet be treated by normal switching. Since it does not know what actual output port to send, it may like the forwarding feature do the job. I thought by choosing'Normal' action, the above can be acheived. Looks like it may not work with controler..? So what is the expected behavior when an app installs a flow with action : Normal. When a packet that matches flow fields comes, shouldn't trigger the nromal control packets like arp and learns the right output port? thanks =Senthil ________________________________ From: Murphy McCauley <[email protected]> To: Senthil <[email protected]> Cc: "[email protected]" <[email protected]> Sent: Tuesday, March 26, 2013 2:23 AM Subject: Re: [pox-dev] Issue in the flow installed by POX application Responses inline. On Mar 26, 2013, at 12:00 AM, Senthil wrote: - I have started the pox with l2_learning - pox py forwarding.l2_learning, my_app. > > >- Sent an HTTP packets from VM attached to the switch with dst -port 8000. The >HTTP server in the remote VM responds this request. > Working so far. > > > >- Installed a flow from my_app that matches HTTP Packets with dst-port =8000 >originated from a VM attached to the given switch. > > >The flow installed in the switch ( highlight in RED below): > > > > cookie=0x40, duration=175.959s, table=0, n_packets=114, n_bytes=8436, >idle_age=0, >priority=20000,tcp,nw_src=192.167.10.10,nw_dst=192.167.20.10,tp_dst=8000 >actions=NORMAL > > >My expectation is: > > The installed flow with action NORMAL should switch the packets to follow >the normal switch forwarding. Since all the arp entries are there, it should >find the path using the normal forwarding... > What makes you believe the ARP entries are there? And which "there" do you mean? On the machine that OVS is running on? What about the ARP entry for the client at the web server? Are they correct? Are 192.167.10.10 and 192.167.20.10 on different subnets? If you have been letting l2_learning pass ARPs through as if the machine is sort of an L2 switch (which is what l2_learning does), and now you're trying to forward these "normally" and Linux is trying to act like an L3 router... This use case makes the apps to install its own flow that redirects the packets to meet its own requirements - thus making it as software defined path... > > >What happens after installing this flow : The HTTP packets are not forwarded. > > > > >Please validate if my expectation in behavior is right. You should probably do some debugging with Wireshark to figure out what's going on. Sniff at the web server. Do you see the request? Sniff at the outgoing interface of the host with OVS. Do you see it there? Do you see ARPs for the web server or the client? Are their MAC addresses as they should be? Also, look at the counters of that flow. 114 packets and 8436 bytes. *Something* seems to be going *somewhere*. If not, how to acheive this use case.. I have to install my own flow and use the normal switching to carry the packet. >With this simple flow with NORMAL action, I can stats specific to this flow >now. And later I can sleectively drop or redirct it. Why do you need to use normal? Why not just modify l2_learning to drop or not drop or redirect when it install flows? The mac_blocker app shows an example of blocking, though there are even easier and more direct ways of doing it (by just modifying l2_learning directly). -- Murphy
