Marko, I agree it can be done, but at least in my head, the egress option is more scalable... You can have a specific RT allocated to "premium" VRFs, which would be only exported, and never imported in any VRF.
Then you implement 2 loopbacks on each PE, and when the PE advertises the routes, it changes the NH to be a different loopback for all the premium VRFs, using a single route-map clause. Of course this all goes away with the bgp next-hop command. Arie -----Original Message----- From: Marko Milivojevic [mailto:[email protected]] Sent: Wednesday, June 09, 2010 21:43 To: Arie Vayner (avayner) Cc: MKS; [email protected] Subject: Re: [c-nsp] L3VPN over RSVP On Wed, Jun 9, 2010 at 18:20, Arie Vayner (avayner) <[email protected]> wrote: > In older releases, where this command is not available you can apply a > route-map on the output direction of the BGP session to the RR, match > the RT of the VRF, and set a different next-hop. It would do the same as > above but without the custom made command. It can be done in the inbound direction, too. Couple of weeks ago I wrote a blog article that tweaks next-hop of the incoming VPNv4 update as a workaround for broken LSP. The same solution can be used to force the traffic via TE tunnel. Here is the link: http://blog.ipexpert.com/2010/05/31/next-hop-in-mpls-vpns/ -- Marko Milivojevic - CCIE #18427 Senior Technical Instructor - IPexpert YES! We include 400 hours of REAL rack time with our Blended Learning Solution! Mailto: [email protected] Telephone: +1.810.326.1444 Fax: +1.810.454.0130 Web: http://www.ipexpert.com/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
