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’]