Controlling public peering access to Pega Cloud with BGP

Controlling public peering access to Pega Cloud with BGP

Description	Guidance and best practices on using Border Gateway Protocol (BGP) to optimize public peering access to Pega Cloud.
Version as of	8.7
Application	Pega Platform
Capability/Industry Area	Pega Cloud

Introduction

AWS Direct Connect Public Virtual Interface (VIF) provides dedicated connectivity from your enterprise network to public AWS networks.  By working with your enterprise network team, you can implement an AWS Direct Connect Public VIF, either directly or by using the services of your preferred Cloud Exchange provider.

Usage note: Throughout this document, “Direct Connect” refers to AWS Direct Connect Public VIF

Leveraging public peering w/ AWS Direct Connect Public VIF

This connectivity model supports limiting access to your Direct Connect connection to ensure that only the appropriate traffic flows across it.  Since Direct Connect relies on Border Gateway Protocol (BGP) to determine the traffic that traverses the link in both directions, Pega recommends enforcing such restrictions by configuring and tuning BGP settings to meet your organization's requirements.

While Pega does not advise on the complexities of your local network configuration, certain best practices apply. This document contains guidance for controlling the scope of traffic that traverses your Direct Connect connection and avoiding some common configuration errors that can impact the flow of traffic.

Prerequisites

• Understand default behaviors of BGP before establishing a connection.
• Review current AWS documentation, since AWS may add capabilities or change their own defaults at any time.
• If implementing Direct Connect through a Cloud Exchange provider, consult your provider for additional guidance as needed.

BGP guidance and best practices

Limit access and visibility between AWS and your network

AWS offers 3 levels of control for both inbound and outbound routing advertisements:

• Region (the region where your Direct Connect terminates)
• Continent (the continent containing the above region)
• Global

Inbound routes

• Definition: Routes advertised by AWS to your enterprise router.
• Default behavior: AWS advertises all their networks (prefixes) over Direct Connect, using BGP community tags to categorize those networks:

Default tagging and region segmentation

• Tuning options: You can use the tags provided by AWS to limit the networks that you receive from AWS.

Example:

• Your enterprise network team configures the enterprise router to only accept routes for AWS networks in us-east-1, since that is the only region your enterprise networks need to access over Direct Connect:

Filtering inbound routing by using tagging

Outbound routes

• Definition: Routes that you advertise to AWS from your enterprise router.
• Default behavior: If you do not apply any community tags, any networks that you advertise to AWS over Direct Connect are advertised by AWS to all regions, globally:

Outbound routing default behavior

• Tuning options: You can use BGP community tags to limit the scope of AWS’ advertisement of your networks.
• Note: In the two diagrams below, your enterprise network team configured Direct Connect in us-east-1 (not shown, for readability)

Example:

• Your enterprise network team configures the enterprise router to advertise three enterprise networks to AWS, each with a different scope:

BGP community tagging for outbound routes

• Your enterprise network team configures the enterprise router to ensure that the networks it advertises to AWS over Direct Connect are only advertised to AWS region, us-east-1:

Advertising to a single region

Summary

To constrain the AWS resources your Direct Connect connection can access to a specific AWS region or continent:

• Consider filtering both inbound and outbound routing advertisements using standard AWS community tags.

• Plan your inbound and outbound filtering carefully to avoid asymmetric routing, as discussed in later sections of this article.

Limit the scope of the routes seen on your local network and those advertised to AWS

Even when it makes sense to allow certain systems to access all AWS networks over Direct Connect (for example to satisfy a performance or security requirement), you might not want to extend that ability to all enterprise networks. For example, you probably want your end users to reach www.amazon.com over the internet, not over Direct Connect.

Example:

• Your enterprise network team configures the enterprise router to advertise the routes it receives from AWS Direct Connect to the Production Network, but not to the User network.

• Your enterprise network team also configures the enterprise router to advertise the Production Network to AWS over Direct Connect, but not the User Network.

Limiting the scope of routes on local network

• The following diagram shows the resulting traffic flow.  User traffic traverses the internet, while Production Network traffic traverses Direct Connect:

Traffic flow with scope limits

Summary

If certain users or systems do not need to use Direct Connect to reach AWS resources (for example, user traffic to www.amazon.com or any service powered by AWS), do two things to make sure that traffic routes over the internet:

• Make sure those systems do not use IP addresses that fall within your advertised networks.

• Make sure those systems do not see routing advertisements from Direct Connect.

Avoid asymmetric routing and other common mismatches

Asymmetric routing occurs when traffic reaches a network over one path, but replies are sent over a different path. This can cause unexpected behavior and broken communication.

In order to avoid asymmetric routing where Direct Connect is involved, consider the following best practices:

Outbound advertisements match approved routes

• Make sure that your enterprise network team configures the enterprise router to advertise the same networks that were submitted and approved during Direct Connect setup.

Example:

• Your enterprise network team configures the enterprise router to advertise the production network to AWS. This is the same network previously submitted and approved. This initial configuration state applies to all other examples in this section:

Matching advertised routes to approved routes

Traffic is sourced from advertised networks

• Make sure the traffic you send over Direct Connect comes only from IP addresses within those approved and advertised networks.  AWS will reject traffic from other networks.

Example:

• Direct Connect forwards traffic from the production network and rejects traffic from the user network, since these source IP addresses do not fall within the approved and advertised range:

Only send traffic from advertised networks

Inbound and outbound scopes match

• Match the scope of your inbound and outbound routing advertisements, so that the AWS networks to which you connect over Direct Connect also have a path back to you over Direct Connect.

Example 1: Symmetric routing configuration

• The production network has been advertised to AWS and inbound routes from AWS over Direct Connect are visible to the production network; the routing advertisements are as follows:

Symmetrical routing

• The resulting flow of traffic between the Production network and AWS is symmetrical: traffic sent to AWS from the Production network traverses Direct Connect, and return traffic from AWS flows back across the same connection:

Symmetrical traffic flow

Example 2: Asymmetric routing configuration

• The Production network has been advertised to AWS, but a route to AWS networks over Direct Connect has not been made available to the production network; the routing advertisements are as follows:

Asymmetric routing advertisement

• The resulting flow of traffic between the production network and AWS is asymmetrical. Assuming a default route to the internet is available to the production network, that route is used to reach AWS; however, AWS sends responses back to the Production network over Direct Connect. This can cause unexpected behavior and broken communication, because many enterprise network configurations will block or drop this return traffic.

Asymmetrical traffic flow

Summary

In order to avoid routing-related problems with the flow of traffic, configure your Direct Connect connection such that the traffic paths are appropriately mirrored.

Additional options for limiting Direct Connect traffic

If your Pega Cloud applications are the only resources you need to access over Direct Connect and you are considering further traffic restrictions, capabilities for doing this depend on which side of the connection is the traffic initiator.

Egress only

• Definition: In this section, egress refers to traffic initiated by Pega.
• Scenario: You only plan on using Direct Connect for integration traffic, which is outbound traffic initiated by your Pega application, connecting to integration endpoints on your enterprise network (for example, email systems or web service providers). You plan on routing ingress traffic (inbound traffic to Pega from end users or other service consumers) over the internet.
• Capabilities: Pega provides a set of static source IP addresses for egress traffic.

Example:

• If the source IP address for your Pega Cloud application traffic is 1.1.1.1, you can specify that your production network only sees a route to 1.1.1.1 over Direct Connect, even though you will receive all routes from AWS over Direct Connect. When a connection reaches a server on your production network from 1.1.1.1, the response will be sent back over Direct Connect. The routing configuration is as follows:

Filtering for Pega egress traffic

To avoid asymmetric routing (discussed in the previous section), you may need to take additional steps. For example, you may want to use network address translation (NAT) to map your production network source IP addresses to an IP address outside the range of your Direct Connect outbound route advertisement, so that traffic reaching AWS over the internet is not incorrectly sent back via Direct Connect.

• Traffic between 1.1.1.1 and your production network flows over Direct Connect, but traffic to other AWS destinations is routed over the internet. The resulting traffic flow is shown in the diagram below:

Egress traffic flow

Ingress only or both ingress and egress

• Definition: In this section, egress refers to traffic initiated by Pega; ingress refers to traffic initiated by systems or users on your enterprise network.
• Scenario: You plan on using your Direct Connect for inbound traffic to Pega initiated by end users or other services on your network.
• Capabilities: Since Pega application endpoints do not use static destination IP addresses, it is not possible to limit Direct Connect traffic in this situation, other than as discussed previously.  

Summary

If certain users and systems do not need to use Direct Connect to reach AWS resources (for example, user traffic to www.amazon.com or any service powered by AWS), do two things to make sure that traffic routes over the internet:

• Make sure those systems do not use IP address that fall within your advertised networks.

• Make sure those systems do not see routing advertisements from Direct Connect.

Results

By following this design pattern, you should be able to:

1. Implement filtering to ensure you route only appropriate egress traffic over your Direct Connect connection.
2. Implement filtering to ensure you route only appropriate ingress traffic you want over your Direct Connect connection.
3. Avoid asymmetric routing of traffic over your Direct Connect connection.
4. Send Pega Cloud integration traffic over your Direct Connect connection and not all traffic destined for AWS IP address space, such as www.amazon.com.