Jump to content
Калькуляторы

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

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

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

 

Share this post


Link to post
Share on other sites
может хватит?

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

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

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

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

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

Edited by Paxton

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Превед Paxton!

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

Share this post


Link to post
Share on other sites
может хватит?

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

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

Share this post


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

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

 

Share this post


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

Share this post


Link to post
Share on other sites
Ответ, полученный в свое время от технарей РТ:

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

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

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

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

 

Share this post


Link to post
Share on other sites
Ответ, полученный в свое время от технарей РТ:

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

Вот так.

Share this post


Link to post
Share on other sites

Чёрт.

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

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

Share this post


Link to post
Share on other sites
Чёрт.

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

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

5+

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

Edited by fdimon

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

 

Share this post


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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites
Ответ, полученный в свое время от технарей РТ:

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

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

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

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

 

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

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

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

Edited by Paxton

Share this post


Link to post
Share on other sites
Лямбда может и поднялась, а вот трафика так и нет.

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this