Quick Notes: RIPv2, RIPng, and Classless Routing

on
** From: Routing TCP/IP, Volume I, 2nd Edition **

  • RIPv2 is not a new protocol; rather, it is RIPv1 with some extensions to bring it more up to date with modern routing environments. 
  • These extensions are:
    • Subnet masks carried with each route entry
    • Authentication of routing updates
    • Next-hop addresses carried with each route entry
    • External route tags
    • Multicast route updates
  • The most important of these extensions is the addition of a Subnet Mask field to the routing update entries, enabling the use of variable-length subnet masks and qualifying RIPv2 as a classless routing protocol.
  • RIP next generation (RIPng), a modification of RIPv2 for routing IPv6.
  • Unlike IPv4, IPv6 is inherently classless; there are no class A, B, and C, or similar address groupings. Therefore RIPng is also a classless routing protocol.
  • All of the operational procedures, timers, and stability functions of RIPv1 remain the same in Version 2, with the exception of the broadcast updates. RIPv2 multicasts updates to other RIPv2-speaking routers, using the reserved class D address 224.0.0.9.


RIPv2 Message Format

  • The basic structure is the same as for RIPv1. All the extensions to the original protocol are carried within what were unused fields. 
  • Like Version 1, RIPv2 updates can contain entries for up to 25 routes. Also like Version 1, RIPv2 operates from UDP port 520 and has a maximum datagram size (with an eight-byte UDP header) of 512 octets.
  • Command will always be set to either one, signifying a request message, or two, signifying a response message.
  • Version will be set to two for RIPv2. If it is set to zero, or if it is set to one but the message is not a valid RIPv1 format, the message will be discarded. RIPv2 will process valid RIPv1 messages.
  • Address Family Identifier is set to two for IPv4. The only exception is a request for a router’s (or host’s) full routing table, in which case it will be set to zero.
  • Route Tag provides a field for tagging external routes or routes that have been redistributed into the RIPv2 process. One suggested use of this 16-bit field is to carry the autonomous system number of routes that have been imported from an external routing protocol. Although RIP itself does not use this field, external routing protocols connected to a RIP domain in multiple locations may use the route tag field to exchange information across the RIP domain. The field may also be used to group certain external routes for easier control within the RIP domain.
  • IP Address is the IPv4 address of the destination of the route. It may be a major network address, a subnet, or a host route.
  • Subnet Mask is 32-bit mask that identifies the network and subnet portion of the IPv4 address.
  • Next Hop identifies a better next-hop address, if one exists, than the address of the advertising router. That is, it indicates a next-hop address, on the same subnet, that is metrically closer to the destination than the advertising router is. If the field is set to all zeros (0.0.0.0), the address of the advertising router is the best next-hop address.
  • Metric is a hop count between 1 and 16.

Compatibility with RIPv1

  • RFC 1723 defines a “compatibility switch” with four settings, which allows Versions 1 and 2 to interoperate:
    • RIP-1, in which only RIPv1 messages are transmitted.
    • RIP-1 Compatibility, which causes RIPv2 to broadcast its messages instead of multicast them so that RIPv1 may receive them.
    • RIP-2, in which RIPv2 messages are multicast to destination address 224.0.0.9.
    • None, in which no updates are sent.
  • The four recommended settings of this switch are
    • RIP-1 Only
    • RIP-2 Only
    • Both
    • None
  • This switch should also be configurable on a per interface basis. Setting 4 can be accomplished by using an access list to filter UDP source port 520, by not including a network statement for the interface, or by configuring a route filter.

Classless Routing

  • Classful route lookups, in which a destination address is first matched to its major network address in the routing table and is then matched to a subnet of the major network. If no match is found at either of these steps, the packet is dropped.
  • When a router performs classless route lookups, it does not pay attention to the class of the destination address. Instead, it performs a bit-by-bit best match between the destination address and all its known routes.
  • The true defining characteristic of classless routing protocols is the capability to carry subnet masks in their route advertisements. One benefit of having a mask associated with each route is that the all-zeros and all-ones subnets are now available for use.
  • Classful routing protocols cannot distinguish between an all-zeros subnet (172.16.0.0, for example) and the major network number (172.16.0.0). Likewise, they cannot distinguish between a broadcast on the all-ones subnet (172.16.255. 255) and an all-subnets broadcast (172.16.255.255).
  • If the subnet masks are included, this difficulty disappears. You can readily see that 172.16.0.0/16 is the major network number and that 172.16.0.0/24 is an all-zeros subnet. 172.16.255.255/16 and 172.16.255.255/24 are just as distinguishable.
  • By default, the Cisco IOS rejects an attempt to configure an all-zeros subnet as an invalid address/mask combination even if a classless routing protocol is running. To override this default behavior, enter the global command ip subnet-zero.

Authentication

  • RIPv2 includes the capability to authenticate the source of a routing update by including a password.
  • Authentication is supported by modifying what would normally be the first route entry of the RIP message.
  • With authentication, the maximum number of entries a single update can carry is reduced to 24.
  • The presence of authentication is indicated by setting the Address Family Identifier field to all ones (0xFFFF). 
  • The Authentication Type for simple password authentication is two (0x0002), and the remaining 16 octets carry an alphanumeric password of up to 16 characters. The password is left-justified in the field, and if the password is less than 16 octets, the unused bits of the field are set to zero.
  • The password is transmitted in plain text.
  • Cisco uses the first and last route entry spaces for MD5 authentication purposes.
  • MD5 is a one-way message digest or secure hash function.
  • MD5 computes a 128-bit hash value from a plain text message of arbitrary length (a RIPv2 update, for instance) and a password. This “fingerprint” is transmitted along with the message. The receiver, knowing the same password, calculates its own hash value. If nothing in the message has changed, the receiver’s hash value should match the sender’s value transmitted with the message.
  • The authentication type is 3, and no password can be seen.

Operation of RIPng

  • RIPng for IPv6 is based on RIPv2, but it is not an extension of RIPv2; it is an entirely separate protocol. 
  • RIPng does not support IPv4, so to use RIP to route both IPv4 and IPv6, you must run RIPv1 or v2 for IPv4 and RIPng for IPv6.
  • RIPng uses the same timers, procedures, and message types as RIPv2. For example, like RIPv2 it uses a 30-second update timer jittered to prevent message synchronization, a 180-second timeout period, a 120-second garbage-collection timer, and a 180-second holddown timer.
  • The IPv6 multicast address used by RIPng is FF02::9.
  • An exception to these parallel functions is authentication. RIPng does not have an authentication mechanism of its own, but instead relies on the authentication features built into IPv6.
  • RIPng sends and receives its messages at UDP port 521.
  • Also unlike RIPv1 and v2, there is no set message size. The message size is dependent only on the MTU of the link on which it is being sent.
  • Command is always set to 1, indicating a Request message, or to 2, indicating a Response message.
  • Version is always set to 1, that is, the current version of RIPng in RIPngv1.
  • IPv6 Prefix is the 128-bit IPv6 destination prefix of the route entry.
  • Route Tag is used in the same way the 16-bit RIPv2 Route Tag field is used: for transporting external route attributes across the RIP domain.
  • Prefix Length is an 8-bit field specifying, in bits, the significant part of the address in the IPv6 Prefix field. For example, if the advertised prefix is 3ffe:2100:1201::/48, the value in the Prefix Length field is 48 (0x30). If the advertised route entry is a default route, the IPv6 prefix is 0:0:0:0:0:0:0:0 and the Prefix Length is 0.
  • Metric is the same hop count metric used by RIPv1 and v2. But as the maximum possible value is 16, the field is reduced to 8 bits from the unnecessarily large 16 bits of RIPv1 and v2.
  • A valid non-zero next-hop address specifies a next-hop router other than the originator of the Response message and a next-hop address of 0:0:0:0:0:0:0:0 specifies the originator of the Response message.
  • But rather than associate a next-hop address with each route entry as RIPv2 does, RIPng specifies the next-hop address in a special route entry and then groups all route entries that use the next-hop address after it. That is, the next-hop address specified in a next-hop route entry applies to all of the route entries following it, either to the end of the Response message or until another special next-hop route entry is found.

Configuring RIPv2

  • Because RIPv2 is merely an enhancement of RIPv1 and not a separate protocol, the RIPv1 commands are used in exactly the same way. 
  • By default, a RIP process configured on a Cisco router sends only RIPv1 messages but listens to both RIPv1 and RIPv2. This default is changed with the version command.
  • The version 2 command causes RIP to send and listen to RIPv2 messages only.
  • The version 1 command causes RIP to send and listen to RIPv1 messages only.
  • The default behavior can be restored by entering the no version command.
  • The interface-level “compatibility switches” recommended by RFC 2453 are implemented in Cisco IOS with the commands ip rip send version and ip rip receive version.
  • Split horizon can be turned off with the no ip split-horizon on the desired interface.
  • The default behavior of RIPv2 is to summarize at network boundaries the same as RIPv1. To turn off summarization and allow subnets to be advertised across network boundaries, use the command no auto-summary with the RIP process.

RIPv2 Authentication

  • The Cisco implementation of RIPv2 message authentication includes the choice of simple password or MD5 authentication, and the option of defining multiple keys, or passwords, on a “key chain.” The router may then be configured to use different keys at different times.

 key chain Tewa
 key 1
 key-string Kachina
interface Ethernet 0
 ip rip authentication key-chain Tewa
 ip rip authentication mode md5
  • A key chain must be configured, even if there is only one key on it. Although any routers that will exchange authenticated updates must have the same password, the name of the key chain has significance only on the local router.
  • If the command ip rip authentication mode md5 is not added, the interface will use the default clear text authentication.
  • Key management is used to migrate from one authentication key to another.

 key chain Keres
 key 1
  key-string Kachina
  accept-lifetime 16:30:00 Jul 1 2004 duration 43200
  send-lifetime 16:30:00 Jul 1 2004 duration 43200
 key 2
  key-string Kiva
  accept-lifetime 04:00:00 Jul 2 2004 13:00:00 Dec 31 2004
  send-lifetime 04:00:00 Jul 2 2004 13:00:00 Dec 31 2004
 key 3
  key-string Koshare
  accept-lifetime 12:30:00 Dec 31 2004 infinite
  send-lifetime 12:30:00 Dec 31 2004 infinite
!
interface Ethernet0
 ip address 198.168.50.130 255.255.255.192
 ip rip authentication key-chain Keres
 ip rip authentication mode md5

The key numbers are examined from the lowest to the highest, and the first valid key is used.

Configuring RIPng

  • After IPv6 unicast routing is enabled on the router, only one command is required to enable RIPng for IPv6 routing. It is an interface command: ipv6 rip process-name enable. 
  • This creates the RIPng process called process-name and enables RIPng on the interface at the same time. The command is entered on each interface that will run RIPng.
ipv6 unicast-routing
interface Ethernet0
 ipv6 address 2001:db8:0:6::1/64
 ipv6 rip bigMountain enable

 interface Ethernet1
 ipv6 address 2001:db8:0:4::1/64
 ipv6 rip bigMountain enable

 interface Ethernet2
 ipv6 address 2001:db8:0:5::1/64
 ipv6 rip bigMountain enable

  • The RIPng process is created and activated on an interface with a single interface command.
  • This is the difference between configuring RIPv1 and v2, and configuring RIPng. Recall that the RIPv1 and v2 configuration requires a global command (router rip) to create the process, and the network address statement to specify the interfaces on which to run the RIP process.
  • With RIPng, when the interface command ipv6 rip bigMountain enable is configured on the first interface, the RIPng process called bigMountain is automatically created.
  • Notice that the process name is specified on each interface. This name is relevant only to the local router, and is used to distinguish between multiple RIPng processes that might be running on the router.
  • Different interfaces can each run a unique RIPng process, without exchanging information between these interfaces, or multiple processes might be running on a single interface.
  • Only a single RIPv1 or RIPv2 process, on the other hand, can run on a router, and an interface either belongs to this process, or it doesn’t run RIP.
  • No two RIPng routing processes can use the same UDP port number if both processes are going to be active on a single interface.
  • By changing the port number on the smallMountain process, Taos sends updates for smallMountain to UDP port 527, and updates for the bigMountain process to the default RIPng port, UDP 521. Receiving routers use the port number to distinguish which routing process a received update belongs to.
  • All routers and hosts that need to participate in the RIPng process with the modified UDP port number must use the same UDP port number.
  • The smallMountain process is configured to use port 527 in this example. The port number must be changed on the routers exchanging RIPng updates with the smallMountain RIPng process.

ipv6 router rip smallMountain
  port 527 multicast-group FF02::9

interface Ethernet0
 ipv6 address 2001:DB8:0:5::2/64
 ipv6 rip hill enable
 ipv6 rip summit enable
interface Ethernet1
 ipv6 address 2001:DB8:0:20::/64
 ipv6 rip hill enable
interface Ethernet2
 ipv6 address 2001:DB8:0:21::/64
 ipv6 rip summit enable
ipv6 router rip hill
  port 527 multicast-group FF02::9

Taos#show ipv6 rip
RIP process "bigMountain", port 521, multicast-group FF02::9, pid 104
     Administrative distance is 120. Maximum paths is 16
     Updates every 30 seconds, expire after 180
     Holddown lasts 0 seconds, garbage collect after 120
     Split horizon is on; poison reverse is off
     Default routes are not generated
     Periodic updates 1078, trigger updates 5
  Interfaces:
    Ethernet2
    Ethernet0
  Redistribution:
    None
RIP process "smallMountain", port 527, multicast-group FF02::9, pid 117
     Administrative distance is 120. Maximum paths is 16
     Updates every 30 seconds, expire after 180
     Holddown lasts 0 seconds, garbage collect after 120
     Split horizon is on; poison reverse is off
     Default routes are not generated
     Periodic updates 1080, trigger updates 5
  Interfaces:
    Ethernet1
    Ethernet2
  Redistribution:
    None

Taos#debug ipv6 rip
RIP Routing Protocol debugging is on
Taos#
RIPng: Sending multicast update on Ethernet2 for bigMountain
        src=FE80::205:5EFF:FE6B:50A0
        dst=FF02::9 (Ethernet2)
        sport=521, dport=521, length=72
        command=2, version=1, mbz=0, #rte=3
        tag=0, metric=1, prefix=2001:DB8:0:5::/64
        tag=0, metric=1, prefix=2001:DB8:0:6::/64
        tag=0, metric=2, prefix=2001:DB8:0:18::/64

RIPng: Sending multicast update on Ethernet1 for smallMountain
        src=FE80::205:5EFF:FE6B:50A1
        dst=FF02::9 (Ethernet1)
        sport=527, dport=527, length=72
        command=2, version=1, mbz=0, #rte=3
        tag=0, metric=1, prefix=2001:DB8:0:4::/64
        tag=0, metric=1, prefix=2001:DB8:0:5::/64
        tag=0, metric=2, prefix=2001:DB8:0:20::/64

  • The global configuration command ipv6 router rip process_name lets you configure global parameters to that RIPng process.
  • RIPng’s default administrative distance is 120, the same as RIPv1 and v2.
  • The default maximum number of paths over which RIPng will load share is 16. RIPng can load share on up to 64 paths.
  • The timer parameters, although not all the values, are the same as for RIPv1 and v2: update every 30 seconds, expire after 180 seconds, holddown is 0, garbage collection is 120 seconds.

ipv6 router rip bigMountain
  timers 10 30 30 60
  maximum-paths 8
  distance 200

Taos#show ipv6 rip
RIP process "bigMountain", port 521, multicast-group FF02::9, pid 104
     Administrative distance is 200. Maximum paths is 8
     Updates every 10 seconds, expire after 30
     Holddown lasts 30 seconds, garbage collect after 60
     Split horizon is on; poison reverse is off
     Default routes are not generated
     Periodic updates 2513, trigger updates 7
  Interfaces:
    Ethernet2
    Ethernet0
  Redistribution:
    None
RIP process "smallMountain", port 527, multicast-group FF02::9, pid 122
     Administrative distance is 120. Maximum paths is 16
     Updates every 30 seconds, expire after 180
     Holddown lasts 0 seconds, garbage collect after 120
     Split horizon is on; poison reverse is off
     Default routes are not generated
     Periodic updates 2511, trigger updates 0
  Interfaces:
    Ethernet2
    Ethernet1
  Redistribution:
    None
Taos#

The administrative distance is only relevant to the local router, but consider carefully the consequence of changing the administrative distance if multiple routing protocols or routing processes are running on the router and addresses are being learned from multiple routing processes.


Metric Manipulation

  • RIPng metrics are adjusted by adding an offset.
  • RIPng does not, however, increment the metrics of each entry in a list of prefixes.
  • RIPng modifies the hop count that is associated with an interface. This increments the metric of every prefix that is advertised to the router via this interface by the amount of the hop count configured on the interface.
  • By default, RIPng adds a single hop to the metric of prefixes advertised by a neighboring router.
  • To change the value that Taos adds to the received metric, use the metric-offset command

Taos#show ipv6 route rip
IPv6 Routing Table - 15 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B – BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R   2001:db8:0:18::/64[120/2]
     via FE80::204:C1FF:FE50:F1C0, Ethernet0
R   2001:db8:0:10::/64 [120/2]
     via FE80::2B0:64FF:FE30:1DE0, Ethernet1
R   2001:db8:0:11::/64 [120/2]
     via FE80::2B0:64FF:FE30:1DE0, Ethernet1
R   2001:db8:0:12::/64 [120/2]
     via FE80::2B0:64FF:FE30:1DE0, Ethernet1
R   2001:db8:0:13::/64 [120/2]
     via FE80::2B0:64FF:FE30:1DE0, Ethernet1
R   2001:DB8:0:20::/64 [120/2]
     via FE80::204:C1FF:FE50:E700, Ethernet2
R   2001:DB8:0:21::/64 [120/2]
     via FE80::204:C1FF:FE50:E700, Ethernet2

interface Ethernet1
 ipv6 rip smallMountain metric-offset 3

 Taos#show ipv6 route rip
IPv6 Routing Table - 15 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B – BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R   2001:DB8:0:10::/64 [120/4]
     via FE80::2B0:64FF:FE30:1DE0, Ethernet1
R   2001:DB8:0:11::/64 [120/4]
     via FE80::2B0:64FF:FE30:1DE0, Ethernet1
R   2001:DB8:0:12::/64 [120/4]
     via FE80::2B0:64FF:FE30:1DE0, Ethernet1
R   2001:DB8:0:13::/64 [120/4]
     via FE80::2B0:64FF:FE30:1DE0, Ethernet1
R   2001:DB8:0:18::/64 [120/2]
     via FE80::204:C1FF:FE50:F1C0, Ethernet0
R   2001:DB8:0:20::/64 [120/2]
     via FE80::204:C1FF:FE50:E700, Ethernet2
R   2001:DB8:0:21::/64 [120/2]
     via FE80::204:C1FF:FE50:E700, Ethernet2

  • This command allows you to adjust the hop count associated with a given link. 
  • All addresses received by the adjusted interface will have the adjusted metric. 
  • By contrast, RIPv1 and v2 allow you to add the offset to a subset (or all) of the addresses received by the interface before they are added to the route table, or the offset can be added to the addresses just before they are advertised out of the interface.


Route Summarization

  • A router advertises routes for 2001:DB8:0:10::/64, 2001:DB8:0:11::/64, 2001:DB8:0:12::/64, and 2001:DB8:0:13::/64. The routes can be summarized into a single entry: 2001:DB8:0:10::/62.
  • The more specific prefixes are automatically suppressed when an encompassing summary address is configured.

interface Ethernet0
 ipv6 address 2001:DB8:0:4::2/64
 ipv6 rip bigMountain enable
 ipv6 rip bigMountain summary-address 2001:DB8:0:10::/62

 Taos#show ipv6 route rip
IPv6 Routing Table - 12 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B – BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R   2001:DB8:0:10::/62 [120/4]
     via FE80::2B0:64FF:FE30:1DE0, Ethernet1
R   2001:DB8:0:18::/64 [120/2]
     via FE80::204:C1FF:FE50:F1C0, Ethernet0
R   2001:DB8:0:20::/64 [120/2]
     via FE80::204:C1FF:FE50:E700, Ethernet2
R   2001:DB8:0:21::/64 [120/2]
     via FE80::204:C1FF:FE50:E700, Ethernet2

Troubleshooting

  • Two configuration problems common to RIPv2 are mismatched versions and misconfigured authentication. Both difficulties are easy to discover with debugging.
  • A more likely source of trouble with RIPv2 or RIPng, or any classless routing protocol, is a misconfigured variable-length subnet mask.

Jemez#debug ip rip events
RIP event debugging is on
Jemez#
RIP: ignored v1 packet from 172.25.150.249 (illegal version)
RIP: ignored v2 packet from 172.25.150.249 (invalid authentication)
Jemez#

Comments

Post a Comment