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). The inner workings of RIPv1 and summarization I will outline in another post if enough people indicate interest in this post