RIP & OSPF

Routing belongs to the control plane.

Its job is to answer questions such as:

• Which destinations are reachable?
• Through which routers or links can they be reached?
• What routes should be installed in the forwarding table?

Routing protocols compute or learn the information that later becomes part of the forwarding table.

Forwarding belongs to the data plane.

When a packet arrives, the router looks at the destination IP address and uses the forwarding table to decide the outgoing interface.

In IP forwarding, this is normally done using longest-prefix matching.

So:

Routing computes the forwarding table. Forwarding uses the forwarding table for each packet.

The Internet has a huge number of destinations.

The slide mentions about 850 million destinations. A router cannot simply store and exchange flat routing information for every possible destination in a naive way.

Problems:

• forwarding tables would become too large;
• routing updates would consume too much bandwidth;
• very fast memory for large forwarding tables is expensive;
• a single global routing algorithm would be impractical.

Therefore, the Internet needs abstraction and hierarchy.

The Internet is a network of networks.

Different organizations operate different parts of the Internet. Each network operator wants control over routing inside its own network.

For example:

• Deutsche Telekom can decide how to route inside its own network;
• another operator can use a different internal routing design;
• these networks may geographically overlap, because different providers all place routers in major cities.

Most large Internet traffic today runs over privately operated commercial networks, even though the Internet historically started from research and educational networks.

Intra-AS routing tells a router how to reach internal destinations inside the same AS.

It also tells an internal router how to reach an AS border router.

Inter-AS routing tells the AS which external destinations are reachable through which neighboring ASes.

Example:

Suppose a router in AS64496 receives a packet for a destination outside AS64496.

The router needs to know:

• which external destinations are reachable through AS64497;
• which external destinations are reachable through AS64498;
• which border router should be used;
• how to reach that border router internally.

Thus:

Inter-AS routing tells the AS where external destinations are reachable. Intra-AS routing tells routers how to get to the chosen border router.

BGP is the standard inter-AS routing protocol used across the Internet.

Different ASes can choose different IGPs internally, but the inter-AS protocol must be compatible globally.

RIP is an intra-AS distance-vector protocol based on Bellman-Ford.

Each router periodically sends its routing table, or distance vector, to its neighbors.

A neighbor uses that information to update its own table.

For each destination, RIP stores information like:

• destination network;
• next-hop router;
• hop count to the destination.

RIP uses hop count as its only metric.

The cost of a route is the number of router hops.

Important limitation:

• RIP cannot assign arbitrary link weights.
• A link cannot simply be configured as weight 2 or weight 10 in the same flexible way as OSPF.
• Traffic engineering is therefore limited.
• To influence RIP routes, one often has to change the topology or the advertised reachability.

RIP uses:

• maximum useful hop count: 15;
• infinity: 16.

This is a pragmatic way to limit the count-to-infinity problem.

Because infinity is only 16, RIP is only suitable for relatively small internal networks.

Suppose router D has a routing table like:

Here:

• x is directly attached to D, so no next router is needed;
• w is reached via A;
• y and z are reached via B.

If A advertises that it can reach z with cost 4, then D can reach z via A with cost 5.

So D may update:

This is an example of “good news travels fast”: a better route can be adopted quickly.

RIP routers exchange distance vectors periodically.

Important details:

• updates are sent every 30 seconds;
• updates are sent as response messages, also called advertisements;
• each advertisement contains up to 25 destination networks;
• RIPv2 uses UDP port 520.

Because RIP periodically exchanges routing entries for destination subnets with neighbors, it is simple and works for small internal networks. However, it does not scale well to large or complex AS-internal networks, because updates become costly, convergence can be slow, and the hop-count metric is limited to 15 hops.

For example, if there were hundreds of millions of prefixes, sending only 25 entries per message would be completely impractical.

Thus RIP is only appropriate for small internal routing domains.

The forwarding table is needed in the network layer.

However, the routing protocol logic usually runs as an application-level routing daemon.

In Unix-like systems, this is historically the routed daemon.

The process works roughly like this:

1. the routing daemon receives RIP advertisements over UDP;
2. it updates its routing information;
3. it installs the resulting routes into the kernel’s forwarding table;
4. the kernel uses the forwarding table to forward packets.

So routing information is exchanged by a user-space process, but forwarding is performed by the network layer.

RIP uses UDP.

This means:

• RIP messages can be lost;
• there is no TCP-style reliability;
• the protocol relies on periodic repetition.

A router should not declare a neighbor dead after one missed update, because a single UDP packet could simply have been lost.

If no advertisement is heard from a neighbor for 180 seconds, RIP declares the neighbor or link dead.

Then:

• routes through that neighbor are invalidated;
• new advertisements are sent to neighbors;
• neighbors update their own tables if necessary;
• the information propagates through the network.

These immediate updates after a change are called triggered updates.

Triggered updates improve convergence because the network does not always have to wait for the next 30-second periodic update.

Distance-vector protocols can suffer from the count-to-infinity problem.

The core issue:

Good news travels fast, but bad news travels slowly.

If a route breaks, routers may still believe that another neighbor has a path, even if that path actually depends on the broken route.

This can create routing loops where routers keep increasing the metric step by step.

RIP limits this problem by defining infinity as 16.

So the count cannot continue forever, but convergence can still be slow.

RIP uses several practical mechanisms.

Split horizon and poison reverse mainly prevent direct two-router loops.

They do not eliminate all possible loops.

Longer loops involving three or more routers can still be problematic.

Therefore, RIP remains simple but limited.

A routing protocol must handle several tasks.

For RIP:

• routing table:
  • metric: hop count;
  • calculation: Bellman-Ford / distance-vector update;
  • update: periodic and triggered advertisements.
• neighbor handling:
  • neighbors exchange updates;
  • if no update is received for 180 seconds, the neighbor/link is considered down.
• database:
  • the database is essentially the distance-vector routing table;
  • it is synchronized indirectly by repeated advertisements.

In OSPF, each router does not merely tell neighbors its current best distances.

Instead, routers describe their local link state:

• who they are;
• which links they have;
• which networks are attached;
• what the administrative cost of each link is.

This information is flooded through the routing domain.

Each router builds a link-state database.

From this database, each router derives a topology map and runs Dijkstra locally.

OSPF uses administrative link weights.

This is more flexible than RIP’s hop count.

For example:

• crossing a mountain range may be expensive;
• long-distance links may be costly;
• some links may have higher capacity or lower cost;
• an operator may want to prefer one path over another.

With OSPF, the operator can assign link weights to influence routing.

The lecture emphasized that using current link utilization directly as the routing metric is usually a bad idea.

Reason:

• small changes in load can change the best path;
• routes may keep flipping back and forth;
• this causes instability and unpredictable behavior.

Therefore OSPF usually uses relatively stable administrative weights, not rapidly changing utilization values.

The lecture described the basic idea of neighbor states:

The key point is that merely receiving a Hello is not enough.

A router needs evidence that the neighbor also sees it.

Only then is communication bidirectional.

Hello packets include parameters such as:

• Router ID;
• Area ID;
• HelloInterval;
• RouterDeadInterval;
• Designated Router;
• Backup Designated Router;
• list of known neighbors.

Routers only become neighbors if important parameters match.

For example, if one router uses a different HelloInterval or RouterDeadInterval than the other, no proper OSPF neighborhood may form.

This can lead to a situation where a physical link is up but unused by OSPF due to configuration mismatch.

The exact default timers depend on configuration and implementation.

The slides show a typical default of:

• HelloInterval: 10 seconds;
• RouterDeadInterval: 4 times HelloInterval.

The lecture also emphasized the general trade-off:

• shorter timers detect failures faster;
• but timers must not be shorter than normal packet delay or RTT;
• otherwise routers may falsely declare neighbors dead.

Large operators often reduce timers to achieve faster convergence, but this must be configured carefully.

OSPF uses well-known multicast addresses.

Important examples:

Other related multicast addresses mentioned in the slides:

Multicast avoids sending routing messages to hosts that do not need to process them.

An LSA has a header and a body.

Important header fields include:

• LS Age;
• Options;
• LS Type;
• Link State ID;
• Advertising Router;
• LS Sequence Number;
• LS Checksum;
• Length.

An LSA instance is identified mainly by:

• LS Type;
• Link State ID;
• Advertising Router.

The LS sequence number is used to distinguish old and new versions of the same LSA.

If a router generates a newer LSA, it uses a newer sequence number.

This allows other routers to replace old information.

The sequence number space is linear and finite.

Because LSAs also have an age, old information can eventually disappear, allowing the protocol to handle sequence number limits.

OSPF uses its own LSA checksum.

This is necessary because OSPF runs directly over IP and cannot rely on TCP or UDP checksums for its own database consistency needs.

Checksums help detect corrupted LSA contents.

The LS Age field prevents stale topology information from remaining forever.

Important values from the slides:

The point is:

Old information must eventually disappear, even if some update was lost.

At the same time, LSAs should not be refreshed too frequently, because routing overhead consumes bandwidth.

When OSPF was designed, network bandwidth was much more limited, so timer choices had to balance correctness and overhead.

Initial synchronization happens after two routers establish bidirectional communication.

They explicitly exchange summaries of their databases.

This uses Database Description packets, or DD packets.

Important properties:

• only one DD packet is sent at a time;
• the sender waits for acknowledgement;
• this is a stop-and-wait style protocol;
• one router acts as the leader and the other as the follower;
• older terminology used “master/slave”, but “leader/follower” is preferred.

During the exchange:

1. routers send LSA headers from their databases;
2. each router determines which LSAs it is missing;
3. missing LSAs are requested using Link State Request packets;
4. the neighbor sends the requested LSAs in Link State Update packets;
5. after this, the routers are fully adjacent.

A simple consistency check is:

• compare the number of LSAs;
• compare sums of LSA checksums.

If these match, the databases are presumed to be equivalent.

If not, more detailed synchronization is needed.

After initial synchronization, new changes are propagated by reliable flooding.

This keeps the LSDBs up to date as links and routers change.

If a router sends an LSA to a neighbor and later receives the same LSA back from that neighbor, this can serve as an implicit acknowledgement.

It shows that the neighbor received and processed the LSA.

OSPF can also use explicit Link State Acknowledgement packets.

Acknowledgements may be delayed to reduce overhead.

One might ask why OSPF does not maintain a spanning tree and send each update only once along that tree.

The lecture’s answer:

• a spanning tree itself must be maintained;
• if a tree link fails, the tree must be recomputed;
• this adds another fragile topology mechanism;
• reliable flooding is more robust.

Flooding creates more messages, but it avoids relying on a separate distribution tree.

The slides list several important LSA-related timers:

The purpose of these timers is to prevent LSAs from being sent at arbitrary rates and to control protocol overhead.

The DR represents the broadcast network to the rest of the OSPF area.

Routers form adjacencies mainly with the DR, rather than with every other router.

The DR is responsible for originating the Network LSA for that broadcast subnet.

Because the DR is important, OSPF also elects a Backup Designated Router, or BDR.

If the DR fails:

1. the BDR immediately becomes the new DR;
2. a new BDR is elected.

This avoids long disruption.

The election process is conservative.

When a router joins a broadcast network:

• it listens to Hello packets;
• if a DR and BDR are already advertised, it accepts the status quo;
• it does not disrupt the existing DR just because it has a higher priority.

If there is no BDR:

• the router with the highest priority becomes BDR;
• ties are broken by the highest Router ID.

If there is no DR:

• the BDR is promoted to DR;
• then a new BDR is elected.

Important consequence:

The router with the highest priority is not necessarily always the DR.

If the highest-priority router goes down and later comes back, it normally does not preempt the current DR. It may at most become BDR.

This avoids unnecessary instability.

An AS, or routing domain, can be divided into areas.

An area is a group of routers that are usually physically or logically close to each other.

Benefits:

• link-state flooding is limited to the area;
• routers do not need full detailed topology information for the whole AS;
• the amount of routing state and update traffic is reduced.

OSPF requires a backbone area, called Area 0.

Inter-area routing must go through the backbone.

This creates a strict two-level hierarchy:

• local areas;
• backbone area.

Area Border Routers summarize distances to destinations inside their own area and advertise this information to the backbone.

Local routers inside an area:

• flood link-state information only inside the area;
• compute detailed shortest paths only within the area;
• send traffic to outside destinations via an area border router.

Inside an area, OSPF is link-state:

• routers have detailed topology information;
• they run Dijkstra;
• routing loops are avoided if the LSDBs are consistent.

Between areas, the situation is different:

• routers do not know the full detailed topology of other areas;
• they know summarized directions through area border routers;
• routing between areas must go through the backbone;
• the globally shortest physical path may not always be used.

Thus OSPF gives exact shortest paths within an area, but hierarchical summarization can make inter-area paths less direct.

The lecture emphasized that this is a severe limitation of OSPF hierarchy:

You cannot simply route directly between two non-backbone areas, even if there is a physical link, unless the OSPF area design supports it through the required hierarchy.

Good area design groups routers that are physically or logically close.

The goal is to:

• keep flooding local;
• reduce the size of the LSDB;
• avoid unnecessary inter-area routing;
• preserve redundancy.

Link and router failures can partition an area.

Some partitions may be repaired automatically, but others require manual intervention.

Virtual links can sometimes be used, but isolated areas with no path to the rest of the network cannot be healed by routing alone.

Redundancy is therefore important.

OSPF messages can be authenticated to prevent malicious routers from injecting false routing information.

OSPF allows multiple same-cost paths.

This enables load splitting across equal-cost next hops.

The slides mention that OSPF can support multiple cost metrics for different types of service, although this is not the main focus of the lecture.

Multicast OSPF, or MOSPF, can use the same topology database as OSPF for multicast routing.