Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

model service network #401

Open
2 tasks
adisos opened this issue Feb 20, 2024 · 6 comments · May be fixed by #896
Open
2 tasks

model service network #401

adisos opened this issue Feb 20, 2024 · 6 comments · May be fixed by #896
Assignees
Labels
Milestone

Comments

@adisos
Copy link
Collaborator

adisos commented Feb 20, 2024

Some of the model's public internet CIDRs (e.g. 161.26.0.0/16) are actually service network and not public internet.
Should model an internal router entity that enables connectivity to service network from each VPC, and remove those CIDRs from public internet.

@kyorav FYI

see https://cloud.ibm.com/docs/cloud-infrastructure?topic=cloud-infrastructure-ibm-cloud-ip-ranges#service-network

  • remove service network cidr from public internet external network list
  • add service network cidrs list, add service network model, update tests
@adisos adisos added the model label Feb 20, 2024
@adisos adisos added this to the v0.4 milestone Feb 20, 2024
@adisos adisos self-assigned this Feb 25, 2024
@adisos adisos modified the milestones: v0.4, v0.5 Apr 9, 2024
@zivnevo zivnevo modified the milestones: v0.5, v0.6 Jun 24, 2024
@zivnevo zivnevo assigned haim-kermany and unassigned adisos Aug 13, 2024
@zivnevo zivnevo modified the milestones: v0.6, v0.7 Aug 13, 2024
@zivnevo zivnevo assigned olasaadi99 and unassigned haim-kermany Sep 10, 2024
@kyorav
Copy link

kyorav commented Sep 26, 2024

From the link in the issue description I think the following CIDRs cover the service network:
10.0.0.0/8
161.26.0.0/16
166.8.0.0/14

@zivnevo
Copy link
Member

zivnevo commented Sep 26, 2024

10.0.0.0/8 doesn't make sense. That a whole lot of IPs.

@kyorav
Copy link

kyorav commented Sep 26, 2024

I know, right? Here is the quote from which I took those ranges (although I admit I don't understand some parts of it):
"
By default, all classic servers and classic gateway and firewall devices are configured with a static route for the 10.0.0.0/8, 161.26.0.0/16 and 166.8.0.0/14 networks to the Back-end Customer Router (BCR). If you configure overlapping routes with those subnets, validate that you have also configured PBR or a similar service. Otherwise, consider using different IP space that doesn't overlap with our service networks for your VPNs or tunnels. Failing to do so can result in the failure to provision your Virtual Servers and Bare Metal Servers.
"

Another option is to somehow scrape the list of CIDRs that follows and stick them into our grouping logic. I don't think we should work with the detailed list, but we have to use CIDRs that compactly contain that list.

@kyorav
Copy link

kyorav commented Sep 26, 2024

If so, we still need to remove it from public network, no? The question is whether VSI's are automatically open to those ranges, and I don't know how to check.

@adisos
Copy link
Collaborator Author

adisos commented Sep 26, 2024

10.0.0.0/8 should not be part of public internet already (see for example https://serverfault.com/questions/304781/ipv4-cidr-ranges-for-everything-except-rfc1918 )

@kyorav
Copy link

kyorav commented Sep 26, 2024

great, then we are left with 161.26.0.0/16 and 166.8.0.0/14.
I verified (visually) that all the CIDRs in the detailed list that are not part of 10.0.0.0/8 are contained in these two.

@olasaadi99 olasaadi99 linked a pull request Sep 30, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants