Отлично — на самом деле у меня не было правильно настроено качество обслуживания для egress. Думаю, мой JSON-файл оказался в неправильном месте (??), потому что как только я скопировал его в «Default», у меня снова заработал гигабит 😀 Рад, как слон!

QoS охватывает много разных аспектов. В одном из них — это разные приоритетные очереди передачи на вашем локальном устройстве. В этом контексте вы правы — для QoS это не так важно. Однако сопоставление qos-egress — это, по сути, просто маркировка исходящих кадров специальным приоритетным VLAN-тегом, который можно использовать по-разному (например, Per-priority Flow Control (PFC) применяет его для тонкого управления потоком). Уже очевидно, что Google использует приоритетный тег egress в заголовке VLAN для регулирования трафика.

В качестве эксперимента я провёл серию тестов скорости на своём Google Fiber (1 Гбит/1 Гбит). Процедура была такой:

cd /proc/net/vlan  
sudo cat eth2.2 <проверка включения сопоставления egress>  
GatewayAdmin@NCGateway:/proc/net/vlan$ sudo cat eth2.2  
eth2.2 VID: 2 REORDER_HDR: 1 dev->priv_flags: 1  
total frames received 151325  
total bytes received 215571890  
Broadcast/Multicast Rcvd 0  

total frames transmitted 58262  
total bytes transmitted 6085006  
Device: eth2  
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0  
EGRESS priority mappings: 0:3                                                                      ^ Вот, включено

Далее я провёл три разных теста скорости (подробнее о важности выбора теста можно почитать в моём посте). Результаты:  
Google в Роли: 822/931, 14 мс  
Speedtest в Роли: 432/937, 10 мс  
BetaSpeedtest в Роли: 914/932, 2 мс  

Затем я убрал сопоставление egress из конфигурации и перезагрузил роутер (команда commit/save не убирает сопоставление egress, оно исчезает только после перезагрузки или если удалить вручную через ip tool). Без сопоставления egress результаты были:  
Google в Роли: 663/26 (пинг не измерял)  
Speedtest в Роли: (программа упала до записи результата)  
BetaSpeedtest в Роли: 640/9, 2 мс  

Вывод, который здесь очевиден — инфраструктура Google ограничивает ваш трафик, если не использовать правильный приоритет. Возможно, именно так они продают разные скорости — нельзя же уменьшить скорость оптической сети, поэтому их роутер, скорее всего, настроен на разные сопоставления egress в зависимости от оплаченного вами сервиса, а вышестоящая сеть применяет ограничение скорости для контроля.

Одна из проблем с этим сопоставлением egress в том, что если вы перенастраиваете устройство, оно не убирает сопоставление egress, даже если в конфигурации оно удалено, и проблема проявится только после следующей перезагрузки шлюза. Поэтому многие случаи, когда кажется, что обновление прошивки вызвало проблему, могут ввести в заблуждение. В посте, на который я ссылался выше, я думал, что виновато обновление прошивки. Но когда я убрал сопоставление egress (всё это произошло после обновления контроллера до версии 5.5.20 release candidate) и перезагрузил шлюз, проблема снова проявилась.

Чтобы точно узнать, включено ли у вас правильное сопоставление egress в работающей конфигурации, нужно проверить содержимое /proc/net/vlan/eth2.2.

Привет! У меня тоже есть Google Fiber, и я заметил серьёзные проблемы со стабильностью после обновления на новую прошивку (у себя на свиче тоже: https://community.ui.com/questions/92300fea-16dd-424c-bb6b-35b39bb01d60). Только что пробежался по тесту скорости — выдало 920 вниз/938 вверх. Мой USG работает на версии v4.3.41.4975503 с применённым вот этим json-файлом: https://community.ui.com/questions/5bd5d926-4c5d-4ec4-b376-c6959e72dde1.