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, Job _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/