VRF Route Leaking with MP-BGP: routing control for AWS transit VPC

VRF Route Leaking with MP-BGP: routing control for AWS transit VPC

The AWS transit VPC, which adopts a hub-spoke architecture to traverse traffic between other VPCs and on-premises, uses BGP as dynamic routing. VRF route leaking with MP-BGP comes handy to manipulate traffic segmentation.

SSH Public Key Authentication to Access Linux (2)
Jabber Deployment ‘Gotchas'(2): Contact Directory Search Why LDAP?
Jabber Deployment ‘Gotchas'(1): Cisco Unified Communications Manager IM and Presence Centralised Deployment

Introduction

This article describes a lab design and configuration to demonstrate VRF route leaking with multi-protocol (MP) BGP.

VRF route leaking is important to segment routing and precisely control traffic flow.

The AWS transit VPC, which adopts a hub-spoke architecture to traverse traffic between other VPCs and on-premises, uses BGP as dynamic routing. VRF route leaking with MP-BGP comes handy to manipulate traffic segmentation. The AWS transit VPC Cloud Formation template provides any-to-any VPC routing only, which may be inadequate to meet Production requirements.

AWS Transit VPC

AWS Transit VPC includes a pair of routers/firewalls as routing hub.All other VPCs connect to the transit routers/firewalls via AWS site-to-site VPN tunnels, which is established using AWS Virtual Private Gateway and Customer Gateway (Figure: AWS Transit VPC).

Reference: https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc.html

AWS Transit VPC

The above figure depicts an AWS Transit VPC desgin. Gateway VPC and Shared VPC provision common services to Spoke1 and Spoke2 VPCs. Spoke1 and Spoke2 shall communicate with Gateway and Shared VPCs, but shall not communicate with each other.

Each AWS VPC tunnels to a dedicated VRF on the Cisco Cloud Services Router (CSR), provisioned in the Transit VPC. It is for traffic control to avoid any-to-any VPC routing.

Please note, Spoke1 and Spoke2 have the same BGP AS number. It will not cause any issue in the current design. There is no requirement for Spoke1 and Spoke2 to communicate with each other. Therefore, AS path 65100-65535-65100 will not be required; BGP loop prevention does not come into play in this case.

Lab Design

A GNS3 lab is deployed to simulate the AWS Transit VPC. Hub router uses Cisco 7200 router image; while the spoke routers use Cisco 3725 router image. Shall CSR1000v routers be required, please see my previous article on deploying CSR1000v on GNS3.

GNS3 lab VRF route leaking with MP-BGP

Hub router has 4 VRFs configured as below:

Hub router VRF configuration

Each VRF forms BGP peering with its corresponding router. Each spoke router has loopback1 configured with a unique IP. So that we can verify later whether Spoke1 can only communicate with Lo1 interfaces of Gateway and Shared, but not Lo1 of Spoke2. Gateway and Shared shall be able to communicate with the Lo1 interfaces of Spoke1 and Spoke2 and with each other’s Lo1.

The MP-BGP configuration on the Hub router is below.

VRF Route Leaking Design

The diagram below describes the VRF route leaking in the current design.

VRF route leaking design
  • All VRFs export their own routes to a route bucket 65535:9999 – no VRF with the RD required;
  • Only Gateway and Shared VRF import the collected routes from the bucket 65535:9999. In this case, only Gateway and Shared VRF know all routes including Gateway, Shared, Spoke1 and Spoke2;
  • Gateway and Shared export their own routes to individual route buckets, 65535:99 and 65535:2 respectively; and
  • Spoke1 and Spoke2 import the Gateway and Shared routes, 65535:99 and 65535:2 respectively. So that Spoke 1 and 2 can communicate with Gateway and Shared, but not with each other.

Please note, it is also possible to export both Gateway and Shared routes to a common bucket (e.g 65535:9998), and Spoke1 and Spoke2 to import the collected routes from the bucket (e.g. 65535:9998). Route leaking design shall be based upon actual requirements. The current design of exporting and importing Gateway and Shared routes respectively allows the flexibility of fine control if certain spoke only requires the communication with either Gateway or Shared, not both. If not such a requirement, then a common bucket for Gateway and Shared promotes configuration simplicity.

The VRF configuration on the Hub router is below:

Following is the MP-BGP configuration on the Hub router:

Verification

Spoke1 can communicate with Gateway and Shared, but not Spoke2:

Verification – Spoke 1

Spoke2 can communicate with Gateway and Shared, but not Spoke1:

Verification – Spoke2

Gateway can communicate with Spoke1, Spoke2 and Shared.

Verification – Gateway

Shared can communicate with Spoke1, Spoke2 and Gateway.

Verification – Shared

Following screenshot shows the Hub BGP routes in each VRF:

Verification – Hub BGP routes in each VRF

Configuration Details

This section includes the complete configuration on each router.

Hub Configuration

Gateway Configuration

Shared Configuration

Spoke1 Configuration

Spoke2 Configuration

COMMENTS

WORDPRESS: 0
DISQUS: 0