OSPF default route

[Brad_199]

Sites joined in ring
Ospf enabled

How do I enforce the default route in site b to point to site a?
How do I ensure that if link from site b to site a went down, ospf would change default route via site c?

[paulgear · Accepted solution]

Hi Brad_199,

There are multiple ways to do this, but the easiest in my opinion is to use different metrics for the default route injected from each location.  If sites A and C have default routes in their routing tables, then you should be inject them with a higher metric on C than A.  On Cisco gear you do this with 'default-information originate'; it appears that there's no direct equivalent on ProVision-based switches.  I'm sure it can be done with some redistribution tweaking, but i don't have a ProVision-based OSPF switch to test on at the moment.

[paulgear]

Hi Brad,

Drop the OSPF config of your switches (anonymised if you prefer) in an attachment and i'll see if i can make some guesses for you.

[Brad_199]

Hi paul,
 
here are configs.
 
to recap on main objective:
 

i want switch b's default route to be via switch a.
if switch b/site b/link to switch a were down i want ospf to change default route on switch b to route via switch c
additional question:
 
i don't understand how some of the metrics have been calculated and want to be able to look at the routing table and also the LSA outputs and determine how they tally up.
 
if i pick one example for you to explain:
 
 

how did switcha determine the route to 10.220.0.0/24 should have a metric of "2"? The LSA output for that network has a metric of 1
thanks
 

[paulgear]

Hi Brad_199,

Firstly, the default route:

Switch B is getting the same metric for the default route from both A & C.  (It would be easier to see this with the output of 'show ip ospf' and 'show ip ospf link-state', but don't bother re-doing them now.)  The routes that A & C are sending to B are external type 2, which don't get different metrics unless you explicitly set them.

So i suggest using 'default-metric N' on each switch to set the metric for redistributed routes.  Note that this will affect all redistributed routes, but since you don't seem to have any others that overlap, it won't likely be a problem.  I would use a large, round value to make it clear which switch the route is coming from, e.g. use 'default-metric 100' on switch A, 'default-metric 300' on switch B, 'default-metric 200' on switch C, etc., according to your order of routing preference.

(You could also use a different metric type for switch A & C, e.g. 'metric-type type1' on switch A and 'metric-type type2' on switch C, and OSPF would prefer metrics of type 1 to type 2, but this is not as scalable, since it wouldn't work if you introduced more switches.)

Regarding LSA metrics:

The switches keep an identical copy of the LSA database, then work out their cost to each link relative to their own position.  The analogy i've read is that it's like having a copy of the same map of your country, but starting from 3 different cities.  You might take 3 different routes to get to the same destination depending on which city you started from.

Your output didn't show 10.20.0.0/24 - i'll assume 10.19.1.0/24 instead.  It is connected on switch C, so it has a metric of 1.  The links between your switches (VLANs 40-42) also have a metric of 1, so switches A and B add the metric of their link to switch C to the metric of the route in the database, giving it a metric of 2 from those switches.

Hope that makes sense.

[Brad_199]

hi paulgear,

if switch B needed to prefer the default route from switch A, which switch would the lower default metric need to be configured?

as it's switch B importing the route, would it be set there (switch B) or would it need to be set on the switch where the route is coming from (switch A)?

[paulgear]

Hi Brad_199,

1. Lower metrics win, so set your preferred default route to 100, and your next preferred to 200 or something like that.
2. You have to set the default metric on the switch originating the route. So if you want A to be the default route for B, set the default metric on A.

[Brad_199]

Ok.

Is that default metric setting only ever used by ospf?
Its set to 10 now and that is the metric assigned to routes originating from that switch. Why does it not seem to add the metric for the link between switches too?

If the link is 1 I was expecting the metric to be 11

[paulgear]

Hi Brad_199,

By default the default route metric is type 2, which does not get internal costs added.  Change it to a type 1 route to get the kind of behaviour you're expecting.  (Be sure to change all switches to use metric-type 1, because OSPF will prefer them over type 2.)

[Brad_199]

in post apr 28, the link costs were added to the total when the routes were still external type 2?

In a default configuration of ospf, what routes exactly are imported into ospf?

[paulgear]

LSA metrics are only added on internal and type 1 external routes, not type 2 external routes (which is the default).  I don't know why it was designed this way originally, but it's always been that way; use type 1 if you want to take into account the internal path for external routes.

Your switches are 5400s, if i remember correctly - it's been a while since i've used OSPF on those, so i wouldn't like to lead you astray.  For default settings and things like that, it's best to check the multicast & routing guide for your switch model: http://www.hp.com/rnd/support/manuals/3500-6200-5400-ChapterFiles.htm

[Brad_199]

Thanks paulgear

What I am confused with is that it says there are many redistribution commands, all, connected, static and by default redistribution is disabled.

Two of my switches have redistribution static enabled but yet their connected routes are advertised into ospf.

Why is that? What have I missed?

[paulgear]

I'd say the most likely issue is that the interfaces are explicitly included with 'ip ospf area X' but it's going to be a lot easier to work out with configs and diagnostics.

This thread seems to have lost your configs; please post them again, along with the output of the following commands:

• show ip ospf
• show ip ospf general
• show ip ospf external-link-state
• show ip ospf link-state
• show ip ospf neighbor
• show ip ospf redistribute

Feel free to anonymise as long as you do it consistently (e.g. substitute 10.x for 172.x or whatever).

[Brad_199]

Hi paulgear,

I'm not necessarily thinking there is a problem, I am I just trying to understand how OSPF works and what I've inherited.

My specific question at this point is:

1. Two of the three switches advertise all of their routes (static & connected) although they only have 'redistribution static' enabled, how have the 'connected' routes been advertised? What is the purpose of the 'redistribution all' command when it doesn't appear to me to be necessary seeing as (or perhaps just in my case) the connected routes are injected into OSPF anyway

[paulgear]

The switches include their connected routes because they are explicitly configured to do so with 'ip ospf ... area backbone' in each VLAN.  This statement causes OSPF to include and advertise them.  This is normal and expected if you want to have a complete routing table.

Also, any VLANs which do not have other OSPF routers on them have 'ip ospf ... passive' configured, which means they don't send out OSPF advertisements.  This should be the default for any VLAN which is client-facing.

There doesn't seem to be a 'redistribution all' in your config anywhere.

[Brad_199]

thanks paulgear.

that makes perfect sense & from the multicasting and routing document it states that the configuration steps to enable OSPF include assigning interfaces or VLANs to the area BUT if the ip ospf X.X.X.X/VLAN area backbone command was used, what would be the purpose of the command 'redistributed connected/all'? 

My switches aren't using 'redistributed connected/all', I'm just trying to understand where those commands would be used as it seems they'll be redundant commands if the normal config steps are to assign interfaces or VLANs to an area

Also as a second question, from looking at one of the switches in the network (haven't checked the others at this point), some VLANS have been assigned to the backbone area but also have the passive command listed:

Example:

vlan 100
   ip ospf 192.168.100.254 passive
   ip ospf 192.168.100.254 area backbone

This VLAN is dynamically added to other switches in the OSPF area so this switch still must advertise the routes but aren't the two commands contradicting each other?  Is that normal to assign a VLAN to an area and then use the passive command on the same VLAN?

[paulgear]

Hi Brad_199,

If you put 'ip ospf ... area ...' statements on your VLAN definitions, it does two things: it includes the relevant subnets as internal routes in OSPF, and it enables OSPF neighbour relationships to form (except when 'ip ospf ... passive' is used - hence the reason for having that command on some VLANs but not others).

If you 'redistribute connected', then it has no effect on neighbour relationships, and it includes ALL connected routes as EXTERNAL routes (type 2 by default) in OSPF.

So in your config 'redistribute connected' is not required, and in general you don't want it because it gives you less control.

[Brad_199]

hi paulgear,

thanks for your info so far, it is helping me a lot to understand ospf more.

based on your knowledge and experience what is your opinion or even the best practises with regards to the number of areas used?

i have 5 devices over 3 sites participating in OSPF:

Should I be looking to keep the configuration simple and therefore use a single area?

Should I create an area for each site, connected to the backbone?

Are there any general rules that dictate the above?

Am I over thinking it?

any assistance/advice would be appreciated

[paulgear]

Hi Brad_199,

Rather than try to answer here, i think it would be best if you listen to this podcast:

http://packetpushers.net/show-134-ospf-design-part-1-debunking-the-multiple-area-myth/

Don't be fooled into thinking that because i'm on the podcast that i'm an expert.  I proposed the episode because i wanted to learn, and it worked - this show challenged a lot of my preconceptions, and caused me to change the way i implemented OSPF in my network.

[Brad_199]

That was an interesting discussion, thanks for forwarding it on.

I think having heard you guys discuss single areas including hundreds of routers, my little network shouldn't be a problem :)

I think I'll swing towards keeping it simple.

Thanks

[paulgear]

Some of the early Packet Pushers shows are worth going back and having a listen to, because they explore a lot of things like this in detail.

Keeping it simple is the right choice in your case.:-)

[Brad_199]

thanks I'll check them out.

is it me or is there no command to change the reference bandwidth??

5406 running K.15.06.008