Re: [openstack-dev] [neutron][routed-network] Host doesn't connected any segments when creating port

[shihanzhang]

agree with Neil.


thanks
shihanzhang




在 2016-11-01 17:13:54，"Neil Jerram" <n...@tigera.io> 写道：

Hi Zhi Chang,


I believe the answer is that the physical network (aka fabric) should provide 
routing between those two subnets. This routing between segments is implicit in 
the idea of a multi-segment network, and is entirely independent of routing 
between virtual _networks_ (which is done by a Neutron router object connecting 
those networks).


Hope that helps! 
Neil 
 


|
From: zhi
Sent: Tuesday, 1 November 2016 07:50
To: OpenStack Development Mailing List (not for usage questions)
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][routed-network] Host doesn't connected 
any segments when creating port
|


Hi, shihanzhang.


I still have a question about routed network. I have two subnets. One is 
10.1.0.0/24 and the other is 10.1.1.0/24. I create two instances in each host.
Such as 10.1.0.10 and 10.1.1.10.


My question is, how does 10.1.0.10 connect to 10.1.1.10 ?  There is no any 
gateway( 10.1.0.1 and 10.1.1.1 ) in each subnet.




Hope four your reply. ;-)




Thanks
Zhi Chang


2016-11-01 14:31 GMT+08:00 zhi <changzhi1...@gmail.com>:

Hi, shihanzhang.


Thanks for your advice. Now I can created ports successfully by your advice. 






Thanks
Zhi Chang




2016-11-01 12:50 GMT+08:00 shihanzhang <ayshihanzh...@126.com>:

Hi Zhi Chang,
Maybe you should add a config option in [ovs] section: bridge_mappings = 
public:br-ex, physnet1:br-physnet1 to handle the provider network 'physnet1'.


Thanks,
shihanzhang

At 2016-11-01 11:56:33, "zhi" <changzhi1...@gmail.com> wrote:

hi shihanzhang.


Below is configuration in ml2_conf.ini. Please review it. :)


stack@devstack:~/neutron/neutron$ cat /etc/neutron/plugins/ml2/ml2_conf.ini 
|grep -v "#"|grep -v ^$
[DEFAULT]
[ml2]
tenant_network_types = vxlan
extension_drivers = port_security
mechanism_drivers = openvswitch,linuxbridge
tenant_network_types = vxlan
[ml2_type_flat]
flat_networks = public,public,
[ml2_type_geneve]
vni_ranges = 1:1000
[ml2_type_gre]
tunnel_id_ranges = 1:1000
[ml2_type_vlan]
network_vlan_ranges = physnet1,physnet2
[ml2_type_vxlan]
vni_ranges = 1:1000
[securitygroup]
firewall_driver = 
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
[agent]
tunnel_types = vxlan
root_helper_daemon = sudo /usr/local/bin/neutron-rootwrap-daemon 
/etc/neutron/rootwrap.conf
root_helper = sudo /usr/local/bin/neutron-rootwrap /etc/neutron/rootwrap.conf
[ovs]
datapath_type = system
bridge_mappings = public:br-ex
tunnel_bridge = br-tun
local_ip = 192.168.10.20






Thanks
Zhi Chang


2016-11-01 9:15 GMT+08:00 shihanzhang <ayshihanzh...@126.com>:

hi Zhi chang,

Could you provide your ml2_conf.ini for ovs agent, I guess the reason is that 
your ovs-agent on host devstack can't handle the related segment id.


Thanks,
shihanzhang


在 2016-10-31 18:43:36，"zhi" <changzhi1...@gmail.com> 写道：

Hi, all.


Recently, I watch the OpenStack Summit video named ' Scaling Up OpenStack 
Networking with Routed Networks '.  Carl and Miguel made this topic.  I learned 
a lot of your topic. Thanks. 


But I have some questions about the demo in the topic. 


I do some steps according to the topic. 


First, creating two networks like this:


neutron net-create multinet --shared --segments type=dict list=true 
provider:physical_network=physnet1,provider:segmentation_id=2016,provider:network_type=vlan
 
provider:physical_network=physnet2,provider:segmentation_id=2016,provider:network_type=vlan




Second, I get two segments after creating this network. I get these segments by 
using " openstack network segment list ". 


Third, I create two subnets by these segments by using this command " 


neutron subnet-create --ip_version 4 --name multi-segment1-subnet [net-id] 
10.1.0.0/24 --segment_id [segment-id]
neutron subnet-create --ip_version 4 --name multi-segment2-subnet [net-id] 
10.1.1.0/24 --segment_id [segment-id]
 "


At last, I want to create a port with host_id. My local environment contains 
two compute nodes, one is named "devstack"  and the other is "devstack2". So I 
use this command "  neutron port-create --binding:host_id=devstack [net-id] ". 


Exception happens in neutron server. The exception says "


Host devstack is not connected to any segments on routed provider network 
[net-id].  It should be connected to one." I can not get this exact point about 
this exception. 


Why does the "routed network" have relationship with host? 


How they work together between "host info (compute node ?)" and "routed 
network"?


What should I do if I want to get rid of this exception?




Hope for your reply. Especially Carl and Miguel. ;-)






Many Thanks
Zhi Chang




 


_

Re: [openstack-dev] [neutron][routed-network] Host doesn't connected any segments when creating port

[shihanzhang]

Hi Zhi Chang,
You also need to connect these two subnets to a router.


Thanks,
shihanzhang

在 2016-11-01 15:47:57，"zhi" <changzhi1...@gmail.com> 写道：

Hi, shihanzhang.


I still have a question about routed network. I have two subnets. One is 
10.1.0.0/24 and the other is 10.1.1.0/24. I create two instances in each host.
Such as 10.1.0.10 and 10.1.1.10.


My question is, how does 10.1.0.10 connect to 10.1.1.10 ?  There is no any 
gateway( 10.1.0.1 and 10.1.1.1 ) in each subnet.




Hope four your reply. ;-)




Thanks
Zhi Chang


2016-11-01 14:31 GMT+08:00 zhi <changzhi1...@gmail.com>:

Hi, shihanzhang.


Thanks for your advice. Now I can created ports successfully by your advice. 






Thanks
Zhi Chang




2016-11-01 12:50 GMT+08:00 shihanzhang <ayshihanzh...@126.com>:

Hi Zhi Chang,
Maybe you should add a config option in [ovs] section: bridge_mappings = 
public:br-ex, physnet1:br-physnet1 to handle the provider network 'physnet1'.


Thanks,
shihanzhang

At 2016-11-01 11:56:33, "zhi" <changzhi1...@gmail.com> wrote:

hi shihanzhang.


Below is configuration in ml2_conf.ini. Please review it. :)


stack@devstack:~/neutron/neutron$ cat /etc/neutron/plugins/ml2/ml2_conf.ini 
|grep -v "#"|grep -v ^$
[DEFAULT]
[ml2]
tenant_network_types = vxlan
extension_drivers = port_security
mechanism_drivers = openvswitch,linuxbridge
tenant_network_types = vxlan
[ml2_type_flat]
flat_networks = public,public,
[ml2_type_geneve]
vni_ranges = 1:1000
[ml2_type_gre]
tunnel_id_ranges = 1:1000
[ml2_type_vlan]
network_vlan_ranges = physnet1,physnet2
[ml2_type_vxlan]
vni_ranges = 1:1000
[securitygroup]
firewall_driver = 
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
[agent]
tunnel_types = vxlan
root_helper_daemon = sudo /usr/local/bin/neutron-rootwrap-daemon 
/etc/neutron/rootwrap.conf
root_helper = sudo /usr/local/bin/neutron-rootwrap /etc/neutron/rootwrap.conf
[ovs]
datapath_type = system
bridge_mappings = public:br-ex
tunnel_bridge = br-tun
local_ip = 192.168.10.20






Thanks
Zhi Chang


2016-11-01 9:15 GMT+08:00 shihanzhang <ayshihanzh...@126.com>:

hi Zhi chang,

Could you provide your ml2_conf.ini for ovs agent, I guess the reason is that 
your ovs-agent on host devstack can't handle the related segment id.


Thanks,
shihanzhang


在 2016-10-31 18:43:36，"zhi" <changzhi1...@gmail.com> 写道：

Hi, all.


Recently, I watch the OpenStack Summit video named ' Scaling Up OpenStack 
Networking with Routed Networks '.  Carl and Miguel made this topic.  I learned 
a lot of your topic. Thanks. 


But I have some questions about the demo in the topic. 


I do some steps according to the topic. 


First, creating two networks like this:


neutron net-create multinet --shared --segments type=dict list=true 
provider:physical_network=physnet1,provider:segmentation_id=2016,provider:network_type=vlan
 
provider:physical_network=physnet2,provider:segmentation_id=2016,provider:network_type=vlan




Second, I get two segments after creating this network. I get these segments by 
using " openstack network segment list ". 


Third, I create two subnets by these segments by using this command " 


neutron subnet-create --ip_version 4 --name multi-segment1-subnet [net-id] 
10.1.0.0/24 --segment_id [segment-id]
neutron subnet-create --ip_version 4 --name multi-segment2-subnet [net-id] 
10.1.1.0/24 --segment_id [segment-id]
 "


At last, I want to create a port with host_id. My local environment contains 
two compute nodes, one is named "devstack"  and the other is "devstack2". So I 
use this command "  neutron port-create --binding:host_id=devstack [net-id] ". 


Exception happens in neutron server. The exception says "


Host devstack is not connected to any segments on routed provider network 
[net-id].  It should be connected to one." I can not get this exact point about 
this exception. 


Why does the "routed network" have relationship with host? 


How they work together between "host info (compute node ?)" and "routed 
network"?


What should I do if I want to get rid of this exception?




Hope for your reply. Especially Carl and Miguel. ;-)






Many Thanks
Zhi Chang




 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev








 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][routed-network] Host doesn't connected any segments when creating port

[shihanzhang]

Hi Zhi Chang,
Maybe you should add a config option in [ovs] section: bridge_mappings = 
public:br-ex, physnet1:br-physnet1 to handle the provider network 'physnet1'.


Thanks,
shihanzhang

At 2016-11-01 11:56:33, "zhi" <changzhi1...@gmail.com> wrote:

hi shihanzhang.


Below is configuration in ml2_conf.ini. Please review it. :)


stack@devstack:~/neutron/neutron$ cat /etc/neutron/plugins/ml2/ml2_conf.ini 
|grep -v "#"|grep -v ^$
[DEFAULT]
[ml2]
tenant_network_types = vxlan
extension_drivers = port_security
mechanism_drivers = openvswitch,linuxbridge
tenant_network_types = vxlan
[ml2_type_flat]
flat_networks = public,public,
[ml2_type_geneve]
vni_ranges = 1:1000
[ml2_type_gre]
tunnel_id_ranges = 1:1000
[ml2_type_vlan]
network_vlan_ranges = physnet1,physnet2
[ml2_type_vxlan]
vni_ranges = 1:1000
[securitygroup]
firewall_driver = 
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
[agent]
tunnel_types = vxlan
root_helper_daemon = sudo /usr/local/bin/neutron-rootwrap-daemon 
/etc/neutron/rootwrap.conf
root_helper = sudo /usr/local/bin/neutron-rootwrap /etc/neutron/rootwrap.conf
[ovs]
datapath_type = system
bridge_mappings = public:br-ex
tunnel_bridge = br-tun
local_ip = 192.168.10.20






Thanks
Zhi Chang


2016-11-01 9:15 GMT+08:00 shihanzhang <ayshihanzh...@126.com>:

hi Zhi chang,

Could you provide your ml2_conf.ini for ovs agent, I guess the reason is that 
your ovs-agent on host devstack can't handle the related segment id.


Thanks,
shihanzhang


在 2016-10-31 18:43:36，"zhi" <changzhi1...@gmail.com> 写道：

Hi, all.


Recently, I watch the OpenStack Summit video named ' Scaling Up OpenStack 
Networking with Routed Networks '.  Carl and Miguel made this topic.  I learned 
a lot of your topic. Thanks. 


But I have some questions about the demo in the topic. 


I do some steps according to the topic. 


First, creating two networks like this:


neutron net-create multinet --shared --segments type=dict list=true 
provider:physical_network=physnet1,provider:segmentation_id=2016,provider:network_type=vlan
 
provider:physical_network=physnet2,provider:segmentation_id=2016,provider:network_type=vlan




Second, I get two segments after creating this network. I get these segments by 
using " openstack network segment list ". 


Third, I create two subnets by these segments by using this command " 


neutron subnet-create --ip_version 4 --name multi-segment1-subnet [net-id] 
10.1.0.0/24 --segment_id [segment-id]
neutron subnet-create --ip_version 4 --name multi-segment2-subnet [net-id] 
10.1.1.0/24 --segment_id [segment-id]
 "


At last, I want to create a port with host_id. My local environment contains 
two compute nodes, one is named "devstack"  and the other is "devstack2". So I 
use this command "  neutron port-create --binding:host_id=devstack [net-id] ". 


Exception happens in neutron server. The exception says "


Host devstack is not connected to any segments on routed provider network 
[net-id].  It should be connected to one." I can not get this exact point about 
this exception. 


Why does the "routed network" have relationship with host? 


How they work together between "host info (compute node ?)" and "routed 
network"?


What should I do if I want to get rid of this exception?




Hope for your reply. Especially Carl and Miguel. ;-)






Many Thanks
Zhi Chang




 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][routed-network] Host doesn't connected any segments when creating port

[shihanzhang]

hi Zhi chang,

Could you provide your ml2_conf.ini for ovs agent, I guess the reason is that 
your ovs-agent on host devstack can't handle the related segment id.


Thanks,
shihanzhang


在 2016-10-31 18:43:36，"zhi" <changzhi1...@gmail.com> 写道：

Hi, all.


Recently, I watch the OpenStack Summit video named ' Scaling Up OpenStack 
Networking with Routed Networks '.  Carl and Miguel made this topic.  I learned 
a lot of your topic. Thanks. 


But I have some questions about the demo in the topic. 


I do some steps according to the topic. 


First, creating two networks like this:


neutron net-create multinet --shared --segments type=dict list=true 
provider:physical_network=physnet1,provider:segmentation_id=2016,provider:network_type=vlan
 
provider:physical_network=physnet2,provider:segmentation_id=2016,provider:network_type=vlan




Second, I get two segments after creating this network. I get these segments by 
using " openstack network segment list ". 


Third, I create two subnets by these segments by using this command " 


neutron subnet-create --ip_version 4 --name multi-segment1-subnet [net-id] 
10.1.0.0/24 --segment_id [segment-id]
neutron subnet-create --ip_version 4 --name multi-segment2-subnet [net-id] 
10.1.1.0/24 --segment_id [segment-id]
 "


At last, I want to create a port with host_id. My local environment contains 
two compute nodes, one is named "devstack"  and the other is "devstack2". So I 
use this command "  neutron port-create --binding:host_id=devstack [net-id] ". 


Exception happens in neutron server. The exception says "


Host devstack is not connected to any segments on routed provider network 
[net-id].  It should be connected to one." I can not get this exact point about 
this exception. 


Why does the "routed network" have relationship with host? 


How they work together between "host info (compute node ?)" and "routed 
network"?


What should I do if I want to get rid of this exception?




Hope for your reply. Especially Carl and Miguel. ;-)






Many Thanks
Zhi Chang__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] 回复： [neutron]dragonflow deployment incorrectness

[shihanzhang]

As I know,  now dragonflow still use neutron l3-agent for snat, so the l3-agent 
is enabled and router namespace  be created.




在 2016-07-28 08:53:20，kangjingt...@sina.com 写道：

Hi 


The reason why a namepspace be created while creating router is just because 
l3-agent is enabled. You can disable it as you want to.


At present, there is only dhcp app in dragonflow need packets from datapath, so 
you will observe controller related flows after you create vms in subnet where 
dhcp is enabled. 


BTW, if you want the all flows showed in br-int, including hidden flows, you 
can use command “ovs-appctl bridge/dump-flows br-int”


- 原始邮件 -
发件人："郑杰" 
收件人："openstack-dev" 
主题：[openstack-dev] [neutron]dragonflow deployment incorrectness
日期：2016年07月27日 14点46分




Hi ,everybody:

when I deploy DragonFlow, I start neutron-server ,df-local-controller and 
df-l3-router, but there still are router namespace when I create routers ,I 
check ovs flow table ,there is no CONTROLLER actions for ip traffic ,so I guess 
something wrong with my conf.
below are my neutron.conf and l3_agent.ini respectively

neutron.conf-
[DEFAULT]
dhcp_agent_notification = False
advertise_mtu = True
api_workers = 10
notify_nova_on_port_data_changes = True
notify_nova_on_port_status_changes = True
auth_strategy = keystone
allow_overlapping_ips = True
debug = True
service_plugins =
core_plugin = dragonflow.neutron.plugin.DFPlugin
transport_url = rabbit://stackrabbit:secret@172.16.18.127:5672/
logging_exception_prefix = %(color)s%(asctime)s.%(msecs)03d TRACE %(name)s 
^[[01;35m%(instance)s^[[00m
logging_debug_format_suffix = ^[[00;33mfrom (pid=%(process)d) %(funcName)s 
%(pathname)s:%(lineno)d^[[00m
logging_default_format_string = %(asctime)s.%(msecs)03d %(color)s%(levelname)s 
%(name)s [^[[00;36m-%(color)s] ^[[01;35m%(instance)s%(color)s%(message)s^[[00m
logging_context_format_string = %(asctime)s.%(msecs)03d %(color)s%(levelname)s 
%(name)s [^[[01;36m%(request_id)s ^[[00;36m%(user_name)s 
%(project_id)s%(color)s] ^[[01;35m%(instance)s%(color)s%(message)s^[[00m
bind_host = 0.0.0.0
use_syslog = False
state_path = /opt/stack/data/neutron

[df]
pub_sub_driver = redis_db_pubsub_driver
enable_selective_topology_distribution = True
publisher_rate_limit_count = 1
publisher_rate_limit_timeout = 180
pub_sub_use_multiproc = False
enable_df_pub_sub = True
monitor_table_poll_time = 30
apps_list = 
l2_app.L2App,l3_proactive_app.L3ProactiveApp,dhcp_app.DHCPApp,dnat_app.DNATApp,sg_app.SGApp,portsec_app.PortSecApp
integration_bridge = br-int
tunnel_type = geneve
local_ip = 172.16.18.127
nb_db_class = dragonflow.db.drivers.redis_db_driver.RedisDbDriver
remote_db_hosts = 172.16.18.127:4001
remote_db_port = 4001
remote_db_ip = 172.16.18.127

[df_l2_app]
l2_responder = True

[df_dnat_app]
ex_peer_patch_port = patch-int
int_peer_patch_port = patch-ex
external_network_bridge = br-ex

-l3_agent.ini 
-
[DEFAULT]
l3_agent_manager = neutron.agent.l3_agent.L3NATAgentWithStateReport
external_network_bridge = br-ex
interface_driver = openvswitch
ovs_use_veth = False
debug = True

[AGENT]
root_helper_daemon = sudo /usr/bin/neutron-rootwrap-daemon 
/etc/neutron/rootwrap.conf
root_helper = sudo /usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf

--ovs-ofctl dump-flows br-int---

NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=1710.883s, table=0, n_packets=0, n_bytes=0, 
idle_age=1710, priority=100,in_port=19 
actions=load:0x17->NXM_NX_REG6[],load:0x3->OXM_OF_METADATA[],resubmit(,1)
 cookie=0x0, duration=1710.883s, table=0, n_packets=1268, n_bytes=53760, 
idle_age=0, priority=100,in_port=13 
actions=load:0x15->NXM_NX_REG6[],load:0x3->OXM_OF_METADATA[],resubmit(,1)
 cookie=0x0, duration=1710.876s, table=0, n_packets=0, n_bytes=0, 
idle_age=1710, priority=100,in_port=15 
actions=load:0x1a->NXM_NX_REG6[],load:0x2->OXM_OF_METADATA[],resubmit(,1)
 cookie=0x0, duration=1710.876s, table=0, n_packets=0, n_bytes=0, 
idle_age=1710, priority=100,in_port=20 
actions=load:0x1c->NXM_NX_REG6[],load:0x3->OXM_OF_METADATA[],resubmit(,1)
 cookie=0x0, duration=1710.876s, table=0, n_packets=3, n_bytes=126, 
idle_age=643, priority=100,in_port=18 
actions=load:0x1b->NXM_NX_REG6[],load:0x2->OXM_OF_METADATA[],resubmit(,1)
 cookie=0x0, duration=1710.883s, table=0, n_packets=0, n_bytes=0, 
idle_age=1710, priority=100,tun_id=0x17 
actions=load:0x17->NXM_NX_REG7[],load:0x3->OXM_OF_METADATA[],resubmit(,72)
 cookie=0x0, duration=1710.882s, table=0, n_packets=0, n_bytes=0, 
idle_age=1710, priority=100,tun_id=0x15 
actions=load:0x15->NXM_NX_REG7[],load:0x3->OXM_OF_METADATA[],resubmit(,72)
 cookie=0x0, duration=1710.876s, table=0, n_packets=0, n_bytes=0, 
idle_age=1710, priority=100,tun_id=0x1a 
actions=load:0x1a->NXM_NX_REG7[],load:0x2->OXM_OF_METADATA[],resubmit(,72)
 

Re: [openstack-dev] [neutron][SFC]

[shihanzhang]

Hi Alioune and Cathy,
 For devstack on ubuntu14.04, the default ovs version is 2.0.2, so there 
was the error as Alioune said.
 Do we need to install speical ovs version in networking-sfc devstack 
plugin.sh?






在 2016-06-07 07:48:26，"Cathy Zhang"  写道：


Hi Alioune,

 

Which OVS version are you using?

Try openvswitch version 2.4.0 and restart the openvswitch-server before 
installing the devstack.

 

Cathy

 

From: Alioune [mailto:baliou...@gmail.com]
Sent: Friday, June 03, 2016 9:07 AM
To:openstack-dev@lists.openstack.org
Cc: Cathy Zhang
Subject: [openstack-dev][neutron][SFC]

 

Probleme with OpenStack SFC

Hi all, 

I've installed Openstack SFC with devstack and all module are corretly running 
except the neutron L2-agent

 

After a "screen -rd", it seems that there is a conflict between l2-agent and 
SFC (see trace bellow).

I solved the issue with "sudo ovs-vsctl set bridge br 
protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13" on all openvswitch 
bridge (br-int, br-ex, br-tun and br-mgmt0).

I would like to know:

  - If someone knows why this error arrises ?

 - is there another way to solve it ?

 

Regards,

 

2016-06-03 12:51:56.323 WARNING 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] OVS is dead. 
OVSNeutronAgent will keep running and checking OVS status periodically.

2016-06-03 12:51:56.330 DEBUG 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Agent rpc_loop - 
iteration:4722 completed. Processed ports statistics: {'regular': {'updated': 
0, 'added': 0, 'removed': 0}}. Elapsed:0.086 from (pid=12775) 
loop_count_and_wait 
/opt/stack/neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py:1680

2016-06-03 12:51:58.256 DEBUG 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Agent rpc_loop - 
iteration:4723 started from (pid=12775) rpc_loop 
/opt/stack/neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py:1732

2016-06-03 12:51:58.258 DEBUG neutron.agent.linux.utils 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Running command (rootwrap 
daemon): ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23'] 
from (pid=12775) execute_rootwrap_daemon 
/opt/stack/neutron/neutron/agent/linux/utils.py:101

2016-06-03 12:51:58.311 ERROR neutron.agent.linux.utils 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None]

Command: ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23']

Exit code: 1

Stdin:

Stdout:

Stderr: 
2016-06-03T12:51:58Z|1|vconn|WARN|unix:/var/run/openvswitch/br-int.mgmt: 
version negotiation failed (we support version 0x04, peer supports version 0x01)

ovs-ofctl: br-int: failed to connect to socket (Broken pipe)

 

2016-06-03 12:51:58.323 ERROR networking_sfc.services.sfc.common.ovs_ext_lib 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None]

Command: ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23']

Exit code: 1

Stdin:

Stdout:

Stderr: 
2016-06-03T12:51:58Z|1|vconn|WARN|unix:/var/run/openvswitch/br-int.mgmt: 
version negotiation failed (we support version 0x04, peer supports version 0x01)

ovs-ofctl: br-int: failed to connect to socket (Broken pipe)

 

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Traceback (most recent call last):

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib   
File 
"/opt/stack/networking-sfc/networking_sfc/services/sfc/common/ovs_ext_lib.py", 
line 125, in run_ofctl

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib
 process_input=process_input)

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib   
File "/opt/stack/neutron/neutron/agent/linux/utils.py", line 159, in execute

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib
 raise RuntimeError(m)

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
RuntimeError:

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Command: ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23']

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Exit code: 1

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Stdin:

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Stdout:

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Stderr: 
2016-06-03T12:51:58Z|1|vconn|WARN|unix:/var/run/openvswitch/br-int.mgmt: 
version negotiation failed (we support version 0x04, peer supports version 0x01)

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
ovs-ofctl: br-int: failed to connect to socket (Broken pipe)

2016-06-03 

Re: [openstack-dev] [Neutron] [Dragonflow] Support configuration of DB clusters

[shihanzhang]

good suggestion！



At 2015-12-25 19:07:10, "Li Ma"  wrote:
>Hi all, currently, we only support db_ip and db_port in the
>configuration file. Some DB SDK supports clustering, like Zookeeper.
>You can specify a list of nodes when client application starts to
>connect to servers.
>
>I'd like to implement this feature, specifying ['ip1:port',
>'ip2:port', 'ip3:port'] list in the configuration file. If only one
>server exists, just set it to ['ip1:port'].
>
>Any suggestions?
>
>-- 
>
>Li Ma (Nick)
>Email: skywalker.n...@gmail.com
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] KILO: neutron port-update --allowed-address-pairs action=clear throws an exception

[shihanzhang]

which branch do you use?  there is not this problem in master branch.





At 2015-09-28 13:43:05, "masoom alam"  wrote:

Can anybody highlight why the following command is throwing an exception:


Command# neutron port-update db3113df-14a3-4d6d-a3c5-d0517a134fc3 
--allowed-address-pairs action=clear


Error:  2015-09-27 21:44:32.144 ERROR neutron.api.v2.resource 
[req-b1cbe1f2-ba21-4337-a714-f337c54ee9fc admin None] update failed
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource Traceback (most recent 
call last):
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/resource.py", line 83, in resource
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource result = 
method(request=request, **args)
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 515, in update
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource 
allow_bulk=self._allow_bulk)
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 652, in prepare_request_body
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource 
attr_vals['validate'][rule])
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/extensions/allowedaddresspairs.py", line 51, in 
_validate_allowed_address_pairs
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource if len(address_pairs) 
> cfg.CONF.max_allowed_address_pair:
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource TypeError: object of type 
'NoneType' has no len()
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource






There is a similar bug filed at Lauchpad for Havana 
https://bugs.launchpad.net/juniperopenstack/+bug/1351979 .However there is no 
fix and the work around  - using curl, mentioned on the bug is also not working 
for KILO...it was working for havana and Icehouseany pointers...?


Thanks



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] KILO: neutron port-update --allowed-address-pairs action=clear throws an exception

[shihanzhang]

I don't see any exception using bellow command


root@szxbz:/opt/stack/neutron# neutron port-update 
3748649e-243d-4408-a5f1-8122f1fbf501 --allowed-address-pairs action=clear
Allowed address pairs must be a list.




At 2015-09-28 14:36:44, "masoom alam" <masoom.a...@wanclouds.net> wrote:

stable KILO


shall I checkout the latest code are you saying this...Also can you please 
confirm if you have tested this thing at your endand there was no problem...




Thanks


On Sun, Sep 27, 2015 at 11:29 PM, shihanzhang <ayshihanzh...@126.com> wrote:

which branch do you use?  there is not this problem in master branch.






At 2015-09-28 13:43:05, "masoom alam" <masoom.a...@wanclouds.net> wrote:

Can anybody highlight why the following command is throwing an exception:


Command# neutron port-update db3113df-14a3-4d6d-a3c5-d0517a134fc3 
--allowed-address-pairs action=clear


Error:  2015-09-27 21:44:32.144 ERROR neutron.api.v2.resource 
[req-b1cbe1f2-ba21-4337-a714-f337c54ee9fc admin None] update failed
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource Traceback (most recent 
call last):
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/resource.py", line 83, in resource
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource result = 
method(request=request, **args)
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 515, in update
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource 
allow_bulk=self._allow_bulk)
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 652, in prepare_request_body
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource 
attr_vals['validate'][rule])
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/extensions/allowedaddresspairs.py", line 51, in 
_validate_allowed_address_pairs
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource if len(address_pairs) 
> cfg.CONF.max_allowed_address_pair:
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource TypeError: object of type 
'NoneType' has no len()
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource






There is a similar bug filed at Lauchpad for Havana 
https://bugs.launchpad.net/juniperopenstack/+bug/1351979 .However there is no 
fix and the work around  - using curl, mentioned on the bug is also not working 
for KILO...it was working for havana and Icehouseany pointers...?


Thanks








网易考拉iPhone6s玫瑰金5288元，现货不加价


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Port Forwarding API

[shihanzhang]

 2) The same FIP address can be used for different mappings, for example 
FIP with IP X

  can be used with different ports to map to different VM's X:4001  -> 
VM1 IP

  X:4002 -> VM2 IP (This is the essence of port forwarding).

 So we also need the port mapping configuration fields


For the second use case, I have a question, does it support DVR?  if VM1 and 
VM2 are on
different compute nodes, how does it work?





在 2015-09-20 14:26:23，"Gal Sagie"  写道：

Hello All,


I have sent a spec [1] to resume the work on port forwarding API and reference 
implementation.


Its currently marked as "WIP", however i raised some "TBD" questions for the 
community.

The way i see port forwarding is an API that is very similar to floating IP API 
and implementation

with few changes:


1) Can only define port forwarding on the router external gateway IP (or 
additional public IPs

   that are located on the router.  (Similar to the case of centralized DNAT)


2) The same FIP address can be used for different mappings, for example FIP 
with IP X

can be used with different ports to map to different VM's X:4001  -> VM1 IP 
  

X:4002 -> VM2 IP (This is the essence of port forwarding).

So we also need the port mapping configuration fields


All the rest should probably behave (in my opinion) very similar to FIP's (for 
example

not being able to remove external gateway if port forwarding entries are 
configured,

if the VM is deletd the port forwarding entry is deleted as well and so on..)

All of these points are mentioned in the spec and i am waiting for the 
community feedback

on them.


I am trying to figure out if implementation wise, it would be smart to try and 
use the floating IP

implementation and extend it for this (given all the above mechanism described 
above already

works for floating IP's)

Or, add another new implementation which behaves very similar to floating IP's 
in most aspects

(But still differ in some)

Or something else...


Would love to hear the community feedback on the spec, even that its WIP


Thanks
Gal.

[1] https://review.openstack.org/#/c/224727/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][L3][QA] DVR job failure rate and maintainability

[shihanzhang]

Sean, 
Thank you very much for writing this, DVR indeed need to get more attention, 
it's a very cool and usefull feature, especially in large-scale. In Juno, it 
firstly lands to Neutron, through the development of Kilo and Liberty, it's 
getting better and better, we have used it in our production,
in the process of use, we found the following bugs have not been fixed, we have 
filed bug on launchpad:
1. every time we create a VM, it will trigger router scheduling, in 
large-scale, if there are lage l3 agents bind to a DVR router, scheduling 
router consume much time, but scheduling action is not necessary.[1]
2. every time we bind a VM with floatingIP, it also trigger router scheduling, 
and send this floatingIP to all bound
l3 agents.[2]
3. Bulk delete VMs from a compute node which has no VM on this router, for most 
part, the router namespace will remain.[3]
4. Updating router_gateway trigger reschedule_router, during reschedule_router, 
the communication is broken related to this router, for DVR router, why router 
need to reschedule_router? it reschedule which l3 agents? [4]
5. Stale fip namespaces are not cleaned up on compute nodes. [5]


I very agree with that we need a group of contributors that
can help with the DVR feature in the immediate term to fix the current bugs.
I am very glad to join this group.


Neutroner, let's start to do the great things!


Thanks,
Hanzhang,Shi


[1] https://bugs.launchpad.net/neutron/+bug/1486795
[2]https://bugs.launchpad.net/neutron/+bug/1486828
[3] https://bugs.launchpad.net/neutron/+bug/1496201
[4] https://bugs.launchpad.net/neutron/+bug/1496204
[5] https://bugs.launchpad.net/neutron/+bug/1470909







At 2015-09-15 06:01:03, "Sean M. Collins"  wrote:
>[adding neutron tag to subject and resending]
>
>Hi,
>
>Carl Baldwin, Doug Wiegley, Matt Kassawara, Ryan Moats, and myself are
>at the QA sprint in Fort Collins. Earlier today there was a discussion
>about the failure rate about the DVR job, and the possible impact that
>it is having on the gate.
>
>Ryan has a good patch up that shows the failure rates over time:
>
>https://review.openstack.org/223201
>
>To view the graphs, you go over into your neutron git repo, and open the
>.html files that are present in doc/dashboards - which should open up
>your browser and display the Graphite query.
>
>Doug put up a patch to change the DVR job to be non-voting while we
>determine the cause of the recent spikes:
>
>https://review.openstack.org/223173
>
>There was a good discussion after pushing the patch, revolving around
>the need for Neutron to have DVR, to fit operational and reliability
>requirements, and help transition away from Nova-Network by providing
>one of many solutions similar to Nova's multihost feature.  I'm skipping
>over a huge amount of context about the Nova-Network and Neutron work,
>since that is a big and ongoing effort. 
>
>DVR is an important feature to have, and we need to ensure that the job
>that tests DVR has a high pass rate.
>
>One thing that I think we need, is to form a group of contributors that
>can help with the DVR feature in the immediate term to fix the current
>bugs, and longer term maintain the feature. It's a big task and I don't
>believe that a single person or company can or should do it by themselves.
>
>The L3 group is a good place to start, but I think that even within the
>L3 team we need dedicated and diverse group of people who are interested
>in maintaining the DVR feature. 
>
>Without this, I think the DVR feature will start to bit-rot and that
>will have a significant impact on our ability to recommend Neutron as a
>replacement for Nova-Network in the future.
>
>-- 
>Sean M. Collins
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Expected cli behavior when ovs-agent is down

[shihanzhang]

hi Vikas Choudhary, when ovs-agent service recover(ovs-agent process restart), 
the dhcp port will not re-binding successfully?





At 2015-08-22 14:26:08, Vikas Choudhary choudharyvika...@gmail.com wrote:

Hi Everybody,


I want to discuss on https://bugs.launchpad.net/neutron/+bug/1348589.This is 
there for more than a year and no discussion i could find on this.


Scenario:
ovs-agent is down and then a network and subnet under this newly created 
network are created using cli. No error visible to user, but following 
irregularities are found.


Discrepancies:
1. neutron port-show dhcp-port shows:
 binding:vif_type  | binding_failed
2. Running ovs-ofctl dump-flows br-tun, no of-flow got added
3. Running ovs-vsctl show br-int, no tag for dhcp-port. 


neutron db will have all the attributes required to retry vif binding.My query 
is when should we trigger this rebinding.Two approaches i could think of are:
1 At neutron server restart, for all ports with vif_type as  binding_failed 
plugins/ml2/drivers/mech_agent.bind_port can be invoked as a sync up activity.


2 In neutron port update api, 
http://developer.openstack.org/api-ref-networking-v2-ext.html , could be 
enhanced to receive vif binding related options also and then eventually 
plugins/ml2/drivers/mech_agent.bind_port can be invoked.Corresponding changes 
will be made to 'port update cli' also.


Please suggest.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] netaddr and abbreviated CIDR format

[shihanzhang]

there was another patch [1] fix the invalid CIDR for subnet.
 
thanks,
   hanzhang, shi


[1] https://review.openstack.org/#/c/201942/


At 2015-08-22 03:33:26, Jay Pipes jaypi...@gmail.com wrote:
On 08/21/2015 02:34 PM, Sean M. Collins wrote:
 So - the tl;dr is that I don't think that we should accept inputs like
 the following:

 x   - 192
 x/y - 10/8
 x.x/y   - 192.168/16
 x.x.x/y - 192.168.0/24

 which are equivalent to::

 x.0.0.0/y   - 192.0.0.0/24
 x.0.0.0/y   - 10.0.0.0/8
 x.x.0.0/y   - 192.168.0.0/16
 x.x.x.0/y   - 192.168.0.0/24

Agreed completely.

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] VPNaaS and DVR compatibility

[shihanzhang]

I have same question, I have filed a bug on launchpad: 
https://bugs.launchpad.net/neutron/+bug/1476469, 
who can help to clarify it?
Thanks,
Hanzhang, shi 






At 2015-08-05 00:33:05, Sergey Kolekonov skoleko...@mirantis.com wrote:

Hi,


I'd like to clarify a situation around VPNaaS and DVR compatibility in Neutron.
In non-DVR case VMs use a network node to access each other and external 
network.
So with VPNaaS enabled we just have additional setup steps performed on network 
nodes to establish VPN connection between VMs.
With DVR enabled two VMs from different networks (or even clouds) should still 
reach each other through network nodes, but if floating IPs are assigned, this 
doesn't work.
So my question is: is it expected and if yes are there any plans to add full 
support for VPNaaS on DVR-enabled clusters?


Thank you.
--

Regards,
Sergey Kolekonov__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron]Subnet's dns nameserver doesn't orderby input

[shihanzhang]

hi, Zhi Chang, 
   this link: #https://bugs.launchpad.net/neutron/+bug/1218629 is ok.




At 2015-07-06 17:13:12, Zhi Chang chang...@unitedstack.com wrote:

Thanks for your reply. Could you send the html link again? This does maybe 
doesn't exist.


Thx
Zhi Chang
 
 
-- Original --
From:  Oleg Bondarevobonda...@mirantis.com;
Date:  Mon, Jul 6, 2015 04:50 PM
To:  OpenStack Development Mailing List (not for usage 
questions)openstack-dev@lists.openstack.org;
Subject:  Re: [openstack-dev] [Neutron]Subnet's dns nameserver doesn't orderby 
input
 
Hi,


Currently there is no dns servers prioritization for subnets in Neutron.

There is an opened bug for this: https://bugs.launchpad.net/neutron/+bug/1218629


Thanks,
Oleg


On Mon, Jul 6, 2015 at 11:21 AM, Zhi Chang chang...@unitedstack.com wrote:

Hi, all
Subnet's nameserver is out of order. That is to say, cmd neutron 
subnet-update [subnet-id] dns_nameservers list=true 1.2.3.4 5.6.7.8 and 
neutron subnet-update [subnet-id] dns_nameservers list=true 5.6.7.8 
1.2.3.4 is same. I think that we often have two or more dns nameservers, one 
is a main nameserver, another is a backup. Therefore, I think we should make 
difference of the above command. 
Does anyone have ideas?


Thx
Zhi Chang



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Issue with neutron-dhcp-agent not recovering known ports cache after restart

[shihanzhang]

hi Shraddha Pandhe,
  I think your analysis is right, I also encountered the same problem， I have 
filed a bug[1] and commit a patch [2] for this bug.


thanks,
  hanzhang shi


[1] https://launchpad.net/bugs/1469615
[2] https://review.openstack.org/#/c/196927/



在 2015-07-01 08:25:48，Shraddha Pandhe spandhe.openst...@gmail.com 写道：

Hi folks..


I have a question about neutron dhcp agent restart scenario. It seems like, 
when the agent restarts, it recovers the known network IDs in cache, but we 
don't recover the known ports [1].


So if a port that was present before agent restarted, is deleted after agent 
restart, the agent wont have it in its cache. So port here [2] will be None. So 
the port will actually never get deleted. 


Same problem will happen if a port is updated. Has anyone seen these issues? Am 
I missing something?


[1] 
https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L82-L87
[2] 
https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L349

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron]Anyone looking at support for VLAN-aware VMs in Liberty?

[shihanzhang]

Hi Eric,


Huawei is also interested in this BP, Hope it can be discussed during the 
design summit.


Thanks,
shihanzhang




在 2015-05-12 08:23:07，Karthik Natarajan natar...@brocade.com 写道：


Hi Eric,

 

Brocade is also interested in the VLAN aware VM’s BP. Let’s discuss it during 
the design summit.

 

Thanks,

Karthik

 

From: Bob Melander (bmelande) [mailto:bmela...@cisco.com]
Sent: Monday, May 11, 2015 9:51 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron]Anyone looking at support for VLAN-aware 
VMs in Liberty?

 

Hi Eric,

 

Cisco is also interested in the kind of VLAN trunking feature that your 
VLAN-aware VM’s BP describe. If this could be achieved in Liberty it’d be great.

Perhaps your BP could be brought up during one of the Neutron sessions in 
Vancouver, e.g., the one on OVN since there seems to be some similarities?

 

Thanks

Bob

 

 

From: Erik Moe erik@ericsson.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Date: fredag 8 maj 2015 06:29
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron]Anyone looking at support for VLAN-aware 
VMs in Liberty?

 

 

Hi,

 

I have not been able to work with upstreaming of this for some time now. But 
now it looks like I may make another attempt. Who else is interested in this, 
as a user or to help contributing? If we get some traction we can have an IRC 
meeting sometime next week.

 

Thanks,

Erik

 

 

From: Scott Drennan [mailto:sco...@nuagenetworks.net]
Sent: den 4 maj 2015 18:42
To:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron]Anyone looking at support for VLAN-aware VMs 
in Liberty?

 

VLAN-transparent or VLAN-trunking networks have landed in Kilo, but I don't see 
any work on VLAN-aware VMs for Liberty.  There is a blueprint[1] and specs[2] 
which was deferred from Kilo - is this something anyone is looking at as a 
Liberty candidate?  I looked but didn't find any recent work - is there 
somewhere else work on this is happening?  No-one has listed it on the liberty 
summit topics[3] etherpad, which could mean it's uncontroversial, but given 
history on this, I think that's unlikely.

 

cheers,

Scott

 

[1]: https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms

[2]: https://review.openstack.org/#/c/94612

[3]: https://etherpad.openstack.org/p/liberty-neutron-summit-topics__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

[shihanzhang]

+1 to deprecate this option


At 2015-03-21 02:57:09, Assaf Muller amul...@redhat.com wrote:
Hello everyone,

The use_namespaces option in the L3 and DHCP Neutron agents controls if you
can create multiple routers and DHCP networks managed by a single L3/DHCP 
agent,
or if the agent manages only a single resource.

Are the setups out there *not* using the use_namespaces option? I'm curious as
to why, and if it would be difficult to migrate such a setup to use namespaces.

I'm asking because use_namespaces complicates Neutron code for what I gather
is an option that has not been relevant for years. I'd like to deprecate the 
option
for Kilo and remove it in Liberty.


Assaf Muller, Cloud Networking Engineer
Red Hat

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] Question about VPNaas

[shihanzhang]

Hi Stacker:


I am a novice, I want  use Neutron VPNaas, through my preliminary 
understanding on this it, I have two questions about it:
(1) why a 'vpnservices' can just has one subnet?
(2) why the subnet of 'vpnservices' can't be changed?
 As I know, the OpenSwan does not has these limitations.
I've learned that there is a BP to do this:
 https://blueprints.launchpad.net/neutron/+spec/vpn-multiple-subnet
 but this BP has been no progress.
 I want to know whether this will do in next cycle or later, who can help 
me to explain? 



Thanks.

-shihanzhang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][sriov] PciDeviceRequestFailed error

[shihanzhang]

I think the problem is in nova, can you show your pci_passthrough_whitelist 
in nova.conf?






At 2014-12-04 18:26:21, Akilesh K akilesh1...@gmail.com wrote:

Hi,
I am using neutron-plugin-sriov-agent.


I have configured pci_whitelist  in nova.conf


I have configured ml2_conf_sriov.ini.


But when I launch instance I get the exception in subject.


On further checking with the help of some forum messages, I discovered that 
pci_stats are empty.
mysql  select hypervisor_hostname,pci_stats from compute_nodes;
+-+---+
| hypervisor_hostname | pci_stats |
+-+---+
| openstack | []|
+-+---+
1 row in set (0.00 sec)



Further to this I found that PciDeviceStats.pools is an empty list too.


Can anyone tell me what I am missing.



Thank you,
Ageeleshwar K
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] FWaaS/Security groups Not blocking ongoing traffic

[shihanzhang]

I also agree file a new bug for FWaaS








At 2014-10-28 00:09:29, Carl Baldwin c...@ecbaldwin.net wrote:
I think I'd suggest opening a new bug for FWaaS since it is a
different component with different code.  It doesn't seem natural to
extend the scope of this bug to include it.

Carl

On Mon, Oct 27, 2014 at 9:50 AM, Itzik Brown itbr...@redhat.com wrote:

 - Original Message -
 From: Carl Baldwin c...@ecbaldwin.net
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Monday, October 27, 2014 5:27:57 PM
 Subject: Re: [openstack-dev] [Neutron] FWaaS/Security groups Not blocking 
 ongoing traffic

 On Mon, Oct 27, 2014 at 6:34 AM, Simon Pasquier spasqu...@mirantis.com
 wrote:
  Hello Itzik,
  This has been discussed lately on this ML. Please see
  https://bugs.launchpad.net/neutron/+bug/1335375.

 This is a good example that any create, update, or delete of a SG rule
 can expose this issue.  This bug only mentions delete.  I'll update
 the bug to increase the scope beyond just deletes because it really is
 the same conntrack issue at the root of the problem.

 Carl

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 Carl,

 FWaaS has the same issues as well.
 What do you suggest - open a new bug or updating the current one?

 Thanks,
 Itzik

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Killing connection after security group rule deletion

[shihanzhang]

Hi, Elena Ezhova, thanks for your work to this problem!
  I agree with your analysis, this why I commit this bug but don't submit patch 
for it.
  I have  want to use conntrack to solve this bug, but I also thought the 
problem you have said:
The problem here is that it is sometimes impossible to tell which 
connection should be killed. For example there may be two instances running in 
different namespaces that have the same ip addresses. As a  compute 
doesn't know anything about namespaces, it cannot distinguish between the two 
seemingly identical connections: 
 $ sudo conntrack -L  | grep 10.0.0.5
 tcp  6 431954 ESTABLISHED src=10.0.0.3 dst=10.0.0.5 
sport=60723 dport=22 src=10.0.0.5 dst=10.0.0.3 sport=22 dport=60723 [ASSURED] 
mark=0 use=1
 tcp  6 431976 ESTABLISHED src=10.0.0.3 dst=10.0.0.5 
sport=60729 dport=22 src=10.0.0.5 dst=10.0.0.3 sport=22 dport=60729 [ASSURED] 
mark=0 use=1


1. I think this problem is due to that in compute node, all tenants  instances 
(if use ovs agent, it use vlan to isolate different tenant instance) are in 
same namespace, so it can't distinguish the connection as above use case.
2. the ip_conntrack works above L3, so it can't  search for a connection by 
destination MAC


I am not clear as ajo said:
  I'm not sure if removing all the conntrack rules that match the certain 
filter would be OK enough, as it may only lead to full reevaluation of rules 
for the next packet of the cleared connections (may be I'm missing some corner 
detail, which could be).








在 2014-10-23 18:22:46，Elena Ezhova eezh...@mirantis.com 写道：

Hi!


I am working on a bug ping still working once connected even after related 
security group rule is deleted 
(https://bugs.launchpad.net/neutron/+bug/1335375). The gist of the problem is 
the following: when we delete a security group rule the corresponding rule in 
iptables is also deleted, but the connection, that was allowed by that rule, is 
not being destroyed.
The reason for such behavior is that in iptables we have the following 
structure of a chain that filters input packets for an interface of an istance:


Chain neutron-openvswi-i830fa99f-3 (1 references)
 pkts bytes target prot opt in out source   destination 

0 0 DROP   all  --  *  *   0.0.0.0/00.0.0.0/0   
 state INVALID /* Drop packets that are not associated with a state. */
0 0 RETURN all  --  *  *   0.0.0.0/00.0.0.0/0   
 state RELATED,ESTABLISHED /* Direct packets associated with a known 
session to the RETURN chain. */
0 0 RETURN udp  --  *  *   10.0.0.3 0.0.0.0/0   
 udp spt:67 dpt:68
0 0 RETURN all  --  *  *   0.0.0.0/00.0.0.0/0   
 match-set IPv43a0d3610-8b38-43f2-8 src
0 0 RETURN tcp  --  *  *   0.0.0.0/00.0.0.0/0   
 tcp dpt:22   rule that allows ssh on port 22  
  
184 RETURN icmp --  *  *   0.0.0.0/00.0.0.0/0   

0 0 neutron-openvswi-sg-fallback  all  --  *  *   0.0.0.0/0 
   0.0.0.0/0/* Send unmatched traffic to the fallback chain. */


So, if we delete rule that allows tcp on port 22, then all connections that are 
already established won't be closed, because all packets would satisfy the 
rule: 
0 0 RETURN all  --  *  *   0.0.0.0/00.0.0.0/0   
 state RELATED,ESTABLISHED /* Direct packets associated with a known 
session to the RETURN chain. */



I seek advice on the way how to deal with the problem. There are a couple of 
ideas how to do it (more or less realistic):
Kill the connection using conntrack
  The problem here is that it is sometimes impossible to tell which 
connection should be killed. For example there may be two instances running in 
different namespaces that have the same ip addresses. As a compute doesn't know 
anything about namespaces, it cannot distinguish between the two seemingly 
identical connections: 
 $ sudo conntrack -L  | grep 10.0.0.5
 tcp  6 431954 ESTABLISHED src=10.0.0.3 dst=10.0.0.5 sport=60723 
dport=22 src=10.0.0.5 dst=10.0.0.3 sport=22 dport=60723 [ASSURED] mark=0 use=1
 tcp  6 431976 ESTABLISHED src=10.0.0.3 dst=10.0.0.5 sport=60729 
dport=22 src=10.0.0.5 dst=10.0.0.3 sport=22 dport=60729 [ASSURED] mark=0 use=1


I wonder whether there is any way to search for a connection by destination MAC?
Delete iptables rule that directs packets associated with a known session to 
the RETURN chain
   It will force all packets to go through the full chain each time and 
this will definitely make the connection close. But this will strongly affect 
the performance. Probably there may be created a timeout after which this rule 
will be restored, but it is uncertain 

Re: [openstack-dev] [neutron][security-groups] Neutron default security groups

[shihanzhang]

As I know there is no a way to disable default security groups, but I think 
this BP can solve this problem:
https://blueprints.launchpad.net/neutron/+spec/default-rules-for-default-security-group



在 2014-09-17 07:44:42，Aaron Rosen aaronoro...@gmail.com 写道：

Hi, 


Inline: 


On Tue, Sep 16, 2014 at 1:00 AM, Fawad Khaliq fa...@plumgrid.com wrote:

Folks,


I have had discussions with some folks individually about this but I would like 
bring this to a broader audience.


I have been playing with security groups and I see the notion of 'default' 
security group seems to create some nuisance/issues.


There are list of things I have noticed so far:
Tenant for OpenStack services (normally named service/services) also ends up 
having default security group. 
Port create operation ends up ensuring default security groups for all the 
tenants as this completely seems out of the context of the tenant the port 
operation takes place. (bug?) 
Race conditions where if system is stressed and Neutron tries to ensure the 
first default security group and in parallel another call comes, Neutron ends 
up trying to create multiple default security groups as the checks for 
duplicate groups are invalidated as soon as the call make past a certain point 
in code.

Right this is a bug. We should catch this foreign key constraint exception here 
and pass as the default security group was already created. We do something 
similar here when ports are created as there is a similar race for 
ip_allocation. 


API performance where orchestration chooses to spawn 1000 tenants and we see 
unnecessary overhead 
For plugins that use RESTful proxy backends require the backend systems to be 
up at the time neutron starts. [Minor, but affects some packaging solutions]


This is probably always a requirement for neutron to work so I don't think it's 
related. 


To summarize, is there a way to disable default security groups? Expected 
answer is no; can we introduce a way to disable it? If that does not make 
sense, should we go ahead and fix the issues around it? 


I think we should fix these bugs you pointed out.  


I am sure some of you must have seen some of these issues and solved them 
already. Please do share how do tackle these issues?


Thanks,

Fawad Khaliq



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OSSN 0020] Disassociating floating IPs does not terminate NAT connections with Neutron L3 agent

[shihanzhang]

Now there is already a bug:https://bugs.launchpad.net/neutron/+bug/1334926 for 
this problem, meanwhile the security group also has same problem, I have report 
a bug:
https://bugs.launchpad.net/neutron/+bug/1335375
 






在 2014-09-16 01:46:11，Martinx - ジェームズ thiagocmarti...@gmail.com 写道：

Hey stackers,


Let me ask something about this... Why not use Linux Conntrack Table at each 
Tenant Namespace (L3 Router) to detect which connections were
made/established over a Floating IP ?


Like this, on the Neutron L3 Router:


--
apt-get install conntrack


ip netns exec qrouter-09b72faa-a5ef-4a52-80b5-1dcbea23b1b6 conntrack -L | grep 
ESTABLISHED



tcp  6 431998 ESTABLISHED src=192.168.3.5 dst=193.16.15.250 sport=36476 
dport=8333 src=193.16.15.250 dst=187.1.93.67 sport=8333 dport=36476 [ASSURED] 
mark=0 use=1
--


Floating IP: 187.1.93.67
Instance IP: 192.168.3.5


http://conntrack-tools.netfilter.org/manual.html#conntrack






Or, as a workaround, right after removing the Floating IP, Neutron might insert 
a temporary firewall rule (for about 5~10 minutes?), to drop the connections of 
that previous Floating IP + Instance IP couple... It looks really ugly but, 
at least, it will make sure that nothing will pass right after removing a 
Floating IP... Effectively terminating (dropping) the NAT connections after 
disassociating a Floating IP... ;-)





Also, I think that NFTables can bring some light here... I truly believe that 
if OpenStack moves to a NFTables_Driver, it will be much easier to: manage 
firewall rules, logging, counters, IDS/IPS, atomic replacements of rules, even 
NAT66... All under a single implementation... Maybe with some kind of 
real-time connection monitoring... I mean, with NFTables, it becomes easier 
to implement a firewall ruleset with a Intrusion Prevention System (IPS), take 
a look:


https://home.regit.org/2014/02/suricata-and-nftables/



So, if NFTables can make Suricata's life easier, why not give Suricata's power 
to Netutron L3 Router? Starting with a new NFTables_Driver... =)


I'm not an expert on NFTables but, from what I'm seeing, it perfectly fits in 
OpenStack, in fact, NFTables will make OpenStack better.


https://home.regit.org/2014/01/why-you-will-love-nftables/



Best!
Thiago


On 15 September 2014 20:49, Nathan Kinder nkin...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Disassociating floating IPs does not terminate NAT connections with
Neutron L3 agent
- ---

### Summary ###
Every virtual instance is automatically assigned a private IP address.
You may optionally assign public IP addresses to instances. OpenStack
uses the term floating IP to refer to an IP address (typically
public) that can be dynamically added to a running virtual instance.
The Neutron L3 agent uses Network Address Translation (NAT) to assign
floating IPs to virtual instances. Floating IPs can be dynamically
released from a running virtual instance but any active connections are
not terminated with this release as expected when using the Neutron L3
agent.

### Affected Services / Software ###
Neutron, Icehouse, Havana, Grizzly, Folsom

### Discussion ###
When creating a virtual instance, a floating IP address is not
allocated by default. After a virtual instance is created, a user can
explicitly associate a floating IP address to that instance. Users can
create connections to the virtual instance using this floating IP
address. Also, this floating IP address can be disassociated from any
running instance without shutting that instance down.

If a user initiates a connection using the floating IP address, this
connection remains alive and accessible even after the floating IP
address is released from that instance. This potentially violates
restrictive policies which are only being applied to new connections.
These policies are ignored for pre-existing connections and the virtual
instance remains accessible from the public network.

This issue is only known to affect Neutron when using the L3 agent.
Nova networking is not affected.

### Recommended Actions ###
There is unfortunately no easy way to detect which connections were
made over a floating IP address from a virtual instance, as the NAT is
performed at the Neutron router. The only safe way of terminating all
connections made over a floating IP address is to terminate the virtual
instance itself.

The following recommendations should be followed when using the Neutron
L3 agent:

- - Only attach a floating IP address to a virtual instance when that
instance should be accessible from networks outside the cloud.
- - Terminate or stop the instance along with disassociating the floating
IP address to ensure that all connections are closed.

The Neutron development team plans to address this issue in a future
version of Neutron.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0020
Original LaunchPad Bug : https://bugs.launchpad.net/neutron/+bug/1334926
OpenStack 

Re: [openstack-dev] [neutron]Performance of security group

[shihanzhang]

hi neutroner!
my patch about 
BP:https://blueprints.launchpad.net/openstack/?searchtext=add-ipset-to-security 
need install ipset in devstack, I have commit the 
patch:https://review.openstack.org/#/c/113453/, who can help me review it, 
thanks very much!


 Best regards,
shihanzhang





At 2014-08-21 10:47:59, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:

+1 NFTablesDriver!


Also, NFTables, AFAIK, improves IDS systems, like Suricata, for example: 
https://home.regit.org/2014/02/suricata-and-nftables/


Then, I'm wondering here... What benefits might come for OpenStack Nova / 
Neutron, if it comes with a NFTables driver, instead of the current IPTables?!


* Efficient Security Group design?
* Better FWaaS, maybe with NAT(44/66) support?
* Native support for IPv6, with the defamed NAT66 built-in, simpler Floating 
IP implementation, for both v4 and v6 networks under a single implementation 
(I don't like NAT66, I prefer a `routed Floating IPv6` version)?
* Metadata over IPv6 still using NAT(66) (I don't like NAT66), single 
implementation?
* Suricata-as-a-Service?!


It sounds pretty cool!   :-)



On 20 August 2014 23:16, Baohua Yang yangbao...@gmail.com wrote:

Great！
We met similar problems.
The current mechanisms produce too many iptables rules, and it's hard to debug.
Really look forward to seeing a more efficient security group design.



On Thu, Jul 10, 2014 at 11:44 PM, Kyle Mestery mest...@noironetworks.com 
wrote:

On Thu, Jul 10, 2014 at 4:30 AM, shihanzhang ayshihanzh...@126.com wrote:

 With the deployment 'nova + neutron + openvswitch', when we bulk create
 about 500 VM with a default security group, the CPU usage of neutron-server
 and openvswitch agent is very high, especially the CPU usage of openvswitch
 agent will be 100%, this will cause creating VMs failed.

 With the method discussed in mailist:

 1) ipset optimization   (https://review.openstack.org/#/c/100761/)

 3) sg rpc optimization (with fanout)
 (https://review.openstack.org/#/c/104522/)

 I have implement  these two scheme in my deployment,  when we again bulk
 create about 500 VM with a default security group, the CPU usage of
 openvswitch agent will reduce to 10%, even lower than 10%, so I think the
 iprovement of these two options are very efficient.

 Who can help us to review our spec?


This is great work! These are on my list of things to review in detail
soon, but given the Neutron sprint this week, I haven't had time yet.
I'll try to remedy that by the weekend.

Thanks!
Kyle


Best regards,
 shihanzhang





 At 2014-07-03 10:08:21, Ihar Hrachyshka ihrac...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Oh, so you have the enhancement implemented? Great! Any numbers that
shows how much we gain from that?

/Ihar

On 03/07/14 02:49, shihanzhang wrote:
 Hi, Miguel Angel Ajo! Yes, the ipset implementation is ready, today
 I will modify my spec, when the spec is approved, I will commit the
 codes as soon as possilbe!





 At 2014-07-02 10:12:34, Miguel Angel Ajo majop...@redhat.com
 wrote:

 Nice Shihanzhang,

 Do you mean the ipset implementation is ready, or just the
 spec?.


 For the SG group refactor, I don't worry about who does it, or
 who takes the credit, but I believe it's important we address
 this bottleneck during Juno trying to match nova's scalability.

 Best regards, Miguel Ángel.


 On 07/02/2014 02:50 PM, shihanzhang wrote:
 hi Miguel Ángel and Ihar Hrachyshka, I agree with you that
 split  the work in several specs, I have finished the work (
 ipset optimization), you can do 'sg rpc optimization (without
 fanout)'. as the third part(sg rpc optimization (with fanout)),
 I think we need talk about it, because just using ipset to
 optimize security group agent codes does not bring the best
 results!

 Best regards, shihanzhang.








 At 2014-07-02 04:43:24, Ihar Hrachyshka ihrac...@redhat.com
 wrote:
 On 02/07/14 10:12, Miguel Angel Ajo wrote:

 Shihazhang,

 I really believe we need the RPC refactor done for this cycle,
 and given the close deadlines we have (July 10 for spec
 submission and July 20 for spec approval).

 Don't you think it's going to be better to split the work in
 several specs?

 1) ipset optimization   (you) 2) sg rpc optimization (without
 fanout) (me) 3) sg rpc optimization (with fanout) (edouard, you
 , me)


 This way we increase the chances of having part of this for the
 Juno cycle. If we go for something too complicated is going to
 take more time for approval.


 I agree. And it not only increases chances to get at least some of
 those highly demanded performance enhancements to get into Juno,
 it's also the right thing to do (c). It's counterproductive to
 put multiple vaguely related enhancements in single spec. This
 would dim review focus and put us into position of getting
 'all-or-nothing'. We can't afford that.

 Let's leave one spec per enhancement. @Shihazhang, what do you
 think?


 Also, I proposed the details of 2, trying

Re: [openstack-dev] [Neutron] Is network ordering of vNICs guaranteed?

[shihanzhang]

Hi Paul, as I know, nova can guarante the ordering of vNICS, can you provide 
the reproduceable test script for this, I am glad to test it








At 2014-08-10 01:16:16, Jay Pipes jaypi...@gmail.com wrote:
Paul, does this friend of a friend have a reproduceable test script for 
this?

Thanks!
-jay

On 08/08/2014 04:42 PM, Kevin Benton wrote:
 If this is true, I think the issue is not on Neutron side but the Nova
 side.
 Neutron just receives and handles individual port requests. It has no
 notion of the order in which they are attached to the VM.

 Can you add the Nova tag to get some visibility to the Nova devs?


 On Fri, Aug 8, 2014 at 11:32 AM, CARVER, PAUL pc2...@att.com
 mailto:pc2...@att.com wrote:

 I’m hearing “friend of a friend” that people have looked at the code
 and determined that the order of networks on a VM is not guaranteed.
 Can anyone confirm whether this is true? If it is true, is there any
 reason why this is not considered a bug? I’ve never seen it happen
 myself.

 __ __

 To elaborate, I’m being told that if you create some VMs with
 several vNICs on each and you want them to be, for example:

 __ __

 __1)__Management Network

 __2)__Production Network

 __3)__Storage Network

 __ __

 You can’t count on all the VMs having eth0 connected to the
 management network, eth1 on the production network, eth2 on the
 storage network.

 __ __

 I’m being told that they will come up like that most of the time,
 but sometimes you will see, for example, a VM might wind up with
 eth0 connected to the production network, eth1 to the storage
 network, and eth2 connected to the storage network (or some other
 permutation.)

 __ __

 __ __


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron]Performance of security group

[shihanzhang]

hi Miguel Ángel and Ihar Hrachyshka,
I agree with you that split  the work in several specs, I have finished the 
work ( ipset optimization), you can do 'sg rpc optimization (without fanout)'.
as the third part(sg rpc optimization (with fanout)),  I think we need talk 
about it, because just using ipset to optimize security group agent codes does 
not bring the best results!


Best regards,
shihanzhang.










At 2014-07-02 04:43:24, Ihar Hrachyshka ihrac...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/07/14 10:12, Miguel Angel Ajo wrote:
 
 Shihazhang,
 
 I really believe we need the RPC refactor done for this cycle, and
 given the close deadlines we have (July 10 for spec submission and 
 July 20 for spec approval).
 
 Don't you think it's going to be better to split the work in
 several specs?
 
 1) ipset optimization   (you) 2) sg rpc optimization (without
 fanout) (me) 3) sg rpc optimization (with fanout) (edouard, you ,
 me)
 
 
 This way we increase the chances of having part of this for the
 Juno cycle. If we go for something too complicated is going to take
 more time for approval.
 

I agree. And it not only increases chances to get at least some of
those highly demanded performance enhancements to get into Juno, it's
also the right thing to do (c). It's counterproductive to put
multiple vaguely related enhancements in single spec. This would dim
review focus and put us into position of getting 'all-or-nothing'. We
can't afford that.

Let's leave one spec per enhancement. @Shihazhang, what do you think?

 
 Also, I proposed the details of 2, trying to bring awareness on
 the topic, as I have been working with the scale lab in Red Hat to
 find and understand those issues, I have a very good knowledge of
 the problem and I believe I could make a very fast advance on the
 issue at the RPC level.
 
 Given that, I'd like to work on this specific part, whether or not
 we split the specs, as it's something we believe critical for 
 neutron scalability and thus, *nova parity*.
 
 I will start a separate spec for 2, later on, if you find it ok, 
 we keep them as separate ones, if you believe having just 1 spec
 (for 1  2) is going be safer for juno-* approval, then we can
 incorporate my spec in yours, but then add-ipset-to-security is
 not a good spec title to put all this together.
 
 
 Best regards, Miguel Ángel.
 
 
 On 07/02/2014 03:37 AM, shihanzhang wrote:
 
 hi Miguel Angel Ajo Pelayo! I agree with you and modify my spes,
 but I will also optimization the RPC from security group agent to
 neutron server. Now the modle is 'port[rule1,rule2...], port...',
 I will change it to 'port[sg1, sg2..]', this can reduce the size
 of RPC respose message from neutron server to security group
 agent.
 
 At 2014-07-01 09:06:17, Miguel Angel Ajo Pelayo 
 mangel...@redhat.com wrote:
 
 
 Ok, I was talking with Édouard @ IRC, and as I have time to
 work into this problem, I could file an specific spec for the
 security group RPC optimization, a masterplan in two steps:
 
 1) Refactor the current RPC communication for 
 security_groups_for_devices, which could be used for full
 syncs, etc..
 
 2) Benchmark  make use of a fanout queue per security group
 to make sure only the hosts with instances on a certain
 security group get the updates as they happen.
 
 @shihanzhang do you find it reasonable?
 
 
 
 - Original Message -
 - Original Message -
 @Nachi: Yes that could a good improvement to factorize the
 RPC
 mechanism.
 
 Another idea: What about creating a RPC topic per security
 group (quid of the
 RPC topic
 scalability) on which an agent subscribes if one of its
 ports is
 associated
 to the security group?
 
 Regards, Édouard.
 
 
 
 
 Hmm, Interesting,
 
 @Nachi, I'm not sure I fully understood:
 
 
 SG_LIST [ SG1, SG2] SG_RULE_LIST = [SG_Rule1, SG_Rule2] .. 
 port[SG_ID1, SG_ID2], port2 , port3
 
 
 Probably we may need to include also the SG_IP_LIST =
 [SG_IP1, SG_IP2] ...
 
 
 and let the agent do all the combination work.
 
 Something like this could make sense?
 
 Security_Groups = {SG1:{IPs:[],RULES:[], 
 SG2:{IPs:[],RULES:[]} }
 
 Ports = {Port1:[SG1, SG2], Port2: [SG1]  }
 
 
 @Edouard, actually I like the idea of having the agent
 subscribed to security groups they have ports on... That
 would remove the need to include all the security groups
 information on every call...
 
 But would need another call to get the full information of a
 set of security groups at start/resync if we don't already
 have any.
 
 
 
 On Fri, Jun 20, 2014 at 4:04 AM, shihanzhang 
 ayshihanzh...@126.com 
 wrote:
 
 
 
 hi Miguel Ángel, I am very agree with you about the
 following point:
 * physical implementation on the hosts (ipsets, nftables,
 ... )
 --this can reduce the load of compute node.
 * rpc communication mechanisms.
 -- this can reduce the load of neutron server can you help
 me to review my BP specs?
 
 
 
 
 
 
 
 At 2014-06-19 10:11:34

Re: [openstack-dev] [neutron]Performance of security group

[shihanzhang]

hi Miguel Angel Ajo Pelayo!
I agree with you and modify my spes, but I will also optimization the RPC from 
security group agent to neutron server. 
Now the modle is 'port[rule1,rule2...], port...', I will change it to 
'port[sg1, sg2..]', this can reduce the size of RPC respose message from 
neutron server to security group agent. 
At 2014-07-01 09:06:17, Miguel Angel Ajo Pelayo mangel...@redhat.com wrote:


Ok, I was talking with Édouard @ IRC, and as I have time to work 
into this problem, I could file an specific spec for the security
group RPC optimization, a masterplan in two steps:

1) Refactor the current RPC communication for security_groups_for_devices,
   which could be used for full syncs, etc..

2) Benchmark  make use of a fanout queue per security group to make
   sure only the hosts with instances on a certain security group get
   the updates as they happen.

@shihanzhang do you find it reasonable?



- Original Message -
 - Original Message -
  @Nachi: Yes that could a good improvement to factorize the RPC mechanism.
  
  Another idea:
  What about creating a RPC topic per security group (quid of the RPC topic
  scalability) on which an agent subscribes if one of its ports is associated
  to the security group?
  
  Regards,
  Édouard.
  
  
 
 
 Hmm, Interesting,
 
 @Nachi, I'm not sure I fully understood:
 
 
 SG_LIST [ SG1, SG2]
 SG_RULE_LIST = [SG_Rule1, SG_Rule2] ..
 port[SG_ID1, SG_ID2], port2 , port3
 
 
 Probably we may need to include also the
 SG_IP_LIST = [SG_IP1, SG_IP2] ...
 
 
 and let the agent do all the combination work.
 
 Something like this could make sense?
 
 Security_Groups = {SG1:{IPs:[],RULES:[],
SG2:{IPs:[],RULES:[]}
   }
 
 Ports = {Port1:[SG1, SG2], Port2: [SG1]  }
 
 
 @Edouard, actually I like the idea of having the agent subscribed
 to security groups they have ports on... That would remove the need to
 include
 all the security groups information on every call...
 
 But would need another call to get the full information of a set of security
 groups
 at start/resync if we don't already have any.
 
 
  
  On Fri, Jun 20, 2014 at 4:04 AM, shihanzhang  ayshihanzh...@126.com 
  wrote:
  
  
  
  hi Miguel Ángel,
  I am very agree with you about the following point:
* physical implementation on the hosts (ipsets, nftables, ... )
  --this can reduce the load of compute node.
* rpc communication mechanisms.
  -- this can reduce the load of neutron server
  can you help me to review my BP specs?
  
  
  
  
  
  
  
  At 2014-06-19 10:11:34, Miguel Angel Ajo Pelayo  mangel...@redhat.com 
  wrote:
  
Hi it's a very interesting topic, I was getting ready to raise
  the same concerns about our security groups implementation, shihanzhang
  thank you for starting this topic.
  
Not only at low level where (with our default security group
  rules -allow all incoming from 'default' sg- the iptable rules
  will grow in ~X^2 for a tenant, and, the
  security_group_rules_for_devices
  rpc call from ovs-agent to neutron-server grows to message sizes of
  100MB,
  generating serious scalability issues or timeouts/retries that
  totally break neutron service.
  
 (example trace of that RPC call with a few instances
   http://www.fpaste.org/104401/14008522/ )
  
I believe that we also need to review the RPC calling mechanism
  for the OVS agent here, there are several possible approaches to breaking
  down (or/and CIDR compressing) the information we return via this api
  call.
  
  
 So we have to look at two things here:
  
* physical implementation on the hosts (ipsets, nftables, ... )
* rpc communication mechanisms.
  
 Best regards,
  Miguel Ángel.
  
  - Mensaje original -
  
   Do you though about nftables that will replace {ip,ip6,arp,eb}tables?
   It also based on the rule set mechanism.
   The issue in that proposition, it's only stable since the begin of the
   year
   and on Linux kernel 3.13.
   But there lot of pros I don't list here (leverage iptables limitation,
   efficient update rule, rule set, standardization of netfilter
   commands...).
  
   Édouard.
  
   On Thu, Jun 19, 2014 at 8:25 AM, henry hly  henry4...@gmail.com 
   wrote:
  
we have done some tests, but have different result: the performance is
nearly
the same for empty and 5k rules in iptable, but huge gap between
enable/disable iptable hook on linux bridge
   
  
On Thu, Jun 19, 2014 at 11:21 AM, shihanzhang  ayshihanzh...@126.com

wrote:
   
  
 Now I have not get accurate test data, but I can confirm the
 following
 points：

   
 1. In compute node, the iptable's chain of a VM is liner, iptable
 filter
 it
 one by one, if a VM in default security group and this default
 security
 group have many members, but ipset chain is set, the time ipset
 filter
 one
 and many member is not much difference

Re: [openstack-dev] [Neutron]One security issue about floating ip

[shihanzhang]

I think this problem also exist in security group!






At 2014-06-27 11:20:31, stanzgy stan@gmail.com wrote:

I have filed this bug on nova
https://bugs.launchpad.net/nova/+bug/1334938




On Fri, Jun 27, 2014 at 10:19 AM, Yongsheng Gong gong...@unitedstack.com 
wrote:

I have reported it on neutron project
https://bugs.launchpad.net/neutron/+bug/1334926




On Fri, Jun 27, 2014 at 5:07 AM, Vishvananda Ishaya vishvana...@gmail.com 
wrote:
I missed that going in, but it appears that clean_conntrack is not done on
disassociate, just during migration. It sounds like we should remove the
explicit call in migrate, and just always call it from remove_floating_ip.

Vish

On Jun 26, 2014, at 1:48 PM, Brian Haley brian.ha...@hp.com wrote:

 Signed PGP part

 I believe nova-network does this by using 'conntrack -D -r $fixed_ip' when the
 floating IP goes away (search for clean_conntrack), Neutron doesn't when it
 removes the floating IP.  Seems like it's possible to close most of that gap
 in the l3-agent - when it removes the IP from it's qg- interface it can do a
 similar operation.


 -Brian

 On 06/26/2014 03:36 PM, Vishvananda Ishaya wrote:
  I believe this will affect nova-network as well. We probably should use
  something like the linux cutter utility to kill any ongoing connections
  after we remove the nat rule.
 
  Vish
 
  On Jun 25, 2014, at 8:18 PM, Xurong Yang ido...@gmail.com wrote:
 
  Hi folks,
 
  After we create an SSH connection to a VM via its floating ip, even
  though we have removed the floating ip association, we can still access
  the VM via that connection. Namely, SSH is not disconnected when the
  floating ip is not valid. Any good solution about this security issue?
 
  Thanks Xurong Yang ___
  OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  ___ OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





--
Best Regards,

Gengyuan Zhang
NetEase Inc.___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] default security group rules in neutron

[shihanzhang]

Hi, Lingxian
I think it indeed backport this feature to neutron, it will be very convenient 
for operators to use default security group!










At 2014-06-23 10:23:39, Lingxian Kong anlin.k...@gmail.com wrote:
Greetings

We use neutron as network functionality implementation in nova, and as
you know, there is a feature called 'os-security-group-default-rules'
in nova extension[1], a hook mechanism to add customized rules when
creating default security groups, which is a very useful feature to
the administrators or operators (at least useful to us in our
deployment). But I found this feature is valid only when using
nova-network.

So, for the functionality parity between nova-network and neutron and
for our use case, I registered a blueprint[2] about default security
group rules in Neutron days ago and related neutron spec[3], and I
want it to be involved in Juno, so we can upgrade our deployment that
time for this feature. I'm ready for the code implementation[3].

But I still want to see what's the community's thought about including
this feature in neutron, any of your feedback and comments are
appreciated!

[1] 
https://blueprints.launchpad.net/nova/+spec/default-rules-for-default-security-group
[2] 
https://blueprints.launchpad.net/neutron/+spec/default-rules-for-default-security-group
[3] https://review.openstack.org/98966
[4] https://review.openstack.org/99320

-- 
Regards!
---
Lingxian Kong

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron]Performance of security group

[shihanzhang]

hi Miguel Ángel,
I am very agree with you about the following point:
  * physical implementation on the hosts (ipsets, nftables, ... )
--this can reduce the load of compute node.
  * rpc communication mechanisms.
  --this can reduce the load of neutron server
can you help me to review my BP specs?










At 2014-06-19 10:11:34, Miguel Angel Ajo Pelayo mangel...@redhat.com wrote:

  Hi it's a very interesting topic, I was getting ready to raise
the same concerns about our security groups implementation, shihanzhang
thank you for starting this topic.

  Not only at low level where (with our default security group
rules -allow all incoming from 'default' sg- the iptable rules
will grow in ~X^2 for a tenant, and, the security_group_rules_for_devices
rpc call from ovs-agent to neutron-server grows to message sizes of 100MB,
generating serious scalability issues or timeouts/retries that 
totally break neutron service.

   (example trace of that RPC call with a few instances
http://www.fpaste.org/104401/14008522/)

  I believe that we also need to review the RPC calling mechanism
for the OVS agent here, there are several possible approaches to breaking
down (or/and CIDR compressing) the information we return via this api call.


   So we have to look at two things here:

  * physical implementation on the hosts (ipsets, nftables, ... )
  * rpc communication mechanisms.

   Best regards,
Miguel Ángel.

- Mensaje original - 

 Do you though about nftables that will replace {ip,ip6,arp,eb}tables?
 It also based on the rule set mechanism.
 The issue in that proposition, it's only stable since the begin of the year
 and on Linux kernel 3.13.
 But there lot of pros I don't list here (leverage iptables limitation,
 efficient update rule, rule set, standardization of netfilter commands...).

 Édouard.

 On Thu, Jun 19, 2014 at 8:25 AM, henry hly  henry4...@gmail.com  wrote:

  we have done some tests, but have different result: the performance is
  nearly
  the same for empty and 5k rules in iptable, but huge gap between
  enable/disable iptable hook on linux bridge
 

  On Thu, Jun 19, 2014 at 11:21 AM, shihanzhang  ayshihanzh...@126.com 
  wrote:
 

   Now I have not get accurate test data, but I can confirm the following
   points：
  
 
   1. In compute node, the iptable's chain of a VM is liner, iptable filter
   it
   one by one, if a VM in default security group and this default security
   group have many members, but ipset chain is set, the time ipset filter
   one
   and many member is not much difference.
  
 
   2. when the iptable rule is very large, the probability of failure that
   iptable-save save the iptable rule is very large.
  
 

   At 2014-06-19 10:55:56, Kevin Benton  blak...@gmail.com  wrote:
  
 

This sounds like a good idea to handle some of the performance issues
until
the ovs firewall can be implemented down the the line.
   
  
 
Do you have any performance comparisons?
   
  
 
On Jun 18, 2014 7:46 PM, shihanzhang  ayshihanzh...@126.com  wrote:
   
  
 

 Hello all,

   
  
 

 Now in neutron, it use iptable implementing security group, but the
 performance of this implementation is very poor, there is a bug:
 https://bugs.launchpad.net/neutron/+bug/1302272 to reflect this
 problem.
 In
 his test, w ith default security groups(which has remote security
 group),
 beyond 250-300 VMs, there were around 6k Iptable rules on evry
 compute
 node,
 although his patch can reduce the processing time, but it don't solve
 this
 problem fundamentally. I have commit a BP to solve this problem:
 https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security

   
  
 
 There are other people interested in this it?

   
  
 

 ___

   
  
 
 OpenStack-dev mailing list

   
  
 
 OpenStack-dev@lists.openstack.org

   
  
 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

   
  
 

   ___
  
 
   OpenStack-dev mailing list
  
 
   OpenStack-dev@lists.openstack.org
  
 
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
 

  ___
 
  OpenStack-dev mailing list
 
  OpenStack-dev@lists.openstack.org
 
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron]Performance of security group

[shihanzhang]

Hello all,


Now in neutron, it use iptable implementing security group, but the performance 
of this  implementation is very poor, there is a 
bug:https://bugs.launchpad.net/neutron/+bug/1302272 to reflect this problem. In 
his test, with default security groups(which has remote security group), beyond 
250-300 VMs, there were around 6k Iptable rules on evry compute node, although 
his patch can reduce the processing time, but it don't solve this problem 
fundamentally. I have commit a BP to solve this 
problem:https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security 
There are other people interested in this it?___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron]Performance of security group

[shihanzhang]

Now I have not get accurate test data, but I  can confirm the following points：
1. In compute node, the iptable's chain of a VM is liner, iptable filter it one 
by one, if a VM in default security group and this default security group have 
many members, but ipset chain is set, the time ipset filter one and many member 
is not much difference.
2. when the iptable rule is very large, the probability of  failure  that  
iptable-save save the iptable rule  is very large.






At 2014-06-19 10:55:56, Kevin Benton blak...@gmail.com wrote:


This sounds like a good idea to handle some of the performance issues until the 
ovs firewall can be implemented down the the line.
Do you have any performance comparisons?

On Jun 18, 2014 7:46 PM, shihanzhang ayshihanzh...@126.com wrote:

Hello all,


Now in neutron, it use iptable implementing security group, but the performance 
of this  implementation is very poor, there is a 
bug:https://bugs.launchpad.net/neutron/+bug/1302272 to reflect this problem. In 
his test, with default security groups(which has remote security group), beyond 
250-300 VMs, there were around 6k Iptable rules on evry compute node, although 
his patch can reduce the processing time, but it don't solve this problem 
fundamentally. I have commit a BP to solve this 
problem:https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security 
There are other people interested in this it?



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-dev][Neutron] Port Mirroring Extension in Neutron

[shihanzhang]

Hi Vinay,
I am very happy to participate in this discussion!






在 2014-05-16 00:03:35，Kanzhe Jiang kanzhe.ji...@bigswitch.com 写道：

Hi Vinay,


I am interested. You could sign up a slot for a Network POD discussion.


Thanks,
Kanzhe



On Thu, May 15, 2014 at 7:13 AM, Vinay Yadhav vinayyad...@gmail.com wrote:

Hi,


I am Vinay, working with Ericsson.


I am interested in the following blueprint regarding port mirroring extension 
in neutron: https://blueprints.launchpad.net/neutron/+spec/port-mirroring


I am close to finishing an implementation for this extension in OVS plugin and 
would be submitting a neutron spec related to the blueprint soon.


I would like to know other who are also interested in introducing Port 
Mirroring extension in neutron.


It would be great if we can discuss and collaborate in development and testing 
this extension


I am currently attending the OpenStack Summit in Atlanta, so if any of you are 
interested in the blueprint, we can meet here in the summit and discuss how to 
proceed with the blueprint.


Cheers,
main(i){putchar((5852758((i-1)/2)*8)-!(1i)*'\r')^89main(++i);}


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev







--
Kanzhe Jiang
MTS at BigSwitch___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] the question of security group rule

[shihanzhang]

Howdy Stackers!


There is a security group problem has been bothering me, but I do not know 
whether is appropriate to consult in there! For a security group rule, it will 
convert to iptable rules in compute node, but a iptable rule '-m state --state 
RELATED,ESTABLISHED -j RETURN' confuse me, according to my understanding this 
rule is to improve the performance of the security group by filteing the first 
package, there are other reasons? 
I hava a use-case: create a securiy group with few securiy group rule, then 
gradually increase the amount of security group rules based on business, if a 
VM in this security group also have connection, the new rules will not take 
effect, how could I deal with such scenarios?___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Interest in discussing vendor plugins for L3 services?

[shihanzhang]

I'm  interested in it. UTC8.
At 2014-02-15 00:31:47,punal patel punal.pa...@gmail.com wrote:

I am interested. UTC - 8.



On Fri, Feb 14, 2014 at 1:48 AM, Nick Ma skywalker.n...@gmail.com wrote:
I'm also interested in it. UTC8.

--

cheers,
Li Ma



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova]Why not allow to create a vm directly with two VIF in the same network

[shihanzhang]

Hi Paul:
  I am very glad to do the thing that puts together the practical use cases in 
which the same VM would benefit from multiple virtual connections to the same 
network, whatever it takes, I think we should at least guarantee the 
consistency of creating vms with nics and attaching nics.




在 2014-01-24 22:33:36，CARVER, PAUL pc2...@att.com 写道：


I agree that I’d like to see a set of use cases for this. This is the second 
time in as many days that I’ve heard about a desire to have such a thing but I 
still don’t think I understand any use cases adequately.

 

In the physical world it makes perfect sense, LACP, MLT, 
Etherchannel/Portchannel, etc. In the virtual world I need to see a detailed 
description of one or more use cases.

 

Shihanzhang, why don’t you start up an Etherpad or something and start putting 
together a list of one or more practical use cases in which the same VM would 
benefit from multiple virtual connections to the same network. If it really 
makes sense we ought to be able to clearly describe it.

 

--

Paul Carver

VO: 732-545-7377

Cell: 908-803-1656

E: pcar...@att.com

Q Instant Message

 

From: Day, Phil [mailto:philip@hp.com]
Sent: Friday, January 24, 2014 09:11
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova]Why not allow to create a vm directly with 
two VIF in the same network

 

I agree its oddly inconsistent (you’ll get used to that over time ;-)  - but to 
me it feels more like the validation is missing on the attach that that the 
create should allow two VIFs on the same network.   Since these are both 
virtualised (i.e share the same bandwidth, don’t provide any additional 
resilience, etc) I’m curious about why you’d want two VIFs in this 
configuration ?

 

From: shihanzhang [mailto:ayshihanzh...@126.com]
Sent: 24 January 2014 03:22
To:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova]Why not allow to create a vm directly with two 
VIF in the same network

 

I am a beginer of nova, there is a problem which has confused me, in the latest 
version, it not allowed to create a vm directly with two VIF in the same 
network, but allowed to add a VIF that it network is same with a existed 
VIF'network, there is the use case that a vm with two VIF in the same network, 
but why not allow to create the vm directly with two VIF in the same network?

 ___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova]Why not allow to create a vm directly with two VIF in the same network

[shihanzhang]

I am a beginer of nova, there is a problem which has confused me, in the latest 
version, it not allowed to create a vm directly with two VIF in the same 
network, but allowed to add a VIF that it network is same with a existed 
VIF'network, there is the use case that a vm with two VIF in the same network, 
but why not allow to create the vm directly with two VIF in the same network?___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] About ports backing floating IPs

[shihanzhang]

I am also perplexed about the ports backing floating ips. when plugin is 
selected  OVS or LB, the ip address belonging to a port backing that floating 
ip is really set on VIF of  'qg-' , what is the port real action?





At 2014-01-15 07:50:36,Salvatore Orlando sorla...@nicira.com wrote:


TL;DR;
I have been looking back at the API and found out that it's a bit weird how 
floating IPs are mapped to ports. This might or might not be an issue, and 
several things can be done about it.
The rest of this post is a boring description of the problem and a possibly 
even more boring list of potential solutions.

Floating IPs are backed by ports on the external network where they are 
implemented; while there are good reason for doing so, this has some seemingly 
weird side effects, which are usually not visible to tenants as only admins are 
allowed (by default) to view the ports backing the floating IPs.


Assigning an external port to a floating IP is an easy way for ensuring the IP 
address used for the floating IP is then not reused for other allocation 
purposes on the external network; indeed admin users might start VMs on 
external networks as well. Conceptually, it is also an example of port-level 
insertion for a network service (DNAT/SNAT).

However these are the tricky aspects:
- IP Address changes: The API allows IP address updates for a floating IP port. 
However as it might be expected, the IP of the floating IP entities does not 
change, as well as the actual floating IP implemented in the backend (l3 agent 
or whatever the plugin uses).
- operational status: It is always down at least for plugins based on OVS/LB 
agents. This is because there is no actual VIF backing a floating IP, so there 
is nothing to wire.
- admin status: updating it just has no effect at all
- Security groups and  allowed address pairs: The API allows for updating them, 
but it is not clear whether something actually happens in the backend, and I'm 
even not entirely sure this makes sense at all. 

Why these things happen, whether it's intended behaviour, and whether it's the 
right behaviour it's debatable.

From my perspective, this leads to inconsistent state, as:
- the address reported in the floating IP entity might differ from the one on 
the port backing the floating IP
- operational status is wrongly represented as down
- expectations concerning operations on the port are not met (eg: admin status 
update)
And I reckon state inconsistencies should always be avoided.

Considering the situation described above, there are few possible options.


1- don't do anything, since the port backing the floating IP is hidden from the 
tenant.
This might be ok provided that a compelling reason for ignoring entities not 
visible to tenants is provided.
However it has to be noted that Neutron authZ logic, which is based on 
openstack.common would allow deployers to change that (*)

2- remove the need for a floating IP to be backed from a port
While this might seem simple, this has non-trivial implications as IPAM logic 
would need to become aware of floating IPs, and should  be discussed further.

3- leverage policy-based APIs, and transform floating IPs in a remote access 
policy
In this way the floating IP will become a policy to apply to a port; it will be 
easier to solve conflicts with security policies and it will be possible to 
just use IPs (or addressing policies) configured on the port.
However, this will be hardly backward compatible, and its feasibility depends 
on the outcome of the more general discussions on policy-based APIs for neutron.

4- Document the current behaviour
This is something which is probably worth doing anyway until a solution is 
agreed upon

Summarising, since all the 'technical' options sounds not feasible for the 
upcoming Icehouse release, it seems worth at least documenting the current 
behaviour, and start a discussion on whether we should do something about this 
and, if yes, what.


Regards and apologies for the long post,
Salvatore

(*) As an interesting corollary, the flexibility of making authZ policies 
super-configurable causes the API to be non-portable. However, this is a 
subject for a different discussion.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] Implement NAPT in neutron (https://blueprints.launchpad.net/neutron/+spec/neutron-napt-api)

[shihanzhang]

I think that these two BP is to achieve same function,it is very necessary to 
implement this function!
https://blueprints.launchpad.net/neutron/+spec/router-port-forwarding
https://blueprints.launchpad.net/neutron/+spec/neutron-napt-api


At 2014-01-09 16:56:20,Nir Yechiel nyech...@redhat.com wrote:





From: Dong Liu willowd...@gmail.com
To: Nir Yechiel nyech...@redhat.com
Cc: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Sent: Wednesday, January 8, 2014 5:36:14 PM
Subject: Re: [neutron] Implement NAPT in neutron 
(https://blueprints.launchpad.net/neutron/+spec/neutron-napt-api)





在 2014年1月8日，20:24，Nir Yechiel nyech...@redhat.com 写道：


Hi Dong,



Can you please clarify this blueprint? Currently in Neutron, If an instance has 
a floating IP, then that will be used for both inbound and outbound traffic. If 
an instance does not have a floating IP, it can make connections out using the 
gateway IP (SNAT using PAT/NAT Overload). Does the idea in this blueprint is to 
implement PAT on both directions using only the gateway IP? Also, did you see 
this one [1]?



Thanks,

Nir



[1] https://blueprints.launchpad.net/neutron/+spec/router-port-forwarding





I think my idea is duplicated with this one. 
https://blueprints.launchpad.net/neutron/+spec/access-vms-via-port-mapping



Sorry for missing this.


[Nir] Thanks, I wasn't familiar with this one. So is there a difference between 
those three?

https://blueprints.launchpad.net/neutron/+spec/router-port-forwarding

https://blueprints.launchpad.net/neutron/+spec/access-vms-via-port-mapping

https://blueprints.launchpad.net/neutron/+spec/neutron-napt-api


Looks like all of them are trying to solve the same challenge using the public 
gateway IP and PAT.




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev