General RIP

  • UDP-520

  • 2 message types; - Request Message (used to ask neighbours to send updates)

  • Response Message (Carries an update)

  • Metric is hop-count

  • On startup RIP broadcasts a request message packet out each RIP enabled interface - The RIP process then enters a loop - Listening for RIP requests OR

  • Response message from other routers

  • Neighbours receiving the ‘request’ send a ‘response’ containing their routing table

  • When the requesting router receives the response message it processes the enclosed information - If particular route entry is new it is entered into the routing table along with address of advertising router (taken from source IP of the packet)

  • If the route is for a network that RIP has already entered, and the new route has a lower metric the existing entry will be replaced - If the advertised hop count is higher than the recorded hop-count and the update originates by the recorded next-hop the route will be marked as unreachable for a specific holddown timer (this feature is not part of the stability features of RFC1058 but Cisco specific)

  • If at the end of the time the same neighbour is still advertising the higher hop count the new metric will be accepted

  • Router sends a ‘response’ message out every RIP interface every 30 seconds (full table)

  • Timers - Update: 30 seconds

  • Expiration/invalid timer = 180 seconds

  • Flush timer = 240 seconds (route will be advertised with metric 16)

  • Hold-down timer = 180 seconds (a route update with higher hop count than current metric)

  • The 4 timers can be manipulated with;

timers basic # applies to the entire RIP process

  • ALL timers in the RIP domain must match
  • The flash-update-threshold command suppresses flash updates when the arrival interval of a regularly scheduled update matches, or is less than the number of seconds that is configured (example 10 seconds). The range is 0 – 30 seconds.
  • RIP employs - Split-horizon with poison reverse (INSERT LINK TO SEPARATE BLOG ENTRY)
  • Triggered updates
  • A triggered update occurs whenever the metric for  certain route has changed and might include only the entry or entries that have changed - these don’t cause the receiving router to reset its update timer
  • To avoid a triggered update storm after a topology change another timer is employed - When triggered update is sent the timer is randomly set (between 1 & 5 seconds)
  • Subsequent updates (triggered) cannot be sent until the timer expires
  • Each RIP message can contain entries for 25 routes - If more they will be sent over multiple RIP messages
  • ECMP balancing used when equal hop counts
  • Initial portion of the message is 4 octets - each route entry is 20 octets

therefore max message size is 4 + (25×20) = 504 octets

+8 byte UDP header = 512 octets (ex IP header)


RIPv2 has the following extensions;

  • Subnet mask carried with each route entry
  • Authentication of routing updates
  • Next-hop address carried with each route entry
  • External route tags
  • Multicast route updates

Multicast updates to

When authentication is enabled the max number of entries a single update can carry is 24


  • RIPng for IPv6 is based on RIPv2
  • Same timers
  • Multicast update to FF02::9
  • No authentication built is a ti relies on the authentication features built into IPv6
  • Sends and receives its messages on UDP-521


RFC 1058 – RIP

RFC 2091 – Triggered Extension to RIP to support demon circuits

RFC 1723 – RIPv2

RFC 1723 – RIP Authentication

RFC 1321 – MD5

RFC 2453 – RIPv2

RFC 2080 – RIPng for IPv6