View source for Controlling Public Peering Access to Pega Cloud with BGP

Controlling Public Peering Access to Pega Cloud with BGP / ← Controlling public peering access to Pega Cloud with BGP

You do not have permission to edit this page, for the following reasons:

• The action you have requested is limited to users in the group: editor.
• The action you have requested is limited to users in one of the groups: editor, Administrators.

---

You can view and copy the source of this page.

{{Design pattern|Title=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=8.7|Applications=Pega Platform|Capability Area=Pega Cloud|Owner=Dara Brosseau}} ==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'' [[File:Direct Connect Public VIF - routing considerations - high level1.jpg|center|thumb|627x627px|Leveraging public peering w/ AWS Direct Connect Public VIF|link=Special:FilePath/Direct_Connect_Public_VIF_-_routing_considerations_-_high_level1.jpg]] 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 ==== * <u>Definition</u>: Routes advertised ''by'' AWS ''to'' your enterprise router. * <u>Default behavior</u>: AWS advertises all their networks (prefixes) over Direct Connect, using BGP community tags to categorize those networks: [[File:Direct Connect Public VIF - routing considerations - inbound filter1.jpg|center|thumb|630x630px|Default tagging and region segmentation|link=Special:FilePath/Direct_Connect_Public_VIF_-_routing_considerations_-_inbound_filter1.jpg]] * <u>Tuning options</u>: You can use the tags provided by AWS to limit the networks that you receive from AWS. <u>Example</u>: * 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: [[File:Direct Connect Public VIF - routing considerations - inbound filter2.jpg|center|thumb|628x628px|Filtering inbound routing by using tagging|link=Special:FilePath/Direct_Connect_Public_VIF_-_routing_considerations_-_inbound_filter2.jpg]] ==== Outbound routes ==== * <u>Definition</u>: Routes that you advertise ''to'' AWS ''from'' your enterprise router. * <u>Default behavior</u>: 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: [[File:Direct Connect Public VIF - routing considerations - outbound filter-defaults1.jpg|center|thumb|632x632px|Outbound routing default behavior|link=Special:FilePath/Direct_Connect_Public_VIF_-_routing_considerations_-_outbound_filter-defaults1.jpg]] * <u>Tuning options</u>: 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)'' <u>Example</u>: * Your enterprise network team configures the enterprise router to advertise three enterprise networks to AWS, each with a different scope: [[File:Direct Connect Public VIF - routing considerations - outbound filter1 (1).jpg|center|thumb|636x636px|BGP community tagging for outbound routes|link=Special:FilePath/Direct_Connect_Public_VIF_-_routing_considerations_-_outbound_filter1_(1).jpg]] * 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: [[File:Direct Connect Public VIF - routing considerations - outbound filter2 (1).jpg|center|thumb|632x632px|Advertising to a single region|link=Special:FilePath/Direct_Connect_Public_VIF_-_routing_considerations_-_outbound_filter2_(1).jpg]] ==== 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. <u>Example</u>: * 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. [[File:Direct Connect Public VIF - routing considerations - limit scope-routes.jpg|center|thumb|632x632px|Limiting the scope of routes on local network|link=Special:FilePath/Direct_Connect_Public_VIF_-_routing_considerations_-_limit_scope-routes.jpg]] * The following diagram shows the resulting traffic flow.  User traffic traverses the internet, while Production Network traffic traverses Direct Connect: [[File:Direct Connect Public VIF - routing considerations - limit scope- traffic.jpg|center|thumb|632x632px|Traffic flow with scope limits|link=Special:FilePath/Direct_Connect_Public_VIF_-_routing_considerations_-_limit_scope-_traffic.jpg]] ==== 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. <u>Example</u>: * 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: [[File:Direct Connect Public VIF - routing considerations - asym1.jpg|center|thumb|632x632px|Matching advertised routes to approved routes|link=Special:FilePath/Direct_Connect_Public_VIF_-_routing_considerations_-_asym1.jpg]] ==== 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. <u>Example</u>: * 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: [[File:Direct Connect Public VIF - routing considerations - asym2.jpg|center|thumb|632x632px|Only send traffic from advertised networks|link=Special:FilePath/Direct_Connect_Public_VIF_-_routing_considerations_-_asym2.jpg]] ==== 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. <u>Example 1: Symmetric routing configuration</u> * 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: [[File:Direct Connect Public VIF - routing considerations - asym3.jpg|center|thumb|632x632px|Symmetrical routing|link=Special:FilePath/Direct_Connect_Public_VIF_-_routing_considerations_-_asym3.jpg]] * 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: [[File:Direct Connect Public VIF - routing considerations - asym4.jpg|center|thumb|632x632px|Symmetrical traffic flow|link=Special:FilePath/Direct_Connect_Public_VIF_-_routing_considerations_-_asym4.jpg]]<u>Example 2: Asymmetric routing configuration</u> * 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: [[File:Direct Connect Public VIF - routing considerations - asym5.jpg|center|thumb|632x632px|Asymmetric routing advertisement|link=Special:FilePath/Direct_Connect_Public_VIF_-_routing_considerations_-_asym5.jpg]] * 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. [[File:Direct Connect Public VIF - routing considerations - asym6-new.jpg|center|thumb|632x632px|Asymmetrical traffic flow|link=Special:FilePath/Direct_Connect_Public_VIF_-_routing_considerations_-_asym6-new.jpg]] ==== 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 ==== *<u>Definition</u>: In this section, egress refers to traffic initiated by Pega. * <u>Scenario</u>: 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. * <u>Capabilities</u>: Pega provides a set of static source IP addresses for egress traffic. <u>Example</u>: * 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: [[File:Direct Connect Public VIF - routing considerations - egress-route.jpg|center|thumb|632x632px|Filtering for Pega egress traffic |link=Special:FilePath/Direct_Connect_Public_VIF_-_routing_considerations_-_egress-route.jpg]]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: [[File:Direct Connect Public VIF - routing considerations - egress-flow.jpg|center|thumb|632x632px|Egress traffic flow|link=Special:FilePath/Direct_Connect_Public_VIF_-_routing_considerations_-_egress-flow.jpg]] ==== Ingress only or both ingress and egress ==== *<u>Definition</u>: In this section, egress refers to traffic initiated by Pega; ingress refers to traffic initiated by systems or users on your enterprise network. * <u>Scenario</u>: You plan on using your Direct Connect for inbound traffic to Pega initiated by end users or other services on your network. * <u>Capabilities</u>: 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: # Implement filtering to ensure you route only appropriate egress traffic over your Direct Connect connection. # Implement filtering to ensure you route only appropriate ingress traffic you want over your Direct Connect connection. # Avoid asymmetric routing of traffic over your Direct Connect connection. # 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.

Return to Controlling public peering access to Pega Cloud with BGP.