OSPF Summarization and Asymmetric Return Path
Contoso Retail runs OSPF across a hub-and-spoke WAN. HQ is area 0; three regional hubs are ABRs for areas 1, 2, and 3. Each of 60 branches is dual-homed to two hubs over metro Ethernet and runs HSRP on its LAN. A new summary route for the payment server farm is configured as 10.16.0.0/12 on Hub A only. Since the change, branch users in area 3 reach the farm through Hub A but return traffic from the farm enters Hub B, and the data-center firewall drops 8% of sessions as asymmetric. Latency to the farm rises from 12 ms to 85 ms. Hub A and Hub B both advertise a default route into their areas; no area is stubby. The payment subnet is actually 10.20.5.0/24 and 10.20.6.0/24, and area 2 also contains 10.18.0.0/16. What is the root cause? How would you redesign summarization and first-hop routing? What verification shows the fix?
1. Explain the root cause of the asymmetric traffic and the latency increase. Include why the 10.16.0.0/12 summary is dangerous.
Read the worked answer
The /12 summary is far too broad: 10.16.0.0/12 covers 10.16.0.0 through 10.31.255.255, which includes the real payment subnets 10.20.5.0/24 and 10.20.6.0/24 but also area 2's 10.18.0.0/16 and many unallocated ranges. Hub A advertises that single summary, so branches prefer it over the default route because it is a longer match. Forward traffic therefore goes through Hub A. Return traffic from the payment farm follows its own default route to Hub B, which is a different path. The firewall sees TCP SYN and SYN-ACK on different interfaces or different stateful inspection contexts and drops sessions. The latency jump from 12 ms to 85 ms is consistent with tromboning through Hub A and back through Hub B. The summary can also blackhole 10.18.0.0/16 if Hub A does not have a route for it, because the /12 hides the more specific area 2 route from area 3.
2. Redesign the OSPF summarization and first-hop routing so both directions use the same path and area 2 remains reachable. Be specific about the summary prefix length and where it is configured.
Read the worked answer
Remove 10.16.0.0/12 from Hub A. Summarize only the payment range, and only if every address in the summary is actually present in the area. With 10.20.5.0/24 and 10.20.6.0/24, a safe summary is 10.20.4.0/22 only if 10.20.4.0/24 and 10.20.7.0/24 are allocated and reachable; otherwise advertise the two /24s. Configure the same summary on both Hub A and Hub B so the branch sees equal-cost or deliberately biased paths, not one summary from one ABR and a default from the other. Never summarize 10.18.0.0/16 into the same prefix. For first-hop symmetry, align HSRP active priority with the OSPF cost on the same hub and add interface tracking. If the branch HSRP active is Hub A, make Hub A also the preferred OSPF next hop for the payment prefix; if Hub B must be standby, it should not advertise a better return path. Where the data center controls the return default, set it to the same hub or use a stateful firewall pair that supports asymmetric routing.
3. What commands and tests would you use to prove the fix and prevent a repeat?
Read the worked answer
Prove the forward path with traceroute from a branch in area 3 to 10.20.5.1 and prove the return path with traceroute from the payment server to the branch. Use show ip route 10.20.5.0 and show ip route 10.18.0.0 on branch and hub routers to confirm longest-match behavior, and show ip ospf database summary to see which ABR originates which Type 3 LSAs. Check show ip ospf border-routers and show ip cef on the hubs for the actual forwarding next hop. On the firewall, compare session tables and counters for drops; a bidirectional capture at the branch and data center should show the same hub address. To prevent recurrence, require that any summary be generated only for an address range fully owned by that area, document the allocation plan, and test both directions before and after every summarization change.