[j-nsp] Internet routes in MPLS network, global table or own VRF?

[Phil Bedard]

On Jan 26, 2012, at 4:01 PM, Keegan Holley <keegan.holley at sungard.com> wrote:

> 2012/1/26 Pavel Lunin <plunin at senetsy.ru>:
>> 
>> 
>>> 
>>> why would FRR LSP's take a route different than what the IGP would
>>> converge to.
>> 
>> 
>> Because FRR uses a path from a different entry (PLP) to probably a different
>> exit (say, next-next-hop). When normal LSP (either SPF or CSPF calculated)
>> is a path from head-end to tail-end. Whether this happens often or rare, the
>> need to care how your detours are calculated is itself a big enough
>> headache.
> 
> That's not how FRR works at least for RSVP.  It pretty much just
> re-runs cspf with something removed.  So it's the same route your IGP
> would choose if said "thing" went dark.  I don't have many obscure
> paths where I wouldn't want traffic to go so I can't really comment on
> your earlier idea.  That being said I've never seen FRR choose a path
> worse than the path the IGP would choose.  It's just preselects that
> path and pre-signals it.  I'm sure there are failure scenarios though.
> 
> 
>> 
>>>> What the VRF-based Internet users will definitely notice is (looks like
>>>> RAS
>>>> is tired of telling this story) is ICMP tunneling and consequent hard to
>>>> interpret delay values. People are very suspicious to the numbers. This
>>>> is
>>>> almost impossible to explain, that the numbers, traceroute shows, have
>>>> nothing to do with their kitty-photos-not-loading problem.
>>> 
>>> Hey kitty photos are serious business especially if you are facebook
>>> stalking the aforementioned kitty.
>> 
>> 
>> Absolutely. This is why in case of issues you should not waste time for
>> explaining why your core router is 200ms away from the previous hop.
>> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp