[j-nsp] Interfaces, deactivate vs disable

[Julian Cowley]

On Wed, 8 Jun 2005, Eric Van Tol wrote:
>> 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;
 	    ...
 	}
     }

> -----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
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>
>

-- 
The question is, "What is the question?"  That is the question of what the
question is, isn't it?