[j-nsp] VPLS issues
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:
DestinationType 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... :)
--
Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS issues
You need to use the strict keyword when installing the LSP.
Sent from my iPhone
On 30 Nov 2012, at 17:29, Richard A Steenbergen r...@e-gerbil.net wrote:
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:
DestinationType 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... :)
--
Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
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
Re: [j-nsp] VPLS issues
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:
DestinationType 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
Re: [j-nsp] VPLS issues
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.comwrote:
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:
DestinationType 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-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
