[ovs-discuss] Behaving differently with same flow but in different methods.

[ananthan]

Thanks for your reply,but now things are more complicated,please go through
this,i have also added tcpdump output.

i deleted flow with priority 303 and 304 ie now no flow with *nw_dst* and *
dl_dst* for ARP and IP.
and only using these 3 rules and now packets are going in both
direction,but how?.I wonder how can packet enter with out *nw_dst* and *
dl_dst* constraint.
*
*
*Rules for Vm:*

ovs-ofctl add-flow xenbr0 "in_port=3 priority=301 dl_type=0x0800
nw_src=115.x.x.121 dl_src=ea:7a:55:f2:66:ef idle_timeout=0 action=normal"

ovs-ofctl add-flow xenbr0 "in_port=3 priority=302 dl_type=0x0806
nw_src=115.x.x.121  dl_src=ea:7a:55:f2:66:ef idle_timeout=0 action=normal"

ovs-ofctl add-flow xenbr0 "in_port=3 priority=299 idle_timeout=0
action=drop"

*Default Flow:*
cookie=0x0, duration=693.512s, table_id=0, n_packets=14779,
n_bytes=4190181, priority=0 actions=NORMAL

Can you please tell me in the above case as i have only allowed outgoing IP
and ARP packets, using *nw_src* and *dl_src* how can IP packets and ARP
come in with out using *nw_dst* and *dl_dst*.As it should be dropped since
there is no explicit rule to exclude that from drop with flow priority 299.
In Method1 that is with global drop, i didnt get any reply with out
allowing incoming IP and ARP with *nw_dst* and *dl_dst*.This is against my
concept of openvswitch working.

As per my understanding since we have drop all on *in_port* 3 priority
299,both incoming and outgoing packets will be blocked,so for packets to go
through we should allow each in and out,so for outgoing ARP and IP packets
to go with out drop at priority 299,create a flow with higher priority than
299 with *dl_src* and *nw_src *as that of vm.And for incoming packet to
pass through priority 299, create flow with higher priority than 299 with *
dl_dst* and *nw_dst* as that of vm.In case of Method1 i think my
understanding is correct as i verified each rule with tcpdump and for
packets to go in and out 4 rules are required involving *dl_src*,*
dl_dst,nw_src*,*nw_dst.*But here in case of *in_port* based drop rule my
understanding failed completely even with drop flow for all *in_port.* Packet
flow is working fine with out *nw_dst* and *dl_dst*.

Also i have noticed that in case of global drop that is with out using *
in_port*
ovs-ofctl del-flows xenbr0
ovs-ofctl add-flow xenbr0 "priority=0 action=drop"
*#Excluding host MAC*
ovs-ofctl add-flow xenbr0 "dl_src=84:2B:2B:0A:78:67 priority=1
action=normal"
ovs-ofctl add-flow xenbr0 "dl_dst=84:2B:2B:0A:78:67 priority=1
action=normal"


On tcpdump of vm i am not able to see any icmp echo request,its only
showing

*11:27:40.007480 ARP, Request who-has 115.x.x.1 tell 115.x.x.121, length 28*

but in case of

ovs-ofctl add-flow xenbr0 "in_port=3 priority=299 idle_timeout=0
action=drop"

in tcpdump i am able to see
*11:37:41.755158 ARP, Request who-has 115.X.X.1 tell 115.X.X.121, length 46*
*11:37:41.986261 IP 115.X.X.71 > 115.X.X.121: ICMP echo request, id 3405,
seq 1914, length 64*

Why is DROP rule behaving differently when used in different way?.



-----------------------------------------------------------------

You're matching on the destination port being 80, which will only
block one direction of the flow. This is enough to prevent traffic
from flowing but my guess is that when you added the input port
constraint it was for traffic originating in the other direction. As a
result, nothing was blocked





On Wed, May 15, 2013 at 4:23 AM, Jesse Gross <jesse at nicira.com> wrote:

> On Tue, May 14, 2013 at 7:26 AM, ananthan <ananthannair935 at gmail.com>
> wrote:
> > But in case of Method2:
> > My understanding became completely wrong,even though ip stealing
> prevention
> > worked no other things worked.And to make situation worse traffic to vm
> > worked with out  rules priority 304 and 303.how can an additional
>  in_port
> > make this much difference.Can some one please explain the problem.
>
> You're matching on the destination port being 80, which will only
> block one direction of the flow. This is enough to prevent traffic
> from flowing but my guess is that when you added the input port
> constraint it was for traffic originating in the other direction. As a
> result, nothing was blocked.
>
> > Also When i added "priority=299,in_port=3 actions=drop" i was able to see
> > ping echo request on tcpdump output.Is it normal as tcpdump capture that
> > before this flow.
>
> Yes, that is normal.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20130515/4fa93e02/attachment.html>