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

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 224.0.0.9

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

RIPng

• 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

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