RIP Packet Format – Detailed Analysis

they are assigned by default to 172.16.0.0 in both cases, and it does not work

I modified your ascii art a litte to reduce scrolling... It sounds like you're saying that you can't reach reach N1 from N2...

Broken RIPv1 topology
=====================

N1 ---- (172.16.1.1/24) R1 (172.16.3.1/30) ----- (172.16.3.2/30) R2 ----- (172.16.2.1/24) N2

Classful routing protocol overview

RIPv1 is a classful routing protocol... as such, it doesn't associate netmasks with routes when they are advertised. Classful routing protocols do a couple non-intuitive things...

1. They only advertise routes out interfaces where the masks match (this is your problem)
2. They automatically summarize at major network boundaries (see bonus material, below)

Interface netmasks

To make your topology work, your masks will have to match on all RIPv1 interfaces, unless you use a classless routing protocol (such as RIPv2, EIGRP, OSPF, or ISIS). If you need to use RIPv1, then reconfigure your topology such that all interfaces have matching masks, like this...

Functional RIPv1 topology
=========================

N1 ---- (172.16.1.1/24) R1 (172.16.3.1/24) ----- (172.16.3.2/24) R2 ----- (172.16.2.1/24) N2

Bonus material: RIPv1 Auto-summarization Example

Since this also tends to trip people up, I am including an example of RIPv1 auto-summarization dynamics.

When I mention major network boundaries below, I'm talking about the classic definitions for Class A, Class B, and Class C IPv4 networks...

• Class A (8-bit netmasks): 1.0.0.0/8 - 127.0.0.0/8
• Class B (16-bit netmasks): 128.0.0.0/16 - 191.255.0.0/16
• Class C (24-bit netmasks): 192.168.0.0/24 - 223.255.255.0/24

Moving on to the RIPv1 auto-summarization example... I will use matching /24 interface netmasks for simplicity.

Lo0:
192.168.1.0/24
Lo1:
1.1.2.0/24
+----+                  +----+                     +----+
| R1 +------------------+ R2 +---------------------+ R3 |
+----+                  +----+                     +----+
          1.1.1.0/24              172.16.1.0/24

router rip               router rip                 router rip
 version 1                version 1                  version 1
 network 192.168.1.0      network 1.0.0.0            network 172.16.0.0
 network 1.0.0.0          network 172.16.0.0

The routing table on R3 contains:
C     172.16.1.0/24
R     1.0.0.0/8        <--- 1.1.1.0/24 and 1.1.2.0/24 are "hidden" by the 
                            classful summary at R2

R     192.168.1.0/24   <--- 192.168.1.0/24 passes transparently through R2
                            since it's a Class C network itself and is not 
                            summarized at R2

R1 and R2 are connected by subnets of the 1.0.0.0/8 major network, so 1.1.1.0/24 and 1.1.2.0/24 are advertised between R1 and R2; however, the link between R2 and R3 is not in 1.0.0.0/8, therefore R2 performs automatic summarization of subnets of 1.0.0.0/8 and subnets of 172.16.0.0/16.

When subnets of a major network are summarized, they get hidden by the summarized route... This happens at R2 when 1.1.1.0/24 and 1.1.2.0/24 are summarized to 1.0.0.0/8. Cisco routers cannot disable auto-summarization under RIP version 1 (but they can for RIPv2).

Most of the references say "RIP is not scalable" hence can be used only in smaller networks. But none say "WHY?" What is that in RIP that actually preventing it from scaling to larger networks? And HOW OSPF overcomes the disadvantage of RIP?

Summary

• RIPv1 floods routes frequently (every 30 seconds), which introduces large CPU loads as the size of the routing table increases. This is compounded by the reality that RIP recalculates metrics for every route, every time it floods the route out a new interface (regardless of whether there was a topology change or not). As the number of routes increases, this is prevents RIP from scaling as well as other protocols.
• RIPv1 is classful
• OSPF floods routes infrequently. If there is a topology change in the network, only the LSAs changed are flooded; metrics are calculated on these changes. As such, on-demand route calculations, on LSAs which are flooded infrequently, make OSPF scale well.
• OSPF is a classless protocol, which supports CIDR, which also makes it a more scalable protocol than RIPv1

RIPv1 Details:

RIP is a Distance Vector protocol; all Distance Vector protocols run the Bellman-Ford algorithm. At a high level, this means:

• All routes in the routing table are periodically announced through all interfaces.
• RIP floods routes out every RIP interface every 30 seconds. Since RIP routes by rumor, this means every router in the topology must work in direct proportion to the size of the routing table every 30 seconds. The CPU load and traffic jitter implications of this become scary as you approach thousands of routes (particularly on CPU-based routers with no hardware forwarding).
• The RIP protocol itself has a fixed maximum hop-count at 15 hops (which is small if you need to do any form of path-weighting).
• Protocols based on Bellman-Ford algorithms are prone to routing loops, and count-to-infinity issues.

OSPF Details:

By way of contrast, OSPF is a link-state protocol running Dijkstra's algorithm. As such:

• Each router only announces its directly connected and redistributed routes in routing updates (called LSAs).
• Each router floods their own LSA every 30 minutes by default (because the route refresh timer is 3600 seconds, or 1 hour)
• LSAs are also flooded when triggered by changes in the routing table
• Routers use Dijkstra's algorithm to perform distributed LSA path calculations only when necessary.