Home / server / Questions / 1056692
Accepted
SlyOne
Asked: 2021-03-12 03:02:12 +0800 CST

proto static metric for overlapping prefixes

  • 772

Can someone please clarify how the route metric is set by Centos 8 in the following situation.

I have two vlans on the system, each of which has a matching route prefix defined in /etc/sysconfig/network-scripts/route-vlanXX. ip route show gives the following:

[user@hostname ~]$ ip r show to match 192.168.56.252
default via 10.210.104.1 dev net proto dhcp metric 350 
192.168.56.0/24 via 192.168.1.1 dev vlan23 proto static metric 416 
192.168.56.0/24 via 192.168.1.33 dev vlan24 proto static metric 417

How is the value 416 and 417 derived? It is not explicitly set by me. proto static metric seems to be distinctly different from the metric setting. Is there any other difference other than the fact one is auto generated and the other is explicitly set?

centos routing ip-routing centos8 linux-networking

1 Answers

  1. Best Answer

    In CentOS8, NetworkManager is more or less mandatory and is the actual manager of interfaces, translating configurations into its own native configuration.

    The documentation that more or less addresses your question is there (from RHEL8's documentation, still upstream of CentOS8 today):

    20.8. How NetworkManager manages multiple default gateways

    While this documentation is only describing multiple gateways (ie multiple default routes aka 0.0.0.0/0 routes), NetworkManager internally assigns a metric to every interface it configures. This metric is then applied to routes with this interface.

    The rationale is you can't add in the same routing table (usually main) two same routes if something like the metric doesn't differentiate them (even if automatic LAN routes added by kernel can be present like this, they wouldn't work anyway). Here this prevents an error if manually configuring twice the route to 192.168.56.0/24. The metric must be different (or else policy routing and multiple routing tables must be used).

    So when not explicitly set, NetworManager makes a few choices and assumptions for the metric to use for an interface. While this metric is internally per interface for NM, there's no actual interface metric, only route metrics (and address metrics which are used for proto kernel routes).

    • no metric was explicitly configured. Base metric value for a VLAN interface is 400

      If you set a default gateway without a metric value, NetworkManager automatically sets the metric value based on the interface type.

      Connection type Default metric value
      [...] [...]
      VLAN 400

      For that, NetworkManager assigns the default value of this network type to the first connection that is activated

    • there was already a previous interface with metric 400. Pick next: 401

      and sets an incremented value to each other connection of the same type in the order they are activated. For example, if two Ethernet connections with a default gateway exist, NetworkManager sets a metric of 100 on the route to the default gateway of the connection that you activate first. For the second connection, NetworkManager sets 101.

    • rinse, repeat. until one reaches metrics 416 and 417 for vlan23 and vlan24

    Just by its metric I can conclude interface net is a Team interface.

    So in the end, this setting in /etc/sysconfig/network-scripts/route-vlan23:

    192.168.56.0/24 via 192.168.1.1 dev vlan23

    is not simply interpreted with something similar to:

    ip route add $(cat /etc/sysconfig/network-scripts/route-vlan23)

    which would get no metric, but is going through NetworkManager which adds the previously determined metric for the interface.

    Else, a second manually added route in the same way without metric would fail:

    ip route add $(cat /etc/sysconfig/network-scripts/route-vlan23)
ip route add $(cat /etc/sysconfig/network-scripts/route-vlan24)
RTNETLINK answers: File exists

    As for proto it's any value between 0 and 255 as defined in /etc/iproute2/rt_protos or its equivalent symbol. LAN routes set by kernel use proto kernel. Tools often choose static when setting a value (and obviously DHCP chooses dhcp).

    I can imagine a routing daemon would more easily track which dynamic routes are handled by itself (and the relevant protocol) and wouldn't touch static routes.

    Eg:

    ip route show proto ospf
    • 1