[j-nsp] VPLS issues

[Krasimir Avramski]

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 <cdebalorre at 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 at 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 at puck.nether.net
> https://puck.nether.net/**mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp>
>