OSPF Cost Not Showing in Local Database

[j.a.m.e.s]

Dear All,

I thought that applying an OSPF cost on an interface would increase the cost of the routes learned via that interface? I have a router and a switch directly connected, both of which are in area 0. The router is an ASBR since it originates a default, but the cost (as applied on the switch interface) is not showing up in the database:

SWITCH#sho ip ospf database external adv-router 10.0.0.1
            OSPF Router with ID (10.0.0.2) (Process ID 1)
             Type-5 AS External Link States
  Routing Bit Set on this LSA
  LS age: 250
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 0.0.0.0 (External Network Number )
  Advertising Router: 10.0.0.1
  LS Seq Number: 80000023
  Checksum: 0x4DAB
  Length: 36
  Network Mask: /0
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 1  <-- Why isn't the metric 600 ?
        Forward Address: 0.0.0.0
        External Route Tag: 1

Here is the SWITCH interface leading to the ASBR router:

SWITCH#sho run inter gi1/48
interface GigabitEthernet1/48
 description ROUTER Gi0/1
 no switchport
 ip address 10.0.0.2 255.255.255.252
 ip pim sparse-mode
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 0 xxxxx
 ip ospf network point-to-point ip ospf cost 600 <- metric has been set to 600
 ip ospf hello-interval 1
 load-interval 30
 qos trust dscp
 tx-queue 3
   priority high
end

And here is the config on the ROUTER:

ROUTER#sho run | sec r o
router ospf 1
 router-id 10.0.0.1
 auto-cost reference-bandwidth 100000
 area 0 authentication message-digest
 timers throttle spf 10 100 5000
 timers throttle lsa 10 100 5000
 timers lsa arrival 80
 passive-interface default
 no passive-interface GigabitEthernet0/0
 no passive-interface GigabitEthernet0/1
 network 0.0.0.0 255.255.255.255 area 0
 default-information originate
end

Could anyone explain why the metric hasn't increased to 600 ?

Regards

James.

[Joseph W. Doherty]

It's because it's an external route, as you highlight a type 5. (BTW, OSPF supports two types of externals, one type with, and the other without, internal link costs.)

Understanding OSPF External Route Path Selection

[j.a.m.e.s]

So if this were a type 1 external default, would the interface cost have been applied?

[Georg Pauwen · Accepted solution]

Hello,

I just tested this, I am not sure if this is specific to the default route being originated, but it doesn't seem to matter which metric type you specify, the metric doesn't change:

default-information originate

-->  Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 1

default-information originate metric-type 1

Result:

-->  Metric Type: 1 (Comparable directly to link state metric)
MTID: 0
Metric: 1

The only way to get the metric changed is to actually specify it explicitly, and it doesn't seem to matter which metric type you use:

default-information originate metric-type 1 metric 600

Result:

-->  Metric Type: 1 (Comparable directly to link state metric)
MTID: 0
Metric: 600

default-information originate metric-type 2 metric 600

Result:

-->  Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 600

[j.a.m.e.s]

Thank you very much for doing this test.

[Joseph W. Doherty]

I would expect the E1 to accumulate link path cost(s), but that's also presuming you're crossing the link using OSPF. In this case, the default is being originated on this router, correct?

[j.a.m.e.s]

Hi Joseph,

Yes, the ospf default is originated by the router itself (in my case, there was an upstream BGP route for 0.0.0.0). It appears from the testing that an OSPF default is something of a special case and setting "type 1" alone is insufficient.

Regards

James.

[Joseph W. Doherty]

Right, but if you go to routers downstream of this one, I would expect an E1 to accumulate the OSPF link costs, on the default route, in addition to its fixed cost.