[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