cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Lewis <adr...@alsiconsulting.co.uk>
Subject Super CIDR on a VPC - Why the limitation?
Date Wed, 12 Feb 2014 13:52:30 GMT
Hi All,



Just wondering what the purpose of specifying a "super CIDR" for a VPC
actually is? Reasons for it that I can think of (not even sure of they're
correct) are:

1.       Sets the quickmode selectors for IPsec VPNs

2.       Sets up some form of routing sanity checks such as RPF in the VR

3.       Route summarisation between connected VRs

4.       Feature parity with Amazon VPCs & corresponding API?



Reasons against it:

1.       It seems to be stuck once set and can't be changed should a
customer's network evolve (maybe hacking the DB and rebooting the system
VMs?)

2.       You can only specify one CIDR and can't use 0.0.0.0/0.0.0.0 so
there's no way to use combinations of 10.x.x.x/8, 192.168.x.x/16 and
172.16.x.x/12 in the same VPC

3.       Just seems a little pointless (IMHO) to have such a significant
limitation



The limitations seem to be fairly significant versus the gains to be made
so I was wondering if anyone knew the reasoning behind this. At least, why
not have the ability to specify and/or edit multiple super CIDRs for a VPC
(and perhaps have a default for the initial selection to all RFC 1918 IPs)?



Thanks in advance for any insights and apologies for any stupidity - still
setting up and trying to formulate some best practice procedures as I go
along.



Adrian

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message