[c-nsp] mpls on RR ?

Mark Tinka mtinka at globaltransit.net
Tue Nov 16 13:28:51 EST 2010


On Tuesday, November 16, 2010 10:07:12 pm Oliver Boehmer 
(oboehmer) wrote:

> no, not really.
> I've seen one SP doing it so they can run the "same"
> config/features on RRs compared to PEs and save on
> testing, and there is one tiny benefit: If you run the
> same MTU on all core links (including the RR links),
> PMTUD on the RR will figure out the "right" MSS without
> relying on frag-needed from the upstream MPLS node as
> the RR already pushes a label, instead of the upstream P
> node. But that's not a big argument, IMHO. I would not
> enable LDP/MPLS on the RR - KISS..

If you're a multi-vendor house and use Juniper's, things can 
get interesting.

JUNOS, by default, resolves BGP next-hops for VPNv4/v6 
routes in the 'inet.3' routing table. The 'inet.3' routing 
table in JUNOS contains routes that are learned over MPLS 
LSP's created by LDP or RSVP.

If you have a Juniper router running as a route reflector, 
in order to reflect VPNv4/v6 routes to clients, the route 
reflector would have to run MPLS, as only MPLS protocols can 
add routes to the 'inet.3' routing table.

I know what you're thinking, but there are workarounds that 
can allow you to reflect VPNv4/v6 routes to clients without 
having to run MPLS on the route reflectors. They may not 
necessarily be obvious, but are well-documented.

Just for those who plan to run multiple vendors in their 
network.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20101117/c43c892f/attachment.bin>


More information about the cisco-nsp mailing list