Routing: static, floating routes and OSPF

The same topology, two philosophies. First you write every route by hand and see exactly what the router knows and where from. Then you delete everything and let OSPF do the same job by itself - after which you cut a cable and time which one recovers faster.

1What a router knows, and from where

A freshly configured router knows one single thing: the networks attached directly to it. That is all. Of the rest of the world it has not the faintest idea, and packets headed there are discarded.

There are exactly two ways of telling it the rest.

Static routes

You write them yourselves, one at a time
They do exactly what you wrote, predictably
They consume no bandwidth and cannot be fooled
With 20 networks and 5 routers that means 100 commands, and you rewrite them at every change

A dynamic protocol (OSPF)

The routers talk to one another and tell each other what they know
A new network is announced once, on one single router
When a link goes down, the path is recomputed by itself
More complex to configure and to troubleshoot

administrative distance (AD)

How much the router trusts the source of a route. Directly connected: 0. Static route: 1. OSPF: 110. When two sources propose routes to the same destination, the one with the smaller AD wins.

metric

How "expensive" a path is, within the same protocol. In OSPF, the metric is the cost, computed from the bandwidth of the interfaces. It is compared only between routes from the same source.

longest prefix match

When several routes match a destination, the router picks the one with the longest prefix - the most specific one. A /24 route beats a /16 one, whatever the AD or the metric.

The order of the decision, once and for all First the longest prefix. If there are several with the same prefix, the smallest AD wins. If the AD is equal too, the smallest metric wins. These three lines explain almost any strange behaviour of a routing table.

2Equipment needed

Qty	Equipment	Model	Packet Tracer category	What it is for here
4	Router	`4331`	Network Devices → Routers	R1, R2, R3 and the ISP router
3	Switch	`2960`	Network Devices → Switches	one for the LAN of each router
3	Computer	`PC-PT`	End Devices	a test host in each LAN
1	Server	`Server-PT`	End Devices	"the Internet", address 8.8.8.8
3	Serial cable	`Serial DCE`	Connections	the three links between the routers
5	Straight cable	`Copper Straight-Through`	Connections	the LANs and the link to the ISP

If the router does not have enough serial interfaces In Packet Tracer, the 4331 router starts with no serial modules. Switch it off from the power button in the Physical tab, drag an HWIC-2T module into a free slot and switch it back on. In the workbench in this page, the interfaces S0/1/0 and S0/1/1 already exist.

3The topology

The topology of laboratory 4 is continued: three routers joined in a triangle, each with its own LAN, plus a way out to the Internet through the ISP router.

Fig. 1 - Three routers, two direct links and a slow backup one. The difference in bandwidth is essential: it is what makes the choice of path matter.

Router	LAN	WAN interfaces	Router ID
R1	172.20.16.0/23 · G0/0/0 .1	S0/1/0: 10.0.0.1/30 · S0/1/1: 10.0.0.5/30 · G0/0/1: 203.0.113.1/30	1.1.1.1
R2	172.20.18.0/24 · G0/0/0 .1	S0/1/0: 10.0.0.2/30 · S0/1/1: 10.0.0.9/30	2.2.2.2
R3	172.20.19.0/24 · G0/0/0 .1	S0/1/0: 10.0.0.6/30 · S0/1/1: 10.0.0.10/30	3.3.3.3
ISP	8.8.8.0/24 · G0/0/1 .1	G0/0/0: 203.0.113.2/30	-

4The workbench

The complete topology, cabled, with the hosts already addressed. The routers are empty - you configure them yourselves, first statically, then with OSPF.

The objectives describe the final state The two that concern OSPF stay unlit while you work with static routes - that is normal. The rest tick themselves off as early as part I.

5Part I: static routing

Address the interfaces

on R1

Router> enable
Router# configure terminal
Router(config)# hostname R1
R1(config)# no ip domain-lookup

R1(config)# interface serial 0/1/0
R1(config-if)# ip address 10.0.0.1 255.255.255.252
R1(config-if)# clock rate 128000
R1(config-if)# no shutdown
R1(config-if)# exit

R1(config)# interface serial 0/1/1
R1(config-if)# ip address 10.0.0.5 255.255.255.252
R1(config-if)# clock rate 128000
R1(config-if)# no shutdown
R1(config-if)# exit

R1(config)# interface gigabitEthernet 0/0/0
R1(config-if)# ip address 172.20.16.1 255.255.254.0
R1(config-if)# no shutdown
R1(config-if)# exit

R1(config)# interface gigabitEthernet 0/0/1
R1(config-if)# ip address 203.0.113.1 255.255.255.252
R1(config-if)# no shutdown
R1(config-if)# end

Repeat for R2, R3 and ISP, with the addresses from the table. On the R2–R3 backup link, declare the bandwidth as well, so that OSPF knows later that it is slow:

on R2 and on R3, interface S0/1/1

R2(config)# interface serial 0/1/1
R2(config-if)# ip address 10.0.0.9 255.255.255.252
R2(config-if)# bandwidth 64
R2(config-if)# no shutdown

bandwidth does not change the real speed The command merely declares what bandwidth the link has, for the computations of the routing protocols. It is an informative label - but the path OSPF chooses depends on it, so it must be correct.

Check the starting point
on R1
```
R1# show ip route
```
You must see only C (connected) and L (local) routes. A ping between the LANs does not work - the routers know nothing about one another. Check this as well, from PC1: ping 172.20.19.10 must fail.

Write the routes, with a next hop

on R1

R1(config)# ip route 172.20.18.0 255.255.255.0 10.0.0.2
R1(config)# ip route 172.20.19.0 255.255.255.0 10.0.0.6
R1(config)# ip route 10.0.0.8 255.255.255.252 10.0.0.2

on R2

R2(config)# ip route 172.20.16.0 255.255.254.0 10.0.0.1
R2(config)# ip route 172.20.19.0 255.255.255.0 10.0.0.10
R2(config)# ip route 10.0.0.4 255.255.255.252 10.0.0.1

on R3

R3(config)# ip route 172.20.16.0 255.255.254.0 10.0.0.5
R3(config)# ip route 172.20.18.0 255.255.255.0 10.0.0.9
R3(config)# ip route 10.0.0.0 255.255.255.252 10.0.0.5

Mind the mask The LAN of R1 is a /23, so the mask is 255.255.254.0, not 255.255.255.0. It is exactly the kind of mistake that produces a bizarre symptom: half the hosts answer, the other half do not.

Test and read the table

on R1

R1# show ip route
R1# show ip route static
R1# ping 172.20.19.10
R1# traceroute 172.20.19.10

An entry looks like this, and every piece of it means something:

the anatomy of a route

  S    172.20.19.0/24 [1/0] via 10.0.0.6, Serial0/1/1
  │           │         │ │       │            │
  │           │         │ │       │            └─ the outgoing interface
  │           │         │ │       └─ next hop: to whom the packet is handed
  │           │         │ └─ the metric (0 for static routes)
  │           │         └─ the administrative distance (1 = static)
  │           └─ the destination and the prefix
  └─ the source of the route: S = static, C = connected, O = OSPF

Experiment: the outgoing interface instead of the next hop
on R1
```
R1(config)# no ip route 172.20.18.0 255.255.255.0 10.0.0.2
R1(config)# ip route 172.20.18.0 255.255.255.0 serial 0/1/0
R1(config)# end
R1# show ip route
R1# ping 172.20.18.10
```
On a point-to-point serial link it works perfectly, because there is only one possible recipient. Now try the same thing on an Ethernet link between two routers and observe the difference.

Question

Why does the interface variant fail on Ethernet but work on serial?

See the answer

On Ethernet, the router knows which interface to send the packet out of, but does not know what destination MAC address to put in the frame: there may be dozens of devices on that segment. Without a next hop it cannot do ARP.

On serial, the problem does not arise: the link has exactly two ends, there are no layer 2 addresses and no need for resolution. The frame simply goes down the wire.

Then go back to the next-hop variant.

6The default route and the floating route

The default route towards the Internet
on R1
```
R1(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.2
```
0.0.0.0 0.0.0.0 matches absolutely any destination - and precisely for that reason it has the shortest possible prefix, so it loses against any other route. It is "if I do not know where, send it there". Test from PC1: ping 8.8.8.8.

On the ISP, configure the return route towards the company - otherwise the replies never come back:
on ISP
```
ISP(config)# ip route 172.20.16.0 255.255.252.0 203.0.113.1
```
The floating route, held in reserve
Traffic towards the LAN of R3 normally goes directly. If the link goes down, we want it to pass through R2. This is obtained by giving the backup route a larger administrative distance:
on R1
```
R1(config)# ip route 172.20.19.0 255.255.255.0 10.0.0.2 200
```
Check with show ip route: the route with AD 200 does not appear in the table as long as the one with AD 1 is valid. Both exist in the configuration, but only one enters the table.

Now shut the direct link and look again:
on R1
```
R1(config)# interface serial 0/1/1
R1(config-if)# shutdown
R1(config-if)# end
R1# show ip route
R1# traceroute 172.20.19.10
```
The route [200/0] via 10.0.0.2 has appeared, and traceroute shows one extra hop. Bring the interface back up and check that the backup route withdraws by itself.

7Summarization and Null0

The three LANs are 172.20.16.0/23, 172.20.18.0/24 and 172.20.19.0/24. The ISP has no reason to know about them separately - one single route is enough for it.

Computing the summary route

See the solution

In binary, the third octet: 16 = 00010000, 18 = 00010010, 19 = 00010011. The blocks covered are .16, .17 (from the /23), .18 and .19 - that is four consecutive values starting from 16. The first 6 bits of the octet are common, so the prefix is 16 + 6 = /22.

The summary route: 172.20.16.0/22, that is 172.20.16.0 255.255.252.0.

On R1, add a route towards Null0 for the unused portion of the summarized block, so that traffic towards non-existent addresses is discarded at once:

on R1

R1(config)# ip route 172.20.16.0 255.255.252.0 null0

Test ping 172.20.20.5 from the ISP: the packet reaches R1 and dies there, instead of travelling around the network looking for a destination that does not exist. The real destinations carry on working, because their routes have a longer prefix and win.

Try 172.20.19.10 (the LAN of R3), 172.20.20.5 (inside the summarized block, but non-existent) and 8.8.8.8 (the Internet). Each falls on a different route, for different reasons - follow the test column to see exactly why.

8Part II: OSPF

Delete everything you wrote
on each router
```
R1(config)# no ip route 172.20.18.0 255.255.255.0 10.0.0.2
R1(config)# no ip route 172.20.19.0 255.255.255.0 10.0.0.6
R1(config)# no ip route 172.20.19.0 255.255.255.0 10.0.0.2 200
R1(config)# no ip route 10.0.0.8 255.255.255.252 10.0.0.2
```
Keep the default route towards the ISP and the one towards Null0. Check with show ip route that only the connected routes remain - and that the ping between the LANs has stopped working again. It is a clean starting point for part two.
Enable OSPF
on R1
```
R1(config)# router ospf 1
R1(config-router)# router-id 1.1.1.1
R1(config-router)# network 172.20.16.0 0.0.1.255 area 0
R1(config-router)# network 10.0.0.0 0.0.0.3 area 0
R1(config-router)# network 10.0.0.4 0.0.0.3 area 0
R1(config-router)# passive-interface gigabitEthernet 0/0/0
R1(config-router)# default-information originate
R1(config-router)# end
```
on R2
```
R2(config)# router ospf 1
R2(config-router)# router-id 2.2.2.2
R2(config-router)# network 172.20.18.0 0.0.0.255 area 0
R2(config-router)# network 10.0.0.0 0.0.0.3 area 0
R2(config-router)# network 10.0.0.8 0.0.0.3 area 0
R2(config-router)# passive-interface gigabitEthernet 0/0/0
R2(config-router)# end
```
On R3, the same, with router-id 3.3.3.3 and the networks 172.20.19.0 0.0.0.255, 10.0.0.4 0.0.0.3 and 10.0.0.8 0.0.0.3.

Wildcard masks are not network masks The network command of OSPF uses a wildcard: the inverse of the mask. For a /24 you write 0.0.0.255, for a /30 0.0.0.3, for a /23 0.0.1.255. The quick rule: subtract each octet of the mask from 255.

The two optional commands that matter passive-interface on the interfaces facing the hosts: the network stays advertised, but no useless Hellos are sent towards the computers any more - bandwidth saved and one attack door closed.
default-information originate on R1: it tells the other routers that it has a way out to the Internet. Without it, R2 and R3 will never learn of the default route.

Check the adjacencies

on R1

R1# show ip ospf neighbor

what should appear

Neighbor ID     Pri   State      Dead Time   Address         Interface
2.2.2.2         1     FULL/BDR   00:00:35    10.0.0.2        Serial0/1/0
3.3.3.3         1     FULL/BDR   00:00:35    10.0.0.6        Serial0/1/1

Both adjacencies must be in the FULL state. If they are missing:

Symptom	The most likely cause
No neighbour in the list	the network is not included in `network`, the wildcard is wrong, or the interface is passive
Stuck in `INIT`	the Hellos leave but do not come back: filtering, wrong VLAN, cable
Stuck in `EXSTART` or `EXCHANGE`	a different MTU on the two interfaces
The adjacency flaps	different hello/dead intervals, or an unstable link

other useful checks

R1# show ip protocols
R1# show ip ospf interface brief
R1# show ip route ospf

Read what the router has learned
show ip route ospf on R1 must show something of this form:
what should appear
```
  O    172.20.18.0/24 [110/65] via 10.0.0.2, Serial0/1/0
  O    172.20.19.0/24 [110/65] via 10.0.0.6, Serial0/1/1
```
110 is the administrative distance of OSPF, 65 is the accumulated cost: 64 for the serial link plus 1 for the LAN interface at the far end. Check on R2 that the default route has appeared as well, marked O*E2 - the sign that it was injected from outside OSPF.

Now test all the pings: everything works without a single route written by hand. This is the difference, in three commands on each router instead of three routes on each router - and the difference grows with every new network.

9The cost, which decides the path

OSPF picks the path with the smallest total cost. The cost of an interface is computed from the bandwidth:

Interface	Bandwidth	Cost = 100 Mbps / bandwidth
Serial, by default	1544 kbps	64
Serial with `bandwidth 64`	64 kbps	1562
FastEthernet	100 Mbps	1
GigabitEthernet	1 Gbps	1 - the minimum cost is 1

The last row is a real problem: with the default reference, a 100 Mbps link and a 10 Gbps link are indistinguishable. It is corrected by raising the reference:

on every router, the same value

R1(config)# router ospf 1
R1(config-router)# auto-cost reference-bandwidth 10000

The same value everywhere If one router has a different reference from its neighbours, it computes incompatible costs and the result is asymmetric routing or loops. IOS displays a warning; do not ignore it.

Force a suboptimal path

on R1

R1# traceroute 172.20.19.10
R1(config)# interface serial 0/1/1
R1(config-if)# ip ospf cost 2000
R1(config-if)# end
R1# show ip route ospf
R1# traceroute 172.20.19.10

With a cost of 2000 on the direct link, the path through R2 (64 + 1562 + 1 = 1627) becomes cheaper than the direct one (2000 + 1 = 2001). traceroute now shows an extra hop. Go back with no ip ospf cost and check that the path returns.

What you have demonstrated You changed no cable and no address. You changed one number, and the whole network recomputed its paths by itself, in both directions. This is, in essence, the entire advantage of dynamic routing.

10The experiment that justifies the whole laboratory

You now have the same network working in two ways. Compare them on the only criterion that matters during a failure: how long it takes until the traffic comes back.

From PC2, start a continuous ping towards PC3 (in Packet Tracer: ping -t 172.20.19.10).
Shut the link the traffic travels on: on R1, interface s0/1/1 followed by shutdown.
Count how many packets are lost until the ping comes back.
Repeat the experiment with static routing, using the floating route configured in part I.

	Static routing with a floating route	OSPF
Detecting the failure	only if the interface goes `down`	through Hellos: at most 40 s, typically far less
Time until switchover	immediate, if the interface went down physically	seconds: detection + flooding + Dijkstra
If the link is "up" but carries nothing	never detects it	detects it from the absence of Hellos
Configuration effort when adding a network	a new route on every router	one `network` command, on one single router

The conclusion of the experiment A floating route switches over quickly, but only if the local interface goes down physically. If the link stays electrically alive and breaks somewhere in the middle - a very frequent scenario on leased lines - the static route notices nothing and the traffic vanishes into thin air. OSPF notices, because it does not rely on the state of the cable, but on the fact that the neighbour answers.

11Assignments

Configure complete static routing and demonstrate connectivity between all three LANs
Demonstrate the working of a floating route: show the table before and after the main link goes down
Compute and configure the summary route, plus the route towards Null0
Delete the static routing and configure single-area OSPF on every router
Document the neighbour table of each router, with the states of the adjacencies
Force OSPF to choose a suboptimal path by changing the cost; demonstrate with traceroute
Measure and report the convergence times in both scenarios
Configure default-information originate and check that R2 and R3 receive the default route, marked O*E2

12Going further

The loop you build yourselves

Go back to static routing and deliberately build a routing loop: traffic from the LAN of R2 towards a certain destination must travel R2 → R1 → R2 → R1… indefinitely.

Which routes must be written, exactly, on each router?
Will the packets circulate for ever? Argue.
Run traceroute towards that destination and describe what you see.
Could OSPF produce the same loop? Why or why not?
Which layer 3 mechanism is missing at layer 2, and is why loops there are fatal?

See the hints

1. It is enough for each of the two routers to point at the other for the same destination: on R2 ip route 192.168.99.0 255.255.255.0 10.0.0.1 and on R1 ip route 192.168.99.0 255.255.255.0 10.0.0.2.

2. No. Every passage through a router decrements the TTL; at zero the packet is discarded and an ICMP time exceeded is sent back to the source.

3. traceroute will display a perfectly visible alternation R1, R2, R1, R2… until the TTL is exhausted. It is the clearest visual demonstration of a routing loop.

4. No, as long as all the routers are in the same area: each has the complete map of the topology and computes shortest paths on a graph - Dijkstra's algorithm produces no cycles by construction. Loops in OSPF appear only at the boundaries between areas or when redistributing between different protocols, that is, exactly where the overall view is lost.

5. The TTL field. The Ethernet header has no equivalent, which is why a layer 2 loop multiplies frames indefinitely - and why STP had to be invented.

13Self-check questions

14Deliverables

Deliverable	Format	Weight
A Packet Tracer file with complete static routing, including a floating route and Null0	.pkt	25 %
A Packet Tracer file with OSPF configured and working	.pkt	25 %
The neighbour and routing tables, with commentary	document	20 %
The convergence measurements, with your own conclusion	document	15 %
Going further: the loop built, with the answers to the five questions	document	15 %