-
Cisco 12000 Manager Release 2.2
- Reelase Notes for Cisco 12000/10720 Router Manager 2.2
- Cisco 12000/10720 Router Manager Installation and Configuration Guide, 2.2
-
Cisco 12000/10720 Router Manager User's Guide, 2.2
-
About This Guide
-
C12kM Overview
-
C12kM Concepts
-
Getting Started
-
Chassis Management
-
Managing Modules
-
Managing Interfaces
-
Interface Profiles
-
Interface Configuration
-
Interface Status
-
Interface Performance
-
Layer 3 QoS
-
Managing ATM Connections
-
VLAN Management
-
Fault Management
-
Change Management
-
Performance Management and Historical Data
-
SONET/SDH COnversion Chart
-
Table Of Contents
Cisco 12000 Series Internet Router Chassis
Physical Interfaces and Technologies
Concepts
This chapter describes Cisco 12000 Manager (C12kM) concepts and covers the following information:
C12kM Objects and Interfaces
C12kM manages both physical and logical objects, as follows:
•
Physical—Represents tangible components and devices such as the chassis (hardware frame), line cards, and interfaces
•
Fault, Configuration, Accounting, Performance, and Security (FCAPS) windows are accessible on both physical and logical C12kM objects, in the form of FCAPS menu options that appear when you right-click on any object in C12kM. FCAPS functionality provides a complete management interface to features of the Cisco 12000 series internet router.
This section covers the following areas:
•
•
Physical Objects
Table 2-1 lists all physical objects created in C12kM and the management functions that can be performed on each object.
Table 2-1 Physical Objects and Management Functions
Shelf—This object represents the physical shelf that holds the chassis.
No management can be performed on a shelf.
Chassis—The hardware frame of the Cisco 12000 series internet router, which houses all subchassis objects (modules).
Command Log
Configuration
Configuration Backup/Restore
Configuration Editor
Fault Management
Initiate Telnet Service
Inventory
IOS Image Download
Launch Web Console
Management Information
SNMP Management
System Log
APS Status
RPR Configuration
RPR StatusGRP (Gigabit Route Processor)—There can be up to two GRPs in a chassis. The primary GRP is the CPU or "brains" of the Cisco 12000 series internet router. The secondary GRP is redundant.
Configuration
Fault Management
Inventory
PerformanceLine Cards—There are various types of line cards within a chassis (for example, ATM, Ethernet, SRP, POS, E3 and DS3). Each of these line cards holds a given number of physical interfaces (ports).
Configuration
Fault Management
InventoryPhysical Interfaces—Each line card has at least one, if not multiple, physical interfaces (ports). The type of physical interface is equivalent to the type of line card the interface resides on. Each physical interface can support multiple technologies (for details, refer to "Physical Interfaces and Technologies" section) The line card type determines what specific technologies are supported by an interface.
Profile
Configuration
Fault Management
Performance
StatusSupporting Modules—Additional subchassis cards and modules: the switch fabric card (SFC), clock scheduler card (CSC), AC or DC power supply module, blower module, and fan tray module.
Configuration
Fault Management
Inventory
The physical objects and interfaces displayed in Table 2-1 are traced as follows:
•
•
•
Refer to the "Views" section for further details on hierarchies within Cisco EMF and C12kM.
Tip
Cisco 12000 Series Internet Router Chassis
The C12kM application supports seven Cisco 12000 series internet router models: the Cisco 12008, Cisco 12012, Cisco 12016, Cisco 12404, Cisco 12406, Cisco 12410, and Cisco 12416.
Figure 2-1 displays a Cisco 12016 internet router chassis as an example, and identifies the modules and sub-modules that you would find:
Figure 2-1 Cisco 12016 Chassis
The Cisco 12016 chassis supports the following components:
•
•
•
•
–
–
–
•
–
–
•
–
–
–
Supporting Modules
C12kM supports five types of supporting modules within a Cisco 12000 series internet router chassis. Some modules only apply to certain chassis types.
•
•
•
•
•
Note
Line Cards
C12kM supports the following line card types:
•
•
•
•
•
•
•
The interfaces on each line card are named according to the lowest supported protocol layer, for example, interfaces on an ATM line card in slot 2 are named: SONET-2-0, SONET-2-1, and interfaces on a POS card in slot 3 would have names SONET-3-0, SONET-3-1. Manual deployment is supported for all the linecards except the SRP linecard.
Physical Interfaces and Technologies
Physical interfaces are modeled as objects below the parent line card. Some generic properties are supported by all the interfaces. As mentioned before, the type of line card characterizes the type of physical interface; for example, an ATM line card will only support ATM interfaces. However, there can be multiple technologies supported on that physical interface. For example, ATM physical interfaces can support the following:
•
•
•
Note
Tip
Table 2-2 outlines each physical interface and the technologies it supports. Also included are the different FCAPS-based windows that are applicable to each physical interface and technology. For example, if you want to configure an ATM interface, look in the table under ATM, and you will notice that four technologies apply: Generic, ATM, SONET, and IP. This means that you should open the configuration windows for these four technologies and configure the fields within, in order to completely configure an ATM interface.
Logical Objects
C12kM supports three logical object types:
•
•
•
Table 2-3 describes the management functions for Layer 3 QoS logical objects.
Table 2-4 describes the management functions for ATM logical objects.
Table 2-5 describes the management functions for VLAN objects.
Views
C12kM views can be accessed by clicking on the Viewer icon in the Cisco EMF launchpad. These views appear in the frame at the left of the window when you open the Map Viewer window (see Figure 2-2).
C12kM views model hierarchical relationships between objects, both physical and logical. Objects are organized into different views and can exist in multiple views simultaneously by reference. Each object can have a number of parent and child objects. You can access C12kM objects by navigating through one of the views to find the object. You can navigate through views by expanding text. Click on the + sign next to any object to expand text. A - sign next to an object indicates there is no more text to expand. Each view represents a different way of containing and grouping objects.
C12kM adds specific views to the standard views supplied by Cisco EMF. The standard Cisco EMF views are the Physical and Network views (for further information on these views, refer to the Cisco Element Management Framework User Guide Release 3.2 (78-12536-01)).
The number in parenthesis next to a view indicates how many top-level objects are contained within the view.
The Views section covers the following areas:
Component Managed View
The Component Managed view displays all objects within the Cisco EMF system. For example, say you have two types of element management applications installed in Cisco EMF: Cisco Digital Subscriber Line Manager (CDM) and the C12kM application. Information for both CDM and C12kM is displayed within the Component Managed view.
The Component Managed view and Physical view have the same basic hierarchy structure, as shown in Figure 2-2.
Figure 2-2 Hierarchy of Component Managed and Physical Views
Layer 3 QoS View
The Layer 3 QoS view displays only Layer 3 QoS objects within C12kM, such as the following:
•
•
•
You can work within this view to create and configure Access Lists or CAR or WRED objects by accessing the respective C12kM menus.
Network View
This view displays all network devices within their relevant networks and subnets. The auto-discovery system of Cisco EMF uses this view to calculate which devices have already been added to the system, so that it does not try to discover the same device multiple times. For details on auto-discovery, refer to "IP Auto Discovery of the Cisco Chassis" section.
Physical View
Objects in the Physical view are ordered according to their relative physical location. The relationships defined in this view are physical containment relationships, meaning that each object is defined according to which object it is contained within. For example: a shelf is located under a site; a chassis is contained under a shelf; and GRPs, line cards, and supporting modules are contained within a chassis.
Refer to Figure 2-2 for an overview of the structure of the Physical view.
VLAN View
The VLAN view displays the VLAN objects in C12kM. The VLAN view can contain one or more domains. A domain is a user-defined grouping of the VLAN objects. This grouping may be done on a customer name basis, on logical groupings like 'Accounting Vlans' or it could be any other user maintained VLAN grouping. There can be mulitple domains in the VLAN view and each domain can contain mulitple VLAN objects. The same VLAN id can be duplicated across different domains. Each VLAN object can have multiple sub-interface objects.
Note
C12kM Object States
C12kM object states reflect the life cycle of an object. Whatever stage the object is in at any given time is reflected in the state type. The state of an object can change frequently, depending upon what actions are being performed on the object. All objects in C12kM have a state assigned to them which appears at the bottom left corner of each FCAPS window for a selected object (see Figure 2-3).
Figure 2-3 C12kM Object States
The two most common object states are Normal and Decommissioned. For example, when you deploy a line card in C12kM, the initial state of the line card is decommissioned. You can then commission the line card to begin active management (for details on how to commission a module, refer to the "Commissioning a Selected Module" section). When you commission the line card, it passes through two transitory states: discovery, then commissioning. The commissioning process determines which state to move the object into (typically Normal). This example reflects the basic process of deploying and commissioning an object.
Certain states ripple down to any objects below. For example, if you decommission a chassis, all subchassis objects are also decommissioned. If you enable performance logging on a line card, all interfaces on the line card are also transitioned to performance logging.
By default, FCAPS windows refresh at a rate dependent upon the type of window. For example, inventory windows are refreshed at a lower rate than performance windows. The average refresh rate is every 30 seconds.
The following sections describe the possible states that an object may be in and provides a description of these states.
Normal State
The normal state indicates that an object is operational. When any physical object enters the normal state, C12kM performs heartbeat polling on the object every 5 minutes to determine whether it is present or not and to determine the current state of the object.
Decommissioned State
The decommissioned state indicates that an object is not managed. When you manually deploy an object, it is normally placed into a decommissioned state.
Tip
The following actions occur on a decommissioned object:
•
•
Decommission buttons are located in Chassis, Module, Interface and VLAN Configuration windows. When you decommission an object, any children of that object also change their state to decommissioned. For example, if you decommission a chassis, all objects within that chassis (GRP card, line cards, interfaces, connections) are also decommissioned. If you decommission a line card, all interfaces and connections on that line card are decommissioned, and so on.
Errored
If the operational status of a module goes down, it moves into the errored state. In the errored state, performance polling (if activated) is stopped; however, heartbeat polling (which polls an object every 5 minutes to verify its existence and current state) continues, until the device responds positively to a heartbeat request. When the module is contactable again, it responds positively to heartbeat requests, and then moves back into the previously held state.
Performance Logging On
Enabling performance logging on an object in the Normal state moves the object into the performance logging on state. This means that performance data is collected on the object and can be viewed in the Performance windows or the Performance Manager windows. Performance logging collects data only for GRPs, interfaces and VLAN sub-interfaces. You can enable performance logging on a global scale or on an individual object basis. Enabling global performance logging puts all subchassis objects into a performance logging on state. However, remember that only GRPs and interfaces actually collect performance data. (For more information on global performance logging, refer to the "Starting Global Performance Logging" section.
Performance logging occurs every 15 minutes. This means that when you enable performance logging or global performance logging initially on an object, it takes 15 minutes for the data to be collected and displayed in C12kM performance menus.
Heartbeat polling is performed on an object in the performance logging on state. If the object moves into the errored state, it is returned to the performance logging on state when the error is rectified. For example, if a line card is in the performance logging on state and it goes down, it moves into the errored state. When heartbeat polling finds that the line card is back up, it restores the line card to the performance logging on state.
Lost Comms
The lost comms (lost communications) state indicates that the object is not contactable. C12kM can apply this state to a chassis, module, or interface. During this state, heartbeat polling is performed on the object. When the object becomes contactable again, it moves out of the lost comms state. For example, say an ATM line card in C12kM was predeployed. When you perform device synchronization (commissioning a chassis), the ATM line card is not yet physically present in the hardware. In this situation, C12kM places the ATM line card into a lost comms state, where it continues to poll for the presence of the line card. When the ATM line card is inserted into the chassis, C12kM detects its presence and moves the line card out of the lost comms state and into its respective state (typically normal).
Lost Comms Poll
A C12kM object in the lost comms poll state signifies that the EM is polling the object even though the object has lost communication with the device. This state machine state is meant for all the interfaces. When C12kM loses connectivity with the device or a module is removed from the chassis then, all or specific interfaces move into the lost comms poll state.
Lost Comms No Poll
The lost comms (lost communications) no poll state occurs when the Cisco 12000 series internet router cannot be contacted. When C12kM loses connectivity with a device, the representative chassis object remains in the lost comms state, so that heartbeat polling continues on the chassis. However, all modules and interfaces within that chassis move into a lost comms no poll state. There is no point in polling modules and interfaces within a device that is not contactable. If the connection with the device is down, all modules and interfaces will be down. When the device becomes contactable again, the chassis is moved out of lost comms state and the modules and interfaces are moved out of the lost comms no poll state.
Discovery Lost Comms
The discovery lost comms state is quite similar to the lost comms no poll state; however, this state only occurs during subchassis discovery. For example, if you commission a chassis (which begins the process of subchassis discovery), and if a pre-deployed line card is not present then, the line card is moved into the discovery lost comms state. When the linecard is re-inserted in the device, subchassis discovery is resumed, and the object moves out of the discovery lost comms state.
Mismatched
The mismatched state occurs when a mismatch is found between what is in the hardware and what is deployed in C12kM. For example, say you are expecting an ATM OC-3 line card. So you predeploy and perform offline configuration in C12kM to prepare for that type of line card. Now, when the line card becomes available and is placed into the chassis, it is not an ATM OC-3 line card, but a POS OC-3 line card. So when C12kM detects the new line card, it finds a mismatch. The line card gets placed into the mismatch state, and a major alarm is raised against the line card.
To rectify a mismatch problem, first you must assess the source of the problem. If the operator was at fault and predeployed an incorrect line card, the operator should delete the predeployed line card and predeploy the correct line card. If the person who inserted the line card is at fault and they inserted the wrong type of line card into the chassis, the line card should be removed. When you remove a line card, C12kM moves the line card into a lost comms state. Insert the correct line card. C12kM finds the new line card and downloads the correct pre-deployment and offline configuration information, then places the line card into its respective state (typically normal).
Mismatch can also occur on a chassis. If, during predeployment of a chassis, an incorrect IP address is entered, this problem will be discovered by C12kM. The chassis predeployment can be performed normally; however, when the chassis is physically present, and the commissioning process is initiated, starting subchassis discovery, C12kM realizes the mismatch. A major alarm is raised against the chassis. To rectify this problem, you can either delete the predeployed chassis and deploy the correct one, or fix the IP address by re-entering the correct one in the chassis Management Information window.
Transient Object States
Certain states in C12kM are temporary or transient, that is, they exist only for a short time while a process is being performed. The following states are transient:
•
•
•
•
•
•
