| Oracle® Communications IP Service Activator Juniper M-series Device Support Guide Release 7.2 E47718-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications IP Service Activator Juniper M-series Device Support Guide Release 7.2 E47718-01 |
|
|
PDF · Mobi · ePub |
This chapter provides some basic information about JUNOS configuration files before describing how the Juniper M-series Device Driver (JDD) configures devices.
This section describes the JUNOS configuration files. It includes the following:
About the Configuration Hierarchy: describes the hierarchy of the JUNOS configuration files
About Configuration Groups: describes configuration groups and their hierarchy
About Active Configuration: describes how the JDD activates new configurations
There are two types of statement in a JUNOS configuration file:
Container statements: hold a collection of statements
Leaf statements: sit within a container statement
Container statements may be nested.
The container and leaf statements that are entered in the configuration file make up a configuration hierarchy. Most top-level statements are container statements that hold other container statements that form the tree branches. The leaf statements are the leaves of the hierarchy tree. Figure 3-1 shows the top-level statements in the Juniper configuration hierarchy.
Figure 3-1 Juniper Configuration Hierarchy
Within the configuration file, statements are indented to show their relative position in the hierarchy. For example:
firewall {
family inet {
filter InFilter--at-0-0-0-1 {
term OrchFilterTerm--4688 {
from {
precedence flash-override;
source-address 150.150.150.0/24;
destination-address 10.50.0.7/32;
}
then {
accept;
}
}
}
}
}
An individual hierarchy of statements, starting at the base of the hierarchy, is referred to as a statement path. For example, the statement path for the above example is expressed as [edit firewall].
Statements within the JUNOS configuration file may be collected in a named group that can be applied to the rest of the configuration. Any number of groups may be defined. A group, or selected sections of the group, can be applied to different sections of the configuration file.
Configuration groups are defined at the top level of the configuration hierarchy. Within each group, the same configuration hierarchy exists as at the top level. This is shown in Figure 3-2.
Figure 3-2 Configuration Groups and Configuration Hierarchy
The Juniper M-series Device Driver uses the configuration groups feature to aid separation of Oracle Communications IP Service Activator-generated configuration. Any configuration that is placed on the device is defined within the orchestream configuration group. The following example shows the opening lines of the group definition:
groups {
orchestream {
interfaces {
at-1/0/0 {
…
This group is then applied to the main configuration by the apply-groups command.
Note:
When configuring an MPLS VPN, if the IP address specified for an interface through IP Service Activator differs from the currently-configured values on the device, IP Service Activator changes the address within the main configuration. The change is commented. This change is made in the main configuration because any interface addresses defined in the orchestream group are merged with those in the main configuration.JUNOS holds ten versions of the configuration file, one of which is the currently running configuration. In Juniper terminology, this is the active configuration. This configuration may be edited to produce a new configuration which is referred to as the candidate configuration.
When a JUNOS commit command is run, the candidate configuration becomes the active configuration file 0). The active configuration becomes the first backup (configuration file 1), and so on.
The Juniper M-series Device Driver uses the commit command when pushing new configuration to the device.
If the device driver is configured for no commit, it uses commit confirm and if successful, it saves the configuration on the device with the name orchestream_new_config.txt. You may then apply this configuration manually if you choose.
If the driver is configured for normal operation, it uses commit confirmed 1. In this case, device commits the configuration and then waits for the Juniper Device Driver to send a Y one second later. If the device does not receive the Y response, it assumes that connectivity to the management station has been lost and rolls back the configuration. This is very useful to ensure that you are not locked out of the device by an errant configuration.
The Juniper M-series Device Driver accesses devices by the command-line interface (CLI). Access is authenticated by Tacacs+, Telnet (Named User), or SSH/RSA with password authentication. You must ensure that the authentication methods are correctly set up for all Juniper devices in your network. You can set the authentication on the Security page in the Discovery dialog box to ensure that it applies to all devices, or set it for individual devices.
Note:
The user specified on the Security page must have the appropriate privilege level on each PE device to be managed. For more information, see "Configuring User Access Privileges".The Juniper M-series Device Driver requires SNMP to be enabled on devices for the IP Service Activator discovery process to work and so that the capabilities of Juniper routers can be obtained. Ensure that SNMP is set up correctly. For more information, see "Configuring SNMP".
To support SSH with password authentication on Juniper M-series devices, configure the SSH authentication keys when the new IP Service Activator build is installed.
To configure the SSH authentication keys:
Enable SSH service on the devices.
On the IP Service Activator installation machine, ensure that the directory ipsaadmin_home_directory/.ssh is empty. The default ipsaadmin_home_directory directory is /export/home/ipsaadmin.
Generate a new key pair using the key generator located in the Service_Activator_Install/ssh/bin directory (typically opt/OracleCommunications/ServiceActivator/ssh/bin) using the following command:
ssh-keygen -f id_rsa -t rsa -b 1024
When prompted for a key password by the key generator, leave the passphrase blank.
Two files are generated:
id_rsa
id_rsa.pub
Copy id_rsa and id_rsa.pub to ipsaadmin_home_directory/.ssh.
Set the protections of the files using the following command:
chmod 600 id_*
When setting the security preferences for the device/domain, select SSH with password authentication and enter the valid username and password for the router.
Note:
The keyed authentication option is not supported.The features supported on each device are dependent on the hardware and software combination and are indicated by a list of capabilities returned from each device. You should always check capabilities before configuring network devices. The Juniper M-series Device Driver does not need correct security settings in order to obtain capabilities.
The Juniper device driver uses SNMP to retrieve the device capabilities.
Capabilities are obtained at two levels:
At device level, the capabilities specify the device's support for SLA measurement techniques, Transparent LAN Services and VLANs. These features are not currently supported by IP Service Activator on Juniper M-series or T-series devices
At interface, sub-interface (unit) and VC endpoint level, the capabilities indicate the QoS, MPLS, and Layer 2 Martini VPN features that can be configured on that interface
The device driver attempts to obtain the capabilities automatically at the end of the discovery process. If this fails you can initiate the process to fetch capabilities manually.
If IP Service Activator is unable to discover capabilities during the discovery process then you can request the capabilities at a later point.
In addition, if the device capabilities have changed, for example, as a result of an operating system upgrade, you can reset and re-fetch capabilities after ensuring the device is unmanaged.
Note:
The provisioning and configuration features supported by IP Service Activator require the Internet Processor II ASIC. The Juniper M-series Device Driver is optimized to correctly report capabilities from Juniper devices with this version of the ASIC. With earlier ASIC versions, support for rate limiting and access rules is incorrectly reported.There may be inconsistencies discovering pre-configured DLCIs, VLANs and VCs. See "Working with Pre-existing VLAN, DLCI, and VC Endpoints" for details.
For more details on the discovery process, see IP Service Activator User's Guide.
The M-series device driver maintains a virtual version of the device state, consisting of the rules, PHB groups, and so on that have been defined in the IP Service Activator-generated configuration group. The device maintains the real state in the active configuration.
When configuration is pushed to the device, the Juniper device driver performs the following steps:
The driver logs into the device and obtains the current configuration.
The driver enters configuration mode by running the edit exclusive command.
If another entity is editing the configuration, no new IP Service Activator configuration is installed on the device. An error message is logged and displayed in the IP Service Activator client.
If no entities are editing the configuration, the driver edits the candidate configuration. The configuration file is locked to all other entities. When configuration is complete, the commit check command is run and JUNOS verifies the candidate configuration:
If the command succeeds, the candidate configuration is made active by sending a commit command.
If JUNOS finds an error, an error is raised against the device. No new IP Service Activator configuration is installed. The device driver saves the failed configuration to a file named last_failed_orchestream_config on the Juniper device. This log file contains details about the error and can be reloaded in order to diagnose and correct the problem.
You can set the maximum limit for routing instance annotation. Issues that are related to long routing instance descriptions on Juniper routers can cause configuration problems. To avoid this, you can set the AnnotationLineLimit using either the command line option or component parameters.
To set AnnotationLineLimit using the command line:
Enter the following command:
-AnnotationLineLimit n
where n is an integer. Setting n to -1 retains the default behavior and the annotation line is not split. Setting n to 0, removes the annotation line. Setting n to a number greater than 0 splits the annotation line at n characters.
For example, if the annotation line has 40 characters, and the annotation line limit is set to 20, the annotation line is split into two lines.
In the following example, the annotation line is a maximum of 20 characters, including "/*" and "*/".
Input String: S2 + S3 + S1
Output Annotate Line:
/* S2 + */
/* S3 */
/* + S1 */
The command line option is -AnnotationLineLimit 40
To set AnnotationLineLimit using the component parameters:
Use the following component parameter:
ComponentParameters -ComponentName juniper-shmitra-ca -set -AnnotationLineLimit n.
where n is an integer. Setting n to -1 retains the default behavior and the annotation line is not split. Setting n to 0, removes the annotation line. Setting n to a number greater than 0 splits the annotation line at n characters.
A check and force consistency process ensures that the configuration of each device always matches the virtual device state. A device may lose its configuration if it goes down. The process works as follows:
The proxy agent regularly polls the UpTime MIB objects which represent the devices that the driver controls. If it finds that the device was down (that is, it has re-booted since the last time it was checked), the proxy agent tells the driver to check the consistency of the device configuration.
The driver initiates the sequence outlined in "Applying IP Service Activator Configuration".
When Routing Engine redundancy is implemented, the configuration pushed to the device by IP Service Activator will only be updated on the Master Routing Engine. The Backup Routing Engine will not be updated with the configuration. As a result, the Backup Routing Engine will not be correct if there is a need to switch over to this engine.
A script is available which maintains synchronization between the command caches of both engines. This script will issue a commit synchronize command to update the Backup Routing Engine and synchronize with the Master Routing Engine after every successful configuration change.
The script file can be found at the following location:
/opt/OracleCommunications/Service Activator/DriverScripts/juniper/CommitSynchronize.py
See the IP Service Activator online Help for information on how to import a driver script file.
Issues related to commit timing on Juniper routers cause configuration rollback. To address this problem, Juniper Device Driver has been enhanced so that the user can set the commit confirm time and commit delay time through the command line option or component parameters CommitConfirmTime and CommitDelayTime.
The unit for CommitConfirmTime is minute and the unit for CommitDelayTime is second.
To set commit confirm time and commit delay time using the command line:
Enter the following commands:
-CommitConfirmTime n -CommitDelayTime m
where n and m are integers.
For example, the following commands set the commit confirm time to five minutes and the commit delay time to three seconds:
-CommitConfirmTime 5 -CommitDelayTime 3
To set commit confirm time and commit delay time using the component parameters:
Use the following component parameters:
ComponentParameters -ComponentName juniper-Marina-ca -set -CommitConfirmTime n
ComponentParameters -ComponentName juniper-Marina-ca -set -CommitDelayTime m
where n and m are integers.
The Juniper python script Commit Synchronize Juniper Driver Script has also been enhanced so that the user can set the synchronizing delay time.
The unit for COMMIT_SYNC_DELAY . COMMIT_SYNC_DELAY is second.
To set the synchronizing delay time in the python script:
Replace 0 as the value for COMMIT_SYNC_DELAY in the following install section of the python script with the desired delay time:
commit synchronize:
COMMIT_SYNC_DELAY = 0
try :
_device.openSession()
_device.deliverCommand('configure')
time.sleep(COMMIT_SYNC_DELAY)
_device.deliverCommand('commit synchronize')
_device.deliverCommand('exit')
_device.closeSession()
except :
_result.setCode(_result.FAILED)
_result.setDetails('Failed to issue command: commit synchronize')
else :
_result.setCode(_result.OK)
_result.setDetails ('Succeeded to issue command: commit synchronize')
You can save the configuration output from the device driver to a file instead of a device. The following options are available:
Output the orchestream configuration group to a file named device-ip-address, local to the Juniper device driver. Output is in XML format, with the output configuration enclosed by markup tags.
Output the orchestream configuration group to a file named orchestream-config-devicename-time-date-.txt, local to the Juniper device driver. The output file includes a replace: tag, enabling you to load the file's configuration group into the active configuration.
Output the orchestream configuration group to a file named orchestream_new_config.txt in the user's home directory on the device.
Disable communication with the device through the CLI and SNMP when outputting configuration to the orchestream-config-devicename-time-date.txt file.
Oracle recommends that you use file output only if it is necessary for your environment.
To implement offline configuration:
In the cman.cfg file, insert the following options in the juniper entry:
- FileConfigDelivery - FileConfigDeliveryDir /opt/OracleCommunications/ServiceActivator/WorkingData - NoDeviceComm
Restart the component manager with the following command:
(ipsacm start)
Run device discovery and manage your device(s).
Create provisioning data and commit a transaction.
For each subsequent committed transaction that would otherwise write directly to the device, a ready-to-load file is created in /opt/OracleCommunications/ServiceActivator/WorkingData directory with the following file name format:
Orchestream_config_DeviceName_time_date.txt
Table 3-1 summarizes the command-line parameters are used to control offline configuration. They must be used together for off-line configuration to work.
Table 3-1 Offline Configuration Command Line Parameters
| Parameter Name | Type | Purpose |
|---|---|---|
|
-FileConfigDelivery |
Flag |
Specifies that configuration will not be pushed onto the device. |
|
-FileConfigDeliveryDir |
String |
Specifies the folder where the files to which configuration will be written are located. |
|
-NoDeviceComm |
Flag |
Specifies that the device will not be contacted to perform show run or show vers commands or SNMP polls. |
|
-EnableFtp |
Flag |
Specifies that the Juniper Device Driver will use FTP instead of Telnet to configure the device. |
The following sections give more details about each parameter.
When you specify the -FileConfigDelivery flag, you prevent the driver from entering configure mode on the device and applying changes to the FileInterface file. Instead, a file named orchestream-config-device_name-time-date.txt is created in a directory specified by -FileConfigDeliveryDir. You must use the -NoDeviceComm flag in conjunction with these flags, and restart the component manager to make the flags effective.
The file created contains the replacement orchestream configuration group with a replace: flag appearing just before the group and interface statements. Once the file is created, load it.
To load the orchestream-config-device_name-time-date.txt file:
Run the JUNOS load replace command.
For example:
[edit] user@host# load replace orchestream-config-zeus-14.58.17-2001-10-04.txt
This overwrites the existing orchestream configuration group with the file's content without affecting any other areas of the router configuration.
Ensure that the apply-groups orchestream statement still exists in the router configuration.
Apply the apply-groups orchestream statement with the following command:
[edit] user@host# set apply-groups orchestream [edit]
Note:
IP address changes that may be required when configuring MPLS VPNs must be applied to the main router configuration and not in the orchestream configuration group.When you specify the -NoDeviceComm flag, both CLI and SNMP connections are disabled, preventing the device driver connecting to the device. If the capabilities of the device are unknown, an over-estimation of the capabilities is performed. SNMP requests are still allowed to be performed by the rest of the system. When you use this flag with -FileConfigDelivery, a good estimation of the configuration changes required are written to the local file. See the example above or "About Active Configuration" for more details.
By default, the Juniper Device Driver uses Telnet to configure the router. However, when you specify the -EnableFtp flag in cman.cfg (Juniper command line), the device driver uses an FTP session to configure the device.
The default configuration is as follows:
juniper-coenglv0219.us.oracle.com.proxy_device_driver@coenglv0219.us.oracle.com[7.0.0.0.0.572]: $-EnableFtp=disabled
To enable FTP mode using Component Parameters:
Enter the following command:
orchadm-bash3.2:$ ./ComponentParameters -ComponentLocation coenglv0219.us.oracle.com -ComponentName juniper-coenglv0219.us.oracle.com -set -EnableFtp enabled
To verify the current value of EnableFtp:
Enter the following command:
juniper-coenglv0219.us.oracle.com.proxy_device_driver@coenglv0219.us.oracle.com[7.0.0.0.0.572]: $-EnableFtp=enabled
To disable FTP mode using Component Parameters:
Enter the following command:
orchadm-bash3.2:$ ./ComponentParameters -ComponentLocation coenglv0219.us.oracle.com -ComponentName juniper-coenglv0219.us.oracle.com -set -EnableFtp disabled
The following are important things to note for configuration:
Changing any of the offline configuration parameters while a device is managed can cause commit failure errors.
The value set in the Manual config field on the Domain and Device property pages, including Warn and Delete, is ignored for Juniper M-series devices. The Juniper M-series Device Driver cannot be set up to monitor for or warn when changes to device configuration are made by other users. However, IP Service Activator can co-exist with manually applied configuration.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|