МТС, сервисы Яндекс, RuTube устали

МТС тут ни причём.

Просто на одном из его магистральных маршрутизаторах ТСПУ РКН повёл себя неадекватно, "зарубив" весь ИСХОДЯЩИЙ траффик. В попытке хоть что-то проанализировать.

По трассе видно отлично.

Подсеть 212.188.x - это несколько магистральных маршрутизаторов. Причём там по 2 адреса на подсеть. Маска 255.255.255.254.

На 150-м - всё норм, а вот на 142-м - как раз, похоже, ТСПУ и стоит. Вот там начинается "затык". Как при приёме пакета, так и отправки его на 145-й. В итоге пакет после обработки на 142-м узле еле добирается (и это ICMP-пакет, молчу про остальные) на 145-й, тот отправляет пакет обратно, его опять обрабатывает 142-й узел - и жопа. Двойная обработка туда-сюда - таймаут.

В итоге однозначно можно сказать - ТСПУ стоит на магистральном маршрутизаторе МТС с адресом 212.188.2.142.

Вот его и "глючит".

Видимо, в роскомпозоре совсем не умеют считать магистральную нагрузку.

Ну что поделать их коробочка не справилась с магистральным трафиком.

МТС тут каким боком?

Это именно роскомнадзор сказал, что проблема произошла у одного из провайдеров на магистральной сети. А откуда он об этом знает? Да оттуда и знает, что сам создал эту проблему.

ппц! какой же у тебя в голове шлак.
icmp 145 отправляет обратно 142 - блять! да что за грибы ты жрёшь?

это даже круче, чем предыдущий шедевр про текстовый HTTP

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

Traceroute использует icmp с TTL.

Для первого узла TTL=1.

Он вернёт пакет с "time exceeded in transit".

И так далее, по увеличению TTL - Time To Live.

Обратное сообщение не факт, что пойдёт по тому же маршруту. Но практика показывает - вернут по тому же маршруту.

Это позволяет выявить "точку непринятия" пакета.

Короче - мы отправляем пакет с увеличивающимся TTL. И смотрим время возврата пакета из-за истечения количества HOP-ов. На каждом HOPе TTL убывает на единицу, при достижении нуля - отправителю отправляется вышеуказанное сообщение - "объект-получатель не может быть достигнут из-за истечения TTL"

Что не так?

тоже в своём роде шедевр!

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

ипать ты трудный.

Слышь, линупсоид-красноглазик.

Мне нахуя man курить, если OSI у меня в крови.

И мне пох, с какой ОС трейсить?

Я вообще привёл трассу с роутера, у которого своя ось. Даже близко не линупс или фряха.

Принцип один. Именно ICMP - сам покури man darpa - а потом выёбывайся.

Суть трассы - ICMP-пакеты с увеличивающимся TTL.

Если будут проблемы - ошибка пойдёт ПО ТОМУ ЖЕ МАРШРУТУ назад.

Да. Это не декларировано. Но именно так и работает.

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

2. ну ты же не на столько тупой, чтобы не погуглить как работает трасировка в linux (а значит и в твоём маршрутизаторе), да?
или гуглом пользоваться не научился?
проблемы с английским?
воспользуйся онлайн-переводчиком - всё же просто.
нужно просто прочитать.

или это такая крайняя степень упёртости, как в случае с текстовым HTTP?
типа "я где-то слышал", а значит так оно и есть,
читать, осмысливать и признавать отказываюсь!
у меня OSI в крови, а маны пишут идиоты!

Ты достал. Чесслово