Skip to content

Conversation

github-actions[bot]
Copy link

This PR contains a snapshot of zed from upstream stable/zed.

brianphaley and others added 6 commits March 4, 2024 16:19
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 793dfb0)
Previously we would expect duplicates rows from MySQL and then filter
them with _unique_floatingip_iterator. This means that we were
converting rows to ORM-mapped objects unnecessarily. This conversion is
very CPU intensive.

Instead, we can remove the duplicates as a part of the query which means
that only unique rows are returned and the number of conversions from
rows to ORM-mapped objects is reduced significantly. It also means that
the _unique_floatingip_iterator function is no longer needed.

Change-Id: I05136302f7b8abc0a985b91c993008595234ad6b
Signed-off-by: Adam Oswick <adam@adamoswick.co.uk>
(cherry picked from commit 8946684)
(cherry picked from commit f96691b)
iptables-save uses a system-dependent value, usually that
found in /etc/protocols, when 'ipip' is given as the
security group protocol. The intent is to always use the
string value for IP protocol '4', as iptables-save has no
'-n' flag to print values numerically.

This updates a previous change (793dfb0) that hard-coded
that string to 'ipencap', which broke CentOS/Fedora, which
uses 'ipv4'.

For this reason we cannot hard-code anything in neutron-lib,
this needs to be added dynamically, so this one-line change
needs to stay here, and effectively closes the bug.

Closes-bug: #2054324
Change-Id: Ic40b539c9ef5cfa4cbbd6575e19e653342e8342b
(cherry picked from commit cd1d191)
@github-actions github-actions bot requested a review from a team as a code owner April 29, 2024 08:23
@github-actions github-actions bot added automated Automated action performed by GitHub Actions synchronisation labels Apr 29, 2024
@markgoddard markgoddard merged commit c683063 into stackhpc/zed Apr 29, 2024
@markgoddard markgoddard deleted the upstream/zed-2024-04-29 branch April 29, 2024 11:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
automated Automated action performed by GitHub Actions synchronisation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants