Большие потери на узле!

http://**********/data/upload/6895e/69fda/d90fde7c3e.jpg
играть проблематично, что случилось и когда приблизительно устранят??????????

 

большие потери на каком узле вы там увидели? эффективные потери там 2%, начиная с узла ростелекома.

 

http://**********/data/upload/4efc3/04012/666542e7d4.jpg
на каком? а вы не видете? на предпоследнем узле инновы.
фризит часто.

 

ahtoito, какие же это потери... смотрите чуть далее - все пакеты (за исключением, возможно, 2% - это скорее всего реально потери) попадают на последний узел! т.е. предпоследний, фаервол-блок просто передает пакеты далее и вам не отвечает. это часто делают для снижения нагрузки на критически важные узлы. а последний узел вам отвечает, да и играете вы на последнем узле - игровом сервере, а никак не на фаерволенном блоке (что вам собственно там делать).

не верите - можно смотреть сигнал, который идет от инновы к вам, с маршрутизатора mmts-9.

 

ясно. тему можете удалить. спс за внимание.

 

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

PHP:

|------------------------------------------------------------------------------------------|

|                                      winmtr statistics                                   |

|                       host              -   %  | sent | recv | best | avrg | wrst | last |

|------------------------------------------------|------|------|------|------|------|------|

|                             192.168.1.1 -    0 |  101 |  101 |    0 |    2 |   20 |    0 |

|                             92.46.142.1 -    0 |  101 |  101 |   40 |   48 |  130 |   40 |

|                           10.245.85.221 -    0 |  101 |  101 |   40 |   45 |  110 |   50 |

|                           10.245.87.248 -    0 |  101 |  101 |   40 |   45 |  130 |   40 |

|                           82.200.249.48 -    0 |  101 |  101 |   40 |   49 |  170 |   40 |

|                kara-core-l2-1.online.kz -    0 |  101 |  101 |   40 |   55 |  130 |   40 |

|                           92.47.151.210 -    0 |  101 |  101 |   40 |   48 |  130 |   50 |

|                asta-core-l2-1.online.kz -    0 |  100 |  100 |   40 |   49 |  110 |   50 |

|                   asta-gate-1.online.kz -    0 |  100 |  100 |   40 |   51 |  180 |   50 |

|                             94.25.4.125 -    0 |  100 |  100 |   90 |  103 |  160 |  100 |

|        ae-8.m7-ar3.msk.ip.rostelecom.ru -    0 |  100 |  100 |  110 |  121 |  190 |  120 |

|                            79.133.94.86 -    0 |  100 |  100 |  110 |  121 |  200 |  110 |

|                 sw-1-ti-po-4.msk.inn.ru -    0 |  100 |  100 |  110 |  118 |  210 |  110 |

|              fw-2-ti-ae-1-57.msk.inn.ru -   50 |  100 |   50 |  130 |  139 |  170 |  140 |

|             aion-frost-02.ti.msk.inn.ru -    0 |  100 |  100 |  110 |  119 |  190 |  120 |

|________________________________________________|______|______|______|______|______|______|

на других узлах как видно проблем нет. я в принципе согласен, что верней всего тут не все 50% "настоящие" потери. но имхо с этим узлом что то не так. кстати до этого он не отбрасывал пакеты при трассировках. я не знаю его настроек, может он начинает отбрасывать icmp пакеты при перегрузках, или еще что. вот по этому и прошу прокомментировать. почему сегодня уже более часа постоянные лаги.

 

ну а что тут комментировать. выше абсолютно аналогичный по смысловой нагрузке пример. внешний ip свой дайте (myipaddress.com), сделайте обратные трассы с trace.inn.ru, убедитесь, что с каналом все хорошо. на последний узел 100 пакетов бы просто не попало, если бы на предпоследнем они потерялись реально. погрешности могут быть - да, потери на иннове могут быть - да, на магистралях могут быть - да, но не 50%. иначе бы эффект был бы куда хуже, чем наблюдаете вы.

я не верю свято в icmp. сами знаете, какой капризный в наших реалиях это протокол (в смысле приоритетов). игровые пакеты могут вести себя совершенно иначе. но вот за них гарантии не дам. проверить можно только от вас программами типа wireshark детально разбирая протокол обмена и фильтруя повторы передачи, либо на провайдере - он может посмотреть сессию обмена.

 

radix, я согласен, что 50% потерь не отображает потери игровых пакетов. иначе это был бы полный кошмар. но поверьте мне хватает и тех потерь которые есть, что бы меня откидывало назад, что бы срывались касты, что бы не срабатывали умения, что бы меня фризило на 1-2 секунды, что бы играть было не комфортно.
это не первая моя трасировка и до сих пор я не замечал, что бы fw-2-ti-ae-1-57.msk.inn.ru отбрасывал icmp пакеты. о5 же я не знаю его настроек, отсюда мне не видно. что там происходит. просто если там поменяли какие то настройки то возможно что то сделано криво и часть игровых пакетов теряется? я не утверждаю что так есть я говорю что так может быть. может отброс icmp пакетов включается когда узел перегружен7 может так быть? вполне. но о5 же я не могу это утверждать, отсюда это не видно. просто появились лаги, на всей трассе есть всего один узел который обрабатывает icmp запрос не так как прежде. поэтому логично что я начинаю думать на него.
в конце концов не важно что я думаю. важно где проблема и когда решится. вот собственно на этот вопрос я и хотел бы услышать ответ. в прошлом уже бывало, что народ начинал жаловаться на проблемы им ответили:"у нас все хорошо." на следующий день народа стало больше, им ответили так же. а потом народа стало очень очень много, и мы услышали что "фогейм заболел...". вот в тот раз у меня не лагало вообще. народ вылетал из пати раз за разом. многие не могли вообще зайти в игру. фризило, откидывало многих. а у меня все было прекрасно. поэтому аргумент "ну не у всех же лагает" не убедителен. вседаки у инновы достаточно сложное сетевое оборудование и отнюдь не обязательно что бы лагало всех.
собственно вопрос: все ли в порядке с fw-2-ti-ae-1-57.msk.inn.ru? и если с ним все нормально, то какая причина сегодняшних лагов?

 

а у меня такая картина с http://trace.inn.ru/ после профилактики, до этого потерь не было вообще! сейчас фризует, отбрасывает назад, играть невозможно ;(

host: speedtest-1-ti loss% snt last avg best wrst stdev
1. sw-1-ti-vl-503.msk.inn.ru 0.0% 10 0.4 0.4 0.3 0.4 0.0
2. r-1-m9-ae-1.msk.inn.ru 0.0% 10 0.3 0.4 0.3 1.5 0.4
3. 109.105.128.82 0.0% 10 0.5 0.5 0.4 0.5 0.0
4. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
5. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
6. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
7. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
8. 85.26.172.138 0.0% 10 25.8 25.8 25.7 25.9 0.0
9. cmir4-b0.ufanet.ru 0.0% 10 37.0 37.0 37.0 37.1 0.0
10. cstr1-1-vl21.str.ufanet.ru 0.0% 10 41.7 41.5 41.3 41.7 0.1
11. ***6.str.ufanet.ru 0.0% 10 41.2 41.2 41.2 41.4 0.1
12. 94.41.156.129.dynamic.str.ufanet.ru 0.0% 10 42.8 43.0 42.6 43.4 0.3

trace complete.

 

по той трассе, что показали вы - нелогично. пакеты поступают дальше. прироста пинга нет. проблем с ним нет. в последнее время этот узел ведет себя именно так. скорее всего, это связано с тем, что в дц проводились работы по оптимизации сетевой инфраструктуры. вот когда будут потерьки и на последнем узле - тогда соглашусь полностью. а пока все чисто, хотя и вызывает подозрения и опасения. но не это не значит, что лагов быть не должно. про отличия в icmp и пакетов реального игрового протокола обмена я уже говорил (там действительно может быть что угодно и мы этого по трассе никогда не увидим - только применение сниффера tcp). да и не только сетевой элемент может вызывать подобную реакцию в конце концов. может быть комплекс проблем.

по приведенной трассе ее не видно. обратные трассы, тесты связности на internet-speed.ru? мне больше пока отталкиваться не от чего. одна трасса - далеко не показатель всех проблем. а если в итоге окажется виновата магистраль - то сроки решения вам вообще не скажут. для всех это будет просто фактом, что авария, сбой или проведение работ.

их и сейчас нет. трасса неплохая. 4,5,6,7 узлы - магистраль. icmp через них проходит точно, игровые пакеты - опять же не скажу с какими показателями попадают.

 

делал я обратную трассировку, но там маршруты разные.

PHP:

traceroute 95.57.11.140

host: speedtest-1-ti             loss%   snt   last   avg  best  wrst stdev
  1. sw-1-ti-vl-503.msk.inn.ru   0.0%    10    0.3   0.4   0.3   0.5   0.0
  2. r-1-m9-ae-1.msk.inn.ru      0.0%    10    0.3   3.2   0.3  17.2   6.2
  3. 79.133.94.85                0.0%    10    0.4   0.4   0.4   0.4   0.0
  4. 95.167.92.106               0.0%    10   15.5  24.4  15.5  64.0  18.8
  5. 94.25.4.126                 0.0%    10   82.9  83.3  82.9  86.3   1.1
  6. 92.47.150.36                0.0%    10   87.2  87.2  87.0  87.5   0.2
  7. asta-core-l2-1-2.online.kz  0.0%    10   99.2 100.2  98.7 111.0   3.8
  8. kara-core-l2-1.online.kz    0.0%    10   99.3  99.0  98.7  99.3   0.2
  9. kara-mx-1.online.kz         0.0%    10   86.2  86.3  86.2  86.3   0.0
 10. 82.200.249.49               0.0%    10   71.9  71.8  71.8  71.9   0.0
 11. ???                        100.0    10    0.0   0.0   0.0   0.0   0.0
 12. 92.46.142.1                 0.0%    10  102.5 100.1  99.4 102.5   1.0
 13. 95.57.11.140               10.0%    10  113.6 127.5 111.3 241.7  42.8

 

4-7 магистраль? а как узнать какая? раньше таких вопросиков не было и маршрут был не 1-12 пункты, а всего 1-6(7). как узнать, кто поменял маршруты? вот трассировка с моей стороны

c:\documents and settings\admin>tracert 109.105.134.14

трассировка маршрута к aion-frost-04.ti.msk.inn.ru [109.105.134.14]
с максимальным числом прыжков 30:

1 2 ms 1 ms 1 ms ***3.str.ufanet.ru [92.50.178.7]
2 17 ms 1 ms 1 ms 92.50.178.1.static.str.ufanet.ru [92.50.178.1]
3 3 ms 3 ms 3 ms cmr4-1-vl16.ufa.ufanet.ru [92.50.191.225]
4 3 ms 3 ms 3 ms b0-cmir4.ufanet.ru [92.50.190.34]
5 4 ms 3 ms 3 ms msk46.transtelecom.net [217.150.41.70]
6 71 ms 72 ms 72 ms innova-gw.transtelecom.net [217.150.49.197]
7 73 ms 72 ms 72 ms sw-1-ti-po-4.msk.inn.ru [109.105.128.34]
8 73 ms * 72 ms fw-2-ti-ae-1-57.msk.inn.ru [109.105.128.46]
9 73 ms 73 ms 73 ms aion-frost-04.ti.msk.inn.ru [109.105.134.14]

трассировка завершена.

 

лерис, а они в общем случае и будут разными. дело не в отличии, а в том чтобы понять есть ли какие проблемы, видимые нам через icmp-протокол, если есть, то где и когда получится исправить. верно? ну так вот обратная трасса за исключением прироста пинга при переходе к региональным узлам меня ничем пока не пугает. единственное - я не знаю, какие показатели были ранее на них. я предлагаю вам сделать трассы (комплект трасс) в проблемное время и в обычный период. может так что и увидим. пока по обратной трассе вижу узлы ростелекома. качественно по icmp ничего не видно, но о проблемах с ним вы слышали наверное (см. объявления)

дэниз, а не мегафон ли у вас в обратку? если же это ростелеком - тоже самое в общем. у них крупное объединение и реорганизация сетей идет - даже объявление по форуму об этих событиях есть. отсюда могут быть и проблемы + нестабильность как маршрута в принципе, так и его качественно-количественных показателей. дайте мне свой внешний ip с myipaddress.com. я посмотрю на mmts-9 роутере и msk-ix.

 

нет, мегафона никогда не было, ростелеком - да, но в последних трассах появился волгоград, зачем? не понимаю

с вашей ссылки мой ip - 94.41.144.124 , пожалуйста

 

radix,я понимаю,что вы защищаете честь инновы,но проблемы есть у многих(в том числе и у меня,я сечас на двух провайдерах,у одного внутриигровой пинг около 300 у другого 600 это норм?),и не надо ссылатся на сторонних провайдеров,иннова сама проплачивает за свой траффик,и делает это дешевле(например через амстердам),не надо просто экономить,тем более как говорит арт количество геймеров на порядок выше,чем мы думаем,и умнож на 300р.

 

перец2, я на форуме лицо совершенно стороннее. я говорю и делаю выводы по тому, что мне показали + то, что я уже знаю. вы мне ничего не показывали, поэтому не буду комментировать дальнейшие посты такого содержания, т.к. это просто трата времени на слова, неподкрепленные цифрами и показателями. да и подключение происходит по существующим каналам на магистралях (за исключением всем известных пиров в москве), и никаких "амстердамов" никто не оплачивает. вас кто-то обманул. переключение маршрутов зависит от того, какие анонсы поступят на mmts-9, к примеру, по bgp. если, к примеру, укртелеком не в состоянии задать всему своему пулу адресов выход по оптимальному маршруту, то роутер инновы так и будет отсылать в одну подсеть с минимальными издержками (retn, telia), а вашему соседу - через пол европы. однако, повторюсь, это слова - без цифр можно хоть с пеной у рта спорить, толку то - интернет такая вещь, где каждый при своем мнении, и просто так не верят.

дэниз, а вот с вами устраиваем сейчас мастер-класс по связности в глобальных сетях. и так мы имели ранее ростелеком? хорошо, теперь нечто иное - но что.
идем допрашивать роутер инновы на mmts-9, что он нам дает на ваш внешний ip:

Код:

router: moscow, mmts-9 
command: show route protocol bgp 94.41.144.124 terse 

inet.0: 356355 destinations, 1799137 routes (354230 active, 0 holddown, 382016 hidden)
+ = active route, - = last active, * = both

a destination        p prf   metric 1   metric 2  next hop        as path
[color="red"]* 94.41.144.0/20     b 170         96      10000 >109.105.128.82  31133 24955 24955 24955 24955 i[/color]
                     b 170         95      10000 >79.133.94.85    12389 24955 24955 24955 i
                     b 170         95      30000 >193.232.245.71  12389 24955 24955 24955 i
                     b 170         95      30000 >193.232.247.71  12389 24955 24955 24955 i
                     b 170         95      10000 >193.232.245.47  31133 24955 24955 24955 24955 i
                     b 170         95      10000 >193.232.247.47  31133 24955 24955 24955 24955 i
                     b 170         85      40000 >217.150.49.198  20485 24955 i
                     b 170         85      40000 >213.248.96.69   1299 20485 24955 i
                     b 170         85      40000 >87.245.255.137  9002 20485 24955 i
                     b 170         85      40000 >195.161.4.145   8342 12389 24955 24955 24955 i

dinet.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

rtcomm.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

:cdn.inet.0: 354161 destinations, 1417990 routes (354003 active, 0 holddown, 1079 hidden)
+ = active route, - = last active, * = both

a destination        p prf   metric 1   metric 2  next hop        as path
[color="red"]* 94.41.144.0/20     b 170         96      10000 >109.105.128.82  31133 24955 24955 24955 24955 i[/color]
                     b 170         95      10000 >79.133.94.85    12389 24955 24955 24955 i
                     b 170         95      30000 >193.232.245.14  12389 24955 24955 24955 i
                     b 170         95      30000 >193.232.247.14  12389 24955 24955 24955 i
                     b 170         95      10000 >193.232.245.47  31133 24955 24955 24955 24955 i
                     b 170         95      10000 >193.232.247.47  31133 24955 24955 24955 24955 i
                     b 170         85      40000 >213.248.96.69   1299 20485 24955 i
                     b 170         85      40000 >87.245.255.137  9002 20485 24955 i
                     b 170         85      39980 >195.161.4.145   8342 12389 24955 24955 24955 i
                     b 170         84      50000 >217.150.49.198  20485 24955 i

{master}

красным я выделил "наилучший" маршрут, который установил роутер инновы, основываясь на качественных метриках (это уже не его придумка - они заимствованы из сети). в пути до ваших сетей мы видим там некую автономную систему as31133 как отправную точку после сети инновы. попытаемся выяснить, чья она, сделав запрос к базе ripe:

Код:

% information related to 'as31133'
[color="red"]aut-num:         as31133[/color]
as-name:         mf-mgsm-as
[color="red"]descr:           ojsc megafon network[/color]
remarks:
remarks:         --- upstreams ---
remarks:
import:          from as20485 accept any
export:          to as20485 announce as-mf-mgsm
import:          from as1299 accept any
export:          to as1299 announce as-mf-mgsm
import:          from as3216 accept any
export:          to as3216 announce as-mf-mgsm
import:          from as2914 accept any
export:          to as2914 announce as-mf-mgsm
import:          from as3356 accept any
export:          to as3356 announce as-mf-mgsm
import:          from as6762 accept any
export:          to as6762 announce as-mf-mgsm
import:          from as6854 accept any
export:          to as6854 announce as-mf-mgsm
.............

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

но это еще не все. смотрим, какой же маршрут от инновы 2-ой по качеству (попутно замечаем, что он почти не уступает первому по метрикам, лишь слегка проигрывает):

b 170 95 10000 >79.133.94.85 12389 24955 24955 24955 i

здесь сразу отмечаем характерный узел 79.133.*.* кто хочет - может пробить его через whois-ip-lookup, я же снова воспользуюсь ripe:

Код:

% information related to 'as12389'
[color="red"]aut-num:         as12389
as-name:         rostelecom-as[/color]
descr:           jsc rostelecom
remarks:
remarks:         upstreams
remarks:
import:          from as3491 accept any
export:          to as3491 announce as-rostelecom
import:          from as2914 accept any
export:          to as2914 announce as-rostelecom
import:          from as1299 accept any
export:          to as1299 announce as-rostelecom
import:          from as1273 accept any
export:          to as1273 announce as-rostelecom
import:          from as3549 accept any
export:          to as3549 announce as-rostelecom
import:          from as3257 accept any
export:          to as3257 announce as-rostelecom

так это же наш ростелеком (с которым не лагало???). отсюда вывод - недавно банально маршрут был переключен и направлен через мегафоновские каналы. у них и своей нагрузки всегда хватало, и на msk-ix у мегафона много раз падало оборудование (хотя в этот раз оно непричем), а теперь до кучи объединение крупнейших сетей.

мой совет - звонить провайдеру, просить либо вернуть прежние маршруты (договорености, лучшие метрики и т.п. - не знаю, в чем там проблема то возникла), либо запретить анонсы своих сетей на мегафон (дабы иннова даже не пыталась туда отправлять пакеты). на второе могут и не пойти - т.к. маршрут через мегафон может быть лучше для остальных целей - веб-серфинг, медиа-контент других isp и т.д.

если что-то непонятно - спрашивайте, если где-то я допустил ошибку - поправляйте. главное - выработать точное и правильное понимание ситуации вообще.

 

radix,я не в украине а на урале,и вы меня вынудили сделать слепки трассировок,ну чтож,выложу в следующем посте

 

укртелеком я для наглядности привел. у его пользователей чаще возникают вопросы в этом плане.
а у вас нечто типа "башинформсвязи"? наверняка также маршрут идет, как у пользователя выше.

 

лагало, конечно, но не настолько

ну что ж, спасибо, попробую поговорить с провайдером.

перец2, ты тоже на урале, кто у тебя провайдер? (интересно, просто)... у меня "уфанет".

 

интересно, что они вам ответят.