Do your devices support IP/MPLS? Mark.
On 9/Sep/18 23:22, ring...@mail.com wrote: > 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/ _______________________________________________ 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/
