[177136] in North American Network Operators' Group
Re: MPLS VPN design - RR in forwarding path?
daemon@ATHENA.MIT.EDU (Jeff Tantsura)
Wed Dec 31 14:14:55 2014
X-Original-To: nanog@nanog.org
From: Jeff Tantsura <jeff.tantsura@ericsson.com>
To: Chuck Anderson <cra@WPI.EDU>
Date: Wed, 31 Dec 2014 19:14:46 +0000
In-Reply-To: <20141231170539.GL18618@angus.ind.WPI.EDU>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
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 c=
ourse- there are hands and brains to support it - could be a viable approac=
h.
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 implemen=
tation.
Hope this helps
Regards,
Jeff
> On Dec 31, 2014, at 9:08 AM, Chuck Anderson <cra@WPI.EDU> wrote:
>=20
>> On Wed, Dec 31, 2014 at 01:08:15PM +0100, Marcin Kurek wrote:
>> Hi everyone,
>>=20
>> 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.
>>=20
>> 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?
>=20
> 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.
