Проблема потери пакетов и фризов

столкнулся с проблемой потери пакетов.
сделал двухстороннюю трассировку.

вот трасировка с http://trace.inn.ru/

дата и время: 6/03/2011 17:53
местоположение: russian federation, moscow city, moscow

traceroute 78.107.58.71

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.1
2. r-1-m9-ae-1.msk.inn.ru 0.0% 10 0.3 0.4 0.3 0.4 0.0
3. msk02.transtelecom.net 0.0% 10 0.5 0.5 0.4 0.8 0.1
4. 212.44.128.149 0.0% 10 3.4 2.3 0.9 3.5 0.8
5. pe-l.saratov.gldn.net 10.0% 10 26.0 26.2 24.7 26.8 0.6
6. 195.68.136.202 10.0% 10 28.6 28.4 27.1 29.3 0.6
7. 89.179.17.229 20.0% 10 32.2 31.5 30.2 32.8 0.8
8. 78.107.58.71 0.0% 10 32.0 32.7 31.6 34.2 0.8

trace complete.

исходя из трассировки от инновы потери происходят на узлах билайн (мой провайдер)

трассировка от меня

трассировка маршрута к sw-1-ti-vl-503.msk.inn.ru [109.105.130.1]
с максимальным числом прыжков 30:
0 mitik-pc [78.107.58.71]
1 ***255-lo0.srt.corbina.net [85.21.230.78]
2 89.179.17.232
3 212.44.144.5
4 cat26.moscow.gldn.net [194.186.10.114]
5 195.239.134.98
6 195.161.4.146
7 sw-1-ti-vl-503.msk.inn.ru [109.105.130.1]

подсчет статистики за: 175 сек. ...
исходный узел маршрутный узел
прыжок rtt утер./отпр. % утер./отпр. % адрес 0 mitik-pc [78.107.58.71] 0/ 100 = 0% |

1 0мс 0/ 100 = 0% 0/ 100 = 0% ***255-lo0.srt.corbina.net [85.21.230.78] 0/ 100 = 0% |

2 1мс 0/ 100 = 0% 0/ 100 = 0% 89.179.17.232 0/ 100 = 0% |

3 2мс 0/ 100 = 0% 0/ 100 = 0% 212.44.144.5 0/ 100 = 0% |

4 38мс 0/ 100 = 0% 0/ 100 = 0% cat26.moscow.gldn.net [194.186.10.114] 0/ 100 = 0% |

5 33мс 0/ 100 = 0% 0/ 100 = 0% 195.239.134.98 1/ 100 = 1% |

6 33мс 1/ 100 = 1% 0/ 100 = 0% 195.161.4.146 5/ 100 = 5% |

7 28мс 6/ 100 = 6% 0/ 100 = 0% sw-1-ti-vl-503.msk.inn.ru [109.105.130.1]

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

исходя из трассировки от меня видно что потеря пакетов происходит на узлах инновы.

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

что желать, и как быть?

 

обратитесь в провайдеру с вопросом почему происходят потери пакетов на указанных узлах

 

нет, потери на магистрали. 6 узел - 195.161.4.146 - это ростелеком.
http://www.db.ripe.net/whois?form_type=simple&full_query_string=&searchtext=195.161.4.146&do_search=search
на конечном sw-1-ti-vl-503.msk.inn.ru [109.105.130.1] как раз таки всё хорошо.

 

а как же в этом случае ?

 

бухойежик, отличные трассы. на 11 узел не обращаем внимание - на firewall-блоке идет дроп icmp-пакетов в виду их низкой приоритетности. это нормально, т.к. сигнал передается далее нормально.

 

да ваще всё круто ))), ток лагает и фризает тож не плохо)))).
и 11 узел тут тож не причём, так рядом себе стоит, криво настроенный, чо с него взять))).

 

а вот этого по трассе достоверно сказать никогда нельзя. на вашей - тем более.

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

я вам бы посоветовал проверить реальные пакеты и скорость обмена. например с помощью wireshark

 

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

 

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

 

может тогда напишете как через wireshark проверить пакеты и скорость? а то судя по инфе с http://trace.inn.ru/ у меня все супер, и другие проекты (не инновы) норм идут, а в аионе регулярные фризы, откаты и т.д.

 

трассировка от меня

трассировка маршрута к sw-1-ti-vl-503.msk.inn.ru [109.105.130.1]
с максимальным числом прыжков 30:
0 mitik-pc [78.107.58.71]
1 ***255-lo0.srt.corbina.net [85.21.230.78]
2 89.179.17.232
3 212.44.144.5
4 cat26.moscow.gldn.net [194.186.10.114]
5 195.239.134.98
6 195.161.4.146
7 sw-1-ti-vl-503.msk.inn.ru [109.105.130.1]

подсчет статистики за: 175 сек. ...
исходный узел маршрутный узел
прыжок rtt утер./отпр. % утер./отпр. % адрес 0 mitik-pc [78.107.58.71] 0/ 100 = 0% |

1 0мс 0/ 100 = 0% 0/ 100 = 0% ***255-lo0.srt.corbina.net [85.21.230.78] 0/ 100 = 0% |

2 1мс 0/ 100 = 0% 0/ 100 = 0% 89.179.17.232 0/ 100 = 0% |

3 2мс 0/ 100 = 0% 0/ 100 = 0% 212.44.144.5 0/ 100 = 0% |

4 38мс 0/ 100 = 0% 0/ 100 = 0% cat26.moscow.gldn.net [194.186.10.114] 0/ 100 = 0% |

5 33мс 0/ 100 = 0% 0/ 100 = 0% 195.239.134.98 1/ 100 = 1% |

6 33мс 1/ 100 = 1% 0/ 100 = 0% 195.161.4.146 5/ 100 = 5% |

7 28мс 6/ 100 = 6% 0/ 100 = 0% sw-1-ti-vl-503.msk.inn.ru [109.105.130.1]

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


исходя из трассировки от меня видно что потеря пакетов происходит на узлах инновы.

 

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

митик, хорошо, тогда уточните у провайдера, а зачем ему понадобился промежуточный узел? вы же играете на игровом сервере, а не на sw-1-ti-vl-503.msk.inn.ru. у вас судя по отзывами проблема с игровым сервером и не более. проверить стоит именно его тогда. даже более того скажу, если провайдеру взбредет в голову проверить трассу до узла fw-*.inn.ru то там потери будут вообще 50% и более, т.к. пакеты проверки связи просто отбрасываются, как ненужные. узловое оборудование очень часто так поступает, дабы снизить нагрузку на себя. чуть выше об этом говорили как раз.

 

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

 

я обратился к провайдеру по причине потери пакетов http://trace.inn.ru/

дата и время: 6/03/2011 17:53
местоположение: russian federation, moscow city, moscow

traceroute 78.107.58.71

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.1
2. r-1-m9-ae-1.msk.inn.ru 0.0% 10 0.3 0.4 0.3 0.4 0.0
3. msk02.transtelecom.net 0.0% 10 0.5 0.5 0.4 0.8 0.1
4. 212.44.128.149 0.0% 10 3.4 2.3 0.9 3.5 0.8
5. pe-l.saratov.gldn.net 10.0% 10 26.0 26.2 24.7 26.8 0.6
6. 195.68.136.202 10.0% 10 28.6 28.4 27.1 29.3 0.6
7. 89.179.17.229 20.0% 10 32.2 31.5 30.2 32.8 0.8
8. 78.107.58.71 0.0% 10 32.0 32.7 31.6 34.2 0.8

trace complete.

в свою очередь провайдер попросил меня сделать трассировку от меня к вам. но так как адреса игровых серверов у меня нет, я сделал трассировку к sw-1-ti-vl-503.msk.inn.ru
не могли бы вы подсказать адрес игрового сервера?

 

109.105.134.11 - гардарика
109.105.134.12 - лантис
109.105.134.13 - кассиэль
109.105.134.14 - териос
109.105.134.15 - делика

 

я понял, почему вы так сделали - спасибо за пояснения. просто, если уж смотреть проблемы со спидтестом, то трассировать надо было тогда до speedtest.inn.ru (он же trace.inn.ru), к примеру. однако, до игрового сервера будет все равно куда точнее и ближе к "боевым" условиям.

 

нет не нормально. во первых, с чего вы решили что это так сконфигурено? судя потому что данная железка пингуется пакетами длинной 1кбайт с интервалом в 0.1с и меньше без проблем, то отсутствует даже защита от флудпинга, отсутствует шейпер на пинг пакеты ,что как раз было бы гораздо логичнее сделать и очень часто делается на многих роутерах и защитах. и при этом ставить шейпер на 11 тип icmp пакета ??? (что далеко не всегда возможно, такую возможность я встречал токма в unix платформах - типа iptables). обычно либо выключают 11 тип совсем на хардовых роутерах типа cisco, juniper и т.д., потому как такой тип icmp ответа обрабатывается непосредственно центральным процессором, а он у них очень слабый, а это очень лёгкая возможность задосить такую железку, либо не трогают совсем, как на unix защитах, ибо машины под них оснащаются гораздо более мощными процессорами и пользы от зарезания такого копеешного трафика ну никакой, а скорее больше вреда.

 

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

 

ну значит я прав, это очередная кривая фича,)) и кстати не единственная, я их обнаружил уже несколько.

 

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