Bug 2032994

Summary: AddressPool IP is not allocated to service external IP wtih aggregationLength 24
Product: OpenShift Container Platform Reporter: Greg Kopels <gkopels>
Component: NetworkingAssignee: Federico Paolinelli <fpaoline>
Networking sub component: Metal LB QA Contact: Greg Kopels <gkopels>
Status: CLOSED ERRATA Docs Contact:
Severity: medium    
Priority: medium CC: cgoncalves, fpaoline, zzhao
Version: 4.10Keywords: Triaged
Target Milestone: ---   
Target Release: 4.10.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-03-10 16:34:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Speaker logs none

Description Greg Kopels 2021-12-15 16:32:03 UTC
Created attachment 1846416 [details]
Speaker logs

Description of problem:
AddressPool IP is not allocated to service external IP when using aggregationLength 24 and addresses: range

Version-Release number of selected component (if applicable):
4.10

How reproducible:
Easily reproducible

Steps to Reproduce:
1. Create a addresspool with address range in specs 3.3.3.2-3.3.3.254
2. Create service of type LoadBalance referencing the addresspool
3. Verify oc get service to see if IP address was allocated to service

Actual results:
nginx-2      LoadBalancer   172.30.100.224   <pending>

Expected results:
nginx-2      LoadBalancer   172.30.26.197   3.3.3.0

Additional info:
An IP is allocated to the external IP service when using addresses: prefix 3.3.3.10/24

Comment 3 Greg Kopels 2021-12-15 16:39:40 UTC
*** Bug 2032995 has been marked as a duplicate of this bug. ***

Comment 5 zhaozhanqi 2022-01-25 03:46:33 UTC
@Greg Kopels Could you help verifying this bug? thanks

Comment 6 Greg Kopels 2022-01-31 08:54:26 UTC
Hi 

I am running cluster version:
NAME      VERSION       AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.10.0-fc.2   True        False         3d23h   Cluster version is 4.10.0-fc.2

I still see the same issue.

I added the output as an attachment.

Thanks Greg

Comment 8 Federico Paolinelli 2022-01-31 13:46:04 UTC
We changed the behaviour allowing the widest CIDR associated to the range.

In your case, the range may correspond to:

3.3.3.2/31
3.3.3.4/30
3.3.3.8/29
3.3.3.16/28
3.3.3.32/27
3.3.3.64/26
3.3.3.128/26
3.3.3.192/27
3.3.3.224/28
3.3.3.240/29
3.3.3.248/30
3.3.3.252/31
3.3.3.254/32

That means that a /26 will be allowed, but a /24 won't.

Comment 9 Greg Kopels 2022-02-02 10:12:29 UTC
Hi 

Okay I validated the bug with a /26 address. Is this documented somewhere? 
Thanks

[gkopels@ test_cases]$ oc get service nginx1
NAME     TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
nginx1   LoadBalancer   172.30.132.228   4.4.4.2       80:30645/TCP   20s

Spec:
  Addresses:
    4.4.4.2-4.4.4.254
  Auto Assign:  false
  Bgp Advertisements:
    Aggregation Length:   26
    aggregationLengthV6:  124
    Communities:
      65535:65282
      7003:007
    Local Pref:  100
  Protocol:      bgp
Events:          <none>

Comment 10 Federico Paolinelli 2022-02-02 10:14:51 UTC
It's not documented, but that's the reasonable thing to do.
You can't advertise a larger cidr that the one you have at your disposal.

Comment 12 zhaozhanqi 2022-02-07 03:45:46 UTC
base on comment 9.  move this bug to verified.

Comment 14 errata-xmlrpc 2022-03-10 16:34:06 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.10.3 security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:0056