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 routes only.

enter image description here

enter image description here But when I run debug ip rip command i see that it is sending, etc and not 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, 2018 at 18:11
  • Thanks for the info Ron. I am new to stake exchange. Will keep that in mind next time. Jan 9, 2018 at 18:28

3 Answers 3


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:

The link between R2 and R3:

R1 has the following loopbacks configured:

interface Loopback25
 ip address
interface Loopback26
 ip address
interface Loopback27
 ip address
interface Loopback28
 ip address
interface Loopback29
 ip address

R2 has the following loopbacks configured:

interface Loopback25
 ip address
interface Loopback26
 ip address
interface Loopback27
 ip address
interface Loopback28
 ip address
interface Loopback29
 ip address

Advertising Networks

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

router1(config)#router rip

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

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

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

You'll notice that despite there being 5 loopbacks in the range, only one of them was advertised from each router: R1 advertised and R2 advertised

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

router3(config)#router rip

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

router3# show ip route rip
R [120/1] via, 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 [120/1] via, 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

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

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, 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 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 [120/1] via, 00:00:14, Ethernet0/0

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

When R2 received the network ID, it applied its own interface subnet size of /27. And therefore assumed (incorrectly) the received advertisement to be for 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 [120/1] via, 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 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).


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.

(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 and acknowledge you have read our privacy policy.

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