Re: [j-nsp] J2300/J4300 FPCs cannot go online
Change the date to 2004, and do not use NTP. set date 200403311010.10 -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mircho Mirchev Sent: Saturday, March 29, 2014 11:32 PM To: Tom Storey Cc: Juniper Maillist Subject: Re: [j-nsp] J2300/J4300 FPCs cannot go online Hi, Same here Seems there are more expired certificates. We'll have to try JTAC - however, I'm not sure if they can help - these boxes are long out of support. Any other ideas? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Community matching policy
Hi -
Let's say I want to reject everything except the following communities:
Either 100:100
OR 101:101
OR both 100:100 101:100
Tried to setup something:
[edit policy-options]
policy-statement TEST {
term TEST1 {
from community [ TEST1 TEST2 ]; ///Is not it logical OR, and
matching everything except what I want because of invert-match//
then reject;
}
term TEST2 {
then accept; And then this should accept what I wanted /
}
}
[edit policy-options]
community TEST1 {
invert-match;
members 100:100;
}
community TEST2 {
invert-match;
members 101:101;
}
However it is rejecting everything. Any thoughts what I'm missing here or
perhaps the approach is not correct.
Thanks in advance.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Main Board PFE Temp Too Hot: What to do?
Hello all, I had about 3 weeks ago a Main Board PFE Temp Too Hot alarm on a EX Switch. Currently everything seems normal, temp is in the 30C area. But the alarm is still present with show chassis alarm. What can I do to clear this? Thanks!Frank --- Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! Rundum glücklich mit freenetMail ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Community matching policy
A match 100:100
B match 101:101
Your TEST1 term match on !A OR !B = !(A AND B), so it effectively rejects
every route that has NO communities 100:100 AND 101:101 (at the same time)
Your target is to accept A OR B, so you can first match and accept on these
communities (TEST1 OR TEST2 defined without invert-match) and then reject
everything else.
Best Regards,
Krasi
On 31 March 2014 12:10, Andrew Khan good1...@outlook.com wrote:
Hi -
Let's say I want to reject everything except the following communities:
Either 100:100
OR 101:101
OR both 100:100 101:100
Tried to setup something:
[edit policy-options]
policy-statement TEST {
term TEST1 {
from community [ TEST1 TEST2 ]; ///Is not it logical OR, and
matching everything except what I want because of invert-match//
then reject;
}
term TEST2 {
then accept; And then this should accept what I wanted /
}
}
[edit policy-options]
community TEST1 {
invert-match;
members 100:100;
}
community TEST2 {
invert-match;
members 101:101;
}
However it is rejecting everything. Any thoughts what I'm missing here or
perhaps the approach is not correct.
Thanks in advance.
___
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] Community matching policy
Hello Krasi,
Thanks for the reply, appreciated. Sorry I did not mention in my first email
that I'm trying to find a workaround while using invert-match. Any idea on
achieving the same results when using invert-match.
Kind regards,
Date: Mon, 31 Mar 2014 13:41:40 +0300
Subject: Re: [j-nsp] Community matching policy
From: kr...@smartcom.bg
To: good1...@outlook.com
CC: juniper-nsp@puck.nether.net
A match 100:100B match 101:101 Your TEST1 term match on !A OR !B = !(A AND
B), so it effectively rejects every route that has NO communities 100:100 AND
101:101 (at the same time)
Your target is to accept A OR B, so you can first match and accept on these
communities (TEST1 OR TEST2 defined without invert-match) and then reject
everything else.
Best Regards,
Krasi
On 31 March 2014 12:10, Andrew Khan good1...@outlook.com wrote:
Hi -
Let's say I want to reject everything except the following communities:
Either 100:100
OR 101:101
OR both 100:100 101:100
Tried to setup something:
[edit policy-options]
policy-statement TEST {
term TEST1 {
from community [ TEST1 TEST2 ]; ///Is not it logical OR, and
matching everything except what I want because of invert-match//
then reject;
}
term TEST2 {
then accept; And then this should accept what I wanted /
}
}
[edit policy-options]
community TEST1 {
invert-match;
members 100:100;
}
community TEST2 {
invert-match;
members 101:101;
}
However it is rejecting everything. Any thoughts what I'm missing here or
perhaps the approach is not correct.
Thanks in advance.
___
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] Community matching policy
In addition to my last question, what I don't understand is that !A OR !B =
!(A AND B) /// how come it became AND operation rather than logical OR///
From Juniper documentation:
You can include the names of multiple communities in the community match
condition. If you do this, only one community needs to match for a match to
occur (matching is effectively a logical OR operation).
Is it invert-match causing this behavior? What if I don't use invert-match,
will it be a logical OR operation e.g. A OR B = A OR B or will it be A OR B
= (A AND B)
Thanks
From: good1...@outlook.com
To: kr...@smartcom.bg
Date: Mon, 31 Mar 2014 11:00:48 +
CC: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Community matching policy
Hello Krasi,
Thanks for the reply, appreciated. Sorry I did not mention in my first email
that I'm trying to find a workaround while using invert-match. Any idea on
achieving the same results when using invert-match.
Kind regards,
Date: Mon, 31 Mar 2014 13:41:40 +0300
Subject: Re: [j-nsp] Community matching policy
From: kr...@smartcom.bg
To: good1...@outlook.com
CC: juniper-nsp@puck.nether.net
A match 100:100B match 101:101 Your TEST1 term match on !A OR !B = !(A AND
B), so it effectively rejects every route that has NO communities 100:100 AND
101:101 (at the same time)
Your target is to accept A OR B, so you can first match and accept on these
communities (TEST1 OR TEST2 defined without invert-match) and then reject
everything else.
Best Regards,
Krasi
On 31 March 2014 12:10, Andrew Khan good1...@outlook.com wrote:
Hi -
Let's say I want to reject everything except the following communities:
Either 100:100
OR 101:101
OR both 100:100 101:100
Tried to setup something:
[edit policy-options]
policy-statement TEST {
term TEST1 {
from community [ TEST1 TEST2 ]; ///Is not it logical OR, and
matching everything except what I want because of invert-match//
then reject;
}
term TEST2 {
then accept; And then this should accept what I wanted /
}
}
[edit policy-options]
community TEST1 {
invert-match;
members 100:100;
}
community TEST2 {
invert-match;
members 101:101;
}
However it is rejecting everything. Any thoughts what I'm missing here or
perhaps the approach is not correct.
Thanks in advance.
___
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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Community matching policy
The logic of !A OR !B makes my head hurt, so its simple to write out a
truth table to work out exactly what it does.
A | B | !A OR !B
---
T | T | F
T | F | T
F | T | T
F | F | T
This makes it clear that !A OR !B is identical to !(A AND B)
I don't think there is any way to do what you are interested in with the
invert-match statement. I would just do something like this
term A {
from {
community [ A B ];
}
then accept;
}
reject;
community A {
members 100:100;
}
community B {
members 101:101;
}
It may be possible to add the two communities into one community statement.
I'm unsure how exactly that will behave though.
Regards,
Dave
On 31 March 2014 12:47, Andrew Khan good1...@outlook.com wrote:
In addition to my last question, what I don't understand is that !A OR !B
= !(A AND B) /// how come it became AND operation rather than logical
OR///
From Juniper documentation:
You can include the names of multiple communities in the community match
condition. If you do this, only one community needs to match for a match to
occur (matching is effectively a logical OR operation).
Is it invert-match causing this behavior? What if I don't use
invert-match, will it be a logical OR operation e.g. A OR B = A OR B or
will it be A OR B = (A AND B)
Thanks
From: good1...@outlook.com
To: kr...@smartcom.bg
Date: Mon, 31 Mar 2014 11:00:48 +
CC: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Community matching policy
Hello Krasi,
Thanks for the reply, appreciated. Sorry I did not mention in my first
email that I'm trying to find a workaround while using invert-match. Any
idea on achieving the same results when using invert-match.
Kind regards,
Date: Mon, 31 Mar 2014 13:41:40 +0300
Subject: Re: [j-nsp] Community matching policy
From: kr...@smartcom.bg
To: good1...@outlook.com
CC: juniper-nsp@puck.nether.net
A match 100:100B match 101:101 Your TEST1 term match on !A OR !B = !(A
AND B), so it effectively rejects every route that has NO communities
100:100 AND 101:101 (at the same time)
Your target is to accept A OR B, so you can first match and accept on
these communities (TEST1 OR TEST2 defined without invert-match) and then
reject everything else.
Best Regards,
Krasi
On 31 March 2014 12:10, Andrew Khan good1...@outlook.com wrote:
Hi -
Let's say I want to reject everything except the following communities:
Either 100:100
OR 101:101
OR both 100:100 101:100
Tried to setup something:
[edit policy-options]
policy-statement TEST {
term TEST1 {
from community [ TEST1 TEST2 ]; ///Is not it logical OR,
and matching everything except what I want because of invert-match//
then reject;
}
term TEST2 {
then accept; And then this should accept what I wanted /
}
}
[edit policy-options]
community TEST1 {
invert-match;
members 100:100;
}
community TEST2 {
invert-match;
members 101:101;
}
However it is rejecting everything. Any thoughts what I'm missing here
or perhaps the approach is not correct.
Thanks in advance.
___
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
___
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] Community matching policy
Le 31/03/2014 13:47, Andrew Khan a écrit :
In addition to my last question, what I don't understand is that !A OR !B =
!(A AND B) /// how come it became AND operation rather than logical OR///
Think of them in terms of boolean truth tables.
From Juniper documentation:
You can include the names of multiple communities in the community match
condition. If you do this, only one community needs to match for a match to
occur (matching is effectively a logical OR operation).
Is it invert-match causing this behavior? What if I don't use invert-match,
will it be a logical OR operation e.g. A OR B = A OR B or will it be A OR B
= (A AND B)
Unless you find what you need at http://preview.tinyurl.com/o5fjmof,
welcome back to me.
Cheers,
mh
Thanks
From: good1...@outlook.com
To: kr...@smartcom.bg
Date: Mon, 31 Mar 2014 11:00:48 +
CC: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Community matching policy
Hello Krasi,
Thanks for the reply, appreciated. Sorry I did not mention in my first email
that I'm trying to find a workaround while using invert-match. Any idea on
achieving the same results when using invert-match.
Kind regards,
Date: Mon, 31 Mar 2014 13:41:40 +0300
Subject: Re: [j-nsp] Community matching policy
From: kr...@smartcom.bg
To: good1...@outlook.com
CC: juniper-nsp@puck.nether.net
A match 100:100B match 101:101 Your TEST1 term match on !A OR !B = !(A AND
B), so it effectively rejects every route that has NO communities 100:100
AND 101:101 (at the same time)
Your target is to accept A OR B, so you can first match and accept on these
communities (TEST1 OR TEST2 defined without invert-match) and then reject
everything else.
Best Regards,
Krasi
On 31 March 2014 12:10, Andrew Khan good1...@outlook.com wrote:
Hi -
Let's say I want to reject everything except the following communities:
Either 100:100
OR 101:101
OR both 100:100 101:100
Tried to setup something:
[edit policy-options]
policy-statement TEST {
term TEST1 {
from community [ TEST1 TEST2 ]; ///Is not it logical OR, and
matching everything except what I want because of invert-match//
then reject;
}
term TEST2 {
then accept; And then this should accept what I wanted /
}
}
[edit policy-options]
community TEST1 {
invert-match;
members 100:100;
}
community TEST2 {
invert-match;
members 101:101;
}
However it is rejecting everything. Any thoughts what I'm missing here or
perhaps the approach is not correct.
Thanks in advance.
___
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
___
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] Community matching policy
Thanks, Dave! Your table is awesome and clarified my doubts and clicked into my
mind :) On your query, It may be possible to add the two communities into one
community statement. I'm unsure how exactly that will behave though
let's say something like
community A members [ 100:100 101:101 ]; // pretty much (100:100 AND
101:101) //
In that case, the route must have a community that matches 100:100 and a
community that matches 101:101
http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-policy/policy-bgp-communities-extended-communities-evaluation-in-routing-policy-match-conditions.html
Kind regards,
Date: Mon, 31 Mar 2014 12:59:57 +0100
Subject: Re: [j-nsp] Community matching policy
From: m...@geordish.org
To: good1...@outlook.com
CC: kr...@smartcom.bg; juniper-nsp@puck.nether.net
The logic of !A OR !B makes my head hurt, so its simple to write out a truth
table to work out exactly what it does.
A | B | !A OR !B
---
T | T | F
T | F | T
F | T | T
F | F | T
This makes it clear that !A OR !B is identical to !(A AND B)
I don't think there is any way to do what you are interested in with the
invert-match statement. I would just do something like this
term A {
from {
community [ A B ];
}
then accept;
}
reject;
community A {
members 100:100;
}
community B {
members 101:101;
}
It may be possible to add the two communities into one community statement. I'm
unsure how exactly that will behave though.
Regards,
Dave
On 31 March 2014 12:47, Andrew Khan good1...@outlook.com wrote:
In addition to my last question, what I don't understand is that !A OR !B =
!(A AND B) /// how come it became AND operation rather than logical OR///
From Juniper documentation:
You can include the names of multiple communities in the community match
condition. If you do this, only one community needs to match for a match to
occur (matching is effectively a logical OR operation).
Is it invert-match causing this behavior? What if I don't use invert-match,
will it be a logical OR operation e.g. A OR B = A OR B or will it be A OR B
= (A AND B)
Thanks
From: good1...@outlook.com
To: kr...@smartcom.bg
Date: Mon, 31 Mar 2014 11:00:48 +
CC: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Community matching policy
Hello Krasi,
Thanks for the reply, appreciated. Sorry I did not mention in my first email
that I'm trying to find a workaround while using invert-match. Any idea on
achieving the same results when using invert-match.
Kind regards,
Date: Mon, 31 Mar 2014 13:41:40 +0300
Subject: Re: [j-nsp] Community matching policy
From: kr...@smartcom.bg
To: good1...@outlook.com
CC: juniper-nsp@puck.nether.net
A match 100:100B match 101:101 Your TEST1 term match on !A OR !B = !(A AND
B), so it effectively rejects every route that has NO communities 100:100 AND
101:101 (at the same time)
Your target is to accept A OR B, so you can first match and accept on these
communities (TEST1 OR TEST2 defined without invert-match) and then reject
everything else.
Best Regards,
Krasi
On 31 March 2014 12:10, Andrew Khan good1...@outlook.com wrote:
Hi -
Let's say I want to reject everything except the following communities:
Either 100:100
OR 101:101
OR both 100:100 101:100
Tried to setup something:
[edit policy-options]
policy-statement TEST {
term TEST1 {
from community [ TEST1 TEST2 ]; ///Is not it logical OR, and
matching everything except what I want because of invert-match//
then reject;
}
term TEST2 {
then accept; And then this should accept what I wanted /
}
}
[edit policy-options]
community TEST1 {
invert-match;
members 100:100;
}
community TEST2 {
invert-match;
members 101:101;
}
However it is rejecting everything. Any thoughts what I'm missing here or
perhaps the approach is not correct.
Thanks in advance.
___
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
___
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] Community matching policy
Yes, that's what that documentation is saying. You probably don't want a
single community statement then.
Regards,
Dave
On 31 March 2014 13:13, Andrew Khan good1...@outlook.com wrote:
Thanks, Dave! Your table is awesome and clarified my doubts and clicked
into my mind :) On your query, It may be possible to add the two
communities into one community statement. I'm unsure how exactly that will
behave though
let's say something like
community A members [ 100:100 101:101 ]; // pretty much (100:100 AND
101:101) //
In that case, the route must have a community that matches 100:100 and a
community that matches 101:101
http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-policy/policy-bgp-communities-extended-communities-evaluation-in-routing-policy-match-conditions.html
Kind regards,
--
Date: Mon, 31 Mar 2014 12:59:57 +0100
Subject: Re: [j-nsp] Community matching policy
From: m...@geordish.org
To: good1...@outlook.com
CC: kr...@smartcom.bg; juniper-nsp@puck.nether.net
The logic of !A OR !B makes my head hurt, so its simple to write out a
truth table to work out exactly what it does.
A | B | !A OR !B
---
T | T | F
T | F | T
F | T | T
F | F | T
This makes it clear that !A OR !B is identical to !(A AND B)
I don't think there is any way to do what you are interested in with the
invert-match statement. I would just do something like this
term A {
from {
community [ A B ];
}
then accept;
}
reject;
community A {
members 100:100;
}
community B {
members 101:101;
}
It may be possible to add the two communities into one community
statement. I'm unsure how exactly that will behave though.
Regards,
Dave
On 31 March 2014 12:47, Andrew Khan good1...@outlook.com wrote:
In addition to my last question, what I don't understand is that !A OR !B
= !(A AND B) /// how come it became AND operation rather than logical
OR///
From Juniper documentation:
You can include the names of multiple communities in the community match
condition. If you do this, only one community needs to match for a match to
occur (matching is effectively a logical OR operation).
Is it invert-match causing this behavior? What if I don't use
invert-match, will it be a logical OR operation e.g. A OR B = A OR B or
will it be A OR B = (A AND B)
Thanks
From: good1...@outlook.com
To: kr...@smartcom.bg
Date: Mon, 31 Mar 2014 11:00:48 +
CC: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Community matching policy
Hello Krasi,
Thanks for the reply, appreciated. Sorry I did not mention in my first
email that I'm trying to find a workaround while using invert-match. Any
idea on achieving the same results when using invert-match.
Kind regards,
Date: Mon, 31 Mar 2014 13:41:40 +0300
Subject: Re: [j-nsp] Community matching policy
From: kr...@smartcom.bg
To: good1...@outlook.com
CC: juniper-nsp@puck.nether.net
A match 100:100B match 101:101 Your TEST1 term match on !A OR !B = !(A
AND B), so it effectively rejects every route that has NO communities
100:100 AND 101:101 (at the same time)
Your target is to accept A OR B, so you can first match and accept on
these communities (TEST1 OR TEST2 defined without invert-match) and then
reject everything else.
Best Regards,
Krasi
On 31 March 2014 12:10, Andrew Khan good1...@outlook.com wrote:
Hi -
Let's say I want to reject everything except the following communities:
Either 100:100
OR 101:101
OR both 100:100 101:100
Tried to setup something:
[edit policy-options]
policy-statement TEST {
term TEST1 {
from community [ TEST1 TEST2 ]; ///Is not it logical OR,
and matching everything except what I want because of invert-match//
then reject;
}
term TEST2 {
then accept; And then this should accept what I wanted /
}
}
[edit policy-options]
community TEST1 {
invert-match;
members 100:100;
}
community TEST2 {
invert-match;
members 101:101;
}
However it is rejecting everything. Any thoughts what I'm missing here
or perhaps the approach is not correct.
Thanks in advance.
___
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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list
Re: [j-nsp] configuration archival, commit comments
I managed to find an hour or so today to look at this further.
A commit script is the result. My very first!
match configuration {
var $comment = $junos-context/commit-context/commit-comment;
if( jcs:empty ($comment)) {
xnm:error {
message No comment specified;
}
}
var $version = version;
change {
junos:comment Automatic commit annotation; _ $comment;
version $version;
}
}
Junos would just complain warning: statement has no contents; ignored when I
tried adding just a comment/annotation, hence the 'change' to version.
version is the very first line of the config, so the annotation ends up right
at the top.
Separately we commit every archived config to a git repo so we end up with
stuff like this;
$ git diff r1..r2
...
@@ -1,5 +1,5 @@
-## Last changed: 2014-03-31 13:46:45 UTC
-/* Automatic commit annotation; remove old annotation */
+## Last changed: 2014-03-31 13:50:03 UTC
+/* Automatic commit annotation; test annotation */
...
...
Mike WilliamsOn Thursday 20 March 2014 13:50:21 wrote:
Hi all,
Random thought for the day.
You can archive the entire config after each commit (archival configuration
transfer-on-commit).
You can apply a comment to each commit (# commit comment blah)
How do you archive that comment?
It's not included in the config.
Thanks
--
Mike Williams
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Community matching policy
With the requirement to use only invert-match community definitions let
say:
TEST1 = everything except 100:100
TEST2 = everything except 101:101
we have !TEST1 OR !TEST2 ( these are target routes you want to accept) =
!(!!TEST1 !!TEST2) = !(TEST1 TEST2)
So define policies:
policy-statement TEST1 {
term 1 {
from community TEST1;
then accept;
}
term 2 {
then reject;
}
}
policy-statement TEST2 {
term 1 {
from community TEST2;
then accept;
}
term 2 {
then reject;
}
}
then apply the following policy expression to BGP neighbor: (!(TEST1
TEST2)):
group test {
neighbor a.b.c.d {
import ( ! ( TEST1 TEST2 ));
}
}
Best regards,
Krasi
On 31 March 2014 14:00, Andrew Khan good1...@outlook.com wrote:
Hello Krasi,
Thanks for the reply, appreciated. Sorry I did not mention in my first
email that I'm trying to find a workaround while using invert-match. Any
idea on achieving the same results when using invert-match.
Kind regards,
--
Date: Mon, 31 Mar 2014 13:41:40 +0300
Subject: Re: [j-nsp] Community matching policy
From: kr...@smartcom.bg
To: good1...@outlook.com
CC: juniper-nsp@puck.nether.net
A match 100:100
B match 101:101
Your TEST1 term match on !A OR !B = !(A AND B), so it effectively
rejects every route that has NO communities 100:100 AND 101:101 (at the
same time)
Your target is to accept A OR B, so you can first match and accept on
these communities (TEST1 OR TEST2 defined without invert-match) and then
reject everything else.
Best Regards,
Krasi
On 31 March 2014 12:10, Andrew Khan good1...@outlook.com wrote:
Hi -
Let's say I want to reject everything except the following communities:
Either 100:100
OR 101:101
OR both 100:100 101:100
Tried to setup something:
[edit policy-options]
policy-statement TEST {
term TEST1 {
from community [ TEST1 TEST2 ]; ///Is not it logical OR, and
matching everything except what I want because of invert-match//
then reject;
}
term TEST2 {
then accept; And then this should accept what I wanted /
}
}
[edit policy-options]
community TEST1 {
invert-match;
members 100:100;
}
community TEST2 {
invert-match;
members 101:101;
}
However it is rejecting everything. Any thoughts what I'm missing here or
perhaps the approach is not correct.
Thanks in advance.
___
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] RE-850 (M7i) and maximum Compact Flash capacity
Hello. I need to change CF in RE-850. How big capacity of CF is supported ? It is difficult to find a 1-2Gb CF now. Have anybody experience installing 8Gb CF ? -- Regards, Sergey ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] maximum BGP multipath ECMP supported on M7i or M10i routers?
Do anyone have in-sight on this? More over, I guess my quest is to find a device that support 1) per flow hashing with as many as ECMP route as possible. (not sure how many ECMP route is supported) 2) consistent hashing (existing flow don't break if route is added or removed) (juniper doc didn't mention this) Your opinion/experience on this is greatly appreciated. Thanks. On Fri, Mar 28, 2014 at 12:44 PM, Yucong Sun sunyuc...@gmail.com wrote: Hi, Does anyone know how many BGP multipath ECMP routes does a M7i/M10i router support? 16? 32 ? 64? I found this document : http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/configuration-statement/maximum-ecmp-edit-chassis.html which says 16/32/64 but it was only mentioning MPLS routes, not BGP multipath routes . I think they might be the samething, but just want to be sure. Thanks! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
