OSPF – how max-metric works
When you configure an OSPF interface with a cost, you can do it directly using ip ospf cost or have the cost calculated for you using auto-cost reference bandwidth. Whichever method you choose, the OSPF RFC 2328 calls it “the cost of sending a packet out this interface”. The Router LSA, or type-1 LSA, has a 16-bit field (65535 in decimal) to represent the “interface output cost”. An interface cost of 65535 is also known as “LSInfinity”.
We’ll go through an example using links between routers which have been configured with OSPF network type point-to-point. The links have IP addresses and active adjacencies, so are represented by in the router LSA by both Stub and P2P links.
Router_A#sh ip ospf interface fa1/0 FastEthernet1/0 is up, line protocol is up Internet Address 192.168.12.1/24, Area 0 Process ID 100, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 10
Router_A#sh ip ospf database router self-originate OSPF Router with ID (1.1.1.1) (Process ID 100) Router Link States (Area 0) LS age: 139 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 1.1.1.1 Advertising Router: 1.1.1.1 LS Seq Number: 80000006 Checksum: 0xCBB0 Length: 84 Number of Links: 3 Link connected to: a Stub Network (Link ID) Network/subnet number: 1.1.1.1 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metrics: 1 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 2.2.2.2 (Link Data) Router Interface address: 192.168.12.1 Number of TOS metrics: 0 TOS 0 Metrics: 10 <--# cost for P2P A_B link Link connected to: a Stub Network (Link ID) Network/subnet number: 192.16.12.0 (Link Data) Network Mask: 255.255.255.0 Number of TOS metrics: 0 TOS 0 Metrics: 10 <--# cost for Stub A_B link
Both the stub and P2P links have a cost specified in the router LSA for the A_B link, and they both reflect the configured “interface output cost”. I guess that makes sense, but which one is used in the the best-path calculations?
Which link metric is used?
If both stub and P2P links have the same cost, why do we care which one is used in the path calculations? One reason that advanced OSPF features like “stub router” exploit the subtle differences between these costs.
I’ve repeated the format from my previous post on P2P links in the ‘three-in-a-row’ example network below. I’ve broken out links to show them as they are represented in the OSPF router LSA.
Let’s look at the cost for router_A to reach router_B’s loopback at address 2.2.2.2. On router A’s interface to router B, the output interface cost used on the A_B link is cost from the point-to-point link (cost = 10). At router_B the output interface cost on the loopback interface is from the stub network link (cost = 1). So the calculation is pretty straight forward with a total path cost of 10 + 1=11 from router_A to router_B’s loopback at address 2.2.2.2.
Router_A#sh ip route 2.2.2.2 Routing entry for 2.2.2.2/32 Known via "ospf 100", distance 110, metric 11, type intra area Last update from 192.16.12.2 on FastEthernet1/0, 00:13:45 ago Routing Descriptor Blocks: * 192.16.12.2, from 2.2.2.2, 00:13:45 ago, via FastEthernet1/0 Route metric is 11, traffic share count is 1
What if we wanted to reach router_B’s interface on the B_C link, at address 192.168.23.1. Once again, the output interface cost used on the A_B link is cost from the point-to-point link (cost = 10). As the B_C link is our destination, we use the cost of router_B’s stub network link on the B_C link (cost = 10). Thus, the total path cost of 10 + 10 = 20 from router_A to router_B’s interface on the B_C link at address 192.168.23.1
Router_A#sh ip route 192.168.23.1 Routing entry for 192.168.23.0/24 Known via "ospf 100", distance 110, metric 20, type intra area Last update from 192.168.12.2 on FastEthernet1/0, 00:03:52 ago Routing Descriptor Blocks: * 192.168.12.2, from 2.2.2.2, 00:03:52 ago, via FastEthernet1/0 Route metric is 20, traffic share count is 1
I really want to drive home the fact that the stub link cost is only considered when calculating the path cost for the subnet assigned to that link.
Adding a second path
Let’s amend our diagram slightly and introduce a new link from router A to router C.
I’ve set a cost of 100 on this A_C link to artificially force traffic over the A_B_C path under steady state conditions. If router_A was to ping router_C’s loopback at 3.3.3.3, there is a path cost of 21 via A_B_C, or a cost of 101 via A_C
Router_A#sh ip route 3.3.3.3 Routing entry for 3.3.3.3/32 Known via "ospf 100", distance 110, metric 21, type intra area Last update from 192.168.12.2 on FastEthernet1/0, 00:13:12 ago Routing Descriptor Blocks: * 192.168.12.2, from 3.3.3.3, 00:13:12 ago, via FastEthernet1/0 Route metric is 21, traffic share count is 1
Max-metric & LSInfinity
But what if we want to take router B out of service and shift traffic gracefully back to the A_C link. RFC 3137 introduces the ‘Stub Router’ feature that allows you to set the transit interfaces to their maximum link cost (or LSInfinity). Setting high costs on a router’s non-stub links, makes paths via that router look pretty crappy, thus shifting transit traffic away from that router.
IOS implements the ‘Stub router’ feature using the ‘max-metric command. Let’s start our traffic shift by configuring “max-metric router-lsa” under the ospf process 100 on router_B.
Router_B(config)#router ospf 100 Router_B(config-router)#max-metric router-lsa
The OSPF process on router_B immediately sets the P2P link cost to LSInfinity and floods a new router LSA with this information.
Looking at router_B’s new LSA we see that the A_B and B_C links have been set to LSInfinity (65535) by the ‘max-metric; command. Also note that the associated stub links on router_B have not been changed.
Router_A#sh ip ospf database router adv-router 2.2.2.2 OSPF Router with ID (1.1.1.1) (Process ID 100) Router Link States (Area 0) LS age: 264 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 2.2.2.2 Advertising Router: 2.2.2.2 LS Seq Number: 80000007 Checksum: 0x2A99 Length: 84 Number of Links: 5 Link connected to: a Stub Network (Link ID) Network/subnet number: 2.2.2.2 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metrics: 1 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 3.3.3.3 (Link Data) Router Interface address: 192.168.23.2 Number of TOS metrics: 0 TOS 0 Metrics: 65535 Link connected to: a Stub Network (Link ID) Network/subnet number: 192.168.23.0 (Link Data) Network Mask: 255.255.255.0 Number of TOS metrics: 0 TOS 0 Metrics: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 1.1.1.1 (Link Data) Router Interface address: 192.168.12.2 Number of TOS metrics: 0 TOS 0 Metrics: 65535 Link connected to: a Stub Network (Link ID) Network/subnet number: 192.168.12.0 (Link Data) Network Mask: 255.255.255.0 Number of TOS metrics: 0 TOS 0 Metrics: 10
Also note that the cost from router_A to router_B’s B_C link is unchanged, because router_B didn’t change the cost for it’s stub network on the B_C link.
Router_A#sh ip route 192.168.23.2
Routing entry for 192.168.23.0/24
Known via "ospf 100", distance 110, metric 20, type intra area
Last update from 192.168.12.2 on FastEthernet1/0, 00:25:12 ago
Routing Descriptor Blocks:
* 192.168.12.2, from 2.2.2.2, 00:25:12 ago, via FastEthernet1/0
Route metric is 20, traffic share count is 1
But what about our path from router_A to router_C’s loopback. Well, it looks like we’ve found a better path, and traffic to 3.3.3.3 will now follow our A_C link using the path cost of 101.
Router_A#sh ip route 3.3.3.3
Routing entry for 3.3.3.3/32
Known via "ospf 100", distance 110, metric 101, type intra area
Last update from 192.168.13.3 on FastEthernet1/1, 00:09:06 ago
Routing Descriptor Blocks:
* 192.168.13.3, from 3.3.3.3, 00:09:06 ago, via FastEthernet1/1
Route metric is 101, traffic share count is 1
De-preferenced but still available
Setting link-costs to LSinfinity doesn’t make paths via those links invalid in OSPF terms, it just makes it less preferable. Let’s fail the A_C link and look at how OSPF responds.
Router_A#sh ip route 3.3.3.3
Routing entry for 3.3.3.3/32
Known via "ospf 100", distance 110, metric 65546, type intra area
Last update from 192.168.12.2 on FastEthernet1/0, 00:00:03 ago
Routing Descriptor Blocks:
* 192.168.12.2, from 3.3.3.3, 00:00:03 ago, via FastEthernet1/0
Route metric is 65546, traffic share count is 1
We’ve fallen back to the A_B_C path, but traffic will still flow. The total cost is little ugly thanks to the stub-router feature still costing all it’s P2P links at 65535.
Total path cost is 10 (router_A interface to RouterB) + 65535 (router_B LSinfinity interface to router_C) + 1 (router_C loopback cost) = 65546.
Wrap-up
Hopefully you’ve gotten a better understanding of LSinfinity and the OSPF “stub router feature”. Let me know in the comments if I can clarify anything or answer any questions you have on the “stub router/max-metric” feature.
If you’re in junos land, you’ll know this as the ‘overload’ feature, but the behavior is identical. I’ll run another post at a later date describing the additional (but non-RFC mandated) max-metric options that IOS and NXOS support.
[amazon_link asins=’0201634724,B008K9ADRI,1587144239,0596002750,B00RN14G7W’ template=’ProductCarousel’ store=’seamlnetwo-20′ marketplace=’US’ link_id=’c3a556d7-f3f1-11e7-aa67-1d78eab3d1da’]
6 thoughts on “OSPF – how max-metric works”
John,
This blog is simply superb. You are a gifted teacher–your explanations are very clear, easily understood, and your graphics are beautiful. Thank you so much for taking the time to do this–this is very helpful in my learning.
One issue is still confusing to me and it revolves around routing to an ingress interface as opposed to an egress interface When I think of the cost of a link, it seems to be a measure of the cost to get to the connected router at the other end of that link. That is, it is an “exit” cost for that interface.
In your example, before you added the A-to-C link, there was not a separate link connection from RouterA to RouterB’s B-to-C interface. Yet that interface’s IP address on Router B is accessible via Router A because that interface is included in the routing table. This seems reasonable to me because Router B obviously knows about it own interfaces. But from RouterA’s perspective, the cost to that interface on RouterB should be the same as the cost to get to RouterB using the A-B link because both of those interfaces are internal interfaces of RouterB.
In other words, if the link cost is indeed an “exit” interface cost, why is it included in a cost calculation when that interface on RouterB (B-to-C link) is not being used for exiting or is even in the transit path?
Obviously my reasoning is wrong so my thinking of a link cost as an interface’s “exit” cost must be incomplete. Any future blogs relating to routing/costs to egress vs. ingress interfaces would surely help me in my OSPF understanding.
Again, thanks for this blog–I am finding them very helpful.
-Andres
Hi Andres,
I think I have understood your question. I always like to be able to explain why something is the way it is. In this case the best I can do is help understand how it works.
I can see that it’s confusing that RTR_A cost to the B interface on the B_C link is the same as the cost to the C interface on the B_C link. However that is the behaviour of the protocol to the best of my understanding.
There are two ways of thinking about a link; either as transit link or as a target. From a transit perspective it’s doesn’t really matter to a remote router that the local and remote ends of the link have the same cost. That link cost is just a component of the overall cost to reach a remote prefix.
For the target case, I totally agree that it’s odd to think that remote routers see RTR_B’s local interface with the same cost as the remote end of the B_C interface. One way I make sense of this is to think of the both the local and remote IP addresses as targets which are reachable out that interface. In that way the ‘exit cost’ model still applies. Or think of the link as having zero-length.
Loopbacks also have a local cost which is reflected to remote routers. It’s true that they’re not providing transit, but there is still an ‘interface output cost of 1’ on Router C to reach it’s loopback.
Thank you for the kind comments and the thought provoking question. Let me know if I didn’t address your question.
Very well written article, thanks for the explanation. So, if I understand the above answered question correctly, you intend to say that if anyone wants to reach from A towards interface on Router-B (facing A) and interface on router-B (facing C), the interface cost will be same (meaning that only cost mattering in this case would be 10 (on 192.168.12.1/24 address located on Router_A).
Also, I think the basic intend of the article is that cost of any networks reachable via the router will be maxed out (unless they are stub networks, i.e, loopback or directly connected interfaces). Please correct me if I misunderstand your point here.
Thanks
Nage
Hi Nage,
Yes the basic intent was to say that the cost of paths that transit the router will be maxed out, but also to say how this was achieved. I was attempting to point out that it was ony the P2P links that received the higher metrics, and that they were only considered when transiting. When trying to reach a locally connected network or loopback, the stub cost which is unchanged is used for the final component of the path cost in OSPF.
Apologies if I answered Andres question in a confusing way, but I don’t agree with assesement. The confusing part (to me at least) is the fact that From routerA both the A end of the A-B link and B end of that link have the same cost from an OSPF perspective. The TL’DR on this is that although it’s a bit confusing it doesn’t really matter, and I wouldn’t spend too much time digging into it, as it will likely hinder your learning. (same could probably be said for this whole post).
From routerA, the cost of reaching the A or B end of the AB link is the same, 10. From routerA, the cost of reaching the A or B end of the BC link is the same, 20 (10+10) Even when B is max metric’d that path cost is unchanged because OSPF looks at the BC link as 10 (Stub cost – because the Stub is the target), rather than the now elevated P2P cost of 65535.
/John
Yeah it can be pretty confusing at first but the key it to remember that cost only comes into play outbound. Therefore, for a destination on the B_C link that is not router C (on a multi access link a type 2 network LSA would let router A know the answer to that question), the stub network cost is used along with the point-to-point cost on the A_B link.
Now if the destination is router C’s loopback, the outbound point-to-point link cost (or transit cost to router C) is 65535.
I think most of the confusion comes from people thinking that router B’s A_B cost somehow affects what router A sees but router A only cares about its own point-to-point cost for the A_B link which is 10.