![]() |
IP Routing: RIP Configuration Guide, Cisco IOS Release 12.4T
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Advanced RIP Features
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Contents
Advanced RIP FeaturesLast Updated: October 25, 2011
The Advanced RIP Features contained in this configuration module cover the implementation of RFC 1724, which allows you to monitor RIPv2 using SNMP, and the information about configuring the cable modem HFC RIP Relay feature. Finding Feature InformationYour software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the Feature Information Table at the end of this document. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required. Information About Advanced RIP FeaturesCable HFCCable technology has been adapting to the deployment of fiber since 1994, leading to hybrid solutions known as hybrid fiber-coaxial (HFC). HFC networks contain both optical-fiber and coaxial cable lines. Optical fiber is deployed from the cable headend to cable operator subscribers with up to 2000 subscribers. Coaxial cable is deployed from the optical-fiber feeders to each subscriber. Hybrid networks provide the bandwidth and reliability of optical fiber at a lower cost than a pure fiber network. HFC RIP RelayThe cable modem HFC RIP Relay feature allows the delivery of Routing Information Protocol (RIP) messages from a Cisco IOS router containing an integrated cable modem to the hybrid fiber-coaxial (HFC) cable modem termination system (CMTS) when they are on different subnets. The integrated cable modem may be physically integrated into the router or via a cable modem high-speed WAN interface card (HWIC). In previous Cisco IOS releases, RIP messages were rejected by the CMTS because the interface on the Cisco IOS router was in a different subnet from the CMTS. The solution involves trapping and handling RIP messages by the cable modem and ensuring that the RIP messages are forwarded to the router. The cable modem HFC RIP Relay feature enhances the scalability, security, and certification requirements of cable operators who require RIP to provision and manage customer cable modems. In the provisioning systems used by some cable operators, when a Cisco IOS router containing an integrated cable modem is connected to a CMTS, RIP messages are rejected because the IP address derived from a DHCP request for the router is from a different pool of IP addresses than for the cable modems. The RIP messages are rejected by the CMTS because the interface on the Cisco IOS router is in a different subnet from the CMTS. Without requiring additional configuration on the CMTS, the HFC RIP Relay feature enables the cable modem to bridge the RIP messages between the Cisco IOS router and the CMTS. The cable modem HFC RIP Relay feature is implemented in Cisco IOS Release 12.4(15)XY, 12.4(20)T, and later releases. The feature requires the cable modem firmware version filename of C21031014bFU07192007.CDF in the United States or the cable modem firmware version filename of C21041014bFU07192007.CDF in Europe and Japan, and the feature is turned off by default. To enable HFC RIP relay, use the new service-module ip rip relay command-line interface (CLI) command. Support is added for configuring a static IP address on the cable modem interface. Configuring a static IP address for the Cisco IOS router with an integrated cable modem is also supported in Cisco IOS Release 12.4(15)XY, 12.4(20)T, and later releases using the ip address command. Benefits of the RIPv2 MIBThe RFC 1724 RIPv2 MIB extensions allow network managers to monitor the RIPv2 routing protocol using SNMP through the addition of new global counters and table objects that previously were not supported by the RFC 1389 RIPv2 MIB. The new global counters and table objects are intended to facilitate quickly changing routes or failing neighbors. RIPv2 MIBThis document describes the Cisco IOS implementation of RFC 1724, RIP Version 2 MIB Extensions . RIPv2 using Simple Network Management Protocol (SNMP). This section describes the MIB objects that are provided by RFC 1724 definitions. The RIPv2 MIB consists of the following managed objects:
The tables below show the objects that are provided by RFC 1724 RIPv2 MIB definitions. The objects are listed in the order in which they appear within the RFC 1724 RIPv2 MIB, per the tables that describe them. The statistics for all of the objects in the global counters can be obtained by querying the rip2Globals object identifier (OID) using snmpwalk or a similar SNMP toolset command on your Network Management Station (NMS). The table below shows the RFC 1724 RIPv2 MIB global counter objects.
The objects in the RFC 1724 RIPv2 MIB interface table track information on a per-interface basis. All objects in the RFC 1724 RIPv2 MIB interface table, except for the rip2IfStatAddress object, represent newly tracked data within RIP. There are no equivalent show commands for these objects. All objects in the RIPv2 MIB interface table are implemented read-only. The table below shows the RFC 1724 RIPv2 MIB interface table objects. The statistics for all objects in the interface table can be obtained by querying the sequence name Rip2IfStatEntry using snmpwalk or a similar SNMP toolset command on your NMS.
The objects in the RFC 1724 RIPv2 MIB interface configuration table track information on a per- interface basis. Except for the Rip2IfConfAuthType object, the data for the objects in the RFC 1724 RIPv2 MIB interface configuration table can also be gathered using the show ip protocol commands. All objects in the RIPv2 MIB interface table are implemented read-only. The table below shows the RIPv2 MIB interface configuration table objects. The statistics for all objects in the configuration table can be obtained by querying the sequence name rip2IfConfEntry using snmpwalk or a similar SNMP toolset command on your NMS.
SNMP Community StringsRouters can have multiple read-only SNMP community strings. When you configure an SNMP read-only community string for the snmp-server command on the router, an existing SNMP snmp-server read-only community string is not overwritten. For example, if you enter the snmp-server community string1 ro and snmp-server community string2 ro commands on the router, the router will have two valid read-only community strings--string1 and string2. If this is not the behavior that you desire, use the no snmp-server community string ro command to remove an existing SNMP read-only community string. How to Configure Advanced RIP Features
Configuring HFC RIP RelayThis section contains the following tasks:
PrerequisitesThe HFC RIP Relay feature requires an Integrated Services Router (ISR) with an integrated cable modem and Cisco IOS Release 12.4(15)XY, 12.4(20)T, or later release and one of the following:
ISR cable products include the Cisco 815, Cisco 1805, and the cable modem HWIC in the Cisco 1800, 2800, and 3800 series routers. RestrictionsThe HFC RIP Relay feature does not support multiple cable modem HWICs in a single router. Enabling HFC RIP RelayPerform this task to enable RIP relay on an integrated cable modem. In this task, a static IP address is configured for the cable modem interface and RIP relay is enabled on the interface. Validation of the source IP address of incoming RIP routing updates is disabled to allow RIP updates from unknown sources. RIP is defined as the routing protocol to be used on all interfaces that are connected to networks 10.0.0.0 and 172.18.0.0. DETAILED STEPS Enabling HFC RIP Relay for a Single Subnet and Disabling Split-HorizonPerform this task to enable RIP relay on an ISR cable modem. In this task, a static IP address is configured for the cable-modem interface and RIP relay is enabled on the interface. Split-horizon is disabled, and RIP is defined as the routing protocol to be used on all interfaces connected to network 10.0.0.0. DETAILED STEPS Verifying the Configuration of HFC RIP Relay
SUMMARY STEPS
DETAILED STEPS
Enabling RIPv2 Monitoring with SNMP Using the RIPv2 RFC 1724 MIB ExtensionsThis section contains the following tasks:
RestrictionsThis implementation of the RIPv2 MIB does not track any data associated with a RIP Virtual Routing and Forwarding (VRF) instance. Only interfaces that are assigned IP addresses in the IP address space configured by the network command in RIP router configuration mode are tracked. Global data is tracked only for changes to the main routing table. Enabling SNMP Read-Only Access on the RouterThere are no router configuration tasks required for the RIPv2: RFC 1724 MIB Extensions feature itself. SNMP read-only access to the objects in the RFC 1724 RIPv2 MIB is enabled when you configure the SNMP server read-only community string on the router. Perform this task to configure the SNMP server read-only community string on the router to enable SNMP read-only access to MIB objects (including the RFC 1724 RIPv2 MIB extensions) on the router. DETAILED STEPS Verifying the Status of the RIPv2 RFC 1724 MIB Extensions on the Router and Your Network Management StationPerform this optional task on your NMS to verify the status of the RFC 1724 RIPv2 MIB extensions on the router and on your NMS. PrerequisitesYour NMS must have the RFC 1724 MIB installed.
DETAILED STEPS
Configuration Examples for Advanced RIP Features
Configuration Examples for HFC RIP Relay
Enabling HFC RIP Relay ExampleThe following example enables RIP relay on an ISR cable modem. A static IP address is configured for the cable-modem interface, and RIP relay is enabled on the interface. Validation of the source IP address of incoming RIP routing updates is disabled to allow RIP updates from unknown sources. RIP is defined as the routing protocol to be used on all interfaces connected to networks 10.0.0.0 and 172.18.0.0. interface Cable-Modem0/3/0 ip address 10.5.5.5 255.255.255.0 service-module ip rip relay exit router rip version 2 no validate-update-source network 10.0.0.0 network 172.18.0.0 Enabling HFC RIP Relay for a Single Subnet and Disabling Split-Horizon ExampleThe following example enables RIP relay on an ISR cable modem. A static IP address is configured for the cable-modem interface, and RIP relay is enabled on the interface. Validation of the source IP address of incoming RIP routing updates is disabled to allow RIP updates from unknown sources, and split-horizon is disabled. RIP is defined as the routing protocol to be used on all interfaces connected to network 172.20.0.0. interface Cable-Modem0/3/0 ip address 172.20.0.2 255.255.255.0 service-module ip rip relay no ip split-horizon exit router rip version 2 no validate-update-source network 172.20.0.0 Configuration Examples for RIPv2 Monitoring with SNMP Using the RIPv2 RFC1724 MIB Extensions
Querying the RIP Interface Status Table Objects ExampleThe following example shows how to send an SNMP query to obtain data for all objects in the RIP interface status table using the snmpwalk command.
$ snmpwalk -m all -v2c 10.0.0.253 -c T8vCx3 Rip2IfStatEntry
RIPv2-MIB::rip2IfStatAddress.10.0.0.253 = IpAddress: 10.0.0.253
RIPv2-MIB::rip2IfStatAddress.172.16.1.1 = IpAddress: 172.16.1.1
RIPv2-MIB::rip2IfStatAddress.172.16.2.1 = IpAddress: 172.16.2.1
RIPv2-MIB::rip2IfStatAddress.172.17.1.1 = IpAddress: 172.17.1.1
RIPv2-MIB::rip2IfStatAddress.172.17.2.1 = IpAddress: 172.17.2.1
RIPv2-MIB::rip2IfStatRcvBadPackets.10.0.0.253 = Counter32: 0
RIPv2-MIB::rip2IfStatRcvBadPackets.172.16.1.1 = Counter32: 1654
RIPv2-MIB::rip2IfStatRcvBadPackets.172.16.2.1 = Counter32: 1652
RIPv2-MIB::rip2IfStatRcvBadPackets.172.17.1.1 = Counter32: 1648
RIPv2-MIB::rip2IfStatRcvBadPackets.172.17.2.1 = Counter32: 1649
RIPv2-MIB::rip2IfStatRcvBadRoutes.10.0.0.253 = Counter32: 0
RIPv2-MIB::rip2IfStatRcvBadRoutes.172.16.1.1 = Counter32: 0
RIPv2-MIB::rip2IfStatRcvBadRoutes.172.16.2.1 = Counter32: 0
RIPv2-MIB::rip2IfStatRcvBadRoutes.172.17.1.1 = Counter32: 0
RIPv2-MIB::rip2IfStatRcvBadRoutes.172.17.2.1 = Counter32: 0
RIPv2-MIB::rip2IfStatSentUpdates.10.0.0.253 = Counter32: 0
RIPv2-MIB::rip2IfStatSentUpdates.172.16.1.1 = Counter32: 0
RIPv2-MIB::rip2IfStatSentUpdates.172.16.2.1 = Counter32: 0
RIPv2-MIB::rip2IfStatSentUpdates.172.17.1.1 = Counter32: 0
RIPv2-MIB::rip2IfStatSentUpdates.172.17.2.1 = Counter32: 0
RIPv2-MIB::rip2IfStatStatus.10.0.0.253 = INTEGER: active(1)
RIPv2-MIB::rip2IfStatStatus.172.16.1.1 = INTEGER: active(1)
RIPv2-MIB::rip2IfStatStatus.172.16.2.1 = INTEGER: active(1)
RIPv2-MIB::rip2IfStatStatus.172.17.1.1 = INTEGER: active(1)
RIPv2-MIB::rip2IfStatStatus.172.17.2.1 = INTEGER: active(1)
The following example shows how to send an SNMP query to obtain data for the rip2IfStatStatus object for all the interfaces in the RIP interface status table using the snmpwalk command.
$ snmpwalk -m all -v2c 10.0.0.253 -c T8vCx3 rip2IfStatStatus
RIPv2-MIB::rip2IfStatStatus.10.0.0.253 = INTEGER: active(1)
RIPv2-MIB::rip2IfStatStatus.172.16.1.1 = INTEGER: active(1)
RIPv2-MIB::rip2IfStatStatus.172.16.2.1 = INTEGER: active(1)
RIPv2-MIB::rip2IfStatStatus.172.17.1.1 = INTEGER: active(1)
RIPv2-MIB::rip2IfStatStatus.172.17.2.1 = INTEGER: active(1)
$
The following example shows how to send an SNMP query to obtain data for the rip2IfStatStatus object for a specific interface IP address in the RIP interface status table using the snmpget command.
$ snmpget -m all -v2c 10.0.0.253 -c T8vCx3 rip2IfStatStatus.10.0.0.253
RIPv2-MIB::rip2IfStatStatus.10.0.0.253 = INTEGER: active(1)
Querying the RIP Interface Configuration Table Objects ExampleThe following example shows how to send an SNMP query to obtain data for all objects in the RIP interface configuration table using the snmpwalk command.
$ snmpwalk -m all -v2c 10.0.0.253 -c T8vCx3 rip2IfConfEntry
RIPv2-MIB::rip2IfConfAddress.10.0.0.253 = IpAddress: 10.0.0.253
RIPv2-MIB::rip2IfConfAddress.172.16.1.1 = IpAddress: 172.16.1.1
RIPv2-MIB::rip2IfConfAddress.172.16.2.1 = IpAddress: 172.16.2.1
RIPv2-MIB::rip2IfConfAddress.172.17.1.1 = IpAddress: 172.17.1.1
RIPv2-MIB::rip2IfConfAddress.172.17.2.1 = IpAddress: 172.17.2.1
RIPv2-MIB::rip2IfConfDomain.10.0.0.253 = ""
RIPv2-MIB::rip2IfConfDomain.172.16.1.1 = ""
RIPv2-MIB::rip2IfConfDomain.172.16.2.1 = ""
RIPv2-MIB::rip2IfConfDomain.172.17.1.1 = ""
RIPv2-MIB::rip2IfConfDomain.172.17.2.1 = ""
RIPv2-MIB::rip2IfConfAuthType.10.0.0.253 = INTEGER: noAuthentication(1)
RIPv2-MIB::rip2IfConfAuthType.172.16.1.1 = INTEGER: noAuthentication(1)
RIPv2-MIB::rip2IfConfAuthType.172.16.2.1 = INTEGER: noAuthentication(1)
RIPv2-MIB::rip2IfConfAuthType.172.17.1.1 = INTEGER: noAuthentication(1)
RIPv2-MIB::rip2IfConfAuthType.172.17.2.1 = INTEGER: noAuthentication(1)
RIPv2-MIB::rip2IfConfAuthKey.10.0.0.253 = ""
RIPv2-MIB::rip2IfConfAuthKey.172.16.1.1 = ""
RIPv2-MIB::rip2IfConfAuthKey.172.16.2.1 = ""
RIPv2-MIB::rip2IfConfAuthKey.172.17.1.1 = ""
RIPv2-MIB::rip2IfConfAuthKey.172.17.2.1 = ""
RIPv2-MIB::rip2IfConfSend.10.0.0.253 = INTEGER: ripVersion2(4)
RIPv2-MIB::rip2IfConfSend.172.16.1.1 = INTEGER: ripVersion2(4)
RIPv2-MIB::rip2IfConfSend.172.16.2.1 = INTEGER: ripVersion2(4)
RIPv2-MIB::rip2IfConfSend.172.17.1.1 = INTEGER: ripVersion2(4)
RIPv2-MIB::rip2IfConfSend.172.17.2.1 = INTEGER: ripVersion2(4)
RIPv2-MIB::rip2IfConfReceive.10.0.0.253 = INTEGER: rip2(2)
RIPv2-MIB::rip2IfConfReceive.172.16.1.1 = INTEGER: rip2(2)
RIPv2-MIB::rip2IfConfReceive.172.16.2.1 = INTEGER: rip2(2)
RIPv2-MIB::rip2IfConfReceive.172.17.1.1 = INTEGER: rip2(2)
RIPv2-MIB::rip2IfConfReceive.172.17.2.1 = INTEGER: rip2(2)
RIPv2-MIB::rip2IfConfDefaultMetric.10.0.0.253 = INTEGER: 1
RIPv2-MIB::rip2IfConfDefaultMetric.172.16.1.1 = INTEGER: 1
RIPv2-MIB::rip2IfConfDefaultMetric.172.16.2.1 = INTEGER: 1
RIPv2-MIB::rip2IfConfDefaultMetric.172.17.1.1 = INTEGER: 1
RIPv2-MIB::rip2IfConfDefaultMetric.172.17.2.1 = INTEGER: 1
RIPv2-MIB::rip2IfConfStatus.10.0.0.253 = INTEGER: active(1)
RIPv2-MIB::rip2IfConfStatus.172.16.1.1 = INTEGER: active(1)
RIPv2-MIB::rip2IfConfStatus.172.16.2.1 = INTEGER: active(1)
RIPv2-MIB::rip2IfConfStatus.172.17.1.1 = INTEGER: active(1)
RIPv2-MIB::rip2IfConfStatus.172.17.2.1 = INTEGER: active(1)
RIPv2-MIB::rip2IfConfSrcAddress.10.0.0.253 = IpAddress: 10.0.0.253
RIPv2-MIB::rip2IfConfSrcAddress.172.16.1.1 = IpAddress: 172.16.1.1
RIPv2-MIB::rip2IfConfSrcAddress.172.16.2.1 = IpAddress: 172.16.2.1
RIPv2-MIB::rip2IfConfSrcAddress.172.17.1.1 = IpAddress: 172.17.1.1
RIPv2-MIB::rip2IfConfSrcAddress.172.17.2.1 = IpAddress: 172.17.2.1
$
The following example shows how to send an SNMP query to obtain data for the rip2IfConfAddress object for all interfaces in the RIP interface configuration table using the snmpwalk command.
$ snmpwalk -m all -v2c 10.0.0.253 -c T8vCx3 rip2IfConfAddress
RIPv2-MIB::rip2IfConfAddress.10.0.0.253 = IpAddress: 10.0.0.253
RIPv2-MIB::rip2IfConfAddress.172.16.1.1 = IpAddress: 172.16.1.1
RIPv2-MIB::rip2IfConfAddress.172.16.2.1 = IpAddress: 172.16.2.1
RIPv2-MIB::rip2IfConfAddress.172.17.1.1 = IpAddress: 172.17.1.1
RIPv2-MIB::rip2IfConfAddress.172.17.2.1 = IpAddress: 172.17.2.1
$
Additional ReferencesRelated Documents
MIBsTechnical Assistance
Feature Information for Advanced RIP FeaturesThe following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
GlossaryOID--object identifier. A managed object within the object tree. SNMP--Simple Network Management Protocol. Aprotocol used to monitor and manage networking devices. snmpget--An SNMP command to query statistics from a specific OID in the MIB. Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R) Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental. © 2011 Cisco Systems, Inc. All rights reserved.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|