Why does RIP resend its whole routing table every 30 seconds instead of only changes, and what does that cost for 1,000 routes?
answer
- no sessions, no acknowledgements
- the update is the keepalive
- 25 entries per message
- 20 bytes per entry
basics
~20 sRIP keeps no neighbour state and sends no acknowledgements, so the periodic full table is both the refresh and the liveness signal; 1,000 routes take 40 Response datagrams, about 21 KB per interface every 30 seconds.
solid answer
~40 sRIP runs over UDP port `520` with no sessions, sequence numbers or acknowledgements. Resending everything every 30 seconds makes that work: a lost datagram is repaired by the next cycle, a rebooted neighbour relearns every route (it also sends a whole-table Request on start-up), and the arrival of each route resets its 180-second timeout, so the update doubles as the keepalive. The price is constant traffic and processing. A Response holds at most 25 route entries of 20 bytes behind a 4-byte header, so 1,000 routes need 40 datagrams of 504 bytes, 532 with IPv4 and UDP headers: 21,280 bytes per interface per cycle, about 5.7 kb/s. The bandwidth is trivial on modern links; every router reprocessing every entry every 30 seconds, forever, is the real cost.
go deeper
Recall that RIP sends its entire routing table to its neighbours every 30 seconds over UDP port 520.
Explain how the periodic full table replaces acknowledgements and keepalives, and how a starting router asks for the table with a Request.
Compute the message count and bytes for a given table size and say why processing, bursts and permanent chatter, not bandwidth, are the real costs.
Weigh statelessness against explicit neighbour tracking and change-only updates when choosing a routing protocol for a network expected to grow.
## What RIP leaves out RIP is deliberately simple. It runs over **UDP port 520** and has: - no neighbour discovery and no session with each neighbour; - no acknowledgements and no retransmission of lost messages; - no sequence numbers saying which version of a route is newer; - no hello packet separate from the routing update. A protocol that sent only changes would need all of those, to know who had received which change and to repair a gap. RIP avoids the machinery by repeating the whole table. ## Why the full table makes the protocol work The periodic Response does several jobs at once: 1. **It repairs loss.** A dropped datagram costs nothing permanent: the same routes arrive again in 30 seconds. That is also why RFC 2453 waits 180 seconds, six intervals, before declaring a route dead. 2. **It is the keepalive.** Each update for a route resets that route's timeout. A neighbour is considered alive exactly as long as its routes keep arriving. 3. **It resynchronises late joiners.** A router that reboots or joins the link learns everything within one interval. RFC 2453 also lets it ask: on start-up it sends a **Request** with a single entry of address family 0 and metric 16, which means "send me your entire table". 4. **It keeps state small.** A router stores only its table and per-route timers; there is no per-neighbour database to keep consistent. Triggered updates, sent when routes change, may carry only the changed entries, but they supplement the periodic full table and never replace it. ## The message layout RFC 2453's Response message: | Part | Size | |---|---| | RIP header: command, version, must-be-zero | 4 bytes | | Each route entry (RTE) | 20 bytes | | Route entries per message | 1 to 25 | | Largest message | 4 + 25 x 20 = 504 bytes | A table longer than 25 entries is split across several Responses; the RFC sets no limit on how many datagrams one update can take. RFC 1058 states the maximum RIP datagram as 512 octets, counted from the RIP header and excluding IP and UDP headers; 504 fits within it. In RIPv2, authentication takes the place of the first entry, leaving room for 24 routes; the version details live with RIPv1 and RIPv2. ## The cost for 1,000 routes Assume 1,000 routes, IPv4 without options, no authentication, and that the whole table goes out on an interface: 1. Messages: 1,000 / 25 = **40** Responses. 2. Each message: 4 + 25 x 20 = 504 bytes of RIP, plus 8 bytes of UDP and 20 of IPv4 = **532 bytes**. 3. Per cycle: 40 x 532 = **21,280 bytes** per interface. 4. Per second: 21,280 / 30 = about **709 bytes/s**, roughly **5.7 kb/s**. Split horizon, part of RIP's loop-prevention rules, can leave out the routes learned through that interface, so the real figure on a given link can be smaller. ## Where the real cost lies - **Bandwidth is small** on modern links, which is why the cost argument against RIP is rarely about the wire. - **Processing is constant.** Every router validates and re-evaluates every received entry every 30 seconds, whether or not anything changed, and resets one timer per route. - **Bursts.** Forty datagrams leave together; on a busy segment several routers doing the same at once is why RFC 2453 requires precautions against their timers drifting into step. - **Nothing scales the chatter down.** A network that has not changed in a month still exchanges its entire state twice a minute on every link. - **Scale hits other limits first.** The 15-hop diameter and minutes-long convergence usually rule RIP out before table size does. ## The trade in one line RIP buys statelessness and self-repair with permanent repetition. That is reasonable for a small network with few routes, and the reason protocols for larger networks track neighbours explicitly and send changes instead.
- What does a RIP router do when it boots, rather than waiting 30 seconds for its neighbours?It sends a Request on every connected network asking for the complete table: RFC 2453 defines a Request with exactly one entry, address family identifier 0 and metric 16, as a request for the whole routing table. Neighbours answer with their full table, split-horizon processing included, and the new router fills in its routes at once.
- Why is the bandwidth of RIP's periodic updates rarely what limits its use?At 25 entries of 20 bytes per message, even 1,000 routes cost only about 5.7 kb/s per interface. RIP runs into its 15-hop diameter, its minutes-long convergence and the processing of every entry every 30 seconds well before the bytes on the wire matter.
saying these in an interview costs you the question
- RIP sends only the changed routes once neighbours are in sync.
- RIP runs over TCP, so its updates are acknowledged.
- A single RIP Response can carry the whole table, however large.
- Full-table updates are pure waste with no benefit.
- RIP neighbours form a session before exchanging routes.