MPLS VPN design - RR in forwarding path?

Thu Jan 1 10:46:23 UTC 2015

Hello all,

Thank you for insightful answers.

I was thinking mostly about the second scenario Chuck mentioned - where 
some traffic naturally flows through the routers that are the RRs 
because of MPLS LSP. Setting next-hop-self on all reflected routes would 
be misconfiguration IMHO.

I am also aware of products like vMX or CSR1000v/XRv and the example 
given by Saku makes me more interested in licensing/pricing options.

Regards,
Marcin

W dniu 2014-12-31 o 18:05, Chuck Anderson pisze:
> 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.