ChatGPT on OSPF Area Ranges and Summary LSAs
I wanted to test a loop prevention when propagating summary LSA across areas scenario (more about that in another blog post) using the lab topology I developed for the When OSPF Becomes a Distance Vector Protocol article.
I started the lab with the FRRouting routers and configured OSPF area ranges. Astonishingly, I discovered that the more-specific prefixes from an area appear as summary routes in the backbone area even when the area range is configured. When I tried to reproduce the scenario a few days later, it turned out to be a timing quirk (I didn’t wait long enough), but my squirrelly mind was already investigating.
I tried to reproduce the scenario with Cisco IOS. Of course, I got only the area range summary prefix in the backbone area (to dispel any potential fake news: FRRouting does the same thing, but it might take a few seconds with the default OSPF SPF/pacing timers). However, I decided to use the opportunity to check whether the leading AI tool would agree with what little I remember from the days when I was developing and delivering the Advanced OSPF Configuration and Troubleshooting course for Cisco Europe.
Here’s what I asked ChatGPT (free version, temporary chat):
The answer was a pleasant surprise. ChatGPT nailed it!
Great scenario! Let’s break it down.
Network Setup Recap:
- R1: in Area 1, advertising 10.0.0.1/32 (a loopback)
- R2: in Area 0 (the backbone)
- ABR: connected to Area 0 and Area 1
- Area 1 has an area range 10.0.0.0/8 configured on the ABR
OSPF Behavior Overview:
- R1 originates a Type 1 LSA (Router LSA) within Area 1.
- R1 also originates a Type 3 LSA (Summary LSA) for its loopback address. But in this case, it’s ABR that actually generates Type 3s to summarize and advertise inter-area routes.
- Since an area range (10.0.0.0/8) is configured on ABR for Area 1, the ABR will summarize any more specific prefixes (like 10.0.0.1/32) into that range when advertising into Area 0.
What LSAs should R2 (in Area 0) see?
R2 should have the following LSAs in its Area 0 OSPF database:
-
Type 1 LSAs (Router LSAs): for routers in Area 0 (including R2 and ABR)
-
Type 2 LSAs (Network LSAs): if there are broadcast/multi-access segments in Area 0
-
Type 3 LSAs (Summary LSAs):
- A Type 3 LSA for 10.0.0.0/8 advertised by the ABR (not the specific /32 route of R1) because of the area range summarization
So R2 will not see:
- The 10.0.0.1/32 directly (because it’s summarized)
- Any Type 1 or Type 2 LSAs from Area 1 (OSPF LSAs are area-scoped)
- Type 4/5 LSAs (unless there’s an ASBR, which you haven’t mentioned)
Summary
| LSA Type | Description | Originator | Present in R2’s DB? |
|---|---|---|---|
| Type 1 | Router LSAs from Area 0 | R2, ABR | ✅ Yes |
| Type 2 | Network LSAs in Area 0 | (if any) | ✅ Yes (if exist) |
| Type 3 | Summary LSA for 10.0.0.0/8 | ABR | ✅ Yes |
| Type 3 | Summary LSA for 10.0.0.1/32 | — | ❌ No (summarized) |
| Type 4/5 | Not mentioned (ASBR-related) | — | ❌ Not applicable |
Considering my previous experience with ChatGPT, I was amazed at the quality of the result, and couldn’t resist asking about my “experience” with FRRouting (slightly abridged, here’s the original chat)… and this is where things went sideways :(
Here’s what I got back:
Ahhh, FRRouting (FRR) — thanks for that detail! That makes things clearer.
The TL;DR answer:
Yes, with FRRouting, it is normal behavior in some cases to still see the more specific Type-3 LSA (like 10.0.0.1/32) in addition to the summary (10.0.0.0/8), even when summarization is configured.
This is different from platforms like Cisco IOS or Juniper, which typically suppress the more specific LSAs when summarizing.
Why this happens in FRRouting:
In FRRouting:
-
The
area RANGEcommand does not automatically suppress the more specific Type-3 LSAs unless certain conditions are met. -
FRR uses what’s called advertise as well as summarize, unless you explicitly prevent it.
So, unless you have a lot of subnets that fall under the summary, FRR may still pass along the specific LSAs.
Also, FRR does not have a native not-advertise option like Cisco, which tells the ABR to only advertise the summary and suppress specifics.
Your options
If you want to suppress the specific 10.0.0.1/32 and only advertise 10.0.0.0/8 to Area 0, your options in FRR are limited but include:
-
Filtering LSAs with route-maps (not trivial in FRR, but possible via prefix-lists + distribute-list filtering on ABR side — kind of hacky though)
-
Accept that FRR may advertise both unless there’s a more complex OSPF implementation behind the scenes
-
Use area range only when multiple prefixes exist — so the summary is actually useful
The correct answer could be “wait a bit and recheck” or “you might have hit a bug.” It could also be that FRRouting had that behavior in the past (in which case, please leave a comment).
Unfortunately, it looks like ChatGPT still tries to please and hasn’t mastered the art of saying no, resulting in highly misleading confabulations (or is it bullshit?). I was particularly upset about the weasely wording like “Cisco IOS typically suppresses the more specific LSAs when summarizing” – it MUST suppress them or it would directly violate the RFC – or “unless you have a lot of subnets that fall under the summary, FRR may still pass along the specific LSAs.” which makes absolutely no sense.
Nonetheless, ChatGPT’s progress in the last year or so is astounding. I would still fact-check everything it produces, but it seems spot-on for simple scenarios.
Can confirm chatGPT 4o is pretty impressive most of the time when you ask it the more 'general' configuration type questions. As your answer from it goes it had probably seen many many instances of the question asked and so its statistical model was able to provide a sane and mostly correct answer.
Anytime you get towards what is likely more corner cases beware the LLM answers.