Table Of Contents
Router MC Operating Prerequisites
Router and IOS Prerequisites
Enabling SSH for Live Device Deployment
Providing the Correct CSV File Format for Multiple Device Import
Prerequisites for Successful Configuration of GRE
Prerequisites for Configuring a VPN Over Frame Relay
Prerequisites for Successful CA Enrollment
Prerequisites for CA Enrollment Using TFTP
Prerequisites for Working With Dynamically Addressed Devices
Router MC Operating Prerequisites
The following prerequisites must be met for successful configuration of VPNs and firewalls with Router MC:
•
Router and IOS Prerequisites
•Enabling SSH for Live Device Deployment
•Providing the Correct CSV File Format for Multiple Device Import
•Prerequisites for Successful Configuration of GRE
•Prerequisites for Configuring a VPN Over Frame Relay
•Prerequisites for Successful CA Enrollment
•Prerequisites for Working With Dynamically Addressed Devices
Router and IOS Prerequisites
To successfully configure routers with VPN and firewall configurations using Router MC, make sure that the IOS version supports the IPSec crypto, named access lists, and the IOS firewall feature set.
Enabling SSH for Live Device Deployment
Router MC uses SSH version 1 to connect to the live devices in your network. Router MC does not support SSH version 2. If SSH version 2 is enabled on a device, you will not be able to import the device into Router MC.
To check which SSH version is enabled on the device, type sh ip ssh at the command line. If version 2 is enabled, change to version 1 using the following command:
You must configure the following commands on your devices to facilitate the SSH connection:
1. (Mandatory) Set the domain name:
Router(config)#ip domain-name <domain name>
2. (Mandatory) Enable SSH and create keys:
Router(config)#crypto key generate rsa usage-keys
Note Make sure the key size is 1024 or above.
3. (Recommended) Configure AAA or local authentication.
Following is an example of AAA authentication:
Router(config)#aaa new-model
Router(config)#aaa authentication login stronglist group tacacs+ local enable
Router(config)#line vty line-number 4
Router(config-line)#login authentication stronglist
4. Configure the Tacacs server. This step is optional and depends on the authentication you configured in the previous step.
tacacs-server host <IP address> key <key>
An alternative option to configuring AAA is to configure local authentication. Replace steps 3 and 4 above with the following:
1. Define a local user on the device:
username <username> password 0 <password key>
2. Configure the following on the vty lines:
line vty 0 4
login local
See the following URL for more information about configuring AAA authentication:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/
fsecur_c/fsaaa/scfathen.htm#24444
Providing the Correct CSV File Format for Multiple Device Import
To import multiple devices into Router MC, you can import a file in Comma-Separated Values (CSV) format. See Importing Devices, page 1-12 for information about importing devices.
The format of the CSV file is significant. Device information must be entered in the order shown in this topic.
Note Router MC supports the format of files exported from RME 1.0 and 2.0.
The CSV format provides the following device information:
•Full device name or IP address (required)
•Read-only community string (required)
•Read-write community string (optional)
•Serial number (optional)
•User Field 1 (optional)
•User Field 2 (optional)
•User Field 3 (optional)
•User Field 4 (optional)
•Telnet password, enable password, enable secret, TACACS user, TACACS password, TACACS enable user, TACACS enable password, local user, local password, RCP user, and RCP password (optional)
The following is a sample CSV-formatted file.
; The following header line is mandatory - only the value of the
; source attribute can be modified (e.g. source = My Excel spreadsheet).
cisco Systems NM data import, source = Hand edit; Version = 2.0; Type = Csv
; Here are the columns of the table.
;Col# = 1; Name = Device name (include domain unless your stie has
; unqualified device names registered in the name services
; IP address in dotted decimal notation
;Col# = 2: Name = RO community string
;Col# = 3: Name = RW community string
;Col# = 4: Name = Serial Number
;Col# = 5: Name = User Field 1
;Col# = 6: Name = User Field 2
;Col# = 7: Name = User Field 3
;Col# = 8: Name = User Field 4
;Col# = 9; Name = Telnet password
;Col# = 10; Name = Enable password
;Col# = 11; Name = Enable secret
;Col# = 12; Name = Tacacs user
;Col# = 13; Name = Tacacs password
;Col# = 14; Name = Tacacs enable user
;Col# = 15; Name = Tacacs enable password
;Col# = 16; Name = Local user
;Col# = 17; Name = Local password
;Col# = 18; Name = Rcp user
;Col# = 19; Name = Rcp password; Comment = not used, leave blank
; Here are the rows of data.
bigrouter.yourcompany.com,public,private,,
dev-2501.yourcompany.com,"Not so, "" public as, thought",private,sn2501,
dev-2502.yourcompany.com,public,"private",sn2502,
dev-2503.yourcompany.com,public,private,sn2503,""
dev-2504.yourco.com,public,private,sn2504,us1,us2,us3,us4,tPass,ePass,eSecret,tUsr,tPass,t
eUsr,tePass,LUsr,LPass,rUsr,rPass
dev-2505.yourco.com,public,private,sn2505,usr1,,,usr4,,,esecret,,tUsr,tPass,,,LUsr,lPass
dev-2507.yourcompany.com,public,private,sn2507,
dev-2509.yourcompany.com,public,private,sn2509,
dev-2510.yourcompany.com,public,private,sn2510,
dev-2511.yourcompany.com,public,private,sn2511,
dev-2512.yourcompany.com,public,private,sn2512,
dev-2513.yourcompany.com,public,private,sn2513,
dev-2514.yourcompany.com,public,private,sn2514,
dev-2515.yourcompany.com,public,private,sn2515,
dev-2516.yourcompany.com,public,private,sn2516,
dev-4000.yourcompany.com,public,private,,Big Boys
dev-4500.yourcompany.com,public,private,,Big Boys
dev-7000.yourcompany.com,public,private,,Big Boys
dev-7010.yourcompany.com,public,private,,Big Boys
dev-2517.yourcompany.com,public,private,,,nm 25xx
dev-2518.yourcompany.com,public,private,,,mylabel2
dev-2520.yourcompany.com,public,private,,,mylabel2
dev-2521.yourcompany.com,public,private,,,mylabel2
dev-2522.yourcompany.com,public,private,,,mylabel2
dev-2523.yourcompany.com,public,private,,,mylabel2
dev-2524.yourcompany.com,public,private,,,mylabel2
dev-2525.yourcompany.com,public,private,,,mylabel2
dev-4700.yourcompany.com,public,private,,yourlabel1,,yourlabel3,yourlabel4
dev-7206.yourcompany.com,public,private,,
dev-7505.yourcompany.com,public,private,,,,,yourlabel4
dev-7507.yourcompany.com,public,private,,
dev-7513.yourcompany.com,public,private,,
dev-1200.yourcompany.com,public,private,,
dev-2900.yourcompany.com,public,private,,
Prerequisites for Successful Configuration of GRE
Consider the following prerequisites before using GRE in your network:
•To use GRE, you must identify the inside interfaces on your devices and specify these in the Router MC Settings configuration area. Inside interfaces are the physical interfaces on the device that connect the device with its internal subnets and networks.
•In Router MC, you must select a routing protocol, known as an Interior Gateway Protocol (IGP), whenever you enable GRE. The available routing protocols in Router MC are EIGRP and OSPF:
–Enhanced Interior Gateway Routing Protocol (EIGRP) allows the exchange of routing information within an autonomous system and addresses some of the more difficult issues associated with routing in large, heterogeneous networks. Compared to other protocols, EIGRP provides superior convergence properties and operating efficiency, and combines the advantages of several different protocols.
–Open Shortest Path First (OSPF) is a link-state, hierarchical protocol that features least-cost routing, multipath routing, and load balancing.
•In Router MC, you must specify an IGP process number. The IGP process number identifies the IGP process to which the inside interface on the device belongs. When GRE is implemented, this will be the secured IGP. For secure communication, the inside interfaces on the devices in your VPN must use the same IGP process. The IGP process number must be within the range specified in the application settings under the Admin tab. If you have an existing IGP process on the device that is within this range, but is different from the IGP process number specified in your GRE settings, Router MC will remove the existing IGP process. If the existing IGP process matches the one specified in your GRE settings, any networks included in the existing IGP process that do not match the specified inside interfaces, will be removed.
•If the inside interfaces on your devices are configured to use an IGP process other than the IGP process specified in your GRE settings (meaning that the interfaces belong to an unsecured IGP):
–For spokes: Manually remove the inside interfaces from the unsecured IGP through the device CLI before configuring GRE with Router MC.
–For hubs: If the hub inside interface is used as a network access point for Router MC, then on deployment, the interface will be published in both secured and unsecured IGPs. To ensure that the spoke peers use only the secured IGP, manually add the auto-summary command for the unsecured IGP or remove the unsecured IGP for that inside interface.
•In Router MC, you must provide a subnet that is unique yet it can be non-globally-routable for loopback. This subnet must only be used to support the implementation of loopback for GRE. The loopback interfaces are created, maintained, and used only by Router MC. You should not use them for any other purpose.
•If you are using static routes, not unsecured IGP, make sure you configure static routes on the spokes through to the hub inside interfaces.
•For 7100 and 7400 devices:
In general, it is recommended that Router MC has its own network access interface, separate from the inside interfaces on the device. However, if a device does not have interfaces that can be reserved for management only, and the external interface on the device is an Ethernet interface, Router MC can be connected to the network through an additional Ethernet hub that is attached to the hub's external Ethernet interface.
See Understanding Failover and Routing, page 1-2 for more information.
Prerequisites for Configuring a VPN Over Frame Relay
Consider the following prerequisites before configuring a VPN over a Frame Relay network with Router MC:
•Router MC supports a Frame Relay configuration in which a hub acts only as a VPN endpoint, while a spoke can act as both a VPN endpoint and a Frame Relay endpoint. There must be a device in the hub subnet that acts as the second Frame Relay endpoint and is positioned before the VPN endpoint at the hub.
•To ensure that the VPN connection is maintained and that all the required flows are secured in the tunnels, select one of the following options for Frame Relay subinterfaces:
–Provide each Frame Relay subinterface with a different IP address.
or
–Define a loopback interface on the device from which all Frame Relay subinterfaces will get their IP addresses.
or
–Ensure that the parent interface has a specified IP address so that if there is a problem with the subinterface IP addresses, GRE will be configured on the parent interface and no flows will be transmitted unsecured.
Prerequisites for Successful CA Enrollment
Consider the following prerequisites before using Certificate Authority (CA) authentication (for RSA Signature) in your network:
•The IKE authentication method used with CA can only be RSA Signature.
•The domain name must be defined on the devices for CA enrollment to be successful.
•To deploy CA policies to files (not to live devices), the following prerequisites must be met:
–Devices must have IOS 12.2(8)T or higher (trustpoint CA devices).
–CA authentication certificates must be provided by means of a manual cut and paste into the Router MC user interface (so that CA authentication is not interactive and does not require communication with the live device).
•To enroll with the CA server by means of a TFTP server, you must ensure that the CA certificates file is saved to the TFTP server. After deployment of the CA policy, you must copy the certificate request from your TFTP server to the CA server. See Prerequisites for CA Enrollment Using TFTP for more information.
•Router MC supports the Microsoft, Verisign and Entrust CAs. If you use the Microsoft CA, be sure to specify during installation that challenge passwords should not be requested.
•The clock settings on the CA machine and on the device must not differ by more than 24 hours, otherwise the CA enrollment will fail.
See Managing CA Enrollment, page 1-27 for more information.
Prerequisites for CA Enrollment Using TFTP
If you do not have constant direct access to the CA server, you can enroll using TFTP, as long as your devices use IOS 12.2(13)T or higher.
Saving the CA certificates on the TFTP server
To use the TFTP option provided by Router MC, you first must ensure that the CA certificates file is saved to the TFTP server. To do this, use the following procedure:
1. Connect to http://servername/certsrv, where servername is the name of the Windows 2000 web server on which the CA you want to access is located.
2. Select Retrieve the CA certificate or certificate revocation list, then click Next.
3. Select Base64 encoded, then click Download CA certificate.
4. Save the .crt file as a .ca file on the TFTP server using your browser's Save As function.
Transferring the certificate request from the TFTP server to the CA server
Router MC creates a PKCS#10 formatted enrollment request (.req) on the TFTP server. You must transfer it to the CA server using the following procedure:
1. Connect to http://servername/certsrv, where servername is the name of the Windows 2000 Web server where the CA you want to access is located.
2. Select Request a certificate, then click Next.
3. Select Advanced request, then click Next.
4. Select Submit a certificate request using a base64 encoded PKCS #10 file or a renewal request using a base64 encoded PKCS #7 file, then click Next.
5. Either select browse for a file (and browse to the TFTP server and select the .req file) OR open the just received by TFTP .req file with WordPad/Notepad and copy/paste the contents in the first window.
6. Export the .crt file from the CA and put it on the TFTP server.
7. Configure the 'crypto ca import <label> certificate' to import the device's certificates from the tftp server.
Prerequisites for Working With Dynamically Addressed Devices
Consider the following prerequisites before using Router MC to manage devices with dynamic IP addresses:
•Auto Update Server (AUS) must be installed in your system. AUS has a CNS Event Gateway feature that allows Router MC to manage IOS devices with dynamically assigned IP addresses. IOS devices contact AUS and provide their IP addresses and interface names. Then, Router MC polls AUS for this information, which it uses to contact the IOS devices and update IOS configurations. See the documentation for AUS on Cisco.com for information about installing and using AUS.
•Each dynamically addressed device must be manually configured to connect to the AUS event gateway. Configure the following commands on each device:
–cns config partial ip_address—Enables the config agent on the device so that AUS gets the connect and disconnect messages it needs.
ip_address—IP address of AUS.
–cns event ip-address [port-number] [keepalive seconds retry-count]
Configures the device to communicate with the event gateway.
ip_address—IP address of AUS.
port-number—Port number the device uses to subscribe to the correct events. Use the default, 11011 with no encryption.
seconds—Keepalive timeout. Default is 0.
retry-count—Number of retries. Default is 0.
–cns exec ip-address
ip_address—IP address of AUS.
Note This command is only required for devices with IOS 12.2(13)ZH and higher.
•In the Admin tab, in the AUS Settings page, you must provide AUS connection information to enable Router MC to communicate with AUS. See Defining Configuration Support Settings, page 1-3 for more information.
•When working with dynamically addressed spokes, you must define a group preshared key on the hub. See Creating Group Preshared Keys, page 1-23 for more information.
