| 2016-01-27 14:26:12 |
Hynek Mlnarik |
description |
One of common questions seen at ask.openstack.org and mailing lists is "Why cannot I ping my floating IP address?". Usually, there are common steps in the diagnostics required to answer the question involving pinging the instance, checking security groups settings etc. Currently, these steps need to be performed manually.
neutron-debug command seems to be perfect fit for performing this diagnostics, yet currently it only supports commands related to probe port manipulation and a ping-all command.
This RFE proposes extending neutron-debug with commands that help automating the diagnostics. Commands would be implemented for ping both floating and related fixed IP address, checking whether given TCP port is open, validation of namespaces (check for namespace existence), and indicative diagnosing security groups settings. |
One of common questions seen at ask.openstack.org and mailing lists is "Why cannot I ping my floating IP address?". Usually, there are common steps in the diagnostics required to answer the question involving pinging the instance, checking security groups settings etc. Currently, these steps need to be performed manually.
neutron-debug command seems to be perfect fit for performing this diagnostics, yet currently it only supports commands related to probe port manipulation and a ping-all command.
This RFE proposes extending neutron-debug with commands that help automating the diagnostics. Commands would be implemented for ping both floating and related fixed IP address, checking whether given TCP port is open, validation of namespaces (check for namespace existence), and indicative diagnosing security groups settings.
Proposed Change
===============
This RFE suggest enhancing neutron-debug with a set of commands
that offer more fine-grained commands for diagnostic of networking
setup. Initially, the command is expected to operate either
from network or compute node (depending on the context of the command),
similarly to the current ping-all command of neutron-debug.
Each of the commands outputs a list of tests and whether they passes/failed. The list of commands and the tests follows:
* Diagnose validity of security groups for ping/TCP/UDP traffic
| Command: ``diagnose-secgroups-ping <port-id>``
| Command: ``diagnose-secgroups-tcp --tcp-port <NN> <port-id>``
| Command: ``diagnose-secgroups-udp --udp-port <NN> <port-id>``
Should be run from: any node
This command uses API calls to check whether security groups allow external traffic to go trough to the given port.
* Diagnose validity of router settings and verify that target IP can be pinged directly from the router. Target-IP can be both fixed and floating.
Command: ``diagnose-router <router-id> <target-IP>``
Should be run from: router node
This command depends on actual networking implementation, here Linux/OVS implementation is used for illustration of the tests.
Tests:
* Check if namespace is configured on L3 agent host
* Ping the *target-IP* from DHCP namespace
* Ping the *target-IP* from router namespace
* Check that floating IP is assigned at router [only when target-IP is floating]
* Check that both GW port and port facing LAN are in enabled admin_state_up
Initial release will only support Linux hosts and OVS switches.
**Future work**
The weakness of neutron-debug command is that it cannot be executed remotely. After completing this RFE, the next step would be to transform the current single-node CLI that executes local commands into a CLI and agent. CLI would then be able to invoke commands remotely via RPC, thus eliminating needs to get access to the affected system beforehand.
This architecture would also create a basis upon which GUI diagnostic tools can operate. Demand for this tool can be seen e.g. in
`bug 1507499 <https://bugs.launchpad.net/neutron/+bug/1507499>`_. |
|
