F5 Distributed Cloud makes it easy to connect your AWS, hybrid and multi-cloud environments globally and easy incorporate innovative technologies like AWS VPC Lattice. Our solution combines network-centric and application-centric approaches, creating agility in your organization and enhancing your security posture. This approach allows you to focus on service networking or network routing to solve a wide range of challenges encountered in the MCN domain.

Integrating new features like VPC Lattice into your complex enterprise IT estate is easy with F5. Our solution lets you stretch VPC Lattice across different regions and external environments. In this article we will walk through a network-centric approach and application-centric approach and show you how we can stretch a VPC Lattice anywhere you want it to go. 

Example Topology

In the example topology we start with deployments in EU-NORTH-1, US-WEST-2 and US-EAST-1 where we have deployed applications. These VPCs have unique IP CIDR blocks and can connect them with a network-centric solution using F5 Distributed Cloud Network Connect.

This is a straightforward task where we create a global network object. Think of this as a container to attach our VPCs. 

Next we will configure a Network Connector which creates the policy between the sites to be connected.

Next we configure the sites to join the global network and update the interior routing of the sites towards the F5 CE nodes.

 For example I have added my EU-NORTH-1 site to enable connectivity to and from it's inside network.

Everything is “simple.” You deploy F5 Distributed Cloud CEs to the different sites, and CE nodes will establish IPSEC/SSL tunnels to the F5 Regional Edges and to each other, creating a network topology, with traffic flowing on an encrypted global network. The traffic may flow directly between sites if you have leveraged a site mesh group, or the traffic may traverse the F5 global network if the mesh is not established.

In the image below, you can see that I have 4 sites configured.  Some of the sites of tunnels directly between them and others will traverse an F5 Region Edge.

If we test our network layer connectivity, we will be able to connect end-to-end as long as each site has the internal routing pointing to the CE nodes.

Region

[ec2-user@ip-10-0-25-46 ~]$ ping 10.5.129.216

PING 10.5.129.216 (10.5.129.216) 56(84) bytes of data.

64 bytes from 10.5.129.216: icmp_seq=1 ttl=123 time=76.7 ms

64 bytes from 10.5.129.216: icmp_seq=2 ttl=124 time=96.3 ms

64 bytes from 10.5.129.216: icmp_seq=3 ttl=124 time=107 ms

[ec2-user@ip-10-5-129-216 ~]$ ping 10.200.210.196

PING 10.200.210.196 (10.200.210.196) 56(84) bytes of data.

64 bytes from 10.200.210.196: icmp_seq=1 ttl=125 time=164 ms

64 bytes from 10.200.210.196: icmp_seq=2 ttl=125 time=161 ms

64 bytes from 10.200.210.196: icmp_seq=3 ttl=125 time=162 ms

[ec2-user@ip-10-200-210-196 ~]$ ping 10.0.25.46

PING 10.0.25.46 (10.0.25.46) 56(84) bytes of data.

64 bytes from 10.0.25.46: icmp_seq=1 ttl=125 time=116 ms

64 bytes from 10.0.25.46: icmp_seq=2 ttl=126 time=118 ms

64 bytes from 10.0.25.46: icmp_seq=3 ttl=126 time=116 ms

[ec2-user@ip-10-5-129-216 ~]$ ping 10.0.25.46

PING 10.0.25.46 (10.0.25.46) 56(84) bytes of data.

64 bytes from 10.0.25.46: icmp_seq=21 ttl=125 time=105 ms

64 bytes from 10.0.25.46: icmp_seq=22 ttl=125 time=91.1 ms

64 bytes from 10.0.25.46: icmp_seq=23 ttl=125 time=88.1 ms

[ec2-user@ip-10-200-210-196 ~]$ ping 10.5.129.216

PING 10.5.129.216 (10.5.129.216) 56(84) bytes of data.

64 bytes from 10.5.129.216: icmp_seq=1 ttl=124 time=169 ms

64 bytes from 10.5.129.216: icmp_seq=2 ttl=124 time=162 ms

64 bytes from 10.5.129.216: icmp_seq=3 ttl=124 time=161 ms

[ec2-user@ip-10-0-25-46 ~]$ ping 10.200.210.196

PING 10.200.210.196 (10.200.210.196) 56(84) bytes of data.

64 bytes from 10.200.210.196: icmp_seq=1 ttl=125 time=111 ms

64 bytes from 10.200.210.196: icmp_seq=2 ttl=126 time=110 ms

64 bytes from 10.200.210.196: icmp_seq=3 ttl=126 time=111 ms

Being able to build a network across clouds is critical in modern IT. There is an old saying, "If it PINGs it is not the network".  While PING does provide connectivity, it does not prove that we have a solution that will allow the organization's agility to grow while minimizing complexity (overlapping IPs due to default VPCs ranges, mergers, acquisitions, or simple scale of deployment) and you may have dozens or hundreds of VPCs and accounts that need to be connected in each region, not to mention the sites located outside of AWS.  Let's explore why we will need to move up the stack to stretch VPC Lattice. 

Everything Evolves

The next project requires us to connect a system in EU-NORTH-1 to an application located in US-EAST-1 environment. We head down the same path of “let’s just route it to global network” During the project phase a new challenge is uncovered; one of the applications or APIs that we need to connect to is presented in US-EAST-1 via VPC Lattice.  VPC Lattice was deployed to simplify VPC and account connectivity in the region, and it has created a new challenge because Lattice runs in link local address space.  

DNS lookup of the service in US-EAST-1

[ec2-user@ip-10-0-15-28 ~]$ nslookup hparr-x-svcs.us-east-1.on.aws

Server: 10.0.0.2

Address: 10.0.0.2#53




Non-authoritative answer:

Name: hparr-x-svcs.us-east-1.on.aws

Address: 169.254.171.32

Name: hparr-x-svcs.us-east-1.on.aws

Address: fd00:ec2:80::a9fe:ab20

We cannot just route the 169.254.0.0/16 across our global network.  If we refer to RFC 3927:

A sensible default for applications which are sending from an IPv4 Link-Local address is to explicitly set the IPv4 TTL to 1. This is not appropriate in all cases, as some applications may require that the IPv4 TTL be set to other values. An IPv4 packet whose source and/or destination address is in the 169.254/16 prefix MUST NOT be sent to any router for forwarding, and any network device receiving such a packet MUST NOT forward it, regardless of the TTL in the IPv4 header. Similarly, a router or other host MUST NOT indiscriminately answer all ARP Requests for addresses in the 169.254/16 prefix. A router may of course answer ARP Requests for one or more IPv4 Link-Local address(es) that it has legitimately claimed for its own use, according to the claim-and- defend protocol described in this document. This restriction also applies to multicast packets. IPv4 packets with a Link-Local source address MUST NOT be forwarded outside the local link, even if they have a multicast destination address.

The link local address is not the only obstacle; VPC Lattice leverages the concept of a service network to cross the VPC and account boundaries, and a service network is constrained to a single region.  Routing is not allowed and the virtual network that presents the lattice cannot be "stretched" from US-EAST to EU-NORTH .

We need a new solution…. A network-only solution is not enough. The good thing is that F5 distributed cloud can create application-centric solutions with Distributed Cloud App Connect allowing us to abstract network addresses and network topologies and even preclude the need to directly connect the networks at all, which will increase the security posture of our deployment.

To address this issue, we leverage F5 Distributed Cloud App Connect to present the Application/API to the EU site and present the VPC Lattice based application in US-EAST-1. 

• First we create an Origin Pool on the US-EAST-1 site that points to VPC Lattice on the site.
  
  

• Next we map the pool to a load balancer

• Next we add a host that will match the DNS record we will use to stretch our lattice across sites and clouds.
  
  

•  Finally we present that application to any site we want.  

If you have not already created the DNS records, you will need to do so. In my example, we will use AWS Route 53 and an internal zone and latency-based records that are tied to regions. We can then create an internal DNS record that points directly to our XC nodes inside interfaces or to an internal load balancer that then steers traffic to the XC nodes in EU-NORTH-1.

On our EU-NORTH-1 test instance, we will not resolve the DNS name of f5-demo.stretched.app to one of the CE ENI IPs  (each site has one or more CE nodes).

Trying to access the app over the F5 XC App Connect interface works as desired.  VPC Lattice requires that we transform the headers to match the VPC Lattice hostname (this happens automatically by Distributed Cloud).

If we look at the application response, we see the header transformation and the XFF header showing the client IPs and how the instance in US-EAST-1 directed the traffic into the link local range.

In our discovery of VPC lattice services in US-EAST-1 we are presented with another challenge. The application consists of about 100 APIs, and they have a parallel deployment in US-WEST-2. The SLA requirement is that a single API being out of service in US-EAST-1 cannot force all APIs to move to US-WEST-2. The different APIs have different data stores and operational models. Some are active/active in both locations, and some are only active in one location at a time. To further complicate the SLA, the company has mandated that both regions (EAST and WEST) need to be in production at the same time. Not only do we need to support these APIs we need to do so at scale and make it transparent.  

In our first step we will create DNS records for the US-WEST-2 region pointing to the CE nodes.

Now we will test access to the app in US-EAST-1, which will work because when we deployed the application in the Distributed Cloud console we selected the US-WEST-2 site (you can add/remove sites as necessary over time). 

Great! We have US-WEST-2 reach the US-EAST-1 Lattice app, let's bring up a US-WEST-2 origin. This can be an additional origin pool or it can be by adding servers from US-WEST-2 into the same origin pool.

Example of using two origin pools

Example of how the VPC Lattice service is discovered and added to the pool via local DNS.

Testing Connectivity to the US-WEST-2 service from US-WEST-2.

Testing connectivity: Our EU-NORTH-1 client can send traffic to both US-EAST-1 and US-WEST-2 via the application presented on CE nodes in EU-NORTH-1

We now have a topology where VPC Lattice-based services in one region are exposed in other regions and we can create fault-tolerant patterns for failover, ensuring that if a given URL is offline in one site it can be steered to another site with minimal interruption. 

Stretching To the Edge

What about AWS Outposts? LocalZones? WaveLength? The short answer is yes.  F5 Distributed Cloud can be used to address multiple needs in these deployments.  Such as:

• Providing Load Balancing to applications on these systems.
• Web Application Firewall services
• MultiCloud networking
• VPC Lattice access across regions 

Below you can see access from an Outpost in Frankfort connecting to my Lattice applications in the US by connecting through a CE node deployed on AWS Outpost.

Global Networks and Security

When we focus on connecting networks, we increase the span of our networks, increase their complexity, and increase the challenges in securing them. F5 Distributed Cloud offers network firewall capabilities for network centric solutions. When we move from network connectivity to application connectivity we limit the span of each network. Users connect to a local system, which is then configured to proxy application traffic. For these applications, we can deliver WAF services and visibility tools that span all environments and increase visibility.
 

Reaching Across Clouds and the Internet

Does this work across clouds? Yes.  Does this work in a data center? Yes. Can I use F5 Distributed Cloud to present an application that has VPC Lattice based components to the internet similar to NGINX and BIG-IP ? Yes. 

Can you use F5 Distributed cloud to expose your applications without directly exposing your AWS environment to the internet? Yes.  The F5 Global Network presents your application to the Internet and traffic will be tunneled to the appropriate location. This solution has the added benefit of Global Anycast, DoS /DDoS protections , andCDN capabilities. 

F5 Distributed Cloud provides unique capabilities that pay dividends. With network-centric and application-centric architectures, and the ability to leverage our global network or direct site-mesh connectivity, you can solve the challenges of interconnecting a hybrid/multi-cloud estate where, when, and how it is necessary.