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
793dfb04d0