
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 <cra@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.