Tuesday 2 May 2017

RIPv2 Network Engineers Notes

RIPv2 General Characteristics.

  • Classless
  • Distance-Vector
  • Timer-based
Attribute Value
Transport Protocol UDP 520
Metric Hop Count, Max = 15 , 16 <- Infinite/Unreachable
Hello interval No Hellos are used.  Relies on regular full routing updates instead.
Update Destination 224.0.0.9 - Multicast for RIPv2
Update Interval 30 Sec


Example Topology




Steady State Route Exchange Info


  • Sends routing updates every 30 seconds by defaults - destined to the multicast address 224.0.0.9
  • Each update contains the full list of routes known to the router along with the metric.


Route Updates and Failure Handling
  • Any new route become known to the router will be sent out immediately with the updated metric. But in this case, the routing update will only include the new route information. These updates are called "Triggered" updates (Flash updates by Cisco). Example below - Adding a new 172.168.1.0/24 network to R1

  • A route failure is propagated using the same mechanism. However, the way the receiving router would know the update is related to a "Failed" route and to tag that route as unreachable, is by looking at the metric.  The Metric of a failed/unreachable route is set to 16 so the receiver knows that route as an unreachable route and acts accordingly from that point onward. 
  • The metric 16 in RIP is regarded as the infinite metric. Hence, any route with the metric 16 is regarded unreachable. The mechanism of routes being tagged with metric of 16 to indicate the lack of reachability is known as "Route Poisoning"
  • In Route that becomes unreachable will removed from the routing tables as a valid route and be marked as a "Possibly Down" route. The route is kept in this state until the IFlushed after – Invalid after Seconds. See example below showing how the removal of the network 172.16.1.0/24 from R1 being notified to its neighbours. The capture below shows how the same information is carried further down via RIP updates (from R2 towards R3)





Routing Loop prevention

RIP uses several different methods to avoid routing loops. Described below;

  • Counting to Infinity:  If the next hop router to a particular prefix advertises the same route with a suddenly increased metric, It will accept the router and update its own metric. In case if the metric reaches infinity (16), that route will be discarded.
  • Split Horizon: A router will refrain from advertising a route back out an interface where the same interface is listed as the routes outgoing interface.
  • Split Horizon with Poisoned Reverse:  In this case, a router A will advertise a route learned via a particular interface out on that same interface, but with infinite metric (16). This is done to help the neighbouring router B to be aware of the fact that apart from the already known route by B, there is no alternative route via A

RIP Timers
  • Update Timer: The time that specifies the time interval over which the updates are sent. The default on Cisco device is 30 Seconds
  • Invalid after Timer: A per route timer. Gets reset everytime a new update is received for that specific route. If no updates are received for a specific route within the time defined by the  "Invalid after Timer", that specific route will be put into the "Invalid" state. And the "Holddown Timer" starts.  Defaults to 180 Seconds.
  • Holddown Timer: A per route timer that starts after a router has been tagged as Invalid. During the hold timer is in effect, the router will advertise the particular route as unreachable. The router will not accept any new modifications to this specific route from any neighbour even if the incoming update has a potentially valid route. Essentially, the route will be locked. down. Defaults to 180 Seconds
  • Flushed after Timer: A per route timer. Begins when an update about a specific route has been received from the next hop. After this timer expires, All information about the route will be completely flushed out from the RIP database.

Route filtering techniques

Controlling RIP advertisements on an interface: The "Network" command under the RIP process would only accept the classful form of network subnets (even if we enter a classless network, it will automatically reformat it to be a classful network). Therefore, it will enable RIP on all interfaces with subnetworks falling under that classful network which is not sometimes desirable. To overcome this issue, following techniques can be used to control each aspect.

  • Sending RIPv2 updates:  Can be disabled on individual interfaces by using "passive-interface Gig0/0" command under the RIP process.
  • Listening for RIPv2 updates: Filter all incoming routes using distribute list, or filter incoming RIPv2 packets using a per-interface ACL
  • Advertisement of Connection subnet: Filter outbound advertisements using distribute list filtering the corresponding connected subnet.
  • Advertising to specific neighbours on a Multi-access network:  Disable multicast updates using "passive-interface" command and use "neighbour 10.1.1.2" command under the RIP process.
  • Disabling auto-summarization at classful boundaries:  RIPv2 has "auto-summary" on by default. Therefore, subnetworks belonging to a specific classful network will only be advertised to a neighbour without modification as long as the neighbour is also connected by a subnetwork that falls under the same classful network. If not, it introduces a classful boundary. Hense, only a classful summary route will be advertised.  This can be stopped by "no auto-summary" command under the RIP process.


RIPv2 Authentication

  • Supports clear text and MD5 passwords.
  • Multiple keys can be used in conjunction with key-chain. 
  • Cisco supports authentication on a per-interface basis.
  • When authentication is enabled, the maximum number of routes that can be carried on the RIP update will be 24 instead of 25 as the Authentication data occupies the first slot. 
Example offset config below (adding 5 to the incoming metric for route 10.2.2.0/24 on Gi0/1 interface)


RIPv2 Offset Lists, Distribute List & Prefix Lists

  • Offset List: Used to manipulate the metric of a received or advertised route. 
    • Specific routes are selected based on ACL: Standard/Extended/Named
    • Can be applied IN or OUT under the RIP process
    • Can be applied to an Interface by referring to a particular Interface under the RIP Process
    • If no interface is referenced, all interfaces will be affected.
    • If a route doesn't match an entry on the offset list, those routes will not be affected.
  • Distribute List: Used filter inbound or outbound RIPv2 updates 
    • Can be applied to any interface
    • Applied under the RIP process
    • If an interface is not specified, the filtering will apply on all interfaces.
      • distribute-list { access-list-number | name } { in | out }[ interface-type interface-number ]
    • Distribute list can also be applied with a prefix-list
      • distribute-list prefix prefix-list-name { in | out } [ interface-type interface-number ]

    1 comment: