The "ovs-vsctl set-controller" command is telling ovs-vswitchd to listen for OpenFlow connections. You would then use ovs-ofctl, which speak OpenFlow (ovs-vsctl does not), to connect to the OpenFlow port you just told ovs-vswitchd to listen on.
--Justin On Jan 11, 2012, at 12:05 AM, Sheili Mittal wrote: > 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:[email protected]] > Sent: 11 January 2012 12:38 > To: Sheili Mittal > Cc: Aaron Rosen; [email protected] > 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:[email protected]] >> Sent: 11 January 2012 10:09 >> To: Sheili Mittal >> Cc: [email protected] >> 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 > <[email protected]> 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: [email protected] > [mailto:[email protected]] On Behalf Of Aaron Rosen >> Sent: 11 January 2012 07:30 >> To: Ben Pfaff >> Cc: [email protected] >> 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 <[email protected]> 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 <[email protected]> > 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@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@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@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 <[email protected]> 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 > <[email protected]> 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 <[email protected]> > 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 > <[email protected]> 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 >> [email protected] >> 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. . > ----------------------------------------------------------------------------------------------------------------------- _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
