Почему снизилась скорость входящего трафика после перехода на BGP с провайдером?

Question

[dmpopof]

Оба провайдера дают каналы в 10 Мб/с. После того как стали анонсировать свою автономную систему обоим провайдерам и назначили реальные адреса из анонсируемой AS на файрвол офиса очень сильно снизилась (до 0,5 Мб/с) скорость загрузки из интернет на ПК из локальной сети за этим файрволом. Только торренты можно качать на 10 Мб/с. Проверял по различным серверам скорости получения/отдачи через speedtest.net. Пострадало именно получение. Выявил при этих тестах, что получение не пострадало только если выбирать сервер speedtest хостингующийся в Мегафоне (пробовал сервера в Петербурге и Москве). Причем ни один из моих провайдеров даже близко не Мегафон.

Оба провайдера отдают default. Один дополнительно еще свои прямо подключенные сети.
Сейчас sh ip bgp neighbors .... показывает
для одного соседа
BGP state = Established, up for 1d10h
для второго соседа
BGP state = Established, up for 1d11h

Предполагал, что дело в неоптимальных путях до нашей AS пока на маршрутизаторах в инете не перестроятся таблицы. Но времени уже прошло более чем достаточно.
Пробовал весами менять провайдеров (конструкция IOS neighbor ..... weight ...), чтобы в итоге трафик из локалки пошел в инет через одного, потом через другого провайдера.

Подскажите, в чем может быть дело? Какие шаги по диагностике посоветуете предпринять?
ниже получившаяся схема сети

Answer 1

[Пума Тайланд]

НУ провайдеров в студию, ну и трасерт до какого нибудь сервера с которого медленно качает с обоих провайдеров.

Answer 2

[dmpopof]

провайдеры Билайн и местный провайдер. Сейчас роутер в общую таблицу поместил дефолт от Билайна. Плохо качает практически отовсюду. Вот например плохо с mirror.yandex.ru. Только что попробовал закачать образ 4 Гб. Скачало 1,5 МБ и оборвало по таймауту. Ниже трассировка до него

#traceroute mirror.yandex.ru
Type escape sequence to abort.
Tracing the route to mirror.yandex.ru (213.180.204.183)
VRF info: (vrf in name/id, vrf out name/id)
  1 ppp253-spb-81-211-116-253.ppp.sovintel.spb.ru (81.211.116.253) [AS 3216] 0 msec 0 msec 4 msec
  2 213.33.201.230 [AS 3216] 20 msec 20 msec 20 msec
  3  *  *  *
  4  *  *
    ugr-p3-be2.yndx.net (87.250.239.78) [AS 3216] [MPLS: Label 19393 Exp 3] 20 msec
  5 ugr-b-c1-ae4.yndx.net (87.250.239.75) [AS 3216] 20 msec *  *
  6  *  *  *
  7  *  *  *
  8  *  *  *
  9  *  *  *
 10  *  *  *
 11  *  *  *
 12  *  *  *
 13  *  *  *
 14  *  *  *
 15  *  *  *
 16  *  *  *
 17  *  *  *
 18  *  *  *
 19  *  *  *
 20  *  *  *
 21  *  *  *
 22  *  *  *
 23  *  *  *
 24  *  *  *
 25  *  *  *
 26  *  *  *
 27  *  *  *
 28  *  *  *
 29  *  *  *
 30  *  *  *

в тоже время
ping mirror.yandex.ru
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 213.180.204.183, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/20/20 ms

а вот пример трассировки до гуглевого DNS

#traceroute 8.8.8.8
Type escape sequence to abort.
Tracing the route to google-public-dns-a.google.com (8.8.8.8)
VRF info: (vrf in name/id, vrf out name/id)
  1 ppp253-spb-81-211-116-253.ppp.sovintel.spb.ru (81.211.116.253) [AS 3216] 4 msec 0 msec 0 msec
  2 beeline-gw.moscow.google.com (81.211.29.15) [AS 3216] 20 msec 20 msec 20 msec
  3 72.14.233.106 [AS 3216] 20 msec
    66.249.94.170 [AS 3216] 24 msec *
  4 64.233.174.85 [AS 3216] [MPLS: Label 575316 Exp 4] 36 msec 36 msec
    209.85.240.116 [AS 3216] [MPLS: Label 496751 Exp 4] 36 msec
  5 216.239.46.15 [AS 3216] 40 msec
    216.239.46.17 [AS 3216] 32 msec
    72.14.233.174 [AS 3216] 40 msec
  6  *  *  *
  7 google-public-dns-a.google.com (8.8.8.8) [AS 3216] 32 msec 36 msec 36 msec

далее меняем веса провайдеров перезапускаем процесс bgp и смотрим трассировку уже через другого провайдера до mirror.yandex.ru

#traceroute mirror.yandex.ru
Type escape sequence to abort.
Tracing the route to mirror.yandex.ru (213.180.204.183)
VRF info: (vrf in name/id, vrf out name/id)
  1 vlan24.asr1k2-a.atknet.ru (62.192.224.141) [AS 38976] 0 msec 0 msec 4 msec
  2 195.239.119.53 [AS 38976] 0 msec 4 msec 0 msec
  3 pe26.Moscow.gldn.net (79.104.225.57) [AS 38976] 20 msec 20 msec 20 msec
  4 213.33.201.230 [AS 38976] 16 msec 20 msec 16 msec
  5 fol2-c4-ae2.yndx.net (87.250.239.41) [AS 38976] 16 msec *  16 msec
  6  *  *
    ugr-b-c1-ae4.yndx.net (87.250.239.75) [AS 38976] 16 msec
  7  *  *  16 msec
  8  *  *  *
  9  *  *  *
 10  *  *  *
 11  *  *  *
 12  *  *  *
 13  *  *  *
 14  *  *  *
 15  *  *  *
 16  *  *  *
 17  *  *  *
 18  *  *  *
 19  *  *  *
 20  *  *  *
 21  *  *  *
 22  *  *  *
 23  *  *  *
 24  *  *  *
 25  *  *  *
 26  *  *  *
 27  *  *  *
 28  *  *  *
 29  *  *  *
 30  *  *  *

Answer 3

[throughtheether]

Как я понял, торренты утилизируют весь канал, а http - нет, я предполагаю, что проблема в работе tcp. Предлагаю:
1) проверить, не режется ли где аксесс-листами icmp (некоторые типы icmp пакетов необходимы для работы path mtu discovery).
2) выбрать один проблемный хост и проверить, icmp-пакеты типа echo request (пинги) какого максимального размера успешно до него доходят.
3) снять дамп трафика при скачивании тестового файла через http (трафик между двумя хостами, в формате .pcap).