What is " OUT-OF-PATH RR's " ?? On Tue, Jul 24, 2018 at 9:30 PM, <[email protected]> wrote:
> Send cisco-nsp mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://puck.nether.net/mailman/listinfo/cisco-nsp > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cisco-nsp digest..." > > > Today's Topics: > > 1. Re: OSPF+BGP and MPLS Q's (Mark Tinka) > 2. Re: OSPF+BGP and MPLS Q's ([email protected]) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 23 Jul 2018 18:28:34 +0200 > From: Mark Tinka <[email protected]> > To: Peter Rathlev <[email protected]>, [email protected] > Cc: [email protected] > Subject: Re: [c-nsp] OSPF+BGP and MPLS Q's > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8 > > > > On 23/Jul/18 16:41, Peter Rathlev wrote: > > > I'm also not sure I understand the first question. BFD is a way to > > overcome certain failure scenarios if you need to use some kind of L2 > > transport between the routers. But the better way, since you ask, is to > > have two or more physically direct and diverse L3 links between the > > routers. > > For backbone links, I'd stay away from VLAN's, especially if those > VLAN's are used to handle multiple physical paths over one physical port. > > This is one area where you want to spend money and make sure each link > sits on its own port. You can reduce costs by having those ports on one > line card, but that's as far as I'd take the concession. > > Also, there used to be some strangeness with running MPLS and other > features on VLAN's. I'm not sure if those issues still exist, but if I > were you, I'd rather not find out. > > > > We have always been single area. Our small size considered this will > > most likely never be a problem. If the size of your network is within > > an order of a magnitude of ours I see no reason at all to introducing > > the complexity of multi-area. > > Agreed. > > IS-IS and OSPFv3 should scale to thousands of routers. Your biggest > limitations are going to be whether you decide to split your IGP into > domains because some of your devices have a small FIB (think ASR920's > with 20,000 supported entries, e.t.c.). But this will depend on how many > devices you have. Your planning should be around your the size of the > "FIB-weakest" devices you operate. > > Those using OSPFv2 with thousands of routers should advise their > experience. > > > > > > We started the network without route reflectors. When we grew to more > > than 20 PE routers we configured three existing PEs as RRs. This was a > > bit more complex than we wanted, so we eventually started using two > > Cisco 2901 as RRs. They have been with us since and are not breaking a > > sweat handling the ~7000 networks and ~17000 paths we have in BGP. > > > > Having RRs really simplifies deploying new PEs. Big networks probably > > have even the deployment of new PEs fully automated, but would then > > choose RRs for scalability reasons. > > > > If I were to start over I would implement RRs from the very start. > > Sage advice, like I also suggested before - do it right now, don't wait > for things to grow... they will. > > Your decision here should be whether you want in-path or out-of-path > RR's. If you're doing MPLS, and for simplicity, I'd say go for > out-of-path RR's. > > If you choose to go for out-of-path RR's, then you give yourself a lot > of options re: the type of kit you can use, namely, x86 servers running > a VM that is hosting a production-grade software version of a > traditional router, e.g., CSR1000v or xRV (Cisco), vRR (Juniper) or > VSR-RR (Nokia, formerly ALU). > > > > We use unique (type 1) RDs per PE and thus have all PEs see paths from > > all other PEs, not just the "best" path, giving us quick failover. > > I don't do Internet in a VRF, but it's quite a popular architecture for > several operators on this and other mailing lists. > > Mark. > > > ------------------------------ > > Message: 2 > Date: Mon, 23 Jul 2018 17:41:50 +0100 > From: <[email protected]> > To: "'Peter Rathlev'" <[email protected]>, <[email protected]> > Cc: <[email protected]> > Subject: Re: [c-nsp] OSPF+BGP and MPLS Q's > Message-ID: <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > > Peter Rathlev > > Sent: Monday, July 23, 2018 3:42 PM > > To: [email protected] > > > > On Mon, 2018-07-23 at 12:23 +0200, [email protected] wrote: > > > Anyone else can give an opinion to those three questions? > > > > Opinions are easy to give. :-) Authority is a different question > altogether. I > > spend my daytime in a place that started with just 6 PE routers and has > slowly > > grown to 51 over ~13-15 years. Still not a big number, but I have been a > part > > of it all the time and have learned some things the hard way. > > > > We're an closed ("enterprise") IS-IS-based MPLS L3VPN network so things > > might not translate directly. We only have IGP links and loopbacks in > IS-IS, > > just above 200 routes in the global table currently. We around > > 7000 prefixes in BGP. > > > > I'm also not sure I understand the first question. BFD is a way to > overcome > > certain failure scenarios if you need to use some kind of L2 transport > > between the routers. But the better way, since you ask, is to have two or > > more physically direct and diverse L3 links between the routers. > > > > We have always been single area. Our small size considered this will most > > likely never be a problem. If the size of your network is within an order > of a > > magnitude of ours I see no reason at all to introducing the complexity of > > multi-area. > > > > We started the network without route reflectors. When we grew to more > > than 20 PE routers we configured three existing PEs as RRs. This was a > bit > > more complex than we wanted, so we eventually started using two Cisco > > 2901 as RRs. They have been with us since and are not breaking a sweat > > handling the ~7000 networks and ~17000 paths we have in BGP. > > > > Having RRs really simplifies deploying new PEs. Big networks probably > have > > even the deployment of new PEs fully automated, but would then choose > > RRs for scalability reasons. > > > > If I were to start over I would implement RRs from the very start. > > > > We use unique (type 1) RDs per PE and thus have all PEs see paths from > all > > other PEs, not just the "best" path, giving us quick failover. > > > > > This topic of RRs is actually very interesting, > At first networks where meant to be very decentralized to sustain attacks, > and the pendulum keeps on swinging back and forth on the > centralize/decentralize front -while the RR thing seems to be stable > through > that. > I guess one of the reasons is that using the RRs gives the control of the > scalability and robustness "sliders" of the solution to the operator. > (in other words the scalability and robustness is agnostic to each other or > to the number of the BGP speakers in the network giving us the best > possible > versatility) > > 1a) You can increase robustness by using different RRs for different > prefix-groups (or AFs) - the more the better robustness (and as a side > effect the solution will scale better). > 1b) you can have 1 (non-resilient) or two and more RRs per prefix-group. > 2) And also for any of the AFs or prefix-groups you can have different > slices or "Planes" each carrying a subset of prefixes thus increasing the > scalability of the solution. > 3) If number of sessions per RR is a problem you can add more RRs per > AF-group (or per AF-group slice) each terminating just a subset of all BGP > sessions > -then you end up with separate infrastructures of RR per 1b) or per > 2). > > Each of these you can scale in or out independently depending on your > requirements. > > Although I'd suggest you want to have 1a to at least divide Public Internet > prefixes and your internal VPN prefixes. > The 1b) is a given for anyone who's using RRs even if they are using just a > single prefix-group (i.e. at least 2 RRs for the whole network) > > > adam > > netconsultings.com > ::carrier-class solutions for the telecommunications industry:: > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > cisco-nsp mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > > > ------------------------------ > > End of cisco-nsp Digest, Vol 188, Issue 19 > ****************************************** > -- -- ________´$$$$`_____________________________,,,_ _______´$$$$$$$`_________________________´$$$` ________`$$$$$$$`______,,________,,_______´$$$$´ _________`$$$$$$$`____´$$`_____´$$`____´$$$$$´ __________`$$$$$$$`_´$$$$$`_´$$$$$`__´$$$$$$$´ ___________`$$$$$$$_$$$$$$$_$$$$$$$_´$$$$$$$´_ ____________`$$$$$$_$$$$$$$_$$$$$$$`´$$$$$$´_ ___,,,,,,______`$$$$$$_$$$$$$$_$$$$$$$_$$$$$$´_ _´$$$$$`____`$$$$$$_$$$$$$$_$$$$$$$_$$$$$$´_ ´$$$$$$$$$`´$$$$$$$_$$$$$$$_$$$$$$$_$$$$$´_ ´$$$$$$$$$$$$$$$$$$_$$$$$$$_$$$$$$$_$$$$$´_ ___`$$$$$$$$$$$$$$$_$$$$$$$_$$$$$$_$$$$$$´_ ______`$$$$$$$$$$$$$_$$$$$__$$_$$$$$$_$$´_ _______`$$$$$$$$$$$$,___,$$$$,_____,$$$$$´_ _________`$$$$$$$$$$$$$$$$$$$$$$$$$$$$$´_ __________`$$$$$$$$$$$$$$$$$$$$$$$$$$$´_ ____________`$$$$$$$$$$$$$$$$$$$$$$$$´_ _______________`$$$$$$$$$$$$$$$$$$$$´_ ~~( ŊëŌ )~~ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
