Re: [j-nsp] ACL behaviour
BGP needs to be allowed in loopback JCL if you have one applied. Otherwise the peer wont come up. On Fri, Nov 30, 2012 at 5:36 PM, Ali Sumsam ali+juniper...@eintellego.netwrote: Hi, There is an ACL on a Cisco router which doesn't have a statement which allows the BGP peering IPs through the interface (where the ACL is applied). However, the BGP is still getting established. I am doing the same thing on Juniper, and the BGP peering is not coming up. If I allow the BGP peer IP in the Juniper firewall filter, it lets the BGP come up. My assumption is that Cisco doesn't apply the ACL on the traffic that is generated by the router itself. Is this the reason of the above behavior? Or is there something else? Please comment. Regards, *Ali Sumsam CCIE* *Network Engineer - Level 3* eintellego Pty Ltd a...@eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)410 603 531 facebook.com/eintellego PO Box 7726, Baulkham Hills, NSW 1755 Australia The Experts Who The Experts Call Juniper - Cisco – Brocade - IBM ___ 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] Error while validating a JunOS
Jinstall validates both current _AND_ rescue config. Check if you have rescue config set and if yes then overwrite it with current config request system config rescue save HTH Thanks Alex - Original Message - From: Ali Sumsam ali+juniper...@eintellego.net To: juniper-nsp@puck.nether.net Sent: Friday, November 30, 2012 1:25 AM Subject: [j-nsp] Error while validating a JunOS Hi, I have a brand new MX5 router for one of my customers. The only configuration I have on this router is 1, one login name and password 2, IP address on FXP0 3, telnet and ftp service. I have uploaded Junos jinstall-ppc-11.2R5.4-export-signed.tgz, which is the recommended one for MX5 on juniper site. When i try to validate this JunOS, it gives me following error. mgd: error: configuration check-out failed Validation failed WARNING: Current configuration not compatible with /var/tmp/jinstall-ppc-11.2R5.4-export-signed.tgz Any suggestion. Can I just ignore this error and live with it? Regards, *Ali Sumsam CCIE* *Network Engineer - Level 3* eintellego Pty Ltd a...@eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)410 603 531 facebook.com/eintellego PO Box 7726, Baulkham Hills, NSW 1755 Australia The Experts Who The Experts Call Juniper - Cisco – Brocade - IBM ___ 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] Error while validating a JunOS
Jinstall validates both current _AND_ rescue config. Check if you have rescue config set and if yes then overwrite it with current config request system config rescue save HTH Thanks Alex - Original Message - From: Ali Sumsam ali+juniper...@eintellego.net To: juniper-nsp@puck.nether.net Sent: Friday, November 30, 2012 1:25 AM Subject: [j-nsp] Error while validating a JunOS Hi, I have a brand new MX5 router for one of my customers. The only configuration I have on this router is 1, one login name and password 2, IP address on FXP0 3, telnet and ftp service. I have uploaded Junos jinstall-ppc-11.2R5.4-export-signed.tgz, which is the recommended one for MX5 on juniper site. When i try to validate this JunOS, it gives me following error. mgd: error: configuration check-out failed Validation failed WARNING: Current configuration not compatible with /var/tmp/jinstall-ppc-11.2R5.4-export-signed.tgz Any suggestion. Can I just ignore this error and live with it? Regards, *Ali Sumsam CCIE* *Network Engineer - Level 3* eintellego Pty Ltd a...@eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)410 603 531 facebook.com/eintellego PO Box 7726, Baulkham Hills, NSW 1755 Australia The Experts Who The Experts Call Juniper - Cisco – Brocade - IBM ___ 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
[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] Routing Instance BGP Full Routing High Memory persists
Did you try gracefully restarting routing? That should keep it forwarding while freeing route process memory Will O'Brien On Nov 30, 2012, at 2:57 PM, Giuliano Medalha giuli...@wztech.com.br wrote: People, We are doing some BGP tests using routing-instances on MX5-T-DC routers. We have created a routing-instance to receive 3 full routing inet.0 tables. The master routing has 3 majors full routing tables too. Before the tests we check the RE percentage of using memory ... using: Router show chassis routing engine It show 47% usage. After the creation of the routing-instance (type virtual-router) - named TEST we could receive more 3 full routing tables on the TEST.inet.0 table Using the same command is show to us: Router show chassis routing engine 87% memory utilization After we remove the routing-instance configuration with a commit command in sequence ... it still shows the same 87% of memory utilization It this procedure is correct ?Is it any update command to clear the memory allocation without disrupting forwarding services ? Can you please give me some feedback about it ? Did anyone see it before ? Thanks a lot, Giuliano ___ 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
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
