Comments 32
Стиль бодрый, автор молодец!
«SA (Source Address) – MAC адрес отправителя. Всегда юникаст.» — может, «всегда должен быть юникаст»?
Мой вариант вполне допустим. А вот конструкция с «должен быть», в данном контексте, звучит как машинный перевод с английского.
Хм. Возможно. Но учитывая, что в сеть можно отправить любую ересь, это хороший вопрос «Всегда юникаст» и «Должен быть юникаст». Потому как при «всегда юникаст» кто-то может начать рассчитывать на это зазря.
увы, но нет.
Есть разница между «всегда юникаст, потому что протокол устроен так, что другого не сунешь» и «всегда юникаст, потому что туда всегда пишут юникаст и если засунуть мультикаст, то непонятно как интерпретировать»
Есть разница между «всегда юникаст, потому что протокол устроен так, что другого не сунешь» и «всегда юникаст, потому что туда всегда пишут юникаст и если засунуть мультикаст, то непонятно как интерпретировать»
Может я промаргал, но есть ли в Ethernet коды ИСПРАВЛЯЮЩИЕ ошибки или только FCS, которое, как я правильно понял автора, лишь ОБНАРУЖИВАЮТ ошибки, но не исправляют их.
Если нет, то получается надёжность и скорость Ethernet каналов такова, что дешевле переслать кадр, чем заниматься ECC кодированием.
Если нет, то получается надёжность и скорость Ethernet каналов такова, что дешевле переслать кадр, чем заниматься ECC кодированием.
Это общее явление во всех системах связи. Дело в том, что любой код, работающий в режиме обнаружения ошибок, является примерно в два раза более устойчивым к этим самым ошибкам, чем он же, но работающий в режиме коррекции.
Так, код Хемминга способен скорректировать всего одну ошибку — но если отказаться от коррекции, то он сможет обнаружить две. Если же использовать модификацию, способную обнаруживать парные ошибки — то в режиме чистого обнаружения она сможет обнаружить тройные ошибки.
Как следствие, при достаточной надежности канала связи получается куда дешевле повторно отправлять битые пакеты, чем корректировать их.
Так, код Хемминга способен скорректировать всего одну ошибку — но если отказаться от коррекции, то он сможет обнаружить две. Если же использовать модификацию, способную обнаруживать парные ошибки — то в режиме чистого обнаружения она сможет обнаружить тройные ошибки.
Как следствие, при достаточной надежности канала связи получается куда дешевле повторно отправлять битые пакеты, чем корректировать их.
Мне всегда было любопытно, можно ли гонять 802.1q (это Ethernet II фрейм в котором EtherType=0x8100) c проставленными VLAN ID=1 и что будет с такими фреймами?
UFO just landed and posted this here
Можно, я сам их гонял на лабораторной работе. Вот с VLAN 0 ситуация хуже — у половины коммутаторов такой VLAN является служебным, означая отсутствие тэга, а у другой половины он является вполне рабочим.
(Под «половиной» коммутаторов я понимаю три из шести находящихся в лаборатории сетевых технологий кафедры ЭВМ ЮУрГУ)
(Под «половиной» коммутаторов я понимаю три из шести находящихся в лаборатории сетевых технологий кафедры ЭВМ ЮУрГУ)
Собственно, а почему бы и нет? Главное, чтобы коммутатор переваривал vlan 1 в качестве trunk на порту.
С dot1q обычно другая картина — его пытаются пропихнуть в обычный access-порт с задранным mtu. Вот тут уже интересней
С dot1q обычно другая картина — его пытаются пропихнуть в обычный access-порт с задранным mtu. Вот тут уже интересней
iSCSI и FCoE понятно. А что такое NSF?
А что такое SFD, которое отделилось от Preamble, начиная с рисунка 2?
На практике же Jumbo фрейм обычно ограничен размером в 9126 байт (на более старом железе в 8092 байт).
Ни разу не встречал 9126 — это особенность Cisco? А как же 9014 и 16128? Последние уже даже в datasheet'ах пишут к PHY микросхемам.
Опс, 9216 байт, и не Jumbo фрейм, а Jumbo MTU — исправлю в тексте. Да, это у Cisco, встречал ещё у них jumbo MTU ровно 9000, которые и дадут размер фрейма в 9014. 16128 не встречал. Сейчас погуглил и увидел, что Интеловские карточки поддерживают. Попробую выяснить как обходится ограничение с CRC, и добавлю к топику.
"… или же с рукавом, который можно использовать для оптимизации женской анатомии. "
Смеялсо очень, хотя, вроде бы банальность. Не часто такие перлы в технических статьях встретишь. Вкупе с доступностью изложения это меня покорило.
Как там говорили, в лихие нулевые… Афтар, пешы исчо.
Смеялсо очень, хотя, вроде бы банальность. Не часто такие перлы в технических статьях встретишь. Вкупе с доступностью изложения это меня покорило.
Как там говорили, в лихие нулевые… Афтар, пешы исчо.
Было любопытно, приобретая современную сетевую карту, какой стандарт она будет использовать для отправки кадров? Примет ли она ответный кадр в любом стандарте?
Интересно: если формат DIX обходится без длины кадра, то как он определяет, что кадр кончился? На сколько я помню, если вышестоящий кадр меньше 46 байт, то он будет дополнен заполнителем. Как узнать сколько такого заполнителя прилетело?
И ещё более интересно — если без длины можно обойтись, то зачем её впендюрили в SNAP?
И ещё более интересно — если без длины можно обойтись, то зачем её впендюрили в SNAP?
На уровне кодирования Ethernet есть символы начала и конца кадра.
Заполнять кадр до 64 байт требуется от источника, т. е. если ниже это просто нестандартно и может быть не принято на стандартном оборудовании.
Некоторые устройства умеют принимать такие кадры.
Заполнять кадр до 64 байт требуется от источника, т. е. если ниже это просто нестандартно и может быть не принято на стандартном оборудовании.
Некоторые устройства умеют принимать такие кадры.
Ну допустим — конец кадра Ethernet мы услышим (хотя «символа конца кадра» там, кажется нет). Но если в payload лежал пакет длинной 1 байт — как мы это узнаем? Он ведь был дополнен до 46. Как мы узнаем, что он был именно один?
А если у нас есть способ это узнать, то зачем нужно длину выносить в отдельное поле Length?
А если у нас есть способ это узнать, то зачем нужно длину выносить в отдельное поле Length?
В 100Мб Ethernet'е символы можно посмотреть здесь: JK — старт, TR — конец.
Если брать формат LLC, то дополнение на поле размера не влияет, если Ethernet II, то если необходимо передавать информацию о размере данных, это обязанность вышележащего протокола.
Если брать формат LLC, то дополнение на поле размера не влияет, если Ethernet II, то если необходимо передавать информацию о размере данных, это обязанность вышележащего протокола.
Да, точно JK и TR это какие-то выкидыши 100BASE-X. Остальным стандартам достаточно услышать, что наступила межкадровая пауза.
> если необходимо передавать информацию о размере данных, это обязанность вышележащего протокола
Так и начал подозревать. Не понятно только, почему в одном случае это делегировали на уровень выше, а в другом — сами решили разбираться.
> если необходимо передавать информацию о размере данных, это обязанность вышележащего протокола
Так и начал подозревать. Не понятно только, почему в одном случае это делегировали на уровень выше, а в другом — сами решили разбираться.
Насколько мне известно, по паузам работает только 10 мегабитный Ethernet, а последующие уже используют специальные контрольные символы.
> Не понятно только, почему в одном случае это делегировали на уровень выше, а в другом — сами решили разбираться.
Так вся статья про это — полустихийное формирование условий, которые потом просто увековечили в стандартах.
> Не понятно только, почему в одном случае это делегировали на уровень выше, а в другом — сами решили разбираться.
Так вся статья про это — полустихийное формирование условий, которые потом просто увековечили в стандартах.
«Встретить пакет с инкапсуляцией в формат фрейма 802.3 SNAP довольно легко и сейчас – это все протоколы семейства STP»
Нет. WireShark указывает, что для STP используется значение 0x42 в полях SSAP и DSAP. SNAP заголовка в пакетах он не усматривает. Если только для проприетарных реализаций.
Кстати, в статье не сказано, как машина отличает формат 802.3 LLC от SNAP. А всё дело в том, что xSAP заполняются магическими байтами 0xAA. Тем самым бездарно их просирая.
Не говоря ж и о том, что кодирование OUI в SNAP изначально избыточно, так как было придумано для множества серий MAC, принадлежащих одному производителю.
Нет. WireShark указывает, что для STP используется значение 0x42 в полях SSAP и DSAP. SNAP заголовка в пакетах он не усматривает. Если только для проприетарных реализаций.
Кстати, в статье не сказано, как машина отличает формат 802.3 LLC от SNAP. А всё дело в том, что xSAP заполняются магическими байтами 0xAA. Тем самым бездарно их просирая.
Не говоря ж и о том, что кодирование OUI в SNAP изначально избыточно, так как было придумано для множества серий MAC, принадлежащих одному производителю.
OUI нисколько не избыточно, это единственный способ формировать кадры проприетарных и тестовых протоколов, которые не пересекутся с другими.
На текущий момент за Cisco Systems зарегистрировано 935 OUI (только что подсчитал).
За каждый OUI может быть закодировано 64к протоколов (PID). Итого Cisco Systems может безболезненно разработать 61,2 млн. протоколов.
Всё-таки, ИМХО, это очень избыточно. Поле OUI могло бы быть сокращено на 1 байт (в каждом из триллиона пакетов ежедневно), если бы не поленились вести отдельный реестр разработчиков протоколов, где одному вендору соответствовал бы один (ну два!) кода.
За каждый OUI может быть закодировано 64к протоколов (PID). Итого Cisco Systems может безболезненно разработать 61,2 млн. протоколов.
Всё-таки, ИМХО, это очень избыточно. Поле OUI могло бы быть сокращено на 1 байт (в каждом из триллиона пакетов ежедневно), если бы не поленились вести отдельный реестр разработчиков протоколов, где одному вендору соответствовал бы один (ну два!) кода.
Sign up to leave a comment.
Всё, что вы хотели знать о Ethernet фреймах, но боялись спросить, и не зря