My journey to CCIE RS — RIP 1

Giuliano Barros
TechRebels

--

This is the fourth topic in the series with my accumulated notes over years of study until passing the CCIE RS lab. Almost 400 notebook pages with information and observations that I considered important when working with Routing and Switching for more than 15 years.

I believe this information will help not only certification exams, but in the day by day of other people (like me) when dealing with Cisco infrastructure.

For those who have not read the previous articles, follow below a list with them. Today we explore the “RIP” part 1.

Feel free to comment and contact me on LinkedIn. If you liked what you read, I encourage you to share it with colleagues in the industry. Don’t forget to follow TechRebels and me by clicking the follow link on the top :)

RIP (Rest in… ops… Routing Information Protocolo)

  • IGP routing protocol that uses distance vector.
  • UDP 520
  • RIP does not have a complete view of the topology and only knows the prefixes published by the directly connected neighbors. This lack of a topology view can cause problems, especially during redistributions.

NOTE: Any protocol that uses VLSM is essentially classless.

RIP v1

  • Classful — does not have a prefix length field (subnet mask).
  • Therefore, all networks within the same core network must use the same mask.
  • Uses broadcast for updates (everyone receives and processes).

RIP v2

  • Classless — has a subnet mask field (supports VLSM).
  • Uses multicast address 224.0.0.9 to propagate updates.

RIP is configured without an AS number or any ID, so there can only be a single RIP process running in the router.

  • NOTE: When using VRFs, we can have one RIP process for each VRF.

NOTE: The <network> command specifies which interfaces will participate in the RIP process. As this command only accepts main networks (by class), if you want to enable for a certain interface while prohibiting others on the same core network, you must use passive-interface, filters, etc … <network> command does not specify which address is propagated.

RIP v2, despite being classless, inherited an automatic classful summarization by default.

Updates (default):

  • Send v1
  • Listen v1 and v2

Major Networks (classes)

  • 0XXX — A
  • 10XX — B
  • 110X — C
  • 1110 — D
  • 1111 — E

VLSM is supported within the same major network. Updates across the boundaries of major networks are summarized as classful. This can result in black holes because it is not known exactly where individual networks are.

NOTE: It is not the routing table that performs load balancing. The RIB only presents the path possibilities for the “switching path”, but it is up to the switching path to determine how load-balancing among these paths will be carried out.

RIP’s Administrative Distance (AD) can be manipulated globally, by prefix or by neighbor.

RIP propagates, by default, routes from the same major network that have the same subnet mask as the interface or classful auto-summary of routes with a mask size different than the interface.

NOTE: A RIP v1 exception is that it allows to propagate host routes (/ 32) with mask size different from the interface, but only within the same major network.

If we use different major networks with auto-summary enabled (RIPv1 and RIPv2), we will probably have routing problems. Routers will receive multiple summarized routes through multiple neighbors over the same major network. Ex: routers can propagate summaries for their loopback networks, which usually belong to a separate major network.

Split Horizon

Updates received on an interface are not forwarded back through the same interface.

  • NOTE: This behavior is undesirable in partial mash NBMA networks.

Split horizon is enabled by default on all interfaces except the main Frelay interface.

NOTE: In Hub-and-Spoke topologies always be careful, because it may appear that the network has full connectivity, but a failure may interrupt connectivity in a specific way.

Timers

  • Update — 30 sec
  • Invalid — 180 sec — shows “possibly down” in the routing table
  • Holddown — 180 sec — during this period accepts routes of the same metric or better to avoid loops
  • Flush — 240 sec — routes are removed from the routing table

RIP timers do not need to agree among neighbors. Timers are not 100% accurate because RIP uses jitter mechanism. Jitter prevents synchronized sending of updates all at once through the interface and therefore prevents synchronized sending of updates on the network. In certain cases, routers are synchronized and send updates all at the same time. For this reason the timers are high (to vary a lot).

Like any protocol, RIP has a limit of prefixes per update (packet).

Update Types

  • Broadcast
  • — RIP v1 — default
  • — RIP v2 — optional
  • Multicast
  • — RIP v2 — default
  • Unicast
  • — RIP v1 and v2 — optional

To use only unicast updates it is necessary to specify <neighbors unicast> and enable <passive-interface>, blocking multicast and broadcast (check with <debug ip rip>).

NOTE: Remember that RIP by default propagates classful summaries, in addition to routes with the same subnet mask as the interface and host routes.

NOTE: Direct-broadcast is disabled for security reasons. One of the possible failures is the “Smurf Attack” (https://pt.wikipedia.org/wiki/Ataque_Smurf).

A security feature is to disable multicast and broadcast on a LAN interface and enable only unicast updates. This ensures that updates are not replicated to other LAN ports based on the MAC table.

To be continued…

Does this RIP content help you in everyday tasks?

Is it missing something important?

Tell me in the comments.

If you like this content, please share. Don’t forget to follow me and TechRebels by clicking “follow” down below :)

About the author:

Giuliano Barros is Network Specialist at PS Network Experts.

Gratuated in Computer Science, CCIE certified by Cisco Systems and work for +15 years with projects for medium and big size companies.

linkedin.com/in/giulianobarros

--

--

Giuliano Barros
TechRebels

DevOps Network Engineer | CCIE RS #49619 | Cisco Champion | Blogger