[ovs-discuss] ofctl connection

Sheili Mittal sheili.mittal at nechclst.in
Wed Jan 11 10:09:30 UTC 2012


Hi Justin,

Sorry for wrong order of arguments with ptcp.
I have tried following but not working yet:-

ovs-vsctl set-controller br0 ptcp:6633:10.0.3.92

and on other machine
ovs-ofctl add-flow tcp:10.0.3.92:6633 "nw_src=10.0.0.0 actions=output:2"
error:- no route to host

I am able to ping 10.0.3.79 by 10.0.3.92 and vive-versa

I have tried this command also but result same :(
ovs-vsctl set-controller br0 ptcp:6633:
ovs-vsctl set-controller br0 ptcp:6633:127.0.0.1

Thanks & Regards,
Sheili 

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

Use "tcp:" on the ovs-ofctl commands, not "ptcp:".  Don't specify an IP address for the "ptcp:" argument in ovs-vsctl (or at least specify a local IP address and put the arguments in the right order).  If you continue to have problems, please look at the man pages to make sure the arguments look sane first.

--Justin


On Jan 11, 2012, at 1:26 AM, Sheili Mittal wrote:

> Hi Justin,
> 
> I tried with following steps but its not working :( bad luck!
> 
> I have 2 machines ( 10.0.3.92 and 10.0.3.79) having OVS installed according to INSTALL.LINUX, vswitchd daemon is running and pointing to database.
> 
> Giving following command on 10.0.3.92:-
> ovs-vsctl set-controller br0 ptcp:10.0.3.79:6633
> command successful
> 
> Giving following command on 10.0.3.79:-
> ovs-ofctl show ptcp:10.0.3.92:6633
> connecting to ptcp:10.0.3.92:6633 (Connection refused) 
> 
> ovs-ofctl add-flow ptcp:10.0.3.92:6633 nw_src=10.0.0.0 actions=output:2
>> l: connecting to ptcp:10.0.3.92:6633 (Connection refused)
> 
> 
> Please correct me where I am wrong in this connection.
> 
> Regards,
> Sheili
> 
> -----Original Message-----
> From: Justin Pettit [mailto:jpettit at nicira.com] 
> Sent: 11 January 2012 14:35
> Cc: Aaron Rosen; discuss at openvswitch.org
> Subject: Re: [ovs-discuss] ofctl connection
> 
> References: <CADGEzusznWntLSkMKfFYABL4sxqfK=TCJxukYKKEwEÆfjg at mail.gmail.com><20120110172854.GA9823 at nicira.com><CADGEzusmKgesibYwswJu3T7Hn8r1pjAjWiGcLigGQQ7R3i4R-w at mail.gmail.com><20120110182130.GE9823 at nicira.com><CADGEzus0uhF-kFfc7zdJJCc8ihaBt1Bn30WdzDwDzS6OpnJP+g at mail.gmail.com><CADGEzusaHR14D_t=hUjY+DKwx313BObhK_fVyrFjDH3KUR9Q at mail.gmail.com><20120110183929.GH9823 at nicira.com><CADGEzus2OaiPfbW6W3rM9OSNSLmw0qjTXAvQANxywAOJe_17Eg at mail.gmail.com><CADGEzutHPvRPA_UDEQ+vfk7Qp+Ys3au49NNTDJS6WLdXw11+Ng at mail.gmail.com><20120111001133.GG32137 at nicira.com><CADGEzuuy9WTwZMZeYBy68zUCj4M-Oi3RRRhnMSdZ-fYKJih_+A at mail.gmail.com><0A8CFEC45B7F4C419F7543867C47442307A6D35B at mailserver.nechclst.in> <CADGEzuvmCwMLhniV134gpo2+STWG4i7TDPJ8HcWb+Zz0vYO0=mail.gmail.com> <0A8CFEC45B7F4C419F7543867C47442307A6D42C at mailserver.nechclst.in> <262A6426-B14A-47D2-BDED-ACCE9E2819FB at nicira.com> <0A8CFEC45B7F4C419F7543867C47442307A6D6E8 at mailserver.nechclst.in> <C218E162-3C68-43D1-BC28-21591F5AFF5F at nicira.com> <0A8CFEC45B7F4C419F7543867C47442307A6D748 at mailserver.nechclst.in>
> To: "Sheili Mittal" <sheili.mittal at nechclst.in>
> X-Mailer: Apple Mail (2.1251.1)
> X-Spam: [F=2000000000; B=500(0); STSI=500(0); STSM=500(0); CM=500; MH=500(2012011101); S=200(2010122901); SC=ne]
> X-MAIL-FROM: <jpettit at nicira.com>
> X-SOURCE-IP: [209.85.214.173]
> X-AnalysisOut: [v=0 c=a=ax9VMZzu0A:10 a=ceEmwcHowA:10 a=9zAlcOel]
> X-AnalysisOut: [0A:10 a=0qzvKZr8+ubEZBJFjXLA=17 a=S0CfSAAAAA:8 a=A]
> X-AnalysisOut: [DynmgAAAA:8 a=v3f1J1AAAA:8 a=T9kJtlqF0SUUv3VBAA:9 a=]
> X-AnalysisOut: [gdOWIEhI-AY2Jab0gA:7 a=uIK1q_8ugA:10 a=87az3203AA:10 a]
> X-AnalysisOut: [=Wnc_zPtJUA:10 a=PuDewjIqVdgnBq:21 a=bJG75j201pbCik:]
> X-AnalysisOut: [21]
> X-OriginalArrivalTime: 11 Jan 2012 09:05:50.0243 (UTC) FILETIME=6C77F30:01CCD040]
> 
> ovs-vswitchd needs to point to a database, not an OpenFlow connection.  Get everything working locally on your system first as described in INSTALL.Linux.  You should be able to configure the system with ovs-ofctl and ovs-vsctl locally.  Then, you should be able to run "ovs-vsctl set-controller br0 ptcp:" and run the ovs-ofctl commands remotely as you describe.
> 
> --Justin
> 
> 
> On Jan 11, 2012, at 12:49 AM, Sheili Mittal wrote:
> 
>> Hi Justin,
>> 
>> I tried following and getting error:-
>> 
>> ovs-vswitchd tcp:10.0.3.92:6633
>> 
>> Jan 11 14:12:18|00125|reconnect|WARN|tcp:10.0.3.92:6633: connection
>> attempt failed (Connection refused) Jan 11
>> 14:12:18|00126|reconnect|INFO|tcp:10.0.3.92:6633: waiting 8 seconds
>> before reconnect
>> 
>> For ovs-ofctl:-
>> ovs-ofctl add-flow tcp:10.0.3.92:6633 nw_src=10.0.0.0 actions=output:2
>> 
>> l: connecting to tcp:10.0.3.92:6633 (Connection refused)
>> 
>> Can you please confirm where I am wrong here?
>> I am trying to confirm for local machine connection for openflow, my
>> target is remote machine.
>> So if ovs-ofctl can connect remote machine also then please confirm.
>> 
>> 
>> Thanks & Regards,
>> Sheili Mittal
>> 
>> -----Original Message-----
>> From: Justin Pettit [mailto:jpettit at nicira.com] 
>> Sent: 11 January 2012 13:42
>> To: Sheili Mittal
>> Cc: Aaron Rosen; discuss at openvswitch.org
>> Subject: Re: [ovs-discuss] ofctl connection
>> 
>> 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: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. . 
>>> 
>> ------------------------------------------------------------------------
>> -----------------------------------------------
>> 
>> 
>> 
>> 
>> 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. . 
>> -----------------------------------------------------------------------------------------------------------------------
> 
> 
> 
> 
> 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. . 
> -----------------------------------------------------------------------------------------------------------------------




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