[j-nsp] Interfaces, deactivate vs disable

[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 
> and disable on an interface, from below:
> 
> <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