For more details, please see ourCookie Policy.


Deployment architectures in AWS using Brocade vRouter and Automation using Cloud Form templates

by PrasadN on ‎08-28-2016 01:00 PM (2,952 Views)


Brocade vRouter can be deployed in the Amazon Web Services (AWS) public cloud to securely transport the traffic between multiple cloud based or on-premise envinronments. The dynamic routing protocols and VPN can be used together to seamlessly connect the cloud based workloads just like you would use networking in on-premise environments. The vRouter is used as an appliance in Amazon Virtual Private Cloud (VPC) which is the networking layer that AWS services use for connectivity. Although the VPC framework provides extensive networking features to handle the workload traffic, there are some inherent limitations in the scenarios when multiple VPCs are required. Brocade vRouter can used to uniquely address several network designs in VPC.


Before we dive into the deployment architectures, here is a brief overview of the basics of AWS Virtual Private Cloud ( VPC)


 AWS EC2 and VPC

Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale cloud computing easier for developers. Amazon EC2's simple web service interface allows you to obtain and configure capacity with minimal friction. A virtual private cloud (VPC) is a virtual network dedicated to your AWS account. This virtual network closely resembles a traditional network that you'd operate in your own data center, with the benefits of using the scalable infrastructure of AWS. You can configure your VPC; you can select its IP address range, create subnets, and configure route tables, network gateways, and security settings. It is logically isolated from other virtual networks in the AWS cloud. You can launch your AWS resources, such as Amazon EC2 instances, into your VPC.


The need for VPC peering

Most customers use more than one VPC for the enterprise workloads. In a typical scenario a customer starts with a single workload and single VPC. As they expand the migration of applications to the cloud, new applications can be added to the same VPC or a new VPC can be allocated to each new application. Some of the common use-cases for multiple VPCs are application isolation, scope of audit containment, risk-level separation, and separate production from non-production workloads, multi-tenant isolation and business unit alignment. Several different types of VPC designs are used to address these scenarios. One of the common deployment scenario is to use a single VPC to host common services like Active Directory, LDAP, DNS etc.


A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IP addresses. Instances in either VPC can communicate with each other as if they are within the same network. AWS uses the existing infrastructure of a VPC to create a VPC peering connection. However there are many limitations with the current support of VPC Peering[1], some of which are listed below


  • VPC peering is supported between your own VPC or with VPC in another AWS account ONLY with a single region
  • VPC peering is not supported between VPC in different regions
  • VPC peering does not support transitive peering relationships
  • Limit on the number active and pending VPC peering connections that you can have per VPC (125)
  • Cannot have more than one VPC peering connection between the same two VPCs at the same time


Brocade vRouter in VPC peering architectures


Brocade vRouter that is deployed in AWS can be used to support the VPC deployment scenarios and address some of the limitations mentioned above. The vRouter is a multifunctional network element that supports dynamic routing, NAT, VPN etc at a very high scale. It can support upto 4M BGP routes, upto 500 IPsec VPN connections and upto 2.5Gbps of VPN throughput


In architectures that require multiple VPC to communicate to each other, there is a VPC peering connection between VPC A and VPC B and between VPC A and VPC C. There is no VPC peering connection between VPC B and VPC C and traffic cannot be routed directly from VPC B to VPC C through VPC A. To route packets directly between VPC B and VPC C, you will need to create a separate VPC peering connection between them. Furthermore these peering connections are restricted by the VPC peering limitations described above



An alternate method is to use Brocade vRouter to terminate the traffic on a VPC through an IPSec VPN. Using a VPN addresses the issues of peering VPC between regions, between AWS accounts, number of peering connections between VPC and number of peering connections for scenarios that require transitive peering.



As the number of VPC increases, the vRouter in VPC-A can serve as a DMVPN hub and the rest of the VPCs can use a vRouter that is configured as a DMVPN spoke. DMVPN allows spoke to spoke communication without having to configure a full mesh of site-site VPN connections. VPC A can provide centralized and common services to the rest of the VPCs. Some of the upcoming capabilities like VRF can be used to support scenarios where the spokes support overlapping IP addresses.





Automation of VPC deployment using Cloud Formation templates

In the above deployment scenario the VPC A is an ideal candidate to deploy the HA configuration. As described in the previous tech-note, the vRouter can also be deployed in a High-Availability configuration. This scenario can be further automated using AWS Cloud Formation templates. The purpose of this template is to provide a starting point for automated deployment of VPCs that incorporate Brocade vRouter.The templates takes input parameters and deploys a VPC spanning two availability zones, one vRouter in each of the availability zones, public subnet and private subnet  IP addresses for vRouter interfaces, route tables, security groups and CloudWatch recovery alarms


The template and usage instructions can be found at