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

Reply via email to