Привет, ребят! Вопрос такой есть: текстовые версии видео актуальны? Я в любом случае готовлю текстовый сценарий, вопрос только насколько сильно приходится пыхтеть над его оформлением.
Приветствую! Прошу разъяснить вопрос для начинающего. Выходит, что в процессе пингов через транзитные узлы в работу вступают модули, если так можно сказать, программы, развёрнутые на базе роутеров (маршрутизаторов). То есть проходящий МИМО них пакет ICMP запроса они разворачивают, копаются в нём, находят нужную им информацию, после чего ЗАНОВО формируют пакет на отправку с телом ОБЯЗАТЕЛЬНО равным изначальному пришедшему телу (уровня ICMP) но с другим заголовком уровня назначения источника и получателя по MAC? То есть фактически при нарушениях в линии связи между роутером RO1 и RO2 (битая линия или наводки из-за чего изменения пришлись, например, на часть запроса, связанного с ICMP), RO2 как получатель не сможет разобрать пришедшую околесицу и ИМЕННО поэтому пинг не дойдет до получателя, а не потому что в конечный узел пришла чушь и он её не понял? Итого 2 вопроса о том, не меняется ли составляющая ICMP запроса от роутера к роутеру и есть на уровне операционки роутеров программа PING или ICMP, разбирающая проходящие мимо неё пакеты, или это как-то иначе исполнено?
Я вопрос не совсем понял. Если речь про логику работы на L3 и при условии что нет никаких ACL/политик, то роутер не будет никак анализировать, что вложено в IP-пакет. Он посмотрит поля TTL и dst ip и пошлет этот пакет дальше, если TTL не обнулится и если у него есть маршрут до destination ip. Ничего заново не формируется с точки зрения IP. "но с другим заголовком уровня назначения источника и получателя по MAC?" Да, чтобы переложить пакет из одной подсети в другую, роутер меняет мак-адреса. Убеждается, что в полученном пакете стоит его мак-адрес, а когда послыает дальше, то в качестве src mac подставляет адрес своего исходящего интерфейса, а в качестве dst мака использует адрес следующего по пути узла. Для отработки ситуаций с ошибками и коллизиями уже на уровне Ethernet есть контрольные суммы, если они не сходятся, кадр уничтожается на том узле, где контрольная сумма не сошлась, соответственно, и все что вложено внутрь кадра уничтожается. В общем случае проходящий через роутер пакет не изменяется, но можно создать политики, которые будут анализировать ICMP и изменять их или дропать, или любое другое действие с ними делать, которое позволяет железо и операционная система роутера
Я правильно понимаю, что при самых первых пингах пакеты потерялись, потому что работал протокол арп у отправителя просто истек таймер ожидания ответа или есть какие-то еще причины? Можешь пояснить за счет чего роутер передает пакеты между разными сетями?
Да, правильно, других причин нет. По поводу второго вопроса. Пакет никак не изменяется при переходе, когда роутер его передает из одной канальной среды в другую, изменения есть на канальном уровне. Пакет всегда запаковывается в кадр канального уровня и когда, пусть это будет Ethernet. У кадра есть src mac и dst mac. Когда кадр пришел в роутер у него в поле src был записан мак-адрес соседа который этот кадр отправил, а в поле dst был записан мак роутера, которые его получил, если роутер видит, что IP-пакет надо слать дальше, он формирует новый кадр, в который запихивает пакет, в поле src mac этого кадра они пишет свой мак, в поле dst они пишет мак получателя, который был изучен через ARP. Это если коротко, будет отдельное видео на эту тему.
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
Спасибо за видео !!! Комент для продвижения
Привет! Спасибо за поддержку!
Текстовая версия: pikabu.ru/story/vidyi_ustroystv_v_ip_khostyi_i_routeryi_chast_2_11342880
Привет, ребят! Вопрос такой есть: текстовые версии видео актуальны? Я в любом случае готовлю текстовый сценарий, вопрос только насколько сильно приходится пыхтеть над его оформлением.
На мой взгляд текстовая версия нужна, но также очень нужны таймкоды на видео, чтобы было просче пересмотреть нужное место
Привет! Уточнить хочу по тайм-кодам, тех что сейчас пишу недостаточно? Или они у тебя не отображаются?
@@N_G-yy6xh привет, извини, не заметил описание к видео, а там оказывается все есть. Тогда все отлично, спасибо за труд!
Приветствую! Прошу разъяснить вопрос для начинающего. Выходит, что в процессе пингов через транзитные узлы в работу вступают модули, если так можно сказать, программы, развёрнутые на базе роутеров (маршрутизаторов). То есть проходящий МИМО них пакет ICMP запроса они разворачивают, копаются в нём, находят нужную им информацию, после чего ЗАНОВО формируют пакет на отправку с телом ОБЯЗАТЕЛЬНО равным изначальному пришедшему телу (уровня ICMP) но с другим заголовком уровня назначения источника и получателя по MAC? То есть фактически при нарушениях в линии связи между роутером RO1 и RO2 (битая линия или наводки из-за чего изменения пришлись, например, на часть запроса, связанного с ICMP), RO2 как получатель не сможет разобрать пришедшую околесицу и ИМЕННО поэтому пинг не дойдет до получателя, а не потому что в конечный узел пришла чушь и он её не понял? Итого 2 вопроса о том, не меняется ли составляющая ICMP запроса от роутера к роутеру и есть на уровне операционки роутеров программа PING или ICMP, разбирающая проходящие мимо неё пакеты, или это как-то иначе исполнено?
Я вопрос не совсем понял. Если речь про логику работы на L3 и при условии что нет никаких ACL/политик, то роутер не будет никак анализировать, что вложено в IP-пакет. Он посмотрит поля TTL и dst ip и пошлет этот пакет дальше, если TTL не обнулится и если у него есть маршрут до destination ip. Ничего заново не формируется с точки зрения IP.
"но с другим заголовком уровня назначения источника и получателя по MAC?"
Да, чтобы переложить пакет из одной подсети в другую, роутер меняет мак-адреса. Убеждается, что в полученном пакете стоит его мак-адрес, а когда послыает дальше, то в качестве src mac подставляет адрес своего исходящего интерфейса, а в качестве dst мака использует адрес следующего по пути узла.
Для отработки ситуаций с ошибками и коллизиями уже на уровне Ethernet есть контрольные суммы, если они не сходятся, кадр уничтожается на том узле, где контрольная сумма не сошлась, соответственно, и все что вложено внутрь кадра уничтожается.
В общем случае проходящий через роутер пакет не изменяется, но можно создать политики, которые будут анализировать ICMP и изменять их или дропать, или любое другое действие с ними делать, которое позволяет железо и операционная система роутера
Я правильно понимаю, что при самых первых пингах пакеты потерялись, потому что работал протокол арп у отправителя просто истек таймер ожидания ответа или есть какие-то еще причины? Можешь пояснить за счет чего роутер передает пакеты между разными сетями?
Да, правильно, других причин нет.
По поводу второго вопроса. Пакет никак не изменяется при переходе, когда роутер его передает из одной канальной среды в другую, изменения есть на канальном уровне. Пакет всегда запаковывается в кадр канального уровня и когда, пусть это будет Ethernet. У кадра есть src mac и dst mac. Когда кадр пришел в роутер у него в поле src был записан мак-адрес соседа который этот кадр отправил, а в поле dst был записан мак роутера, которые его получил, если роутер видит, что IP-пакет надо слать дальше, он формирует новый кадр, в который запихивает пакет, в поле src mac этого кадра они пишет свой мак, в поле dst они пишет мак получателя, который был изучен через ARP. Это если коротко, будет отдельное видео на эту тему.
@@N_G-yy6xh Спасибо!🙏
Спасибо за видео!