[ovs-discuss] ofctl connection
Justin Pettit
jpettit at nicira.com
Wed Jan 11 09:04:36 UTC 2012
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. .
> -----------------------------------------------------------------------------------------------------------------------
More information about the discuss
mailing list