RIP configuration part 1
CCIE blueprint: 3.4.a Implement and troubleshoot RIPv2
This post is part of a multipost series about RIP. Other posts in this series are:
- RIP
- RIP configuration part 2
- RIP authentication
- RIP summarization
- Miscelanious RIP commands
- RIPng
This post will cover the configuration of RIP. Basic RIP configuration is peanuts and done in seconds. There are some additional features that can be configured, but most of the time these won’t really be necessary. This post will cover the following configuration items for RIP:
- Generic configuration
- Broadcast and Unicast updates and passive interfaces
- Split Horizon
This post become so large I decided to split it into two parts. Part two will follow shortly.
Generic configuration
Like I said, the generic configuration of RIP is very simple. It actually can consist of two commands, but in most cases it will be a little more. The most basic configuration for RIP is as follows:
router rip
network 0.0.0.0
This will enable RIPv1 on all interfaces on the router. This is probably not what you want. You will want to be running RIPv2 and you will want to disable auto-summary (why that is will be explained in the RIP summarization post). Your basic configuration will then change into the following:
router rip
version 2
no auto-summary
network 0.0.0.0
Still very simple right? This will enable RIPv2 on all interfaces and will disable auto-summary. Of course you can change the network statement to reflect your actual network.
Broadcast and Unicast updates and passive interfaces
There are some scenario’s in which the multicast traffic originated by RIPv2 is not what you want. This might be because you are on a medium that does not support multicast, or there are other reasons why you are not able or do not want to use multicast. For these scenario’s it is possible to use broadcast or unicast updates. You might wonder why this paragraph includes the seemingly unrelated topic of passive interfaces, but this will become clear in a few moments.
Broadcast updates
Enabling broadcast is done on a per interface level. It consists of a single command:
interface gigabitEthernet 0/1.58
ip rip v2-broadcast
This will disable multicast updates on the interface and enable broadcast updates. You do not need to enable this command on both sides of the link (even though it would probably not make sense not to do so) The following image shows the change on the wire when changing from multicast to broadcast.
Unicast updates
Enabling unicast updates is less straightforward than enabling broadcast updates. To enable unicast updates we first have to configure neighbors under the RIP process.
R8(config)#router rip
R8(config-router)#neighbor 155.1.58.5
This will enable unicast updates to that specific neighbor. However, when we look at the traffic capture we will notice something strange.
R8 still originates updates to the multicast address of 224.0.0.9 alongside the unicast updates. This is probably not what we want, so we want to disable the multicast updates. This can be done by making the interface passive.
Making an interface passive is also done under the RIP process:
R8(config)#router rip
R8(config-router)#passive-interface g0/1.58
When we take a new look at the traffic captures we see that the unicast updates are still sent by R8, but that it is no longer originating multicast updates on the interface.
In the image you can still see the broadcast updates originated by R5. This is not a problem. Both router will learn routes from each other even though their communication method is configured differently. This can be verified by looking at the routing table. (Filtered to show only relevant information)
R5:
R 150.1.8.8 [120/1] via 155.1.58.8, 00:00:22, GigabitEthernet0/1.58
R 150.1.10.10 [120/2] via 155.1.58.8, 00:00:22, GigabitEthernet0/1.58
R 155.1.8.0/24 [120/1] via 155.1.58.8, 00:00:22, GigabitEthernet0/1.58
R 155.1.10.0/24 [120/2] via 155.1.58.8, 00:00:22, GigabitEthernet0/1.58
[120/1] via 155.1.58.8, 00:00:22, GigabitEthernet0/1.58
R8:
R* 0.0.0.0/0 [120/2] via 155.1.58.5, 00:00:11, GigabitEthernet0/1.58
150.1.0.0/32 is subnetted, 7 subnets
R 150.1.1.1 [120/2] via 155.1.58.5, 00:00:11, GigabitEthernet0/1.58
R 150.1.2.2 [120/2] via 155.1.58.5, 00:00:11, GigabitEthernet0/1.58
R 150.1.3.3 [120/2] via 155.1.58.5, 00:00:11, GigabitEthernet0/1.58
R 150.1.5.5 [120/1] via 155.1.58.5, 00:00:11, GigabitEthernet0/1.58
Split Horizon
Split horizon is a technique that is used to help prevent routing loops. Simply put it boils down to the following rule: Don’t advertise information received on an interface out of the same interface. This makes sure that if I tell you the network 10.0.0.0/8 is reachable through me, you don’t tell me the 10.0.0.0/8 network is reachable through you. Unless you know a different route to the same network. This can be seen in the debug (debug ip rip) output below.
For this example I created a very simple 3-node network where all nodes are connected to each other. The router used are R1, R3 and R6. These routers all have loopback addresses in the format of 150.1.x.x where x is the router number.
In the example, shown from the viewpoint of R3 we can see that R3 sends an update to R6 containing the loopbacks of R1 and R3. It sends an update to R1 containing the loopbacks of R3 and R6. After that it receives an update from R1 containing the loopbacks of R1 and R6 and an update from R6 containing the loopbacks of R1 and R6.
R3#
RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/1.36 (155.1.36.3)
RIP: build update entries
150.1.1.1/32 via 0.0.0.0, metric 2, tag 0
150.1.3.3/32 via 0.0.0.0, metric 1, tag 0
155.1.13.0/24 via 0.0.0.0, metric 1, tag 0
RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/1.13 (155.1.13.3)
RIP: build update entries
150.1.3.3/32 via 0.0.0.0, metric 1, tag 0
150.1.6.6/32 via 0.0.0.0, metric 2, tag 0
155.1.36.0/24 via 0.0.0.0, metric 1, tag 0
RIP: received v2 update from 155.1.13.1 on GigabitEthernet0/1.13
150.1.1.1/32 via 0.0.0.0 in 1 hops
150.1.6.6/32 via 0.0.0.0 in 2 hops
155.1.16.0/24 via 0.0.0.0 in 1 hops
RIP: received v2 update from 155.1.36.6 on GigabitEthernet0/1.36
150.1.1.1/32 via 0.0.0.0 in 2 hops
150.1.6.6/32 via 0.0.0.0 in 1 hops
155.1.16.0/24 via 0.0.0.0 in 1 hops
From this we can see that R3 never gets it’s own loopback announced back to it. This would be impossible since there are no other routes to it than via R3 itself. It does get the loopbacks of R1 and R6 announced from both neighbors and it announces the loopbacks of both of its neighbors to the other neighbor. This means that for example both R1 and R3 announce the same network to each other (150.1.6.6) regardless of the split horizon rule. This is because they both have a different path to that network. They will never announce the network back to each other if they did not have another route.
We can verify that by shutting the link between R1 and R6. In that case R1 will use the path through R3 to get to R6 and will stop advertising the network to R3.
R3#
RIP: received v2 update from 155.1.13.1 on GigabitEthernet0/1.13
150.1.1.1/32 via 0.0.0.0 in 1 hops
150.1.6.6/32 via 0.0.0.0 in 16 hops (inaccessible)
155.1.16.0/24 via 0.0.0.0 in 16 hops (inaccessible)
RIP: received v2 update from 155.1.36.6 on GigabitEthernet0/1.36
150.1.1.1/32 via 0.0.0.0 in 2 hops
150.1.6.6/32 via 0.0.0.0 in 1 hops
155.1.16.0/24 via 0.0.0.0 in 1 hops
RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/1.36 (155.1.36.3)
RIP: build update entries
150.1.1.1/32 via 0.0.0.0, metric 2, tag 0
150.1.3.3/32 via 0.0.0.0, metric 1, tag 0
155.1.13.0/24 via 0.0.0.0, metric 1, tag 0
RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/1.13 (155.1.13.3)
RIP: build update entries
150.1.3.3/32 via 0.0.0.0, metric 1, tag 0
150.1.6.6/32 via 0.0.0.0, metric 2, tag 0
155.1.16.0/24 via 0.0.0.0, metric 2, tag 0
155.1.36.0/24 via 0.0.0.0, metric 1, tag 0
RIP: received v2 update from 155.1.13.1 on GigabitEthernet0/1.13
150.1.1.1/32 via 0.0.0.0 in 1 hops
RIP: received v2 update from 155.1.36.6 on GigabitEthernet0/1.36
150.1.1.1/32 via 0.0.0.0 in 2 hops
150.1.6.6/32 via 0.0.0.0 in 1 hops
155.1.16.0/24 via 0.0.0.0 in 1 hops
Here we can see that on the moment the link on R1 goes down it advertises the networks 150.1.6.6 and 155.1.16.0 with a metric of 16, which means that the network is unreachable. This will cause any other routers using that route to remove it from the routing table. We also see R3 announcing the loopback of R6 to R1. R1’s update now consists of just one network, being its own loopback. This is the split horizon rule in action.
You might have noticed R6 continuing to advertise the route to R1’s loopback. This is because the link on R6’s side did not go down. Because of this R6 remains in the assumption it can reach R1’s loopback via the G0/1.16 link. This is not the case, but it will take R6 three minutes to figure this out. This is because the routers are not connected back to back, but are using a switch in between. Because of this the physical line at R6 never went down. This can be solved using BFD which we will cover later in this post.
So, you might think Split Horizon looks and sounds great. How do I configure it. The answer is you don’t. So why all this trouble of explaining it, moreover in a post about configuration? Because you can disable it.
But, but why? Why would I want to do that?
Sometimes you might have a network that is point to multipoint non broadcast. This will mean that the devices on the spoke end will not be able to communicate with each other directly. The hub router will have multiple routers connected to a single interface. That single interface will receive routing updates from all spokes containing the networks at the spoke site. (say for example a main office as the hub and several regional offices as the spokes). When Split Horizon is enabled these networks will never be able to reach each other. (you can also solve this with a default route).
Disabling Split Horizon will make the hub able to advertise all the routes back to the spokes. The spoke originally originating the update should ignore the update when it comes back in.
So if we disable split horizon in our little network, what will happen? Let’s take a look.
The configuration of Split horizon is very simple. On the interface it’s just one command:
R1(config)#int g 0/1.13
R1(config-subif)#no ip split-horizon
The effect is drastic. Where R1 first only advertised its own loopback, now it advertises everything:
Before:
R1#
RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/1.13 (155.1.13.1)
RIP: build update entries
150.1.1.1/32 via 0.0.0.0, metric 1, tag 0
After:
RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/1.13 (155.1.13.1)
RIP: build update entries
150.1.1.1/32 via 0.0.0.0, metric 1, tag 0
150.1.3.3/32 via 155.1.13.3, metric 2, tag 0
150.1.6.6/32 via 155.1.13.3, metric 3, tag 0
155.1.13.0/24 via 0.0.0.0, metric 1, tag 0
155.1.16.0/24 via 155.1.13.3, metric 3, tag 0
155.1.36.0/24 via 155.1.13.3, metric 2, tag 0
So, is that a bad thing? Like I explained earlier, it does not have to be. However, it can be a major issue impacting the stability of your network. This might lead to a race condition where several routers think they have a route to a destination while that route is not available. This will result in the metric increasing untill 16 is reached. This behaviour is called ‘counting to infinity’
