smilint output for ./VIRTUAL-ROUTER-MIB
| Message Severities |
|---|
| Severity | Count |
|---|
| severe | 1 |
| error | 1 |
| warning | 2 |
| Message Types |
|---|
| Type | Count |
|---|
| comment-terminates (warning) | 1 |
| internal-other (severe) | 1 |
| object-identifier-not-prefix (error) | 1 |
| type-without-format (warning) | 1 |
Messages:
VIRTUAL-ROUTER-MIB
1: -- extracted from draft-ietf-l3vpn-vr-mib-04.txt
2: -- at Tue Aug 2 06:34:59 2005
3:
4: VIRTUAL-ROUTER-MIB DEFINITIONS ::= BEGIN
5: --
6:
7: IMPORTS
8: InterfaceIndex
9: FROM IF-MIB
10: InetAddressType, InetAddress
11: FROM INET-ADDRESS-MIB
12: -- RFC Ed.: VPN-TC-STD-MIB in Last Call in L3VPN WG
13: VPNId
14: FROM VPN-TC-STD-MIB
15: OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP
16: FROM SNMPv2-CONF
17: Unsigned32, OBJECT-TYPE, MODULE-IDENTITY, TimeTicks,
18: NOTIFICATION-TYPE, mib-2
19: FROM SNMPv2-SMI
20: TruthValue, DisplayString, RowStatus, TEXTUAL-CONVENTION
21: FROM SNMPv2-TC;
22:
23: virtualRouterMIB MODULE-IDENTITY
24: LAST-UPDATED "200507221200Z"
25: ORGANIZATION
26: "IETF L3VPN WG"
27: CONTACT-INFO
28:
29: "
30: Elwin Stelzer Eliazer
31: Corona Networks, Inc.
32: 630 Alder Drive
33: Milpitas, CA 95035
34: USA
35: Phone: +1-408-519-3832
36: Email: elwinietf@yahoo.com
37:
38: Samuel Hancock
39: ACM Systems
40: 3034 Gold Canal Drive
41: Rancho Cordova, CA 95670
42: USA
43: Phone: +1-916-463-7949
44: Email: hancoc_s@yahoo.com
45:
46: Benson Schliesser
47: SAVVIS Communications
48: 1 Savvis Parkway
49: Town and Country, MO 63017
50: USA
51: Phone: +1-314-628-7036
52: Email: bensons@savvis.net
53:
54: Joseph Laria (Editor)
55: Level Stream Research
56: Wilmington, MA 01887
57: USA
58: Phone: +1-978-223-9908
59: Email: jlaria@levelstream.com
60: "
61:
62: DESCRIPTION
63: "The MIB module is the definition of the managed
64: objects for the Virtual Router."
65: REVISION "200507221200Z" -- 22 July 2005 12:00:00 GMT
66: DESCRIPTION "Initial version, published as RFC yyyy."
67: -- RFC Ed.: replace yyyy with actual RFC number & remove this note
68: ::= { mib-2 xxxx } -- To be assigned
68: error -
Object identifier element `xxxx' name only allowed as first element
69: -- RFC Ed.: replace xxxx with IANA-assigned number & remove this note
70:
71:
72:
73: --
74: -- Textual conventions
75: --
76:
77:
78: VrIdentifier ::= TEXTUAL-CONVENTION
78: warning -
warning: type `VrIdentifier' has no format specification
79: STATUS current
80: DESCRIPTION
81: "Virtual Router Identifier.
82: VRID 0 is reserved for the Administrative VR
83: and cannot be used to create VR's.
84: "
85: SYNTAX Unsigned32 (0..4294967295)
86:
87: VrRpTriggerBitCode ::= TEXTUAL-CONVENTION
88: STATUS current
89: DESCRIPTION
90: "This object represents Routing Protocol (RP)
91: Triggers on a Virtual Router. The BITS
92: represent an Action-code that specifies the
93: action on the Routing Protocols.
94:
95: The actions are: initiate or shutdown.
96:
97: When encoding the RP using the BITS construct,
98: the value is encoded as an OCTET STRING where
99: the first bit (bit 0) is the highest bit of the
100: octet.
101:
102: Bits 0-3 may be specified in any combination to
103: allow multiple Routing Protocols to be acted on
104: simultaneously or individually.
105: "
106: SYNTAX BITS {
107: rip (0),
108: ospf(1),
109: bgp (2),
110: isis (3)
111: }
112:
113: --
114: -- Node definitions
115: --
116:
117: vrMIBObjects OBJECT IDENTIFIER ::= { virtualRouterMIB 1 }
118:
119: vrConfig OBJECT IDENTIFIER ::= { vrMIBObjects 1 }
120:
121: vrConfigScalars OBJECT IDENTIFIER ::= { vrConfig 1 }
122:
123: vrConfigNextAvailableVrId OBJECT-TYPE
124: SYNTAX VrIdentifier
125: MAX-ACCESS read-only
126: STATUS current
127: DESCRIPTION
128: "The next available Virtual Router Id (index).
129: This object provides a hint for the vrID value
130: to use when administratively creating a new
131: vrConfigEntry.
132:
133: A GET of this object returns the next available vrId
134: value to be used to create an entry in the associated
135: vrConfigTable; or zero, if no valid vrId
136: value is available. A value of zero(0) indicates that
137: it is not possible to create a new vrConfigEntry
138: This object also returns a value of zero when it is the
139: lexicographic successor of a varbind presented in an
140: SNMP GETNEXT or GETBULK request, for which circumstance
141: it is assumed that ifIndex allocation is unintended.
142:
143: Successive GETs will typically return different
144: values, thus avoiding collisions among cooperating
145: management clients seeking to create table entries
146: simultaneously.
147:
148: Unless specified otherwise by its MAX-ACCESS and
149: DESCRIPTION clauses, an object of this type is read-only,
150: and a SET of such an object returns a notWritable error."
151: ::= { vrConfigScalars 1 }
152:
153: vrConfigTable OBJECT-TYPE
154: SYNTAX SEQUENCE OF VrConfigEntry
155: MAX-ACCESS not-accessible
156: STATUS current
157: DESCRIPTION
158: "This table is for creating the new Virtual Routers."
159: ::= { vrConfig 2 }
160:
161: vrConfigEntry OBJECT-TYPE
162: SYNTAX VrConfigEntry
163: MAX-ACCESS not-accessible
164: STATUS current
165: DESCRIPTION
166: "The entries in this table can be added/deleted
167: using the vrRowStatus."
168: INDEX { vrId }
169: ::= { vrConfigTable 1 }
170:
171: VrConfigEntry ::=
172: SEQUENCE {
173: vrId
174: VrIdentifier,
175: vrRowStatus
176: RowStatus,
177: vrName
178: DisplayString,
179: vrContextName
180: DisplayString,
181: vrTrapEnable
182: TruthValue,
183: vrMaxRoutes
184: Unsigned32,
185: vrAdminStatus
186: INTEGER,
187: vrVpnId
188: VPNId,
189: vrRpTrigger
190: VrRpTriggerBitCode,
191: vrMaxRoutesTrapEnable
192: TruthValue
193: }
194:
195: vrId OBJECT-TYPE
196: SYNTAX VrIdentifier
197: MAX-ACCESS not-accessible
198: STATUS current
199: DESCRIPTION
200: "The unique id of this virtual router instance. A Virtual
201: Router cannot not be created with vrId = 0.
202: VRID 0 is reserved for the Administrative VR.
203: "
204: ::= { vrConfigEntry 1 }
205:
206: vrRowStatus OBJECT-TYPE
207: SYNTAX RowStatus
208: MAX-ACCESS read-create
209: STATUS current
210: DESCRIPTION
211: "The status column has three defined values:
212:
213: - `active', which indicates that the conceptual row is
214: available for use by the managed device;
215: - `createAndGo', which is supplied by a management
216: station wishing to create a new instance of a
217: conceptual row and to have its status automatically set
218: to active, making it available for use by the managed
219: device;
220:
221: - `destroy', which is supplied by a management station
222: wishing to delete all of the instances associated with
223: an existing conceptual row."
224: ::= { vrConfigEntry 2 }
225:
226: vrName OBJECT-TYPE
227: SYNTAX DisplayString
228: MAX-ACCESS read-create
229: STATUS current
230: DESCRIPTION
231: "The Name of the Virtual Router."
232: ::= { vrConfigEntry 3 }
233:
234: vrContextName OBJECT-TYPE
235: SYNTAX DisplayString
236: MAX-ACCESS read-create
237: STATUS current
238: DESCRIPTION
239: "The SNMPv2 Community String or SNMPv3 contextName
240: denotes the VR 'context' and is used to logically
241: separate the MIB module management."
242: ::= { vrConfigEntry 4 }
243:
244: vrTrapEnable OBJECT-TYPE
245: SYNTAX TruthValue
246: MAX-ACCESS read-create
247: STATUS current
248: DESCRIPTION
249: "This objects is used to enable the generation
250: of the VrUp and VrDown traps.
251: true(1) - VR Traps Enabled
252: false(2) - VR Traps Disabled"
253: DEFVAL { true }
254: ::= { vrConfigEntry 5 }
255:
256: vrMaxRoutes OBJECT-TYPE
257: SYNTAX Unsigned32
258: MAX-ACCESS read-create
259: STATUS current
260: DESCRIPTION
261: "This object specifies the maximum number of routes that
262: this VR can support. The default value is 4 Gig (meaning
263: unlimited)."
264: DEFVAL { 4294967295 }
265: ::= { vrConfigEntry 6 }
266:
267: vrAdminStatus OBJECT-TYPE
268: SYNTAX INTEGER {
269: up(1),
270: down(2),
271: testing(3),
272: unknown(4)
273: }
274: MAX-ACCESS read-create
275: STATUS current
276: DESCRIPTION
277: "The administrative state of the Virtual Router."
278: DEFVAL { down }
279: ::= { vrConfigEntry 7 }
280:
281: vrVpnId OBJECT-TYPE
282: SYNTAX VPNId
283: MAX-ACCESS read-create
284: STATUS current
285: DESCRIPTION
286: "The Virtual Private Network Identifier of the Virtual
287: Router."
288: ::= { vrConfigEntry 8 }
289:
290: vrRpTrigger OBJECT-TYPE
291: SYNTAX VrRpTriggerBitCode
292: MAX-ACCESS read-create
293: STATUS current
294: DESCRIPTION
295: "This object represents Routing Protocol (RP)
296: Triggers on a Virtual Router and it meant to
297: be used to initiate or shutdown routing
298: protocols on a VR. Multiple RPs can be acted
299: on simultaneously. Also, individual RPs can
300: be brought up in steps, which should not
301: affect the RPs that were running. The BITS
302: represent an Action-code that specifies what
303: action is to be performed for the RPs.
304: The actions are: initiate(1) or shutdown(0).
305:
306: The running status of an RP shall be available
307: in the VR stats table's vrRpStatus, which has
308: a similar format, but represents the status.
309:
310: Bits 0-3 may be specified in any combination.
311: Individual routing protocols may be enabled
312: and disabled independently. Protocols are
313: enabled by setting the respective BIT and are
314: disabled by resetting the BIT.
315:
316: So, for example, to enable RIP and BGP protocols
317: the vrRpTrigger bits 0 and 2 need to be set, and
318: as encoded as 10100000.
319: All zeros should be interpreted as all protocols
320: disable.
321: "
322: DEFVAL { '00000000'b }
323: ::= { vrConfigEntry 9 }
324: vrMaxRoutesTrapEnable OBJECT-TYPE
325: SYNTAX TruthValue
326: MAX-ACCESS read-create
327: STATUS current
328: DESCRIPTION
329: "This objects is used to enable the generation
330: of the VR Max Routes Exceeded traps.
331: true(1) - VR Max Routes Exceeded Traps Enabled
332: false(2) - VR Max Routes Exceeded Traps Disabled"
333: DEFVAL { true }
334: ::= { vrConfigEntry 10 }
335:
336:
337:
338: vrStat OBJECT IDENTIFIER ::= { vrMIBObjects 2 }
339:
340: vrStatScalars OBJECT IDENTIFIER ::= { vrStat 1 }
341:
342: vrConfiguredVRs OBJECT-TYPE
343: SYNTAX Unsigned32
344: MAX-ACCESS read-only
345: STATUS current
346: DESCRIPTION
347: "The number of VRs configured on this network element."
348: ::= { vrStatScalars 1 }
349:
350: vrActiveVRs OBJECT-TYPE
351: SYNTAX Unsigned32
352: MAX-ACCESS read-only
353: STATUS current
354: DESCRIPTION
355: "The number of VRs that are active on the network element.
356: These are VRs for which the
357: vrStatOperStatus = up(1)"
358: ::= { vrStatScalars 2 }
359:
360: vrStatTable OBJECT-TYPE
361: SYNTAX SEQUENCE OF VrStatEntry
362: MAX-ACCESS not-accessible
363: STATUS current
364: DESCRIPTION
365: "This table contains statistics for the Virtual Router."
366: ::= { vrStat 2 }
367:
368: vrStatEntry OBJECT-TYPE
369: SYNTAX VrStatEntry
370: MAX-ACCESS not-accessible
371: STATUS current
372: DESCRIPTION
373: "Entries in this table a per vrId."
374: INDEX { vrId }
375: ::= { vrStatTable 1 }
376:
377: VrStatEntry ::=
378: SEQUENCE {
379: vrStatRouteEntries
380: Unsigned32,
381: vrStatFIBEntries
382: Unsigned32,
383: vrStatUpTime
384: TimeTicks,
385: vrOperStatus
386: INTEGER,
387: vrRpStatus
388: VrRpTriggerBitCode,
389: vrRouterAddressType
390: InetAddressType,
391: vrRouterAddress
392: InetAddress
393: }
394:
395: vrStatRouteEntries OBJECT-TYPE
396: SYNTAX Unsigned32
397: MAX-ACCESS read-only
398: STATUS current
399: DESCRIPTION
400: "Total number of routes for this VR."
401: ::= { vrStatEntry 1 }
402:
403: vrStatFIBEntries OBJECT-TYPE
404: SYNTAX Unsigned32
405: MAX-ACCESS read-only
406: STATUS current
407: DESCRIPTION
408: "Total number of FIB Entries for this VR."
409: ::= { vrStatEntry 2 }
410:
411: vrStatUpTime OBJECT-TYPE
412: SYNTAX TimeTicks
413: MAX-ACCESS read-only
414: STATUS current
415: DESCRIPTION
416: "The time in (in hundredths of a second) since
417: this VR entry has been operational."
418: ::= { vrStatEntry 3 }
419:
420: vrOperStatus OBJECT-TYPE
421: SYNTAX INTEGER {
422: up(1),
423: down(2),
424: unknown(3)
425: }
426: MAX-ACCESS read-only
427: STATUS current
428: DESCRIPTION
429: "The operational status of the Virtual Router."
430: ::= { vrStatEntry 4 }
431:
432: vrRpStatus OBJECT-TYPE
433: SYNTAX VrRpTriggerBitCode
434: MAX-ACCESS read-only
435: STATUS current
436: DESCRIPTION
437: "This object represents the status of Routing
438: Protocols on this VR corresponding to the list
439: of RP specified in vrRpTrigger.
440:
441: The BITS represent an Action-code that specifies
442: the status of the RPs.
443: The status are: initiated (1) or shutdown (0).
444: Initiated status is indicated when the respective
445: BIT value is 1 and indicates shutdown when the
446: respective BIT value is 0.
447:
448: Bits 0-3 may appear in any combination to
449: indicate that RPs may be enabled and disabled
450: independently or that multiple RP are acted on
451: simultaneously.
452: "
453: ::= { vrStatEntry 5 }
454:
455: vrRouterAddressType OBJECT-TYPE
456: SYNTAX InetAddressType
457: MAX-ACCESS read-only
458: STATUS current
459: DESCRIPTION
460: "Router Address Type of this VR."
461: ::= { vrStatEntry 6 }
462:
463: vrRouterAddress OBJECT-TYPE
464: SYNTAX InetAddress
465: MAX-ACCESS read-only
466: STATUS current
467: DESCRIPTION
468: "Router Address of this VR. It is derived from one of the
469: interfaces. If loopback interface is present, the loopback
470: interface address can be used. However, loopback interface
471: is optional."
472: ::= { vrStatEntry 7 }
473:
474:
475: vrIfConfig OBJECT IDENTIFIER ::= { vrMIBObjects 3 }
476:
477: vrIfConfigScalars OBJECT IDENTIFIER ::= { vrIfConfig 1 }
478:
479: vrIfConfigTable OBJECT-TYPE
480: SYNTAX SEQUENCE OF VrIfConfigEntry
481: MAX-ACCESS not-accessible
482: STATUS current
483: DESCRIPTION
484: "This table is for configuring VR Interfaces."
485: ::= { vrIfConfig 2 }
486:
487: vrIfConfigEntry OBJECT-TYPE
488: SYNTAX VrIfConfigEntry
489: MAX-ACCESS not-accessible
490: STATUS current
491: DESCRIPTION
492: "Entries in this table correspond to the entries in
493: the ifTable that apply to the Virtual Router."
494: INDEX { vrId,
495: vrIfId }
496: ::= { vrIfConfigTable 1 }
497:
498:
499: VrIfConfigEntry ::=
500: SEQUENCE {
501: vrIfId
502: InterfaceIndex,
503: vrIfConfigRowStatus
504: RowStatus
505: }
506:
507: vrIfId OBJECT-TYPE
508: SYNTAX InterfaceIndex
509: MAX-ACCESS not-accessible
510: STATUS current
511: DESCRIPTION
512: "Virtual Router Interface Index."
513: ::= { vrIfConfigEntry 1 }
514:
515: vrIfConfigRowStatus OBJECT-TYPE
516: SYNTAX RowStatus
517: MAX-ACCESS read-create
518: STATUS current
519: DESCRIPTION
520: " This object is used to create, delete or
521: modify a row in this table."
522: ::= { vrIfConfigEntry 2 }
523:
524:
525:
526: -- *******************************************************************
527: -- Module Traps/Notifications
528: -- *******************************************************************
529:
530:
531: vrNotificationsPrefix OBJECT IDENTIFIER ::= { vrMIBObjects 4 }
532:
533: vrNotifications OBJECT IDENTIFIER ::= { vrNotificationsPrefix 0 }
534:
535: vrUp NOTIFICATION-TYPE
536: OBJECTS { vrOperStatus }
537: STATUS current
538: DESCRIPTION
539: "This notification is generated when the specified
540: VR is about to be initialized or change the VR's
541: operational status from down to up."
542: ::= { vrNotifications 1 }
543:
544: vrDown NOTIFICATION-TYPE
545: OBJECTS { vrOperStatus }
546: STATUS current
547: DESCRIPTION
548: "This notification is generated when the specified
549: VR's operational status is about to go down."
550: ::= { vrNotifications 2 }
551:
552: vrMaxRoutesExceeded NOTIFICATION-TYPE
553: OBJECTS { vrRowStatus, vrMaxRoutes, vrStatRouteEntries }
554: STATUS current
555: DESCRIPTION
556: "This notification is generated when the specified VR has
557: exceeded the maximum number of routes specified.
558: "
559: ::= { vrNotifications 3 }
560:
561: -- *******************************************************************
562: -- Module Compliance/Conformance Statements
563: -- *******************************************************************
564:
565: vrConformance OBJECT IDENTIFIER ::= { virtualRouterMIB 2 }
566:
567: vrCompliances OBJECT IDENTIFIER ::= { vrConformance 1 }
568:
569: vrMIBCompliance MODULE-COMPLIANCE
570: STATUS current
571: DESCRIPTION
572: "The compliance statement for entities that implement the
573: VIRTUAL-ROUTER-MIB. Implementation of this MIB module
574: is strongly recommended for any platform targeted for a
575: carrier-class environment.
576: When this MIB module is implemented with support for
577: read-create, then such an implementation can claim full
578: compliance.
579: Such devices can then be both monitored and configured
580: with this MIB."
581: MODULE -- this module
582: MANDATORY-GROUPS { vrConfigGroup, vrStatGroup,
583: vrIfGroup, vrNotificationGroup }
584: ::= { vrCompliances 1 }
585:
586: vrGroups OBJECT IDENTIFIER ::= { vrConformance 2 }
587:
588: vrConfigGroup OBJECT-GROUP
589: OBJECTS { vrRowStatus, vrName,
590: vrContextName, vrTrapEnable,
591: vrMaxRoutes, vrAdminStatus,
592: vrVpnId, vrRpTrigger,
593: vrMaxRoutesTrapEnable,
594: vrConfigNextAvailableVrId }
595: STATUS current
596: DESCRIPTION
597: "A collection of attributes that support provisioning
598: of a virtual router."
599: ::= { vrGroups 1 }
600:
601: vrStatGroup OBJECT-GROUP
602: OBJECTS { vrConfiguredVRs, vrActiveVRs,
603: vrStatRouteEntries, vrStatFIBEntries, vrStatUpTime,
604: vrOperStatus, vrRpStatus, vrRouterAddress,
605: vrRouterAddressType }
606: STATUS current
607: DESCRIPTION
608: "A collection of attributes that contain stats about the
609: virtual router."
610: ::= { vrGroups 2 }
611:
612:
613:
614: vrIfGroup OBJECT-GROUP
615: OBJECTS { vrIfConfigRowStatus }
616: STATUS current
617: DESCRIPTION
618: "A collection of attributes that support provisioning of
619: a virtual router interfaces."
620: ::= { vrGroups 3 }
621:
622: vrNotificationGroup NOTIFICATION-GROUP
623: NOTIFICATIONS { vrUp, vrDown, vrMaxRoutesExceeded }
624: STATUS current
625: DESCRIPTION
626: "A collection of traps that are supported by the VR."
627: ::= { vrGroups 4 }
628:
629: END
630:
631: -- 13.0 IANA Considerations for L3VPN-VR-MIB module
632: --
633: --
634: -- 1.0 Terminology
635: --
636: -- This document uses terminology defined in [PPVPN-FW] and [PPVPN-VR].
637: --
638: -- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
639: -- NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
640: -- "OPTIONAL" in this document are to be interpreted as described in
641: -- RFC 2119, reference [RFC2119].
642: --
643: --
644: -- 2.0 Introduction
645: --
646: -- This memo defines a MIB module for the Virtual Router [PPVPN-VR,
647: -- PPVPN-VR-AS] model of Provider Provisioned VPNs [PPVPN-FW].
648: --
649: -- Following are the goals, in defining this MIB module:
650: --
651: -- - To have a means for Service Providers to provision VPN service for
652: -- subscribers, at the PE device.
653: --
654: -- - To make the agent-side implementation simple, by not modifying the
655: -- existing standard MIB modules.
656: --
657: -- - Define all the gluing tables that are needed toward this end.
658: -- 3.0 The Internet-Standard Management Framework
659: --
660: -- For a detailed overview of the documents that describe the current
661: -- Internet-Standard Management Framework, please refer to section 7 of
662: -- RFC 3410 [RFC3410].
663: --
664: -- Managed objects are accessed via a virtual information store, termed
665: -- the Management Information Base or MIB. MIB module objects are
666: -- generally accessed through the Simple Network Management (SNMP)
667: -- Protocol. Objects in a MIB module are defined using the mechanisms
668: -- defined in the Structure of Management Information (SMI). This memo
669: -- specifies a MIB module that is compliant to the SMIv2, which is
670: -- described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579]
671: -- and STD 58, RFC 2580 [RFC2580].
672: --
673: --
674: -- 4.0 Overview of the Virtual Router MIB Module
675: --
676: --
677: -- 4.1 SNMP Contexts for Management for Virtual Routers
678: --
679: -- There is a need for a single agent to manage multiple Virtual Routers.
680: -- The Architecture for describing SNMP Management Frameworks [RFC3411]
681: -- provides a way to support such cases.
682: --
683: -- Managing multiple virtual routers requires that the PE management
684: -- plane be subdivided into logical VR management domains. In the VR
685: -- model of PPVPNs a single PE device may contain many virtual routers.
686: -- Different management entities SHOULD be able to manage specific
687: -- virtual routers and associated services. The Service Provider MUST be
688: -- able to manage all virtual routers and associated services.
689: --
690: --
691: -- Using SNMP contexts to group a collection of management information
692: -- provides the following benefits:
693: --
694: -- (1) Uses a standard framework defined by the IETF, allowing the
695: -- product to remain flexible to all implementations of virtual
696: -- router devices.
697: --
698: -- (a) Use SNMPv2c Community String's
699: --
700: -- (b) Use SNMPv3 contextName's
701: --
702: -- (2) Prevents vendors from having to modify the standard MIBs,
703: -- allowing the implementation to remain standards compliant.
704: --
705: -- (3) Provides a framework that will work for RIP, OSPF, IS-IS, BGP,
706: -- IP-FORWARDING, MPLS, and any other MIB module that can be
707: -- administratively grouped with a VR.
708: -- The SNMP context for the Virtual Router instance can be specified in
709: -- the VrConfigTable. The VrContextName columnar object is used to set
710: -- the SNMPv2c Community String or the SNMPv3 contextName for a given VR.
711: --
712: -- A virtual router context represents the set of MIB module objects that
713: -- could be administratively grouped within a VR. For example, each VR
714: -- would maintain its own instance of routing protocol MIB module tables.
715: -- However, the ADMIN context would contain single instances of objects
716: -- and tables that pertain to system wide configuration such as the Entity,
717: -- Interfaces, and ATM MIB modules.
718: --
719: -- A management system using the SNMP context of a particular virtual
720: -- router MUST be able to manage the virtual router without disrupting
721: -- other virtual routers in the same PE device.
722: --
723: -- For example, a PE can be subdivided into two 2 VRs running the OSPF
724: -- routing protocol. Each VR will maintain a unique instance of the
725: -- OSPF-MIB. Therefore, the ospfAreaTable of VR-A is distinct from the
726: -- ospfAreaTable of VR-B.
727: --
728: -- +-----------------------------------------------------------------+
729: -- | +------------------------------------------------------------+ |
730: -- | | SNMP entity (including Engine, Applications) | |
731: -- | | | |
732: -- | | example contextNames: | |
733: -- | | | |
734: -- | | "vr01" "vr09" "admin" | |
735: -- | | --------- --------- ------------ | |
736: -- | | | | | | |
737: -- | +------|------------------|-------------------|--------------+ |
737: warning -
warning: note, -- terminates a comment
737: severe -
syntax error, unexpected '|', expecting $end
738: -- | | | | |
739: -- | +------|------------------|-------------------|--------------+ |
740: -- | | MIB | instrumentation | | | |
741: -- | | +---v------------+ +---v------------+ +----v-----------+ | |
742: -- | | | context=vr01 | | context=vr09 | | context=admin | | |
743: -- | | | | | | | | | |
744: -- | | | +------------+ | | +------------+ | | +------------+ | | |
745: -- | | | | OSPF MIB | | | | OSPF MIB | | | | VR MIB | | | |
746: -- | | | +------------+ | | +------------+ | | +------------+ | | |
747: -- | | | | | | | | | |
748: -- | | | +------------+ | | +------------+ | | +------------+ | | |
749: -- | | | | BGP MIB | | | | BGP MIB | | | | ATM MIB | | | |
750: -- | | | +------------+ | | +------------+ | | +------------+ | | |
751: -- | | | | | | | | | |
752: -- | | | +------------+ | | +------------+ | | +------------+ | | |
753: -- | | | | IP MIB | | | | IP MIB | | | | ENTITY MIB | | | |
754: -- | | | +------------+ | | +------------+ | | +------------+ | | |
755: -- | | | | | | | | | |
756: -- | | | +------------+ | | +------------+ | | +------------+ | | |
757: -- | | | | other MIB | | | | other MIB | | | | IF MIB | | | |
758: -- | | | +------------+ | | +------------+ | | +------------+ | | |
759: -- | | | ... | | ... | | ... | | |
760: -- +-----------------------------------------------------------------+
761: -- Filtering mechanisms based on the SNMP context of a particular virtual
762: -- router may implemented to allow different management entities to manage
763: -- those objects and services provisioned the 'Admin' context.
764: --
765: --
766: --
767: -- 4.2 VR Indexing
768: --
769: -- While the standard protocol MIB module tables are instantiated in the
770: -- context specified using SNMP contexts, there may be tables that are
771: -- defined with the VRID as index.
772: --
773: -- The VRID is of local significance to a particular PE device, and need
774: -- not be globally unique. Thus a particular VRID value assigned to a VR
775: -- in one PE device may indicate a different VR in another PE device.
776: --
777: -- The VRID has an Unsigned32 value, and this value is assigned by the
778: -- management station. To aid the management station in assigning a VRID
779: -- without conflict, the management station can get the
780: -- 'NextAvailableVRID' from the PE device.
781: --
782: -- A SNMP manager SHOULD NOT assume global significance of any VRID value
783: -- other than 0.
784: --
785: --
786: -- For those MIB module tables instantiated in the virtual router context,
787: -- indexing can only be assumed unique for that particular VR. However
788: -- those indices in the "ADMIN" context are unique across the entire
789: -- system, including all VRs.
790: --
791: --
792: --
793: -- 4.3 Creation and Deletion of VRs
794: --
795: -- The VR Config Table is used for this purpose. This is a read-create
796: -- table and adding an entry into this table will create a VR. Removing
797: -- an entry from this table marks the deletion of a VR.
798: --
799: -- VRID 0 is assigned to the Administrative VR, which exists by default,
800: -- and need not be created. Deletion of the Administrative VR will not be
801: -- permitted. The VRID of the Administrative VR (VRID 0) should be a
802: -- reserved VRID number. VRID 0 could be termed the "null VR" and it
803: -- could be the context that manages the resource pool of unattached
804: -- interfaces. Routing would then not exist in the context of
805: -- Administrative VR.
806: --
807: --
808: --
809: -- 4.4 Administrative and Operational Status of VRs
810: --
811: -- VRs can be administratively turned down. When this is done, no
812: -- packet forwarding via the VR takes place.
813: --
814: -- VrOperStatus denotes the operational status of a VR. Currently the
815: -- VrOperStatus is expected to change along the VrAdminStatus unless an
816: -- error condition exists.
817: -- 4.4.1 VR Routing Protocol Trigger
818: --
819: -- A construct for independently instantiating routing protocol
820: -- instances for each VR may be useful a solution especially in a PE
821: -- router where scaling of resources would be necessary.
822: --
823: -- VrRpTrigger object represents the Routing Protocol (RP) triggers
824: -- on a VR and is it meant to be used to initiate or shutdown routing
825: -- protocols on a VR.
826: --
827: --
828: -- 4.5 Binding interfaces to a VR
829: --
830: -- Interfaces are bound to a VR, using vrIfConfigTable. This is
831: -- a read-write table, and note that interfaces are not created through
832: -- this table. The vrIfConfigTable MIB module table is used to indicated
833: -- the relationship between interfaces and virtual router IDs. For each
834: -- interface present in the system, this table is used to provide the
835: -- mapping from IfIndex to a unique VR. The table show which interfaces
836: -- are ?attached or connected? to a virtual router. An interface can not
837: -- be attached to more than one VR.
838: --
839: -- The "Admin" VR could be used to manage the resource pool of
840: -- unattached interfaces. However interfaces would not be attached to
841: -- VRID 0.
842: --
843: -- 4.6 Setting per VR limits
844: --
845: -- VRs consume resources on a device, and hence the following parameters
846: -- defined in vrConfigTable are used to specify an upper bound of resource
847: -- utilization:
848: --
849: -- VrMaxRoutes -
850: -- Specify the maximum number of routes that will be permitted in VR. This
851: -- includes all routes, such as the statically configured routes, and the
852: -- routes learnt via dynamic routing protocols.
853: --
854: --
855: -- 4.7 Per VR Statistics
856: --
857: -- In addition to those statistics available through the VR instantiated
858: -- MIB module tables, there are some per-VR statistics available through
859: -- vrStatTable.
860: --
861: -- 4.8 Traps
862: --
863: -- This memo defines that VrUp and VrDown traps are generated just after
864: -- VrOperStatus leaves, or just before it enters, the down state,
865: -- respectively.
866: --
867: -- (1) A transition into the down state will occur when an error is
868: -- detected on a VR instance.
869: --
870: -- (2) Departing the down state generally indicates that the
871: -- VR is going to up, which is considered a "healthy" state.
872: --
873: -- An exception to the above generation of VrUp/VrDown traps on changes
874: -- in VrOperStatus, occurs when an VR is "flapping", i.e., when it is
875: -- rapidly oscillating between the up and down states. If traps were
876: -- generated for each such oscillation, the network and the network
877: -- management system would be flooded with unnecessary traps. In such a
878: -- situation, the agent should limit the rate at which it generates traps.
879: --
880: -- This memo defines that enabling and disabling the VR traps is achieved
881: -- by setting the VrTrapEnable to true(1) or false(2), respectively. By
882: -- default, this object should have the value true(1).
883: -- On some devices where system memory is limited, there may be a need to
884: -- restrict the maximum number of routes allowed on the system. This memo
885: -- defines vrMaxRoutesExceeded trap to indicate when vrStatRouteEntries
886: -- exceeds the maximum limit. There is a danger of notification storms
887: -- with this type of notification. The definition of vrMaxRoutes is such
888: -- that vrStatRouteEntries could never exceed it. So whenever vrMaxRoutes
889: -- has been reached, each new attempt to add a route will cause a new
890: -- Notification. In order to prevent notification storms of this type,
891: -- this memo also defines and the enabling and disabling of this trap
892: -- which is acheived by setting the VrMaxRouteTrapEnable to true(1) or
893: -- false(2), respectively. By default, this object should have the value
894: -- true(1).
895: --
896: --
897: -- 4.9 Usability Considerations
898: -- 4.9.1 Multiple Agents
899: --
900: -- The MIB module is based upon the premise that a single SNMP agent should
901: -- represent every virtual router on a physical router. An alternative
902: -- approach would be to deploy a separate SNMP agent for each virtual
903: -- router. Creating multiple agents for use by the administrator
904: -- (Service Provider) could be done, for instance by binding to different
905: -- ports or addresses on the P-node. However from a resource perspective,
906: -- it is more efficient to use a single agent and multiplex based on the
907: -- community/context as described in this document. In either case,
908: -- though, a VR-MIB module is needed to map each VR to its respective
909: -- agent or context.
910: --
911: -- There could be a case where a separate agent per VR may be useful,
912: -- though not as a replacement for the VR-MIB module. If the platform
913: -- supports instantiation of an agent *within* the VR then the VPN user
914: -- could query stats, etc., from that agent. This would not be a
915: -- replacement for the VR-MIB module because (in addition to the above
916: -- points) the Service Provider may very well not have
917: -- reachability/connectivity (not to mention uniqueness in addressing)
918: -- into the VPN. For example, the Service Provider may not have
919: -- management-network access to the customers' networks.
920: --
921: --
922: -- 4.9.2 Provisioning vs. Monitoring
923: -- The VR-MIB module goes to some length the support configuration using
924: -- SNMP. Other MIB modules tend to be for monitoring purposes, with an
925: -- occasional read-write variable. There is value in having configuration
926: -- capabilities in this MIB module. The VR-MIB module fills in a gap,
927: -- allowing for creation of the VR, while the VR context MIB modules allow
928: -- for configuration of the VR itself. This might prove useful, perhaps
929: -- even allowing for interoperable management tools.
930: --
931: -- Some Service Provider may intend to use it only for monitoring. This
932: -- is because there may be other mechanisms available to them for
933: -- configuration of a specific platforms, such as Corba or XML interfaces
934: -- that they may find more valuable for this function.
935: -- 5.0 Sample VR MIB module Configuration Scenario
936: --
937: -- 5.1 Creation of a VR
938: --
939: -- Creating VR instances can be achieved using the following example.
940: --
941: -- (1) Get the next available Virtual Router Id using the
942: -- NextAvailableVrId, to create a VR:
943: --
944: -- Using a context with 'read' access for system level entities.
945: -- GetRequest { NextAvailableVrId.0 }
946: -- Response { NextAvailableVrId.0 = 5555 }
947: --
948: -- (2) In VrConfigTable, create VR Instance using VrRowStatus:
949: --
950: -- Using a context with 'read-write' access for system level entities
951: -- SetRequest {
952: -- VrRowStatus.5555 createAndGo(4),
953: -- VrName.5555 "BigTelcoVR",
954: -- VrContextName.5555 "vr5555",
955: -- VrTrapEnable.5555 true(1),
956: -- VrAdminStatus.5555 up(1)
957: -- }
958: -- 6.0 Definition of the Virtual Router MIB Module
959: --
960: -- --
961: -- -- VIRTUAL-ROUTER-MIB
962: -- --
963: --
964: --
965: --
966: --
967: -- 7.0 Acknowledgments
968: --
969: -- Funding for the RFC Editor function is currently provided by the
970: -- Internet Society.
971: --
972: -- Special thanks to Joan Cucchiara for providing valuable comments
973: -- on this MIB.
974: --
975: --
976: --
977: -- 8.0 Security Considerations
978: --
979: -- There are a number of management objects defined in this MIB module
980: -- with a MAX-ACCESS clause of read-write and/or read-create. Such
981: -- objects may be considered sensitive or vulnerable in some network
982: -- environments. The support for SET operations in a non-secure
983: -- environment without proper protection can have a negative effect on
984: -- network operations. These are the tables and objects and their
985: -- sensitivity/vulnerability:
986: -- The Administrative VR provides visibility into and control over
987: -- multiple VPNs. As such, security considerations for implementations
988: -- of the Administrative VR and associated control plane(s) are critical
989: -- to the security of the VPNs supported on each PE device.
990: --
991: -- Some of the readable objects in this MIB module (i.e., objects with a
992: -- MAX-ACCESS other than not-accessible) may be considered sensitive or
993: -- vulnerable in some network environments. It is thus important to
994: -- control even GET and/or NOTIFY access to these objects and possibly
995: -- to even encrypt the values of these objects when sending them over
996: -- the network via SNMP. These are the tables and objects and their
997: -- sensitivity/vulnerability:
998: --
999: -- Use of any vrContextName MUST be allowed in the Administrative VR.
1000: -- Additional authentication and security mechanisms SHOULD be used for
1001: -- SNMP access in the Administrative VR.
1002: --
1003: -- VRs other than the Administrative VR MUST NOT have access to other
1004: -- VR's Instantiated MIB modules, and MAY have access to their own
1005: -- instantiated MIB modules.
1006: --
1007: -- In VRs other than the Administrative VR, access to that VR's
1008: -- instantiated MIB modules MAY be permitted via that VR's vrContextName.
1009: -- Use of any vrContextName other than that assigned to the accessed VR
1010: -- MUST result in an error, and implementations SHOULD provide a logging
1011: -- mechanism for such events.
1012: --
1013: -- SNMP versions prior to SNMPv3 did not include adequate security.
1014: -- Even if the network itself is secure (for example by using IPSec),
1015: -- even then, there is no control as to who on the secure network is
1016: -- allowed to access and GET/SET (read/change/create/delete) the objects
1017: -- in this MIB module.
1018: --
1019: -- It is RECOMMENDED that implementers consider the security features as
1020: -- provided by the SNMPv3 framework (see [RFC3410], section 8),
1021: -- including full support for the SNMPv3 cryptographic mechanisms
1022: -- (for authentication and privacy).
1023: --
1024: -- Further, deployment of SNMP versions prior to SNMPv3 is NOT
1025: -- RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
1026: -- enable cryptographic security. It is then a customer/operator
1027: -- responsibility to ensure that the SNMP entity giving access to an
1028: -- instance of this MIB module is properly configured to give access to
1029: -- the objects only to those principals (users) that have legitimate
1030: -- rights to indeed GET or SET (change/create/delete) them.
1031: -- 9.0 References
1032: --
1033: -- 9.1 Normative References
1034: --
1035: -- [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture
1036: -- for Describing SNMP Management Frameworks", RFC 2571, April 1999.
1037: --
1038: -- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1039: -- Requirements Levels", BCP 14, RFC 2119, March 1997.
1040: --
1041: -- [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
1042: -- Rose, M. and S. Waldbusser, "Structure of Management
1043: -- Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1044: -- 1999.
1045: --
1046: -- [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
1047: -- Rose, M. and S. Waldbusser, "Textual Conventions for
1048: -- SMIv2", STD 58, RFC 2579, April 1999.
1049: --
1050: -- [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
1051: -- Rose, M. and S. Waldbusser, "Conformance Statements for
1052: -- SMIv2", STD 58, RFC 2580, April 1999.
1053: --
1054: -- [VPNTCMIB] B. Schliesser, and T. Nadeau, "Definition of Textual
1055: -- Conventions for Provider Provisioned Virtual Private Network
1056: -- (PPVPN) Management.", Internet Draft
1057: -- <draft-ietf-l3vpn-tc-mib-03.txt>, May 2004.
1058: --
1059: --
1060: --
1061: --
1062: -- 9.2 Informative References
1063: --
1064: -- [RFC2685] Fox B., et al, "Virtual Private Networks
1065: -- Identifier", RFC 2685, September 1999.
1066: --
1067: --
1068: -- [PPVPN-FW] R. Callon, et al., "A Framework for Layer 3 Provider
1069: -- Provisioned Virtual Private Networks",
1070: -- draft-ietf-l3vpn-framework-00.txt, March 2003.
1071: --
1072: -- [PPVPN-VR] P. Knight, et al., "Network based IP VPN Architecture
1073: -- using Virtual Routers", draft-ietf-l3vpn-vpn-vr-02.txt,
1074: -- April 2004.
1075: --
1076: -- [PPVPN-VR-AS] A. Nagarajan, et al., "Applicability Statement for
1077: -- Virtual Router-based Layer 3 PPVPN approaches",
1078: -- draft-ietf-l3vpn-as-vr-01.txt, March 2004.
1079: -- 10.0 Authors' Addresses
1080: --
1081: -- Elwin Stelzer Eliazer
1082: -- Corona Networks, Inc.
1083: -- 630 Alder Drive
1084: -- Milpitas, CA 95035
1085: -- USA
1086: -- Phone: +1-408-519-3832
1087: -- Email: elwinietf@yahoo.com
1088: --
1089: -- Samuel Hancock
1090: -- ACM Systems
1091: -- 3034 Gold Canal Drive
1092: -- Rancho Cordova, CA 94123
1093: -- USA
1094: -- Phone: +1-916-463-7949
1095: -- Email: hancoc_s@yahoo.com
1096: --
1097: -- Benson Schliesser
1098: -- SAVVIS Communications
1099: -- 1 Savvis Parkway
1100: -- Town and Country, MO 63017
1101: -- USA
1102: -- Phone: +1-314-628-7036
1103: -- Email: bensons@savvis.net
1104: --
1105: -- Joseph Laria
1106: -- Level Stream Research
1107: -- Wilmington, MA 01887
1108: -- USA
1109: -- Phone: +1-978-223-9908
1110: -- Email: jlaria@levelstream.com
1111: --
1112: --
1113: --
1114: -- 11.0 Intellectual Property Considerations
1115: --
1116: -- The IETF takes no position regarding the validity or scope of any
1117: -- Intellectual Property Rights or other rights that might be claimed
1118: -- to pertain to the implementation or use of the technology described
1119: -- in this document or the extent to which any license under such rights
1120: -- might or might not be available; nor does it represent that it has
1121: -- made any independent effort to identify any such rights. Information
1122: -- on the procedures with respect to rights in RFC documents can be
1123: -- found in BCP 78 and BCP 79.
1124: --
1125: -- Copies of IPR disclosures made to the IETF Secretariat and any
1126: -- assurances of licenses to be made available, or the result of an
1127: -- attempt made to obtain a general license or permission for the use
1128: -- of such proprietary rights by implementers or users of this
1129: -- specification can be obtained from the IETF on-line IPR repository
1130: -- at http://www.ietf.org/ipr.
1131: --
1132: -- The IETF invites any interested party to bring to its attention any
1133: -- copyrights, patents or patent applications, or other proprietary
1134: -- rights that may cover technology that may be required to implement
1135: -- this standard. Please address the information to the IETF at
1136: -- ietf-ipr@ietf.org.
1137: -- 12.0 Full Copyright Statement
1138: --
1139: -- Copyright (C) The Internet Society (2005).
1140: --
1141: -- This document is subject to the rights, licenses and restrictions
1142: -- contained in BCP 78, and except as set forth therein, the authors
1143: -- retain all their rights.
1144: --
1145: -- This document and the information contained herein are provided on
1146: -- an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
1147: -- REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
1148: -- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1149: -- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
1150: -- OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1151: -- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1152: --
1153: --
1154: -- 13.0 IANA Considerations for L3VPN-VR-MIB Module
1155: --
1156: -- The IANA is requested to assign { mib-2 XXXX } to the
1157: -- L3VPN-VR-MIB module specified in this document.
1158: