Юрист

Пользователи
  • Публикаций

    7
  • Зарегистрирован

  • Посещение

Репутация

5 Обычный

Информация о Юрист

Информация

  • Пол
    Мужчина
  • Район
    Ховрино

ОнЛайм

  • Абонент ОнЛайм
    Да

Посетители профиля

1 271 просмотр профиля
  1. У Вас очень странная топология домашнего сегмента. Смысл её мне не вполне понятен. Зачем Вам нужен коммутатор к которому одновременно подключены маршрутизатор и приставка? В любом случае, коммутатор обычно является пассивным сетевым устройством (он не изменяет проходящие через него пакеты) поэтому даже если его интерфейсы и имеют MAC адреса, но провайдеру они не видны. А большинство коммутаторов таких адресов вовсе не имеет. Если не считать такими адресами последние 6 байтов идентификатора моста в заголовке STP.
  2. Вы правы, такая точка зрения тоже имеет право на существование. Я обычно так рассуждаю когда вижу, скажем, рентгеновский снимок: "там всё равно ничего не поймешь, людей много и внутри у них всё разное". Позволю только напомнить, что все методы сетевой диагностики базируются на icmp (не надо приводить мне примеры вроде сетевых сканеров, они создавались не для диагностики). Он относится к наинизшему, сетевому уровню стека протоколов TCP/IP и принципиально необходим для работы сети Интернет. Сами же постоянно просите в темах о проблемах с интернетом выполнить ping или трассировку. .
  3. Не знаю какие маршрутизаторы МГТС ставит сейчас, но по крайней мере раньше можно было перевести их в режим моста и спокойно про них навсегда забыть. Если, конечно, есть собственный маршрутизатор.
  4. Эта точка зрения, к сожалению, не соответствует действительности. Во-первых, у Вас сама фраза сформулирована неудачно. Речь идет не о потере пакетов, а об отсутствии icmp пакета "TTL expired" при уменьшении TTL тестового пакета до нуля. Во-вторых, обратите внимание, от узла в части случаев поступает этот ответ при отбрасывании пакета. Почему он не приходит в остальных случаях? Значит либо узел не получил тестовый пакет, либо не сгенерировал ответ на исчерпание TTL, либо этот ответ был утерял на одном из обратных переходов. В данном случае первый и последний варианты отпадают сразу, остается вариант, что узел в части случаев посылает icmp, а в других случаях этого не делает. Но мы же не можем предположить, что ответ генерируется с какой-то заранее заданной вероятностью, верно? Значит есть какая-то объективная причина. Почти со 100% вероятностью это перегрузка чего-то. Процессора этого узла, коммутационной матрицы, каналов связи, интерфейсов - неважно. Вы можете произвести мониторинг потерь на этом узле и я Вам гарантирую, что сможете установить зависимость процента потерь от времени суток, дня недели и каких-то заметных событий в сети. Произошло что-то экстраординарное, люди бросаются искать информацию в сети, растет процент потерь. Если мы можем с большой долей уверенности говорить о том, что узел чрезмерно загружен, это обычно проявляется также и в росте задержек прохождения пакетов на этом узле. И для того чтобы предположить такие задержки процент потерь даже лучший показатель, чем собственно время отклика. Отклик генерируется локально, чтобы его отправить может потребоваться гораздо меньше времени, чем на маршрутизацию пакета между интерфейсами. И так далее. Так что говорить о том, что процент потерь на промежуточных переходах не имеет значения, принципиально неверно. Значение оно имеет, хотя и не то, которое ему иногда могут придавать (в стиле "я отправил 300 пакетов и получил 200 ответов, значит 33% пакетов на узле теряется").