d17b1a6abb
Map 'ipip' to use the string 'ipencap' so the
IptablesFirewallDriver class in neutron works correctly.
Once neutron-lib is bumped this can be removed.
Add tests for IP protocol 'ipip', '4' and '94' to make
sure the IptablesFirewallDriver class in neutron treats
them correctly.
Long description below.
This is one of those confusing edge cases and I think
Linux is conspiring against us. Let me explain.
1) neutron-lib does correctly define the protocol name 'ipip' as 4.
2) The linux kernel uses the same in in.h:
IPPROTO_IPIP = 4
IPPROTO_BEETPH = 94 (?)
3) iptables maps 'ipip' to 94 and 'ipencap' to 4.
# for num in {0..255}; do iptables -A INPUT -p $num; done
# iptables-save | grep -E 'ipip|ipencap'
-A INPUT -p ipencap
-A INPUT -p ipip
4) /etc/protocols does the same as iptables:
grep -E 'ipencap|ipip' /etc/protocols
ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ``IP'')
ipip 94 IPIP # IP-within-IP Encapsulation Protocol
5) getprotoby{name|number} does what /etc/protocols does:
$ getprotobyname ipip
struct protoent: (0x7fbbbcca9c60)
p_name ipip
p_aliases IPIP
p_proto 94
$ getprotobynumber 4
struct protoent: (0x7fc51ad86be0)
p_name ipencap
p_aliases IP-ENCAP
p_proto 4
Neutron actually builds a mapping based on the getprotoby*
calls, so in the iptables case it winds-up doing the wrong
thing.
Partial-bug: #2054324
Change-Id: Icc84b54be07d39059723d6c233c03aa130102423
(cherry picked from commit
|
||
|---|---|---|
| api-ref | ||
| devstack | ||
| doc | ||
| etc | ||
| neutron | ||
| playbooks | ||
| rally-jobs | ||
| releasenotes | ||
| roles | ||
| tools | ||
| vagrant/ovn | ||
| zuul.d | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .pylintrc | ||
| .stestr.conf | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| README.rst | ||
| TESTING.rst | ||
| bindep.txt | ||
| plugin.spec | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
OpenStack Neutron
Neutron is an OpenStack project to provide "network connectivity as a service" between interface devices (e.g., vNICs) managed by other OpenStack services (e.g., Nova).
To learn more about neutron:
- Documentation: https://docs.openstack.org/neutron/latest/
- Features: https://specs.openstack.org/openstack/neutron-specs
- Defects: https://launchpad.net/neutron
- Release notes: https://docs.openstack.org/releasenotes/neutron/index.html
- Source: https://opendev.org/openstack/neutron
If you would like to contribute to Neutron, please read the file CONTRIBUTING.rst or see the Neutron contributor guide:
https://docs.openstack.org/neutron/latest/contributor/contributing.html
Get in touch via email. Use [Neutron] in your subject.