Configuring Interfaces Before the PICs Are Installed

Problem

You are expecting new PICs and want to prepare the configuration file in advance.

Solution

Add the new interface to the router configuration but keep it deactivated:

	[edit 
interfaces]
	aviva@router1# set ge-1/1/0 unit 0 family inet address 172.19.121.3/24
	aviva@router1# set ge-1/1/0 description "172.19.121.3/24; to router2's ge-0/0/1"
	aviva@router1# deactivate ge-1/1/0

Use the following command to activate the interface:

	[edit interfaces]
	aviva@router1# activate ge-1/1/0

 

Discussion

When you are preparing the router for new hardware, either a new PIC or a new FPC with one or more PICs, or when you have a maintenance window in which you will be rearranging the FPCs or PICs in the router, you can preconfigure the interfaces before the hardware has arrived or is in the new location. This recipe shows how to configure a Gigabit Ethernet interface before the PIC is in the router.

The management process, MGD, ignores all inactive portions of the configuration when you issue a commit command. The deactivated configuration is effectively commented out of the configuration file, and the interface control daemons will not see the configuration data. One downside to this is that if there are mistakes in your configuration, you won't see the errors messages from MGD.

Because no physical hardware is installed in the router, you don't see this interface with any of the show interfaces commands. The only way to know that it's there is to look at the configuration. If you are outside the deactivated hierarchy, the CLI marks it with the string inactive:

	[edit interfaces]
	aviva@router1# show
	inactive: ge-1/1/0 {
	 description "172.19.121.3/24; to router2's ge-0/0/1";
	 unit 0 {
	 family inet {
	 address 172.19.121.3/24;
	 }
	 }
	}

If you issue the show command from a hierarchy that is within the deactivated statement, the CLI shows a three-line notice to catch your attention:

	[edit interfaces]
	aviva@router1# show ge-1/1/0 
	##
	## inactive: interfaces ge-1/1/0
	## 
	description "172.19.121.3/24; to router2's ge-0/0/1";
	unit 0 {
	 family inet {
	 address 172.19.121.3/24;
	 }
	}

While you can set the ge-1/1/0 interface configuration without issuing the deactivate command, you are leaving yourself open for possible problems if someone installs the PIC unexpectedly.

Deactivating an interface's configuration rather than deleting is also a good practice when the hardware fails and you are waiting for a replacement PIC. When the new PIC arrives, you don't need to reconfigure the interface. Just reactivate it:

	[edit 
interfaces]
	aviva@router1# activate ge-1/1/0

For all interfaces, you can configure a disable statement. While this might look like a way to deactivate an interface, it actually does something quite different: it activates the interface, but treats it as being down or administratively disabled. When you commit a configuration that contains a disabled interface, the interface control daemon, DCD, sees the interface and the configuration data, but does not configure the interface. Here, you disable interface fe-0/0/0:

	[edit interfaces]
	aviva@router1# set fe-0/0/0 disable

The configuration shows this:

	[edit interfaces]
	aviva@router1# show fe-0/0/0
	disable;
	unit 0 {
	 family inet {
	 address 192.168.20.1/30;
	 {
	}

When you check the status of the interface, you see that the physical interface is administratively down, but the link to the remote side is up. The logical interface is also down.

	aviva@router1> show interfaces fe-0/0/0 terse
	Interface Admin Link Proto Local Remote
	fe-0/0/0 down up
	fe-0/0/0.0 up down inet 192.168.20.1/30

This output illustrates that when an interface is disabled instead of being deactivated, you see information about the interface in the show interfaces output instead of seeing nothing at all, which is the case with the deactivated interface.

To get the interface back up, you might think that it's logical to enable it:

	[edit interfaces fe-0/0/0]
	aviva@router1# set enable

While this does what you want, it may not be what you expect:

	[edit interfaces]
	aviva@router1# show fe-0/0/0
	enable;
	unit 0 {
	 family inet {
	 address 192.168.220.1/30;
	 }
	}

You generally don't need or want to explicitly enable an interface. The better way to get the interface back up is to remove the disable statement:

	[edit interfaces fe-0/0/0]
	aviva@router1# delete disable
	edit interfaces]
	aviva@router1# show fe-0/0/0
	unit 0 {
	 family inet {
	 address 192.168.220.1/30;
	 }
	}