Перейти к содержимому
Калькуляторы

Флуд (Было: Проблемы связанности у Ростелеком) С первоначальным топиком тема связана уже мало

если у вас прибыло, значит у кого-то убыло :)
Наверное у нас убыло.

До 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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

может хватит?

трейсы покажите! Вам даже комерсы скажут где трабл :)

Какие трейсы? У РТ MPLS ядро скрыто. То бишь TTL в IP пакетах на P маршрутизаторах не изменяется.

Насколько помню, между УАКами лежат RSVP туннели (full mesh), даже не по одному, а по несколько штук с помощью явного задания strict-loose узлов, через которые должен идти траф конкретного туннеля. Поэтому траф в один и тот же destination может идти разными путями.

Ессно на разных участках загрузка каналов разная, поэтому где-то суровые дропы, где-то попроще.

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

Изменено пользователем Paxton

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот что значит NGN сети? Это когда глючит, но не можешь понять где! :-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Превед Paxton!

Ну и теперь в очередной раз убеди нас, что это был единственно верный дизайн, аи-яй-яй ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

может хватит?

трейсы покажите! Вам даже комерсы скажут где трабл :)

Какие трейсы? У РТ MPLS ядро скрыто. То бишь TTL в IP пакетах на P маршрутизаторах не изменяется.

Насколько помню, между УАКами лежат RSVP туннели (full mesh), даже не по одному, а по несколько штук с помощью явного задания strict-loose узлов, через которые должен идти траф конкретного туннеля. Поэтому траф в один и тот же destination может идти разными путями.

Ессно на разных участках загрузка каналов разная, поэтому где-то суровые дропы, где-то попроще.

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

Не понял, это что, константация факта того, что управлять трафиком на ИП и МПЛС сетях невозможно?

Или иллюстрация конкретной проблемной стройки?

Тогда вопрос - а нафига то строили такое глючилово?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ответ, полученный в свое время от технарей РТ:

"Не надо пинговать Juniper !

У него совсем другая архитектура и результат ping на его ядро непредсказуем и не коррелирует с поведением транзитного трафика."

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это правильно.

Я на цисках тоже ограничения на control-plane делаю, чтобы не запинговывали.

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

 

Так что пинг - вообще не показатель ничего, даже и серверы можно настроить весьма продвинуто. :)))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так что пинг - вообще не показатель ничего, даже и серверы можно настроить весьма продвинуто. :)))
Аха, научите - как настроить сервер так, что б если пинг идет через ТТК - то они нормально отвечают, а если через РТ - то теряют ответы и тормозят.

По моему, пинг до самих рутеров РТ вообще никого не волнует, по большому счету. Волнует пинг до хостов, к которым пакет идет через РТ транзитом. Тут уж никакой архитектурой не отделаешься, разве что архитектурой рук по отношению к голове и жопе.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Превед 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. Это, как говорится, ОБС. Аффтар к сети РТ никакого отношения не имеет :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ответ, полученный в свое время от технарей РТ:

"Не надо пинговать Juniper !

У него совсем другая архитектура и результат ping на его ядро непредсказуем и не коррелирует с поведением транзитного трафика."

А RETN-а вся сеть на Juna-х и нормально пингается.

Что же они делают не так ? :)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ответ, полученный в свое время от технарей РТ:

"Не надо пинговать Juniper !

У него совсем другая архитектура и результат ping на его ядро непредсказуем и не коррелирует с поведением транзитного трафика."

Что в общем и целом верно. Особенно если оно вращает несколько full-view BGP.

Что RE Джуни вращает внутри себя - значения не имеет. Rate-limit на генерацию icmp в Juniper'е работает на несколько другом уровне. Ни к загрузке routing engine, ни, тем более, к загрузке forwarding engine это не имеет никакого отношения

 

А в общем и целом согласен: выводы из результатов пингов транзитных железок в большей степени зависят от компетентности пингующего, нежели от загрузки каналов ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У РЕТНа сеть, как слоенный пирог. Есть специальный слой для скоростных пингов и прямых трассировок. Чтобы все видели уникальные показатели сети. Есть слои для паблик трафика, есть слои для торонтов и прочего ГК, есть слои для спец сигнализации и приоритетных клиентов. А связаны слои очень хитрыми шнягами, произведенными в самой воюющей стране мира по специальному заказу. На РЕТН работает один из самых классных связных номерных ящиков современной России с привлечением спецов со всего мира. Ростелеком о таких шнягах не только не знает, но, даже узнав, не сможет их применить, т.к. попадет под ограничения КАКОМ, т.к. в его истории слишком велики роли Ф.Э.Дзержинского и И.В.Сталина.

Вот так.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Чёрт.

А Феликс Эдмундович ещё и Наркомом путей сообщения был.

Как дальше жить ? :(

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Чёрт.

А Феликс Эдмундович ещё и Наркомом путей сообщения был.

Как дальше жить ? :(

5+

А еще он беспризорников отлавливал (не в интернете). :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Мля, а что опять с зарубедьем случилось, никто не в курсе?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Трансы у нас упали, видимо перегруз...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Похоже глобальная проблема.

Опять где то в Финляндии.

Наверно брятья славяне перекрыли за газ.

Изменено пользователем fdimon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

есть такое...

Похоже, у голдентелекома наблюдаются проблемы на стыке в Стокгольме.

Поменялся адрес роутера на стыке в Стокгольме, начались потери

Старты не признаются, однако трафик до ламлайта и коджента вместо линкса пошел через ретн...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня теперь FV выглядит так:

 

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
ххх                4  3216 9097046  188696 24334939    3    0 1w2d        10110

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Трансы у нас упали, видимо перегруз...
Падение одной из семи наших лямбд в регионы на 20 мин такие эффекты вызывает ?

Дак это получается, что субж даже как backup использовать нельзя. :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Лямбда может и поднялась, а вот трафика так и нет.

Совсем уже все препенды и коммунити снял, а трафика хорошо если 30% от былого...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

голден вообще глобально упал, а на рткоме 90% потерь.

 

я такую жесть первый раз вижу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ответ, полученный в свое время от технарей РТ:

"Не надо пинговать Juniper !

У него совсем другая архитектура и результат ping на его ядро непредсказуем и не коррелирует с поведением транзитного трафика."

Что в общем и целом верно. Особенно если оно вращает несколько full-view BGP.

Что RE Джуни вращает внутри себя - значения не имеет. Rate-limit на генерацию icmp в Juniper'е работает на несколько другом уровне. Ни к загрузке routing engine, ни, тем более, к загрузке forwarding engine это не имеет никакого отношения

 

А в общем и целом согласен: выводы из результатов пингов транзитных железок в большей степени зависят от компетентности пингующего, нежели от загрузки каналов ;)

Ratelimit пакеты только дропает, а значит повлиять может только на пакетлосс.

А загруженный RE дает не столько пакетлосс, сколько джиттер. Из-за чего на показатели пингов нельзя ориентироваться, как на достоверный RTT доступа к ресурсам за маршрутизаторами.

Изменено пользователем Paxton

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Лямбда может и поднялась, а вот трафика так и нет.

Совсем уже все препенды и коммунити снял, а трафика хорошо если 30% от былого...

Наша сумма аплинков устанавливает исторический рекорд, но запас ещё есть, сумма российских пиров идет вниз.

Отдача в регионы колеблется в пределах +/- 3%.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Проблема с кабелем рядом с Хельсинки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.