I've deliberately drawn the Ethernet L2 topologies as lines (rather than switches) because it's an L3 problem. Assume that the L2 gear is super-robust: multiple power supplies, multiple supervisors, etc... The muliaccess Ethernets might even be 10BASE5 :-)
The problem is not a typo (if there are typos, I'll fix 'em). The problem is also not related to failure of a non-redundant device like R5. If R5 goes down, all of the hosts in Area 5 will become unreachable. That's obvious. The problem I've introduced will be somewhat surprising because it's in a redundant area. It's subtle, but detailed in the diagram, and can be eliminated with a telnet client. Can you spot it?
R1, ospf redistribute static needs subnets
ReplyDelete:-)
ReplyDeleteYeah it's not the 'subnets' keyword. I peppered the configurations with a few configuration differences that would be meaningless to reachability in this network.
This problem is subtle, but I thought it'd be too easy if I only cited the one line of configuration which introduces the problem.
Is it "area 5 stub no-summary" vs. "area 5 stub"? I'm guessing the one with "no-summary" is the way to go.
ReplyDeleteR4 and R3 disagree about the stubbiness of area 5. This means that R4 will advertise specific routes from area 0 and area 6 into area 5, and R3 will not. The specific routes 10.0.0.0/31, etc... will cause R4 to be the preferred path for that prefix.
ReplyDeleteIt's stupid, but doesn't introduce a reachability problem.
Keep looking!
The entire 10.6.1.0/24 subnet will not have connectivity to the rest of the network because the "network" command is configured incorrectly on R6. The way it's configured now indicates that OSPF should be run on an interface with an IP address of exactly 0.0.0.0, which of course does not exist, so R6 won't even establish neighbor relationships with R3 and R4.
ReplyDeleteHi Matt,
ReplyDeleteUsing the network command in this way enables OSPF on all interfaces (in 12.4(25d) anyway).
It doesn't look like it should work, but it does!