Open Stack

Yes, you are right, that’s the problem, so , I also prefer to check  the connected route, we should forbid the duplicated connected route, otherwise, connected route can’t recover.
but in physical router, we could add the connected route with different priority, so I’m not sure whether the restriction is necessary. What do you think?

Cheers,
XuRong Yang

发件人: Liping Mao -X (limao - YI JIN XIN XI FU WU(SU ZHOU)YOU XIAN GONG SI at Cisco) [mailto:limao at cisco.com]
发送时间: 2014年7月9日 15:23
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [OpenStack-dev][neutron] add connect rout to router fail after deleteing

Hi,

I’m not sure that I fully understand this, but I think the problem is because you add a route the same with the connected route.
Maybe we need to check if the route is duplicated with the connected route before we add with API?

Thanks.

Regards,
Liping Mao


From: Yangxurong [mailto:yangxurong at huawei.com]
Sent: 2014年7月9日 14:56
To: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [OpenStack-dev][neutron] add connect rout to router fail after deleteing

Hi, neutron stackers,

My use case is as follows:
1. create a router
2. create a network with subnet 4.6.72.0/23
3. attach the above subnet to the router
4. update the router with route {destination: 4.6.72.0/23, nexthop: 4.6.72.10}, success
5. remove the above route from the router, success
6. update the router with the same route again, operation success, but the route isn't added to the router namespace, so not take effect

This problem is caused by removing the connected route, so when adding the route the second time, "ip route replace" command fail.

I think we need to restrict the modification of connected route.
I have reported a bug: https://bugs.launchpad.net/neutron/+bug/1339028
Any thoughts?

Cheers,
XuRong Yang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140709/9a161348/attachment.html>