cancel
Showing results for 
Search instead for 
Did you mean: 
Dave_Potter
F5 Employee
F5 Employee

One of the most common headaches in NetOps is thoughtfully planning out internal IP address allocations. How many IP's will be needed? Does the site contain microservices? Will the workloads in a site need to connect to other sites? When it comes to supporting deployments in public clouds, many resources use the exact same CIDR blocks, for example, 10.0.0.0/8, 192.168.0.0/16, and 172.16.0.0/16 - 172.17.0.0/16. With services being spun up automatically, in many situations, the owner of the service may not have any idea which IP addresses to use and simply choose a common default. Having the same IP address used at multiple connected sites poses real challenges for transit routing.

F5 Distributed Cloud Mesh solves the IP Address overlap problem once and for all by exposing apps and services directly from the Global Network, and it steers traffic to independent bakend origin sites using a combination of network proxies and invisible tunnels, all configurable without VPN's and without direct site to site routing.

in the following topology, I have an AWS TGW Site connected to Azure VNET and GCP sites. Because the org contracts out the development of its portfolio services, independent contractors are free to use whatever CIDR blocks they want. In this case, both Azure and GCP are using exact the same CIDR range 10.40.0.0/16.

Picture-MCN-IP_Overlap_Topology.jpg

 

This would be a problem in a traditionally routed network, but using a L7 HTTP or L4 TCP load balancer in Distributed Cloud Mesh, it's simple to deploy a reverse-proxy like service and tunnel connections to where an otherwise unreachable service endpoint may be located.

Consider the following scenario - a company has subcontracted and divided development and QA for part of a service it provides between two independent contractors. Both contractors are connected to the company with a Distributed Cloud Mesh global network, and both contractors use the same CIDR block, 10.40.0.0/16. Users need to access part of the app now developed and hosted by contractor B in GCP. Meanwhile, subcontractor A in Azure still needs to be able to connect to the app and continue validating it. The app is distributed in the following way:

  1. The main ingress to the app continues to be in Azure via an HTTP Load Balancer hosted on F5 Distributed Cloud
  2. A module in AWS calls out to the refer-a-friend module that has just been relocated from contractor A in Azure to contractor B in GCP.
  3. Contractor A in Azure needs to continue to validate the the refer-a-friend module and also needs to the module's endpoint now hosted by contractor B.

Note: Contractors A and B both use the same CIDR block, 10.40.0.0/16.

Distributed Cloud Mesh App Configuration
To provide Contractor A with ssh access to the server and continue to QA the app now running in GCP, an L4 TCP Load Balancer is deployed internally in F5XC with the following YAML configuration.

Origin Pool:

metadata:
  name: gcp-remote-ssh
  namespace: dpotter
  labels: {}
  annotations: {}
  description: null
  disable: null
spec:
  origin_servers:
    - private_ip:
        ip: 10.40.0.4
        site_locator:
          site:
            tenant: tme-lab-works-oeaclgke
            namespace: system
            name: dp-gcp-vpc-2
        outside_network: {}
      labels: {}
  no_tls: {}
  port: 22
  same_as_endpoint_port: {}
  healthcheck: null
  loadbalancer_algorithm: LB_OVERRIDE
  endpoint_selection: LOCAL_PREFERRED
  advanced_options: null
resource_version: null

TCP Load Balancer:

metadata:
  name: same-cidr-other-site
  namespace: dpotter
  labels: {}
  annotations: {}
spec:
  domains:
    - same-cidr-other-site.demo.internal
  listen_port: 2022
  origin_pools: []
  origin_pools_weights:
    - pool:
        tenant: tme-lab-works-oeaclgke
        namespace: dpotter
        name: gcp-remote-ssh
      weight: 1
      priority: 1
      endpoint_subsets: {}
  advertise_custom:
    advertise_where:
      - site:
          network: SITE_NETWORK_INSIDE_AND_OUTSIDE
          site:
            tenant: tme-lab-works-oeaclgke
            namespace: system
            name: azure-vnet-wus2
        use_default_port: {}
  hash_policy_choice_round_robin: {}
  idle_timeout: 3600000
  retract_cluster: {}
  dns_info: []

With the above configuration, connections to hostname same-cidr-other-site.demo.internal:2022 from Contractor A in Azure will now be proxied and tunneled by the Distributed Cloud Platform to the server on TCP/22 running in GCP hosted by Contractor B. This makes it possible for Contractor A to continue to QA and validate the module now developed by Contractor B, while also preserving the original workflow:

Internet > External Ingress > Azure, and now from Azure > GCP.

Validation

  1. No direct access between Contractors A and B
    root@dpotter-appserver:/home/azureuser# ping 10.40.0.4
    PING 10.40.0.4 (10.40.0.4) 56(84) bytes of data.
    ^C
    --- 10.40.0.4 ping statistics ---
    3 packets transmitted, 0 received, 100% packet loss, time 2050ms
    
    root@dpotter-appserver:/home/azureuser# ping 10.40.0.5
    PING 10.40.0.5 (10.40.0.5) 56(84) bytes of data.
    ^C
    --- 10.40.0.5 ping statistics ---
    3 packets transmitted, 0 received, 100% packet loss, time 2039ms
  2. SSH is allowed from Contractor A to the module's server now owned by Contractor B despite both contractors using the same CIDR block (10.40.0.0/16)
    Client side:

    root@dpotter-appserver:/home/azureuser# telnet same-cidr-other-site.demo.internal 2022
    Trying 10.40.0.5...
    Connected to same-cidr-other-site.demo.internal.
    Escape character is '^]'.
    SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.2
    ^]q
    
    telnet> q
    Connection closed.
    root@dpotter-appserver:/home/azureuser#

    Server side:

    root@docker-ubuntu-20-2-vm:/home/da.potter# tcpdump -ni ens4 tcp port 22
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on ens4, link-type EN10MB (Ethernet), capture size 262144 bytes
    22:26:23.941910 IP 10.40.0.3.51675 > 10.40.0.4.22: Flags [S], seq 3472146549, win 65535, options [mss 1132,nop,wscale 9,sackOK,TS val 2217414740 ecr 0], length 0
    22:26:23.941965 IP 10.40.0.4.22 > 10.40.0.3.51675: Flags [S.], seq 2409916872, ack 3472146550, win 64768, options [mss 1420,sackOK,TS val 316240982 ecr 2217414740,nop,wscale 7], length 0
    22:26:23.953482 IP 10.40.0.3.51675 > 10.40.0.4.22: Flags [.], ack 1, win 2048, options [nop,nop,TS val 2217414750 ecr 316240982], length 0
    22:26:23.963366 IP 10.40.0.4.22 > 10.40.0.3.51675: Flags [P.], seq 1:42, ack 1, win 506, options [nop,nop,TS val 316241004 ecr 2217414750], length 41

Conclusion
IP Address Overlap is no longer a problem, and isn't even a concern when using Distributed Cloud Mesh global networks to connect sites with apps distributed between them. Using TCP Load Balancers with internally advertised VIPs, it's easy to maintain service level connectivity between sites even when the sites and services use the exact same IP addresses.

Version history
Last update:
‎09-Aug-2022 12:20
Updated by:
Contributors