[c-nsp] OSPF+BGP and MPLS Q's

[ringbit at mail.com]

Hi Mark,

Would like to get back to this with some more questions.

1. Imagine a ring topology with core switches each sw connected with dual 10G links thus Port channel for increased capacity. The redundancy is achieved from OSPF adjacency over two different VLANs with BFD enabled (first vlan going clock wise and second vlan anti clockwise traversing the trunk links). 

Would be interested to know your thought on preparing this type of config for MPLS. Convert the trunk links into L3 links? If yes, what about other VLANs (customer vlans) traversing the trunks?


What for considering whether a device can be in backbone area 0 or not? Because some are not and for simplicity I want to consider having all in area 0.

Thanks!
Ton


> Sent: Monday, July 23, 2018 at 6:28 PM
> 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
>
> 
> 
> 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.
>