I'm a little confused about the output I'm seeing in my routing table, particularly the 'metric' column:
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 wlan0
172.16.35.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet1
192.168.0.0 0.0.0.0 255.255.255.0 U 9 0 0 wlan0
192.168.82.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet8According to the man page, metric indicates the 'distance' to the target. I was a little confused about what exactly "target" was. I assumed it was my router (it goes to gateway 0.0.0.0, which then goes to my router at 192.168.0.1). Thus, I expected the metric to be a single hop to my router. However, it's 9! Why is this so number high?
22 Answers
According to the man page, metric indicates the 'distance' to the target.
I expected the metric to be a single hop to my router. However, it's 9! Why is this so number high?
The metric field has a number of different meanings:
The Metric field indicates the cost of a route. If multiple routes exist to a given destination network ID, the metric is used to decide which route is to be taken. The route with the lowest metric is the preferred route. Some routing algorithms only store a single route to any Network ID in the routing table even when multiple routes exist. In this case, the metric is used by the router to decide which route to store in the routing table.
Metrics can indicate different ways of expressing a route preference:
Hop Count.
A common metric. Indicates the number of routers (hops) in the path to the network ID.
Delay.
A measure of time that is required for the packet to reach the network ID. Delay is used to indicate the speed of the path—local area networks (LAN) links have a low delay, wide area network (WAN) links have a high delay—or a congested condition of a path.
Throughput.
The effective amount of data that can be sent along the path per second. Throughput is not necessarily a reflection of the bit rate of the link, as a very busy Ethernet link may have a lower throughput than an unutilized 64-Kbps WAN link.
Reliability.
A measure of the path constancy. Some types of links are more prone to link failures than others. For example, with WAN links, leased lines are more reliable than dial-up lines.
Source Routing Tables
6I'm going to comment on this because the existing answer is technically correct in a descriptive sense but misses key concrete details and values useful for debugging and engineering purposes, some of which I had to go test myself for Windows 10 21H2, though this should apply to nearly all Windows versions, minus some Windows-specific built-in defaults that changed in newer versions of Windows (more on that later).
A small note: Other OSes, including many embedded OSes in devices (routers/switches/IoT/etc), often use a single metric (vs different summed gateway and interface metrics, like Windows), but the basic rule of lowest route metric always wins is consistent everywhere I've ever seen.
For noobs: The point of automatic metric values is, in theory, to try to ensure that the "best" route is picked as often as possible without extra configuration, when there are 2+ routes to a destination. The reason the man page definition shown in the other answer is so vague/broad is that you can structure values picked however you want, so any OS/engineer/dev/system can pick values as they please, trying to ensure that their definition of "best" route/link usually wins (i.e. is the lowest value). That said, in most normal applications "best" is almost always determined by assigning values based on raw link speed in ranges to accommodate connections that vary regularly in link speed (mostly wireless links).
I don't know and haven't tested to see if the interface metric is consistently/periodically updated on a wireless link as its link speed crosses into different ranges, but I'd imagine there's some hysteresis/stickiness or it's just hard-set at link-up to prevent it from potentially swapping priority back and forth too rapidly, if at all, with another link (usually a wired connection in the same machine, like a laptop).
Basic Routing Metrics on Windows
A route is selected from the routing table (checked from the command line with "route print") and is the sum of the interface metric and gateway metric. "Active Routes" shows you the summed, functional metrics.
To see these values separated without checking the control panel you can use Run->"netsh int ipv4 show add"
These two metrics can both be edited in the network card's properties->Advanced->"IPv4" or "IPv6" depending on which set of routes/traffic you're dealing with (Run->"ncpa.cpl" to go straight there -- Do not use the form-over-function Settings App). You can see the separate metrics under "Default Gateways" and "Interface Metric".
Automatic Metric Values on Windows (varies by version)
Interface Metric:
Per this ubiquitous Microsoft page, there are internal tables used to set the interface metric depending on the link speed. At present they list, in order, pre-XP-SP2 values (I assume), XP SP2 through Windows 8.1 values, then Windows 10+ values for wireless links and wired links (separate tables). The server versions are almost certainly identical to their equivalent consumer release, as with many things under the covers.
- Example: 1Gbit standard ethernet wired link, Win10 -> 4th table (per above), "Greater than or equal to 200 Mb and less than 2 Gb" is an interface automatic metric of 25.
Gateway Metric:
Gateway metric can be slightly trickier, as the defaults are not apparent or seemingly even documented in a quick search. Here it is set by whether the link uses a dynamic or static IP. There may be other conditions, but these two are all I've found.
From testing, I've found that the default static metric is 256 and the default dynamic/DHCP metric is 0. Since these are added to your interface metric above and you can see in the above linked tables that 256 is larger/worse than any automatic interface metric, it tells you a dynamically-addressed link will always take priority over any statically-addressed link if all defaults/automatic settings are used.
Basic Considerations in Practice
As an example: For someone administering a server or other Windows device with a static IP that doesn't want a rogue/test/2nd router on, say, a second NIC to suddenly pull the device's traffic through said router (possibly taking the server offline), forcibly set both your gateway and interface metrics low enough that no other auto-assignment is likely to supersede it. Perhaps use 1 and 10 respectively or just 1 and 1 if you want that route/NIC to always be used bar none. Just document that you did that as hard-setting some things to extreme values can occasionally cause issues down the line.
Possible Quirks/Bugs
Before starting this little documentation project, I set a secondary NIC's interface metric to 100 to deal with a network lab I had set up and after maybe a week or two, with just normal use in between, I came back and found the interface's gateway metric was also set to 100... not sure how that happened or if it was a corner-case bug but quickly setting it to static and back (it used DHCP, so there was no gateway in the NIC properties to set) fixed it and the issue hasn't returned.
