Comments 77
Спасибо, именно про домен коллизий нужно читать начинающим айтишникам. Куда же они без домена коллизий, да в сеть на коммутаторах сунутся? Расскажите ещё больше про коаксиал, хабы и особенности эксплуатации 10Мбит half-duplex интерфейсов.
Заметим, реально нужная и серьёзная часть (например, про типы оптики, особенности их кроссировок и возникающие специфичные для оптики проблемы) опущена на словах «а ещё, кроме антиквариата, там и нормальные сети бывают».
Заметим, реально нужная и серьёзная часть (например, про типы оптики, особенности их кроссировок и возникающие специфичные для оптики проблемы) опущена на словах «а ещё, кроме антиквариата, там и нормальные сети бывают».
amarao: Вы, конечно, человек на этом ресурсе известный и уважаемый, ethernet — одна из постоянно используемых Вами технологий, а хабы, домен коллизий и прочее — устаревшая рухлядь. Но! Не смотря на все это я с удовольствием прочитал статью siberianMan, т.к. пользоваться этой «устаревшей рухлядью» приходилось, но, что такое домен коллизий на столько ясно нигде обяснено небыло (особенно в те мохнатые годы). Возможно, это будет интересно и кому то еще. Если мой комментарий обижает — прошу прощения.
Я согласен с amarao. Если человек не знал написанного в топике, то ему и не стоит забивать себе голову терминами времен прошлого тысячелетия. У меня немало знакомых, уверенных, что коллизии — до сих пор бич ethernet сетей, и чтобы их не было, нужны обязательно управляемые свитчи или роутеры :) Ну и, конечно, любой отправленный одним компьютером пакет обязательно вылетит из всех портов.
В современном мире коллизий не существуют. В современном мире все хабы давно выкинуты на свалку. Точка. Иначе придется признать, что и IPX неплохо бы изучать всем подряд, с ним ведь тоже когда-то работали.
Соответственно, к статье есть одна серьезная претензия. В ней не сказано в явном виде, что ко всему в первой половине топика следует относиться как к историческому экскурсу, и что сейчас «домен коллизий» всегда содержит ровно два устройства, которые всегда передают данные в полнодуплексном режиме и потому не могут столкнуться с коллизией.
Или могут? Да, могут. Например, изначально на свитче и на подключенном у нему устройстве стояло автосогласование, согласовывалось на 100/full. А потом серверному админу пришло в голову, что надо бы жестко выставить 100/full, для надежности. Почему-то после этого сеть начала работать не пойми как, с дикими потерями… Да, это, пожалуй, единственный способ увидеть коллизии в современном мире. И про это автор ничего не рассказал.
В современном мире коллизий не существуют. В современном мире все хабы давно выкинуты на свалку. Точка. Иначе придется признать, что и IPX неплохо бы изучать всем подряд, с ним ведь тоже когда-то работали.
Соответственно, к статье есть одна серьезная претензия. В ней не сказано в явном виде, что ко всему в первой половине топика следует относиться как к историческому экскурсу, и что сейчас «домен коллизий» всегда содержит ровно два устройства, которые всегда передают данные в полнодуплексном режиме и потому не могут столкнуться с коллизией.
Или могут? Да, могут. Например, изначально на свитче и на подключенном у нему устройстве стояло автосогласование, согласовывалось на 100/full. А потом серверному админу пришло в голову, что надо бы жестко выставить 100/full, для надежности. Почему-то после этого сеть начала работать не пойми как, с дикими потерями… Да, это, пожалуй, единственный способ увидеть коллизии в современном мире. И про это автор ничего не рассказал.
UFO just landed and posted this here
Выше я привел рабочий способ получить коллизии. Однако, этот сценарий не имеет ничего общего с тем, что было раньше.
«Коллизии между двумя девайсами сейчас можно запросто получить превысив длину сегмента физической линии»
«А какое поле для «деятельности» в случае каскадирования коммутаторов, вы даже не представляете.»
Ну-ка с этих моментов поподробнее. Особенно «каскадирование коммутаторов» меня заинтересовало. Я вот не могу себе представить цепочку даже из сотни свитчей, в которой будут коллизии ;)
«Коллизии между двумя девайсами сейчас можно запросто получить превысив длину сегмента физической линии»
«А какое поле для «деятельности» в случае каскадирования коммутаторов, вы даже не представляете.»
Ну-ка с этих моментов поподробнее. Особенно «каскадирование коммутаторов» меня заинтересовало. Я вот не могу себе представить цепочку даже из сотни свитчей, в которой будут коллизии ;)
Ну как ни крути, а методы CSMA/CD являются частью технологии 802.3, думаю, если уж изучать стандарт, то нужно хотя бы общее представление иметь.
CSMA/CD лишь формально присутствует в гигабите, и его вообще нет в 10G и выше.
Изучать стандарт? Ну признаюсь: я отвратительно знаю, как работает L1 на витой паре. До данного топика даже примерно не представлял себе модуляцию сигнала в 100M/1G линках. Когда-то слышал про слово «преамбула», но смутно понимаю, что это.
Однако, я весьма хорошо знаю, как работать с L1, какие могут вылезти проблемы, как их обнаружить и устранить.
Да, я в курсе, что такое «коллизия», однако мне это никак не помогает. Фактически, единственное, что про них надо знать, это краткий алгоритм «видишь коллизии на порту => проверь speed и duplex с обеих сторон => проблема решена».
Изучать стандарт? Ну признаюсь: я отвратительно знаю, как работает L1 на витой паре. До данного топика даже примерно не представлял себе модуляцию сигнала в 100M/1G линках. Когда-то слышал про слово «преамбула», но смутно понимаю, что это.
Однако, я весьма хорошо знаю, как работать с L1, какие могут вылезти проблемы, как их обнаружить и устранить.
Да, я в курсе, что такое «коллизия», однако мне это никак не помогает. Фактически, единственное, что про них надо знать, это краткий алгоритм «видишь коллизии на порту => проверь speed и duplex с обеих сторон => проблема решена».
а потом вот такие «не нужно забивать голову коллизиями и прочим барахлом» прохвесиионалы лезут своими немытыми руками в Wi-Fi и удивляются, почему все так хреново работает…
Я плотно работаю с вайфайной инфраструктурой (угадайте какого вендора :) ). Работает она зашибись. Если бы она работала не зашибись, то была бы масса жалоб на работу массы вайфай телефонов. Они — ребята очень нежные по части качества сигнала.
А все потому, что для грамотной организации вайфай сети надо понимать, как она устроена (хотя я все никогда не интересовался методами кодирования), а езернет — «воткнул и поехали».
А все потому, что для грамотной организации вайфай сети надо понимать, как она устроена (хотя я все никогда не интересовался методами кодирования), а езернет — «воткнул и поехали».
«У меня немало знакомых, уверенных, что коллизии — до сих пор бич ethernet сетей».
Это действительно так (о распространенности мненеия), более того, это транслируется некоторой литературой. Хотя в Олиферах начала 2000 это все прекрасно расписано. И про сужение домена коллизий до порт-сетевая в случае свича и полудуплекса и разрешение ситуации в случае фулдуплекса.
Тут довелось позаниматься достаточно поверхностно темой индастриалезернета, так в относительно свежих специализированных статьях до сих пор пишут, что общий доступ к среде с контролем несущей и коллизии — это то, что мешает немодифицированному езернету активно использоваться на нижнем уровне АСУТП. Хотя давно есть EthernetIP и набор рекомендаций (не упоминаю про синхронные модфицикации езернета, речь об обычном), как на свичах строить нижний уровень при требованиях Soft RealTime. Ну там сегментация, сужение широковещательного домена, CoS, QoS и прочее.
Это действительно так (о распространенности мненеия), более того, это транслируется некоторой литературой. Хотя в Олиферах начала 2000 это все прекрасно расписано. И про сужение домена коллизий до порт-сетевая в случае свича и полудуплекса и разрешение ситуации в случае фулдуплекса.
Тут довелось позаниматься достаточно поверхностно темой индастриалезернета, так в относительно свежих специализированных статьях до сих пор пишут, что общий доступ к среде с контролем несущей и коллизии — это то, что мешает немодифицированному езернету активно использоваться на нижнем уровне АСУТП. Хотя давно есть EthernetIP и набор рекомендаций (не упоминаю про синхронные модфицикации езернета, речь об обычном), как на свичах строить нижний уровень при требованиях Soft RealTime. Ну там сегментация, сужение широковещательного домена, CoS, QoS и прочее.
Под рил-тайм есть специальные свитчи, с чертовски низким latency, с первоклассной приоритезацией отдельных видов трафика. Для Nexus 3000 заявляют менее 200нс. Есть конкурент от Arista, там около 500нс. Я как-то посчитал на калькуляторе, сколько метров оптического патч-корда дают такую же задержку, и сколько времени требуется для сериализации 1500-байтного пакета на 40G линке, и проникся безграничным уважением к разработчикам данных ASICов.
В основном оно предназначено для трейдеров — где иногда лишние 500 наносекунд задержки при передаче пакета крайне нежелательны.
В основном оно предназначено для трейдеров — где иногда лишние 500 наносекунд задержки при передаче пакета крайне нежелательны.
Это все рилтайм не какой надо рилтайм. Рилтайм это не скорость и не низкие задержки, рилтайм это гарантированность и изохронность. Какая-нибудь промшина старая со скоростью меньше мегабита будет рилтайм, а 1G или 10G пусть даже с задержками минимальными — нет. Максимум это будет SRT, но не IRT.
АСУ-шники за настоящий жесткий рилтайм считают только изохронные вещи. И эти реализации могут работать вообще без свичей, на разделямой среде в том числе, но коллизий там не будет за счет наличия мастера и четкой синхронизации всех устройств с выделением мастером четкого графика передачи для каждого устройства. Хотя да, при сбое синхронизации колллизии там возможны.
АСУ-шники за настоящий жесткий рилтайм считают только изохронные вещи. И эти реализации могут работать вообще без свичей, на разделямой среде в том числе, но коллизий там не будет за счет наличия мастера и четкой синхронизации всех устройств с выделением мастером четкого графика передачи для каждого устройства. Хотя да, при сбое синхронизации колллизии там возможны.
рилтайм это гарантированность и изохронность
Именно под это и делаются подобного класса свитчи.
Хотя в принципе любые свитчи с DCB и FCoE годятся под рилтайм. Ибо FCoE трафик очень чувствителен и к джиттеру, и к потерям. Ни при каких обстоятельствах не должно быть потерь.
Ну и сами понимаете — если некое приложение требует микросекундного RTT и за эти микросекунды прокачивает миллионы долларов, то, опять же, связь должна быть исключительно надежной и предсказуемой.
То, что вы написали — не поставят на управление системой с быстротекущими процессами, на самый нижний уровень, где исполнительные механизмы и контроллеры — это сфера синхронных промышленных шин или модифицированного езернет — так называемые IRT требования. А вот чуть выше, где тоже требования достаточно жесткие, но уже не смертельно, там где SCADA и еще что-то подобное — поставят.
Ключевые слова — Powerlink, EtherCAT, ProfiNET. Там модифицирован сам принцип классического езернета. В этих сетях не только гарантированный цикл доставки пакета от точки до точки, но и гарантированный цикл передачи для всех устройств в сети.
Если при правильно спроектированной сети на пусть даже прецезионных свичах, но обычного езернет — риск потерь можно минимизоровать максимально, одномастерная синхронная система их исключает на уровне дизайна, архитектуры и принципа работы протокола. Возможность потерь исчезает как класс. Ну, разве кроме ситуаций физической неисправности.
Ключевые слова — Powerlink, EtherCAT, ProfiNET. Там модифицирован сам принцип классического езернета. В этих сетях не только гарантированный цикл доставки пакета от точки до точки, но и гарантированный цикл передачи для всех устройств в сети.
Если при правильно спроектированной сети на пусть даже прецезионных свичах, но обычного езернет — риск потерь можно минимизоровать максимально, одномастерная синхронная система их исключает на уровне дизайна, архитектуры и принципа работы протокола. Возможность потерь исчезает как класс. Ну, разве кроме ситуаций физической неисправности.
обычного езернет — риск потерь можно минимизоровать максимально, одномастерная синхронная система их исключает на уровне дизайна, архитектуры и принципа работы протокола. Возможность потерь исчезает как класс.
Я не зря упоминал FCoE. Малейшие потери — и весь массив переходит в RO, вызывая дикую головную боль у администраторов. Современные ЦОДовые коммутаторы гарантируют доставку пакетов (в том числе FCoE) без потерь, для этого применено множество разных технологий. А та же 3000-я линейка нексусов вдобавок к этому еще и обеспечивает невероятно низкую задержку при передаче данных.
Нагуглите lossless ethernet.
И да, за последние несколько лет в этой области произошел заметный прогресс. Цискины каталисты например все до единого не годятся для беспотерьной передачи данных. А нексусы специально для этого и разрабатывали, такая вот у них архитектура.
Я охотно верю. Но факт есть факт. В АСУТП нижнерго уровня это не используют. Невероятно низкая задержка хорошо, но она не всегда нужна а автоматизации. Важнее дать «высказаться» каждому узлу сети ровно в необходимый момент времени. Даже если не будет никакой потери, но не будет выдержан график — катастрофа. Люди не зря придумали все эти модификации, хотя в момент их создания классический езрнет уже был намного быстрее. И индустриальные свичи существовали. Почитайте, как работает Powerlink хотя бы — поймете разницу. Это примерно как спорить, что линукс (оговорюсь — без спец-патчей) ОС реального времени потому, что запущенный на каком-нибудь мегаксеоне последнем он быстрее на порядки, чем QNX на первом пне. Быстрее, но дело не в этом.
lossless ethernet погуглю :)
lossless ethernet погуглю :)
Даже если не будет никакой потери, но не будет выдержан график — катастрофа.
Именно для этого и разрабатываются low-latency коммутаторы.
Еще раз: есть некие приложения, которые играют на том, что два других узла рассинхронизированы на несколько микросекунд. Им требуется мгновенная, гарантированная доставка пакетов и абсолютная синхронизация. Как и в случае ваших АСУТП. Точнее — в моем случае требования к качеству передачи данных куда выше, чем в вашем.
Указанные вами технологии используются по инерции — потому что их хватает, и надобности заменять их на что-то более совершенное нет.
Ремарка.
В промышленных сетях АСУТП (не во всех конечно, там где это необходимо) точность синхронизации (посредством PTP) — мньше 1 мкс. Вы меня убедили, что данный класс оборудования дает тот же самый результат и даже лучше. Вопрос только в том — что решение это своего рода брутфорс. В классических же АСУТП сетях это решение — архитектурное. Ваша линейка оборудования доросла до того, что бы обеспчивать losless? Здорово. Но АСУ изначально шло по пути изменения протокола и архитектуры.
В промышленных сетях АСУТП (не во всех конечно, там где это необходимо) точность синхронизации (посредством PTP) — мньше 1 мкс. Вы меня убедили, что данный класс оборудования дает тот же самый результат и даже лучше. Вопрос только в том — что решение это своего рода брутфорс. В классических же АСУТП сетях это решение — архитектурное. Ваша линейка оборудования доросла до того, что бы обеспчивать losless? Здорово. Но АСУ изначально шло по пути изменения протокола и архитектуры.
Вы поймите, езрнет девайсы давно достигли в своем развитии определенного уровня, однако на производствах, где технопроцессы связаны с опасными средами, где требования непрерывности и прочие риски — используются другие вещи. Классический езернет — по сути мультимастерная сеть. Синхронный езернет — каждый передает по четкому графику, пусть даже не с такими классными параметрами, как вы привели выше. Именно поэтому классические синхронные шины еще и не сдают своих поизиций… пока.
Вы поймите, что требование передачи данных по ethernet без потерь встречается не только в указанных вами случаях. Оно на самом деле широко распространено. Ваши классические синхронные шины используются потому, что, во-первых, их производительности хватает, а во-вторых — современное железо, исключающее потери на ethernet транспорте, стоит вовсе не две копейки.
Вы все о потерях… Да может не быть потерь, может. В обычном езрнете каждая станция сама себе голова — когда захотела, тогда и передала данные. Потерь не будет, может и задержек даже критичных не будет. Но это за счет… как бы это сказать… Запаса. По принципу — сила есть, ума не надо. Если же передачу каждой станции контролировать — вопрос решен. Для любых скоростей. Разница чувствуется? Им просто неоткуда взяться, если мы управляем передачей централизовано. Это гарантия принципиальная, а не по логике — на это способно крутое железо.
Потерь не будет, может и задержек даже критичных не будет. Но это за счет… как бы это сказать… Запаса.
Назовите конкретную особенность, которая не позволяет использовать современные коммутаторы под указанную вами задачу.
Централизация управления передачей данных — куда более отвратительный подход, чем неблокируемая локальная фабрика коммутации и мощная приоритезация на уровне каждого порта, с большим запасом по пропускной способности.
Я возьму паузу для ответа :) Пока считайте, что убежден вашими доводами.
Да, кстати. Помнится в теме про связь ДЦ по L2 вы много чего про L2 недоброго говорили. Домен отказа и все такое. В ваших устройствах со всевозможными глюками типа штормов широковещательных и прочего чем бороться? Классическими средствами типа storm-control и прочие механизмы защиты? Ну та же приоритезация может помочь. Может мой пример неудачный, но вы поймете, что я имею в виду. В системе с разделением времени, когда для передачи каждого узла выделен временной слот, любые траблы, создаваемые одним узлом не повлияют на передачу других. Их слот у них никто не отнимет. При этом источник проблем может как угодно «засрать» свой. Поправьте меня, если я что-то переврал.
В ваших устройствах со всевозможными глюками типа штормов широковещательных и прочего чем бороться?
Грамотным дизайном. Современные коммутируемые сети строятся не на STP, а на TRILL. Плюс — «QoS на стероидах» вроде DCB и PFC. В итоге даже тотальный шторм никак не повлияет на время или качество доставки приоритетных пакетов. Хотя никто не отменял storm control…
А сколько должно быть устройств в широковещательном сегменте для ваших АСУТП? Если десяток-два, то широковещательный сегмент может быть представлен в виде одного-двух (для резервирования) коммутаторов.
А реализовано ли у вас резервирование коммутаторов с временем восстановления в пределах нескольких миллисекунд (в зависимости от характера аварии)?
В пром сетях не используют обычный STP. Там проприетарные протоколы типа TurboRING, HyperRING и прочее. Могу ошибиться, но что-то в районе 20mc. Но опять же, это в сетях верхнего уровня. В по-настоящему критичных и жестких случаях делается полное дублирование. Хотя это бывает и дорого. И да, я писал, свичей может не быть вообще. Они даже могут мешать. Если надо сделать отказоустойчиво — выполнят второй контур. Он будет работать параллельно и независимо.
Я не возражаю против объяснения всёго этого, я за то, чтобы разделять now() и history(). Пишешь про устройство таблицы прерываний на какой-нибудь Амиге — явно отделяй его от современного MSI-X. Одно дело почитать о том, как были устроены компьютеры/сети/программы в прошлом (поучительно и любопытно), другое дело читать про то, как работает инфраструктура сейчас (необходимо и обязательно).
Когда их путают — получается плохая статья.
Когда их путают — получается плохая статья.
Ну что вы, вот мне все это полезно было прочитать, хотя на мой взгляд название для статьи не самое удачное, но было вполне интересно.
PS. справедливости ради, тема с оптическими кабелями как-то внезапно уж оборвалась, можно было как раз тут «физику» и раскрыть.
PS. справедливости ради, тема с оптическими кабелями как-то внезапно уж оборвалась, можно было как раз тут «физику» и раскрыть.
Всё равно не понимаю, как так получается: при переходе с 100 Мбит на 1 Гбит количество пар увеличилось вдвое, а скорость в 10 раз.
зависимость не линейная. меняется (увеличивается) частота передачи данных, при том, что меньше пакетов теряется из-за ошибок.
Ну просто же совсем.
Вместо одной пары на передачу используются все 4 = рост в 4 раза.
Вместо двух уровней сигнала в паре используется 4 уровня = рост еще в 2 раза.
Плюс подняли опорную частоту со 100 до 125 МГц = рост еще в 1.25 раза.
Итого 4х2х1.25 = 10.
Вместо одной пары на передачу используются все 4 = рост в 4 раза.
Вместо двух уровней сигнала в паре используется 4 уровня = рост еще в 2 раза.
Плюс подняли опорную частоту со 100 до 125 МГц = рост еще в 1.25 раза.
Итого 4х2х1.25 = 10.
А принимать сигнал по оставшимся 0 парам?
>>Кроме того, для того, чтоб использовать все пары одновременно для приема и передачи сетевой адаптер вычитает из общего сигнала собственный переданный сигнал, чтоб получить сигнал переданный другой стороной. Таким образом реализуется полнодуплексный режим по одному каналу.
Кстати говоря именно по этой причине в обе стороны обычно не более 60МБ\с (~0.5Гб\с).
Кстати говоря именно по этой причине в обе стороны обычно не более 60МБ\с (~0.5Гб\с).
Понял, спасибо.
Кстати говоря именно по этой причине в обе стороны обычно не более 60МБ\с (~0.5Гб\с).
Зависит от кривизны рук производителей сетевых карт.
Сейчас специально провел колхоз-тест двумя парами iperf'ов и получил в одну сторону 930Мбит/с, а в другую 600 Мбит/с при одновременной передаче, с сетевыми картами Intel. При этом на источнике трафика, который показал 600Мбит/с, можно бы и больше выжать, если подкрутить настройки сетевой подсистемы.
В то-же время позволю себе кинуть камень в огород Realtek, так как я пока не встречал у них сетевых карт, которые вытягивали бы более ~600Мбит/с даже при односторонней передаче данных.
Не забывайте, общей пропускной способности мало.
Надо учитывать pps при минимальных и максимальных размерах пакетов.
Надо учитывать pps при минимальных и максимальных размерах пакетов.
А при чем тут pps? Их имеет смысл считать только когда пакеты маленькие и, по этому, их много. В данном случае iperf не дает большого количества маленьких пакетов, так как отправляет данные большими блоками. В связи с этим сетевая карта должна вытягивать полную пропускную способность.
Так и пишите, размер пакетов.
А в реальной жизни большая доля мелких пакетов.
А в реальной жизни большая доля мелких пакетов.
Я указал на используемый для тестирования общепринятый инструмент.
Из справки следует, что «set length read/write buffer to n (default 8 KB)», те буфер на уровне приложения по умолчанию 8кбайт, что при отключенных jumbo frame значительно больше, чем размер одного ethernet-кадра, следовательно смотреть на pps не имеет смысла. При полученной пропускной способности у нас и так будет минимально возможное значение pps на L2 уровне.
Разрешите уточнить, какую из реальных жизней Вы имеете ввиду?
Моя основная реальная жизнь, где из приложений сетевой подсистеме передаются блоки размеры которых измеряются мегабайтами (и следовательно фрагментируются они оптимально) чем-то менее реальна, чем жизнь в телекоме с торрентами?
Из справки следует, что «set length read/write buffer to n (default 8 KB)», те буфер на уровне приложения по умолчанию 8кбайт, что при отключенных jumbo frame значительно больше, чем размер одного ethernet-кадра, следовательно смотреть на pps не имеет смысла. При полученной пропускной способности у нас и так будет минимально возможное значение pps на L2 уровне.
А в реальной жизни большая доля мелких пакетов.
Разрешите уточнить, какую из реальных жизней Вы имеете ввиду?
Моя основная реальная жизнь, где из приложений сетевой подсистеме передаются блоки размеры которых измеряются мегабайтами (и следовательно фрагментируются они оптимально) чем-то менее реальна, чем жизнь в телекоме с торрентами?
А принимать по тем же самым 4м парам. В статье про это написано.
На самом деле есть (была) и другая версия гигабита — две пары туда, две пары обратно, каждая выдаёт по 500 мбит/с. Не прижился.
Боб Меткалф, создатель Eедположил, что технология будет разработана к: е сказал:
коллизия моска :)
спасибо за интересную статью.
коллизия моска :)
спасибо за интересную статью.
Не смотря на это на практике часто используют 2х-парный кабель, подключают сразу 2 компьютера по одному 4х-парному,
Убил бы кулибиных за такое доброе использование, когда простой переход с «напольной» сети на нормальную «внутристенную» певращается в ад с попыткой разобраться куда же залинкован этот грёбанный хвост!
Наиболее интересующий меня вопрос во всем этом — почему используются именно контакты 1-2 и 3-6, кто это придумал и сколько он будет гореть в аду?
В том плане, почему было не взять 1-2, 3-4 что сэкономило бы кучу сил монтажникам…
В том плане, почему было не взять 1-2, 3-4 что сэкономило бы кучу сил монтажникам…
если посмотреть на схему то видно что пары расходятся от центра 4-5 3-6 и две по бокам ( точнее нумерация пар чуть-чуть другая, но не важно )
если посмотреть на RJ-11 и прочие то видно что это сделано для совместимости, то есть в разетку можно воткнуть телефон и на другой стороне центральную пару завести на телефонный аналоговый кросс и это будет нормально работать ( даже можно и FE паралельно пользовать, но не нужно )
если посмотреть на RJ-11 и прочие то видно что это сделано для совместимости, то есть в разетку можно воткнуть телефон и на другой стороне центральную пару завести на телефонный аналоговый кросс и это будет нормально работать ( даже можно и FE паралельно пользовать, но не нужно )
The original idea in wiring modular connectors, as seen in the registered jacks, was that the first pair would go in the center positions, the next pair on the next outermost ones, and so on. Also, signal shielding would be optimized by alternating the «live» and «earthy» pins of each pair. The TIA/EIA-568-B terminations diverge slightly from this concept because on the 8 position connector, the resulting pinout would separate the outermost pair too far to meet the electrical echo requirements of high-speed LAN protocols.
en.wikipedia.org/wiki/TIA/EIA-568#Theory
А вы не задумывались, почему витая пара… витая?)
en.wikipedia.org/wiki/TIA/EIA-568#Theory
А вы не задумывались, почему витая пара… витая?)
Опоздала статья лет так на 15, домен коллизий, кроссовер кабеля, коаксиал, концентраторы — зачем все это? Те кто помнит и так разбираются в сетях, те кто только изучает — получит багаж устаревшего ненужного хлама знаний. Лучше бы про типы оптики и современные тенденции побольше. В средних и крупных городах уже и SOHO сегмент перетянут на оптику вплоть до «последней мили», а тут на тебе коаксиал.
PoE работает на двух парах.
Практика критерий истины ;)
Во избежание недопонимания: есть работающий VoIP телефон, питающийся через PoE и подключенный через две пары.
Практика критерий истины ;)
Во избежание недопонимания: есть работающий VoIP телефон, питающийся через PoE и подключенный через две пары.
>40-гигабитный Ethernet (или 40GbE) и 100-гигабитный Ethernet (или 100GbE). Разработка этих стандартов была закончена только в июле 2010 года. В настоящий момент ведущие производители сетевого оборудования, такие как Cisco, Juniper Networks и Huawei уже заняты разработкой и выпуском первых маршрутизаторов поддерживающих эти технологии.
Это с какого такого древнего рекламного проспекта Cisco копипаст? «только в июле 2010 можно сказать в конце 2010, но в конце 2012 это уже седая древность.
И вообще-то даже на момент принятия стандарта были продукты с 40G на драфте. В любом случае стандарт специально делался для упрощения работы и имеющиеся платы 4x10G относительно легко стали 1x40G. Другой вопрос что архитектура „ведущих производителей“ не позволяла полноценно работать на этих скоростях.
Это с какого такого древнего рекламного проспекта Cisco копипаст? «только в июле 2010 можно сказать в конце 2010, но в конце 2012 это уже седая древность.
И вообще-то даже на момент принятия стандарта были продукты с 40G на драфте. В любом случае стандарт специально делался для упрощения работы и имеющиеся платы 4x10G относительно легко стали 1x40G. Другой вопрос что архитектура „ведущих производителей“ не позволяла полноценно работать на этих скоростях.
extreme networks же, не?
Mellanox, BNT
не буду раздувать холивар вокруг брендов, скажу лишь
L2 свитч с несколькими 40G это уже не экзотика — если надо таковой можно найти практически у любого серьезного вендора
проблема возникает на рутинге — старые шасси не справляются с такими скоростями, архитектура с центральных процом тоже. Требуются уже более умные линейные платы aka ASIC и полноценный MPLS. Для датацентра это все не так актуально, а вот для провайдера уровня города — очень даже. Хотя даже в Москве выше 40G еще вроде никто не прыгал.
L2 свитч с несколькими 40G это уже не экзотика — если надо таковой можно найти практически у любого серьезного вендора
проблема возникает на рутинге — старые шасси не справляются с такими скоростями, архитектура с центральных процом тоже. Требуются уже более умные линейные платы aka ASIC и полноценный MPLS. Для датацентра это все не так актуально, а вот для провайдера уровня города — очень даже. Хотя даже в Москве выше 40G еще вроде никто не прыгал.
Требуются уже более умные линейные платы aka ASIC и полноценный MPLS. Для датацентра это все не так актуально
Да ну на фиг? Современный ЦОД без MPLS — фигня какая-то. Да и с учетом виртуализации, 10G на аплинк — маловато будет. Так что как раз для ЦОДов и нужны быстрые коммутаторы. Причем именно L3 коммутаторы.
старые шасси не справляются с такими скоростями
Потому делают новые. К примеру, у циски есть абсолютно модульные нексусы 7k, в которых и фабрика поддается замене. Всего можно вставить 5 модулей, каждый дает по 110гб/с на слот (кроссбар). Выйдут новые — не проблема обновиться без замены шасси, и, наверное, плат и супервизоров.
По роутингу тоже никаких проблем. Старые F1 платы, правда, роутить не умели, задействуя ресурсы М карт, но F2 избавлены от этого позорного недуга (хотя временами все равно могут задействовать ресурсы М-ок).
>10G на аплинк
А что IX стал давать больше 10G?
>Современный ЦОД без MPLS — фигня какая-то.
И много у нас ЦОД, которым реально нужен MPLS?
несколько разнесенных аплинков?
распределенные кластера виртуализации?
А что IX стал давать больше 10G?
>Современный ЦОД без MPLS — фигня какая-то.
И много у нас ЦОД, которым реально нужен MPLS?
несколько разнесенных аплинков?
распределенные кластера виртуализации?
А что IX стал давать больше 10G?
Причем тут IX? Под «датацентр» я понимаю «корпоративный датацентр со своим сетевым и серверным оборудованием».
И много у нас ЦОД, которым реально нужен MPLS?
несколько разнесенных аплинков?
распределенные кластера виртуализации?
Много. Очень. Если взять 1000 крупнейших компаний страны (по капитализации), то у каждой из них в ЦОДах будет тот самый MPLS, полностью резервированная двухуровневая (или даже трехуровневая) сетевая топология и виртуализация.
Скорее всего, цифры «1000» сильно занижена.
>А что IX стал давать больше 10G?
40G
40G
На самом деле, для 10GE Ethernet используются модули и кабели SFP+, а для 40GE QSFP.
Это вы вообще к чему? XENPAK, XFP, X2 — тоже вполне себе десяточные и очень распространённые модули. SFP+ это всего лишь самый современный формфактор, обеспечивающий максимальную плотность десяток на слот (не считая переходников из QSFP в 4x10GE).
А 40GE, в свою очередь, может работать и через CFP-модули, необязательно QSFP.
А 40GE, в свою очередь, может работать и через CFP-модули, необязательно QSFP.
>>XENPAK, XFP, X2 — тоже вполне себе десяточные и очень распространённые модули.
>>CFP-модули
Очень большие модули. Для маршрутизатора пойдут, а вот для L2 комутатора слишком большие. К тому же эти модули только оптические, а с SFP+ и QSFP есть и медные кабели, что на много дешевле.
>>CFP-модули
Очень большие модули. Для маршрутизатора пойдут, а вот для L2 комутатора слишком большие. К тому же эти модули только оптические, а с SFP+ и QSFP есть и медные кабели, что на много дешевле.
Насчёт компактности всё верно, SFP+ самый молодой и технически самый актуальный форм-фактор для 10GE, позволивший спрятать всю начинку в сверхкомпактный корпус, позволяющий создавать одноюнитовые коммутаторы с 48 десятками на борту. Уже даже и дальнобойные ZR для SFP+ появились, что раньше казалось невозможным.
А вот насчёт исключительно оптической направленности указанных мной модулей не надо сказок. XENPAK и X2 имеют возможности подключения медных модулей — у циски это архаичный CX4 для первого и 10GBASE-T для второго. У других вендоров не смотрел.
А вот насчёт исключительно оптической направленности указанных мной модулей не надо сказок. XENPAK и X2 имеют возможности подключения медных модулей — у циски это архаичный CX4 для первого и 10GBASE-T для второго. У других вендоров не смотрел.
Всегда было интересно, каким образом происходит синхронизация передатчика и приемника по скорости при отсутствии сигнала синхронизации как, например, в SPI? Например, если подключить роутер, поддерживающий только 100 мбит, к гигабитной сетевой карте, всё будет отлично работать. Как сетевая карта определяет, что устройство на другом конце провода поддерживает только более старый стандарт и более низкую скорость?
> Возникает вопрос: откуда берется ограничение на длину сегмента у Ethernet по витой паре, если нет разделяемой среды?
…
>Таким образом если концентратор начинал принимать сигналы сразу с двух портов, то он не знал, что транслировать в остальные порты, это была коллизия. То же касалось и первых Ethernet-сетей использующих оптику (10Base-FL).
Я далек от физики, но вот тут не понял. Всегда думал что ограничение ~100 метров из-за затухания сигнала. На некоторых древних 10мбитных цисках и хорошей витой пары добивало до 170 метров.
Или я путаю термины и длина сегмента это про размер кадра, а не длину кабеля между двумя устройствами?
…
>Таким образом если концентратор начинал принимать сигналы сразу с двух портов, то он не знал, что транслировать в остальные порты, это была коллизия. То же касалось и первых Ethernet-сетей использующих оптику (10Base-FL).
Я далек от физики, но вот тут не понял. Всегда думал что ограничение ~100 метров из-за затухания сигнала. На некоторых древних 10мбитных цисках и хорошей витой пары добивало до 170 метров.
Или я путаю термины и длина сегмента это про размер кадра, а не длину кабеля между двумя устройствами?
Sign up to leave a comment.
Физика Ethernet для самых маленьких