Windows uses a strict priority system when evaluating network routes. The routing table is processed from top to bottom, and the most specific route always takes precedence. Both interface metrics (set in network adapter properties) and route metrics (defined in the routing table) play crucial roles in this decision-making process.

When there's a conflict between interface metrics and route metrics:

1. Route specificity always wins over metrics (a /32 route beats a /24 route)
2. For equally specific routes, Windows compares the sum of interface metric and route metric
3. The lower combined metric value determines the preferred route

Consider this PowerShell output showing route evaluation:

Get-NetRoute -AddressFamily IPv4 | Sort-Object -Property PrefixLength,RouteMetric | 
Format-Table -AutoSize

InterfaceMetric RouteMetric DestinationPrefix  
--------------- ----------- -----------------
1               10          192.168.1.0/24
5               1           192.168.1.100/32

In this case, the /32 route would be used for 192.168.1.100 despite having a higher interface metric because:

1. It's more specific (/32 vs /24)
2. Even if metrics were compared (5+1=6 vs 1+10=11), the more specific route wins

To adjust interface metrics programmatically:

# PowerShell: Set interface metric
Set-NetIPInterface -InterfaceAlias "Ethernet" -InterfaceMetric 15

# C# equivalent:
using System.Net.NetworkInformation;
var adapter = NetworkInterface.GetAllNetworkInterfaces()
    .First(n => n.Name == "Ethernet");
var ipProperties = adapter.GetIPProperties();
ipProperties.GetIPv4Properties().Metric = 15;

When you need precise control, use route commands:

# Add persistent route with specific metric
route -p add 10.0.0.0 mask 255.255.255.0 192.168.1.1 metric 5 if 2

# Corresponding PowerShell:
New-NetRoute -DestinationPrefix "10.0.0.0/24" -InterfaceIndex 2 -NextHop 192.168.1.1 -RouteMetric 5 -PolicyStore PersistentStore

Diagnose routing decisions with these tools:

# Show effective metrics
Get-NetIPInterface | Where-Object {$_.AddressFamily -eq "IPv4"} | 
Select-Object InterfaceAlias,InterfaceMetric | Sort-Object -Property InterfaceMetric

# Trace route selection
Test-NetConnection -ComputerName target.example.com -DiagnoseRouting

In Windows networking, two distinct metrics govern routing decisions:

• Interface Metric: Set in TCP/IP properties (ncpa.cpl → Properties → IPv4 → Advanced)
• Route Metric: Associated with specific routes in the routing table (visible via route print)

Windows employs a two-tiered decision process:

1. Longest Prefix Match (most specific route wins)
2. When equal prefix length:
   a) Lower route metric takes precedence
   b) Interface metric only breaks ties when route metrics are equal

Consider this configuration:

# Interface configuration:
NIC1: IP 192.168.1.10/24, Interface Metric = 1
NIC2: IP 10.0.0.5/24, Interface Metric = 10

# Routing table:
Network Destination  Netmask      Gateway      Interface     Metric
192.168.1.0         255.255.255.0  On-link     192.168.1.10     10
10.0.0.0            255.255.255.0  On-link     10.0.0.5         20

In this case, traffic to 192.168.1.15 will use NIC1 despite the higher route metric (10) because:

1. Both routes are on-link (same prefix length)
2. NIC1's route metric (10) is lower than NIC2's (20)
3. Interface metric only becomes relevant if route metrics were equal

To check effective routes and metrics:

Get-NetRoute | Sort-Object -Property RouteMetric | 
Format-Table -AutoSize DestinationPrefix,NextHop,RouteMetric,InterfaceMetric,InterfaceAlias

Case 1: Multiple default gateways

# Conflicting default routes
0.0.0.0/0 via 192.168.1.1 metric 10 (NIC1, ifmetric=1)
0.0.0.0/0 via 10.0.0.1 metric 5 (NIC2, ifmetric=50)

# Result: Traffic uses NIC2 (lower route metric wins)

Case 2: Equal route metrics

# Tiebreaker scenario
172.16.1.0/24 via NIC1 (route metric=15, ifmetric=1)
172.16.1.0/24 via NIC2 (route metric=15, ifmetric=10)

# Result: Traffic uses NIC1 (lower interface metric breaks tie)

• Always set explicit route metrics when creating persistent routes
• Use netsh interface ipv4 set interface for interface metric adjustments
• Remember interface metrics only affect local preference, not routing table decisions

# Example: Setting interface metric
netsh interface ipv4 set interface "Ethernet" metric=10

# Example: Adding route with specific metric
route -p add 192.168.2.0 mask 255.255.255.0 192.168.1.1 metric 5