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

Mark Tinka mark.tinka at seacom.mu
Mon Jul 23 12:28:34 EDT 2018



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.


More information about the cisco-nsp mailing list