[c-nsp] cisco-nsp Digest, Vol 188, Issue 19

Tue Jul 24 22:21:40 EDT 2018

What is " OUT-OF-PATH RR's " ??

On Tue, Jul 24, 2018 at 9:30 PM, <cisco-nsp-request at puck.nether.net> wrote:

> Send cisco-nsp mailing list submissions to
>         cisco-nsp at puck.nether.net
>
> 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
>         cisco-nsp-request at puck.nether.net
>
> You can reach the person managing the list at
>         cisco-nsp-owner at puck.nether.net
>
> 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 (adamv0025 at netconsultings.com)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 23 Jul 2018 18:28:34 +0200
> From: Mark Tinka <mark.tinka at seacom.mu>
> To: Peter Rathlev <peter at rathlev.dk>, ringbit at mail.com
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] OSPF+BGP and MPLS Q's
> Message-ID: <07e4633b-c1e8-272e-6b63-0204ec27adf6 at seacom.mu>
> 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: <adamv0025 at netconsultings.com>
> To: "'Peter Rathlev'" <peter at rathlev.dk>,       <ringbit at mail.com>
> Cc: <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] OSPF+BGP and MPLS Q's
> Message-ID: <003601d422a4$0e4fd1c0$2aef7540$@netconsultings.com>
> Content-Type: text/plain;       charset="us-ascii"
>
> > Peter Rathlev
> > Sent: Monday, July 23, 2018 3:42 PM
> > To: ringbit at mail.com
> >
> > On Mon, 2018-07-23 at 12:23 +0200, ringbit at mail.com 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
> cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
>
>
> ------------------------------
>
> End of cisco-nsp Digest, Vol 188, Issue 19
> ******************************************
>

-- 
-- 
________´$$$$`_____________________________,,,_
_______´$$$$$$$`_________________________´$$$`
________`$$$$$$$`______,,________,,_______´$$$$´
_________`$$$$$$$`____´$$`_____´$$`____´$$$$$´
__________`$$$$$$$`_´$$$$$`_´$$$$$`__´$$$$$$$´
___________`$$$$$$$_$$$$$$$_$$$$$$$_´$$$$$$$´_
____________`$$$$$$_$$$$$$$_$$$$$$$`´$$$$$$´_
___,,,,,,______`$$$$$$_$$$$$$$_$$$$$$$_$$$$$$´_
_´$$$$$`____`$$$$$$_$$$$$$$_$$$$$$$_$$$$$$´_
´$$$$$$$$$`´$$$$$$$_$$$$$$$_$$$$$$$_$$$$$´_
´$$$$$$$$$$$$$$$$$$_$$$$$$$_$$$$$$$_$$$$$´_
___`$$$$$$$$$$$$$$$_$$$$$$$_$$$$$$_$$$$$$´_
______`$$$$$$$$$$$$$_$$$$$__$$_$$$$$$_$$´_
_______`$$$$$$$$$$$$,___,$$$$,_____,$$$$$´_
_________`$$$$$$$$$$$$$$$$$$$$$$$$$$$$$´_
__________`$$$$$$$$$$$$$$$$$$$$$$$$$$$´_
____________`$$$$$$$$$$$$$$$$$$$$$$$$´_
_______________`$$$$$$$$$$$$$$$$$$$$´_

~~( ŊëŌ )~~