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 an Query packet. If so, then it processes the Query
packet.
-
It checks if the packet is an 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 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 add the new neighbor to the neighbor table, and send 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.
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 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, 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 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
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.