Sunday, December 8, 2013

AWS hybrid cloud – shared customer gateway to multiple VPCs

VPN connection is the most commonly used method to connect enterprise data centers to AWS Virtual Private Cloud. More often than not, enterprises use multiple VPCs, sometimes across multiple regions. For a large enterprise doing business internationally, its global data center footprint can be linked to AWS data centers across multiple continents, thus forming a global hybrid cloud.

Clearly, it is desirable to have a redundant pair of Customer Gateways to terminate multiple VPN connections to multiple VPCs. Having dedicated gateway to each VPC is neither scalable nor cost efficient. Automation will be impossible if new hardware is required each time a new VPC is created.

However, AWS’s current VPN connection creation logic is designed to ensure unique tunnel IP addresses for each connection within a single VPC, but not necessarily across multiple VPCs. In other words, each time a new VPC establishes tunnels to existing customer gateway, there is a real risk that address conflict will bring down existing production traffic.

In this AWS guide, a couple of workarounds are suggested to support connecting a single customer router to multiple VPCs. However, neither workaround is elegant. In the first case, implementing VRF just for the sake of this deficiency creates unnecessary complexity on the customer’s part, not to mention some devices may not support VRF. In the second case, which is essentially trial and error, automated VPN creation through scripting and API becomes extremely cumbersome.

AWS Feature Request
Because each customer gateway is uniquely identifiable (at least within the region), it seems logical (and desirable) for AWS to implement a feature to ensure uniqueness of tunnel address generated for shared customer gateways.
  •    Phase 1 may support uniqueness within the region, as illustrated.
  •     Phase 2 may support uniqueness across multiple regions. In a global hybrid cloud, enterprise data centers may connect to multiple AWS regions in multiple continents.



Friday, November 1, 2013

Nexus 5500 routing anomaly (OSPF stuck in EXSTART)

If you are using Nexus 5500 as a router, watch out for a routing anomaly. Otherwise, you may spend a lot of time debugging, troubleshooting becomes even more challenging when the other router is another vendor’s product.

In a typical scenario when a router is attached to a pair of Nexus 5500, and OSPF adjacency is to be established, the best practice is to run layer 3 Non VPC VLANs on a separate link from VPC trunk, and enable peer-gateway. However, the standard practice will result in OSPF adjacency established for directly connected Nexus 5k only, while the remote Nexu 5k remain in EXSTART.

Turns out, this is due to a little known Cisco bug. As a result, Cisco clearly states “separate link for nonvpc vlans on n5k is not supported”.

Currently the fix release is still pending. So a workaround is required, which is to run both VPC and non-VPC VLANs on VPC peer link.

Before change:
5548-sw1# sh ip ospf nei
OSPF Process ID 1 VRF default
Total number of neighbors: 2
Neighbor ID     Pri State            Up Time  Address         Interface
10.147.187.20  128 EXSTART/DR       00:10:14 10.147.187.20  Vlan110
10.147.254.161 129 FULL/BDR         00:10:12 10.147.187.19  Vlan110

Making change (both Nexus 5k):
5548-sw1# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
5548-sw1(config)# int po10
5548-sw1(config-if)# switchport trunk allowed vlan 110

Must reset OSPF on interface for change to take effect:
5548-sw1(config)# int vlan 110
5548-sw1(config-if)# ip ospf shut
5548-sw1(config-if)# no ip ospf shut
5548-sw1# sh ip ospf nei
OSPF Process ID 1 VRF default
Total number of neighbors: 2
Neighbor ID     Pri State            Up Time  Address         Interface
10.147.187.20  128 FULL/DR          00:00:02 10.147.187.20  Vlan110

10.147.254.161 129 FULL/BDR         00:00:02 10.147.187.19  Vlan110

Sunday, March 31, 2013

Redefining Networking

The networking industry as we know and love is shaken. New concepts emerge almost daily, buzz words abound, various “visions” in their nascent forms mixing reality with fantasy. Beneath the surface of chaos, fundamental changes are taking shape.

Like many network professionals, I feel the need to navigate through the frontal tide of confusion, and grasp the essence of change. Initially, as I swallowed a lot of information, I was easily confused and swayed one way or another. Let’s face it, most materials out there are vendor affiliated, which is inherently partial and biased. But over time, a clearer picture has emerged. However pure and simple, it has given me consistency and continuation in the thought process. I hope it will help you establish your own framework as well, and chart your own course forward.

Virtual Networking – the beginning of change
Let’s start with why, why the change, why now. To me, change is not about doing what networking already does, in a different way. Fundamentally, networking enables communication and supports compute, which enables applications. Compute has gone through its own revolution which is virtualization. Compute virtualization brought networking into the hypervisor environment, thus creating an overlap between two previously separate domains. This rudimentary form of virtual networking can be seen in the form of current generation virtual switches.