AWS Elastic IP architecture

Christopher Morrow morrowc.lists at gmail.com
Thu May 28 17:08:32 UTC 2015


On Thu, May 28, 2015 at 11:44 AM, Luan Nguyen (CBU)
<luan.nguyen at dimensiondata.com> wrote:
> What I am trying to get at is yeah, you still need the l2 extension
> encapsulation, but on top you need something for disaster recovery, machines
> mobility between data centers, sort of like Vshield Edge using NAT – you can

probably what the vm mobilty looks like is a change in the L2 path,
right? why make it anymore complicated than that? inside a single
availability domain I would expect the L2 domain a vm sees doesn't
change, even if the VM itself is moved from physical machine to
physical machine.

making it more complex at the vm level is probably a bunch of work
that doesn't have to happen.

> change the NAT pool and update the DNS record, but the internal would remain

that sounds like a bunch of work though, which I don't think is really
necessary. I'm just a plumber, though so I don't actually know what
anyone does with this stuff.

> the same no matter where you move it to. LISP seems like a simple
> solution…so as specific host route injection, which for enterprise shouldn’t

lisp wasn't really finalized (still sort of isn't) when aws/ec2
started going like gang busters. They might have changed technology
under the hood, but it doesn't seem like they would have had to (not
in a drastic 'change encap type' sort of way at least).

> be much of a problem, but DRaaS cloud provider, this could ballooning the
> routing table pretty quickly.

how so? does the external and internal view from the vm have to be the
same? do the public /32's have to be individually routed ? inside what
scope at the datacenter?

> What does Google use? :)

no idea, probably rabbits with different colored carrots?



More information about the NANOG mailing list