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:[email protected]] > Sent: 11 January 2012 13:42 > To: Sheili Mittal > Cc: Aaron Rosen; [email protected] > 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:[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. . >> > ------------------------------------------------------------------------ > ----------------------------------------------- > > > > > 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
