Many times as a business, and in turn a network, grows new equipment is needed to cope with more users, more bandwidth, and increased feature usage. In this case, an administrator may want to move a configuration from an old AOS unit to a new AOS unit in lieu of having to recreate the configuration from scratch. This document covers the processes for doing this and any concerns a user must have before hand.
Sections Included in this Document
Hardware and Software Requirements
Deployment Concerns and Considerations
Creating the New Configuration
- Uploading the Configuration using the Web Interface
- Uploading the Configuration using the CLI
- Verifying the New Configuration
Hardware and Software Requirements
All units that run AOS use the same command set which means that a configuration on any unit can be moved to another with little intervention. However, it is important to note that if the unit you are moving to does not have the same features you have configured on your current unit, those commands will be lost. Check the AOS Feature Matrix - Product Feature Matrix to see if your new unit supports your current features.
Many times in AOS, command structures have been changed to accommodate new syntax for added features. If upgrading to a unit with equivalent or newer software, this will not cause a problem. However, if moving to a unit with a lower firmware version, these commands will not be accepted properly and could cause loss of configuration. It is important to make sure the new unit has an equivalent or higher firmware version to prevent this.
If your old unit was utilizing modules including NIMs, VIMs, Wide Modules, or XIMs, make sure these are inserted into the new unit properly before booting it and loading the new configuration. If not, these commands will not be accepted.
Deployment Concerns and Considerations
Before moving a configuration to a new unit, make sure you have a saved copy of the current configuration that can be referenced back to after making changes if needed. It is also recommended that this configuration be kept on the old unit, and to keep this unit on standby so that if the insertion of the new unit does not function properly, the original unit can be easily inserted in to get the circuit functioning properly again.
ADTRAN recommends that you also test the new configuration once it has been finalized on the new unit (or an equivalent) in a lab environment to make sure that the configuration loads correctly and functions properly.
It is also recommended that a straight-through DB9 - DB9, male to female serial cable, be kept on hand so that in case the configuration is loaded incorrectly, the unit will be accessible even if IP connectivity is not available. For more information on this, please see the appropriate section on console connections in Accessing the Command Line Interface in AOS.
Creating the New Configuration
There are two main issues that must be addressed when moving a configuration from unit to unit:
- The original and new unit's feature set difference (as discussed in the Hardware and Software Requirements section)
- The unit's physical interfaces
The first issue is very simple, and should be addressed before the purchase of the new unit. If you are using a feature on your original unit that would like to continue to use, make sure your new choice of unit supports that feature. If not, these commands will be lost upon the upload of the new configuration.
The second issue is slightly more involved. Generally, different AOS units have different physical interfaces. The NetVanta and Total Access line have a vast array of built in and supported add-on interfaces. There are many variations like the number of NIM slots, the number of Ethernet ports, Ethernet and gigabit-Ethernet ports on different units, as well as the ability to support certain virtual interfaces like VLANs. It is important to study and know the new unit's built in and virtual interface ability and to make decisions before hand of which interface will represent which of the original unit's connections.
Adding to this, different AOS units have different slot and port designations for different interfaces. Though they all follow the same naming convention, NIM slots vary on certain equipment meaning that a slot/port designation could move from 1/1 to 3/1, etc. This should be verified before creating the configuration.
Luckily, after the interface designation and numbering scheme have been figured out, the commands under the certain interfaces can be simply copied under the new interface. The only caveat to this are interface specific features. Though all IP interfaces work in the same basic manner (even virtual vs. physical interfaces), there are certain commands that are unique to certain interfaces. For example, a PPP interface may have an IP address, subnet mask, and the no shutdown command which will be the same if moving to an Ethernet interface. However, if the command ppp authentication chap is also included, this will not be used on the Ethernet interface because it is a PPP specific command.
An example configuration move is shown below for reference.
Company A currently has a NetVanta 3458 controlling all the routing function in their network. They are looking to move to a fiber/gigabit solution for their internet connection, and in turn have decided to move from the NetVanta 3448 to a NetVanta 4430 which has 2 Gigabit Ethernet ports, as well as a third Ethernet interface, NIM slots, a wide modular slot and a higher capacity routing back-plane. Currently the NetVanta 3458 is using Ethernet 0/1 for the LAN, Ethernet 0/2 for their Internet connection, VLAN 1 for their DMZ (plugged into Switchport 0/1) and NIM slot 1 and 2 for their 4xT1 point-to-point circuit to a neighboring site. All of the features on the 3458 are available on the 4430 and the 4430 is running the same firmware, so no commands should be in jeopardy of being removed upon conversion.
Below is the configuration for the relevant portion of the NetVanta 3458 (its interface configuration)
interface eth 0/1
description LAN
ip address 10.10.10.1 255.255.255.0
ip access-policy Private
no shutdown
!
interface eth 0/2
description WAN
ip address 1.1.1.1 255.255.255.252
ip access-policy Public
no shutdown
!
interface switchport 0/1
no shutdown
!
interface switchport 0/2
no shutdown
!
interface switchport 0/3
no shutdown
!
interface switchport 0/4
no shutdown
!
interface switchport 0/5
no shutdown
!
interface switchport 0/6
no shutdown
!
interface switchport 0/7
no shutdown
!
interface switchport 0/8
no shutdown
!
interface vlan 1
description DMZ
ip address 192.168.0.1 255.255.255.0
ip access-policy DMZ
no shutdown
!
interface t1 1/1
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 1/2
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 2/1
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 2/2
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface ppp 1
ip address 172.16.0.1 255.255.255.252
ppp multilink
cross-connect 1 t1 1/1 1 ppp 1
cross-connect 2 t1 1/2 1 ppp 1
cross-connect 3 t1 2/1 1 ppp 1
cross-connect 4 t1 2/2 1 ppp 1
!
The NetVanta 4430 port designations will be much different. The 4430 has 2 Gigabit Ethernet ports, 1 fast Ethernet port, 2 NIM slots (slots 1 and 2), and 1 wide-module (slot 3). Company A decides to match the connections to the following interfaces:
- LAN: Gigabit-ethernet 0/1
- WAN: Gigabit-ethernet 0/2
- DMZ: ethernet 0/1
- PPP connection: Because of possible further expansion, Company A purchases a wide module and will be moving the T1's to the 8xT1 wide module
Let's go through the configuration changes step by step:
LAN: Gigabit-ethernet 0/1
Here is the LAN configuration for Ethernet 0/1 on the 3458:
interface eth 0/1
description LAN
ip address 10.10.10.1 255.255.255.0
ip access-policy Private
no shutdown
Moving this to a gigabit Ethernet port is very simple. Ethernet interfaces, regardless of type, will generally take the same commands. In this case, all we need to do is change the port designation:
interface gigabit-ethernet 0/1
description LAN
ip address 10.10.10.1 255.255.255.0
ip access-policy Private
no shutdown
WAN: Gigabit-ethernet 0/2
The following is the WAN interface configuration on the 3458:
interface eth 0/2
description WAN
ip address 1.1.1.1 255.255.255.252
ip access-policy Public
no shutdown
Again in this section, we must just simply change the interface designation:
interface gigabit-ethernet 0/2
description WAN
ip address 1.1.1.1 255.255.255.252
ip access-policy Public
no shutdown
It is important to note that the switchports below the Ethernet 0/2 interface should be removed. The 4430 does not have any switchports.
DMZ: Ethernet 0/1
For the DMZ configuration, we are simply moving a VLAN interface to an Ethernet interface. Though VLANs are virtual, the command set between a VLAN and a Ethernet port have very few differences, meaning we can simply change the interface type and number.
interface vlan 1
description DMZ
ip address 192.168.0.1 255.255.255.0
ip access-policy DMZ
no shutdown
The new interface would look like the below:
interface Ethernet 0/1
description DMZ
ip address 192.168.0.1 255.255.255.0
ip access-policy DMZ
no shutdown
PPP connection
This conversion is a little trickier. The PPP portion will mostly be able to stay the same because PPP is supported inside the 4430 in the same manner. However, the T1s are being moved to the wide slot, slot 3, so numbering for the T1 interfaces must change The original T1 interface configuration of the 3458 below:
interface t1 1/1
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 1/2
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 2/1
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 2/2
tdm-group 1 timeslots 1-24 speed 64
no shutdown
Will become the following on the 4430:
interface t1 3/1
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 3/2
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 3/3
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 3/4
tdm-group 1 timeslots 1-24 speed 64
no shutdown
Changing these slot and port numbers, however, does affect the some of the PPP configuration. At the bottom of the PPP configuration, you will see the cross connects that actually designate the underlying T1s the PPP connection operates across. Since these slots have changed, we must change them in this configuration as well. The original is below:
interface ppp 1
ip address 172.16.0.1 255.255.255.252
ppp multilink
cross-connect 1 t1 1/1 1 ppp 1
cross-connect 2 t1 1/2 1 ppp 1
cross-connect 3 t1 2/1 1 ppp 1
cross-connect 4 t1 2/2 1 ppp 1
!
On the 4430 it will become:
interface ppp 1
ip address 172.16.0.1 255.255.255.252
ppp multilink
cross-connect 1 t1 3/1 1 ppp 1
cross-connect 2 t1 3/2 1 ppp 1
cross-connect 3 t1 3/3 1 ppp 1
cross-connect 4 t1 3/4 1 ppp 1
!
The configuration is now ready to be tested and then added to the new 4430 for the upgrade. The modified interface configurations are shown below:
interface gigabit-ethernet 0/1
description LAN
ip address 10.10.10.1 255.255.255.0
ip access-policy Private
no shutdown
!
interface gigabit-ethernet 0/2
description WAN
ip address 1.1.1.1 255.255.255.252
ip access-policy Public
no shutdown
!
interface eth 0/1
description DMZ
ip address 192.168.0.1 255.255.255.0
ip access-policy DMZ
no shutdown
!
interface t1 3/1
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 3/2
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 3/3
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 3/4
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface ppp 1
ip address 172.16.0.1 255.255.255.252
ppp multilink
cross-connect 1 t1 3/1 1 ppp 1
cross-connect 2 t1 3/2 1 ppp 1
cross-connect 3 t1 3/3 1 ppp 1
cross-connect 4 t1 3/4 1 ppp 1
!
Note that this is not a complete configuration and only the illustrative sections referenced for the purpose of this guide.
Now that the configuration is ready, it should be uploaded to the new unit and made active so that it can be used.
For help access the AOS Web Interface, please see the document https://supportforums.adtran.com/docs/DOC-2898.
Once inside the Web Interface, click on the "utilities" tab on the left-hand menu and then click "configuration". You should see the below:
To upload the configuration, press "choose file" at the bottom and select the new configuration file you created. Once this has been done, click "upload". Once the configuration has been uploaded, the screen will refresh and you will see a message explaining a reboot is necessary with an associated "Reboot" button. Press this. When the unit finishes rebooting, the new configuration is now active.
There are many ways to upload the configuration to the unit including FTP, SCP, Xmodem (through console), HTTP, and more. In this example, we will use TFTP as this is usually the simplest way via IP to do this as many computers can run simple tftp servers.
To TFTP the configuration onto the unit, put the new file in the appropriate directory on the TFTP server and then run the following commands:
#copy tftp startup-config
Address of remote host? 10.10.10.1
Source filename? config.txt
Destination filename? config.txt
As you can see above, after typing the copy tftp startup-config command, the unit will ask you for the TFTP server address. After inputting that, you will be asked for the source and destination filename. Once this is entered, the transfer will start.
Once the transfer is finished you should be able to see the new configuration as the current startup-config using the show startup-config command. When rebooting the unit, remember to refrain from saving the current running configuration as this will overwrite what you uploaded and saved as the startup configuration.
If after the unit boots up, the unit does not seem to be functioning properly, you can use the show output-errors command to view what configuration in the startup-config created an error when it tried to apply it. This is where a console cable becomes handy, especially if for some reason the unit is not available. An example of this command output is shown below:
#show output-errors
!
(config)#interface vlan 1
%unrecognized command
(config)#description DMZ
%unrecognized command
(config)#ip address 172.16.0.1 255.255.255.0
%unrecognized command
(config)#ip access-policy DMZ
%unrecognized command
(config)#no shutdown
%unrecognized command
Using our original example, you can see above that the VLAN was never changed to Ethernet 0/1 for the DMZ. Because of this, all those commands were entered in global configuration mode, meaning they were not accepted. In this case, we need to edit the startup-config again and reload it on the unit, or manually add those configuration commands.
Similarly, use this command to see any other errors that might have also failed and then add those commands or investigate why they were not entered correctly.
For instruction on logging into the AOS CLI, please see Accessing the Command Line Interface in AOS.
For more information regarding access the AOS web interface, please see Accessing the Web Interface in AOS.
