Часто приходится сталкиваться с ошибочным мнением о том, что на сети нет потери пакетов, потому что “на графиках нет полок”(и CRC). Однако, графики это результат усреднения, у кого-то это 5 минут, у других 30 секунд, а где-то интервал усреднения может быть даже 5 секунд. Но всё равно такие графики не учитывают явления “микробёрстов”. “Проблема” выражается в том, что практически в любой сети существуют интерфейсы с различной скоростью. Например, в не очень большой сети это 100М на доступе, 1G на агрегации и 10G в ядре или его подобии. И каждый переход 10G->1G, 1G->100M и т.п. является потенциальной проблемой.

Для того, чтобы продемонстрировать эти самые микробёрсты, соберём следующую схему из одного коммутатора и компьютера.

В качестве коммутатора взят DCS-3950-28C просто потому что он был под рукой. Это относительно недорогой свитч, используемый на просторах СНГ для строительства FTTB-сетей, обычно продаётся под различными названиями разными поставщиками.

На схеме используется 3 netns – по умолчанию(“глобальный”), netns G(генератор трафика) и netns C(приёмник трафика). Что такое netns и как их конфигурировать написано здесь. Настроены они следующим образом:

# ip route show
192.0.2.0/30 dev eth0.10  proto kernel  scope link  src 192.0.2.1 
192.0.2.4/30 dev veth  proto kernel  scope link  src 192.0.2.5

# ip netns exec G ip route show
default via 192.0.2.5 dev vethG 
192.0.2.4/30 dev vethG  proto kernel  scope link  src 192.0.2.6 

# ip netns exec C ip route show
default via 192.0.2.1 dev eth2 
192.0.2.0/30 dev eth2  proto kernel  scope link  src 192.0.2.2 

В глобальном netns включна маршрутизация(ip forwarding), таким образом между G и C существует L3-связность. G – это генератор трафика(для простоты понимания можно представить, что это некий сервер где-то в интернете, с которого что-то качает клиент C, но лучше абстрагироваться для дальнейшего обобщения).

Ограничим приём трафика от G полосой в 30Мбит/с (т.е. установим полисер на интерфейсе veth, который смотрит в сторону netns G):

tc qdisc add dev veth handle ffff: ingress
tc filter add dev veth parent ffff: protocol ip prio 10 u32 match ip src 0.0.0.0/0 police rate 30mbit burst 512k drop flowid :1

Генератор отправляет трафик(с 192.0.2.6 на 192.0.2.2) со скоростью 200Мбит/с и этот трафик режется до 30Мбит/с на интерфейсе veth, в интерфейс eth0.10 он отправляется уже со скоростью 30Мбит/с, затем проходит через свитч и попадает в netns C на интерфейс eth2. Таким образом, линк 1G загружен на 3%, линк 100M на 30% и такие цифры показывает сам свитч. Полок нет, значит и потерь нет, всё логично.
Теперь посчитаем трафик на выходе из eth0.10 и на входе eth2 с помощью iptables:

# iptables -I FORWARD -s 192.0.2.6 -d 192.0.2.2 -o eth0.10 -j ACCEPT
# ip netns exec C iptables -I INPUT -s 192.0.2.6 -d 192.0.2.2 -i eth2 -j ACCEPT

Запускаем генератор:

ip netns exec G iperf -c 192.0.2.2 -b 200M -u -i 1 -t 10

и смотрим счётчики

# ip netns exec C iptables -nvxL INPUT ; iptables -nvxL FORWARD
Chain INPUT 
    pkts      bytes target     prot opt in     out     source   destination         
   25111 37616278 ACCEPT     all  --  eth2   *       192.0.2.6   192.0.2.2           
Chain FORWARD
    pkts      bytes target     prot opt in     out     source   destination         
   25384 38025232 ACCEPT     all  --  *      eth0.10  192.0.2.6   192.0.2.2  

Как видно, возникла потеря 273=25384-25111 пакетов. Попробуем разобраться почему. Для этого снимем дампы с eth0.10 и eth2, чтобы потом их сопоставить и понять где и почему пропадает трафик:

ip netns exec C tcpdump -i eth2 -c 5000 -s 0 -w /dev/shm/eth2.pcap &
tcpdump -i eth0.10 -c 5000 -s 0 -w /dev/shm/eth0.10.pcap &

Запустили ещё раз генератор, получили дампы, но, к сожаленью в них абсолютно одинаковые кадры и поэтому если сделать merge этих дампов(для того, чтобы применить средства анализа), то потом нельзя будет различить потоки. Внесём небольшие изменения в дамп eth0.10.pcap, заменив ip.src 192.0.2.6 на 192.0.2.8 во всех пакетах:

cat eth0.10.pcap | sed 's/\xC0\x00\x02\x06/\xC0\x00\x02\x08/g' > eth0.10-2.pcap

Теперь открываем eth0.10-2.pcap с помощью wireshark, делаем merge с eth2.pcap (File->Merge) и запускаем анализ Statistics->IO Graph с параметрами как на картинке:

Чёрная линия – трафик на выходе из eth0.10, красная на входе eth2. Отсюда видно, что первые 0.025 секунды трафик не ограничивается, а просто пересылается с veth на eth0.10 с той скоростью, с которой он пришёл на интерфейс veth и лишь потом(начиная с 0.025с) начинает ограничиваться полосой 30Мбит/с. Однако, если усреднить поток по тем самым 5-30-300 секундам, с которыми строят графики системы мониторинга, то мы увидем лишь прямую линию в 30Мбит/с.

Как видно из графика, у коммутатора есть буфер кадров, но его не хватило, а потерянный трафик это разница площадей, покрашенных в фиолетовый и зелёный цвета. Фиолетовая область это и есть burst и если бы он был короче по времени в 5-10 раз, то буфера коммутатора хватило бы на то, чтобы компенсировать рассогласование скоростей.

Это наглядное объяснение тому что такое “10 Gbps to 1 Gbps speed mismatch” и зачем на коммутаторе Cisco ME-3800X сделали буфер коммутации 352Мбайта:

A total buffer size of 352 MB is available to provide per service advanced QoS capabilities.. Such amount of buffer is required when stringent applications like financial or video must be protected against the impact of 10 Gbps to 1 Gbps speed mismatch.

Описанную методику можно применять пусть не для вычисления размера буфера коммутации, но хотя бы для того, чтобы сравнивать различные свитчи по этому параметру.

IRL

Собственно возникает вопрос, наблюдается ли это явление в реальной жизни? Если кратко, то да.
Мало того, на том же самом DCS-3950-28C подропанный трафик никак не считается и нельзя узнать происходит оно или нет. На оборудовании другого класса такие счётчики обычно есть. Например, на Huawei S9300:

dis qos queue statistics interface GigabitEthernet 5/0/3 
 Queue  CIR/PIR(kbps)  Passed(Packet/Byte)  Dropped(Packet/Byte)
   -------------------------------------------------------------
     0              0       11,281,055,120               423,367
              1000000   10,412,905,209,194           593,997,022
   -------------------------------------------------------------
     1              0                8,362                     0
              1000000            1,854,260                     0
   -------------------------------------------------------------
     2              0                    0                     0
              1000000                    0                     0
   -------------------------------------------------------------
     3              0                    0                     0
              1000000                    0                     0
   -------------------------------------------------------------
     4              0       16,977,133,574                     0
              1000000   22,433,465,221,860                     0
   -------------------------------------------------------------
     5              0                   63                     0
              100000                 6,174                     0
   -------------------------------------------------------------
     6              0            4,267,642                     0
              1000000          309,122,210                     0
   -------------------------------------------------------------
     7              0                6,314                     0
              1000000              719,796                     0
   -------------------------------------------------------------

Эта табличка – распределение трафика по аппаратным очередям(исходящим). Здесь видно, что в нулевой очереди есть дропы(хотя по графикам загрузка линка не превышает 50%). И если в эту очередь попадёт реал-тайм сервис, например iptv udp, то ждите жалоб на “квадратики” и “рассыпания”.

Что делать?

Из всего этого делается простой вывод, QoS в мультисервисной сети нужен на всех участках, даже если по графикам полок нет. В действительности, проблемы “speed mismatch” это не только переходы через интерфейсы с разным скоростями, такими как 10G->1G, но даже если все порты будут одной скорости, то всё равно трафик из 2ух портов может приходить в один и это будет тоже самое, что и 10G->1G, только 20G->10G.
В условиях выживания(?) мультисервисных сетей и роста OTT-сервисов, можно брать деньги за раскраску(и её учёт при распределении трафика по очередям) с различных рейлтайм-сервисов, но этот вопрос лежит скорее в плоскости коммерции и политики.

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

И в третьих, очень важно проверить, что поток трафика 200мбит/с, идущий в порт 100мбит/с не блокирует нормальную работу других портов. Если возникает явная деградация сервиса, то такое оборудование лучше не покупать. На DCS-3950-28C такое явление не наблюдается.