On 12/Mar/18 19:36, adamv0...@netconsultings.com wrote:
> Cluster-ID saves RAM only if RR1 and RR2 are connected like in your
> case, if they are not and RR1s only talk to RR1 in other POPs and RR2s
> only talk to RR2s in other POPs/Clusters then the Cluster-ID is just
> for loop prevention really.
Not sure why you'd want to partition RR iBGP adjacencies.
I believe in fully meshing all RR's, regardless of cluster location.
> And on a side note,
> Although Cluster-ID saves some RAM in case RR1 and RR2 are connected
> and configured with the same Cluster-ID –it doesn’t save CPU cycles
> (and RAM necessary for particular RIB out/RIB in) where RR1 sends
> couple Mill of prefixes to RR2 only for RR2 to drop all of those (well
> apart form couple of the odd prefixes originated by RR1) and vice
> versa in the opposite direction.
True, but in our case, RAM would be more precious than CPU (remember, we
are running our RR's on a VM sitting on top of a multi-core x86 platform).
The CSR1000v images come with differing levels of supported memory for
its own operations. It's not a function of the hardware; it's a function
of the state-of-the-art of the actual VM image itself.
So you might have as much as 768GB of RAM on the hardware, but the VM is
only setup to support 4GB, or 8GB, or 16GB, or 32GB, or... The amount of
RAM the VM image will support increases with every iteration of the
cisco-nsp mailing list firstname.lastname@example.org
archive at http://puck.nether.net/pipermail/cisco-nsp/