idnits 2.17.1 draft-ietf-rip-mib-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. 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. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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 518: '... 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 507 has weird spacing: '...lid has the ...' == Line 585 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 (March 1997) is 9903 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 714, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 717, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 725, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 729, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 734, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 752, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 755, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 758, 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' ** Obsolete normative reference: RFC 1723 (ref. '10') (Obsoleted by RFC 2453) ** Downref: Normative reference to an Informational RFC: RFC 1721 (ref. '11') Summary: 17 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft G. Malkin 3 draft-ietf-rip-mib-00.txt Xylogics, Inc. 4 Obsoletes: 1724 F. Baker 5 Category: Standards Track Cisco Systems 6 March 1997 8 RIP Version 2 MIB Extension 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a "working 21 draft" or "work in progress." 23 Please check the I-D abstract listing contained in each Internet 24 Draft directory to learn the current status of this or any other 25 Internet Draft. 27 It is intended that this document will be submitted to the IESG for 28 consideration as a standards document. Distribution of this document 29 is unlimited. 31 Abstract 33 This memo defines a portion of the Management Information Base (MIB) 34 for use with network management protocols in TCP/IP-based internets. 35 In particular, it defines objects for managing RIP Version 2. 37 Acknowledgements 39 The authors would like to thank the IETF ripv2 Working Group for 40 their help in improving the RIP-2 MIB extension. 42 Table of Contents 44 1. The Network Management Framework ...................... 2 45 2. Objects ............................................... 2 46 2.1 Format of Definitions ................................ 3 47 3. Overview .............................................. 3 48 3.1 Textual Conventions .................................. 3 49 3.2 Structure of MIB ..................................... 3 50 3.3 Modifications from RFC 1389 .......................... 3 51 4. Definitions ........................................... 5 52 4.1 Global Counters ...................................... 6 53 4.2 RIP Interface Tables ................................. 6 54 4.3 Peer Table ........................................... 12 55 5. References ............................................ 17 56 6. Security Considerations ............................... 18 57 7. Authors' Addresses .................................... 18 59 1. The Network Management Framework 61 The Internet-standard Network Management Framework consists of three 62 components. They are: 64 STD 16/RFC 1155 which defines the SMI, the mechanisms used for 65 describing and naming objects for the purpose of management. 67 STD 16/RFC 1212 defines a more concise description mechanism, 68 which is wholly consistent with the SMI. 70 RFC 1156 which defines MIB-I, the core set of managed objects for 71 the Internet suite of protocols. STD 17/RFC 1213 defines MIB- 72 II, an evolution of MIB-I based on implementation experience 73 and new operational requirements. 75 STD 15/RFC 1157 which defines the SNMP, the protocol used for 76 network access to managed objects. 78 The Framework permits new objects to be defined for the purpose of 79 experimentation and evaluation. 81 2. Objects 83 Managed objects are accessed via a virtual information store, termed 84 the Management Information Base or MIB. Objects in the MIB are 85 defined using the subset of Abstract Syntax Notation One (ASN.1) [7] 86 defined in the SMI. In particular, each object has a name, a syntax, 87 and an encoding. The name is an object identifier, an 88 administratively assigned name, which specifies an object type. The 89 object type together with an object instance serves to uniquely 90 identify a specific instantiation of the object. For human 91 convenience, we often use a textual string, termed the OBJECT 92 DESCRIPTOR, to also refer to the object type. 94 The syntax of an object type defines the abstract data structure 95 corresponding to that object type. The ASN.1 language is used for 96 this purpose. However, the SMI [3] purposely restricts the ASN.1 97 constructs which may be used. These restrictions are explicitly made 98 for simplicity. 100 The encoding of an object type is simply how that object type is 101 represented using the object type's syntax. Implicitly tied to the 102 notion of an object type's syntax and encoding is how the object type 103 is represented when being transmitted on the network. 105 The SMI specifies the use of the basic encoding rules of ASN.1 [8], 106 subject to the additional requirements imposed by the SNMP. 108 2.1 Format of Definitions 110 Section 4 contains the specification of all object types contained in 111 this MIB module. The object types are defined using the conventions 112 defined in the SMI, as amended by the extensions specified in [9]. 114 3. Overview 116 3.1 Textual Conventions 118 Several new data types are introduced as a textual convention in this 119 MIB document. These textual conventions enhance the readability of 120 the specification and can ease comparison with other specifications 121 if appropriate. It should be noted that the introduction of the 122 these textual conventions has no effect on either the syntax nor the 123 semantics of any managed objects. The use of these is merely an 124 artifact of the explanatory method used. Objects defined in terms of 125 one of these methods are always encoded by means of the rules that 126 define the primitive type. Hence, no changes to the SMI or the SNMP 127 are necessary to accommodate these textual conventions which are 128 adopted merely for the convenience of readers and writers in pursuit 129 of the elusive goal of clear, concise, and unambiguous MIB documents. 131 The new data type is RouteTag. The RouteTag type represents the 132 contents of the Route Domain field in the packet header or route 133 entry. 135 3.2 Structure of MIB 137 The RIP-2 MIB contains global counters, useful for detecting the 138 deleterious effects of RIP incompatibilities; two "interfaces" 139 tables, which contains interface-specific statistics and 140 configuration information; and an optional "peer" table, containing 141 information that may be helpful in debugging neighbor relationships. 142 Like the protocol itself, this MIB takes great care to preserve 143 compatibility with RIP-1 systems and controls for monitoring and 144 controlling system interactions. 146 3.3 Modifications from RFC 1389 148 The RIP-2 MIB was originally published in RFC 1389. It encoded the 149 concept of a Routing Domain, and did not address unnumbered 150 interfaces. 152 In the current version of the protocol, Route Domains are deprecated; 153 therefore, they are deprecated in the MIB as well. This means that 154 the object rip2IfConfDomain is deprecated, and the object 155 rip2PeerDomain (which cannot be deprecated, being an instance object) 156 must always be zero. 158 Unnumbered interfaces are supported in this version. Since the IP 159 Address that the neighbor uses may be unknown to the system, a 160 pseudo-address is used to identify these interfaces. The pseudo- 161 address is in the class A network 0.0.0.0, and the host number (the 162 least significant 24 bits of the address) are the ifIndex value of 163 the relevant IP Interface. This is an additional new meaning of the 164 objects rip2IfStatAddress and rip2IfConfAddress, backward compatible 165 with the RFC 1389 usage. The object rip2IfConfSrcAddress is added, 166 to permit the configuration of the source address on an unnumbered 167 interface, and the meaning of the object rip2PeerAddress is broadened 168 to remain relevant on unnumbered interfaces. 170 rip2IfConfSend is augmented with two values for the use of Demand RIP 171 under RIP-I and RIP-II rules. This avoids the necessity of a Demand 172 RIP MIB. 174 MD5 Authentication is supported. 176 4. Definitions 178 RIPv2-MIB DEFINITIONS ::= BEGIN 180 IMPORTS 181 MODULE-IDENTITY, OBJECT-TYPE, Counter32, 182 TimeTicks, IpAddress FROM SNMPv2-SMI 183 TEXTUAL-CONVENTION, RowStatus FROM SNMPv2-TC 184 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 185 mib-2 FROM RFC1213-MIB; 187 -- This MIB module uses the extended OBJECT-TYPE macro as 188 -- defined in [9]. 190 rip2 MODULE-IDENTITY 191 LAST-UPDATED "9407272253Z" -- Wed Jul 27 22:53:04 PDT 1994 192 ORGANIZATION "IETF RIP-II Working Group" 193 CONTACT-INFO 194 " Fred Baker 195 Postal: Cisco Systems 196 519 Lado Drive 197 Santa Barbara, California 93111 198 Tel: +1 805 681 0115 199 E-Mail: fbaker@cisco.com 201 Postal: Gary Malkin 202 Bay Networks 203 8 Federal Street 204 M/S BL8-05 205 Billerica, MA 01821 207 Phone: +1 508 916 4237 208 EMail: gmalkin@baynetworks.com 209 DESCRIPTION 210 "The MIB module to describe the RIP Version 2 Protocol" 211 ::= { mib-2 23 } 213 -- RIP-2 Management Information Base 215 -- the RouteTag type represents the contents of the 216 -- Route Domain field in the packet header or route entry. 217 -- The use of the Route Domain is deprecated. 219 RouteTag ::= TEXTUAL-CONVENTION 220 STATUS current 221 DESCRIPTION 222 "the RouteTag type represents the contents of the Route Domain 223 field in the packet header or route entry" 225 SYNTAX OCTET STRING (SIZE (2)) 227 --4.1 Global Counters 229 -- The RIP-2 Globals Group. 230 -- Implementation of this group is mandatory for systems 231 -- which implement RIP-2. 233 -- These counters are intended to facilitate debugging quickly 234 -- changing routes or failing neighbors 236 rip2Globals OBJECT IDENTIFIER ::= { rip2 1 } 238 rip2GlobalRouteChanges OBJECT-TYPE 239 SYNTAX Counter32 240 MAX-ACCESS read-only 241 STATUS current 242 DESCRIPTION 243 "The number of route changes made to the IP Route 244 Database by RIP. This does not include the refresh 245 of a route's age." 246 ::= { rip2Globals 1 } 248 rip2GlobalQueries OBJECT-TYPE 249 SYNTAX Counter32 250 MAX-ACCESS read-only 251 STATUS current 252 DESCRIPTION 253 "The number of responses sent to RIP queries 254 from other systems." 255 ::= { rip2Globals 2 } 257 --4.2 RIP Interface Tables 259 -- RIP Interfaces Groups 260 -- Implementation of these Groups is mandatory for systems 261 -- which implement RIP-2. 263 -- The RIP Interface Status Table. 265 rip2IfStatTable OBJECT-TYPE 266 SYNTAX SEQUENCE OF Rip2IfStatEntry 267 MAX-ACCESS not-accessible 268 STATUS current 269 DESCRIPTION 270 "A list of subnets which require separate 271 status monitoring in RIP." 272 ::= { rip2 2 } 274 rip2IfStatEntry OBJECT-TYPE 275 SYNTAX Rip2IfStatEntry 276 MAX-ACCESS not-accessible 277 STATUS current 278 DESCRIPTION 279 "A Single Routing Domain in a single Subnet." 280 INDEX { rip2IfStatAddress } 281 ::= { rip2IfStatTable 1 } 283 Rip2IfStatEntry ::= 284 SEQUENCE { 285 rip2IfStatAddress 286 IpAddress, 287 rip2IfStatRcvBadPackets 288 Counter32, 289 rip2IfStatRcvBadRoutes 290 Counter32, 291 rip2IfStatSentUpdates 292 Counter32, 293 rip2IfStatStatus 294 RowStatus 295 } 297 rip2IfStatAddress OBJECT-TYPE 298 SYNTAX IpAddress 299 MAX-ACCESS read-only 300 STATUS current 301 DESCRIPTION 302 "The IP Address of this system on the indicated 303 subnet. For unnumbered interfaces, the value 0.0.0.N, 304 where the least significant 24 bits (N) is the ifIndex 305 for the IP Interface in network byte order." 306 ::= { rip2IfStatEntry 1 } 308 rip2IfStatRcvBadPackets OBJECT-TYPE 309 SYNTAX Counter32 310 MAX-ACCESS read-only 311 STATUS current 312 DESCRIPTION 313 "The number of RIP response packets received by 314 the RIP process which were subsequently discarded 315 for any reason (e.g. a version 0 packet, or an 316 unknown command type)." 317 ::= { rip2IfStatEntry 2 } 319 rip2IfStatRcvBadRoutes OBJECT-TYPE 320 SYNTAX Counter32 321 MAX-ACCESS read-only 322 STATUS current 323 DESCRIPTION 324 "The number of routes, in valid RIP packets, 325 which were ignored for any reason (e.g. unknown 326 address family, or invalid metric)." 327 ::= { rip2IfStatEntry 3 } 329 rip2IfStatSentUpdates OBJECT-TYPE 330 SYNTAX Counter32 331 MAX-ACCESS read-only 332 STATUS current 333 DESCRIPTION 334 "The number of triggered RIP updates actually 335 sent on this interface. This explicitly does 336 NOT include full updates sent containing new 337 information." 338 ::= { rip2IfStatEntry 4 } 340 rip2IfStatStatus OBJECT-TYPE 341 SYNTAX RowStatus 342 MAX-ACCESS read-create 343 STATUS current 344 DESCRIPTION 345 "Writing invalid has the effect of deleting 346 this interface." 347 ::= { rip2IfStatEntry 5 } 349 -- The RIP Interface Configuration Table. 351 rip2IfConfTable OBJECT-TYPE 352 SYNTAX SEQUENCE OF Rip2IfConfEntry 353 MAX-ACCESS not-accessible 354 STATUS current 355 DESCRIPTION 356 "A list of subnets which require separate 357 configuration in RIP." 358 ::= { rip2 3 } 360 rip2IfConfEntry OBJECT-TYPE 361 SYNTAX Rip2IfConfEntry 362 MAX-ACCESS not-accessible 363 STATUS current 364 DESCRIPTION 365 "A Single Routing Domain in a single Subnet." 366 INDEX { rip2IfConfAddress } 367 ::= { rip2IfConfTable 1 } 369 Rip2IfConfEntry ::= 370 SEQUENCE { 371 rip2IfConfAddress 372 IpAddress, 373 rip2IfConfDomain 374 RouteTag, 375 rip2IfConfAuthType 376 INTEGER, 377 rip2IfConfAuthKey 378 OCTET STRING (SIZE(0..16)), 379 rip2IfConfSend 380 INTEGER, 381 rip2IfConfReceive 382 INTEGER, 383 rip2IfConfDefaultMetric 384 INTEGER, 385 rip2IfConfStatus 386 RowStatus, 387 rip2IfConfSrcAddress 388 IpAddress 389 } 391 rip2IfConfAddress OBJECT-TYPE 392 SYNTAX IpAddress 393 MAX-ACCESS read-only 394 STATUS current 395 DESCRIPTION 396 "The IP Address of this system on the indicated 397 subnet. For unnumbered interfaces, the value 0.0.0.N, 398 where the least significant 24 bits (N) is the ifIndex 399 for the IP Interface in network byte order." 400 ::= { rip2IfConfEntry 1 } 402 rip2IfConfDomain OBJECT-TYPE 403 SYNTAX RouteTag 404 MAX-ACCESS read-create 405 STATUS obsolete 406 DESCRIPTION 407 "Value inserted into the Routing Domain field 408 of all RIP packets sent on this interface." 409 DEFVAL { '0000'h } 410 ::= { rip2IfConfEntry 2 } 412 rip2IfConfAuthType OBJECT-TYPE 413 SYNTAX INTEGER { 414 noAuthentication (1), 415 simplePassword (2), 416 md5 (3) 417 } 419 MAX-ACCESS read-create 420 STATUS current 421 DESCRIPTION 422 "The type of Authentication used on this 423 interface." 424 DEFVAL { noAuthentication } 425 ::= { rip2IfConfEntry 3 } 427 rip2IfConfAuthKey OBJECT-TYPE 428 SYNTAX OCTET STRING (SIZE(0..16)) 429 MAX-ACCESS read-create 430 STATUS current 431 DESCRIPTION 432 "The value to be used as the Authentication Key 433 whenever the corresponding instance of 434 rip2IfConfAuthType has a value other than 435 noAuthentication. A modification of the corresponding 436 instance of rip2IfConfAuthType does not modify 437 the rip2IfConfAuthKey value. If a string shorter 438 than 16 octets is supplied, it will be left- 439 justified and padded to 16 octets, on the right, 440 with nulls (0x00). 442 Reading this object always results in an OCTET 443 STRING of length zero; authentication may not 444 be bypassed by reading the MIB object." 445 DEFVAL { ''h } 446 ::= { rip2IfConfEntry 4 } 448 rip2IfConfSend OBJECT-TYPE 449 SYNTAX INTEGER { 450 doNotSend (1), 451 ripVersion1 (2), 452 rip1Compatible (3), 453 ripVersion2 (4), 454 ripV1Demand (5), 455 ripV2Demand (6) 456 } 457 MAX-ACCESS read-create 458 STATUS current 459 DESCRIPTION 460 "What the router sends on this interface. 461 ripVersion1 implies sending RIP updates compliant 462 with RFC 1058. rip1Compatible implies 463 broadcasting RIP-2 updates using RFC 1058 route 464 subsumption rules. ripVersion2 implies 465 multicasting RIP-2 updates. ripV1Demand indicates 466 the use of Demand RIP on a WAN interface under RIP 467 Version 1 rules. ripV2Demand indicates the use of 468 Demand RIP on a WAN interface under Version 2 rules." 469 DEFVAL { ripVersion2 } 470 ::= { rip2IfConfEntry 5 } 472 rip2IfConfReceive OBJECT-TYPE 473 SYNTAX INTEGER { 474 rip1 (1), 475 rip2 (2), 476 rip1OrRip2 (3), 477 doNotReceive (4) 478 } 479 MAX-ACCESS read-create 480 STATUS current 481 DESCRIPTION 482 "This indicates which version of RIP updates 483 are to be accepted. Note that rip2 and 484 rip1OrRip2 implies reception of multicast, 485 in addition to broadcast, packets." 486 DEFVAL { rip1OrRip2 } 487 ::= { rip2IfConfEntry 6 } 489 rip2IfConfDefaultMetric OBJECT-TYPE 490 SYNTAX INTEGER ( 0..15 ) 491 MAX-ACCESS read-create 492 STATUS current 493 DESCRIPTION 494 "This variable indicates the metric that is to 495 be used for the default route entry in RIP updates 496 originated on this interface. A value of zero 497 indicates that no default route should be 498 originated; in this case, a default route via 499 another router may be propagated." 500 ::= { rip2IfConfEntry 7 } 502 rip2IfConfStatus OBJECT-TYPE 503 SYNTAX RowStatus 504 MAX-ACCESS read-create 505 STATUS current 506 DESCRIPTION 507 "Writing invalid has the effect of deleting 508 this interface." 509 ::= { rip2IfConfEntry 8 } 511 rip2IfConfSrcAddress OBJECT-TYPE 512 SYNTAX IpAddress 513 MAX-ACCESS read-create 514 STATUS current 515 DESCRIPTION 516 "The IP Address this system will use as a source 517 address on this interface. If it is a numbered 518 interface, this MUST be the same value as 519 rip2IfConfAddress. On unnumbered interfaces, 520 it must be the value of rip2IfConfAddress for 521 some interface on the system." 522 ::= { rip2IfConfEntry 9 } 524 --4.3 Peer Table 526 -- Peer Table 528 -- The RIP Peer Group 529 -- Implementation of this Group is Optional 531 -- This group provides information about active peer 532 -- relationships intended to assist in debugging. An 533 -- active peer is a router from which a valid RIP 534 -- updated has been heard in the last 180 seconds. 536 rip2PeerTable OBJECT-TYPE 537 SYNTAX SEQUENCE OF Rip2PeerEntry 538 MAX-ACCESS not-accessible 539 STATUS current 540 DESCRIPTION 541 "A list of RIP Peers." 542 ::= { rip2 4 } 544 rip2PeerEntry OBJECT-TYPE 545 SYNTAX Rip2PeerEntry 546 MAX-ACCESS not-accessible 547 STATUS current 548 DESCRIPTION 549 "Information regarding a single routing peer." 550 INDEX { rip2PeerAddress, rip2PeerDomain } 551 ::= { rip2PeerTable 1 } 553 Rip2PeerEntry ::= 554 SEQUENCE { 555 rip2PeerAddress 556 IpAddress, 557 rip2PeerDomain 558 RouteTag, 559 rip2PeerLastUpdate 560 TimeTicks, 561 rip2PeerVersion 562 INTEGER, 564 rip2PeerRcvBadPackets 565 Counter32, 566 rip2PeerRcvBadRoutes 567 Counter32 568 } 570 rip2PeerAddress OBJECT-TYPE 571 SYNTAX IpAddress 572 MAX-ACCESS read-only 573 STATUS current 574 DESCRIPTION 575 "The IP Address that the peer is using as its source 576 address. Note that on an unnumbered link, this may 577 not be a member of any subnet on the system." 578 ::= { rip2PeerEntry 1 } 580 rip2PeerDomain OBJECT-TYPE 581 SYNTAX RouteTag 582 MAX-ACCESS read-only 583 STATUS current 584 DESCRIPTION 585 "The value in the Routing Domain field in RIP 586 packets received from the peer. As domain suuport 587 is deprecated, this must be zero." 588 ::= { rip2PeerEntry 2 } 590 rip2PeerLastUpdate OBJECT-TYPE 591 SYNTAX TimeTicks 592 MAX-ACCESS read-only 593 STATUS current 594 DESCRIPTION 595 "The value of sysUpTime when the most recent 596 RIP update was received from this system." 597 ::= { rip2PeerEntry 3 } 599 rip2PeerVersion OBJECT-TYPE 600 SYNTAX INTEGER ( 0..255 ) 601 MAX-ACCESS read-only 602 STATUS current 603 DESCRIPTION 604 "The RIP version number in the header of the 605 last RIP packet received." 606 ::= { rip2PeerEntry 4 } 608 rip2PeerRcvBadPackets OBJECT-TYPE 609 SYNTAX Counter32 610 MAX-ACCESS read-only 611 STATUS current 612 DESCRIPTION 613 "The number of RIP response packets from this 614 peer discarded as invalid." 615 ::= { rip2PeerEntry 5 } 617 rip2PeerRcvBadRoutes OBJECT-TYPE 618 SYNTAX Counter32 619 MAX-ACCESS read-only 620 STATUS current 621 DESCRIPTION 622 "The number of routes from this peer that were 623 ignored because the entry format was invalid." 624 ::= { rip2PeerEntry 6 } 626 -- conformance information 628 rip2Conformance OBJECT IDENTIFIER ::= { rip2 5 } 630 rip2Groups OBJECT IDENTIFIER ::= { rip2Conformance 1 } 631 rip2Compliances OBJECT IDENTIFIER ::= { rip2Conformance 2 } 633 -- compliance statements 634 rip2Compliance MODULE-COMPLIANCE 635 STATUS current 636 DESCRIPTION 637 "The compliance statement " 638 MODULE -- this module 639 MANDATORY-GROUPS { 640 rip2GlobalGroup, 641 rip2IfStatGroup, 642 rip2IfConfGroup, 643 rip2PeerGroup 644 } 645 GROUP rip2GlobalGroup 646 DESCRIPTION 647 "This group defines global controls for RIP-II systems." 648 GROUP rip2IfStatGroup 649 DESCRIPTION 650 "This group defines interface statistics for RIP-II systems." 651 GROUP rip2IfConfGroup 652 DESCRIPTION 653 "This group defines interface configuration for RIP-II systems." 654 GROUP rip2PeerGroup 655 DESCRIPTION 656 "This group defines peer information for RIP-II systems." 657 ::= { rip2Compliances 1 } 659 -- units of conformance 661 rip2GlobalGroup OBJECT-GROUP 662 OBJECTS { 663 rip2GlobalRouteChanges, 664 rip2GlobalQueries 665 } 666 STATUS current 667 DESCRIPTION 668 "This group defines global controls for RIP-II systems." 669 ::= { rip2Groups 1 } 670 rip2IfStatGroup OBJECT-GROUP 671 OBJECTS { 672 rip2IfStatAddress, 673 rip2IfStatRcvBadPackets, 674 rip2IfStatRcvBadRoutes, 675 rip2IfStatSentUpdates, 676 rip2IfStatStatus 677 } 678 STATUS current 679 DESCRIPTION 680 "This group defines interface statistics for RIP-II systems." 681 ::= { rip2Groups 2 } 682 rip2IfConfGroup OBJECT-GROUP 683 OBJECTS { 684 rip2IfConfAddress, 685 rip2IfConfAuthType, 686 rip2IfConfAuthKey, 687 rip2IfConfSend, 688 rip2IfConfReceive, 689 rip2IfConfDefaultMetric, 690 rip2IfConfStatus, 691 rip2IfConfSrcAddress 692 } 693 STATUS current 694 DESCRIPTION 695 "This group defines interface configuration for RIP-II systems." 696 ::= { rip2Groups 3 } 697 rip2PeerGroup OBJECT-GROUP 698 OBJECTS { 699 rip2PeerAddress, 700 rip2PeerDomain, 701 rip2PeerLastUpdate, 702 rip2PeerVersion, 703 rip2PeerRcvBadPackets, 704 rip2PeerRcvBadRoutes 705 } 706 STATUS current 707 DESCRIPTION 708 "This group defines peer information for RIP-II systems." 709 ::= { rip2Groups 4 } 710 END 712 5. References 714 [1] Cerf, V., "IAB Recommendations for the Development of Internet 715 Network Management Standards", RFC 1052, IAB, April 1988. 717 [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review 718 Group", RFC 1109, IAB, August 1989. 720 [3] Rose M., and K. McCloghrie, "Structure and Identification of 721 Management Information for TCP/IP-based internets", STD 16, RFC 722 1155, Performance Systems International, Hughes LAN Systems, May 723 1990. 725 [4] McCloghrie K., and M. Rose, "Management Information Base for 726 Network Management of TCP/IP-based internets", RFC 1156, Hughes 727 LAN Systems, Performance Systems International, May 1990. 729 [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 730 Network Management Protocol", STD 15, RFC 1157, SNMP Research, 731 Performance Systems International, Performance Systems 732 International, MIT Laboratory for Computer Science, May 1990. 734 [6] Rose, M., Editor, "Management Information Base for Network 735 Management of TCP/IP-based internets: MIB-II", RFC 1158, 736 Performance Systems International, May 1990. 738 [7] Information processing systems - Open Systems Interconnection - 739 Specification of Abstract Syntax Notation One (ASN.1), 740 International Organization for Standardization, International 741 Standard 8824, December 1987. 743 [8] Information processing systems - Open Systems Interconnection - 744 Specification of Basic Encoding Rules for Abstract Notation One 745 (ASN.1), International Organization for Standardization, 746 International Standard 8825, December 1987. 748 [9] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", 749 STD 16, RFC 1212, Performance Systems International, Hughes LAN 750 Systems, March 1991. 752 [10] Malkin, G., "RIP Version 2 - Carrying Additional Information", 753 RFC 1723, Xylogics, Inc., November 1994. 755 [11] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1721, 756 Xylogics, Inc., November 1994. 758 [12] Malkin, G., "RIP Version 2 Protocol Applicability Statement", RFC 759 1722, Xylogics, Inc., November 1994. 761 6. Security Considerations 763 Security issues are not discussed in this memo. See the most recent 764 SNMP RFCs for security considerations. 766 7. Authors' Addresses 768 Gary Malkin 769 Bay Networks 770 8 Federal Street 771 M/S BL8-05 772 Billerica, MA 01821 774 Phone: 508-916-4237 775 EMail: gmalkin@baynetworks.com 777 Fred Baker 778 Cisco Systems 779 519 Lado Drive 780 Santa Barbara, California 93111 782 Phone: 805-681-0115 783 EMail: fred@cisco.com