On 6/May/16 16:54, raf wrote:
> > > - are the (v)RRs really have to be part of the IGP ? with two or more > paths to the core ? Your RR's should be part of your IGP, otherwise iBGP won't work. Having two links into your RR's is certainly recommended. > - are the (v)RRs really have to be physically connected to routers ? > > I know that Mark have deploy cisco CSR1000v, and I am interested about > details on his setup, but interested on other scenarios also :) So I've always used core switches in my PoP's. The reason is simple - core router ports are not cheap, as you rightly mention. A lot of service providers like to interconnect their core routers, and other routers in the PoP in a back-to-back fashion. I don't. I find this wasteful as not all routers are peaking at line rate most of the time, and is also expensive because, well, again, core router ports are not cheap. So I use core switches in the PoP. The core routers connect to the core switches, and all other routers in the PoP (peering routers, edge routers, border routers, RR's, service routers, Metro-E switches, BNG routers, e.t.c.) do the same also. Traffic that needs to flow from a non-core router to another non-core router never touches the core routers. Good! Traffic that needs to traverse the core routers goes over switch-to-core-router link (shared infrastructure is scales better commercially). This keeps core router port count low, and thus, cheap. If traffic hitting the core routers were to grow, I just upgrade the switch-to-core-router link, and all other downstream routers connected to the core switch benefit without having to be touched. In our case, our CSR1000v-based RR's are running on HP servers. Those connect into our 2 core switches in each PoP over Cat-6 into a copper SFP in the core switch (as the core switch is an all-optical unit). I'd also recommend connecting your iLO-equivalent ports on your RR's to your internal management network, just to maintain some OoB access to the hypervisor for future troubleshooting. Hope this helps. Mark. _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
