Andrei Опубликовано 11 января, 2009 · Жалоба если у вас прибыло, значит у кого-то убыло :)Наверное у нас убыло.До mail.ru mtr www.mail.ru My traceroute [v0.67] ***** (0.0.0.0)(tos=0x0 psize=64 bitpattern=0x00) Sun Jan 11 16:58:16 2009 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 87.226.ххх.х 0.8% 7542 8.3 7.3 2.0 362.5 21.6 2. se-0-3-0.chelyabinsk-r1.ur.ip.ro 0.0% 7542 8.4 24.1 7.3 494.6 32.2 3. ae-1.m7-ar1.msk.ip.rostelecom.ru 9.0% 7541 57.4 57.2 38.4 526.5 28.9 4. 195.239.8.25 9.0% 7541 43.4 57.2 38.2 461.1 30.5 5. cat01.Moscow.gldn.net 9.5% 7541 53.7 63.3 39.2 532.8 40.3 6. mailru-KK12-1-gw.Moscow.gldn.net 9.3% 7541 52.7 62.5 41.4 455.9 27.1 7. 194.67.57.226 10.3% 7541 48.5 59.2 41.5 501.1 26.2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Paxton Опубликовано 11 января, 2009 (изменено) · Жалоба может хватит?трейсы покажите! Вам даже комерсы скажут где трабл :) Какие трейсы? У РТ MPLS ядро скрыто. То бишь TTL в IP пакетах на P маршрутизаторах не изменяется. Насколько помню, между УАКами лежат RSVP туннели (full mesh), даже не по одному, а по несколько штук с помощью явного задания strict-loose узлов, через которые должен идти траф конкретного туннеля. Поэтому траф в один и тот же destination может идти разными путями. Ессно на разных участках загрузка каналов разная, поэтому где-то суровые дропы, где-то попроще. Предполагаю, даже в нормальное время с разных source ip к одному и тому же dest ip должен наблюдаться разный RTT - когда траф идет различными путями. Изменено 11 января, 2009 пользователем Paxton Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
PowerPack Опубликовано 11 января, 2009 · Жалоба Вот что значит NGN сети? Это когда глючит, но не можешь понять где! :-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гoсть Опубликовано 11 января, 2009 · Жалоба Превед Paxton! Ну и теперь в очередной раз убеди нас, что это был единственно верный дизайн, аи-яй-яй ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlexBT Опубликовано 12 января, 2009 · Жалоба может хватит?трейсы покажите! Вам даже комерсы скажут где трабл :) Какие трейсы? У РТ MPLS ядро скрыто. То бишь TTL в IP пакетах на P маршрутизаторах не изменяется. Насколько помню, между УАКами лежат RSVP туннели (full mesh), даже не по одному, а по несколько штук с помощью явного задания strict-loose узлов, через которые должен идти траф конкретного туннеля. Поэтому траф в один и тот же destination может идти разными путями. Ессно на разных участках загрузка каналов разная, поэтому где-то суровые дропы, где-то попроще. Предполагаю, даже в нормальное время с разных source ip к одному и тому же dest ip должен наблюдаться разный RTT - когда траф идет различными путями. Не понял, это что, константация факта того, что управлять трафиком на ИП и МПЛС сетях невозможно?Или иллюстрация конкретной проблемной стройки? Тогда вопрос - а нафига то строили такое глючилово? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 12 января, 2009 · Жалоба Ответ, полученный в свое время от технарей РТ: "Не надо пинговать Juniper ! У него совсем другая архитектура и результат ping на его ядро непредсказуем и не коррелирует с поведением транзитного трафика." Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 12 января, 2009 · Жалоба Это правильно. Я на цисках тоже ограничения на control-plane делаю, чтобы не запинговывали. Да и ответ на пинг софтовый маршрутизатор шлёт в последнюю очередь. По ответам можно хоть о загрузке проца судить, а на хардовых так это вовсе не показатель - пакетики он форвардит вообще без использования центрального процессора. Так что пинг - вообще не показатель ничего, даже и серверы можно настроить весьма продвинуто. :))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LionSprings Опубликовано 12 января, 2009 · Жалоба Так что пинг - вообще не показатель ничего, даже и серверы можно настроить весьма продвинуто. :)))Аха, научите - как настроить сервер так, что б если пинг идет через ТТК - то они нормально отвечают, а если через РТ - то теряют ответы и тормозят. По моему, пинг до самих рутеров РТ вообще никого не волнует, по большому счету. Волнует пинг до хостов, к которым пакет идет через РТ транзитом. Тут уж никакой архитектурой не отделаешься, разве что архитектурой рук по отношению к голове и жопе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Paxton Опубликовано 12 января, 2009 · Жалоба Превед Paxton!Ну и теперь в очередной раз убеди нас, что это был единственно верный дизайн, аи-яй-яй ;) Есть мнение, что к современной сети РТ слово "дизайн" не применимо :) может хватит?трейсы покажите! Вам даже комерсы скажут где трабл :) Какие трейсы? У РТ MPLS ядро скрыто. То бишь TTL в IP пакетах на P маршрутизаторах не изменяется. Насколько помню, между УАКами лежат RSVP туннели (full mesh), даже не по одному, а по несколько штук с помощью явного задания strict-loose узлов, через которые должен идти траф конкретного туннеля. Поэтому траф в один и тот же destination может идти разными путями. Ессно на разных участках загрузка каналов разная, поэтому где-то суровые дропы, где-то попроще. Предполагаю, даже в нормальное время с разных source ip к одному и тому же dest ip должен наблюдаться разный RTT - когда траф идет различными путями. Не понял, это что, константация факта того, что управлять трафиком на ИП и МПЛС сетях невозможно?Или иллюстрация конкретной проблемной стройки? Тогда вопрос - а нафига то строили такое глючилово? Это констатация того, что кроме ИП и МПЛС нужно иметь нормальное администрирование и capacity planning. Какой бы ни был инжиниринг трафика, он не поможет передать 25 Гбит/c через 10GE интерфейс :) Ответ, полученный в свое время от технарей РТ:"Не надо пинговать Juniper ! У него совсем другая архитектура и результат ping на его ядро непредсказуем и не коррелирует с поведением транзитного трафика." Что в общем и целом верно. Особенно если оно вращает несколько full-view BGP. Кстати, если у кого проблемы у РТ в ЮФО, то там, говорят, еще и GSR глючит при балансировке - в один канал пакеты отправляет, а в другой - дропает. Так что пусть там дежурная смена сделает clear ip cef. Это, как говорится, ОБС. Аффтар к сети РТ никакого отношения не имеет :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kirya Опубликовано 12 января, 2009 · Жалоба Ответ, полученный в свое время от технарей РТ:"Не надо пинговать Juniper ! У него совсем другая архитектура и результат ping на его ядро непредсказуем и не коррелирует с поведением транзитного трафика." А RETN-а вся сеть на Juna-х и нормально пингается.Что же они делают не так ? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
evd Опубликовано 12 января, 2009 · Жалоба Ответ, полученный в свое время от технарей РТ:"Не надо пинговать Juniper ! У него совсем другая архитектура и результат ping на его ядро непредсказуем и не коррелирует с поведением транзитного трафика." Что в общем и целом верно. Особенно если оно вращает несколько full-view BGP. Что RE Джуни вращает внутри себя - значения не имеет. Rate-limit на генерацию icmp в Juniper'е работает на несколько другом уровне. Ни к загрузке routing engine, ни, тем более, к загрузке forwarding engine это не имеет никакого отношения А в общем и целом согласен: выводы из результатов пингов транзитных железок в большей степени зависят от компетентности пингующего, нежели от загрузки каналов ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Клава Маус Опубликовано 12 января, 2009 · Жалоба У РЕТНа сеть, как слоенный пирог. Есть специальный слой для скоростных пингов и прямых трассировок. Чтобы все видели уникальные показатели сети. Есть слои для паблик трафика, есть слои для торонтов и прочего ГК, есть слои для спец сигнализации и приоритетных клиентов. А связаны слои очень хитрыми шнягами, произведенными в самой воюющей стране мира по специальному заказу. На РЕТН работает один из самых классных связных номерных ящиков современной России с привлечением спецов со всего мира. Ростелеком о таких шнягах не только не знает, но, даже узнав, не сможет их применить, т.к. попадет под ограничения КАКОМ, т.к. в его истории слишком велики роли Ф.Э.Дзержинского и И.В.Сталина. Вот так. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kirya Опубликовано 12 января, 2009 · Жалоба Чёрт. А Феликс Эдмундович ещё и Наркомом путей сообщения был. Как дальше жить ? :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lip Опубликовано 12 января, 2009 · Жалоба Чёрт.А Феликс Эдмундович ещё и Наркомом путей сообщения был. Как дальше жить ? :( 5+А еще он беспризорников отлавливал (не в интернете). :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
chainick Опубликовано 12 января, 2009 · Жалоба Мля, а что опять с зарубедьем случилось, никто не в курсе? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 12 января, 2009 · Жалоба Трансы у нас упали, видимо перегруз... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fdimon Опубликовано 12 января, 2009 (изменено) · Жалоба Похоже глобальная проблема. Опять где то в Финляндии. Наверно брятья славяне перекрыли за газ. Изменено 12 января, 2009 пользователем fdimon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AntZ Опубликовано 12 января, 2009 · Жалоба есть такое... Похоже, у голдентелекома наблюдаются проблемы на стыке в Стокгольме. Поменялся адрес роутера на стыке в Стокгольме, начались потери Старты не признаются, однако трафик до ламлайта и коджента вместо линкса пошел через ретн... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
chainick Опубликовано 12 января, 2009 · Жалоба У меня теперь FV выглядит так: Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd ххх 4 3216 9097046 188696 24334939 3 0 1w2d 10110 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kirya Опубликовано 12 января, 2009 · Жалоба Трансы у нас упали, видимо перегруз...Падение одной из семи наших лямбд в регионы на 20 мин такие эффекты вызывает ?Дак это получается, что субж даже как backup использовать нельзя. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 12 января, 2009 · Жалоба Лямбда может и поднялась, а вот трафика так и нет. Совсем уже все препенды и коммунити снял, а трафика хорошо если 30% от былого... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
chainick Опубликовано 12 января, 2009 · Жалоба голден вообще глобально упал, а на рткоме 90% потерь. я такую жесть первый раз вижу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Paxton Опубликовано 12 января, 2009 (изменено) · Жалоба Ответ, полученный в свое время от технарей РТ:"Не надо пинговать Juniper ! У него совсем другая архитектура и результат ping на его ядро непредсказуем и не коррелирует с поведением транзитного трафика." Что в общем и целом верно. Особенно если оно вращает несколько full-view BGP. Что RE Джуни вращает внутри себя - значения не имеет. Rate-limit на генерацию icmp в Juniper'е работает на несколько другом уровне. Ни к загрузке routing engine, ни, тем более, к загрузке forwarding engine это не имеет никакого отношения А в общем и целом согласен: выводы из результатов пингов транзитных железок в большей степени зависят от компетентности пингующего, нежели от загрузки каналов ;) Ratelimit пакеты только дропает, а значит повлиять может только на пакетлосс. А загруженный RE дает не столько пакетлосс, сколько джиттер. Из-за чего на показатели пингов нельзя ориентироваться, как на достоверный RTT доступа к ресурсам за маршрутизаторами. Изменено 12 января, 2009 пользователем Paxton Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kirya Опубликовано 12 января, 2009 · Жалоба Лямбда может и поднялась, а вот трафика так и нет.Совсем уже все препенды и коммунити снял, а трафика хорошо если 30% от былого... Наша сумма аплинков устанавливает исторический рекорд, но запас ещё есть, сумма российских пиров идет вниз.Отдача в регионы колеблется в пределах +/- 3%. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VAF Опубликовано 12 января, 2009 · Жалоба Проблема с кабелем рядом с Хельсинки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...