ospf weird metric?

rossonieri#1rossonieri#1 Member Posts: 800
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?

lab1-b.png

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.
the More I know, that is more and More I dont know.

Comments

  • zoidbergzoidberg Member Posts: 365 ■■■■□□□□□□
    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...
  • TurgonTurgon Banned Posts: 6,313 ■■■■■■■■■□
    Everything Zoidburg said makes sense to me.
  • rossonieri#1rossonieri#1 Member Posts: 800
    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 :)
    the More I know, that is more and More I dont know.
  • zoidbergzoidberg Member Posts: 365 ■■■■□□□□□□
    first off, no need to export ospf into ospf :)

    i'll look at this some more in a few minutes
  • rossonieri#1rossonieri#1 Member Posts: 800
    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 :D
    the More I know, that is more and More I dont know.
  • zoidbergzoidberg Member Posts: 365 ■■■■□□□□□□
    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;
    }
    }
  • zoidbergzoidberg Member Posts: 365 ■■■■□□□□□□
    you may also want to include your loopbacks under the ospf process.
  • rossonieri#1rossonieri#1 Member Posts: 800
    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?
    the More I know, that is more and More I dont know.
  • zoidbergzoidberg Member Posts: 365 ■■■■□□□□□□
    just to clarify..... what is it you're still seeing as a problem?
  • rossonieri#1rossonieri#1 Member Posts: 800
    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 :)
    the More I know, that is more and More I dont know.
  • zoidbergzoidberg Member Posts: 365 ■■■■□□□□□□
    but what is it that you don't like about the metric 20?
  • zoidbergzoidberg Member Posts: 365 ■■■■□□□□□□
    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#1rossonieri#1 Member Posts: 800
    :)
    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 :)
    the More I know, that is more and More I dont know.
  • zoidbergzoidberg Member Posts: 365 ■■■■□□□□□□
    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#1rossonieri#1 Member Posts: 800
    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 :

    lab1-c.png

    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 :)
    the More I know, that is more and More I dont know.
  • rossonieri#1rossonieri#1 Member Posts: 800
    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 :)
    the More I know, that is more and More I dont know.
  • zoidbergzoidberg Member Posts: 365 ■■■■□□□□□□
    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#1rossonieri#1 Member Posts: 800
    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 :)
    the More I know, that is more and More I dont know.
  • zoidbergzoidberg Member Posts: 365 ■■■■□□□□□□
    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#1rossonieri#1 Member Posts: 800
    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.
    the More I know, that is more and More I dont know.
Sign In or Register to comment.