Hi, Right, one is when besides forwarding packets a router also functioning as a RR, another - when RR sets NH to itself and hence forces all the traffic to pass thru the router in fast path. Keep in mind - some architectures, such as seamless MPLS would require a RR to be in the fast path. There are some other cases where it could be a requirement. I'd advice to look into vRR space - price/performance looks quite good.
Wrt open source implementations - if you are looking into relatively basic feature set (v4/v6 unicast/vpn) reliability is not of main concern and of course- there are hands and brains to support it - could be a viable approach. Might you be looking into more complex feature set - EVPN, BGP-LS, FS, enhanced route refresh, etc, highly optimized code wrt update rate/ number of peers supported - most probably you'd end up with a commercial implementation. Hope this helps Regards, Jeff > On Dec 31, 2014, at 9:08 AM, Chuck Anderson <c...@wpi.edu> wrote: > >> On Wed, Dec 31, 2014 at 01:08:15PM +0100, Marcin Kurek wrote: >> Hi everyone, >> >> I'm reading Randy's Zhang BGP Design and Implementation and I found >> following guidelines about designing RR-based MPLS VPN architecture: >> - Partition RRs >> - Move RRs out of the forwarding path >> - Use a high-end processor with maximum memory >> - Use peer groups >> - Tune RR routers for improved performance. >> >> Since the book is a bit outdated (2004) I'm curious if these rules >> still apply to modern SP networks. >> What would be the reasoning behind keeping RRs out of the forwarding >> path? Is it only a matter of performance and stability? > > When they say "move RRs out of the forwarding path", they could mean > "don't force all traffic through the RRs". These are two different > things. Naive configurations could end up causing all VPN traffic to > go through the RRs (e.g. setting next-hop-self on all reflected > routes) whereas more correct configurations don't do that--but there > may be some traffic that natrually flows through the same routers that > are the RRs, via an MPLS LSP for example. That latter is fine in many > cases, the former is not. E.g. I would argue that a P-router can be > an RR if desired.
