Hi
"strict" is only useful in case you want to cease vpls service when all lsps
matching .*-SILVER.* are down. Default behavior (without "strict" keyword)
with empty(or down) install-nexthop match is to ignore term.
Since the aim is to route over "single lsp" why regex-lsp is used? Why not
"install-nexthop lsp *lsp-name".*
*
*
Best Regards,
Krasi
On Fri, Nov 30, 2012 at 8:59 PM, Christian <cdebalo...@neotelecoms.com>wrote:
> Hello,
> Any luck with the "strict" option at the install-nexthop ?
> Rgds,
>
> Christian
>
> Le 30/11/2012 17:41, Richard A Steenbergen a écrit :
>
> Does anybody have any experience with forced LSP path selection for VPLS
>> circuits? Long story short, when we fire up traffic on one particular
>> VPLS instance, we're seeing SOME of the traffic it's carrying being
>> blackholed. The pattern is one of certain IP or even TCP port pairs
>> being blocked, and it seems to rotate over time, which screams "hashing
>> across multiple LSPs where one of them is doing something bad, and it
>> changes as the LSPs resignal over time" to me. To try and lock this
>> down, I'm trying to force the VPLS traffic to route over a single LSP,
>> in the usual manner with a forwarding-table export policy, and a very
>> simple extended community regexp against the vrf-target community.
>>
>> term VPLS {
>> from community MATCH_VPLS;
>> then {
>> install-nexthop lsp-regex .*-SILVER.*;
>> load-balance per-packet;
>> accept;
>> }
>> }
>>
>> But it sure as hell doesn't look like it's narrowing the LSP selection:
>>
>> ras@re0.router> show route forwarding-table family vpls table blah
>> Routing table: blah.vpls
>> VPLS:
>> Destination Type RtRef Next hop Type Index NhRef Netif
>> ...
>> 00:xx:xx:xx:xx:xx/48 user 0 indr 1050634 5
>> idxd 3223 2
>> idx:1 xx.xx.142.132 Push 262153, Push
>> 655412(top) 4543 1 xe-7/3/0.0
>> idx:1 xx.xx.142.62 Push 262153, Push
>> 752660, Push 691439(top) 1315 1 xe-4/1/0.0
>> idx:2 xx.xx.142.132 Push 262153, Push
>> 758372(top) 1923 1 xe-7/3/0.0
>> idx:2 xx.xx.142.62 Push 262153, Push
>> 382341, Push 691439(top) 2541 1 xe-4/1/0.0
>> idx:3 xx.xx.142.132 Push 262153, Push
>> 758372(top) 1923 1 xe-7/3/0.0
>> idx:3 xx.xx.142.62 Push 262153, Push
>> 382341, Push 691439(top) 2541 1 xe-4/1/0.0
>> idx:4 xx.xx.142.30 Push 262153, Push
>> 714676(top) 1500 1 xe-4/1/1.0
>> idx:4 xx.xx.142.62 Push 262153, Push
>> 619458, Push 378636(top) 3864 1 xe-4/1/0.0
>> idx:xx xx.xx.142.82 Push 262153, Push
>> 601828(top) 989 1 xe-5/0/0.0
>> idx:xx xx.xx.142.132 Push 262153, Push
>> 684644(top) 3516 1 xe-7/3/0.0
>> idx:xx xx.xx.142.62 Push 262153, Push
>> 528898, Push 760875(top) 4766 1 xe-4/1/0.0
>> idx:xx xx.xx.142.62 Push 262153, Push
>> 792036, Push 691439(top) 3473 1 xe-4/1/0.0
>>
>> Any ideas, about this or about troubleshooting the forwarding plane for
>> VPLS in general? Other than that VPLS just sucks... :)
>>
>>
> ______________________________**_________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/**mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp>
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
