On Sun, Mar 11, 2018 at 02:46:31PM +0200, Mark Tinka wrote:
> On 11/Mar/18 14:20, Job Snijders wrote:
> > Folks - i'm gonna cut short here: by sharing the cluster-id across
> > multiple devices, you lose in topology flexibility, robustness, and
> > simplicity.
> 11 years across 3 different networks in separate continents - a shared
> Cluster-ID has never been a problem for me.
> You'll have to do better than that...

"32 years and I've not been hit by a bus, so I can stop looking?"
or perhaps, https://en.wikipedia.org/wiki/Appeal_to_tradition ? :-D

One example where shared Cluster-ID is painful, is the fact that a set
of route-reflector-clients MUST peer with ALL the devices that share
that specific cluster ID. If one client's IBGP session is missing
(perhaps due to misconfiguration), and another client's session is down
(perhaps due to a XPIC or forwarding-plane problem), the view on the
IBGP state becomes incomplete. With unique Cluster-IDs this failure
scenario doesn't exist. The fact that 2 down IBGP sessions can cause
operational issues shows that shared Cluster-ID designs are fragile.

I didn't say that you can't make things work with shared Cluster-IDs,
you'll just have to make sure you stay within the constraints and are
aware of the risks. To me that's just a design choice with no
operational upsides, I'll happily burn the RAM in exchange for
flexibility & robustness.

Kind regards,

cisco-nsp mailing list  cisco-nsp@puck.nether.net
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to