Bump. Anyone?
> Sent: Friday, August 31, 2018 at 10:47 PM > From: ring...@mail.com > To: "Mark Tinka" <mark.ti...@seacom.mu> > Cc: cisco-nsp@puck.nether.net > Subject: Re: [c-nsp] OSPF+BGP and MPLS Q's > > 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.ti...@seacom.mu> > > To: "Peter Rathlev" <pe...@rathlev.dk>, ring...@mail.com > > Cc: cisco-nsp@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. > > > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
