[ovs-discuss] not seeing return packets from IN_PORT

Ben Pfaff blp at nicira.com
Tue Jan 10 18:39:04 UTC 2012


If you apply the following series:
http://openvswitch.org/pipermail/dev/2011-December/013943.html
http://openvswitch.org/pipermail/dev/2011-December/013944.html
http://openvswitch.org/pipermail/dev/2011-December/013945.html
and then turn up the log level for the "dpif" module, then we should
be able to better see what's happening to those packets, since they're
too widely spaced to hit in the flow table.

On Tue, Jan 10, 2012 at 01:32:00PM -0500, Aaron Rosen wrote:
> These packets are the normal SYN packets to initial a TCP connection.
> 
> The weird thing though is if I use this flow_mod it works fine:  (using a
> fake ip/mac as the response).
> 
>  cookie=0x0, duration=6.622s, table=0, n_packets=93776, n_bytes=6191149,
> idle_timeout=100,priority=65535,tcp,in_port=65534,vlan_tci=0x0000,dl_src=00:1f:29:32:92:4d,dl_dst=00:1b:21:6a:85:88,nw_src=10.0.0.10,nw_dst=10.0.0.13,nw_tos=0,tp_src=53641,tp_dst=5004
> actions=mod_dl_src:66:f3:43:38:f4:a2,mod_dl_dst:00:1f:29:32:92:4d,mod_nw_src:10.0.0.100,mod_nw_dst:10.0.0.10,mod_tp_dst:9877,IN_PORT
> 
> 
> Then on return packets for that I have this: (so the client is tricked in
> to connecting to 10.0.0.100 which is really it's self. Though I don't want
> to have to rely on having an extra IP to do this.
> 
>  cookie=0x0, duration=6.622s, table=0, n_packets=143378, n_bytes=158529948,
> idle_timeout=100,tcp,in_port=65534,dl_src=00:1f:29:32:92:4d,nw_src=10.0.0.10,nw_dst=10.0.0.100,tp_src=9877,tp_dst=53641
> actions=mod_dl_src:00:1b:21:6a:85:88,mod_dl_dst:00:1f:29:32:92:4d,mod_nw_dst:10.0.0.10,mod_nw_src:10.0.0.13,mod_tp_src:5004,IN_PORT
> 
> 
> 
> On Tue, Jan 10, 2012 at 1:21 PM, Ben Pfaff <blp at nicira.com> wrote:
> 
> > The datapath actions look like what I'd expect to see.  I'd expect the
> > modified packets to show up in tcpdump.  I see that there are only two
> > such packets over an 18-second period.  Can you send them faster?  It
> > looks like the second packet didn't get caught by the kernel flow
> > ("used:never") so both packets were actually processed in userspace;
> > perhaps there is a bug in the userspace processing, which is currently
> > in transition.
> >
> > On Tue, Jan 10, 2012 at 01:12:59PM -0500, Aaron Rosen wrote:
> > > pg46 openvswitch # ovs-ofctl dump-flows dp0
> > > NXST_FLOW reply (xid=0x4):
> > > # Removed other flows here for paste...
> > >  cookie=0x0, duration=18.467s, table=0, n_packets=2, n_bytes=148,
> > >
> > idle_timeout=100,priority=65535,tcp,in_port=65534,vlan_tci=0x0000,dl_src=00:1f:29:32:92:4d,dl_dst=00:1b:21:6a:85:88,nw_src=10.0.0.10,nw_dst=10.0.0.13,nw_tos=0,tp_src=58209,tp_dst=5004
> > >
> > actions=mod_dl_src:00:1f:29:32:92:4d,mod_dl_dst:00:1f:29:32:92:4d,mod_nw_src:10.0.0.10,mod_nw_dst:10.0.0.10,mod_tp_dst:9877,IN_PORT
> > > *
> > > *
> > > pg46 openvswitch # ovs-dpctl dump-flows dp0
> > >
> > in_port(0),eth(src=00:1f:29:32:92:4d,dst=00:1b:21:6a:85:88),eth_type(0x0800),ipv4(src=10.0.0.10,dst=10.0.0.13,proto=6,tos=0,ttl=64,frag=no),tcp(src=58209,dst=5004),
> > > packets:0, bytes:0, used:never,
> > >
> > actions:set(eth(src=00:1f:29:32:92:4d,dst=00:1f:29:32:92:4d)),set(ipv4(src=10.0.0.10,dst=10.0.0.10,proto=6,tos=0,ttl=64,frag=no)),set(tcp(src=58209,dst=9877)),0
> > >
> > >
> > > pg46 openvswitch # ovs-appctl -t ovs-vswitchd  ofproto/trace dp0
> > >
> > 'in_port(0),eth(src=00:1f:29:32:92:4d,dst=00:1b:21:6a:85:88),eth_type(0x0800),ipv4(src=10.0.0.10,dst=10.0.0.13,proto=6,tos=0,ttl=64,frag=no),tcp(src=58209,dst=5004)'
> > > Flow: priority0:tunnel0:in_portfffe:tci(0)
> > > mac00:1f:29:32:92:4d->00:1b:21:6a:85:88 type0800 proto6 tos0 ttl64
> > > ip10.0.0.10->10.0.0.13 port58209->5004
> > > Rule: table=0 cookie=0
> > >
> > priority=65535,tcp,in_port=65534,vlan_tci=0x0000,dl_src=00:1f:29:32:92:4d,dl_dst=00:1b:21:6a:85:88,nw_src=10.0.0.10,nw_dst=10.0.0.13,nw_tos=0,tp_src=58209,tp_dst=5004
> > > OpenFlow
> > >
> > actions=mod_dl_src:00:1f:29:32:92:4d,mod_dl_dst:00:1f:29:32:92:4d,mod_nw_src:10.0.0.10,mod_nw_dst:10.0.0.10,mod_tp_dst:9877,IN_PORT
> > >
> > > Final flow: priority0:tunnel0:in_portfffe:tci(0)
> > > mac00:1f:29:32:92:4d->00:1f:29:32:92:4d type0800 proto6 tos0 ttl64
> > > ip10.0.0.10->10.0.0.10 port58209->9877
> > > Datapath actions:
> > >
> > set(eth(src=00:1f:29:32:92:4d,dst=00:1f:29:32:92:4d)),set(ipv4(src=10.0.0.10,dst=10.0.0.10,proto=6,tos=0,ttl=64,frag=no)),set(tcp(src=58209,dst=9877)),0
> > >
> > >
> > > On Tue, Jan 10, 2012 at 12:28 PM, Ben Pfaff <blp at nicira.com> wrote:
> > > > On Tue, Jan 10, 2012 at 12:15:39PM -0500, Aaron Rosen wrote:
> > > >> Hello,
> > > >>
> > > >> I have a quick question about what could be happening to these
> > packets.
> > > >>
> > > >> I start a tcp connection 10.0.0.10 > 10.0.0.13:
> > > >>
> > > >> 12:02:55.961344 00:1f:29:32:92:4d (oui Unknown) > 00:1b:21:6a:85:88
> > > >> (oui Unknown), ethertype IPv4 (0x0800), length 74: 10.0.0.10.50490 >
> > > >> 10.0.0.13.5004: S
> > > >>
> > > >> Then the following flow entry is installed in order to handle this
> > flow:
> > > >>
> > > >> ?cookie=0x0, duration=4.55s, table=0, n_packets=1, n_bytes=74,
> > > >>
> > >
> > idle_timeout=10,priority=65535,tcp,in_port=65534,vlan_tci=0x0000,dl_src=00:1f:29:32:92:4d,dl_dst=00:1b:21:6a:85:88,nw_src=10.0.0.10,nw_dst=10.0.0.13,nw_tos=0,tp_src=50490,tp_dst=5004
> > > >>
> > >
> > actions=mod_dl_src:00:1f:29:32:92:4d,mod_dl_dst:00:1f:29:32:92:4d,mod_nw_src:10.0.0.10,mod_nw_dst:10.0.0.10,mod_tp_dst:9877,IN_PORT
> > > >>
> > > >>
> > > >> Though, I never see these packets come back in on the interface that
> > > >> it went out on.
> > > >
> > > > What does "ovs-appctl ofproto/trace" or "ovs-dpctl dump-flows" show
> > > > happening to the packets?
> > >
> > >
> > >
> > > --
> > > Aaron O. Rosen
> > > Masters Student - Network Communication
> > > 306B Fluor Daniel
> >
> 
> 
> 
> -- 
> Aaron O. Rosen
> Masters Student - Network Communication
> 306B Fluor Daniel



More information about the discuss mailing list