0

I have the following topology. I am using RIP Version 1 routing protocols. As far as i know RIP supports only classful IP addresses. So it should send 10.0.0.0 routes only.

enter image description here

enter image description here But when I run debug ip rip command i see that it is sending 10.1.0.0, 10.2.0.0 etc and not 10.0.0.0. I have not touched any auto summarization settings. Also i am not getting any updates from router 4 nor it is getting any updates from other routers and hence i can't ping that router.

Can anyone please explain whats happening here and clear my doubt regarding classless and classful ip advertisements in RIP.

  • 2
    Please, never use an image for text. Copy the text and paste it into your question, then use the Preformatted-Text option ({}) on it. – Ron Maupin Jan 9 '18 at 18:11
  • Thanks for the info Ron. I am new to stake exchange. Will keep that in mind next time. – Shubham Kumar Jan 9 '18 at 18:28
7

RIP is classful only in the sense of the network command in the routing process. The network command does not accept a mask, and automatically assumes the classful mask of the IP you enter.

RIP does not advertise network masks. In fact, it only advertises network IDs. Moreover, RIP only advertises network IDs of networks it knows about that match the outgoing interface's subnet mask.

A receiving router will take the received advertised Network ID and apply the subnet mask belonging to the receiving interface.

I wrote about the specific workings on a reddit post. I'll add that here for additional details / context.

Quoted from https://www.reddit.com/r/ccna/comments/7ce90v/what_rip_advertises_definitive_proof/

What RIP actually advertises:

There is some confusion about RIP and what/how it advertises routes, so I thought I'd put together this little example to settle the question definitively.

RIP (v1) is a routing protocol built in the FLSM days - Fixed Length Subnet Masking. This is how networks were built before VLSM (Variable length subnet masking).

In FLSM, every subnet in your network was the same size. This spared routing protocols from the burden of having to share a subnet mask with each network that was advertised. Hence, when RIP advertises a route, it only shares the Network ID -- no subnet mask is included. But let's prove that...

Topology and Base Configuration

Here is the topology we are using:

+----------+           +----------+           +----------+
|          |e0/0       |          |e0/1       |          |
|    R1    +-----------+    R2    +-----------+    R3    |
|          |       e0/0|          |       e0/1|          |
+----------+           +----------+           +----------+

The link between R1 and R2: 172.20.12.0/27

The link between R2 and R3: 172.20.23.0/29

R1 has the following loopbacks configured:

interface Loopback25
 ip address 172.20.125.1 255.255.255.128
interface Loopback26
 ip address 172.20.126.1 255.255.255.192
interface Loopback27
 ip address 172.20.127.1 255.255.255.224
interface Loopback28
 ip address 172.20.128.1 255.255.255.240
interface Loopback29
 ip address 172.20.129.1 255.255.255.248

R2 has the following loopbacks configured:

interface Loopback25
 ip address 172.20.225.2 255.255.255.128
interface Loopback26
 ip address 172.20.226.2 255.255.255.192
interface Loopback27
 ip address 172.20.227.2 255.255.255.224
interface Loopback28
 ip address 172.20.228.2 255.255.255.240
interface Loopback29
 ip address 172.20.229.2 255.255.255.248

Advertising Networks

You'll notice R1 and R2 have five loopbacks all different sizes, but all from the same classful range of 172.20.0.0/16. We will use this to enable RIP on all interfaces on the routers:

router1(config)#router rip
router1(config-router)#network 172.20.0.0

router2(config)#router rip
router2(config-router)#network 172.20.0.0
 After giving RIP a few minutes to converge, here are the results:

router1#show ip route rip
R        172.20.227.0/27 [120/1] via 172.20.12.2, 00:00:25, Ethernet0/0

router2# show ip route rip
R        172.20.127.0/27 [120/1] via 172.20.12.1, 00:00:05, Ethernet0/0

You'll notice that despite there being 5 loopbacks in the 172.20.0.0/16 range, only one of them was advertised from each router: R1 advertised 172.20.127.0/27 and R2 advertised 172.20.227.0/27.

The reason is RIP only advertises networks when they match the outgoing interface's subnet mask. Between R1 and R2 was a /27, and therefore only the /27 loopback was advertised between R1 and R2.

Remember, RIP was written for the FLSM days, which means RIP expects every network to be the same size.

What gets advertised to R3?

Let's now enable RIP on R3 and see what happens. Recall that the link between R2 and R3 is 172.20.23.0/29.

router3(config)#router rip
router3(config-router)#network 172.20.0.0

After giving RIP a few minutes to converge, here is what R3 learns:

router3# show ip route rip
R        172.20.229.0/29 [120/1] via 172.20.23.2, 00:00:06, Ethernet0/1

Notice, despite R2 having learned of the /27 network from R1 from RIP, R2 did not forward that route to R3 because the link between R2 and R3 is a /29, therefore R2 only forwarded /29 networks to R3.

R3, having no /29 networks (other than the one it was directly connected to) had nothing to advertise to R2. Hence R2's routing table did not change when we enabled RIP on R3:

router2# show ip route rip 
R        172.20.127.0/27 [120/1] via 172.20.12.1, 00:00:18, Ethernet0/0

Proving the behavior with one final test:

The last piece to show really just affirms the behavior of RIP. Let's go ahead and MISconfigure the link between R1 and R2:

router1(config)#int eth0/0
router1(config-if)#ip address 172.20.12.1 255.255.255.240

R1 was just configured with 172.20.12.1/28 and R2 will be left configured with 172.20.12.2/27. Yes, the networks are different sizes, but the routers will still be able to ping each other:

router2#ping 172.20.12.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.20.12.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/6 ms

I also went ahead and 'bounced' the RIP process by doing a no router rip and then re-enabling it on all routers with the network 172.20.0.0 command.

After a few minutes, we will take a look at what R1 and R2 have learned from each other:

router2# show ip route rip | i ^R
R        172.20.128.0/27 [120/1] via 172.20.12.1, 00:00:14, Ethernet0/0

The result: R1's interface IP is in a /28 network, and advertised the network ID of 172.20.128.0 -- R1's only /28 loopback.

When R2 received the network ID 172.20.128.0, it applied its own interface subnet size of /27. And therefore assumed (incorrectly) the received advertisement to be for 172.20.128.0/27 when in fact this network is actually a /28.

The same thing happened on the other side:

router1#show ip route rip | i ^R
R        172.20.227.0/28 [120/1] via 172.20.12.2, 00:00:13, Ethernet0/0

R2's interface IP is in a /27 network, and therefore advertised the network ID172.20.227.0 -- which is the network ID of the only /27 R2 knows about.

When R1 received it, it applied the local interface's size of /28 and therefore added 172.20.227.0/28 to the routing table.

This proves, definitively, what RIP chooses to advertise, and the manor in which it advertises it. Which is summarized below.

Summary / TLDR

RIP will advertise the Network ID of all networks that match the outgoing interface's subnet size.

The receiving router will apply the local interface's subnet mask size to all received Network IDs.

*The above does not account for or reveal how RIP's summarization works. All of the above was done with summarization enabled (the default behavior of RIPv1).

2

This is done due to the processing that RIP does with updates.

For further understanding, class routing protocols as RIPv1 do not include subnet mask in the routing update. Nevertheless, the routing table includes RIPv1 routes with the net address as with the subnet mask.

How would a router that runs RIPv1 determine the subnet mask that it must apply to a route added to the routing table?

Here we have the rules to process RIPv1 routes:

  • If an routing update and the interface for which it was received belong to the same principal net, it aplies the subnet mask of the interface to the net in the routing update.
  • If the routing update and the interface over which it is received belong to different main nets, it applies the subnet mask with class of the net to the net in the routing update.
2

(Only classful in RIP? - had to look that up) RIPv1 uses classful routes which is one of the reasons it shouldn't be used any more.

RIPv2 (RFC 2080) uses CIDR, doesn't transmit the complete routing table over and over again, leverages multicast (v1 uses broadcasts) and should be preferred over RIPv1 at all times.

On a somewhat larger network you should consider to use a link-state routing protocol like OSPF instead of the aged distance-vector concept.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.