[j-nsp] EX4200 Notprsnt VC members after reboot (filesystem corruption)
Hi all, Not much technical detail to provide at this stage but I wanted to know if anyone else has experienced the same/similar problem -- We've just been through a programme of upgrading ~400 EX4200s (some single switches, most multiple switch/VC) from JUNOS 10.0R2 to 10.0S1. This process, of course, involved lots of reboots. In a small number of cases, upon rebooting the VC, we have member switches 'disappear' -- from the VC master they show up as 'NotPrsnt' (not present). I haven't been involved first hand with the recovery process but from what I understand, the console log entries indicate that the member switch doesn't appear to have unmounted its filesystems cleanly and upon rebooting, filesystem corruption is detected on da0s1a and badness ensues. The end result is a switch that doesn't boot and doesn't join the VC. It's effectively orphaned, unmanageable and an on-site visit is required to recover it. Has anyone had problems with EX4200s and filesystem corruption relating to ungraceful power-downs, routine reboots (i.e. for JUNOS upgrades or whatever), or anything else? Does anyone know of any tricks to access a switch in this state remotely? (unfortunately there is no out-of-band management path available). A re-install of JUNOS (from a JUNOS tgz located in a USB flash disk) typically 'fixes' the problem. A power cycle is not enough. Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Full table inside VRF - J Series
Hi All, Note that my J experience is limited, I've mainly been exposed to lots of C over the years... :). We are looking to try and squeeze a Full table into a vrf on the J Series. Is this possible, or is the only bet to go for an M Series or C7200/NPE-G1 or 2? cheers /rolf ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Setting forwarding-class in firewall filter, non-match behaviour
Hi all,
Re: setting the forwarding-class of a packet through a firewall filter.
Many (almost all) of the examples I've looked at do not include a
catch-all term to handle packets not matched by any explicitly-defined
terms. At the risk of exposing myself as a J-noob...
Is it safe to assume that, if the desired result is that packets NOT
matched by explicitly-defined terms are permitted, a catch-all term
must be configured with an 'accept' (or some other non-terminating)
action?
Using this input filter example:
(stolen from
http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/policy-configuring-actions-in-firewall-filter-terms.html)
firewall {
filter filter1 {
term 1 {
from {
dscp 2;
}
then {
dscp 0;
forwarding-class best-effort;
}
}
term 2 {
from {
dscp 3;
}
then {
forwarding-class best-effort;
}
}
}
}
I read this as:
- if the packet is marked DSCP 2, set DSCP to 0 and place in
'best-effort' forwarding class and accept the packet.
- if the packet is marked DSCP 3, place in 'best-effort' forwarding
class and accept the packet.
- discard all other packets
Am I missing something?
I think what I really want, to avoid dropping traffic, is something like:
firewall {
filter FILTER1 {
term TERM1 {
from {
dscp ef;
}
then forwarding-class expedited-forwarding;
}
term DEFAULT {
then forwarding-class best-effort;
accept;
}
}
}
...then rewrite DSCP bits on egress based on the forwarding-class, or
do it all within the firewall filter (depending on platform).
(I know I don't strictly need the 'accept;' command in the DEFAULT
term, but for the sake of clarity, I think it's a good option)
Cheers,
Dale
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Setting forwarding-class in firewall filter, non-match behaviour
This is probably better:
term BEST-EFFORT
thenforwarding-class best-effort
next-term
term DSCP-EF
fromdscp ef
thenforwarding-class expedited-forwarding
next-term
term default-accept
thenaccept
You can insert additional terms later to modify loss-priority, sampling, etc...
after the classification portion of the filter but before the default-accept.
I would use a rewrite rule to modify DSCP on egress, so that its consistent
across platforms.
From: Dale Shaw dale.shaw+j-...@gmail.com
To: juniper-nsp@puck.nether.net
Sent: Sun, June 20, 2010 3:59:12 AM
Subject: [j-nsp] Setting forwarding-class in firewall filter, non-match
behaviour
Hi all,
Re: setting the forwarding-class of a packet through a firewall filter.
Many (almost all) of the examples I've looked at do not include a
catch-all term to handle packets not matched by any explicitly-defined
terms. At the risk of exposing myself as a J-noob...
Is it safe to assume that, if the desired result is that packets NOT
matched by explicitly-defined terms are permitted, a catch-all term
must be configured with an 'accept' (or some other non-terminating)
action?
Using this input filter example:
(stolen from
http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/policy-configuring-actions-in-firewall-filter-terms.html)
firewall {
filter filter1 {
term 1 {
from {
dscp 2;
}
then {
dscp 0;
forwarding-class best-effort;
}
}
term 2 {
from {
dscp 3;
}
then {
forwarding-class best-effort;
}
}
}
}
I read this as:
- if the packet is marked DSCP 2, set DSCP to 0 and place in
'best-effort' forwarding class and accept the packet.
- if the packet is marked DSCP 3, place in 'best-effort' forwarding
class and accept the packet.
- discard all other packets
Am I missing something?
I think what I really want, to avoid dropping traffic, is something like:
firewall {
filter FILTER1 {
term TERM1 {
from {
dscp ef;
}
then forwarding-class expedited-forwarding;
}
term DEFAULT {
then forwarding-class best-effort;
accept;
}
}
}
...then rewrite DSCP bits on egress based on the forwarding-class, or
do it all within the firewall filter (depending on platform).
(I know I don't strictly need the 'accept;' command in the DEFAULT
term, but for the sake of clarity, I think it's a good option)
Cheers,
Dale
___
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] Recommended sampling rates on MS-500 pic
Hello, I would like to know what is the recommended sampling rates to use on a network and what can the juniper support. In addition, what factors determine what sampling rate to use. Thanks you! --tim ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Setting forwarding-class in firewall filter, non-match behaviour
I personally think Dale's firewall configuration is better. The
config allows for a packet to exit fw filter evaluation once a match
condition is met, by being subjected to a single action. Derick's FW
filter forces a packet to traverse all terms regardless of a match,
and is subjected to at least two actions via two different terms
(fwd-class + next-term AND accept). And there's no real need for the
latter.
Regards,
Addy.
On 6/20/10, Derick Winkworth dwinkwo...@att.net wrote:
This is probably better:
term BEST-EFFORT
thenforwarding-class best-effort
next-term
term DSCP-EF
fromdscp ef
thenforwarding-class expedited-forwarding
next-term
term default-accept
thenaccept
You can insert additional terms later to modify loss-priority, sampling,
etc... after the classification portion of the filter but before the
default-accept. I would use a rewrite rule to modify DSCP on egress, so
that its consistent across platforms.
From: Dale Shaw dale.shaw+j-...@gmail.com
To: juniper-nsp@puck.nether.net
Sent: Sun, June 20, 2010 3:59:12 AM
Subject: [j-nsp] Setting forwarding-class in firewall filter, non-match
behaviour
Hi all,
Re: setting the forwarding-class of a packet through a firewall filter.
Many (almost all) of the examples I've looked at do not include a
catch-all term to handle packets not matched by any explicitly-defined
terms. At the risk of exposing myself as a J-noob...
Is it safe to assume that, if the desired result is that packets NOT
matched by explicitly-defined terms are permitted, a catch-all term
must be configured with an 'accept' (or some other non-terminating)
action?
Using this input filter example:
(stolen from
http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/policy-configuring-actions-in-firewall-filter-terms.html)
firewall {
filter filter1 {
term 1 {
from {
dscp 2;
}
then {
dscp 0;
forwarding-class best-effort;
}
}
term 2 {
from {
dscp 3;
}
then {
forwarding-class best-effort;
}
}
}
}
I read this as:
- if the packet is marked DSCP 2, set DSCP to 0 and place in
'best-effort' forwarding class and accept the packet.
- if the packet is marked DSCP 3, place in 'best-effort' forwarding
class and accept the packet.
- discard all other packets
Am I missing something?
I think what I really want, to avoid dropping traffic, is something like:
firewall {
filter FILTER1 {
term TERM1 {
from {
dscp ef;
}
then forwarding-class expedited-forwarding;
}
term DEFAULT {
then forwarding-class best-effort;
accept;
}
}
}
...then rewrite DSCP bits on egress based on the forwarding-class, or
do it all within the firewall filter (depending on platform).
(I know I don't strictly need the 'accept;' command in the DEFAULT
term, but for the sake of clarity, I think it's a good option)
Cheers,
Dale
___
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
--
Sent from my mobile device
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Setting forwarding-class in firewall filter, non-match behaviour
On Sunday 20 June 2010 05:15:45 pm Derick Winkworth wrote: I would use a rewrite rule to modify DSCP on egress, so that its consistent across platforms. I still prefer the IOS way, where TOS byte values are re- written on ingress (I believe we began a small petition for this capability a year or more back, but it didn't gain any traction). However, it works just as well in JUNOS, just on egress. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Setting forwarding-class in firewall filter, non-match behaviour
Agreed I asked juniper for the same thing but got blown off. Egress remarking rewrites everything not just what I want. On Jun 20, 2010 10:52 AM, Mark Tinka mti...@globaltransit.net wrote: On Sunday 20 June 2010 05:15:45 pm Derick Winkworth wrote: I would use a rewrite rule to modif... I still prefer the IOS way, where TOS byte values are re- written on ingress (I believe we began a small petition for this capability a year or more back, but it didn't gain any traction). However, it works just as well in JUNOS, just on egress. Cheers, Mark. ___ 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] Setting forwarding-class in firewall filter, non-match behaviour
On Sunday 20 June 2010 10:55:10 pm Chris Evans wrote: Agreed I asked juniper for the same thing but got blown off. You can remark/rewrite on ingress but: - only to 'dscp 0'/'dscp be' - only on some platforms (M320, T-series, MPC MX cards) So it's not quite there. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Notprsnt VC members after reboot (filesystem corruption)
On Sun, Jun 20, 2010 at 04:35:40PM +1000, Dale Shaw wrote: Has anyone had problems with EX4200s and filesystem corruption relating to ungraceful power-downs, routine reboots (i.e. for JUNOS upgrades or whatever), or anything else? Does anyone know of any tricks to access a switch in this state remotely? (unfortunately there is no out-of-band management path available). A re-install of JUNOS (from a JUNOS tgz located in a USB flash disk) typically 'fixes' the problem. A power cycle is not enough. Remote console access is needed to fix this. If you can at least connect all the VC member management ethernet ports together with a separate OOB switch along with a Console Server connected to all VC member console ports, even if the OOB network is trunked back to your location through an in-band VLAN, you might be able to recover from this remotely. When I was in this situation recently the corrupted member switch was able to boot enough to be able to FTP JUNOS via OOB from another VC member switch. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Setting forwarding-class in firewall filter, non-match behaviour
I agree. One thing that we do fairly often is create a multifield classifier
like this to just accept a couple of values to place into the appropriate
forwarding-class, then for a default action reset to BE forwarding-class for
all non-matching traffic. This works well in situations where you may not want
to use a BA classifier as you don't trust the markings or you want them
rewritten on egress.
Regards,
-Jeff
On Jun 20, 2010, at 6:47 AM, Addy Mathur wrote:
I personally think Dale's firewall configuration is better. The
config allows for a packet to exit fw filter evaluation once a match
condition is met, by being subjected to a single action. Derick's FW
filter forces a packet to traverse all terms regardless of a match,
and is subjected to at least two actions via two different terms
(fwd-class + next-term AND accept). And there's no real need for the
latter.
Regards,
Addy.
On 6/20/10, Derick Winkworth dwinkwo...@att.net wrote:
This is probably better:
term BEST-EFFORT
thenforwarding-class best-effort
next-term
term DSCP-EF
fromdscp ef
thenforwarding-class expedited-forwarding
next-term
term default-accept
thenaccept
You can insert additional terms later to modify loss-priority, sampling,
etc... after the classification portion of the filter but before the
default-accept. I would use a rewrite rule to modify DSCP on egress, so
that its consistent across platforms.
From: Dale Shaw dale.shaw+j-...@gmail.com
To: juniper-nsp@puck.nether.net
Sent: Sun, June 20, 2010 3:59:12 AM
Subject: [j-nsp] Setting forwarding-class in firewall filter, non-match
behaviour
Hi all,
Re: setting the forwarding-class of a packet through a firewall filter.
Many (almost all) of the examples I've looked at do not include a
catch-all term to handle packets not matched by any explicitly-defined
terms. At the risk of exposing myself as a J-noob...
Is it safe to assume that, if the desired result is that packets NOT
matched by explicitly-defined terms are permitted, a catch-all term
must be configured with an 'accept' (or some other non-terminating)
action?
Using this input filter example:
(stolen from
http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/policy-configuring-actions-in-firewall-filter-terms.html)
firewall {
filter filter1 {
term 1 {
from {
dscp 2;
}
then {
dscp 0;
forwarding-class best-effort;
}
}
term 2 {
from {
dscp 3;
}
then {
forwarding-class best-effort;
}
}
}
}
I read this as:
- if the packet is marked DSCP 2, set DSCP to 0 and place in
'best-effort' forwarding class and accept the packet.
- if the packet is marked DSCP 3, place in 'best-effort' forwarding
class and accept the packet.
- discard all other packets
Am I missing something?
I think what I really want, to avoid dropping traffic, is something like:
firewall {
filter FILTER1 {
term TERM1 {
from {
dscp ef;
}
then forwarding-class expedited-forwarding;
}
term DEFAULT {
then forwarding-class best-effort;
accept;
}
}
}
...then rewrite DSCP bits on egress based on the forwarding-class, or
do it all within the firewall filter (depending on platform).
(I know I don't strictly need the 'accept;' command in the DEFAULT
term, but for the sake of clarity, I think it's a good option)
Cheers,
Dale
___
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
--
Sent from my mobile device
___
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] Setting forwarding-class in firewall filter, non-match behaviour
i wonder what the real world performance implications are on an ASIC forwarding
platform... We really haven't seen any issues with the way we are doing it.
I think I prefer the flexibility for later
From: Richmond, Jeff jeff.richm...@frontiercorp.com
To: Addy Mathur addy.mat...@gmail.com
Cc: Derick Winkworth dwinkwo...@att.net; juniper-nsp@puck.nether.net
juniper-nsp@puck.nether.net
Sent: Sun, June 20, 2010 11:18:40 AM
Subject: Re: [j-nsp] Setting forwarding-class in firewall filter, non-match
behaviour
I agree. One thing that we do fairly often is create a multifield classifier
like this to just accept a couple of values to place into the appropriate
forwarding-class, then for a default action reset to BE forwarding-class for
all non-matching traffic. This works well in situations where you may not want
to use a BA classifier as you don't trust the markings or you want them
rewritten on egress.
Regards,
-Jeff
On Jun 20, 2010, at 6:47 AM, Addy Mathur wrote:
I personally think Dale's firewall configuration is better. The
config allows for a packet to exit fw filter evaluation once a match
condition is met, by being subjected to a single action. Derick's FW
filter forces a packet to traverse all terms regardless of a match,
and is subjected to at least two actions via two different terms
(fwd-class + next-term AND accept). And there's no real need for the
latter.
Regards,
Addy.
On 6/20/10, Derick Winkworth dwinkwo...@att.net wrote:
This is probably better:
term BEST-EFFORT
thenforwarding-class best-effort
next-term
term DSCP-EF
fromdscp ef
thenforwarding-class expedited-forwarding
next-term
term default-accept
thenaccept
You can insert additional terms later to modify loss-priority, sampling,
etc... after the classification portion of the filter but before the
default-accept. I would use a rewrite rule to modify DSCP on egress, so
that its consistent across platforms.
From: Dale Shaw dale.shaw+j-...@gmail.com
To: juniper-nsp@puck.nether.net
Sent: Sun, June 20, 2010 3:59:12 AM
Subject: [j-nsp] Setting forwarding-class in firewall filter, non-match
behaviour
Hi all,
Re: setting the forwarding-class of a packet through a firewall filter.
Many (almost all) of the examples I've looked at do not include a
catch-all term to handle packets not matched by any explicitly-defined
terms. At the risk of exposing myself as a J-noob...
Is it safe to assume that, if the desired result is that packets NOT
matched by explicitly-defined terms are permitted, a catch-all term
must be configured with an 'accept' (or some other non-terminating)
action?
Using this input filter example:
(stolen from
http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/policy-configuring-actions-in-firewall-filter-terms.html)
firewall {
filter filter1 {
term 1 {
from {
dscp 2;
}
then {
dscp 0;
forwarding-class best-effort;
}
}
term 2 {
from {
dscp 3;
}
then {
forwarding-class best-effort;
}
}
}
}
I read this as:
- if the packet is marked DSCP 2, set DSCP to 0 and place in
'best-effort' forwarding class and accept the packet.
- if the packet is marked DSCP 3, place in 'best-effort' forwarding
class and accept the packet.
- discard all other packets
Am I missing something?
I think what I really want, to avoid dropping traffic, is something like:
firewall {
filter FILTER1 {
term TERM1 {
from {
dscp ef;
}
then forwarding-class expedited-forwarding;
}
term DEFAULT {
then forwarding-class best-effort;
accept;
}
}
}
...then rewrite DSCP bits on egress based on the forwarding-class, or
do it all within the firewall filter (depending on platform).
(I know I don't strictly need the 'accept;' command in the DEFAULT
term, but for the sake of clarity, I think it's a good option)
Cheers,
Dale
___
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
--
Sent from my mobile device
___
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] Full table inside VRF - J Series
Yes you can do this on a J-series. If you can handle the full table in inet.0, you can handle this full table in a VRF. Just make sure you have enough RAM to hold a full table (regardless of the type of routing-instance) ... Truman On 20/06/2010, at 4:53 PM, Rolf Mendelsohn wrote: Hi All, Note that my J experience is limited, I've mainly been exposed to lots of C over the years... :). We are looking to try and squeeze a Full table into a vrf on the J Series. Is this possible, or is the only bet to go for an M Series or C7200/NPE-G1 or 2? cheers /rolf ___ 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
