OSPF Summarization Issue

[ten]

We are running a collapsed core so the closet switches are directly connected to each core switch via a layer 3 point-to-point link.

The closet switches are in OSPF area 1 as are their links to the core devices.

The link between the core devices is in OSPF area 0.

The closet subnets are summarized into one route from area 1 into in area 0.

The problem occurs if a link to the closet goes down to say, core A.

Core A still has the summary route and does not learn a more specific route to the closet switch with the down link from core B, because core B passes the summarized route to core A via the area 0 P2P link between the two.

So core A routes traffic to Null0 for that subnet.

Any ideas on how to get around this other than by turning off summarization?

[Richard Burts]

I am not clear about the topology of the network that you describe. Am I correct in understanding that access switch 1 (which has subnet 1) might be connected to core A and that access switch 2 (which has subnet 2) might be connected to core 2, and that access switch 1 has no connectivity to access switch 2? In this situation when core 1 gets a packet with destination subnet 1 it seems that it would try to forward via core 2 and the packet gets dropped. Or is the problem something else?

If the network has that type of single connected topology then the loss of connectivity to access switch 1 would seem to always isolate access switch 1. And the only solution for this is some degree of redundant connection. Either access switches should be dual connected to two cores or access switches should have connectivity to other access switches. Perhaps another alternative to consider would be to consider changing the OSPF areas design. Perhaps you could put the closet switches connected to core 1 into area 1 and put the closet switches connected to core 2 into area 2. This would seem to solve the problem of core 2 advertising a summary to core 1 for subnets that core 2 does not have access to.

I wonder if the network is two cores connected via point to point (so that area 0 is only that point to point link) and a group of closet switches in area 1 what real benefit there is to running OSPF with multiple areas. For this topology I would think that configuring OSPF to use just a single area would work pretty well and would avoid the problem that you describe.

HTH

Rick

[bojanvonkaenel]

Same question here.

I try to give more specific Information:

Two Collapsed-Cores, both ABR's.

Each Access-Switch connects to BOTH cores, using L3 P2P-Links.

Both Cores learn the Client-Subnets trough OSPF, using a non-zero-area (lets say area 1).

The interconnect of the two Cores is Area 0.

Trough the interconnect, both Cores learn the Summary of all the Client-Subnets.

Now the Problem:

Lets say, that the Link between Core 1 and the Access-Switch Fails.

Core 1 don't have a specific entry to that Client-Subnet anymore, and sends the traffic to Null0,

because it only has the Summary-entry in Area 0.

See also the attached Drawing.

[John Blakley]

Bojan,

I'm assuming that you have a range command on your core switches to do the summary? If so, you should be able to do the summarization on both switches so both advertise the summary route. Otherwise, you're going to have more specific routes in your table and your traffic won't go the direction that you're wanting it to anyway.

HTH,

John

[bojanvonkaenel]

John, thank you for your Answer.

I have currently a small lab-setup, and here are some Details:

On the Cores i use

  area 60 range 10.60.0.0 255.255.0.0

to summarize the routes. (In fact, i use Area 60 instead of 1 for Client-Subnets).

The routing table looks like this, in the case, when the link between the Access-Switch and Core 1 fails:

On Core 1:

O       10.60.0.0/16 is a summary, 00:03:50, Null0

On Core 2:

C       10.60.1.0/24 is directly connected, GigabitEthernet1/0/3

O       10.60.0.0/16 is a summary, 00:01:02, Null0

So, in that case, Core 1 cannot reach the Network 10.60.1.0/24.

But in fact, Core1 could reach 10.60.1.0/24 trough Core 2.

-------

Without summarization (no area 60 range 10.60.0.0 255.255.0.0), it looks like this:

On Core 1:

O IA    10.60.1.0/24 [110/200] via 10.0.0.30, 00:00:08, GigabitEthernet1/0/1

On Core 2:

C       10.60.1.0/24 is directly connected, GigabitEthernet1/0/3

Core 1 reaches 10.60.1.0/24 trough Core 2.

[Richard Burts]

One solution that should work for this would be to configure a GRE tunnel between the cores with the tunnel source address and the tunnel destination address using the interfaces in area 0. Assign the GRE tunnel to area 60. This way the cores will exchange their detailed routers in area 60 via their surviving connection in area 0. Then if the connection to the access switch fails the core will still know of the route to the individual prefixes in area 60.

HTH

Rick

[bojanvonkaenel]

Rick

Interesting, i had a similar Idea:

In the Lab, i currently use cat3750 in the core to test this. So it should be possible to have a VLAN-Trunk between the Cores, with one VLAN for Area 0 and one VLAN for Area 60.

I think i will try this.

What about the VLAN-Idea v.s. the GRE-Tunnel?

What is best-practice?

Thanks!

[Richard Burts]

This is an interesting suggestion. And it made me realize that my suggestion of using GRE is quite router centric. In general GRE would be supported in almost all router IOS. But in fact very few switch IOS support GRE. So if the issue comes up in a network which is using Layer 3 switches as the OSPF routers then your suggestion of a trunk between the cores with a VLAN in area 0 and a VLAN in the other area would be a nice solution.

Note that suggesting a trunk between the cores implies that the cores are directly connected. This would be quite possible in some networks but might be difficult or impossible in some other networks. Since GRE takes away the greographical constraint, I would suggest that the GRE solution is preferred in networks where GRE is supported. And that the trunk is a good alternative in situations where GRE is not supported.

HTH

Rick

[rettuc_ccnp]

If each closet switch is connected to each "core switch" this issue  shouldn't require any special configurations or protocol outside of  OSPF.  What is trying to be accomplished here is fundamental...

how and where summarization is being configured seems suspect...

OSPF summarization (assuming that is what has been configured vs. a  summarized static route) should only be configured on the ABR (internal  summarization) or the ASBR (external summarization) which in either case  a failure of one link should cause the path via to the summarized route  via that link to be withdrawn and the secondary path injected.  Since  this isn't happening I'm wondering if something is misconfigured or not  configured at all.

- ten,

     can you explain how and at which device/s you are summarizing?