[c-nsp] L3VPN over RSVP

[Arie Vayner (avayner)]

Hmm, I think you are missing the point a bit...

The bgp next-hop command sets the next-hop for the advertisements the
local routers sends out. The remote PE would select the path using an
IGP lookup based on the remote BGP next-hop.

So setting the BGP next-hop locally, would affect the path selection of
a remote PE.
You then have to make sure that the remote PE sees the local next-hop
via the TE tunnel (for example, using a static route...)

Arie

-----Original Message-----
From: MKS [mailto:rekordmeister at gmail.com] 
Sent: Sunday, June 13, 2010 13:38
To: Arie Vayner (avayner)
Cc: Marko Milivojevic; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] L3VPN over RSVP

Hi all

I can see that on a spoke site the bgp next-hop command is a nice way
of routing the traffic to the TE tunnel that is pointed to the hub
site.

Now I guess that on the hub site I would have to use a route-map to
direct each spoke site to the corrent TE tunnel, or am I missing the
point?

Regards
MKS

On Thu, Jun 10, 2010 at 6:28 AM, Arie Vayner (avayner)
<avayner at cisco.com> wrote:
> 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:markom at ipexpert.com]
> Sent: Wednesday, June 09, 2010 21:43
> To: Arie Vayner (avayner)
> Cc: MKS; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] L3VPN over RSVP
>
> On Wed, Jun 9, 2010 at 18:20, Arie Vayner (avayner)
<avayner at cisco.com> 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: markom at ipexpert.com
> Telephone: +1.810.326.1444
> Fax: +1.810.454.0130
> Web: http://www.ipexpert.com/
>