Hi, There was a discussion about the behaviour of "admin_state_up". You can take a look at the following link: https://bugs.launchpad.net/neutron/+bug/1237807
Changing admin_state_up from True to False will break dhcp. it will remove dhcp service ports from the network but dhcp agent will be alive. To see the difference between network's admin_state_up=True and admin_state_up=False, you can run the following commands: # neutron agent-list (write down dhcp_agent ID) # neutron agent-show 91e15f2f-2e27-460c-a305-a82d9e462c81 (run this command when admin state True) # neutron agent-show 91e15f2f-2e27-460c-a305-a82d9e462c81 (run this command when admin state False - wait a 1 min after you changed admin state from True to False before running this command) ********** When admin state set to TRUE ******************* configurations { "subnets": 1, "use_namespaces": true, "dhcp_lease_duration": 86400, "dhcp_driver": "neutron.agent.linux.dhcp.Dnsmasq", "networks": 1, "ports": 2 } ****** When admin state set to FALSE ********** configurations { "subnets": 0, "use_namespaces": true, "dhcp_lease_duration": 86400, "dhcp_driver": "neutron.agent.linux.dhcp.Dnsmasq", "networks": 0, "ports": 0 } Erhan, On Tue, Jan 20, 2015 at 11:40 AM, Timur Nurlygayanov < tnurlygaya...@mirantis.com> wrote: > Hi Danny, > > I know that if we will set admin_state_up= false we will disable DHCP > service for this network and new VMs will not get network settings by DHCP. > > On Wed, Dec 31, 2014 at 2:41 AM, Danny Choi (dannchoi) <dannc...@cisco.com > > wrote: > >> Hi, >> >> I have a VM with an interface attached to network “provider-net-1” and >> assigned IP 66.0.0.8. >> >> localadmin@qa4:~/devstack$ nova list >> >> >> +--------------------------------------+------+--------+------------+-------------+--------------------------+ >> >> | ID | Name | Status | Task State | >> Power State | Networks | >> >> >> +--------------------------------------+------+--------+------------+-------------+--------------------------+ >> >> | d4815a38-ea64-4189-95b2-fefe82a07b72 | vm-1 | ACTIVE | - | >> Running | provider_net-1=66.0.0.8 | >> >> >> +--------------------------------------+------+--------+------------+-------------+--------------------------+ >> >> Verify ping 66.0.0.8 from the router namespace is successful. >> >> Then I set the admin_state_up = false for the network. >> >> localadmin@qa4:~/devstack$ neutron net-update --admin_state_up=false >> provider_net-1 >> >> Updated network: provider_net-1 >> >> localadmin@qa4:~/devstack$ neutron net-show provider_net-1 >> >> +---------------------------+--------------------------------------+ >> >> | Field | Value | >> >> +---------------------------+--------------------------------------+ >> >> | admin_state_up | False | >> <<<<<<< >> >> | id | 9532b759-68a2-4dc0-bcd4-b372fccabe3c | >> >> | name | provider_net-1 | >> >> | provider:network_type | vlan | >> >> | provider:physical_network | physnet1 | >> >> | provider:segmentation_id | 399 | >> >> | router:external | False | >> >> | shared | False | >> >> | status | ACTIVE | >> >> | subnets | 8e75c110-9b31-4268-ba5c-e130fa139d32 | >> >> | tenant_id | e217fbc20a3b4f4fab49ec580e9b6a15 | >> >> +---------------------------+--------------------------------------+ >> >> Afterwards, the ping is still successful. >> >> I expect the ping to fail since the network admin_state_up= false. >> >> What is the expected behavior? What does it mean when a network's >> admin_state_up = false? >> >> Thanks, >> Danny >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > > Timur, > Senior QA Engineer > OpenStack Projects > Mirantis Inc > > My OpenStack summit schedule: > http://kilodesignsummit.sched.org/timur.nurlygayanov#.VFSrD8mhhOI > > __________________________________________________________________________ > 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