Mailing List Archive: About gre flow of OVSQuantumTunnelAgent

About gre flow of OVSQuantumTunnelAgent

May 8, 2012, 6:40 AM

Post #1 of 7 (2222 views)

Hi,
I have tried to run OVSQuantumTunnelAgent with two compute hosts. But VM on hostb cannot get ip from dhcp server on hostb. I found the br-tun has the flows set:
[root@robinlinux ~]# ovs-ofctl show br-tun
OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:0000b2dea5b34a44
n_tables:255, n_buffers:256
features: capabilities:0xc7, actions:0xfff
1(patch-int): addr:aa:c9:ac:8c:be:a8
config: 0
state: 0
2(gre-0): addr:76:4c:ca:ca:61:1c
config: 0
state: 0
3(gre-1): addr:52:91:f7:6c:08:57
config: 0
state: 0
LOCAL(br-tun): addr:b2:de:a5:b3:4a:44
config: PORT_DOWN
state: LINK_DOWN
OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=0
[root@robinlinux ~]# ovs-ofctl dump-flows br-tun
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=66.985s, table=0, n_packets=0, n_bytes=0, priority=3,tun_id=0x2 actions=mod_vlan_vid:1,output:1
cookie=0x0, duration=69.593s, table=0, n_packets=2, n_bytes=652, priority=4,in_port=1,dl_vlan=1 actions=set_tunnel:0x2,NORMAL
cookie=0x0, duration=1884.901s, table=0, n_packets=449, n_bytes=145796, priority=1 actions=drop

It seems we have just flows for connection between br-int and br-tun, have no flows out/in for gre port. So all traffic on gre port are dropped by default rule 3#.

any thoughts?

Thanks

Re: About gre flow of OVSQuantumTunnelAgent [ In reply to ]

dan at nicira

May 8, 2012, 8:27 AM

Post #2 of 7 (2171 views)

Permalink

resending to netstack list, reply all somehow mangled the address...

On Tue, May 8, 2012 at 8:12 AM, Dan Wendlandt <dan@nicira.com> wrote:

>
> Hi Yong,
>
> On Tue, May 8, 2012 at 6:40 AM, Yong Sheng Gong <gongysh@cn.ibm.com>wrote:
>
>>
>> Hi,
>> I have tried to run OVSQuantumTunnelAgent with two compute hosts. But VM
>> on hostb cannot get ip from dhcp server on hostb.
>>
>
> If the VM and the dhcp server are both on "hostb", then packets would be
> switched directly between them on br-int, they would not need to be
> tunneled. Perhaps you meant one was on hosta?
>
> Either way, please create a bug on launchpad and attach the output of the
> plugin agents running on both hosts. Thanks,
>
> Dan
>
> p.s. be sure that you've got the latest master, as there have been a
> couple important bug fixes recently.
>
>
>
>> I found the br-tun has the flows set:
>> [root@robinlinux ~]# ovs-ofctl show br-tun
>> OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:0000b2dea5b34a44
>> n_tables:255, n_buffers:256
>> features: capabilities:0xc7, actions:0xfff
>> 1(patch-int): addr:aa:c9:ac:8c:be:a8
>> config: 0
>> state: 0
>> 2(gre-0): addr:76:4c:ca:ca:61:1c
>> config: 0
>> state: 0
>> 3(gre-1): addr:52:91:f7:6c:08:57
>> config: 0
>> state: 0
>> LOCAL(br-tun): addr:b2:de:a5:b3:4a:44
>> config: PORT_DOWN
>> state: LINK_DOWN
>> OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=0
>> [root@robinlinux ~]# ovs-ofctl dump-flows br-tun
>> NXST_FLOW reply (xid=0x4):
>> cookie=0x0, duration=66.985s, table=0, n_packets=0, n_bytes=0,
>> priority=3,tun_id=0x2 actions=mod_vlan_vid:1,output:1
>> cookie=0x0, duration=69.593s, table=0, n_packets=2, n_bytes=652,
>> priority=4,in_port=1,dl_vlan=1 actions=set_tunnel:0x2,NORMAL
>> cookie=0x0, duration=1884.901s, table=0, n_packets=449, n_bytes=145796,
>> priority=1 actions=drop
>>
>> It seems we have just flows for connection between br-int and br-tun,
>> have no flows out/in for gre port. So all traffic on gre port are dropped
>> by default rule 3#.
>>
>> any thoughts?
>>
>> Thanks
>>
>>
>> --
>> Mailing list: https://launchpad.net/~netstack
>> Post to : netstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~netstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: About gre flow of OVSQuantumTunnelAgent [ In reply to ]

dedutta at cisco

May 8, 2012, 9:05 AM

Post #3 of 7 (2182 views)

Permalink

Hi

Dave and I have encountered this problem before. One thing to do is to ensure you have the latest ovs (in 11.10 the ovs didn't like tunnels)

debo

On May 8, 2012, at 8:27 AM, Dan Wendlandt wrote:

> resending to netstack list, reply all somehow mangled the address...
>
> On Tue, May 8, 2012 at 8:12 AM, Dan Wendlandt <dan@nicira.com> wrote:
>
> Hi Yong,
>
> On Tue, May 8, 2012 at 6:40 AM, Yong Sheng Gong <gongysh@cn.ibm.com> wrote:
>
> Hi,
> I have tried to run OVSQuantumTunnelAgent with two compute hosts. But VM on hostb cannot get ip from dhcp server on hostb.
>
> If the VM and the dhcp server are both on "hostb", then packets would be switched directly between them on br-int, they would not need to be tunneled. Perhaps you meant one was on hosta?
>
> Either way, please create a bug on launchpad and attach the output of the plugin agents running on both hosts. Thanks,
>
> Dan
>
> p.s. be sure that you've got the latest master, as there have been a couple important bug fixes recently.
>
>
> I found the br-tun has the flows set:
> [root@robinlinux ~]# ovs-ofctl show br-tun
> OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:0000b2dea5b34a44
> n_tables:255, n_buffers:256
> features: capabilities:0xc7, actions:0xfff
> 1(patch-int): addr:aa:c9:ac:8c:be:a8
> config: 0
> state: 0
> 2(gre-0): addr:76:4c:ca:ca:61:1c
> config: 0
> state: 0
> 3(gre-1): addr:52:91:f7:6c:08:57
> config: 0
> state: 0
> LOCAL(br-tun): addr:b2:de:a5:b3:4a:44
> config: PORT_DOWN
> state: LINK_DOWN
> OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=0
> [root@robinlinux ~]# ovs-ofctl dump-flows br-tun
> NXST_FLOW reply (xid=0x4):
> cookie=0x0, duration=66.985s, table=0, n_packets=0, n_bytes=0, priority=3,tun_id=0x2 actions=mod_vlan_vid:1,output:1
> cookie=0x0, duration=69.593s, table=0, n_packets=2, n_bytes=652, priority=4,in_port=1,dl_vlan=1 actions=set_tunnel:0x2,NORMAL
> cookie=0x0, duration=1884.901s, table=0, n_packets=449, n_bytes=145796, priority=1 actions=drop
>
> It seems we have just flows for connection between br-int and br-tun, have no flows out/in for gre port. So all traffic on gre port are dropped by default rule 3#.
>
> any thoughts?
>
> Thanks
>
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp
>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp

Re: About gre flow of OVSQuantumTunnelAgent [ In reply to ]

gongysh at cn

May 8, 2012, 2:53 PM

Post #4 of 7 (2171 views)

Permalink

Sorry. I mean hostb's vm to access dnsmasq on hosta.

-----Dan Wendlandt <dan@nicira.com> wrote: -----

To: Yong Sheng Gong/China/IBM@IBMCN
From: Dan Wendlandt <dan@nicira.com>
Date: 05/08/2012 11:12PM
Cc: netstack@lists.launchpad.net
Subject: Re: [Netstack] About gre flow of OVSQuantumTunnelAgent

Hi Yong,

On Tue, May 8, 2012 at 6:40 AM, Yong Sheng Gong <gongysh@cn.ibm.com> wrote:

Hi,
I have tried to run OVSQuantumTunnelAgent with two compute hosts. But VM on hostb cannot get ip from dhcp server on hostb.

If the VM and the dhcp server are both on "hostb", then packets would be switched directly between them on br-int, they would not need to be tunneled. Perhaps you meant one was on hosta?
Either way, please create a bug on launchpad and attach the output of the plugin agents running on both hosts. Thanks,
Dan
p.s. be sure that you've got the latest master, as there have been a couple important bug fixes recently.

I found the br-tun has the flows set:
[root@robinlinux ~]# ovs-ofctl show br-tun
OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:0000b2dea5b34a44
n_tables:255, n_buffers:256
features: capabilities:0xc7, actions:0xfff
1(patch-int): addr:aa:c9:ac:8c:be:a8
config: 0
state: 0
2(gre-0): addr:76:4c:ca:ca:61:1c
config: 0
state: 0
3(gre-1): addr:52:91:f7:6c:08:57
config: 0
state: 0
LOCAL(br-tun): addr:b2:de:a5:b3:4a:44
config: PORT_DOWN
state: LINK_DOWN
OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=0
[root@robinlinux ~]# ovs-ofctl dump-flows br-tun
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=66.985s, table=0, n_packets=0, n_bytes=0, priority=3,tun_id=0x2 actions=mod_vlan_vid:1,output:1
cookie=0x0, duration=69.593s, table=0, n_packets=2, n_bytes=652, priority=4,in_port=1,dl_vlan=1 actions=set_tunnel:0x2,NORMAL
cookie=0x0, duration=1884.901s, table=0, n_packets=449, n_bytes=145796, priority=1 actions=drop

It seems we have just flows for connection between br-int and br-tun, have no flows out/in for gre port. So all traffic on gre port are dropped by default rule 3#.

any thoughts?

Thanks

--
Mailing list: https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp"]https://help.launchpad.net/ListHelp

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt Nicira, Inc: http://www.nicira.com"]www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: About gre flow of OVSQuantumTunnelAgent [ In reply to ]

gongysh at cn

May 8, 2012, 2:58 PM

Post #5 of 7 (2192 views)

Permalink

my ovs version on redhat Enterprise linux server 6.1:
[root@robinlinux ~]# ovs-vsctl --version
ovs-vsctl (Open vSwitch) 1.4.0
Compiled Mar 21 2012 21:02:10

-----Debo~ Dutta <dedutta@cisco.com> wrote: -----

To: Dan Wendlandt <dan@nicira.com>
From: Debo~ Dutta <dedutta@cisco.com>
Date: 05/09/2012 12:05AM
Cc: Yong Sheng Gong/China/IBM@IBMCN, netstack@lists.launchpad.net, David Lapsley <dlapsley@nicira.com>
Subject: Re: [Netstack] About gre flow of OVSQuantumTunnelAgent

Hi
Dave and I have encountered this problem before. One thing to do is to ensure you have the latest ovs (in 11.10 the ovs didn't like tunnels)
debo
On May 8, 2012, at 8:27 AM, Dan Wendlandt wrote:
resending to netstack list, reply all somehow mangled the address...

On Tue, May 8, 2012 at 8:12 AM, Dan Wendlandt <dan@nicira.com> wrote:

Hi Yong,

On Tue, May 8, 2012 at 6:40 AM, Yong Sheng Gong <gongysh@cn.ibm.com> wrote:

Hi,
I have tried to run OVSQuantumTunnelAgent with two compute hosts. But VM on hostb cannot get ip from dhcp server on hostb.

If the VM and the dhcp server are both on "hostb", then packets would be switched directly between them on br-int, they would not need to be tunneled. Perhaps you meant one was on hosta?
Either way, please create a bug on launchpad and attach the output of the plugin agents running on both hosts. Thanks,
Dan
p.s. be sure that you've got the latest master, as there have been a couple important bug fixes recently.

I found the br-tun has the flows set:
[root@robinlinux ~]# ovs-ofctl show br-tun
OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:0000b2dea5b34a44
n_tables:255, n_buffers:256
features: capabilities:0xc7, actions:0xfff
1(patch-int): addr:aa:c9:ac:8c:be:a8
config: 0
state: 0
2(gre-0): addr:76:4c:ca:ca:61:1c
config: 0
state: 0
3(gre-1): addr:52:91:f7:6c:08:57
config: 0
state: 0
LOCAL(br-tun): addr:b2:de:a5:b3:4a:44
config: PORT_DOWN
state: LINK_DOWN
OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=0
[root@robinlinux ~]# ovs-ofctl dump-flows br-tun
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=66.985s, table=0, n_packets=0, n_bytes=0, priority=3,tun_id=0x2 actions=mod_vlan_vid:1,output:1
cookie=0x0, duration=69.593s, table=0, n_packets=2, n_bytes=652, priority=4,in_port=1,dl_vlan=1 actions=set_tunnel:0x2,NORMAL
cookie=0x0, duration=1884.901s, table=0, n_packets=449, n_bytes=145796, priority=1 actions=drop

It seems we have just flows for connection between br-int and br-tun, have no flows out/in for gre port. So all traffic on gre port are dropped by default rule 3#.

any thoughts?

Thanks

--
Mailing list: https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp"]https://help.launchpad.net/ListHelp

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt Nicira, Inc: http://www.nicira.com/"]www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt Nicira, Inc: http://www.nicira.com/"]www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

--
Mailing list: https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp"]https://help.launchpad.net/ListHelp

Re: About gre flow of OVSQuantumTunnelAgent [ In reply to ]

dedutta at cisco

May 8, 2012, 3:59 PM

Post #6 of 7 (2178 views)

Permalink

We were having issues with the patch ports … can you check if your GRE packets for pings flow from the br-tun to br-tun …..

debo

On May 8, 2012, at 2:53 PM, Yong Sheng Gong wrote:

> Sorry. I mean hostb's vm to access dnsmasq on hosta.
>
>
> -----Dan Wendlandt <dan@nicira.com> wrote: -----
>
> To: Yong Sheng Gong/China/IBM@IBMCN
> From: Dan Wendlandt <dan@nicira.com>
> Date: 05/08/2012 11:12PM
> Cc: netstack@lists.launchpad.net
> Subject: Re: [Netstack] About gre flow of OVSQuantumTunnelAgent
>
>
> Hi Yong,
>
> On Tue, May 8, 2012 at 6:40 AM, Yong Sheng Gong <gongysh@cn.ibm.com> wrote:
>
> Hi,
> I have tried to run OVSQuantumTunnelAgent with two compute hosts. But VM on hostb cannot get ip from dhcp server on hostb.
>
> If the VM and the dhcp server are both on "hostb", then packets would be switched directly between them on br-int, they would not need to be tunneled. Perhaps you meant one was on hosta?
>
> Either way, please create a bug on launchpad and attach the output of the plugin agents running on both hosts. Thanks,
>
> Dan
>
> p.s. be sure that you've got the latest master, as there have been a couple important bug fixes recently.
>
>
> I found the br-tun has the flows set:
> [root@robinlinux ~]# ovs-ofctl show br-tun
> OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:0000b2dea5b34a44
> n_tables:255, n_buffers:256
> features: capabilities:0xc7, actions:0xfff
> 1(patch-int): addr:aa:c9:ac:8c:be:a8
> config: 0
> state: 0
> 2(gre-0): addr:76:4c:ca:ca:61:1c
> config: 0
> state: 0
> 3(gre-1): addr:52:91:f7:6c:08:57
> config: 0
> state: 0
> LOCAL(br-tun): addr:b2:de:a5:b3:4a:44
> config: PORT_DOWN
> state: LINK_DOWN
> OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=0
> [root@robinlinux ~]# ovs-ofctl dump-flows br-tun
> NXST_FLOW reply (xid=0x4):
> cookie=0x0, duration=66.985s, table=0, n_packets=0, n_bytes=0, priority=3,tun_id=0x2 actions=mod_vlan_vid:1,output:1
> cookie=0x0, duration=69.593s, table=0, n_packets=2, n_bytes=652, priority=4,in_port=1,dl_vlan=1 actions=set_tunnel:0x2,NORMAL
> cookie=0x0, duration=1884.901s, table=0, n_packets=449, n_bytes=145796, priority=1 actions=drop
>
> It seems we have just flows for connection between br-int and br-tun, have no flows out/in for gre port. So all traffic on gre port are dropped by default rule 3#.
>
> any thoughts?
>
> Thanks
>
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp
>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp

Re: About gre flow of OVSQuantumTunnelAgent [ In reply to ]

dan at nicira

May 8, 2012, 4:00 PM

Post #7 of 7 (2176 views)

Permalink

Creating a bug and posting the logs from the agents will probably be the
most useful here.

dan

On Tue, May 8, 2012 at 3:59 PM, Debo~ Dutta <dedutta@cisco.com> wrote:

> We were having issues with the patch ports … can you check if your GRE
> packets for pings flow from the br-tun to br-tun …..
>
> debo
>
> On May 8, 2012, at 2:53 PM, Yong Sheng Gong wrote:
>
> Sorry. I mean hostb's vm to access dnsmasq on hosta.
>
>
> -----Dan Wendlandt <dan@nicira.com> <dan@nicira.com> wrote: -----
>
> To: Yong Sheng Gong/China/IBM@IBMCN
> From: Dan Wendlandt <dan@nicira.com> <dan@nicira.com>
> Date: 05/08/2012 11:12PM
> Cc: netstack@lists.launchpad.net
> Subject: Re: [Netstack] About gre flow of OVSQuantumTunnelAgent
>
>
> Hi Yong,
>
> On Tue, May 8, 2012 at 6:40 AM, Yong Sheng Gong <gongysh@cn.ibm.com>wrote:
>
>>
>> Hi,
>> I have tried to run OVSQuantumTunnelAgent with two compute hosts. But VM
>> on hostb cannot get ip from dhcp server on hostb.
>>
>
> If the VM and the dhcp server are both on "hostb", then packets would be
> switched directly between them on br-int, they would not need to be
> tunneled. Perhaps you meant one was on hosta?
>
> Either way, please create a bug on launchpad and attach the output of the
> plugin agents running on both hosts. Thanks,
>
> Dan
>
> p.s. be sure that you've got the latest master, as there have been a
> couple important bug fixes recently.
>
>
>
>> I found the br-tun has the flows set:
>> [root@robinlinux ~]# ovs-ofctl show br-tun
>> OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:0000b2dea5b34a44
>> n_tables:255, n_buffers:256
>> features: capabilities:0xc7, actions:0xfff
>> 1(patch-int): addr:aa:c9:ac:8c:be:a8
>> config: 0
>> state: 0
>> 2(gre-0): addr:76:4c:ca:ca:61:1c
>> config: 0
>> state: 0
>> 3(gre-1): addr:52:91:f7:6c:08:57
>> config: 0
>> state: 0
>> LOCAL(br-tun): addr:b2:de:a5:b3:4a:44
>> config: PORT_DOWN
>> state: LINK_DOWN
>> OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=0
>> [root@robinlinux ~]# ovs-ofctl dump-flows br-tun
>> NXST_FLOW reply (xid=0x4):
>> cookie=0x0, duration=66.985s, table=0, n_packets=0, n_bytes=0,
>> priority=3,tun_id=0x2 actions=mod_vlan_vid:1,output:1
>> cookie=0x0, duration=69.593s, table=0, n_packets=2, n_bytes=652,
>> priority=4,in_port=1,dl_vlan=1 actions=set_tunnel:0x2,NORMAL
>> cookie=0x0, duration=1884.901s, table=0, n_packets=449, n_bytes=145796,
>> priority=1 actions=drop
>>
>> It seems we have just flows for connection between br-int and br-tun,
>> have no flows out/in for gre port. So all traffic on gre port are dropped
>> by default rule 3#.
>>
>> any thoughts?
>>
>> Thanks
>>
>>
>> --
>> Mailing list: https://launchpad.net/~netstack
>> Post to : netstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~netstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp
>
>
>

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~