[ovs-discuss] How can this work with out _dst ?

Tue May 21 07:35:58 UTC 2013

All incoming packets should be dropped as there is no rule for incoming
traffic.But packets are going in and out.

I tried tcpdump to troubleshoot:
*
*
*1.DROP all in_port 2*
in_port=2 priority=299 action=drop"    tcpdump :As expected no
incoming/outgoing packets.
*
*
*2.Allowed incoming ARP *
in_port=2 priority=303 dl_type=0x0806 dl_dst=6a:3b:ad:97:c9:8a
nw_dst=5.x.x.125 idle_timeout=0 action=normal
tcpdump: As expected tcpdump shows ARP request from other vms.
*
*
*3.Allowed incoming IP packets *
in_port=2 priority=304 dl_type=0x0800 nw_dst=5.x.x.125
 dl_dst=6a:3b:ad:97:c9:8a action=normal"
tcpdump:As expected shows icmp echo request .

Above 3 as expected:but when

*1.DROP all in_port 2*
in_port=2 priority=299 action=drop"

*2.Allowed Outgoing ARP*

"in_port=2 priority=301 dl_type=0x0800 nw_src=5.x.x.125
dl_src=6a:3b:ad:97:c9:8a action=normal"

*3.Allowed outgoing packets*
"in_port=2 priority=302 dl_type=0x0806 nw_src=5.x.x.125
 dl_src=6a:3b:ad:97:c9:8a action=normal"

Both incoming and outgoing worked.

Regards,
kev

On Tue, May 21, 2013 at 11:30 AM, Ben Pfaff <blp at nicira.com> wrote:

> Same procedure, except that you have to instead figure out where you
> think it should be dropped and was not.
>
> On Tue, May 21, 2013 at 11:26:55AM +0530, kevin parker wrote:
> > Thank You Ben for the detailed description,but my issue is everything is
> > working :) .I hope it shouldn't work so that i can troubleshoot the
> issue.
> > The only thing i am not able to understand is how packets are reaching my
> > vm with out *nw_dst* and *dl_dst*.
> >
> >
> > On Mon, May 20, 2013 at 11:47 PM, Ben Pfaff <blp at nicira.com> wrote:
> >
> > > On Sat, May 18, 2013 at 02:47:50PM +0530, kevin parker wrote:
> > > > Can some one please say how this work?
> > > >
> > > >
> > >
> 1.priority=400,arp,in_port=2,dl_src=6a:3b:ad:97:c9:8a,nw_src=5.x.x.12,arp_sha=6a:3b:ad:97:c9:8a
> > > > actions=NORMAL
> > > >
> > > > 2.priority=399,ip,in_port=2,dl_src=6a:3b:ad:97:c9:8a,nw_src=5.x.x.12
> > > > actions=NORMAL
> > > >
> > > > 3.priority=398,in_port=2 actions=drop
> > > >
> > > > 4.priority=0 actions=NORMAL
> > > >
> > > > i have only enabled outgoing IP and ARP,but still i am able to
> connect
> > > > through dis.How can packet go in with out *nw_dst *and *dl_dst*.?
> > >
> > > It's hard for us to guess what you expect to work or not work.
> > >
> > > This procedure described in the FAQ might help you figure out what's
> > > going on or at least to clarify your question.
> > >
> > > Q: I have a sophisticated network setup involving Open vSwitch, VMs or
> > >    multiple hosts, and other components.  The behavior isn't what I
> > >    expect.  Help!
> > >
> > > A: To debug network behavior problems, trace the path of a packet,
> > >    hop-by-hop, from its origin in one host to a remote host.  If
> > >    that's correct, then trace the path of the response packet back to
> > >    the origin.
> > >
> > >    Usually a simple ICMP echo request and reply ("ping") packet is
> > >    good enough.  Start by initiating an ongoing "ping" from the origin
> > >    host to a remote host.  If you are tracking down a connectivity
> > >    problem, the "ping" will not display any successful output, but
> > >    packets are still being sent.  (In this case the packets being sent
> > >    are likely ARP rather than ICMP.)
> > >
> > >    Tools available for tracing include the following:
> > >
> > >        - "tcpdump" and "wireshark" for observing hops across network
> > >          devices, such as Open vSwitch internal devices and physical
> > >          wires.
> > >
> > >        - "ovs-appctl dpif/dump-flows <br>" in Open vSwitch 1.10 and
> > >          later or "ovs-dpctl dump-flows <br>" in earlier versions.
> > >          These tools allow one to observe the actions being taken on
> > >          packets in ongoing flows.
> > >
> > >          See ovs-vswitchd(8) for "ovs-appctl dpif/dump-flows"
> > >          documentation, ovs-dpctl(8) for "ovs-dpctl dump-flows"
> > >          documentation, and "Why are there so many different ways to
> > >          dump flows?" above for some background.
> > >
> > >        - "ovs-appctl ofproto/trace" to observe the logic behind how
> > >          ovs-vswitchd treats packets.  See ovs-vswitchd(8) for
> > >          documentation.  You can out more details about a given flow
> > >          that "ovs-dpctl dump-flows" displays, by cutting and pasting
> > >          a flow from the output into an "ovs-appctl ofproto/trace"
> > >          command.
> > >
> > >        - SPAN, RSPAN, and ERSPAN features of physical switches, to
> > >          observe what goes on at these physical hops.
> > >
> > >    Starting at the origin of a given packet, observe the packet at
> > >    each hop in turn.  For example, in one plausible scenario, you
> > >    might:
> > >
> > >        1. "tcpdump" the "eth" interface through which an ARP egresses
> > >           a VM, from inside the VM.
> > >
> > >        2. "tcpdump" the "vif" or "tap" interface through which the ARP
> > >           ingresses the host machine.
> > >
> > >        3. Use "ovs-dpctl dump-flows" to spot the ARP flow and observe
> > >           the host interface through which the ARP egresses the
> > >           physical machine.  You may need to use "ovs-dpctl show" to
> > >           interpret the port numbers.  If the output seems surprising,
> > >           you can use "ovs-appctl ofproto/trace" to observe details of
> > >           how ovs-vswitchd determined the actions in the "ovs-dpctl
> > >           dump-flows" output.
> > >
> > >        4. "tcpdump" the "eth" interface through which the ARP egresses
> > >           the physical machine.
> > >
> > >        5. "tcpdump" the "eth" interface through which the ARP
> > >           ingresses the physical machine, at the remote host that
> > >           receives the ARP.
> > >
> > >        6. Use "ovs-dpctl dump-flows" to spot the ARP flow on the
> > >           remote host that receives the ARP and observe the VM "vif"
> > >           or "tap" interface to which the flow is directed.  Again,
> > >           "ovs-dpctl show" and "ovs-appctl ofproto/trace" might help.
> > >
> > >        7. "tcpdump" the "vif" or "tap" interface to which the ARP is
> > >           directed.
> > >
> > >        8. "tcpdump" the "eth" interface through which the ARP
> > >           ingresses a VM, from inside the VM.
> > >
> > >    It is likely that during one of these steps you will figure out the
> > >    problem.  If not, then follow the ARP reply back to the origin, in
> > >    reverse.
> > >
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20130521/3fb99864/attachment.html>