[ovs-discuss] ofctl connection

Sheili Mittal sheili.mittal at nechclst.in
Wed Jan 11 08:05:07 UTC 2012


Hi Justin,

Thanks for your quick reply.
I have already tried ovs-vsctl , connection is working but it is not
giving command for add-flow etc..with all actions so I moved to
ovs-ofctl.
That's why I was asking whether we can work on openflow protocol with
ofctl, I think no.

Thanks & Regards,
Sheili Mittal

-----Original Message-----
From: Justin Pettit [mailto:jpettit at nicira.com] 
Sent: 11 January 2012 12:38
To: Sheili Mittal
Cc: Aaron Rosen; discuss at openvswitch.org
Subject: Re: [ovs-discuss] ofctl connection

You need to tell ovs-vswitchd to listen for incoming OpenFlow
connections.  Try "ovs-vsctl set-controller <bridge> ptcp:"  You should
then be able to remotely connect to that bridge with OpenFlow over TCP.
Note that if you have multiple bridges on the same host, you'll need to
use different IP addresses or ports to distinguish them.

By the way, I noticed an error in the auto-generated description of
"ptcp:" and "pssl:" in the "set-controller" command.  That command is
telling *ovs-vswitchd* to listen for OpenFlow connections, not
ovs-vsctl.  I'll send out a patch later to clean that up.

--Justin


On Jan 10, 2012, at 8:46 PM, Sheili Mittal wrote:

> Hi Aaron,
>  
> Yes this is not related to this mail chain, I just thought if you have
worked with remote machine with ofctl then it would help me.
> This query was for me .
>  
> Can you please tell how you connect switch with local machine by using
ofctl command socket connection like tcp:<ip>:port
> I am getting error for this.
>  
> Regards,
> Sheili
>  
>  
> From: Aaron Rosen [mailto:arosen at clemson.edu] 
> Sent: 11 January 2012 10:09
> To: Sheili Mittal
> Cc: discuss at openvswitch.org
> Subject: Re: [ovs-discuss] not seeing return packets from IN_PORT
>  
> I've never tried it remotely, though this has nothing to do with this
email thread.....
> 
> Aaron
> 
> On Tue, Jan 10, 2012 at 10:46 PM, Sheili Mittal
<sheili.mittal at nechclst.in> wrote:
> Hi Aaron,
>  
> Are you using ovs-ofctl  for the connection.
> When I am using ovs-ofctl show tcp:<ip>:6633
> It shows "Connecton refused"
>  
> Please suggest how to make remote connection with ofctl?
> I tried with loopback address too but the same error coming.
>  
> ovs-ofctl show ptcp:<ip>:6633
> this gives error "protocol family not supported"
>  
> Regards,
> Sheili
>  
> From: discuss-bounces at openvswitch.org
[mailto:discuss-bounces at openvswitch.org] On Behalf Of Aaron Rosen
> Sent: 11 January 2012 07:30
> To: Ben Pfaff
> Cc: discuss at openvswitch.org
> Subject: Re: [ovs-discuss] not seeing return packets from IN_PORT
>  
> Hey Ben, 
>  
> Sorry for some reason this packet seem to be showing up now.. I'm not
quite sure what the deal was before :/ 
>  
>  1f:29:32:92:4d (oui Unknown) > 00:1b:21:6a:85:88 (oui Unknown),
ethertype IPv4 (0x0800), length 74: 10.0.0.10.36985 > 10.0.0.13.5004: S 
>  00:1f:29:32:92:4d (oui Unknown) > 00:1f:29:32:92:4d (oui Unknown),
ethertype IPv4 (0x0800), length 74: 10.0.0.10.36985 > 10.0.0.10.9877: S 
>  
>  
> At this point though I'm curious why the the host 10.0.0.10 doesn't
reply back to it's self with an syn-ack for the syn packet it receive?
(The SYN-ACK isn't coming across the loop back either) . 
>  
> Thanks again for your help, 
> 
> Aaron
>  
> pg46 ~ # netstat -an | grep 9877
> tcp        0      0 0.0.0.0:9877            0.0.0.0:*
LISTEN     
>  
> pg46 ~ # ifconfig dp0
> dp0       Link encap:Ethernet  HWaddr 00:1f:29:32:92:4d  
>           inet addr:10.0.0.10  Bcast:10.0.0.255  Mask:255.255.255.0
>  
>  
>  
>  
> 
> On Tue, Jan 10, 2012 at 7:11 PM, Ben Pfaff <blp at nicira.com> wrote:
> As an experiment, you could start to add "printk"s to the kernel
> module.  That's what I'd do next while debugging the problem.
> 
> On Tue, Jan 10, 2012 at 05:10:38PM -0500, Aaron Rosen wrote:
> > I'm not sure if this helps eliminate anything but I just tried this
in
> > mininet  and the same thing occurs there if dl_src/nw_src ==
> > dl_dst/nw_dst  .
> >
> > Thanks,
> >
> > Aaron
> >
> >
> > #packet that goes in
> > 14:02:47.309736 06:3b:31:b8:d5:a2 (oui Unknown) > ca:05:25:be:fd:70
> > (oui Unknown), ethertype IPv4 (0x0800), length 74: 10.0.0.10.39458 >
> > 10.0.0.11.5004: Flags [S], seq 3794257069, win 5840, options [mss
> > 1460,sackOK,TS val 47077922 ecr 0,nop,wscale 9], length 0
> >
> >
> > #flow_mod
> >   cookie=0, duration_sec=50s, duration_nsec=950000000s, table_id=1,
> > priority=65535, n_packets=1, n_bytes=74,
> >
idle_timeout=100,hard_timeout=0,tcp,in_port=2,dl_vlan=0xffff,dl_vlan_pcp
=0x00,dl_src=06:3b:31:b8:d5:a2,dl_dst=ca:05:25:be:fd:70,nw_src=10.0.0.10
,nw_dst=10.0.0.11,nw_tos=0x00,tp_src=39458,tp_dst=5004,actions=mod_dl_sr
c:06:3b:31:b8:d5:a2,mod_dl_dst:06:3b:31:b8:d5:a2,mod_nw_src:10.0.0.10,mo
d_nw_dst:10.0.0.10,mod_tp_dst:9877,IN_PORT
> >
> >
> > #packet is not returned.
> >
> >
> > On Tue, Jan 10, 2012 at 3:02 PM, Aaron Rosen <arosen at clemson.edu>
wrote:
> > > Here are lines (154-158) from here http://codepad.org/APdmOTGN
(more debug)
> > >
> > > Thanks,
> > >
> > > Aaron
> > >
> > > Jan 10 14:46:07 localhost ovs-vswitchd: 04385|dpif|DBG|system at dp0:
miss
> > > upcall:
> > > Jan 10 14:46:07 localhost ovs-vswitchd:
> > >
in_port(0),eth(src=00:1f:29:32:92:4d,dst=00:1b:21:6a:85:88),eth_type(0x0
800),ipv4(src=10.0.0.10,dst=10.0.0.13,proto=6,tos=0,ttl=64,frag=no),tcp(
src=38710,dst=5004)
> > > Jan 10 14:46:07 localhost ovs-vswitchd: 00:1f:29:32:92:4d >
> > > 00:1b:21:6a:85:88, ethertype IPv4 (0x0800), length 74:
10.0.0.10.38710 >
> > > 10.0.0.13.5004: S 3410511224:3410511224(0) win 14600 <mss
> > > 1460,sackOK,timestamp 9255759 0,nop,wscale 6>
> > > Jan 10 14:46:07 localhost ovs-vswitchd: 04386|dpif|DBG|system at dp0:
execute
> > >
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=38710,dst=
9877)),0
> > > on packet 00:1f:29:32:92:4d > 00:1b:21:6a:85:88, ethertype IPv4
(0x0800),
> > > length 74: 10.0.0.10.38710 > 10.0.0.13.5004: S
3410511224:3410511224(0) win
> > > 14600 <mss 1460,sackOK,timestamp 9255759 0,nop,wscale 6>
> > > Jan 10 14:46:07 localhost ovs-vswitchd: 04387|dpif|DBG|system at dp0:
> > > put[create][modify]
> > >
in_port(0),eth(src=00:1f:29:32:92:4d,dst=00:1b:21:6a:85:88),eth_type(0x0
800),ipv4(src=10.0.0.10,dst=10.0.0.13,proto=6,tos=0,ttl=64,frag=no),tcp(
src=38710,dst=5004),
> > >
actions:set(eth(src=00:1f:29:32:92:4d,dst=00:1f:29:32:92:4d)),set(ipv4(s
rc=10.0.0.10,dst=10.0.0.10,proto=6,tos=0,ttl=64,frag=no)),set(tcp(src=38
710,dst=9877)),0
> > >
> > >
> > >
> > > On Tue, Jan 10, 2012 at 1:39 PM, Ben Pfaff <blp at nicira.com> wrote:
> > >>
> > >> I'd expect such packets to show up in tcpdump in any case.
> > >>
> > >> On Tue, Jan 10, 2012 at 01:35:48PM -0500, Aaron Rosen wrote:
> > >> > I'd be curious what the expected behavior should be if linux
sees a
> > >> > packet
> > >> > arriving on an interface matching it's dl_src/src_ip. (Since
this should
> > >> > have probably gone through lo ).
> > >> >
> > >> > I also enabled log_martians and it's not saying anything about
this.
> > >> >
> > >> > Thanks,
> > >> >
> > >> > Aaron
> > >> >
> > >> > On Tue, Jan 10, 2012 at 1:32 PM, Aaron Rosen
<arosen at clemson.edu> 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(0x0
800),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(s
rc=10.0.0.10,dst=10.0.0.10,proto=6,tos=0,ttl=64,frag=no)),set(tcp(src=58
209,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(0x
0800),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:4
d,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
> > >> > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> > Aaron O. Rosen
> > >> > Masters Student - Network Communication
> > >> > 306B Fluor Daniel
> > >
> > >
> > >
> > >
> > > --
> > > Aaron O. Rosen
> > > Masters Student - Network Communication
> > > 306B Fluor Daniel
> > >
> > >
> >
> >
> >
> > --
> > Aaron O. Rosen
> > Masters Student - Network Communication
> > 306B Fluor Daniel
> 
> 
>  
> -- 
> Aaron O. Rosen
> Masters Student - Network Communication
> 306B Fluor Daniel
> 
> DISCLAIMER: 
>
------------------------------------------------------------------------
----------------------------------------------- 
> The contents of this e-mail and any attachment(s) are confidential and
> intended 
> for the named recipient(s) only.  
> It shall not attach any liability on the originator or NECHCL or its 
> affiliates. Any views or opinions presented in  
> this email are solely those of the author and may not necessarily
reflect the 
> opinions of NECHCL or its affiliates.  
> Any form of reproduction, dissemination, copying, disclosure,
modification, 
> distribution and / or publication of  
> this message without the prior written consent of the author of this
e-mail is 
> strictly prohibited. If you have  
> received this email in error please delete it and notify the sender 
> immediately. . 
>
------------------------------------------------------------------------
-----------------------------------------------
> 
> 
> 
> -- 
> Aaron O. Rosen
> Masters Student - Network Communication
> 306B Fluor Daniel
> 
> 
> DISCLAIMER: 
>
------------------------------------------------------------------------
----------------------------------------------- 
> The contents of this e-mail and any attachment(s) are confidential and
> intended 
> for the named recipient(s) only.  
> It shall not attach any liability on the originator or NECHCL or its 
> affiliates. Any views or opinions presented in  
> this email are solely those of the author and may not necessarily
reflect the 
> opinions of NECHCL or its affiliates.  
> Any form of reproduction, dissemination, copying, disclosure,
modification, 
> distribution and / or publication of  
> this message without the prior written consent of the author of this
e-mail is 
> strictly prohibited. If you have  
> received this email in error please delete it and notify the sender 
> immediately. . 
>
------------------------------------------------------------------------
-----------------------------------------------
> 
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss




DISCLAIMER: 
----------------------------------------------------------------------------------------------------------------------- 
The contents of this e-mail and any attachment(s) are confidential and
intended 
for the named recipient(s) only.  
It shall not attach any liability on the originator or NECHCL or its 
affiliates. Any views or opinions presented in  
this email are solely those of the author and may not necessarily reflect the 
opinions of NECHCL or its affiliates.  
Any form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of  
this message without the prior written consent of the author of this e-mail is 
strictly prohibited. If you have  
received this email in error please delete it and notify the sender 
immediately. . 
-----------------------------------------------------------------------------------------------------------------------



More information about the discuss mailing list