ospf weird metric?

rossonieri#1

hi guys,

i'd just reviewed my ospf lab, and i do need some help here.

dear webmaster, i need your permission to upload a scenario image here - may i?



uups .. i'm sorry - its way too large i think.

so from the picture above, i've run RIP - all 3 routers doing fine, no missing network - but, the question is after i've configured OSPF - it has this weird metric that i couldnt understand why?


how come that 10.222.6.0/24 get this 20?
the rest of 2 routers doing great.
all 3 routers configured using standard export prot ospf and direct, and the neighbor are only directly connected interface on each router.

please ask me my guess from my question above - just a little bit clue would be just fine.

TIA.

zoidberg

The metric of 20 sounds right. Why don't you like it?

The default ospf cost for a ethernet link is 10. You're 2 ethernet hops away, so 20. The default for fast ethernet is 1. The calculation is based on a default reference bandwidth of 100mbps. 100mbps/100mbps = metric 1. 100mbps/10mbps = metric 10. This can be adjusted with the reference-bandwidth command under protocol ospf.

The other routes are being redistributed into the ospf domain, so different rules apply. There's E1 or type 1 routes, and E2 or type 2 routes. The default, and what it looks like you are using, is type 2 routes with no metric. Type 2 routes will cause all ospf routers to use the metric they are assigned when they are advertised into ospf as the total cost to get to the network. Type 1 metrics add the metric they are assigned when redistributed as well as the cost to reach the asbr that is advertising the network.

If you redistributed a route as an E1 with a metric of 100, it would show up as 120 on the other side of your network. If it was an E2 with a metric of 100, it would still show 100 on the other side.

In your redistribution policy, you can change the metric with the metric command, and the type using the external type command.

I hope that helps. My caffiene hasn't kicked in and a do have a feeling that I overlooked something here...

Turgon

Everything Zoidburg said makes sense to me.

rossonieri#1

hi zoidberg,

thanks for the answer

The metric of 20 sounds right. Why don't you like it?
The default ospf cost for a ethernet link is 10. You're 2 ethernet hops away, so 20.

ya - and that made me think its weird since the other network - like 5.0/24, 9.0/24 got their 0 metric - but its own friendly network like 6.0/24 gets 20?

i'm not injecting any RIP into OSPF yet, so this 150 local preference also makes me wondering
being intra network means that OSPF learned from itself right (directly connected)?
and those Ext2 from its neighbor?

please look at that 10.0/24 network which is the same hop from 6.0/24 - it gets 0 metric?


please do CMIIW

zoidberg

first off, no need to export ospf into ospf

i'll look at this some more in a few minutes

rossonieri#1

zoidberg,

first off, no need to export ospf into ospf

hahaha ... i like that kind of answer, sweet
let me give it a test drive first,
a cup of coffee seems nice indeed

[edit]

nope ... no go
still the same result.
6.0/24 still has the metric of 20 and 10 pref
the other still get metric of 0 and 150 pref

[/edit]

i'll go get some coffee too i guess

zoidberg

the 150 does mean it's external. i'm assuming on r3 you're doing the same export policy, which matches direct routes (10.222.5/24 and 10.222.9/24) and then exports them into ospf. you could just run ospf on those interfaces, you prolly want passive, and then you shouldn't need the policy to bring those networks into ospf.

intra will be learned from within the ospf area, not necessarily directly connected.
inter will be learned from within the ospf domain (other areas).

etx2 means external type 2. these will be learned from outside ospf using your policy, specifically your from protocol direct then accept.

if you're only looking to have the r1-r2-r3 and the interfaces connecting them all talking via ospf, and do not want the side networks in your ospf yet, then use something like this.

protocols {
ospf {
area 0.0.0.0 {
interface fxp1.0;
interface fxp0.0;
}
}

zoidberg

you may also want to include your loopbacks under the ospf process.

rossonieri#1

etx2 means external type 2. these will be learned from outside ospf using your policy, specifically your from protocol direct then accept.

ooo yes, i've forgot a little bit there, sorry
that is why the other get 150 pref ... my bad.
thank you, so the problem decrease to 1 : metric 20
ya - using loopback since i'd hardcoded the router-id.

[edit]
if i delete the export policy like you've told me,
then its very obvious that R1 cant see any network beyond R3 right?

zoidberg

just to clarify..... what is it you're still seeing as a problem?

rossonieri#1

that metric 20 is my biggest homework i think

btw, thank you for your help zoidberg - i appreciated

[edit]
on a second thought,
by deleting that ospf export policy - it means it just like a directly connected network but using the metric of 10.

so ... that metric 20 problem is gone accordingly - because it is, it has to be 20.


i've done my homework, i think

thank you for sharing zoidberg, turgon

zoidberg

but what is it that you don't like about the metric 20?

zoidberg

sorry, missed your edit....
yes, deleting the export policy will cause the networks past r3 to disappear. you can make them reappear using that policy, or by adding those interfaces to your ospf process, either passive or not. passive is likely the best choice.

if you use the policy, the networks will be external routes. if you add the interfaces to ospf, the routes will be internal, and then have a non-zero metric as well.

it all boils down to what you are trying to accomplish.

rossonieri#1

but what is it that you don't like about the metric 20?

like i said on my first post,
thats kind of weird : the 10.0/24 gets metric 0, but the 6.0/24 gets 20?
and the rest get 150 pref? <-- this is my bad, i've forgot already

but, you've clear my mind by offer me to delete that export policy,
thank you

zoidberg

the 10.222.10/24 is getting a 0 metric because you're redistributing into ospf as an external type 2 with no metric defined, with your from protocol direct then accept.

10.222.6/24 is internal to ospf, and the metric 20 is the default ospf metric to reach that network.

this is nothing strange, it's the way ospf works and the way you set things up. as i already mentioned, there's a number of ways to change this behavior. if it's really bugging you that half your routes show metric 0 and the other half show a real ospf metric, make 1 of 2 changes.

1) stop redistributing. add the interfaces running to those network to your ospf process with a passive statement. the networks will then be advertised as internal routes with actual metrics.

2) continue redistributing, but change to type 1 routes. this will cause the external networks to be advertised with a metric reflecting the ospf metric to actualy reach them and not a constant 0. from protocol direct then external type 1 accept.

rossonieri#1

hi zoidberg,

i try to change my scenario now - 3 routers seems difficult to see how that export policy affect the routing info. i've expanded to 4 routers, delete any RIP, and using 2 kind of testing :



scenario1, the blue arrow
will be no export policy, and only using a basic interface command. the goal is to check whether all those routers covers all the networks, and their respective preference/metric.

scenario2, the green arrow
will use some route policy, and only advertise on directly connected interface to see whether 6.0/24 and 9.0/24 will still having a 20 and 30 or perhaps bigger metric from R1 point of view.

i'll let you know the result later

rossonieri#1

done scenario1, the blue arrow

the config :
delete protocol rip

set routing-option router-id <lo0.0_IP> -> on each router
set protocol ospf area 0 interface lo0.0 -> since i hardcoded the router-id on each router.
set protocol ospf area 0 interface N -> for any neighbor-connected interface on each router,
set protocol ospf area 0 interface N passive -> for any no-neighbor interface on each router

there are no policy involved - pure interface.

the results :
sh route protocol ospf
sh ospf route -> stated path = intra -> all routers in area 0, and no redistributed routes
sh ospf interface
sh ospf neighbor

as i have expected (and mostly, zoidberg expected) - all routers see all networks - including the loopback interface on each router, all 4 routers having normal OSPF preference of 10 to each network, and the metric is normal 10 for directly ethernet connected, multiplied by hop traversed.

from R1 to
10.222.6.0/24 metric 20
10.222.9.0/24 metric 30
10.222.11.0/24 metric 40

temporary conclusion :
the result actually is my normal daily expectation for any configured OSPF networks,
before i've begin to use export policy.

so later, wait for the 2nd scenario

zoidberg

good work!

the reason export policies affecting routing info is because it's external vs. internal routes.

have fun with scenario 2. if i understand what you're doing, and if you use the export policy i think you'll use... here's my predictions :P

from R1 to
10.222.6.0/24 metric 20
10.222.9.0/24 metric 30
10.222.11.0/24 metric 0

rossonieri#1

hi zoidberg,

have fun with scenario 2. if i understand what you're doing, and if you use the export policy i think you'll use... here's my predictions :P

from R1 to
10.222.6.0/24 metric 20
10.222.9.0/24 metric 30
10.222.11.0/24 metric 0

thanks for the prompt output!
absolutely, exactly what you've predicted.

explanation from scenario 2, using export policy from protocol direct only with no modification.

the config :
delete protocol ospf; commit; -> disable and delete all previous ospf config, start from scartch.

set the export policy :
policy-option policy-statement export-ospf;
set from protocol direct; set then accept;

include the export policy to ospf :
set protocol ospf export export-ospf; commit;

enable ospf on neighbor-connected interface :
set protocol ospf area 0 interface N; commit;

ok - there are external type 2 path type and intra,
being external type 2 is the result of redistributing direct protocol (or external protocol) to the ospf which triggers the 150 preference value instead of normal 10. since this is a type 2 - like zoidberg said, the metric real metric wasnt included in the routing table = 0.

being intra - is the normal directly attached interface to any neighbor (or not in the form of redistributed route) hence the normal metric value is 10 multiplied by hops traversed.

the question :
if that ospf was only enabled on neighbor-connected interface, then how come the loopback address stated as intra? eventhough its preference value is 150 and the metric is 0?

ok, let me answer this on my lab,
and i shall now moved to my scenario2-b :
create export policy which include interface protocol only.

temporary conclusion :
later on ... wait for my scenario 2 b

zoidberg

How are the scenarios going? Figure everything out yet?

Those Intra routes you mention are created because your routers are acting as AS Border Routers thru the act of redistribution. This causes the ASBRs to inject a Type 4 LSA (ASBR Summary LSA) advertising it's router-id so other routers know how to reach the ASBR listed in your redistributed routes sent via Type 5 External LSAs. These Type 4 LSA routes are not the same as your externals and OSPF will count a metric to them, and you see that with the values of 10, 20, 30.

If you look further down your output, your actual loopback advertisement via redistribution is the /32 routes showing up as External Type 2 (not LSA), and as discussed these routes will have metric of 0 when you check out the routing-table because of the Type 2 (Not LSA). For fun, you should really try setting routes as external type 1 just to see the difference.

The Type 1 & 2 I talk about is the type of external route and not OSPF LSA types. Just wanted to clarify as reading those 2 paragraphs back-to-back could be confusing to some.

rossonieri#1

hi zoidberg,

it was a lot of fun studying i've forgot to post the result here, instead i've just moved on bit-matching FW filter on that JNCIS-ER slides, sorry my bad

ok, scenario 2b.
create OSPF neighbor for directly-connected interface,
redistributing protocol direct to OSPF using export policy & modify its LSA type to external type 1 instead of normal 2

the config :
set policy-opt policy-state export-direct from prot direct;then extern type 1;then accept;
set prot ospf export export-direct;
set prot ospf area 0 interf N;
commit conf 30;

the result (i've change the map back to our previous 3 routers) :
all routers has adjacent, and the wonderful thing are these 3 :
all neighbor advertised route are having this 150 preference value,
stated as external type 1 - compares to previous scenario 2a = ext2,
and using their normal 10*hop metric - compares to the previous scenario 2a output = 0.

ok - now, i'll discuss what zoidberg has explained on the previous post above :

Those Intra routes you mention are created because your routers are acting as AS Border Routers thru the act of redistribution. This causes the ASBRs to inject a Type 4 LSA (ASBR Summary LSA) advertising it's router-id so other routers know how to reach the ASBR listed in your redistributed routes sent via Type 5 External LSAs. These Type 4 LSA routes are not the same as your externals and OSPF will count a metric to them, and you see that with the values of 10, 20, 30.

If you look further down your output, your actual loopback advertisement via redistribution is the /32 routes showing up as External Type 2 (not LSA), and as discussed these routes will have metric of 0 when you check out the routing-table because of the Type 2 (Not LSA). For fun, you should really try setting routes as external type 1 just to see the difference.

this explanation is what i was looking for, and is a great input zoidberg, thank you

The Type 1 & 2 I talk about is the type of external route and not OSPF LSA types. Just wanted to clarify as reading those 2 paragraphs back-to-back could be confusing to some.

thank you for the clarification support,
and my output above - should give some of us a picture.

its true, that routing is way much harder than
now, continue to Firewall family inet filter.