model service network

[adisos]

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

[kyorav]

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]

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

[kyorav]

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]

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]

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]

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.