Oh I see that makes sense, if all your revenue is in Internet services then of course it’s hard to justify building separate iBGP infrastructure to protect the handful of pure VPN customers.
With regards to ORR, are you using add-path already or RRs are doing all the path selection on behalf of clients please? adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: From: Mark Tinka [mailto:mark.ti...@seacom.mu] Sent: Monday, March 12, 2018 2:41 PM To: adamv0...@netconsultings.com; 'Job Snijders' Cc: 'Curtis Piehler'; 'Cisco Network Service Providers' Subject: Re: [c-nsp] IOS-XR BGP RR MCID (Multiple Cluster ID) On 12/Mar/18 13:02, adamv0...@netconsultings.com <mailto:adamv0...@netconsultings.com> wrote: If RR1s and RR2s never talk to each to each other then it doesn't matter whether they have common or unique Cluster-IDs Agreed. But in our case, they do. Job is right, you should at least use separate TCP sessions for different AFs, Which BGP Session/Policy templates lend themselves naturally to, already. 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). We don't do Internet in a VRF. 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. Our main business is regular Internet. VPNv4/VPNv6 accounts for not even a rounding error in % terms on our network. That said, it is useful to run as late as you possibly can code on your edge routers and RR's to protect yourself against dodgy attributes or unexpected NLRI behaviour. 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. We don't run Internet in a VRF, so shouldn't have that concern. As soon as ORR is available on the CSR1000v, I'll provide some feedback on its performance in our scenario. Mark. _______________________________________________ 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/