Layer 3 Routing Models - RIPv1 RIPv2 EIGRP OSPF

How a router starts the RIP process

The router generates a RIP request packet to be sent out all ports. The packet will successfully exit a port if the port is (all):

• Functional (the port exists, and the line protocol is up).
• RIP-enabled.
• Not RIP-passive.

RIP versions

The router deals with RIP packets differently depending on what version of RIP it is running.

• If it is running RIPv1, it can:
  • Send and receive RIPv1 packets.
  • Send broadcasts.
• If it is running RIPv2, it can:
  • Send and receive RIPv2 packets.
  • Send multicasts.
• If the RIP version is not set, it can
  • Send RIPv1 packets.
  • Receive RIPv1 and RIPv2 packets.
  • Send broadcasts.

How a router sends RIP updates

There are two types of RIP updates: regular and triggered.

• The router sends regular updates every 30 seconds. The update contains all of the information in the routing table.
• The router sends triggered updates only when a route has changed or an interface changes state (up or down).

How a router processes incoming RIP packets

When a router receives a RIP packet (flowchart here):

• It drops the packet if (any):
  • The incoming port does not have a valid IP address or is not RIP-enabled.
  • The source IP address is not from a directly connected network.
  • The packet came from the router itself.
  • The packet's RIP version does not match the router's RIP version.
• If the packet is a request packet:
  • Check the port to see if it is a passive interface.
    • If it is, drop the packet.
    • If it is not a passive interface, process the packet:
      • Create a RIP response packet, which contains information about a route or the entire routing table (depending on the request).
      • Send the RIP response out the same port.
• If the packet is a response packet, process it:
  • Look through each RIP route portion of the packet (the portion from address family identifier, or AFI, to the metric). A RIP packet can contain up to 25 RIP route portions.
    • Ignore any portions where (any):
      • The metric is greater than infinity.
      • The AFI is not the IP family.
      • It is a broadcast, Class D, or Class E address.
  • Set the next hop to the incoming port's address.
  • For new routes, ignore the route portion if the metric is now 16.
  • For existing routes, the metric is set to 16.
  • If the packet contains information about a network that does not exist in the RIP database, it is added to the database.
  • If a network already has an entry in the RIP database, update it with the latest information.
  • Send out new and updated routes on the next triggered update.

How a router processes incoming EIGRP packets

When a router receives an EIGRP packet (flowchart here):

• It checks to see if the EIGRP process for the autonomous system that is specified in the packet is enabled.
  • If it is not enabled, then the router drops the packet.
  • Otherwise, it sends the packet to that EIGRP process.

When an EIGRP process receives an EIGRP packet:

• It makes the following checks and drops the packet if (any):
  • The receiving interface does not have EIGRP enabled.
  • The packet does not come from the same subnet as the receiving interface.
  • The receiving interface is passive.
• It checks if the packet is a Hello packet.
  • If so, then it processes the Hello packet (skip to next section).
  • Otherwise, it checks if the packet came from an existing neighbor.
    • If not, then it drops the packet.
    • If the packet did come from an existing neighbor:
      • It checks if the packet is an Acknowledgment packet.
        • If so, then it removes the acknowledged packet from the neighbor's output queue.
        • Otherwise, it checks the sequence number on the packet and the neighbor's last heard sequence number.
          • If the sequence number on the packet is larger than the last heard, then update the last heard.
          • If the sequence numbers are the same or the one on the packet is smaller than the last heard, then it drops the packet.
        • It checks if the packet piggybacks an Acknowledgment.
          • If so, it removes the acknowledged packet from the neighbor's output queue.
            • It checks if there are any packets in the neighbor's output queue.
              • If there are not, then it sends an Acknowledgment packet back to the neighbor.
        • It checks if the packet is an Update packet. If so, then it processes the Update packet.
        • It checks if the packet is a Query packet. If so, then it processes the Query packet.
        • It checks if the packet is a Reply packet. If so, then it processes the Reply packet.

When an EIGRP process processes a Hello packet:

• It checks if the Hello packet has matching K values as the EIGRP process.
  • If not, then it removes the neighbor from the router's neighbor table.
• It checks if the neighbor already exists in the neighbor table.
  • If so, then it updates the last-heard time and hold timer.
  • If not, it adds the new neighbor to the neighbor table, and sends a full update of its topology table to the new neighbor.

When an EIGRP process processes an Update packet:

• It goes through all routes in the Update packet and updates the topology table.

When an EIGRP process processes a Query packet:

• It updates the topology table with the route in the query.
• It checks if updating the topology table does not cause the process to query other neighbors.
• If it does not, then reply the best route to the queried neighbor.

When an EIGRP process processes a Reply packet:

• It makes the following checks and drops the packet if (any):
  • The replied route does not exist.
  • The network is not in ACTIVE state.
  • The neighbor who replied was not queried.
• It checks if the replied route is better than the best heard in the reply table.
  • If so, then it replaces the best heard in the reply table with the replied route.
• It checks if the replied route is the last expected reply.
  • If it is, then processes the last Reply packet to a query.

When an EIGRP process processes a last Reply packet to a query:

• It replies to all queried neighbors with the best-heard route from the reply table.
• It sets the network to PASSIVE state.
• It updates the topology table with the best route.

When an EIGRP process updates the topology table with a route:

• Checks if the network is in ACTIVE state.
  • If so, it ignores the update.
• It gets the old best route and old best metric to the network.
• It adds the route to the topology table.
• It gets the new best route and new best metric to the network.
• It checks if the new best route is unreachable or there is no feasible successor.
  • If either is true, then it queries neighbors about the route.
    • If there is no neighbor to query, then it removes the network from topology and routing table.
  • If the new best route is feasible, then it adds all successors for the network to the routing table.
    • Update neighbors.

How a router processes incoming OSPF packets

When a router receives an OSPF packet (flowchart here):

• It checks to see if an OSPF process is enabled on the port that received the packet.
  • If it is not enabled, then the router drops the packet.
  • Otherwise, it sends the packet to that OSPF process.

When an OSPF process receives an OSPF packet (flowchart here):

• It makes the following checks and drops the packet if (any):
  • The receiving interface does not have OSPF enabled.
  • The packet does not come from the same subnet as the receiving interface.
  • The receiving interface is passive.
  • The packet is for (backup) designated router and the router is not.
  • The receiving interface does not have the same area id as indicated in the packet.
  • The authentication failed for the packet.
• It checks if the packet is a Hello packet.
  • If so, then it processes the Hello packet (skip to next section).
  • Otherwise, it checks if the packet came from an existing neighbor.
    • If not, then it drops the packet.
    • If the packet did come from an existing neighbor:
      • It checks if the packet is a Database Description packet (DDP). If so, then it processes the DDP.
      • It checks if the packet is a Link State Request (LSR) packet. If so, then it processes the LSR.
      • It checks if the packet is a Link State Update (LSU) packet. If so, then it processes the LSU.
      • It checks if the packet is a Link State Acknowledgment (LSAck) packet. If so, then it processes the LSAck.

When an OSPF process processes a Hello packet (flowchart here):

• It checks if the Hello packet has matching hello & dead timer values as the OSPF process.
  • If not, then it prints out a warning message and drops the packet.
• It checks if the neighbor already exists in the neighbor table.
  • If so, then it resets the dead timer.
  • If not, it adds the new neighbor to the neighbor table and sets the neighbor state to 2-WAY.
    • The adjacency is established with the neighbor if:
      • The underlying network is point-to-point.
      • The underlying network is broadcast and the router itself is designated router, backup designated router, the neighboring router is designated router, or the neighboring router is backup designated router.
• It checks if backup designated router is present.
  • If not, then it performs designated router election after wait timer expires.

When an OSPF process processes a Database Description packet (flowchart here):

• If the state is start, the master/slave relationship is formed based on router ID. The neighbor state is updated to exchange.
• During the exchange state, the OSPF process goes through all the link state advertisement (LSA) headers stored in the packet. If the router does not have the LSA described in the header, it stores the header in the queue.
• If there are no more DDPs, the neighbor state transitions to loading. The headers stored in the queue are used to generate LSRs.

When an OSPF process processes a Link State Request (LSR) packet (flowchart here):

• It looks up its Link State Database and puts the information in the Link State Update (LSU) packet and sends to the adjacent neighbor.
• After all the corresponding LSUs are received for the LSRs, the neighbor state transitions to full.

When an OSPF process processes a Link State Update (LSU) packet (flowchart here):

• It validates the LSA's checksum. If the checksum is invalid, discard the LSA.
• It checks the LSA's type. If the type is unknown, discard the LSA.
• It checks the LSA's age. If the age is equal to maximum allowed value and there is currently no instance of the LSA in the router's database, and none of router's neighbors are in states exchange or loading states, then the router sends an acknowledge.
• If the LSA is not in the database or is newer, add to the database.
• If the LSA is the same instance as the database copy, and the LSU is not used as an implied acknowledgment, send a LSAck to the neighbor.
• If the database copy is more recent, discard the LSA without acknowledging it.

When an OSPF process processes a Link State Acknowledgment packet (flowchart here):

• It checks neighbor's state. If the neighbor is in a lesser state than exchange, discards the packet.
• It checks if the acknowledgment is for an instance of a LSA stored in the retransmission list for the neighbor. If yes, the OSPF process removes the LSU from the retransmission list.

When an OSPF process updates the routing table with a route (flowchart here):

• All routers in the same autonomous system belonging to the same area should have identical database.
• After a LSA has been added to the database, the OSPF process starts a timer. The router performs shortest path first (SPF) calculation after the timer expires. The SPF algorithm uses LSAs stored in the database to generate OSPF routes. The routes are added to the routing table.

How routes are Redistributed using Redistribution feature.

• Redistribution commands can be configured in the router mode of the routers for all types of the routing protocols including EIGRP, EIGRPv6, OSPF, OSPFv3, RIP, and RIPv6.
• Once a redistribution command is configured.
  • Router checks for that specific type of the route in its routing table
    •  If any exists that matches the redistribution command it will add the route to the destination protocol’s database or topology table and sends out an update to its neighbors for that route.
    • If there is not any matching route in the routing table, it checks back the routing table for the newly receiving routes. If any matches the command it will add it to the destination protocol’s database and sends out an update for that route to its neighbors.
    • If route which matches the redistribution command’s protocol gets deleted from the routing table the router sends out an update to its neighbor and announces that specific route’s status as down.
• Once a redistribution command is removed from the router
  • The router marks the metric of the matching routes as unreachable and sends an update to its neighbor about that route.
• Once an interface comes up or a network commands gets added to any routing protocols.
  • Router checks whether a redistribution command is configured. If  there is any configured it will send an update out of that interface.

How CEF works

• Cisco Express Forwarding uses a cache table for fast forwarding.
• The CEF cache table contains entries matching destination networks to next hop IP address, next hop layer 2 information, and outgoing interface.
• The CEF cache table is built from lookups in the routing table and IP address to layer 2 information.
• When packets are needed to be sent out, whether receiving from an interface or sending from the local device, it looks up the destination network in the CEF cache table first.
• If it is found, it uses that information to encapsulate and modify the frame and sends it out.
• If it is not found, it uses process routing, which is same as looking up routing table and passing to lower layer for layer 2 encapsulation. It also records the information in the cache table when the layer 2 information is complete.

IPv6 Routing and Routing Protocols

• Routing in IPv6 works the same way as in IPv4 with "ip classless" enabled, which is always enabled in Packet Tracer.
• Display of routing table in IPv6 does not group networks together as in different classes in IPv4.
• RIPv6 works the same way as RIPv2.
• Multiple instances of RIP can be run at the same time on the same device.
• EIGRPv6 and OSPFv3 work the same way as in IPv4 except the router-id's are still using IPv4 addresses. They can be either automatically chosen from the assigned IPv4 addresses on the device or manually configured for the routing protocol instance.

How a router processes incoming BGP packets

When a BGP peer receives an open packet (flowchart here):

• If versions are different
  • Send BGP error open version notice back
  • Stop neighbor peering
  • Start Connect retry timer
• If neighbor's AS is not the same as this router's configured neighbor AS:
  • Send BGP error open Bad AS notice back
  • Stop neighbor peering
  • Start Connect retry timer
• If neighbor's speaker ID is the same as this router's speaker ID:
  • Send BGP error open Bad ID notice back
  • Stop neighbor peering
  • Start Connect retry timer
• If neighbor's holdtime is less than 3:
  • Send BGP error open Bad Holdtime notice back
  • Stop neighbor peering
  • Start Connect retry timer
• Negotiate holdtimes, using the smaller of the neighbor's and this router's hold time.
• Change state to OPEN CONFIRM
• Send keepalive to neighbor

When a BGP peer receives a notification packet (flowchart here):

• If error code is Cease
  • Send Cease back
• If error code is hold time expire
  • Close TCP connection
• Stop neighbor peering
• Start connect retry timer

When a BGP peer receives an update packet: (flowchart here):

• If Update packet contains withdrawn routes
  • Set withdrawn route in neighbor's incoming routing information base table to be unfeasible
• If Update packet contains route updates
  • If new route:
    • Add route to the neighbor's incoming routing information base table
  • If existing route exists:
    • Update routing information
• Run decision process to pick best routes to the main routing information base and install routes to the routing table

When a BGP peer receives a keepalive packet: (flowchart here):

• Increment keepalive count
• Refresh hold down timer
• Run decision process to pick best routes to the main routing information base and install routes to the routing table

BGP Decision Process: (flowchart here):

• Check all network statements
  • If network is not installed in the main BGP routing information base table
    • If network is reachable
      • If another route is already installed, make the other route unfeasible
      • If route is not already installed, add route to routing table if not there
• Check all neighbor's incoming routing information base table
  • Verify route is loop free (AS Path does not go through local AS)
  • If synchronization is enabled, verify the route's next hop is reachable through an IGP
  • If the route is the best route available, add route to routing table if not there
• Send routing update for redistributed routes
• Remove all unfeasible routes from the main routing information base and send withdraws if necessary
• Send out route updates for all new routes installed
• Remove all unfeasible routes from the main routing table