Reviewed: https://review.opendev.org/c/openstack/neutron/+/911154 Committed: https://opendev.org/openstack/neutron/commit/cd1d191e335dca707ac9324fd81e642cb453a6cf Submitter: "Zuul (22348)" Branch: master
commit cd1d191e335dca707ac9324fd81e642cb453a6cf Author: Brian Haley <[email protected]> Date: Tue Mar 5 11:59:05 2024 -0500 Use the system-dependent string for IP protocol 4 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 (793dfb04d) 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 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2054324 Title: Iptables rule wrong if created a rule with protocol 4 Status in neutron: Fix Released Bug description: I followed this document to create security group rule for requirement "Allow ingress Protocol IPIP or 4" and I used "ipip" value https://docs.openstack.org/api-ref/network/v2/index.html#create-security-group-rule btw I expected my iptables rule on nova compute is "-A INPUT -s 172.16.2.0/24 -p 4 -j ACCEPT" but the runtime rule in kernel was "-A INPUT -s 172.16.2.0/24 -p ipip -j ACCEPT" and proto number was 94 not 4 // the rules output for one port Chain neutron-linuxbri-idf95737e-7 (1 references) pkts bytes target prot opt in out source destination 115K 219M RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED /* Direct packets associated with a known session to the RETURN chain. */ 0 0 RETURN udp -- * * 0.0.0.0/0 172.16.2.165 udp spt:67 dpt:68 0 0 RETURN udp -- * * 0.0.0.0/0 255.255.255.255 udp spt:67 dpt:68 0 0 RETURN 94 -- * * 172.16.2.0/24 0.0.0.0/0 0 0 RETURN udp -- * * 172.16.2.0/24 0.0.0.0/0 udp dpt:8472 0 0 RETURN tcp -- * * 172.16.2.0/24 0.0.0.0/0 tcp dpt:4240 0 0 RETURN udp -- * * 172.16.2.0/24 0.0.0.0/0 udp multiport dports 30000:32767 1 90 RETURN tcp -- * * 172.16.2.0/24 0.0.0.0/0 tcp dpt:10250 0 0 RETURN tcp -- * * 172.16.2.0/24 0.0.0.0/0 tcp dpt:4245 512 30720 RETURN tcp -- * * 172.16.2.0/24 0.0.0.0/0 tcp multiport dports 30000:32767 0 0 RETURN icmp -- * * 172.16.2.0/24 0.0.0.0/0 0 0 RETURN udp -- * * 172.16.2.0/24 0.0.0.0/0 udp dpt:4789 0 0 RETURN tcp -- * * 172.16.2.0/24 0.0.0.0/0 tcp dpt:4244 2 142 RETURN tcp -- * * 172.16.2.0/24 0.0.0.0/0 tcp dpt:179 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID /* Drop packets that appear related to an existing connection (e.g. TCP ACK/FIN) but do not have an entry in conntrack. */ 14 2122 neutron-linuxbri-sg-fallback all -- * * 0.0.0.0/0 0.0.0.0/0 /* Send unmatched traffic to the fallback chain. */ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2054324/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
