Hi Neil, Neutron extensions are to be treated as optional (one by one) from an API user point of view. Many reference implementations implement multiple extensions at once in the same plugin and by that may create the (false) expectation the extensions always come together. But as soon as another cloud loads different plugins this expectation is going to break. For example this is the l3 service plugin's extension list: https://github.com/openstack/neutron/blob/8a584171cd505593c69f9149aa58c6aa9b... But another plugin loaded in another cloud may choose to implement a different set of extensions. So I'd argue the client should be more lenient here and accept when the 'routes' attribute is not there. It's another interesting question what may changed in the Calico CI, I'd probably start with this line in the log you linked: 2019-09-26 18:32:52.772 | ++ /opt/stack/new/networking-calico/devstack/plugin.sh:source:98 : inidelete /etc/neutron/neutron.conf DEFAULT service_plugins That tells Neutron not to load any service plugins - including the l3 service plugin. Hope that helps, Bence