Lab: Multi-area OSPF

Objective

By the end of this lab you will have built a two-area OSPF domain and answered, with database counts rather than opinion, the question every area design turns on: what did the boundary buy, and what did it cost? You will summarise four site prefixes into one, then fail one of the four and watch the backbone continue to advertise a route to it — because that is not a bug in summarisation, it is what summarisation is.

Architecture

Three routers, one area boundary, and enough prefixes on each side of it for the boundary to have something to do.

   external 203.0.113.0/24                         area 10
   (blackhole, redistributed)                  172.16.0.0/24  vif 100
             |                                 172.16.1.0/24  vif 101
        +----+-----+                           172.16.2.0/24  vif 102
        |  R-CORE  | lo 10.255.0.1/32          172.16.3.0/24  vif 103
        +----+-----+                                  |
     eth1 |       | eth0 10.0.0.1/24              eth1 | trunk
  br-core-vlans   |                              +-----+------+
  10.20.0.1/24    |     br-backbone              |   R-SITE   | lo 10.255.0.3/32
  10.21.0.1/24    |     10.0.0.0/24  area 0      +-----+------+
                  |                                    | eth0 10.10.0.2/30
             eth0 | 10.0.0.2/24                        |
        +---------+---------+                     br-area10
        |      R-ABR        | lo 10.255.0.2/32    10.10.0.0/30
        +---------+---------+   area 0 <-> area 10  point-to-point
             eth1 | 10.10.0.1/30
                  +---------------------------------->

The four site prefixes are VLAN sub-interfaces on one trunk, and the two core prefixes are the same trick on the backbone side. They are ordinary Ethernet interfaces as far as OSPF is concerned, they carry no hosts, and they exist so that each side of the boundary has a set of prefixes worth summarising or suppressing. 203.0.113.0/24 is a blackhole static on R-CORE, redistributed into OSPF so that a genuine Type-5 external LSA exists to watch a stub area remove.

Requirements

• A hypervisor able to run three guests across four isolated layer-2 segments: br-backbone, br-area10, br-core-vlans, br-site-vlans. Nested virtualisation is sufficient.
• Three VyOS 1.5 LTS (circinus) guests, installed to disk, 1 GB RAM and two NICs each. Every command here is VyOS 1.5 syntax and has not been executed end to end for this writing, so treat the outputs as shapes to match.
• Console access to R-ABR and R-SITE. Task 6 breaks the adjacency between them on purpose. If you are managing either router across br-area10 you will lose the session at that step.
• Roughly 4 GB of RAM and 12 GB of disk in total.
• No hosts, no DHCP, no upstream connectivity. Every address in this lab is inside documentation or private space and nothing leaves the four bridges.

Scenario

A regional site has grown to four VLANs and the backbone team has started asking why their routers hold a route for each of them. You have been asked to put the site behind an area boundary and summarise it, and the change record has a line you are expected to fill in honestly: what visibility does the backbone lose?

Answering that with “not much” is the failure mode this lab exists to prevent. By Task 5 you will have a number, and by Task 6 you will have watched the backbone advertise a route to a prefix that had gone away.

Tasks

Task 1: Wire the segments and save the pre-lab configuration

Create the four bridges with no physical port attached. Attach eth0 and eth1 on each router as shown in the Architecture table.

On each router:

show configuration commands | save /config/pre-multiarea-lab.txt

Task 2: Address everything and originate one external route

R-CORE carries the backbone, two core VLANs and the external:

configure
set system host-name r-core
set interfaces loopback lo address 10.255.0.1/32
set interfaces ethernet eth0 address 10.0.0.1/24
set interfaces ethernet eth0 description 'backbone'
set interfaces ethernet eth1 description 'core services trunk'
set interfaces ethernet eth1 vif 20 address 10.20.0.1/24
set interfaces ethernet eth1 vif 20 description 'core services A'
set interfaces ethernet eth1 vif 21 address 10.21.0.1/24
set interfaces ethernet eth1 vif 21 description 'core services B'
set protocols static route 203.0.113.0/24 blackhole
commit
save
exit

R-ABR sits on both sides of the boundary:

configure
set system host-name r-abr
set interfaces loopback lo address 10.255.0.2/32
set interfaces ethernet eth0 address 10.0.0.2/24
set interfaces ethernet eth0 description 'backbone'
set interfaces ethernet eth1 address 10.10.0.1/30
set interfaces ethernet eth1 description 'area 10 transit'
commit
save
exit

R-SITE carries the four site VLANs:

configure
set system host-name r-site
set interfaces loopback lo address 10.255.0.3/32
set interfaces ethernet eth0 address 10.10.0.2/30
set interfaces ethernet eth0 description 'area 10 transit'
set interfaces ethernet eth1 description 'site VLAN trunk'
set interfaces ethernet eth1 vif 100 address 172.16.0.1/24
set interfaces ethernet eth1 vif 101 address 172.16.1.1/24
set interfaces ethernet eth1 vif 102 address 172.16.2.1/24
set interfaces ethernet eth1 vif 103 address 172.16.3.1/24
commit
save
exit

Confirm the sub-interfaces came up before you build anything on top of them:

show interfaces

Task 3: Build the two areas

The area an interface belongs to is decided by the network statement that matches its address. One statement per prefix, and the area id is part of the statement rather than a property of the router.

R-CORE, entirely in area 0, and originating the external:

configure
set protocols ospf parameters router-id 10.255.0.1
set protocols ospf area 0 network 10.0.0.0/24
set protocols ospf area 0 network 10.255.0.0/24
set protocols ospf area 0 network 10.20.0.0/24
set protocols ospf area 0 network 10.21.0.0/24
set protocols ospf interface eth1.20 passive
set protocols ospf interface eth1.21 passive
set protocols ospf redistribute static
set protocols ospf redistribute static metric-type 1
commit
save
exit

R-ABR, with one foot in each area. This is the only statement that makes a router an ABR — there is no abr keyword:

configure
set protocols ospf parameters router-id 10.255.0.2
set protocols ospf area 0 network 10.0.0.0/24
set protocols ospf area 0 network 10.255.0.0/24
set protocols ospf area 10 network 10.10.0.0/30
set protocols ospf interface eth1 network-type point-to-point
commit
save
exit

R-SITE, entirely inside area 10. Note that one network statement covers all four site VLANs, because a network statement is a match against interface addresses rather than a prefix to advertise:

configure
set protocols ospf parameters router-id 10.255.0.3
set protocols ospf area 10 network 10.10.0.0/30
set protocols ospf area 10 network 10.255.0.0/24
set protocols ospf area 10 network 172.16.0.0/22
set protocols ospf interface eth0 network-type point-to-point
set protocols ospf interface eth1.100 passive
set protocols ospf interface eth1.101 passive
set protocols ospf interface eth1.102 passive
set protocols ospf interface eth1.103 passive
commit
save
exit

Confirm the shape of the domain from evidence. On R-SITE:

$ show ip ospf border-routers

============ OSPF router routing table =============
R    10.255.0.2            [10] area: 0.0.0.10, ABR
                         via 10.10.0.1, eth0

A missing row here is the finding that matters most in a multi-area estate: an area with no reachable ABR is stranded, and every inter-area prefix it should have is simply absent. Then on R-ABR:

show ip ospf
show ip ospf interface
show ip ospf neighbor

show ip ospf reports this router as an ABR and lists both areas with their interface counts. show ip ospf interface shows which interface is in which area — that pairing is the audit surface for the whole design, and it is worth pasting into the change record.

Task 4: Inventory the database before you change anything

This is the measurement the rest of the lab is compared against. Take it on both sides of the boundary and write the counts down.

On R-CORE, in the backbone:

show ip ospf database
show ip ospf database summary
show ip route ospf

You should find four Type-3 summary LSAs for the site prefixes — 172.16.0.0/24 through 172.16.3.0/24 — advertised by 10.255.0.2, plus a Type-3 for the area 10 transit link and one for R-SITE’s loopback. Every one of them is a separate LSA, a separate routing-table entry, and a separate thing to recompute when the site changes.

On R-SITE, inside area 10:

show ip ospf database
show ip ospf database summary
show ip ospf database external
show ip route ospf

Area 10 is a standard area today, so it holds everything: Type-3 summaries for the backbone prefixes, and a Type-5 external for 203.0.113.0/24 that R-CORE redistributed. Record the count of each. Confirm the external is genuinely usable rather than merely present:

show ip route 203.0.113.0/24

Task 5: Summarise at the ABR

The four site prefixes were chosen to aggregate cleanly: 172.16.0.0/24 through 172.16.3.0/24 are exactly 172.16.0.0/22. On R-ABR:

configure
set protocols ospf area 10 range 172.16.0.0/22
commit
save
exit

Now repeat the Task 4 inventory on R-CORE:

show ip ospf database summary
show ip route ospf

The four component prefixes are gone from the backbone and one 172.16.0.0/22 has taken their place. Confirm the negative explicitly — the range prefix present and the components absent — because a Type-3 for 172.16.1.0/24 sitting next to the /22 means the range is not matching what you think it is.

Then check the place the summary did not change anything. Aggregation alters only what leaves an area, so inside area 10 the four /24s are still learned in full detail from R-SITE’s Type-1 router LSA. R-ABR is the router that can show you both views at once, because it is a member of both areas:

show ip ospf database router
show ip route ospf

$ show ip route ospf

O>* 172.16.0.0/24 [110/20] via 10.10.0.2, eth1, 00:04:11
O   172.16.0.0/22 [110/20] via 0.0.0.0, Null0, 00:00:36
O>* 172.16.1.0/24 [110/20] via 10.10.0.2, eth1, 00:04:11

The ABR installs a discard route for every range it advertises, automatically and without configuration. It exists to stop the ABR forwarding a packet for the range back toward whoever sent it when no component prefix matches. Nothing has been lost yet — the more specific /24s are longer matches and win — but that Null0 entry is the mechanism behind everything in Task 6.

Confirm the data plane still works end to end. From R-CORE:

ping -c 3 -W 2 172.16.1.1
ping -c 3 -W 2 172.16.3.1

Task 6: Measure what the summary hides

A site VLAN fails. On R-SITE, take one down:

configure
set interfaces ethernet eth1 vif 101 disable
commit
exit

Now work outwards. On R-SITE, the prefix has gone from the local routing table and from the area’s topology. On R-ABR:

show ip route ospf

172.16.1.0/24 is no longer there. R-ABR knows. Now the backbone, on R-CORE:

show ip ospf database summary
show ip route ospf
show ip route 172.16.1.1

Nothing changed. R-CORE still has 172.16.0.0/22, still resolves 172.16.1.1 against it, and still believes the destination is reachable. The /22 is advertised as long as any component is present, so three surviving VLANs keep the summary alive.

Now find out what that costs, from the data plane:

ping -c 3 -W 2 172.16.1.1

The route exists and the ping fails. The packet follows the /22 to R-ABR, finds no more-specific route there, matches the discard route, and is dropped. A monitoring system that alerts on route presence sees nothing. One that pings the gateway sees the failure immediately, and that difference is the entire argument for monitoring inside the area rather than at the boundary.

Bring the VLAN back and confirm both views recover:

configure
delete interfaces ethernet eth1 vif 101 disable
commit
save
exit

Before leaving summarisation, try the other modifier on R-ABR. A range marked not-advertise suppresses its components and originates no summary at all. Take the /22 out of the way first, so what you are watching is one range rather than the interaction of two:

configure
delete protocols ospf area 10 range 172.16.0.0/22
set protocols ospf area 10 range 172.16.3.0/24 not-advertise
commit
exit

On R-CORE, three site prefixes are back as individual Type-3 summaries and 172.16.3.0/24 is absent entirely — no component, no summary, no route. It is an area filter rather than a global one, so a prefix that also arrives by another protocol is unaffected and has to be filtered there too. Put the aggregate back:

configure
delete protocols ospf area 10 range 172.16.3.0/24
set protocols ospf area 10 range 172.16.0.0/22
commit
save
exit

Task 7: Make area 10 a stub, and break it first

The site does not need the backbone’s external routes; it needs a way out. That is what a stub area is for. Apply it the way an operator under time pressure applies it — on the ABR, where the change “obviously” belongs:

configure
set protocols ospf area 10 area-type stub
commit
exit

Within a dead interval the adjacency between R-ABR and R-SITE is gone. Diagnose it rather than undoing it. On R-ABR:

show ip ospf neighbor
show ip ospf interface eth1

The neighbour has vanished entirely — not stuck at ExStart, not flapping, but absent, while the interface is up and the link is fine. Prove the link is fine:

ping -c 3 -W 2 10.10.0.2

That combination is the signature. ExStart means the Hellos agreed and the database exchange failed; an empty neighbour table with a healthy link means the Hellos themselves are being discarded. RFC 2328 section 10.5 lists what a router checks in a received Hello before it will accept the sender as a neighbour, and the E-bit — the sender’s external-routing capability — is on that list. R-ABR now clears E on that interface and R-SITE still sets it, so each discards the other’s Hello.

Watch it happen:

timeout 30 tcpdump -ni eth1 -vv proto ospf

Hellos are visible in both directions. Nothing is lost on the wire; both routers are choosing to ignore what arrives.

Fix it on R-SITE:

configure
set protocols ospf area 10 area-type stub
commit
save
exit

The adjacency returns. Now inventory the effect:

show ip ospf database external
show ip ospf database summary
show ip route ospf

show ip ospf database external on R-SITE is empty — Type-5 LSAs are not flooded into a stub area, and the ABR is the wall. In their place the ABR has injected a default route as a Type-3 summary, so R-SITE still has a way to reach 203.0.113.0/24; it simply no longer knows anything about it. Confirm both halves:

show ip route 0.0.0.0/0
show ip route 203.0.113.0/24

The first has a route via the ABR; the second resolves through the default rather than through a specific external. Compare the database counts with the Task 4 numbers and write the difference down.

Task 8: Make it totally stubby, and notice which flag did not have to match

A stub area still receives every inter-area Type-3 the ABR can generate — in this topology, the two core VLANs, the backbone segment and R-CORE’s loopback. The site needs none of them. no-summary suppresses them all except the default, and unlike the stub flag it belongs on the ABR alone:

configure
set protocols ospf area 10 area-type stub no-summary
commit
save
exit

Run that on R-ABR only. Then, on R-SITE:

show ip ospf neighbor
show ip ospf database summary
show ip route ospf

The adjacency is untouched. no-summary is an instruction to the ABR about what it originates; it is not advertised in the Hello, so there is nothing for the two routers to disagree about. The summary database now holds a single Type-3 for 0.0.0.0/0, and the routing table for area 10 is its own prefixes plus one default.

Confirm the data plane survived the diet. From R-SITE:

ping -c 3 -W 2 10.20.0.1
ping -c 3 -W 2 10.255.0.1

Both still work, over the default route rather than over a specific summary. That is the whole bargain of a totally-stubby area: the site keeps every path it had and loses every piece of information about them.

Finally, take the counts one last time and assemble the table your change record needs:

Validation

• show ip ospf border-routers on R-SITE lists 10.255.0.2 as an ABR reached through area 10.
• show ip ospf on R-ABR reports two areas and identifies the router as an ABR; show ip ospf interface puts eth0 in area 0 and eth1 in area 10.
• show ip ospf database summary on R-CORE contains 172.16.0.0/22 and none of 172.16.0.0/24, 172.16.1.0/24, 172.16.2.0/24, 172.16.3.0/24.
• show ip ospf database summary on R-SITE contains exactly one entry, for 0.0.0.0/0.
• show ip ospf database external on R-SITE is empty, and the same command on R-CORE still shows 203.0.113.0/24.
• show ip route ospf on R-ABR contains a 172.16.0.0/22 entry via Null0 alongside the four component /24s via 10.10.0.2.
• From R-CORE, ping -c 3 172.16.1.1 and ping -c 3 172.16.3.1 both succeed, and ping -c 3 10.255.0.3 reaches R-SITE’s loopback.
• From R-SITE, ping -c 3 10.20.0.1 succeeds and show ip route 10.20.0.1 resolves through 0.0.0.0/0 rather than through a /24 summary.
• show ip ospf neighbor on both R-ABR and R-SITE shows one neighbour in Full/- — point-to-point, so no DR role.

Expected Outcome

A two-area OSPF domain in which the backbone holds one route for a four-VLAN site instead of four, the site holds one route for the entire rest of the world, and every router still reaches every prefix. You have a database inventory at four configurations, a measured example of an outage the backbone could not see, and a diagnosed area-type mismatch with the Hello capture that identified it.

Troubleshooting

show ip ospf border-routers is empty on R-SITE. No ABR is reachable. Check that R-ABR really has an interface in area 0 — an ABR with both interfaces in non-backbone areas is not an ABR, and OSPF will not tell you so.

The site prefixes never appear in the backbone. Check R-SITE’s network statement against the interface addresses. network 172.16.0.0/22 matches all four /24s; network 172.16.0.0/24 matches only the first, and the other three interfaces stay outside OSPF entirely with no error.

The range is configured and the components are still in the backbone. The range does not cover them. Compare the range against each component prefix bit by bit; 172.16.0.0/23 covers two of these four, and the other two keep crossing as individual summaries.

The adjacency drops right after an area-type change. The area type is set on one router and not the other. It has to be identical on every router with an interface in that area. no-summary is the exception and belongs on the ABR alone.

show ip ospf database external is not empty inside the stub area. Either the stub flag has not been applied on this router, or the external is arriving by a path that is not OSPF. show ip route 203.0.113.0/24 names the protocol that installed it.

A ping fails against a route that is present. You are in Task 6 whether you meant to be or not. The route is a summary, the component behind it is gone, and the ABR’s discard route is dropping the packet. Check the component prefixes on the ABR, not on the router that has the summary.

Cleanup

Nothing here writes outside the routers’ configuration, and the restore is a single load per router. Do the protocol first so the domain tears down in an orderly way rather than through a config replacement.

Step 1. On each router:

configure
delete protocols ospf
commit
save
exit

Step 2. Confirm the domain is gone before restoring anything:

show ip ospf neighbor
show ip route ospf

Both are empty on all three routers.

Step 3. Restore the pre-lab configuration. load replaces the candidate wholesale, so read the diff before committing it:

configure
load /config/pre-multiarea-lab.txt
compare
commit
save
exit

Step 4. Confirm the routers are back where they started, including the VLAN sub-interfaces and the blackhole static:

show configuration commands
show interfaces
show ip route static

Step 5. Delete the four bridges on the hypervisor if you are finished with them.

What You Learned

• An ABR is made by its interfaces, not by a keyword. One router with a network statement in each of two areas became the boundary, and show ip ospf border-routers on the far side is how the rest of the domain confirms it.
• A network statement is a match, not an advertisement. One network 172.16.0.0/22 line put four VLAN sub-interfaces into area 10, and the prefixes that reached the database came from the interface addresses.
• Summarisation changes only what leaves the area. The backbone went from four Type-3 LSAs to one while area 10’s own view was untouched, and the ABR quietly installed a discard route you did not configure.
• The discard route is where the cost lands. A failed component prefix left the summary standing, the backbone kept advertising a route to it, and the packet died at the ABR — a ping that fails against a route that exists.
• The stub flag must match everywhere; no-summary must not. The first is carried in the Hello and an ABR-only edit silently destroys the adjacency; the second is a local instruction to the ABR and changes nothing about neighbour formation.
• Area types are measured in database counts. You have four inventories, and each row of that table is a real trade between what the routers hold and what they can see.