> Job Snijders [mailto:j...@ntt.net] > Sent: Sunday, March 11, 2018 10:51 AM > > On Sun, Mar 11, 2018 at 12:39:13PM +0200, Mark Tinka wrote: > > Each major PoP has been configured with its unique, global Cluster-ID. > > > > This has been scaling very well for us. > > > > I think the Multiple Cluster-ID is overkill. > > Have you considered the downsides of sharing a Cluster-ID across multiple > boxes, and do you have any arguments to support why it is overkill? > If RR1s and RR2s never talk to each to each other then it doesn't matter whether they have common or unique Cluster-IDs > > > Also if you carry a mix of full internet prefixes and VPN prefixes > > > across your backbone, then I suggest you carve up one iBGP > > > infrastructure for VPN prefixes and a separate one for the Internet > > > prefixes (for stability and security reasons -and helps with scaling > > > too if that's a concern). > > > > We use the same RR for all address families. Resources are plenty with > > a VM-based RR deployment. > > Are you at least using separate BGP sessions for each address families? > Job is right, you should at least use separate TCP sessions for different AFs, but if you have Internet prefixes carried by VMPv4 then you're still at danger, unless you carve up a separate BGP process or iBGP infrastructure for Internet prefixes, yes the BGP Attribute Filter and Enhanced Attribute Error Handling should keep you relatively safe but I wouldn't count on it (it's still not an RFC and I haven't dig into it for years so not sure where are vendors at with addressing all the requirements in the draft). Internet is a wild west with universities advertising unknown attributes and operators prepending their AS 255+ times and you can only hope that any of such events will bring your border PE sessions down and actually won't be relied to your RRs which then start dropping sessions to all clients or restarting BGP/RPD processes... Hence my requirement for dedicated iBGP infrastructure for Internet prefixes.
> > The RR's are out-of-path, so are not part of our IP/MPLS data plane. > > Are you using optimal route reflection, or how have you mitigated negative > effects caused by the lack of ORR? > One fact that people usually overlook with ORR in MPLS backbones is that ORR actually requires prefixes to be the same when they arrive at the RRs so RRs can ORR on the best and second best to a particular set of clients. And my experience is that usually operators are using Type 1 RDs in their backbones (so PE's-RID:VPN-ID format) -a that was the only way how to get ECMP or BGP-PIC/local-repair working ages before Add-Path got introduced. And in case of Type 1 RDs the ORR is useless as RRs in this case are merely reflecting routes and are not performing any path selection on behalf of clients. So the only way how to make use of ORR is to completely change your RD plan to Type 0 RDs VPN by VPN (maybe starting with Internet VRF) and introduce add-path as a prerequisite of course. adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: _______________________________________________ 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/