[j-nsp] Virtual route reflector physical layout
Mark Tinka
mark.tinka at seacom.mu
Fri May 6 11:21:26 EDT 2016
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.
More information about the juniper-nsp
mailing list