Table Of Contents
Pseudowire Emulation Edge-to-Edge MIBs for Ethernet and Frame Relay Services
The Pseudowire Emulation Edge-to-Edge (PWE3) MIBs for Ethernet and Frame Relay Services provide Simple Network Management Protocol (SNMP) support within an Any Transport over Multiprotocol Label Switching (AToM) infrastructure emulating Ethernet and Frame Relay services over packet switched networks (PSNs). The PWE3 MIBs include the CISCO-IETF-PW-MIB (PW-MIB), the CISCO-IETF-PW-MPLS-MIB (PW-MPLS-MIB), the CISCO-IETF-PW-ENET-MIB (PW-ENET-MIB), and the CISCO-IETF-PW-FR-MIB (PW-FR-MIB).
This release introduces support for the CISCO-IETF-PW-FR-MIB (PW-FR-MIB), which provides network management information specific to a Frame Relay over pseudowire (FRoPW) connection in an MPLS AToM or an IP network.
Feature History for the PWE3 MIBs
This feature was introduced.
The title was modified to include Frame Relay as a transport.
Support was added for the Cisco 12000 Series Routers and for the CISCO-IETF-PW-FR-MIB (PW-FR-MIB).
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Prerequisites for the PWE3 MIBs
•SNMP must be enabled on the label switch routers (LSRs).
•MPLS must be enabled on the LSRs.
•Pseudowires must be configured with Ethernet or Frame Relay access circuits. (For more detailed information, see the Any Transport over MPLS feature module or the Cisco IOS Wide-Area Networking Configuration Guide, Release 12.3.)
Restrictions for the PWE3 MIBs
This implementation of the PWE3 MIBs is limited to read-only (RO) permission for MIB objects except for the cpwVcUp and cpwVcDown notification enable object, cpwVcUpDownNotifEnable, which, for purposes of this release, has been extended to be writable by the SNMP agent.
•The following tables in the PW-MIB are not supported in this release:
•The following objects in the PW-MPLS-MIB are not supported in this release:
•The following tables in the PW-ENET-MIB are not supported in this release:
•The following table in the PW-FR-MIB is not supported in this release:
Information About the PWE3 MIBs
To configure the PWE3 MIBs, you need to understand the following concepts:
What is a Pseudowire
A pseudowire is a point-to-point connection between pairs of provider edge (PE) routers (Figure 1). Its primary function is to emulate services like Ethernet over an underlying core MPLS network through encapsulation into a common MPLS format. By encapsulating services into a common MPLS format, a pseudowire allows carriers to converge their services to an MPLS network.
Figure 1 Sample Pseudowire Topology
PWE3 MIBs Architecture
The PWE3 MIBs architecture shown in Figure 2 categorizes three groups of MIBs that when used together, provide a complete picture of the emulated service; the native transport, which carries the service across the core network; and the relationship between the two.
Figure 2 PWE3 MIBs Architecture
The architecture is modular in nature, in that once deployed, new emulated service MIB modules or additional transport MIB modules simply "plug in" to or extend the existing infrastructure rather than require a new and unique one. This allows you to build management applications without the concern of a new service requiring the deployment of a completely new management strategy. Because the architecture is a generalized association mechanism between existing service and transport MIB modules, it should be noted that the native MIB modules work in the absence of the associated PWE3-specific MIBs. The advantage is that if a PWE3-specific MIB has not yet been deployed in Cisco IOS software, which associates a service or transport with pseudowires, these MIB modules can still be queried. However, the only drawback is that the associations with the pseudowires are absent. For example, although the Asynchronous Transfer Mode (CISCO-IETF-PW-ATM) MIB is not available in this implementation, you may still see entries in the corresponding native service MIB modules such as the ATM Forum and Cisco proprietary ATM MIB modules.
When the corresponding PWE3-specific MIB modules are implemented in the future, you will be able to see those pseudowire associations at that time.
Components and Functions
The PWE3 MIBs have the following components and functions:
•PW-MIB (the pseudowire MIB)
This MIB binds the PW-MPLS-MIB and the PW-ENET-MIB together, and provides status of the pseudowire emulation by using counters for monitoring and configuration of services, statistics, and notifications by using the SNMP protocol.
•PW-MPLS-MIB (the pseudowire MPLS-MIB)
This MIB provides managed objects that can be used by a network manager to monitor pseudowire emulation MPLS services, such as MPLS-Traffic Engineering (TE)-PSN and MPLS-non-TE-PSN, by using the SNMP protocol.
•PW-ENET-MIB (the pseudowire Ethernet services MIB)
This MIB provides managed objects that can be used by a network manager to monitor pseudowire emulation Ethernet services by using the SNMP protocol.
•PW-FR-MIB (the pseudowire Frame Relay services MIB)
This MIB provides managed objects that can be used by a network manager to monitor pseudowire emulation Frame Relay services by using the SNMP protocol.
This MIB uses an FRoPW connection that consists of two segments: the Frame Relay segment and the pseudowire segment. The PW-FR-MIB provides hooks to those segments. The PW MIB contains information about the pseudowire segment, and the PW-FR-MIB contains information about the Frame Relay segment.
The PW-FR-MIB is defined at the Pseudowire Service Emulation Layer and resides on top of the generic PW-MIB (Figure 2). Therefore, the PW-FR-MIB is highly dependent on the existence and the service provided by the PW-MIB. In addition, an existing PW-FR connection entry must associate with an existing virtual circuit (VC) entry in the PW-MIB.
The PW-FR-MIB and the generic PW-MIB are logically tied by the PW VC Index, which is an internal index defined to support the PW-MIB. Currently, each PW VC index uniquely maps into an existing VC entry in the PW-MIB and the PW-FR-MIB.
MIB Tables in the PW-MIB
The PW-MIB consists of the following tables:
•cpwVcTable (Table 1)—Contains high-level generic parameters related to virtual circuit (VC) creation. This table is implemented as read only and is indexed by the cpwVcIndex, which uniquely identifies a singular connection. A row in this table represents an emulated virtual connection. This table is used for all VC types.
•cpwVcPerfTotalTable (Table 2)—Provides per-VC performance information from the VC start time. This table is indexed by the cpwVcIndex.
•cpwVcIdMappingTable (Table 3)—Provides reverse mapping of the existing VCs based on VC type and VC ID ordering. This table is typically useful for element manager software (EMS) ordered query of existing VCs. This table is indexed by cpwVcIdMappingVcType, cpwVcIdMappingVcID, cpwVcIdMappingPeerAddrType and cpwVcIdMappingPeerAddr. This table is implemented as read only.
•cpwVcPeerMappingTable (Table 4)—Provides reverse mapping of the existing VCs based on VC type and VC ID ordering. This table is typically useful for EMS ordered query of existing VCs. This table is indexed by cpwVcPeerMappingPeerAddrType, cpwVcPeerMappingPeerAddr, cpwVcPeerMappingVcType, and cpwVcPeerMappingVcID. This table is implemented as read only.
Table 1 lists the cpwVcTable objects and their descriptions.
Table 2 lists the cpwVcPerfTotalTable objects and their descriptions.
Table 3 lists the cpwVcIdMappingTable objects and their descriptions.
Table 4 lists the cpwVcPeerMappingTable objects and their descriptions.
MIB Tables in the PW-MPLS-MIB
The PW-MPLS-MIB consists of the following tables:
•cpwVcMplsTable (Table 5)—Specifies information for the VC to be carried over an MPLS PSN. This table is indexed on cpwVcIndex.
•cpwVcMplsOutboundTable (Table 6)—Associates VCs using an MPLS PSN with the outbound MPLS tunnels toward the PSN or the physical interface in case of the VC only. A row in this table represents a link between PW VCs that require MPLS tunnels and an MPLS tunnel toward the PSN. This table is indexed by the cpwVcIndex and an additional index that is not supported in this implementation; consequently, its value is 1. The operator creates at least one entry in this table for each PW VC that requires an MPLS PSN. This implementation does not support the VC-only case or the cpwVcMplsOutboundIndex.
•cpwVcMplsInboundTable (Table 7)—Associates VCs using an MPLS PSN with the inbound MPLS tunnels for packets coming from the PSN, if such association is desired mainly for security reasons. A row in this table represents a link between PW VCs that require MPLS tunnels and an MPLS tunnel for packets arriving from the PSN. This table is indexed by the set of indexes used to identify the VC, cpwVcIndex and an additional index that is not supported in this implementation; consequently, its value is 1. An entry is created in this table either automatically by the local agent or manually by the operator when strict mode is required. This table points to the appropriate MPLS MIB. For MPLS-TE, the four variables relevant to the indexing of an MPLS TE tunnel are set. This implementation does not support the VC-only case or the cpwVcMplsInboundIndex.
•cpwVcMplsNonTeMappingTable (Table 8)—Maps an inbound or outbound tunnel to a VC in non-TE applications. A row in this table represents the association between a PW VC and its non-TE MPLS outer tunnel. An application can use this table to retrieve quickly the PW carried over a specific non-TE MPLS outer tunnel. This table in indexed by the XC index for the MPLS non-TE tunnel and the direction of the VC in the specific entry. The same table is used in both inbound and outbound directions, but in a different row for each direction. If the inbound association is not known, no rows should exist for it. Rows are created by the local agent when all the association data is available for display.
•cpwVcMplsTeMappingTable (Table 9)—Maps an inbound or outbound tunnel to a VC in MPLS-TE applications. A row in this table represents the association between a PW VC and its MPLS-TE outer tunnel. An application can use this table to retrieve quickly the PW carried over a specific TE MPLS outer tunnel. This table in indexed by the four indexes of a TE tunnel, the direction of the VC specific entry, and the VcIndex. The same table is used in both inbound and outbound directions, but a different row for each direction. If the inbound association is not known, no rows should exist for it. Rows are created by the local agent when all the association data is available for display. This table shows mappings between pseudowires and the xconnect index for non-TE outer tunnel or index.
Table 5 lists the cpwVcMplsTable objects and their descriptions.
Table 6 lists the cpwVcMplsOutboundTable objects and their descriptions.
Table 7 lists the cpwVcMplsInboundTable objects and their descriptions.
Table 8 lists the cpwVcMplsNonTeMappingTable objects and their descriptions.
Table 9 lists the cpwVcMplsTeMappingTable objects and their descriptions.
MIB Tables in the PW-ENET-MIB
The PW-ENET-MIB consists of the following table:
•cpwVcEnetTable (Table 10)—Provides Ethernet port mapping and VLAN configuration for each Ethernet emulated virtual connection. This table is indexed on cpwVcIndex, which uniquely identifies a singular connection. The second level index for this table is cpwVcEnetPwVlan, which indicates VLANs on this VC. This table is used only for Ethernet VC types—ethernetVLAN, ethernet, or ethernet virtual private LAN service (VPLS), and is implemented as read-only.
Table 10 lists the cpwVcEnetTable objects and their descriptions.
MIB Tables in the PW-FR-MIB
The PW-FR-MIB consists of the following table:
•cpwVcFrTable (Table 11)—Contains entries that represent an FRoPW connection operating in one-to-one mapping mode in which there is a one-to-one correspondence between a Frame Relay VC and a pair of unidirectional pseudowires.
Table 11 lists the cpwVcFrTable objects and their descriptions.
The PWE3 MIBs represent an ASN.1 notation reflecting specific components of the pseudowire services. The MIBs enable a network management application using SNMP to GET this information for display. The MIBs support the standard GETNEXT and GETBULK functionality, but do not support configuration capabilities (via SET) in the current implementation.
The PWE3 MIBs contain the following supported scalar object:
•cpwVcUpDownNotifEnable—This object reflects the configuration of the cpwVcUp and cpwVcDown notifications. If either of the notifications is configured via the command-line interface (CLI), then this object has a value of true(1). If this object is set via SNMP to true(1), then it enables the emission of both the cpwVcUp and cpwVcDown notifications; if the object is set via SNMP to false(2), these notifications are not emitted.
Note cpwVcUpDownNotifEnable can be set only if RW is configured for snmp-server community string [view view-name] [ro] [number].
The PWE3 MIBs contain the following unsupported scalar objects:
•cpwVcIndexNext—Indicates the next cpwVcIndex value when adding rows to the cpwVcTable.
•cpwVcNotifRate—Indicates the rate at which cpwVcUp/Down notifications can be issued from the device.
•cpwVcMplsOutboundIndexNext—Contains an appropriate value to be used for cpwVcMplsOutboundIndex when creating entries in the cpwVcMplsOutboundTable. The value 0 indicates that no unassigned entries are available. To obtain the cpwVcMplsOutboundIndex value for a new entry, the manager issues a management protocol retrieval operation to obtain the current value of this object. After each retrieval, the software agent should modify the value to the next unassigned index; however, the software agent must not assume such retrieval will be done for each row created.
•cpwVcMplsInboundIndexNext—Contains an appropriate value to be used for cpwVcMplsInboundIndex when creating entries in the cpwVcMplsInboundTable. The value 0 indicates that no unassigned entries are available. To obtain the cpwVcMplsInboundIndex value for a new entry, the manager issues a management protocol retrieval operation to obtain the current value of this object. After each retrieval, the software agent should modify the value to the next unassigned index; however, the agent must not assume such retrieval will be done for each row created.
The cpwVcUp and cpwVcDown notifications in the PW-MIB indicate when the operStatus values for a range of PW VCs have changed state.
The definition of these objects in the PW-MIB indicates that events of the same type, either up or down, must be able to be correlated into ranges. The implementation of these notifications does not do any of this correlation. A notification is generated for each individual VC that has an operational state change if that notification is enabled. A notification does not signal an operational state change for a group of VCs as described in the MIB.
The PWE3 MIBs provide the ability to manage pseudowire emulation edge-to-edge by providing MPLS-related information about the service and a mechanism to monitor the Ethernet or Frame Relay access circuits.
How to Configure the PWE3 MIBs
This section contains the following procedures:
•Enabling the SNMP Agent (required)
•Verifying the PWE3 MIBs Configuration (optional)
Enabling the SNMP Agent
Perform this task to enable the SNMP agent.
2. show running-configuration
3. configure terminal
4. snmp-server community string [view view-name] [ro] [number]
6. write memory
Setting Up AToM or Frame Relay Circuits Across a Network
For detailed information, see the Any Transport over MPLS feature module or the Cisco IOS Wide-Area Networking Configuration Guide, Release 12.3.
Verifying the PWE3 MIBs Configuration
Perform a MIB walk using your SNMP management tool on cpwVcMIB, cpwVcMplsMIB, cpwVcEnetMIB, and cpwVcFrMIB to verify that the PW-MIB, the PW-MPLS-MIB, the PW-ENET-MIB, and the PW-FR-MIB objects are populated correctly.
Note This release supports SNMPv1 and SNMPv2c.
Configuration Examples for the PWE3 MIBs
This section provides the following configuration example:
PWE3 MIBs: Example
In the following example, the configuration permits any SNMP manager to access all objects with read-only permissions using the community string public.Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.
Router(config)# snmp-server community public ro
Note There is no explicit way to configure the PWE3 MIBs. However, for information on AToM configuration tasks and examples, see the Any Transport over MPLS feature module; for Frame Relay, see the Cisco IOS Wide-Area Networking Configuration Guide, Release 12.3.
There are notifications specific to the PWE3 MIBs. For detailed information on the commands used to configure them, see the "Additional References" section.
The following sections provide references related to the PWE3 MIBs.
Related Topic Document Title
SNMP Support for VPNs
EoMPLS configuration tasks
The "How to Configure Any Transport over MPLS" section in the Any Transport over MPLS feature module
Frame Relay configuration tasks
Cisco IOS Wide-Area Networking Configuration Guide, Release 12.3
Pseudo Wire (PW) Management Information Base, Internet draft, February 2004 [draft-ietf-pwe3-pw-mib-04.txt]; Zelig, D., Nadeau, T.D., Danenberg, D. and Mantin, S.
Ethernet Pseudo Wire (PW) Management Information Base, Internet draft, February 2004 [draft-pwe3-enet-mib-04.txt]; Zelig, D. and Nadeau, T.D.
Pseudo Wire (PW) over MPLS PSN Management Information Base, Internet draft, February 2004 [draft-ietf-pwe3-pw-mpls-mib-05.txt]; Zelig, D., Nadeau, T.D., Danenberg, D., Mantin, S. and Malis, A.
Definitions for Textual Conventions and OBJECT-IDENTITIES for Pseudo-Wires Management, Internet draft, February 2003 [draft-ietf-pwe3-pw-tc-mib-04.txt]; Nadeau, T.D., Danenberg, D., Zelig, D. and Malis, A.
Frame Relay over Pseudo-Wires, Internet draft, July 2003 [draft-ietf-pwe3-frame-relay-01.txt]; Martini, L., et al.
Note For information on using SNMP MIB features, see the appropriate documentation for your network management system.
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
This feature uses no new or modified commands. All commands used with this feature are documented in the Cisco IOS Release 12.3 command reference publications.
CE router—customer edge router. A router that is part of a customer network and that interfaces to a provider edge (PE) router.
DLCI—data-link connection identifier. A unique number assigned to a PVC endpoint in a Frame Relay network. Identifies a particular PVC endpoint within an access channel in a Frame Relay network and has local significance only to that channel.
encapsulation—Wrapping of data in a particular protocol header. For example, Ethernet data is wrapped in a specific Ethernet header before network transit. Also, when bridging dissimilar networks, the entire frame from one network is simply placed in the header used by the data link layer protocol of the other network.
EoMPLS—Ethernet over Multiprotocol Label Switching (MPLS). A tunneling mechanism that allows a service provider to tunnel customer Layer 2 traffic though a Layer 3 MPLS network. EoMPLS is a point-to-point solution only. EoMPLS is also known as Layer 2 tunneling.
IETF—Internet Engineering Task Force. A task force (consisting of more than 80 working groups) that is developing standards for the Internet and the IP suite of protocols.
LDP—Label Distribution Protocol. The protocol that supports MPLS hop-by-hop forwarding and the distribution of bindings between labels and network prefixes. The Cisco proprietary version of this protocol is the Tag Distribution Protocol (TDP).
LSP—label-switched path. A configured connection between two label switch routers (LSRs) in which label-switching techniques are used for packet forwarding; also a specific path through an MPLS network.
LSR—label switch router. A Multiprotocol Label Switching (MPLS) node that can forward native Layer 3 packets. The LSR forwards a packet based on the value of a label attached to the packet.
MIB—Management Information Base. A database of network management information that is used and maintained by a network management protocol such as Simple Network Management Protocol (SNMP). The value of a MIB object can be changed or retrieved by using SNMP commands, usually through a network management system. MIB objects are organized in a tree structure that includes public (standard) and private (proprietary) branches.
MPLS—Multiprotocol Label Switching. A switching method for the forwarding of IP traffic through the use of a label. This label instructs the routers and the switches in the network where to forward the packets based on preestablished IP routing information.
MTU—maximum transmission unit. Maximum packet size, in bytes, that a particular interface can handle.
NMS—network management system. System responsible for managing at least part of a network. An NMS is generally a reasonably powerful and well-equipped computer, such as an engineering workstation. NMSs communicate with agents to help keep track of network statistics and resources.
notification—A message sent by a Simple Network Management Protocol (SNMP) agent to a network management station, console, or terminal to indicate that a significant network event has occurred. See also trap.
OSPF—Open Shortest Path First. A link-state hierarchical Interior Gateway Protocol routing algorithm, derived from the IS-IS protocol. OSPF features include least-cost routing, multipath routing, and load balancing.
PE router—provider edge router. A router that is part of a service provider's network and is connected to a customer edge (CE) router.
primary tunnel—A tunnel whose label-switched path (LSP) may be fast rerouted if there is a failure. Backup tunnels cannot be primary tunnels.
pseudowire—PW. A mechanism that carries the elements of an emulated service from one provider edge (PE) to one or more PEs over a packet switched network (PSN).
SNMP—Simple Network Management Protocol. A management protocol used almost exclusively in TCP/IP networks. SNMP provides a means for monitoring and controlling network devices, and for managing configurations, statistics collection, performance, and security.
trap—A message sent by an SNMP agent to a network management station, console, or terminal, indicating that a significant event occurred. Traps are less reliable than notification requests because the receiver does not send an acknowledgment when it receives a trap. The sender cannot determine if the trap was received.
tunnel—A secure communication path between two peers, such as routers.
Note Refer to Internetworking Terms and Acronyms for terms not included in this glossary.
Copyright © 2004 Cisco Systems, Inc. All rights reserved.