One document matched: draft-ietf-l3vpn-vr-mib-02.txt
Differences from draft-ietf-l3vpn-vr-mib-01.txt
INTERNET-DRAFT Elwin Stelzer
draft-ietf-l3vpn-vr-mib-02.txt Corona Networks, Inc.
Expires: January 2005
Sam Hancock
ACM Systems
Benson Schliesser
SAVVIS Communications
Joseph Laria
Level Stream Research
July 2004
Virtual Router Management Information Base Using SMIv2
1.0 Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
2.0 Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP based internets.
In particular, it defines objects for managing networks using Virtual
Routers (VR).
3.0 Table of Contents
1.0 Status of this Memo
2.0 Abstract
Expires January 2005 [Page 1]
Draft Virtual Router MIB July 2004
3.0 Table of Contents
4.0 Terminology
5.0 Introduction
6.0 The Internet-Standard Management Framework
7.0 Overview of the Virtual Router MIB
7.1 SNMP Contexts for Management for Virtual Routers
7.2 VR Indexing
7.3 Creation and Deletion of VRs
7.4 Administrative and Operational Status of VRs
7.5 Binding interfaces to a VR
7.6 Setting per VR limits
7.7 Per VR Statistics
7.8 Traps
8.0 Sample VR MIB Configuration Scenario
8.1 Creation of a VR
9.0 Definition of the Virtual Router MIB
10.0 Acknowledgments
11.0 Security Considerations
12.0 References
13.0 Authors' Addresses
4.0 Terminology
This document uses terminology defined in [PPVPN-FW] and [PPVPN-VR].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119, reference [RFC2119].
5.0 Introduction
This memo defines a MIB for the Virtual Router [PPVPN-VR, PPVPN-VR-AS]
model of Provider Provisioned VPNs [PPVPN-FW].
Following are the goals, in defining this MIB:
- To have a means for Service Providers to provision VPN service for
subscribers, at the PE device.
- To make the agent-side implementation simple, by not modifying the
existing standard MIBs.
- Define all the gluing tables that are needed toward this end.
Expires January 2005 [Page 2]
Draft Virtual Router MIB July 2004
6.0 The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a
MIB module that is compliant to the SMIv2, which is described in STD
58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC
2580 [RFC2580].
7.0 Overview of the Virtual Router MIB
7.1 SNMP Contexts for Management for Virtual Routers
There is a need for a single agent to manage multiple Virtual Routers.
The Architecture for describing SNMP Management Frameworks [RFC3411]
provides a way to support such cases.
Managing multiple virtual routers requires that the PE management plane be
subdivided into logical VR management domains. In the VR model of PPVPNs
a single PE device may contain many virtual routers. Different management
entities SHOULD be able to manage specific virtual routers and associated
services. The Service Provider MUST be able to manage all virtual routers
and associated services.
Using SNMP contexts to group a collection of management information
provides the following benefits:
(1) Uses a standard framework defined by the IETF, allowing the
product to remain flexible to all implementations of virtual
router devices.
(a) Use SNMPv2c Community String's
(b) Use SNMPv3 contextName's
(2) Prevents vendors from having to modify the
standard MIBs, allowing the implementation to remain standards
compliant.
(3) Provides a framework that will work for RIP, OSPF, IS-IS, BGP,
IP-FORWARDING, MPLS, and any other MIB that can be administratively
Expires January 2005 [Page 3]
Draft Virtual Router MIB July 2004
grouped with a VR.
The SNMP context for the Virtual Router instance can be specified in
the VrConfigTable. The VrContextName columnar object is used to set the
SNMPv2c Community String or the SNMPv3 contextName for a given VR.
A virtual router context represents the set of MIB objects that could be
administratively grouped within a VR. For example, each VR would maintain
its own instance of routing protocol MIB tables. However, the ADMIN context
would contain single instances of objects and tables that pertain to system
wide configuration such as the Entity, Interfaces, and ATM MIBs.
A management system using the SNMP context of a particular virtual
router MUST be able to manage the virtual router without disrupting other
virtual routers in the same PE device.
For example, a PE can be subdivided into two 2 VRs running the OSPF routing
protocol. Each VR will maintain a unique instance of the OSPF-MIB.
Therefore, the ospfAreaTable of VR-A is distinct from the
ospfAreaTable of VR-B.
+-----------------------------------------------------------------+
| +------------------------------------------------------------+ |
| | SNMP entity (including Engine, Applications) | |
| | | |
| | example contextNames: | |
| | | |
| | "vr01" "vr09" "admin" | |
| | --------- --------- ------------ | |
| | | | | | |
| +------|------------------|-------------------|--------------+ |
| | | | |
| +------|------------------|-------------------|--------------+ |
| | MIB | instrumentation | | | |
| | +---v------------+ +---v------------+ +----v-----------+ | |
| | | context=vr01 | | context=vr09 | | context=admin | | |
| | | | | | | | | |
| | | +------------+ | | +------------+ | | +------------+ | | |
| | | | OSPF MIB | | | | OSPF MIB | | | | VR MIB | | | |
| | | +------------+ | | +------------+ | | +------------+ | | |
| | | | | | | | | |
| | | +------------+ | | +------------+ | | +------------+ | | |
| | | | BGP MIB | | | | BGP MIB | | | | ATM MIB | | | |
| | | +------------+ | | +------------+ | | +------------+ | | |
| | | | | | | | | |
| | | +------------+ | | +------------+ | | +------------+ | | |
| | | | IP MIB | | | | IP MIB | | | | ENTITY MIB | | | |
| | | +------------+ | | +------------+ | | +------------+ | | |
| | | | | | | | | |
| | | +------------+ | | +------------+ | | +------------+ | | |
| | | | other MIB | | | | other MIB | | | | IF MIB | | | |
| | | +------------+ | | +------------+ | | +------------+ | | |
| | | ... | | ... | | ... | | |
+-----------------------------------------------------------------+
Expires January 2005 [Page 4]
Draft Virtual Router MIB July 2004
Filtering mechanisms based on the SNMP context of a particular virtual router
may implemented to allow different management entities to manage those objects
and services provisioned the 'Admin' context.
7.2 VR Indexing
While the standard protocol MIB tables are instantiated in the
context specified using SNMP contexts, there may be tables that are
defined with the VRID as index.
The VRID is of local significance to a particular PE device, and need
not be globally unique. Thus a particular VRID value assigned to a VR
in one PE device may indicate a different VR in another PE device.
The VRID has an Unsigned32 value, and this value is assigned by the management
station. To aid the management station in assigning a VRID without conflict,
the management station can get the 'NextAvailableVRID' from the PE device.
A SNMP manager SHOULD NOT assume global significance of any VRID value
other than 0.
For those MIB tables instantiated in the virtual router context, indexing can
only be assumed unique for that particular VR. However those indices in the
"ADMIN" context are unique across the entire system, including all VRs.
7.3 Creation and Deletion of VRs
The VR Config Table is used for this purpose. This is a read-create
table and adding an entry into this table will create a VR. Removing
an entry from this table marks the deletion of a VR.
VRID 0 is assigned to the Administrative VR, which exists by default,
and need not be created. Deletion of the Administrative VR will not be
permitted. The VRID of the Administrative VR (VRID 0) should be a
reserved VRID number. VRID 0 could be termed the "null VR" and it could
be the context that manages the resource pool of unattached interfaces.
Routing would then not exist in the context of Administrative VR.
7.4 Administrative and Operational Status of VRs
VRs can be administratively turned down. When this is done, no
packet forwarding via the VR takes place.
VrOperStatus denotes the operational status of a VR. Currently the
VrOperStatus is expected to change along the VrAdminStatus unless an
error condition exists.
Expires January 2005 [Page 5]
Draft Virtual Router MIB July 2004
7.5 Binding interfaces to a VR
Interfaces are bound to a VR, using vrIfConfigTable. This is
a read-write table, and note that interfaces are not created through
this table. The vrIfConfigTable MIB table is used to indicated the
relationship between interfaces and virtual router IDs. For each
interface present in the system, this table is used to provide the
mapping from IfIndex to a unique VR. The table show which interfaces
are –attached or connected• to a virtual router. An interface can not
be attached to more than one VR.
The "Admin" VR could be used to manage the resource pool of
unattached interfaces. However interfaces would not be attached to
VRID 0.
7.6 Setting per VR limits
VRs consume resources on a device, and hence the following parameters
defined in vrConfigTable are used to specify an upper bound of resource
utilization:
VrMaxRoutes -
Specify the maximum number of routes that will be permitted
in VR. This includes all routes, such as the statically configured routes,
and the routes learnt via dynamic routing protocols.
7.7 Per VR Statistics
In addition to those statistics available through the VR instantiated MIB
tables, there are some per-VR statistics available through vrStatTable.
7.8 Traps
This memo defines that VrUp and VrDown traps are generated just after
VrOperStatus leaves, or just before it enters, the down state,
respectively.
(1) A transition into the down state will occur when an error is
detected on a VR instance.
(2) Departing the down state generally indicates that the
VR is going to up, which is considered a "healthy" state.
An exception to the above generation of VrUp/VrDown traps on changes
in VrOperStatus, occurs when an VR is "flapping", i.e., when it is
rapidly oscillating between the up and down states. If traps were
generated for each such oscillation, the network and the network
management system would be flooded with unnecessary traps. In such a
situation, the agent should limit the rate at which it generates traps.
This memo defines that enabling and disabling the VR traps is achieved
by setting the VrTrapEnable to true(1) or false(2), respectively. By
default, this object should have the value true(1).
Expires January 2005 [Page 6]
Draft Virtual Router MIB July 2004
8.0 Sample VR MIB Configuration Scenario
8.1 Creation of a VR
Creating VR instances can be achieved using the following example.
(1) Get the next available Virtual Router Id using the
NextAvailableVrId, to create a VR:
Using a context with 'read' access for system level entities.
GetRequest { NextAvailableVrId.0 }
Response { NextAvailableVrId.0 = 5555 }
(2) In VrConfigTable, create VR Instance using VrRowStatus:
Using a context with 'read-write' access for system level entities
SetRequest {
VrRowStatus.5555 createAndGo(4),
VrName.5555 "BigTelcoVR",
VrContextName.5555 "vr5555",
VrTrapEnable.5555 true(1),
VrAdminStatus.5555 up(1)
}
9.0 Definition of the Virtual Router MIB
--
-- VIRTUAL-ROUTER-MIB
--
VIRTUAL-ROUTER-MIB DEFINITIONS ::= BEGIN
IMPORTS
InterfaceIndex
FROM IF-MIB
InetAddressType, InetAddress
FROM INET-ADDRESS-MIB
-- RFC Ed.: VPN-TC-MIB in Last Call in L3VPN WG
VPNId
FROM VPN-TC-MIB
OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP
FROM SNMPv2-CONF
experimental, Unsigned32, OBJECT-TYPE,
MODULE-IDENTITY, TimeTicks, NOTIFICATION-TYPE
FROM SNMPv2-SMI
TruthValue, DisplayString, RowStatus, TEXTUAL-CONVENTION
FROM SNMPv2-TC;
virtualRouterMIB MODULE-IDENTITY
LAST-UPDATED "200407161200Z"
ORGANIZATION
"IETF L3VPN WG"
CONTACT-INFO
Expires January 2005 [Page 7]
Draft Virtual Router MIB July 2004
"
Elwin Stelzer Eliazer
Corona Networks, Inc.
630 Alder Drive
Milpitas, CA 95035
USA
Phone: +1-408-519-3832
Email: elwinietf@yahoo.com
Samuel Hancock
ACM Systems
3034 Gold Canal Drive
Rancho Cordova, CA 95670
USA
Phone: +1-916-463-7949
Email: hancoc_s@yahoo.com
Benson Schliesser
SAVVIS Communications
1 Savvis Parkway
Town and Country, MO 63017
USA
Phone: +1-314-628-7036
Email: bensons@savvis.net
Joseph Laria
Level Stream Research
Wilmington, MA 01887
USA
Phone: +1-978-884-3537
Emain: jlaria@levelstream.com
"
DESCRIPTION
"The MIB is the definition of the managed
objects for the Virtual Router."
REVISION "200407161200Z" -- 16 July 2004 12:00:00 GMT
DESCRIPTION "Initial version, published as RFC yyyy."
-- RFC Ed.: replace yyyy with actual RFC number & remove this note
::= { experimental xxxx } -- To be assigned
-- RFC Ed.: replace xxxx with IANA-assigned number & remove this note
--
-- Textual conventions
--
VrIdentifier ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Virtual Router Identifier.
Expires January 2005 [Page 8]
Draft Virtual Router MIB July 2004
VRID 0 is reserved for the Administrative VR
and cannot be used to create VR's.
"
SYNTAX Unsigned32
--
-- Node definitions
--
vrMIBObjects OBJECT IDENTIFIER ::= { virtualRouterMIB 1 }
vrConfig OBJECT IDENTIFIER ::= { vrMIBObjects 1 }
vrConfigScalars OBJECT IDENTIFIER ::= { vrConfig 1 }
vrConfigNextAvailableVrId OBJECT-TYPE
SYNTAX VrIdentifier
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The next available Virtual Router Id (index).
This object provides a hint for the vrID value
to use when administratively creating a new
vrConfigEntry.
A GET of this object returns the next available vrId
value to be used to create an entry in the associated
vrConfigTable; or zero, if no valid vrId
value is available. A value of zero(0) indicates that
it is not possible to create a new vrConfigEntry
This object also returns a value of zero when it is the
lexicographic successor of a varbind presented in an
SNMP GETNEXT or GETBULK request, for which circumstance
it is assumed that ifIndex allocation is unintended.
Successive GETs will typically return different
values, thus avoiding collisions among cooperating
management clients seeking to create table entries
simultaneously.
Unless specified otherwise by its MAX-ACCESS and
DESCRIPTION clauses, an object of this type is read-only,
and a SET of such an object returns a notWritable error."
::= { vrConfigScalars 1 }
vrConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF VrConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table is for creating the new Virtual Routers."
::= { vrConfig 2 }
Expires January 2005 [Page 9]
Draft Virtual Router MIB July 2004
vrConfigEntry OBJECT-TYPE
SYNTAX VrConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The entries in this table can be added/deleted
using the vrRowStatus."
INDEX { vrId }
::= { vrConfigTable 1 }
VrConfigEntry ::=
SEQUENCE {
vrId
VrIdentifier,
vrRowStatus
RowStatus,
vrName
DisplayString,
vrContextName
DisplayString,
vrTrapEnable
TruthValue,
vrMaxRoutes
Unsigned32,
vrAdminStatus
INTEGER,
vrVpnId
VPNId,
vrRpTrigger
Unsigned32
}
vrId OBJECT-TYPE
SYNTAX VrIdentifier
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The unique id of this virtual router instance. A Virtual
Router cannot not be created with vrId = 0.
VRID 0 is reserved for the Administrative VR.
"
::= { vrConfigEntry 1 }
vrRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status column has three defined values:
- `active', which indicates that the conceptual row is
available for use by the managed device;
Expires January 2005 [Page 10]
Draft Virtual Router MIB July 2004
- `createAndGo', which is supplied by a management
station wishing to create a new instance of a
conceptual row and to have its status automatically set
to active, making it available for use by the managed
device;
- `destroy', which is supplied by a management station
wishing to delete all of the instances associated with
an existing conceptual row."
::= { vrConfigEntry 2 }
vrName OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Name of the Virtual Router..
"
::= { vrConfigEntry 3 }
vrContextName OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The SNMPv2 Community String or SNMPv3 contextName
denotes the VR 'context' and is used to logically
separate the MIB management."
::= { vrConfigEntry 4 }
vrTrapEnable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This objects is used to enable the generation
of the VrUp and VrDown traps.
true(1) - VR Traps Enabled
false(2) - VR Traps Disabled"
DEFVAL { true }
::= { vrConfigEntry 5 }
vrMaxRoutes OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object specifies the maximum number of routes that
this VR can support. The default value is 4 Gig (meaning
unlimited)."
DEFVAL { 4294967295 }
::= { vrConfigEntry 6 }
Expires January 2005 [Page 11]
Draft Virtual Router MIB July 2004
vrAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1),
down(2),
testing(3),
unknown(4)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The administrative state of the Virtual Router."
DEFVAL { down }
::= { vrConfigEntry 7 }
vrVpnId OBJECT-TYPE
SYNTAX VPNId
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Virtual Private Network Identifier of the Virtual
Router."
::= { vrConfigEntry 8 }
vrRpTrigger OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Routing Protocol Triggers on the Virtual Router.
This can be used to initiate or shutdown routing protocols
on a VR.
The 32 bits are divided into:
16 bits of RP bitmap,
15 bits reserved (0), and 1 bit of action-code.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|RP bitmap (MSB)|
+-+-+-+-+-+-+-+-+
|RP bitmap (LSB)|
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+
|*| Reserved |
+-+-+-+-+-+-+-+-+ *=action-code
The RP bitmap specify the RP that is to be initiated or
Expires January 2005 [Page 12]
Draft Virtual Router MIB July 2004
shutdown. Multiple RPs can be acted on simultaneously.
Also, individual RPs can be brought up in steps, which
should not affect the RPs that were running.
Action-code specify what needs to be done for the RPs
in the RP bitmap. The actions are: initiate or shutdown.
The running status of the RP shall be available in the
VR stats table's vrRpStatus, which has a similar
format, but represent the status."
::= { vrConfigEntry 9 }
vrStat OBJECT IDENTIFIER ::= { vrMIBObjects 2 }
vrStatScalars OBJECT IDENTIFIER ::= { vrStat 1 }
vrConfiguredVRs OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of VRs configured on this network element."
::= { vrStatScalars 1 }
vrActiveVRs OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of VRs that are active on the network element.
These are VRs for which the
vrStatOperationalStatus = up(1)"
::= { vrStatScalars 2 }
vrStatTable OBJECT-TYPE
SYNTAX SEQUENCE OF VrStatEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains statistics for the Virtual Router."
::= { vrStat 2 }
vrStatEntry OBJECT-TYPE
SYNTAX VrStatEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entries in this table a per vrId."
INDEX { vrId }
::= { vrStatTable 1 }
VrStatEntry ::=
SEQUENCE {
Expires January 2005 [Page 13]
Draft Virtual Router MIB July 2004
vrStatRouteEntries
Unsigned32,
vrStatFIBEntries
Unsigned32,
vrStatUpTime
TimeTicks,
vrOperStatus
INTEGER,
vrRpStatus
Unsigned32,
vrRouterAddressType
InetAddressType,
vrRouterAddress
InetAddress
}
vrStatRouteEntries OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Total number of routes for this VR."
::= { vrStatEntry 1 }
vrStatFIBEntries OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Total number of FIB Entries for this VR."
::= { vrStatEntry 2 }
vrStatUpTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The time in (in hundredths of a second) since
this VR entry has been operational."
::= { vrStatEntry 3 }
vrOperStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1),
down(2),
unknown(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The operational state of the Virtual Router."
::= { vrStatEntry 4 }
Expires January 2005 [Page 14]
Draft Virtual Router MIB July 2004
vrRpStatus OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"List of Routing Protocols on this VR."
::= { vrStatEntry 5 }
vrRouterAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Router Address Type of this VR."
::= { vrStatEntry 6 }
vrRouterAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Router Address of this VR. It is derived from one of the
interfaces. If loopback interface is present, the loopback
interface address can be used. However, loopback interface
is optional."
::= { vrStatEntry 7 }
vrIfConfig OBJECT IDENTIFIER ::= { vrMIBObjects 3 }
vrIfConfigScalars OBJECT IDENTIFIER ::= { vrIfConfig 1 }
vrIfConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF VrIfConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table is for configuring VR Interfaces."
::= { vrIfConfig 2 }
vrIfConfigEntry OBJECT-TYPE
SYNTAX VrIfConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entries in this table correspond to the entries in
the ifTable that apply to the Virtual Router."
INDEX { vrId,
vrIfId }
::= { vrIfConfigTable 1 }
Expires January 2005 [Page 15]
Draft Virtual Router MIB July 2004
VrIfConfigEntry ::=
SEQUENCE {
vrIfId
InterfaceIndex,
vrIfConfigRowStatus
RowStatus
}
vrIfId OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Virtual Router Interface Index."
::= { vrIfConfigEntry 1 }
vrIfConfigRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object is used to create, delete or
modify a row in this table."
::= { vrIfConfigEntry 2 }
-- *********************************************************************
-- Module Traps/Notifications
-- *********************************************************************
vrNotificationsPrefix OBJECT IDENTIFIER ::= { vrMIBObjects 4 }
vrNotifications OBJECT IDENTIFIER ::= { vrNotificationsPrefix 0 }
vrUp NOTIFICATION-TYPE
OBJECTS { vrRowStatus }
STATUS current
DESCRIPTION
"This notification is generated when the specified
VR is about to initialized or change the status from
down to up."
::= { vrNotifications 1 }
vrDown NOTIFICATION-TYPE
OBJECTS { vrRowStatus }
STATUS current
DESCRIPTION
"This notification is generated when the specified
VR is about to go down."
::= { vrNotifications 2 }
Expires January 2005 [Page 16]
Draft Virtual Router MIB July 2004
vrMaxRoutesExceeded NOTIFICATION-TYPE
OBJECTS { vrRowStatus, vrMaxRoutes, vrStatRouteEntries }
STATUS current
DESCRIPTION
"This notification is generated when the specified VR has
exceeded the maximum number of routes specified"
::= { vrNotifications 3 }
-- *********************************************************************
-- Module Compliance/Conformance Statements
-- *********************************************************************
vrConformance OBJECT IDENTIFIER ::= { virtualRouterMIB 2 }
vrCompliances OBJECT IDENTIFIER ::= { vrConformance 1 }
vrMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for entities that implement the
VIRTUAL-ROUTER-MIB. Implementation of this MIB
is strongly recommended for any platform targeted for a
carrier-class environment."
MODULE -- this module
MANDATORY-GROUPS { vrConfigGroup, vrStatGroup,
vrIfGroup, vrNotificationGroup }
::= { vrCompliances 1 }
vrGroups OBJECT IDENTIFIER ::= { vrConformance 2 }
vrConfigGroup OBJECT-GROUP
OBJECTS { vrRowStatus, vrName,
vrContextName, vrTrapEnable,
vrMaxRoutes, vrAdminStatus,
vrVpnId, vrRpTrigger,
vrConfigNextAvailableVrId }
STATUS current
DESCRIPTION
"A collection of attributes that support provisioning
of a virtual router."
::= { vrGroups 1 }
vrStatGroup OBJECT-GROUP
OBJECTS { vrConfiguredVRs, vrActiveVRs,
vrStatRouteEntries, vrStatFIBEntries, vrStatUpTime,
vrOperStatus, vrRpStatus, vrRouterAddress,
vrRouterAddressType }
STATUS current
DESCRIPTION
"A collection of attributes that contain stats about the
virtual router."
::= { vrGroups 2 }
Expires January 2005 [Page 17]
Draft Virtual Router MIB July 2004
vrIfGroup OBJECT-GROUP
OBJECTS { vrIfConfigRowStatus }
STATUS current
DESCRIPTION
"A collection of attributes that support provisioning of a
virtual router interfaces."
::= { vrGroups 3 }
vrNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS { vrUp, vrDown, vrMaxRoutesExceeded }
STATUS current
DESCRIPTION
"A collection of traps that are supported by the VR."
::= { vrGroups 4 }
END
10.0 Acknowledgments
Special thanks to Joan Cucchiara for providing valuable comments on this MIB.
11.0 Security Considerations
There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations. These are the tables and objects and their
sensitivity/vulnerability:
The Administrative VR provides visibility into and control over multiple
VPNs. As such, security considerations for implementations of the
Administrative VR and associated control plane(s) are critical to the
security of the VPNs supported on each PE device.
Some of the readable objects in this MIB module (i.e., objects with a
MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability:
Use of any vrContextName MUST be allowed in the Administrative VR.
Additional authentication and security mechanisms SHOULD be used for SNMP
access in the Administrative VR.
Expires January 2005 [Page 18]
Draft Virtual Router MIB July 2004
VRs other than the Administrative VR MUST NOT have access to other VR's
Instantiated MIBs, and MAY have access to their own instantiated MIBs.
In VRs other than the Administrative VR, access to that VR's instantiated
MIBs MAY be permitted via that VR's vrContextName. Use of any vrContextName
other than that assigned to the accessed VR MUST result in an error, and
implementations SHOULD provide a logging mechanism for such events.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec),
even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module.
It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
12.0 References
[RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2571, April 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirements Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC2685] Fox B., et al, "Virtual Private Networks
Identifier", RFC 2685, September 1999.
Expires January 2005 [Page 19]
Draft Virtual Router MIB July 2004
[VPNTCMIB] B. Schliesser, and T. Nadeau, "Definition of Textual
Conventions for Provider Provisioned Virtual Private Network
(PPVPN) Management.", Internet Draft
<draft-ietf-l3vpn-tc-mib-03.txt>, May 2004.
[PPVPN-FW] R. Callon, et al., "A Framework for Layer 3 Provider
Provisioned Virtual Private Networks",
draft-ietf-l3vpn-framework-00.txt, March 2003.
[PPVPN-VR] P. Knight, et al., "Network based IP VPN Architecture
using Virtual Routers", draft-ietf-l3vpn-vpn-vr-02.txt, April 2004.
[PPVPN-VR-AS] A. Nagarajan, et al., "Applicability Statement for
Virtual Router-based Layer 3 PPVPN approaches",
draft-ietf-l3vpn-as-vr-01.txt, February 2004.
13.0 Authors' Addresses
Elwin Stelzer Eliazer
Corona Networks, Inc.
630 Alder Drive
Milpitas, CA 95035
USA
Phone: +1-408-519-3832
Email: elwinietf@yahoo.com
Samuel Hancock
ACM Systems
3034 Gold Canal Drive
Rancho Cordova, CA 94123
USA
Phone: +1-916-463-7949
Email: hancoc_s@yahoo.com
Benson Schliesser
SAVVIS Communications
1 Savvis Parkway
Town and Country, MO 63017
USA
Phone: +1-314-628-7036
Email: bensons@savvis.net
Joseph Laria
Level Stream Research
Wilmington, MA 01887
USA
Phone: +1-978-884-3537
Emain: jlaria@levelstream.com
Expires January 2005 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-21 12:59:16 |