RIP

CCIE Jan 1, 2013

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

Tags

Rob Edwards

Northern (UK) chap focusing on platforms, automation, cloud and cloud native applications. Recovering network engineer, although it turns out networking is as important, if not more, now than before!

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.