cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7975
Views
24
Helpful
16
Replies

Which interface is added by OSPF cost?

r-kitagawa
Level 1
Level 1

Hi Sir,

I ask question of OSPF cost.

I want to know when add OSPF cost of interface.

When I configure 'ip ospf cost' on router's interface,

is OSPF cost added by incoming interface or outgoing interface?

Ryusuke.

1 Accepted Solution

Accepted Solutions

Hi Rick,

The OSPF cost is the outgoing cost for packets transmitted from this interface (used when executing the SPF tree by adding it to the cost of relevant path to the destination), do you mean with your statement that it is added to the cost of the incoming interface to calculate the whole path cost.

BR,

Mohammed Mahmoud.

View solution in original post

16 Replies 16

Richard Burts
Hall of Fame
Hall of Fame

Ryusuke

The cost is added on the incoming interface.

HTH

Rick

HTH

Rick

Rick

Your answer is best.

Thank you.

Ryusuke

Hi Rick,

The OSPF cost is the outgoing cost for packets transmitted from this interface (used when executing the SPF tree by adding it to the cost of relevant path to the destination), do you mean with your statement that it is added to the cost of the incoming interface to calculate the whole path cost.

BR,

Mohammed Mahmoud.

Why is it that the cost is added at the outgoing interface in routing and ingress interface in switches.. Is there any logic or any theory behind this ?

You mean the incoming interface on which we learn the route or what. 

 

R1-a-----b-R2-c-------d-R3-e--------f-R4-g-----PC1

 

When R1 learns the prefix of PC1 via ospf while learning the cost is used right so R4s f and R3's d and R2' b cost is used. am i right. 

Please do not hesitate to click the STAR button if you are satisfied with my answer.

"am i right."

No, cost to PC1, at R1 would be a + c + e + g.

JORGE RODRIGUEZ
Level 10
Level 10

Hi Ryusuke,

Why would you want to override the ospf cost on an interface? By default OSPF automatically calculates its matrics on interfaces participating in OSPF

based on the formula 100 Mbps devided by the interface total bandwidth.. a 64k link gets a metric of 1562, another example is a T1 1.544 gets a metric of 64 , 100 Megs link gets a metric of 1 and so on, the higher the bandwidth the lowest its cost and therefore prefered path and that matrics gets propagated through the OSPF domain . It is posible with the command you indicated to manipulate/override the default calculation on an interface, I have yet not seen a scenario where you would need to override the default behavior.

In the event you do need to change this

I would pay close attention which interfaces

participating in OSPF you need to change it,

remember that by chnaging the value to lower or higer it would inpact OSPF traffic desitions in chosing optimal path.

OSPF reference

http://www.cisco.com/en/US/tech/tk365/tk480/tsd_technology_support_sub-protocol_home.html

Q&A

http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a0080094704.shtml

HTH, please rate if this helps

Jorge

Jorge Rodriguez

Hi Jorge

Thank you.

I configure it carefully.

This scenario is route control on same bandwidth interface.

Because,

there is different reliability network of same bandwidth in Japan.

My customer's policy don't use low reliability network for normal use.

Low reliability network is used for redundancy.(for backup route)

Ryusuke

(a very belated response . . .)

"By default OSPF automatically calculates its matrics on interfaces participating in OSPF based on the formula 100 Mbps devided by the interface total bandwidth.."

Actually that's a feature of Cisco. Other vendors don't or use a different base value. (Also BTW, don't believe the inversion of bandwidth is suggest by the RFC.)

It can illustrate like this:

1.jpg

The Routing table on R1 will see the route from R3 + Cost 100, right?

 

Thank you very much.

No, R1 will see the cost as what's R1's interface to R2(?) plus R2's interface to R3 (100).

Yes, if you are looking at the direction of the route update (incoming interfaces) or as RFC 2328 states, "a cost is associated with the output side of each router interface"

 

e.g.

The route update from R3 would add the advertised cost from R3 + R2 (incoming interface cost) + R1 (incoming interface cost)

or

R1 would have the cost of its R1 (output interface cost) + R2 (output interface cost) + R3 (output interface cost)

"The route update from R3 would add the advertised cost from R3 + R2 (incoming interface cost) + R1 (incoming interface cost)"

Correct, although by "incoming", to clarify, I believe you mean the source of the route update. The cost would be the for egress on the same interface.

"R1 would have the cost of its R1 (output interface cost) + R2 (output interface cost) + R3 (output interface cost)"

That would only be correct if the route of interest was directly connected to R3. I.e. there could be many downstream OSPF link costs, to the destination network, from R3. So, whatever the cost that R3 provides, at R1, it would also include the link costs of R1 => R2 and R2 => R3.

Well, I guess we are telling the same thing, however lets try to visualize a bit to clear off the inbound / outbound interface part.

 

snip.jpg

 

R11- 1.1.1.1

R13 - 3.3.3.3

 

With default Costs :-

 

R11#sh ip rou 3.3.3.3
Routing entry for 3.3.3.3/32
Known via "ospf 1", distance 110, metric 3, type intra area
Last update from 10.1.1.1 on GigabitEthernet0/0, 00:03:15 ago
Routing Descriptor Blocks:
* 10.1.1.1, from 10.1.1.2, 00:03:15 ago, via GigabitEthernet0/0
Route metric is 3, traffic share count is 1

 

Why metric 3 ? 1 for each Gig interface and 1 for the loopback,

i.e. the route update from R13 has Cost of loopback + Cost of R12 Gig 0/1 + Cost of R11 Gig 0/0 (look at the direction of the LSA)

or

look at the direction of the path computation from the perspective of R11 to 3.3.3.3/32. It has to reach out via R11 Gig 0/0 + R12 Gig 0/1 and R13 lo1.

 

Let's look at R13 also

 

R13#sh ip rou 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "ospf 1", distance 110, metric 3, type intra area
Last update from 10.1.1.2 on GigabitEthernet0/0, 00:03:58 ago
Routing Descriptor Blocks:
* 10.1.1.2, from 1.1.1.1, 00:03:58 ago, via GigabitEthernet0/0
Route metric is 3, traffic share count is 1

 

Same logic in the reverse way.


Next, adding Cost 8 to Gi0/1 on R12 only

 

The same route update / lsa for 3.3.3.3/32 on it's way accumulated the cost of 8 from R13 to R11 (look at the direction of the udpate or computation as above)


R11#sh ip rou 3.3.3.3
Routing entry for 3.3.3.3/32
Known via "ospf 1", distance 110, metric 10, type intra area
Last update from 10.1.1.1 on GigabitEthernet0/0, 00:01:30 ago
Routing Descriptor Blocks:
* 10.1.1.1, from 10.1.1.2, 00:01:30 ago, via GigabitEthernet0/0
Route metric is 10, traffic share count is 1

 

The most important output, let's check whether the cost made any difference on R13

The update from R11 (1.1.1.1/32) crosses the interface of R12 Gig 0/1 to reach R13 so there could be a doubt ;)


R13#sh ip rou 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "ospf 1", distance 110, metric 3, type intra area
Last update from 10.1.1.2 on GigabitEthernet0/0, 00:06:39 ago
Routing Descriptor Blocks:
* 10.1.1.2, from 1.1.1.1, 00:06:39 ago, via GigabitEthernet0/0
Route metric is 3, traffic share count is 1

 

No change, it's the same ! Why? Look at the direction, is it ingress/inbound or egress/outbound ? It's always good to leave some thought to the readers.

 

Computation in link state algorithm is like perspective taking.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: