Как моя частота процессора может быть выше максимального значения МГц в lscpu?

Ниже я отвечаю на свой вопрос.

Самый простой обходной путь (мой подход):помещение одной из пар veth в другое сетевое пространство имен. Назовем его test.

$ sudo ip netns add test
$ sudo ip link add h1-eth0 type veth peer name h2-eth0 netns test

$ sudo ip link set dev h1-eth0 up
$ sudo ip netns exec test ip link set dev h2-eth0 up

$ sudo ip addr add 10.0.0.1/24 dev h1-eth0
$ sudo ip netns exec test ip addr add 10.0.0.2/24 dev h2-eth0

$ sudo tc qdisc add dev h1-eth0 root netem delay 60ms
$ sudo ip netns exec test tc qdisc add dev h2-eth0 root netem delay 60ms

Теперь проверяем:

$ ping -I h1-eth0 -c1 10.0.0.2
PING 10.0.0.2 (10.0.0.2) from 10.0.0.1 h1-eth0: 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=120 ms

--- 10.0.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 120.056/120.056/120.056/0.000 ms

$ sudo ip netns exec test ping -I h2-eth0 -c1 10.0.0.1
PING 10.0.0.1 (10.0.0.1) from 10.0.0.2 h2-eth0: 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=120 ms

--- 10.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 120.146/120.146/120.146/0.000 ms

Другие подходы

Я обнаружил, что мой вопрос уже задавали, но ответа на него тоже не было:https://serverfault.com/questions/585246/network-level-of-veth-doesnt-respond-to-arp. Отсюда мы видим, что проблема с ARP.

Вопрос, связанный с этой проблемой с ARP, был задан здесь Linux не отвечает на сообщения запроса ARP, если запрошенный IP-адрес связан с другим (отключенным )интерфейсом и автор темы получил некоторые объяснение, но проблема все еще не была решена.

Проблема в том, что адреса 10.0.0.1 и 10.0.0.2 присутствуют не только в основной таблице маршрутов, но и в локальной таблице маршрутов, а локальная таблица маршрутов имеет более высокий приоритет, чем основная таблица маршрутов. Ниже приведены эти таблицы для первоначальной настройки из моего вопроса, т.е. БЕЗ переноса одного конца пары veth в другое сетевое пространство именtest:

$ ip route show table local
broadcast 10.0.0.0 dev h1-eth0  proto kernel  scope link  src 10.0.0.1 
broadcast 10.0.0.0 dev h2-eth0  proto kernel  scope link  src 10.0.0.2 
local 10.0.0.1 dev h1-eth0  proto kernel  scope host  src 10.0.0.1 
local 10.0.0.2 dev h2-eth0  proto kernel  scope host  src 10.0.0.2 
broadcast 10.0.0.255 dev h1-eth0  proto kernel  scope link  src 10.0.0.1 
broadcast 10.0.0.255 dev h2-eth0  proto kernel  scope link  src 10.0.0.2 
...

$ ip route show table main
10.0.0.0/24 dev h1-eth0  proto kernel  scope link  src 10.0.0.1 
10.0.0.0/24 dev h2-eth0  proto kernel  scope link  src 10.0.0.2 
...

При наличии одного из концов пары veth в другом сетевом пространстве имен у нас не возникает ситуации, когда два из адресов помещаются в локальную таблицу маршрутов одновременно. Так что, наверное, поэтому у нас такой проблемы нет. Пробовал удалять адреса из локальной таблицы маршрутов (только один из них или оба --в разных комбинациях )но не помогло. В целом, я не до конца понимаю ситуацию, поэтому я просто остановлюсь на установке концов пары veth в разные сетевые пространства имен. Тем более, что так чаще всего используется пара veth, насколько мне известно.