idnits 2.17.1 draft-ietf-rip-mib-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 533: '... interface, this MUST be the same valu...' -- The draft header indicates that this document obsoletes RFC1724, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 520 has weird spacing: '...lid has the ...' == Line 601 has weird spacing: '...n field in R...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2001) is 8406 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 738, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 741, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 749, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 753, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 758, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 776, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 781, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 784, but no explicit reference was found in the text ** Downref: Normative reference to an Unknown state RFC: RFC 1052 (ref. '1') ** Downref: Normative reference to an Unknown state RFC: RFC 1109 (ref. '2') ** Downref: Normative reference to an Historic RFC: RFC 1156 (ref. '4') ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '5') ** Obsolete normative reference: RFC 1158 (ref. '6') (Obsoleted by RFC 1213) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Downref: Normative reference to an Informational RFC: RFC 1721 (ref. '11') Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft G. Malkin 2 draft-ietf-rip-mib-01.txt Nortel Networks 3 Obsoletes: 1724 F. Baker 4 Category: Standards Track Cisco Systems 5 April 2001 7 RIP Version 2 MIB Extension 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This memo defines a portion of the Management Information Base (MIB) 33 for use with network management protocols in TCP/IP-based internets. 34 In particular, it defines objects for managing RIP Version 2. 36 Acknowledgements 38 The authors would like to thank the IETF ripv2 Working Group for 39 their help in improving the RIP-2 MIB extension. 41 Table of Contents 43 1. The Network Management Framework ...................... 2 44 2. Objects ............................................... 2 45 2.1 Format of Definitions ................................ 3 46 3. Overview .............................................. 3 47 3.1 Textual Conventions .................................. 3 48 3.2 Structure of MIB ..................................... 3 49 3.3 Modifications from RFC 1389 .......................... 3 50 4. Definitions ........................................... 5 51 4.1 Global Counters ...................................... 6 52 4.2 RIP Interface Tables ................................. 6 53 4.3 Peer Table ........................................... 12 55 Malkin & Baker Expires: 23Oct01 1 56 5. References ............................................ 17 57 6. Security Considerations ............................... 18 58 7. Authors' Addresses .................................... 18 60 Malkin & Baker Expires: 23Oct01 2 61 1. The Network Management Framework 63 The Internet-standard Network Management Framework consists of three 64 components. They are: 66 STD 16/RFC 1155 which defines the SMI, the mechanisms used for 67 describing and naming objects for the purpose of management. 69 STD 16/RFC 1212 defines a more concise description mechanism, 70 which is wholly consistent with the SMI. 72 RFC 1156 which defines MIB-I, the core set of managed objects for 73 the Internet suite of protocols. STD 17/RFC 1213 defines MIB- 74 II, an evolution of MIB-I based on implementation experience 75 and new operational requirements. 77 STD 15/RFC 1157 which defines the SNMP, the protocol used for 78 network access to managed objects. 80 The Framework permits new objects to be defined for the purpose of 81 experimentation and evaluation. 83 2. Objects 85 Managed objects are accessed via a virtual information store, termed 86 the Management Information Base or MIB. Objects in the MIB are 87 defined using the subset of Abstract Syntax Notation One (ASN.1) [7] 88 defined in the SMI. In particular, each object has a name, a syntax, 89 and an encoding. The name is an object identifier, an 90 administratively assigned name, which specifies an object type. The 91 object type together with an object instance serves to uniquely 92 identify a specific instantiation of the object. For human 93 convenience, we often use a textual string, termed the OBJECT 94 DESCRIPTOR, to also refer to the object type. 96 The syntax of an object type defines the abstract data structure 97 corresponding to that object type. The ASN.1 language is used for 98 this purpose. However, the SMI [3] purposely restricts the ASN.1 99 constructs which may be used. These restrictions are explicitly made 100 for simplicity. 102 The encoding of an object type is simply how that object type is 103 represented using the object type's syntax. Implicitly tied to the 104 notion of an object type's syntax and encoding is how the object type 105 is represented when being transmitted on the network. 107 The SMI specifies the use of the basic encoding rules of ASN.1 [8], 108 subject to the additional requirements imposed by the SNMP. 110 Malkin & Baker Expires: 23Oct01 3 111 2.1 Format of Definitions 113 Section 4 contains the specification of all object types contained in 114 this MIB module. The object types are defined using the conventions 115 defined in the SMI, as amended by the extensions specified in [9]. 117 3. Overview 119 3.1 Textual Conventions 121 Several new data types are introduced as a textual convention in this 122 MIB document. These textual conventions enhance the readability of 123 the specification and can ease comparison with other specifications 124 if appropriate. It should be noted that the introduction of the 125 these textual conventions has no effect on either the syntax nor the 126 semantics of any managed objects. The use of these is merely an 127 artifact of the explanatory method used. Objects defined in terms of 128 one of these methods are always encoded by means of the rules that 129 define the primitive type. Hence, no changes to the SMI or the SNMP 130 are necessary to accommodate these textual conventions which are 131 adopted merely for the convenience of readers and writers in pursuit 132 of the elusive goal of clear, concise, and unambiguous MIB documents. 134 The new data type is RouteTag. The RouteTag type represents the 135 contents of the Route Domain field in the packet header or route 136 entry. 138 3.2 Structure of MIB 140 The RIP-2 MIB contains global counters, useful for detecting the 141 deleterious effects of RIP incompatibilities; two "interfaces" 142 tables, which contains interface-specific statistics and 143 configuration information; and an optional "peer" table, containing 144 information that may be helpful in debugging neighbor relationships. 145 Like the protocol itself, this MIB takes great care to preserve 146 compatibility with RIP-1 systems and controls for monitoring and 147 controlling system interactions. 149 3.3 Modifications from RFC 1389 151 The RIP-2 MIB was originally published in RFC 1389. It encoded the 152 concept of a Routing Domain, and did not address unnumbered 153 interfaces. 155 In the current version of the protocol, Route Domains are deprecated; 156 therefore, they are deprecated in the MIB as well. This means that 157 the object rip2IfConfDomain is deprecated, and the object 158 rip2PeerDomain (which cannot be deprecated, being an instance object) 160 Malkin & Baker Expires: 23Oct01 4 161 must always be zero. 163 Unnumbered interfaces are supported in this version. Since the IP 164 Address that the neighbor uses may be unknown to the system, a 165 pseudo-address is used to identify these interfaces. The pseudo- 166 address is in the class A network 0.0.0.0, and the host number (the 167 least significant 24 bits of the address) are the ifIndex value of 168 the relevant IP Interface. This is an additional new meaning of the 169 objects rip2IfStatAddress and rip2IfConfAddress, backward compatible 170 with the RFC 1389 usage. The object rip2IfConfSrcAddress is added, 171 to permit the configuration of the source address on an unnumbered 172 interface, and the meaning of the object rip2PeerAddress is broadened 173 to remain relevant on unnumbered interfaces. 175 rip2IfConfSend is augmented with two values for the use of Demand RIP 176 under RIP-I and RIP-II rules. This avoids the necessity of a Demand 177 RIP MIB. 179 MD5 Authentication is supported. 181 Malkin & Baker Expires: 23Oct01 5 182 4. Definitions 184 RIPv2-MIB DEFINITIONS ::= BEGIN 186 IMPORTS 187 MODULE-IDENTITY, OBJECT-TYPE, Counter32, 188 TimeTicks, IpAddress FROM SNMPv2-SMI 189 TEXTUAL-CONVENTION, RowStatus FROM SNMPv2-TC 190 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 191 mib-2 FROM RFC1213-MIB; 193 -- This MIB module uses the extended OBJECT-TYPE macro as 194 -- defined in [9]. 196 rip2 MODULE-IDENTITY 197 LAST-UPDATED "9407272253Z" -- Wed Jul 27 22:53:04 PDT 1994 198 ORGANIZATION "IETF RIP-II Working Group" 199 CONTACT-INFO 200 " Fred Baker 201 Postal: Cisco Systems 202 519 Lado Drive 203 Santa Barbara, California 93111 204 Tel: +1 805 681 0115 205 E-Mail: fbaker@cisco.com 207 Postal: Gary Malkin 208 Nortel Networks 209 600 Technology Park 210 Billerica, MA 01821 212 Phone: +1 978 288 3634 213 EMail: gmalkin@nortelnetworks.com" 214 DESCRIPTION 215 "The MIB module to describe the RIP Version 2 Protocol" 216 ::= { mib-2 23 } 218 -- RIP-2 Management Information Base 220 -- the RouteTag type represents the contents of the 221 -- Route Domain field in the packet header or route entry. 222 -- The use of the Route Domain is deprecated. 224 RouteTag ::= TEXTUAL-CONVENTION 225 STATUS current 226 DESCRIPTION 227 "the RouteTag type represents the contents of the Route Domain 228 field in the packet header or route entry" 229 SYNTAX OCTET STRING (SIZE (2)) 231 Malkin & Baker Expires: 23Oct01 6 232 --4.1 Global Counters 234 -- The RIP-2 Globals Group. 235 -- Implementation of this group is mandatory for systems 236 -- which implement RIP-2. 238 -- These counters are intended to facilitate debugging quickly 239 -- changing routes or failing neighbors 241 rip2Globals OBJECT IDENTIFIER ::= { rip2 1 } 243 rip2GlobalRouteChanges OBJECT-TYPE 244 SYNTAX Counter32 245 MAX-ACCESS read-only 246 STATUS current 247 DESCRIPTION 248 "The number of route changes made to the IP Route 249 Database by RIP. This does not include the refresh 250 of a route's age." 251 ::= { rip2Globals 1 } 253 rip2GlobalQueries OBJECT-TYPE 254 SYNTAX Counter32 255 MAX-ACCESS read-only 256 STATUS current 257 DESCRIPTION 258 "The number of responses sent to RIP queries 259 from other systems." 260 ::= { rip2Globals 2 } 262 --4.2 RIP Interface Tables 264 -- RIP Interfaces Groups 265 -- Implementation of these Groups is mandatory for systems 266 -- which implement RIP-2. 268 -- The RIP Interface Status Table. 270 rip2IfStatTable OBJECT-TYPE 271 SYNTAX SEQUENCE OF Rip2IfStatEntry 272 MAX-ACCESS not-accessible 273 STATUS current 274 DESCRIPTION 275 "A list of subnets which require separate 276 status monitoring in RIP." 277 ::= { rip2 2 } 279 Malkin & Baker Expires: 23Oct01 7 280 rip2IfStatEntry OBJECT-TYPE 281 SYNTAX Rip2IfStatEntry 282 MAX-ACCESS not-accessible 283 STATUS current 284 DESCRIPTION 285 "A Single Routing Domain in a single Subnet." 286 INDEX { rip2IfStatAddress } 287 ::= { rip2IfStatTable 1 } 289 Rip2IfStatEntry ::= 290 SEQUENCE { 291 rip2IfStatAddress 292 IpAddress, 293 rip2IfStatRcvBadPackets 294 Counter32, 295 rip2IfStatRcvBadRoutes 296 Counter32, 297 rip2IfStatSentUpdates 298 Counter32, 299 rip2IfStatStatus 300 RowStatus 301 } 303 rip2IfStatAddress OBJECT-TYPE 304 SYNTAX IpAddress 305 MAX-ACCESS read-only 306 STATUS current 307 DESCRIPTION 308 "The IP Address of this system on the indicated 309 subnet. For unnumbered interfaces, the value 0.0.0.N, 310 where the least significant 24 bits (N) is the ifIndex 311 for the IP Interface in network byte order." 312 ::= { rip2IfStatEntry 1 } 314 rip2IfStatRcvBadPackets OBJECT-TYPE 315 SYNTAX Counter32 316 MAX-ACCESS read-only 317 STATUS current 318 DESCRIPTION 319 "The number of RIP response packets received by 320 the RIP process which were subsequently discarded 321 for any reason (e.g. a version 0 packet, or an 322 unknown command type)." 323 ::= { rip2IfStatEntry 2 } 325 rip2IfStatRcvBadRoutes OBJECT-TYPE 326 SYNTAX Counter32 327 MAX-ACCESS read-only 329 Malkin & Baker Expires: 23Oct01 8 330 STATUS current 331 DESCRIPTION 332 "The number of routes, in valid RIP packets, 333 which were ignored for any reason (e.g. unknown 334 address family, or invalid metric)." 335 ::= { rip2IfStatEntry 3 } 337 rip2IfStatSentUpdates OBJECT-TYPE 338 SYNTAX Counter32 339 MAX-ACCESS read-only 340 STATUS current 341 DESCRIPTION 342 "The number of triggered RIP updates actually 343 sent on this interface. This explicitly does 344 NOT include full updates sent containing new 345 information." 346 ::= { rip2IfStatEntry 4 } 348 rip2IfStatStatus OBJECT-TYPE 349 SYNTAX RowStatus 350 MAX-ACCESS read-create 351 STATUS current 352 DESCRIPTION 353 "Writing invalid has the effect of deleting 354 this interface." 355 ::= { rip2IfStatEntry 5 } 357 -- The RIP Interface Configuration Table. 359 rip2IfConfTable OBJECT-TYPE 360 SYNTAX SEQUENCE OF Rip2IfConfEntry 361 MAX-ACCESS not-accessible 362 STATUS current 363 DESCRIPTION 364 "A list of subnets which require separate 365 configuration in RIP." 366 ::= { rip2 3 } 368 rip2IfConfEntry OBJECT-TYPE 369 SYNTAX Rip2IfConfEntry 370 MAX-ACCESS not-accessible 371 STATUS current 372 DESCRIPTION 373 "A Single Routing Domain in a single Subnet." 374 INDEX { rip2IfConfAddress } 375 ::= { rip2IfConfTable 1 } 377 Rip2IfConfEntry ::= 379 Malkin & Baker Expires: 23Oct01 9 380 SEQUENCE { 381 rip2IfConfAddress 382 IpAddress, 383 rip2IfConfDomain 384 RouteTag, 385 rip2IfConfAuthType 386 INTEGER, 387 rip2IfConfAuthKey 388 OCTET STRING (SIZE(0..16)), 389 rip2IfConfSend 390 INTEGER, 391 rip2IfConfReceive 392 INTEGER, 393 rip2IfConfDefaultMetric 394 INTEGER, 395 rip2IfConfStatus 396 RowStatus, 397 rip2IfConfSrcAddress 398 IpAddress 399 } 401 rip2IfConfAddress OBJECT-TYPE 402 SYNTAX IpAddress 403 MAX-ACCESS read-only 404 STATUS current 405 DESCRIPTION 406 "The IP Address of this system on the indicated 407 subnet. For unnumbered interfaces, the value 0.0.0.N, 408 where the least significant 24 bits (N) is the ifIndex 409 for the IP Interface in network byte order." 410 ::= { rip2IfConfEntry 1 } 412 rip2IfConfDomain OBJECT-TYPE 413 SYNTAX RouteTag 414 MAX-ACCESS read-create 415 STATUS obsolete 416 DESCRIPTION 417 "Value inserted into the Routing Domain field 418 of all RIP packets sent on this interface." 419 DEFVAL { '0000'h } 420 ::= { rip2IfConfEntry 2 } 422 rip2IfConfAuthType OBJECT-TYPE 423 SYNTAX INTEGER { 424 noAuthentication (1), 425 simplePassword (2), 426 md5 (3) 427 } 429 Malkin & Baker Expires: 23Oct01 10 430 MAX-ACCESS read-create 431 STATUS current 432 DESCRIPTION 433 "The type of Authentication used on this 434 interface." 435 DEFVAL { noAuthentication } 436 ::= { rip2IfConfEntry 3 } 438 rip2IfConfAuthKey OBJECT-TYPE 439 SYNTAX OCTET STRING (SIZE(0..16)) 440 MAX-ACCESS read-create 441 STATUS current 442 DESCRIPTION 443 "The value to be used as the Authentication Key 444 whenever the corresponding instance of 445 rip2IfConfAuthType has a value other than 446 noAuthentication. A modification of the corresponding 447 instance of rip2IfConfAuthType does not modify 448 the rip2IfConfAuthKey value. If a string shorter 449 than 16 octets is supplied, it will be left- 450 justified and padded to 16 octets, on the right, 451 with nulls (0x00). 453 Reading this object always results in an OCTET 454 STRING of length zero; authentication may not 455 be bypassed by reading the MIB object." 456 DEFVAL { ''h } 457 ::= { rip2IfConfEntry 4 } 459 rip2IfConfSend OBJECT-TYPE 460 SYNTAX INTEGER { 461 doNotSend (1), 462 ripVersion1 (2), 463 rip1Compatible (3), 464 ripVersion2 (4), 465 ripV1Demand (5), 466 ripV2Demand (6) 467 } 468 MAX-ACCESS read-create 469 STATUS current 470 DESCRIPTION 471 "What the router sends on this interface. 472 ripVersion1 implies sending RIP updates compliant 473 with RFC 1058. rip1Compatible implies 474 broadcasting RIP-2 updates using RFC 1058 route 475 subsumption rules. ripVersion2 implies 476 multicasting RIP-2 updates. ripV1Demand indicates 477 the use of Demand RIP on a WAN interface under RIP 479 Malkin & Baker Expires: 23Oct01 11 480 Version 1 rules. ripV2Demand indicates the use of 481 Demand RIP on a WAN interface under Version 2 rules." 482 DEFVAL { ripVersion2 } 483 ::= { rip2IfConfEntry 5 } 485 rip2IfConfReceive OBJECT-TYPE 486 SYNTAX INTEGER { 487 rip1 (1), 488 rip2 (2), 489 rip1OrRip2 (3), 490 doNotReceive (4) 491 } 492 MAX-ACCESS read-create 493 STATUS current 494 DESCRIPTION 495 "This indicates which version of RIP updates 496 are to be accepted. Note that rip2 and 497 rip1OrRip2 implies reception of multicast, 498 in addition to broadcast, packets." 499 DEFVAL { rip1OrRip2 } 500 ::= { rip2IfConfEntry 6 } 502 rip2IfConfDefaultMetric OBJECT-TYPE 503 SYNTAX INTEGER ( 0..15 ) 504 MAX-ACCESS read-create 505 STATUS current 506 DESCRIPTION 507 "This variable indicates the metric that is to 508 be used for the default route entry in RIP updates 509 originated on this interface. A value of zero 510 indicates that no default route should be 511 originated; in this case, a default route via 512 another router may be propagated." 513 ::= { rip2IfConfEntry 7 } 515 rip2IfConfStatus OBJECT-TYPE 516 SYNTAX RowStatus 517 MAX-ACCESS read-create 518 STATUS current 519 DESCRIPTION 520 "Writing invalid has the effect of deleting 521 this interface." 522 ::= { rip2IfConfEntry 8 } 524 rip2IfConfSrcAddress OBJECT-TYPE 525 SYNTAX IpAddress 526 MAX-ACCESS read-create 527 STATUS current 529 Malkin & Baker Expires: 23Oct01 12 530 DESCRIPTION 531 "The IP Address this system will use as a source 532 address on this interface. If it is a numbered 533 interface, this MUST be the same value as 534 rip2IfConfAddress. On unnumbered interfaces, 535 it must be the value of rip2IfConfAddress for 536 some interface on the system." 537 ::= { rip2IfConfEntry 9 } 539 --4.3 Peer Table 541 -- Peer Table 543 -- The RIP Peer Group 544 -- Implementation of this Group is Optional 546 -- This group provides information about active peer 547 -- relationships intended to assist in debugging. An 548 -- active peer is a router from which a valid RIP 549 -- updated has been heard in the last 180 seconds. 551 rip2PeerTable OBJECT-TYPE 552 SYNTAX SEQUENCE OF Rip2PeerEntry 553 MAX-ACCESS not-accessible 554 STATUS current 555 DESCRIPTION 556 "A list of RIP Peers." 557 ::= { rip2 4 } 559 rip2PeerEntry OBJECT-TYPE 560 SYNTAX Rip2PeerEntry 561 MAX-ACCESS not-accessible 562 STATUS current 563 DESCRIPTION 564 "Information regarding a single routing peer." 565 INDEX { rip2PeerAddress, rip2PeerDomain } 566 ::= { rip2PeerTable 1 } 568 Rip2PeerEntry ::= 569 SEQUENCE { 570 rip2PeerAddress 571 IpAddress, 572 rip2PeerDomain 573 RouteTag, 574 rip2PeerLastUpdate 575 TimeTicks, 576 rip2PeerVersion 577 INTEGER, 579 Malkin & Baker Expires: 23Oct01 13 580 rip2PeerRcvBadPackets 581 Counter32, 582 rip2PeerRcvBadRoutes 583 Counter32 584 } 586 rip2PeerAddress OBJECT-TYPE 587 SYNTAX IpAddress 588 MAX-ACCESS read-only 589 STATUS current 590 DESCRIPTION 591 "The IP Address that the peer is using as its source 592 address. Note that on an unnumbered link, this may 593 not be a member of any subnet on the system." 594 ::= { rip2PeerEntry 1 } 596 rip2PeerDomain OBJECT-TYPE 597 SYNTAX RouteTag 598 MAX-ACCESS read-only 599 STATUS current 600 DESCRIPTION 601 "The value in the Routing Domain field in RIP 602 packets received from the peer. As domain suuport 603 is deprecated, this must be zero." 604 ::= { rip2PeerEntry 2 } 606 rip2PeerLastUpdate OBJECT-TYPE 607 SYNTAX TimeTicks 608 MAX-ACCESS read-only 609 STATUS current 610 DESCRIPTION 611 "The value of sysUpTime when the most recent 612 RIP update was received from this system." 613 ::= { rip2PeerEntry 3 } 615 rip2PeerVersion OBJECT-TYPE 616 SYNTAX INTEGER ( 0..255 ) 617 MAX-ACCESS read-only 618 STATUS current 619 DESCRIPTION 620 "The RIP version number in the header of the 621 last RIP packet received." 622 ::= { rip2PeerEntry 4 } 624 rip2PeerRcvBadPackets OBJECT-TYPE 625 SYNTAX Counter32 626 MAX-ACCESS read-only 627 STATUS current 629 Malkin & Baker Expires: 23Oct01 14 630 DESCRIPTION 631 "The number of RIP response packets from this 632 peer discarded as invalid." 633 ::= { rip2PeerEntry 5 } 635 rip2PeerRcvBadRoutes OBJECT-TYPE 636 SYNTAX Counter32 637 MAX-ACCESS read-only 638 STATUS current 639 DESCRIPTION 640 "The number of routes from this peer that were 641 ignored because the entry format was invalid." 642 ::= { rip2PeerEntry 6 } 644 Malkin & Baker Expires: 23Oct01 15 645 -- conformance information 647 rip2Conformance OBJECT IDENTIFIER ::= { rip2 5 } 649 rip2Groups OBJECT IDENTIFIER ::= { rip2Conformance 1 } 650 rip2Compliances OBJECT IDENTIFIER ::= { rip2Conformance 2 } 652 -- compliance statements 653 rip2Compliance MODULE-COMPLIANCE 654 STATUS current 655 DESCRIPTION 656 "The compliance statement " 657 MODULE -- this module 658 MANDATORY-GROUPS { 659 rip2GlobalGroup, 660 rip2IfStatGroup, 661 rip2IfConfGroup, 662 rip2PeerGroup 663 } 664 GROUP rip2GlobalGroup 665 DESCRIPTION 666 "This group defines global controls for RIP-II systems." 667 GROUP rip2IfStatGroup 668 DESCRIPTION 669 "This group defines interface statistics for RIP-II systems." 670 GROUP rip2IfConfGroup 671 DESCRIPTION 672 "This group defines interface configuration for RIP-II 673 systems." 674 GROUP rip2PeerGroup 675 DESCRIPTION 676 "This group defines peer information for RIP-II systems." 677 ::= { rip2Compliances 1 } 679 Malkin & Baker Expires: 23Oct01 16 680 -- units of conformance 682 rip2GlobalGroup OBJECT-GROUP 683 OBJECTS { 684 rip2GlobalRouteChanges, 685 rip2GlobalQueries 686 } 687 STATUS current 688 DESCRIPTION 689 "This group defines global controls for RIP-II systems." 690 ::= { rip2Groups 1 } 691 rip2IfStatGroup OBJECT-GROUP 692 OBJECTS { 693 rip2IfStatAddress, 694 rip2IfStatRcvBadPackets, 695 rip2IfStatRcvBadRoutes, 696 rip2IfStatSentUpdates, 697 rip2IfStatStatus 698 } 699 STATUS current 700 DESCRIPTION 701 "This group defines interface statistics for RIP-II systems." 702 ::= { rip2Groups 2 } 703 rip2IfConfGroup OBJECT-GROUP 704 OBJECTS { 705 rip2IfConfAddress, 706 rip2IfConfAuthType, 707 rip2IfConfAuthKey, 708 rip2IfConfSend, 709 rip2IfConfReceive, 710 rip2IfConfDefaultMetric, 711 rip2IfConfStatus, 712 rip2IfConfSrcAddress 713 } 714 STATUS current 715 DESCRIPTION 716 "This group defines interface configuration for RIP-II 717 systems." 718 ::= { rip2Groups 3 } 719 rip2PeerGroup OBJECT-GROUP 720 OBJECTS { 721 rip2PeerAddress, 722 rip2PeerDomain, 723 rip2PeerLastUpdate, 724 rip2PeerVersion, 725 rip2PeerRcvBadPackets, 726 rip2PeerRcvBadRoutes 727 } 729 Malkin & Baker Expires: 23Oct01 17 730 STATUS current 731 DESCRIPTION 732 "This group defines peer information for RIP-II systems." 733 ::= { rip2Groups 4 } 734 END 736 5. References 738 [1] Cerf, V., "IAB Recommendations for the Development of Internet 739 Network Management Standards", RFC 1052, IAB, April 1988. 741 [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review 742 Group", RFC 1109, IAB, August 1989. 744 [3] Rose M., and K. McCloghrie, "Structure and Identification of 745 Management Information for TCP/IP-based internets", STD 16, RFC 746 1155, Performance Systems International, Hughes LAN Systems, May 747 1990. 749 [4] McCloghrie K., and M. Rose, "Management Information Base for 750 Network Management of TCP/IP-based internets", RFC 1156, Hughes 751 LAN Systems, Performance Systems International, May 1990. 753 [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 754 Network Management Protocol", STD 15, RFC 1157, SNMP Research, 755 Performance Systems International, Performance Systems 756 International, MIT Laboratory for Computer Science, May 1990. 758 [6] Rose, M., Editor, "Management Information Base for Network 759 Management of TCP/IP-based internets: MIB-II", RFC 1158, 760 Performance Systems International, May 1990. 762 [7] Information processing systems - Open Systems Interconnection - 763 Specification of Abstract Syntax Notation One (ASN.1), 764 International Organization for Standardization, International 765 Standard 8824, December 1987. 767 [8] Information processing systems - Open Systems Interconnection - 768 Specification of Basic Encoding Rules for Abstract Notation One 769 (ASN.1), International Organization for Standardization, 770 International Standard 8825, December 1987. 772 [9] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", 773 STD 16, RFC 1212, Performance Systems International, Hughes LAN 774 Systems, March 1991. 776 [10] Malkin, G., "RIP Version 2 - Carrying Additional Information", 777 RFC 2453, Bay Networks, November 1998. 779 Malkin & Baker Expires: 23Oct01 18 781 [11] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1721, 782 Xylogics, Inc., November 1994. 784 [12] Malkin, G., "RIP Version 2 Protocol Applicability Statement", RFC 785 1722, Xylogics, Inc., November 1994. 787 6. Security Considerations 789 Security issues are not discussed in this memo. See the most recent 790 SNMP RFCs for security considerations. 792 7. Authors' Addresses 794 Gary Malkin 795 Nortel Networks 796 600 Technology Park 797 Billerica, MA 01821 799 Phone: 978-288-3634 800 EMail: gmalkin@nortelnetworks.com 802 Fred Baker 803 Cisco Systems 804 519 Lado Drive 805 Santa Barbara, California 93111 807 Phone: 805-681-0115 808 EMail: fred@cisco.com 810 Malkin & Baker Expires: 23Oct01 19