[j-nsp] Interfaces, deactivate vs disable

[Raymond, Steven]

I don't quite understand the difference between deactivate and disable on an interface, from below:

<https://www.juniper.net/techpubs/software/junos/junos60/swconfig60-getting-started/html/cli-configuration-mode43.html>

"In some portions of the configuration hierarchy, you can include a disable statement to disable functionality. One example is disabling an interface by including the disable statement at the [edit interface interface-name] hierarchy level. When you deactivate a statement, that specific object or property is completely ignored and is not applied at all when you issue a commit command. When you disable a functionality, it is activated when you issue a commit command but is treated as though it is down or administratively disabled."

Can anyone please give an example of where it would be better to use either of disable or deactivate, specifically as it pertains to downing an interface?

Thanks

[Harry Reynolds]

Disable sets the interface to admin down, but retains the related
config. When you do a show int terse you will see the protocol families
and addresses. Deactivate causes the related config to be ignored, as
in, factory default. This marks the interface as admin up, but with no
config (no families, addresses, etc.). Either method "bounces" the
interface as the link layer will go down. Personally, I feel that
deactivate can cause folks to feel the problem relates to the config (or
lack of), as it is easy to miss the deactivate statement if you are
below that hierarchy level.

HTHs

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of
Raymond, Steven
Sent: Wednesday, June 08, 2005 8:17 AM
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] Interfaces, deactivate vs disable
I don't quite understand the difference between deactivate
<https://www.juniper.net/techpubs/software/junos/junos60/swcon
fig60-getting-started/html/cli-configuration-mode43.html>
"In some portions of the configuration hierarchy, you can
include a disable statement to disable functionality. One
example is disabling an interface by including the disable
statement at the [edit interface interface-name] hierarchy
level. When you deactivate a statement, that specific object
or property is completely ignored and is not applied at all
when you issue a commit command. When you disable a
functionality, it is activated when you issue a commit
command but is treated as though it is down or
administratively disabled."
Can anyone please give an example of where it would be better
to use either of disable or deactivate, specifically as it
pertains to downing an interface?
Thanks
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

[Eric Van Tol]

Disable is especially useful in the case of monitoring. Deactivate
removes the interface from the config (same as physically pulling the
card out), rendering a previously monitored (SNMP, etc.) port or
interface "gone", thereby causing alarms in your monitoring station.
Reactivation, if I am correct, could cause the SNMP-index number to
change, thereby requiring a change in the NMS(es).

Disabling just disables the interface (shutdown), which still provides
your NMS a point to monitor, albeit zero traffic on that interface.

In addition, if you are an NSP, you may have customers that move from
one medium to another on the same router. The ability to deactivate can
offer you the option of pre-building the configuration of the interface
if they want to keep the same IPs.

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Raymond,
Steven
Sent: Wednesday, June 08, 2005 11:17 AM
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] Interfaces, deactivate vs disable

I don't quite understand the difference between deactivate and disable
on an interface, from below:

<https://www.juniper.net/techpubs/software/junos/junos60/swconfig60-gett
ing-started/html/cli-configuration-mode43.html>

"In some portions of the configuration hierarchy, you can include a
disable statement to disable functionality. One example is disabling an
interface by including the disable statement at the [edit interface
interface-name] hierarchy level. When you deactivate a statement, that
specific object or property is completely ignored and is not applied at
all when you issue a commit command. When you disable a functionality,
it is activated when you issue a commit command but is treated as though
it is down or administratively disabled."

Can anyone please give an example of where it would be better to use
either of disable or deactivate, specifically as it pertains to downing
an interface?

Thanks


_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

[Eric Van Tol]

Personally, I feel that deactivate can cause folks to feel the problem
relates to the config (or lack of), as it is easy to miss the

deactivate

statement if you are below that hierarchy level.

I agree. It would be helpful if deactivated config statements could
have hash-marks in front of them to make it more obvious.

-evt

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Harry Reynolds
Sent: Wednesday, June 08, 2005 11:24 AM
To: Raymond, Steven; juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] Interfaces, deactivate vs disable

Disable sets the interface to admin down, but retains the related
config. When you do a show int terse you will see the protocol families
and addresses. Deactivate causes the related config to be ignored, as
in, factory default. This marks the interface as admin up, but with no
config (no families, addresses, etc.). Either method "bounces" the
interface as the link layer will go down. Personally, I feel that
deactivate can cause folks to feel the problem relates to the config (or
lack of), as it is easy to miss the deactivate statement if you are
below that hierarchy level.

HTHs

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of
Raymond, Steven
Sent: Wednesday, June 08, 2005 8:17 AM
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] Interfaces, deactivate vs disable
I don't quite understand the difference between deactivate
<https://www.juniper.net/techpubs/software/junos/junos60/swcon
fig60-getting-started/html/cli-configuration-mode43.html>
"In some portions of the configuration hierarchy, you can
include a disable statement to disable functionality. One
example is disabling an interface by including the disable
statement at the [edit interface interface-name] hierarchy
level. When you deactivate a statement, that specific object
or property is completely ignored and is not applied at all
when you issue a commit command. When you disable a
functionality, it is activated when you issue a commit
command but is treated as though it is down or
administratively disabled."
Can anyone please give an example of where it would be better
to use either of disable or deactivate, specifically as it
pertains to downing an interface?
Thanks
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

[Johannes Resch]

Post by Raymond, Steven

Personally, I feel that deactivate can cause folks to feel the problem
relates to the config (or lack of), as it is easy to miss the

deactivate

statement if you are below that hierarchy level.

I agree. It would be helpful if deactivated config statements could
have hash-marks in front of them to make it more obvious.

also, it would be really helpful if "disable" used on a physical
interface also disabled the physical layer. (as opposed to deactivating
the whole PIC to disable L1 functionality - which is not really an option
on PICs with more than 1 port)

regards,
-jr

[Daniel Roesen]

Post by Johannes Resch
also, it would be really helpful if "disable" used on a physical
interface also disabled the physical layer. (as opposed to deactivating
the whole PIC to disable L1 functionality - which is not really an option
on PICs with more than 1 port)

Absolutely, a great annoyance right now that you cannot disable L1
properly.

And while we're at it, I (and many others) still way for "disable" on
BGP groups and neighbors. :-)


Best regards,
Daniel

[Richard A Steenbergen]

Post by Daniel Roesen

Post by Johannes Resch
also, it would be really helpful if "disable" used on a physical
interface also disabled the physical layer. (as opposed to deactivating
the whole PIC to disable L1 functionality - which is not really an option
on PICs with more than 1 port)

Absolutely, a great annoyance right now that you cannot disable L1
properly.
And while we're at it, I (and many others) still way for "disable" on
BGP groups and neighbors. :-)

Yes please, and yes please. It is pretty darn annoying not being able to
turn off the laser or make the port stop being green without powering off
the entire PIC, confuses the heck out of remote hands monkeys.

It is also pretty darn annoying that you have to deactivate an entire
group when you deactivate its only/last remaining neighbor, leads to a lot
of weird corner cases with automated config management that just shouldn't
be.

While we're on the subject of small silly but annoying things, fix the
empty prefix-list problem too. :P Sometimes I want a prefix-list to be
empty (so that it can be easily filled with something later), and if I am
referencing it in a standardized config I can't deactivate it without also
breaking the policy that references it. The only work around it to
intentionally put junk data in, and reserve a prefix on which the junk
data can be applied harmlessly, which is just plain stupid. :)

Oh and can't we find the guy who wrote the firewall language and the guy
who wrote the policy language and lock them in the same room together
until they add a termless "then whatever" default action that ALWAYS STAYS
ON THE BOTTOM to the firewall filters. Inserting the "default action" term
to the bottom after adding every new term is a pain in the ass.

Bleh must stop asking for easy things, will just make me disappointed when
I don't get them. :)

[Daniel Roesen]

Post by Richard A Steenbergen
It is also pretty darn annoying that you have to deactivate an entire
group when you deactivate its only/last remaining neighbor, leads to a lot
of weird corner cases with automated config management that just shouldn't
be.

ACK!

Post by Richard A Steenbergen
While we're on the subject of small silly but annoying things, fix the
empty prefix-list problem too. :P Sometimes I want a prefix-list to be
empty (so that it can be easily filled with something later), and if I am
referencing it in a standardized config I can't deactivate it without also
breaking the policy that references it.

Yes yes yes!

Post by Richard A Steenbergen
Oh and can't we find the guy who wrote the firewall language and the guy
who wrote the policy language and lock them in the same room together
until they add a termless "then whatever" default action that ALWAYS STAYS
ON THE BOTTOM to the firewall filters. Inserting the "default action" term
to the bottom after adding every new term is a pain in the ass.

Yep. Another annoyance. Something like "terminal-term" instead of "term
foo" would be nice. Or give the term name "terminal" or "last-resort"
some special meaning.

Post by Richard A Steenbergen
Bleh must stop asking for easy things, will just make me disappointed when
I don't get them. :)

:-)

We should collect all that stuff on
http://wiki.denog.de/twiki/bin/view/NETWORKER/JunosWishlist


Best regards,
Daniel

[Warren Kumari]

While all of these sound nice, I would happily trade them all for a
different prompt (and possibly a warning) when you have typed "commit
confirm" and have not yet typed "commit" - I cannot even begin to
count the number of times I have shot myself in the foot withthat -
seems like I would stop using commit confirmed, but it's like a drug....

Warren

Post by Daniel Roesen

Post by Richard A Steenbergen
It is also pretty darn annoying that you have to deactivate an entire
group when you deactivate its only/last remaining neighbor, leads to a lot
of weird corner cases with automated config management that just shouldn't
be.

ACK!

Post by Richard A Steenbergen
While we're on the subject of small silly but annoying things, fix the
empty prefix-list problem too. :P Sometimes I want a prefix-list to be
empty (so that it can be easily filled with something later), and if I am
referencing it in a standardized config I can't deactivate it
without also
breaking the policy that references it.

Yes yes yes!

Post by Richard A Steenbergen
Oh and can't we find the guy who wrote the firewall language and the guy
who wrote the policy language and lock them in the same room together
until they add a termless "then whatever" default action that
ALWAYS STAYS
ON THE BOTTOM to the firewall filters. Inserting the "default
action" term
to the bottom after adding every new term is a pain in the ass.

Yep. Another annoyance. Something like "terminal-term" instead of "term
foo" would be nice. Or give the term name "terminal" or "last-resort"
some special meaning.

Post by Richard A Steenbergen
Bleh must stop asking for easy things, will just make me
disappointed when
I don't get them. :)

:-)
We should collect all that stuff on
http://wiki.denog.de/twiki/bin/view/NETWORKER/JunosWishlist
Best regards,
Daniel
--
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

[rivo nurges]

Post by Johannes Resch
also, it would be really helpful if "disable" used on a physical
interface also disabled the physical layer. (as opposed to deactivating
the whole PIC to disable L1 functionality - which is not really an option
on PICs with more than 1 port)

As I have recently discovered "disable" will disable L1 on SFP based GE
cards.

[Alexander Koch]

Post by Johannes Resch
also, it would be really helpful if "disable" used on a physical
interface also disabled the physical layer. (as opposed to deactivating
the whole PIC to disable L1 functionality - which is not really an option
on PICs with more than 1 port)

Speaking only of GE interfaces all SFP- equipped interfaces
do that by now. It could be the OC48 SFP cards do the same,
at least that would make sense.

Alexander

[rivo nurges]

Post by Alexander Koch

Post by Johannes Resch
also, it would be really helpful if "disable" used on a physical
interface also disabled the physical layer. (as opposed to deactivating
the whole PIC to disable L1 functionality - which is not really an option
on PICs with more than 1 port)

Speaking only of GE interfaces all SFP- equipped interfaces
do that by now. It could be the OC48 SFP cards do the same,
at least that would make sense.

At least PB-1OC48-SON-SFP and I-1OC48-SON-SFP with 7.2R1.7 doesn't disable L1.

[Julian Cowley]

Post by Eric Van Tol

Personally, I feel that deactivate can cause folks to feel the problem
relates to the config (or lack of), as it is easy to miss the deactivate
statement if you are below that hierarchy level.

I agree. It would be helpful if deactivated config statements could
have hash-marks in front of them to make it more obvious.

Yes, it's not obvious. We decided to use annotation just to remind
us how the interface was disabled:

/* Spare port (remove both disable statements to enable again) */
t3-0/1/1 {
disable;
unit 0 {
disable;
...
}
}

Post by Eric Van Tol
-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Harry Reynolds
Sent: Wednesday, June 08, 2005 11:24 AM
To: Raymond, Steven; juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] Interfaces, deactivate vs disable
Disable sets the interface to admin down, but retains the related
config. When you do a show int terse you will see the protocol families
and addresses. Deactivate causes the related config to be ignored, as
in, factory default. This marks the interface as admin up, but with no
config (no families, addresses, etc.). Either method "bounces" the
interface as the link layer will go down. Personally, I feel that
deactivate can cause folks to feel the problem relates to the config (or
lack of), as it is easy to miss the deactivate statement if you are
below that hierarchy level.
HTHs

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of
Raymond, Steven
Sent: Wednesday, June 08, 2005 8:17 AM
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] Interfaces, deactivate vs disable
I don't quite understand the difference between deactivate
<https://www.juniper.net/techpubs/software/junos/junos60/swcon
fig60-getting-started/html/cli-configuration-mode43.html>
"In some portions of the configuration hierarchy, you can
include a disable statement to disable functionality. One
example is disabling an interface by including the disable
statement at the [edit interface interface-name] hierarchy
level. When you deactivate a statement, that specific object
or property is completely ignored and is not applied at all
when you issue a commit command. When you disable a
functionality, it is activated when you issue a commit
command but is treated as though it is down or
administratively disabled."
Can anyone please give an example of where it would be better
to use either of disable or deactivate, specifically as it
pertains to downing an interface?
Thanks
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

[Eric Van Tol]

This begs the question, if using a standardized config, such as a
firewall filter, what should be done when the packets hit that term
which references the empty prefix-list? should they be accepted or
denied?

See PR59806 for pitfalls of this idea. While I agree that empty
prefix-lists can be helpful, one of our support techs made a grave
mistake when deleting the last prefix out of a prefix-list that was
referenced in a firewall filter. Junos did not issue an error and let
him commit the config, but then proceeded to deny all traffic transiting
the interfaces on which the filter was applied.

-evt

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Richard A
Steenbergen
Sent: Wednesday, June 08, 2005 12:46 PM
To: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Re: Interfaces, deactivate vs disable

Post by Daniel Roesen

Post by Johannes Resch
also, it would be really helpful if "disable" used on a physical
interface also disabled the physical layer. (as opposed to

deactivating

Post by Daniel Roesen

Post by Johannes Resch
the whole PIC to disable L1 functionality - which is not really an

option

Post by Daniel Roesen

Post by Johannes Resch
on PICs with more than 1 port)

Absolutely, a great annoyance right now that you cannot disable L1
properly.
And while we're at it, I (and many others) still way for "disable" on
BGP groups and neighbors. :-)

Yes please, and yes please. It is pretty darn annoying not being able to

turn off the laser or make the port stop being green without powering
off
the entire PIC, confuses the heck out of remote hands monkeys.

It is also pretty darn annoying that you have to deactivate an entire
group when you deactivate its only/last remaining neighbor, leads to a
lot
of weird corner cases with automated config management that just
shouldn't
be.

While we're on the subject of small silly but annoying things, fix the
empty prefix-list problem too. :P Sometimes I want a prefix-list to be
empty (so that it can be easily filled with something later), and if I
am
referencing it in a standardized config I can't deactivate it without
also
breaking the policy that references it. The only work around it to
intentionally put junk data in, and reserve a prefix on which the junk
data can be applied harmlessly, which is just plain stupid. :)

Oh and can't we find the guy who wrote the firewall language and the guy

who wrote the policy language and lock them in the same room together
until they add a termless "then whatever" default action that ALWAYS
STAYS
ON THE BOTTOM to the firewall filters. Inserting the "default action"
term
to the bottom after adding every new term is a pain in the ass.

Bleh must stop asking for easy things, will just make me disappointed
when
I don't get them. :)

[Daniel Roesen]

Post by Eric Van Tol
This begs the question, if using a standardized config, such as a
firewall filter, what should be done when the packets hit that term
which references the empty prefix-list? should they be accepted or
denied?

That depends on the context in which the prefix-list is used. And
I disagree with IOS' semantics here.

A prefix-list specifies prefixes which do match when the prefix-list
is being referenced. The natural no-surprises outcome of an empty
prefix-list is (should be) that no prefix matches. If I give you an
empty shopping list you don't come back with all the goods the shop
had to offer, do you? :-)


Best regards,
Daniel

[Lars Erik Gullerud]

Post by Daniel Roesen

Post by Eric Van Tol
This begs the question, if using a standardized config, such as a
firewall filter, what should be done when the packets hit that term
which references the empty prefix-list? should they be accepted or
denied?

That depends on the context in which the prefix-list is used. And
I disagree with IOS' semantics here.
A prefix-list specifies prefixes which do match when the prefix-list
is being referenced. The natural no-surprises outcome of an empty
prefix-list is (should be) that no prefix matches. If I give you an
empty shopping list you don't come back with all the goods the shop
had to offer, do you? :-)

I couldn't agree more - I actually prefer the OLD JunOS behaviour that
would not let you commit a configuration with an empty prefix-list over
the current behaviour that allows empty lists, having been bit by the same
problem as the previous poster.

Firewall term referencing a prefix-list, with a discard-action. Remove the
last IP in the prefix-list and it suddenly matches ANY, not NONE - whoops,
there goes all your traffic into the big bitbucket in the sky. I'd rather
take the "checkout failed" message any day. :-/

/leg

[Josef Buchsteiner]

Post by Daniel Roesen

Post by Eric Van Tol
This begs the question, if using a standardized config, such as a
firewall filter, what should be done when the packets hit that term
which references the empty prefix-list?? should they be accepted or
denied?

That depends on the context in which the prefix-list is used. And
I disagree with IOS' semantics here.
A prefix-list specifies prefixes which do match when the prefix-list
is being referenced. The natural no-surprises outcome of an empty
prefix-list is (should be) that no prefix matches. If I give you an
empty shopping list you don't come back with all the goods the shop
had to offer, do you? :-)

LEG> I couldn't agree more - I actually prefer the OLD JunOS behaviour that
LEG> would not let you commit a configuration with an empty prefix-list over
LEG> the current behaviour that allows empty lists, having been bit by the same
LEG> problem as the previous poster.

LEG> Firewall term referencing a prefix-list, with a discard-action. Remove the
LEG> last IP in the prefix-list and it suddenly matches ANY, not NONE - whoops,

this is a bug and fixed in 7.2+ 7.2R2 7.3R1 . Once the prefix
list is empty we should not match in the firewall. I need to look what the
issue is once we use an empty prefix-list in a policy.

Josef


LEG> there goes all your traffic into the big bitbucket in the sky. I'd rather
LEG> take the "checkout failed" message any day. :-/





LEG> /leg
LEG> _______________________________________________
LEG> juniper-nsp mailing list juniper-nsp at puck.nether.net
LEG> http://puck.nether.net/mailman/listinfo/juniper-nsp

[Harry Reynolds]

AFAIK, we have sticky SNMP index values as they are written to a file.
Unless new HW is added, or pics are moved, I think the index will stay
the same. Also, IMO deactivate is not the same as pulling the card. With
no card the interface is not listed in a show interface. With
deactivate, it is listed but as if there was no configuration.
Deactivating will cause any logical units/sub interfaces to
disappear....

Cheers

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Eric Van Tol
Sent: Wednesday, June 08, 2005 8:26 AM
To: Raymond, Steven; juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] Interfaces, deactivate vs disable
Disable is especially useful in the case of monitoring.
Deactivate removes the interface from the config (same as
physically pulling the card out), rendering a previously
monitored (SNMP, etc.) port or interface "gone", thereby
causing alarms in your monitoring station.
Reactivation, if I am correct, could cause the SNMP-index
number to change, thereby requiring a change in the NMS(es).
Disabling just disables the interface (shutdown), which still
provides your NMS a point to monitor, albeit zero traffic on
that interface.
In addition, if you are an NSP, you may have customers that
move from one medium to another on the same router. The
ability to deactivate can offer you the option of
pre-building the configuration of the interface if they want
to keep the same IPs.
-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of
Raymond, Steven
Sent: Wednesday, June 08, 2005 11:17 AM
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] Interfaces, deactivate vs disable
I don't quite understand the difference between deactivate
<https://www.juniper.net/techpubs/software/junos/junos60/swcon
fig60-gett
ing-started/html/cli-configuration-mode43.html>
"In some portions of the configuration hierarchy, you can
include a disable statement to disable functionality. One
example is disabling an interface by including the disable
statement at the [edit interface interface-name] hierarchy
level. When you deactivate a statement, that specific object
or property is completely ignored and is not applied at all
when you issue a commit command. When you disable a
functionality, it is activated when you issue a commit
command but is treated as though it is down or
administratively disabled."
Can anyone please give an example of where it would be better
to use either of disable or deactivate, specifically as it
pertains to downing an interface?
Thanks
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

[Phil Shafer]

Disable sets the interface to admin down, but retains the related config.

Implementation-wise, the difference is that "disable" is implemented
in specific software components, while deactivate/activate/inactive
are all controlled by the UI software. During commit, any
configuration marked inactive will not be published to software
components. If you disable an interface, the interface control daemon
will see if, but not configure it. If you deactivate it, the daemon
will not see the configuration data.

So deactivated configuration is effectively commented out of the
configuration file.

Personally, I feel that deactivate can cause
folks to feel the problem relates to the config (or lack of), as it is
easy to miss the deactivate statement if you are below that hierarchy
level.

This should no longer be the case, you should see a message informing
you that the configuration in inactive and where in the hierarchy
above you it was deactivated:

[edit interfaces so-3/3/3 unit 0 family inet]
cli# show
##
## inactive: interfaces so-3/3/3
##
filter {
input test;
output test;
}
address 10.1.2.3/24;

[edit interfaces so-3/3/3 unit 0 family inet]
cli# show filter
##
## inactive: interfaces so-3/3/3
##
input test;
output test;

[edit interfaces so-3/3/3 unit 0 family inet]
cli# top

[edit]
cli# show interfaces so-3/3/3 unit 0 family inet filter
##
## inactive: interfaces so-3/3/3
##
input test;
output test;

[edit]
cli#

Thanks,
Phil

[Phil Shafer]

Post by Warren Kumari
I would happily trade them all for a
different prompt (and possibly a warning) when you have typed "commit
confirm" and have not yet typed "commit"

Should be simple enough to improve the drug. It's now PR 60372.

Thanks,
Phil

[Phil Shafer]

Post by Daniel Roesen
Yep. Another annoyance. Something like "terminal-term" instead of "term
foo" would be nice. Or give the term name "terminal" or "last-resort" some
special meaning.

Are you looking for a full term or just an "otherwise"?

Thanks,
Phil

[Daniel Roesen]

Post by Phil Shafer

Post by Daniel Roesen
Yep. Another annoyance. Something like "terminal-term" instead of "term
foo" would be nice. Or give the term name "terminal" or "last-resort" some
special meaning.

Are you looking for a full term or just an "otherwise"?

Uhm, what do you mean with "just an 'otherwise'"? Can you given an
example?

What I was thinking of was e.g.:

policy-options {
policy-statement bla {
term accept-FOO {
...
}
term accept-BAR {
...
}
term accept-BAZ {
...
}
term deny-and-log-rest {
then {
discward;
log;
count denied-rest;
}
}
}
}

Now I want to add more FROB and QUX acceptance. Everytime I have to
add something I need to do the "set term ..." drill, and always
remember the final "insert term deny-and-log-rest after
$LAST_ADDED_TERM". How nice it would be to have

...
terminal-term deny-and-log-rest {
then {
discard;
log;
count denied-rest
}
}
...

which would automatically get sorted as last term in the policy/filter
automatically.

I know it's possible for policies by no using "term" but just "then"
directly in the policy-statement level (which is ugly and makes readers
scratch their head), but this is not possible with firewall filters.


Best regards,
Daniel

[Erdem Sener]

Hi,

Although what you suggest is wise enough on a last term aspect, but
still the question "where to place it between multiple terms?" remains
I guess.

Cheers,
Erdem

Post by Daniel Roesen

Post by Phil Shafer

Post by Daniel Roesen
Yep. Another annoyance. Something like "terminal-term" instead of "term
foo" would be nice. Or give the term name "terminal" or "last-resort" some
special meaning.

Are you looking for a full term or just an "otherwise"?

Uhm, what do you mean with "just an 'otherwise'"? Can you given an
example?
policy-options {
policy-statement bla {
term accept-FOO {
...
}
term accept-BAR {
...
}
term accept-BAZ {
...
}
term deny-and-log-rest {
then {
discward;
log;
count denied-rest;
}
}
}
}
Now I want to add more FROB and QUX acceptance. Everytime I have to
add something I need to do the "set term ..." drill, and always
remember the final "insert term deny-and-log-rest after
$LAST_ADDED_TERM". How nice it would be to have
...
terminal-term deny-and-log-rest {
then {
discard;
log;
count denied-rest
}
}
...
which would automatically get sorted as last term in the policy/filter
automatically.
I know it's possible for policies by no using "term" but just "then"
directly in the policy-statement level (which is ugly and makes readers
scratch their head), but this is not possible with firewall filters.
Best regards,
Daniel
--
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

[Richard A Steenbergen]

Post by Daniel Roesen
Now I want to add more FROB and QUX acceptance. Everytime I have to
add something I need to do the "set term ..." drill, and always
remember the final "insert term deny-and-log-rest after
$LAST_ADDED_TERM". How nice it would be to have
...
terminal-term deny-and-log-rest {
then {
discard;
log;
count denied-rest
}
}
...

I think you're over-complicating it. Just as we now have:

policy-statement blah {
term foo {
....
}
term bar {
....
}
then {
default action which always stays on the bottom here;
}
}

We should also have:

filter blah {
term foo {
....
}
term bar {
....
}
then {
default action which always stays on the bottom here;
}
}

This only seems logical, since most firewalls will have some default
action for that which doesn't match (a default reject, accept, log, etc).

Of course what I would really kill for is chained firewall filters like we
have chained policies, but lets start with this dirt simple feature first.
:)

[Daniel Roesen]

Probably.

Post by Richard A Steenbergen
filter blah {
term foo {
....
}
term bar {
....
}
then {
default action which always stays on the bottom here;
}
}
This only seems logical, since most firewalls will have some default
action for that which doesn't match (a default reject, accept, log, etc).

Yes, but I'm always uncomfortable with mixing the terms syntax with
the no-terms syntax. I just doesn't look "right". Perhaps "then"
without a covering term should be forbidden if other terms do exist,
and instead call it "default". THAT would make sense to me. And this
could work the same way in policies.

So you can have either:

filter/policy blah {
term foo {
....
}
term bar {
....
}
default {
default action which always stays on the bottom here;
}
}

but still policies like:

policy blah {
then {
...
}
}

or

policy blah {
from {
....
}
then {
....
}
}

Post by Richard A Steenbergen
Of course what I would really kill for is chained firewall filters like we
have chained policies, but lets start with this dirt simple feature first.

Oh indeed. I have that on my long christmas wishlist too. :)

$ grep "filter chain" vendor/juniper/JunOS-featurerequests
- support firewall filter chains on interfaces

That would make it easy to combine generic filters with
interface-specific ones... which isn't possible atm.


Best regards,
Daniel

[Richard A Steenbergen]

Post by Daniel Roesen
Yes, but I'm always uncomfortable with mixing the terms syntax with
the no-terms syntax. I just doesn't look "right". Perhaps "then"
without a covering term should be forbidden if other terms do exist,
and instead call it "default". THAT would make sense to me. And this
could work the same way in policies.

I dunno, a default "then" action seems to make perfect sense to me. It is
a direct reference to the "then" block in a term, and because there is no
other match criteria no other elements are needed. In my mind this makes
far more sense than some reserved-name term, and probably implements a
lot easier too.

For example, lets say that you had a reserved-name term "default" which
always got sorted in the bottom. Besides the fact that this behavior is
non-obvious to the casual observer, and hard to document in the cli online
help, it leads to unnecessary one-off behaviors. Lets say that I type
"insert term default before term someearlierterm", what happens? Does it
stay stuck at the bottom? Does it generate an error? I don't see why you
would want to screw with it personally, when the default "then" action
simplifies term-less configs AND makes so much sense already. :)

But at any rate, I don't want to confuse the poor Juniper people or dilute
the point that we need a default-action term. Asking for such a complex
change is probably just going to result in no action being taken without
major customer revenue attached. We're better off asking for something
that is so simple to implement and test that they can slip it in simply
because it *should* be done, and not because someone with a $50mil check
is demanding it. Plus it is pretty much self-documenting, since it just
makes firewalling consistant with the existing policy language.

[Phil Shafer]

Post by Daniel Roesen

Post by Phil Shafer
Are you looking for a full term or just an "otherwise"?

Uhm, what do you mean with "just an 'otherwise'"? Can you given an
example?

My question was whether you needed a full term or just the "then"
part of it, as a "then" to be applied when no terms match.

I was thinking of the way you can currently put a term-less "then"
after all your term in a policy-statement:

[edit policy-options policy-statement test]
root at dent# show
term one {
from interface so-0/0/0.0;
then reject;
}
... more terms ...
then {
color add 50;
accept;
}

We can do something like this for filters. It's now PR 60413.

Post by Daniel Roesen
I know it's possible for policies by no using "term" but just "then"
directly in the policy-statement level (which is ugly and makes readers
scratch their head), but this is not possible with firewall filters.

We'll likely follow the existing precedent so readers only have so
scratch their head once.

Thanks,
Phil

[Daniel Roesen]

Post by Phil Shafer

Post by Daniel Roesen

Post by Phil Shafer
Are you looking for a full term or just an "otherwise"?

Uhm, what do you mean with "just an 'otherwise'"? Can you given an
example?

My question was whether you needed a full term or just the "then"
part of it, as a "then" to be applied when no terms match.

Just the latter.

Post by Phil Shafer
I was thinking of the way you can currently put a term-less "then"

[...]

Post by Phil Shafer
We can do something like this for filters. It's now PR 60413.

Excellent! Thanks Phil!

Post by Phil Shafer

Post by Daniel Roesen
I know it's possible for policies by no using "term" but just "then"
directly in the policy-statement level (which is ugly and makes readers
scratch their head), but this is not possible with firewall filters.

We'll likely follow the existing precedent so readers only have so
scratch their head once.

I'll rest for it. Better 95% than 0%. At least the functionality would
be there then. ;)


Best regards,
Daniel

[Douglas Marschke]

I think the behavior is consistent though. No from statement in a term
matches all. So an empty prefix list to me, would be like having no
from statement which would match all.



-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Lars Erik
Gullerud
Sent: Wednesday, June 08, 2005 4:11 PM
To: Daniel Roesen
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Re: Re: Interfaces, deactivate vs disable

Post by Eric Van Tol
This begs the question, if using a standardized config, such as a
firewall filter, what should be done when the packets hit that term
which references the empty prefix-list? should they be accepted or
denied?

That depends on the context in which the prefix-list is used. And I
disagree with IOS' semantics here.
A prefix-list specifies prefixes which do match when the prefix-list
is being referenced. The natural no-surprises outcome of an empty
prefix-list is (should be) that no prefix matches. If I give you an
empty shopping list you don't come back with all the goods the shop
had to offer, do you? :-)

I couldn't agree more - I actually prefer the OLD JunOS behaviour that
would not let you commit a configuration with an empty prefix-list over
the current behaviour that allows empty lists, having been bit by the
same problem as the previous poster.

Firewall term referencing a prefix-list, with a discard-action. Remove
the last IP in the prefix-list and it suddenly matches ANY, not NONE -
whoops, there goes all your traffic into the big bitbucket in the sky.
I'd rather take the "checkout failed" message any day. :-/

/leg
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

[Daniel Roesen]

Post by Douglas Marschke
I think the behavior is consistent though. No from statement in a term
matches all. So an empty prefix list to me, would be like having no
from statement which would match all.

I cannot follow this logic, and from what I gather discussing this with
other folks, noone else either. :-)

Can you please point out where this "empty prefix-list matching any"
makes any sense? I have yet to experience any situation where I want
to match anything, but keep the option to specify the exact list later.
Or want to fallback from specifics to "any".


Best regards,
Daniel

[Doug Marschke]

Well makes sense to me, but that does not mean it makes sense to all!

Looks like it will change anyway...so you win! ;)


----- Original Message -----
From: "Daniel Roesen" <dr at cluenet.de>
To: <juniper-nsp at puck.nether.net>
Sent: Monday, June 13, 2005 8:02 AM
Subject: [j-nsp] Re: Re: Re: Interfaces, deactivate vs disable

Post by Daniel Roesen

Post by Douglas Marschke
I think the behavior is consistent though. No from statement in a term
matches all. So an empty prefix list to me, would be like having no
from statement which would match all.

I cannot follow this logic, and from what I gather discussing this with
other folks, noone else either. :-)
Can you please point out where this "empty prefix-list matching any"
makes any sense? I have yet to experience any situation where I want
to match anything, but keep the option to specify the exact list later.
Or want to fallback from specifics to "any".
Best regards,
Daniel
--
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp