ESnet employs MPLS virtual circuits from our customer sites to VLANs connecting over DX cross connects in US-EAST and US-WEST regions. Exploring the DX provider paradigm we have demonstrated that the billing of the DX network service can be billed to the provider with the compute costs billed directly to the customer. In this way a network provider can cover the shared network resource cost, if desired. While the carrier does provision EBGP, in our use case it was only used for monitoring not for exchanging routes. Each of our customers provision both a public and private/VPC EBGP peering, see public and private DX services. This gets interesting when you realized the routes advertised by AWS differ by geographic region in the public Internet case and when peering with DX AWS advertises a much larger table and recommends that end sites build policies based on the information in this link: https://ip-ranges.amazonaws.com/ip-ranges.json At some point your DX customers will need to make the decision to prefer the public AWS route prefixes that you export to them or those received directly from their DX public EBGP service. -Mike O'Connor On Wed, Mar 2, 2016 at 5:03 AM, James Bensley <jwbensley@gmail.com> wrote:
On 1 March 2016 at 20:41, Michael O'Connor <moc@es.net> wrote:
Jay,
VPC is supported over IPsec if your public path is sufficient into the AWS cloud.
^ This.
I work for a DirectConnect provider, albeit in the UK though. We have fibre links to a AWS edge routers and we have multiple customers seperated by VLANs over a fibre link, each terminating into different VRFs on our edge and the AWS edge. For each customer we have an eBGP session with a virtual gateway that lives inside the customer's VPC domain.
Also for each customer they have backup tunnels using IPSec over the Internet. Again we run eBGP over the IPSec tunnels to the virtual gateway inside each customers VPC domain.
"just works".
James.
-- Michael O'Connor ESnet Network Engineering moc@es.net 631 344-7410