Dynamic Route Failover

[Jesse Hottle]

Hello,

I am trying to get our network traffic to dynamically pick the best route out/in in case of a link failure. I have attached a diagram showing our current router links. The majority of the links are connected to the end-point routers using wireless backhaul bridges. We have two connections forming a ring back to our central noc. (DS3, and PTP fiber connections). Can any one help with this?

[Jesse Hottle]

Here is a config of the 3550

[Istvan_Rabai]

Hi Jesse,

This config seems to me OK, with one reservation:

Why do you configure the secondary ip addresses on Fa0/1, Fa0/2 and Fa0/3?

As far as I understand, they are point-to-point interfaces to another layer3 switch or router.

So there is no reason to define an additional subnet on that link. Or is there?

Can there be hosts on the secondary subnet?

Thanks:

Istvan

[Jesse Hottle]

There are backhaul units that I need management IP addresses on. I didnt want them to be on the same address space as the routable inteface IP's.

How can I change the default costs for routes. I want some traffic to route out different paths as a priority.

J

[Istvan_Rabai]

Hi Jesse,

If you want to change the default cost of the default route you need to apply this command:

default-information originate metric xxx metric-type [1|2]

If you want to change the default cost of other routes you can do it by several ways:

1. On interface level change the bandwidth parameter of the interface, like this:

interface fastethernet 1/1

bandwidth 100000 (kbits per second)

2. On interface level you can use the "ip ospf cost x" command

3. Under the routing process you can change the auto-cost reference-bandwidth:

router ospf 1

auto-cost reference-bandwidth 1000

Default is 100, which means the ospf process will calculate the interface cost according to this:

cost= 100*1000,000 / bandwidth (Mbps)

This is why the default cost of a fastethernet link is 1.

If you increase the auto-cost reference-bandwidth to 1000 (for example) then the ospf costs of ALL interfaces on that router will be multiplied by 10. This gives you more granularity in applying ospf cost to interfaces.

It is recommended to use this command on all routers within the network, and then use the bandwidth and/or ip ospf cost commands to set the desired link costs.

Cheers:

Istvan

[Jesse Hottle]

If all the interfaces are fastethernet then why wouldn't I want to assign a cost reference of 1000 to each? Also, I got a big problem with traffic not routing anything out at all over one of the ospf links on the 3550. Traffic seems to only be going one way, when a shorter path is available.

[Istvan_Rabai]

Hi Jesse,

This is the normal behavior of routing protocols: they install the least cost routes in the routing table.

This implies that the router will route traffic through the least cost route (shorter path).

So this should not be a problem.

Anyway, if you want to route traffic through another interface, then you can play around with the link costs.

If you want to route a specific well-defined traffic through another interface, then you can use policy based routing.

Cheers:

Istvan

[Jesse Hottle]

Hello again,

Is there a reason on my serial ds3 connection to router A, that I am not using an ip ospf network type command on each interface? Just trying to understand why that is.

Thanks,

j

[Jesse Hottle]

Hello,

I tried changing the interface costs on the 3550. I set on to a cost of 20 the other to a cost of 10. I want all traffic to route out the interface with a cost of 10, but still there is zero traffic passing this interface. The only traffic that passes is if I login to the switch on the IP assigned to that int.

This has me stumped. Everything else appears to be ok.

[Istvan_Rabai]

Hi Jesse,

You should have a look at the cost of a whole path in the routing table of the 3550. (show ip route)

The cost of a path is the summarized cost of all links that lies between the source and destination.

This summarized path cost should be the least cost path for it to be elected into the routing table.

So if you change the ip ospf cost of one interface only in the path, that may not be enough.

Probably the cost of the DS3 line contributes the most to the path cost.

You should then change the cost of this interface on router B (in the Redundant Project.bmp file).

BUT: you should be aware that if you change the cost of the DS3 interface this will change the costs of routes in all ospf routers, and thereby rearranging the routing tables in some routers.

One way is to play around with the cost of this interface.

Another way may be to install a static route into your 3550 for some destinations via the DS3 link.

A third way may be, as I mentioned earlier to use policy based routing for some well defined traffic types to override the contents of the routing table.

Concerning your previous question on the DS3 line: The reason you may have this line is for redundancy at least. So if one of your routers or links goes down to router A, then you will have an instantaneous failover to the other route towards router A.

Otherwise, I'm glad everything else works fine.

Cheers:

Istvan

[Jesse Hottle]

I think my routing tables are creating a loop to one of the networks behind one of the 3550's. Running the trace command from any routers other that the CORE Router A, takes forever to complete, if it even does. Traces from Router A fly right out. However, I have no issue pinging any network I have being advertised.

Also, the link in question does failover if I disable the other connected path, traffic flows just fine. Do you recommend any thing for maybe load balancing on just this router? Also, it seems my routing tables are way, way to big.

[Istvan_Rabai]

Hi Jesse,

Based on the drawings I had no idea that your network will grow up so big :)

If you consider your routing tables are too big, then you can make the networks behind your 3550s and 7206s different OSPF areas and then summarize those routes into the backbone with the "area x range" command.

By backbone I mean the ring formed by the 7507, 3550s and 7206s on the Redundant_Project.bmp file.

So the interfaces in this backbone should remain in area 0, and interfaces going away from this ring can be different areas, like 1, 2, 3, 4.

I don't see in your drawing how many subnets are behind the different routers. If there are more than 1, then it may be worth to create an area out of them and then summarize the routes within each area into the backbone as one summarized route.

For this, the addressing scheme needs to be hierarchical.

This means that if there are 4 subnets behind a 3550, then they should be easily summarizable, like the following:

1. 10.1.0.0/24

2. 10.1.1.0/24

3. 10.1.2.0/24

4. 10.1.3.0/24

These 4 subnets then can be summarized into 10.1.0.0/22

If these subnets would be in area 1 on a 3550 then the summarization would look like this:

router ospf 1

area 1 range 10.1.0.0 255.255.252.0

And this would reduce the size of the routing tables in your backbone (area 0) by advertising only 10.1.0.0/22 into the backbone.

For area 2 you could use the 10.2.0.0 range and the summarized route would began with the 10.2. prefix.

This way it would be easily seen in each backbone router which area the given summarized route belongs to (this is just for the readability of your routing tables).

Of couse, these are just general hints, you should consider your specific adressing scheme and adapt all this to it, if you think these are adaptable.

Cheers:

Istvan

[Jesse Hottle]

What about IP subnets that are spread out across multiple routers?

Example:

Router B - 192.168.2.0/24

192.168.3.0/24

Router C - 192.168.4.0/24

192.168.5.0/24

Router D - 192.168.6.0/24

192.168.7.0/24

Also, I only have 2 routers that are not directly attached to the backbone. And I think putting those within there own area is a good idea. I have many subnet spread throughout this network, up to 30 full class "C"'s subnetted all over the place.

[Istvan_Rabai]

Hi Jesse,

Yes, it's a good idea to put those routers with up to 30 subnets within their own area.

Don't forget to summarize the address range on the area border router (the router connecting the backbone area 0 and this area) with the "area x range" command as I mentioned earlier.

If that area is not connected anywhere else just to the backbone, then you can also configure them as stub areas.

The good thing with stub areas is that the area border router (the router connecting the backbone area 0 with the stub area) injects a default route into the stub area.

So the routing tables within the stub area will be smaller.

This is just an idea from my side.

Your consideration is needed.

Cheers:

Istvan

[Jesse Hottle]

I didnt want to configure them as stub areas because soon we will have redundant paths to these locations as well, and I would just have to change it. Thanks for explaining the summarization, I a little iffy in it, but worth a test. If I sent you a config of one of my two connected routers, could you check it out?

thanks again,

j

[Istvan_Rabai]

Sure.