Introduction

The Routing Information Protocol (RIP) is a distance-vector routing protocol, which employs the hop count as a routing metric. RIP prevents routing loops by implementing a limit on the number of hops allowed in a path from the source to a destination. It is an open standard routing protocol that is used in local area networks (LANs) and small to medium-sized enterprise networks. RIPv2 is defined in RFC-2453 and is an extension of the original Routing Information Protocol (RIP). RIPv2 was widely used in the past for small to medium-sized enterprise networks, but its popularity has decreased over time. This is because RIPv2 has some limitations compared to other routing protocols, such as OSPF and EIGRP, which offer more advanced features and better scalability for larger networks.

The maximum number of hops allowed for RIP is 15. This hop limit, however, also limits the size of networks that RIP can support. A hop count of 16 is considered an infinite distance and used to deprecate inaccessible, inoperable, or otherwise undesirable routes in the selection process. RIPv2 uses UDP destination port 520.

In an effort to avoid unnecessary load on hosts that do not participate in routing, RIPv2 multicasts the entire routing table to all adjacent routers at the address 224.0.0.9, as opposed to RIPv1 which uses broadcast. Unicast addressing is still allowed for special applications. You can use Clavister cOS Core to allow RIPv2 routers placed on separated physical interfaces to exchange multicast routing messages.

Note: Clavister cOS Core does not support RIP but can be configured to allow the needed traffic to pass through it.

Configuring cOS Core

IP settings

In order to allow multicast messages to be forwarded we must change the ‘Multicast TTL Min’ value in the Clavister security gateway. By default multicast messages with TTL values lower than 3 will be dropped. This needs to be changed to 1.

Service

Before we start we create a service for the RIPv2 port needed as shown below.

IP policy setup

In this example we create two Multicast IP policies for the respective RIPv2 routers, in this example we have two RIPv2 routers placed behind the interfaces called WAN and LAN.

Let´s start by creating an IP policy for our primary router located on the “LAN” interface. The router sends multicast messages to 224.0.0.9 which should be received by a router located on the WAN interface. The first IP policy in this example is a Multicast policy that forwards the router exchange traffic destined to address 224.0.0.9, which is the RIPv2 multicast address, to find adjacent routers and exchange routing tables. We create a multicast IP policy that will allow traffic from the router that sends the multicast messages. Follow the configuration image and make sure that the destination address is set to 224.0.0.9. Change the interfaces and source IP to the corresponding router IP in your configuration when appropriate if we want to further restrict the IP policy to only allow RIPv2 from the actual router(s), in this example we leave things fairly open but it is recommended to restrict it more before going live (can be useful for testing purposes).

We need to make sure to tell the firewall where to forward the messages that we receive from the RIPv2 router on the LAN interface in this example, we do that by adding the WAN interface a under the destination translation option, we leave the IP address field blank (don’t forget to press the plus button when adding). Make sure to uncheck the “Require IGMP” check-box(1). We do not want to create additional IGMP rules in order to forward the RIPv2 traffic.

Create one more multicast IP policy for the opposite direction from the interface WAN to LAN (and change the destination translation interface to be LAN). When done the IP rule section should look like this.

Now our RIPv2 routers will be able to exchange their routing tables when they are located on separate interfaces in the Clavister firewall. The firewall will receive the multicast message and forward it to the corresponding interface.

Related articles