I am working on a design for a large ISP. The idea is to split the ISP into 3 regions, each region has it own set of Reflectors wich in turn mesh with the ones in the other regions, then PEs in each region peer with the local reflectors....so far no challenge yet.
Now, each region has its own peering or ASBR routers for Transit peering, and obviously each area shoudl prefer it's own ASBR as 1st choice. this can be acheived by:
1-Loads of attributes manipulation, filtering between RRs of each region...and later adminsitration.
2-Leave attributes unchanged (except NH self), then path selection will be down to NH IGP metric. this will work fine until for one reason or the other metric are tampered with.
3-Combine ASBR and reflector functionality into one device, which is not desirable.
a BGP route reflector server adds two attributes to each reflected BGP advertisement:
BGP originator-id = BGP router-id of client that injected the advertisement in the BGP domain
BGP cluster-list = an ordered list of BGP reflections represented by cluster-ids (if set) or by BGP RRS BGP router-ids
In my experience the cluster-list is used to pickup the best path as the one with the shortest BGP cluster-list even if this is not clearly stated in BGP selection path I have seen this.(note: if IGP metric to next-hop and other parameters are equal)
So the ASBR client of the local path should be preferred with standard settings and without the need to tune other BGP parameters.
Clearly IGP metric to BGP next-hop could come first in the hierarchy of selection criteria, so you need to ensure that local ASBR has the better IGP metric and this should be reasonable.
In a simple topolgy where sessions follow physical paths, you are right that if left untuned, the solution would work as intended. Each Reflector would see its closer ASBR as best and advertise that best prefix only. so each region will use its closer ASBR.
However, in this ISP's topology logical sessions are not necessarily following physical paths and there are areas where Reflectors are almost same numbers of hops away from ASBR1 or ASBR2. Which means that relying on IGP metrics would not be best in thi scase, knowing that IGP's metrics are tampered with weekly.
Another solution would be to use same cluster ID on each Region's reflector, this will stop advertsing same prefix between Refelectors...but kills redundancy.
>> where Reflectors are almost same numbers of hops away from ASBR1 or ASBR2. Which means that relying on IGP metrics would not be best in thi scase, knowing that IGP's metrics are tampered with weekly.
let me repeat the concept :
each RRS client will use the BGP advertisement with the shortest cluster-list that is that of the local ASBR.
I don't think a good working ISP plays with IGP metrics every week, but it will use MPLS TE for traffic engineering to move traffic quotas instead.
Do u agree that there will be cases were cluster list may be the same for ASBR1 & ASBR2, in which case we are down IGP metric as a tie breaker.
ISP is going through a capacity upgarde phase which means metric have to be changed to switch traffic away from affected links.
Note, that there also some Reflectors with nearest ASBR, they still have to reflect prefixes from another region. so teh cluster list may be very different from teh actual optimal path (physical and ligical topologies are not the same).
In an ideal scenario, I would leave BGP attributes untouched, but would preffer to have more control on selection and this must be independant of IGP metrics. If budget was not a limitation, using ASBR as Reflector would be a solution. so in short, I will have a good think about leaving IGP metrics decide.
After more consideration, I weighed PROS & CONS of relying on IGP Vs tunning BGP attributes on Reflectors. I came to the conclusion that the latter more practical, as it gives control and would limit configuration changes on these nodes only...leaving other BGP speakers with standard configurations.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...