Как стать автором
Обновить

Комментарии 250

О! А расскажите что может быть плохого если таки соединить две сетевые розетки пачкордом?
Ну и так же что плохого бывает если во внутренних маршрутах будет более 16 хопов (читать как 16 свичей/ройтеров/серверов?)?
>О! А расскажите что может быть плохого если таки соединить две сетевые розетки пачкордом?
*пожимая плечами* ну, с розетками-то ничего не случится.
а если розетки сводятся на активные L2-порты свитча, на которых отсутствует защита от петель…

>Ну и так же что плохого бывает если во внутренних маршрутах будет более 16 хопов
строго говоря, s/15/16
лично я минимум 2 раза слышал данную фразу в качестве аргумента при выборе внутреннего протокола маршрутизации )
Вы не мудрите, вы для простых скажите. Это таки хабр, я понимаю что ничего не сгорит. Но вот что случится со свичем или с ситуацией в сетке если как вы говорите у него отсутствует защита от петель (такие еще производятся) и таки два порта замкнуться?
Ну не зависнет же он?

Ну и второй вопрос остался открытым :)
Если соединить два порта одним пачкордом, то начнется «сетевой шторм» (если нет защиты), ибо пакеты будут бегать по кругу в этой петле (грубо говоря).
Как-то проводил эксперимент такой — DOS (там где проводил эксперимент на компах был запущен DOS и воткнут в сеть) умер, сказав что-то о фатальной ошибке.
В принципе, можно это сравнить с DoS-атакой на самого себя.
Если соединить два порта одним пачкордом, то начнется «сетевой шторм».

Вы уверены? Я сначала, правда, тоже так подумал. А потом подумал, что тогда эти два порта выпадут из таблицы коммутации по идее, т.к. на них не будет хостов. Вот если петля хотя бы из 2х коммутаторов, то да.
Зависит от оборудования. На свитче или роутере это вызовет шторм если железяка глупая (даже проверял когда-то в школьные годы, о чем написал).
Несколько лет назад «по приколу» решил соединить свитч сам с собой… Посмотрел, «так прикольно мигает… ну и фиг с ним, пусть мигает», и уехал. Вернулся через 4 часа, на столбе висят ребята и отключают меня от сети :) Объяснил ситуацию, посмеялись, вернули меня в сеть и уехали. Но на всю жизнь я запомнил то, что так делать нельзя :)
> Но на всю жизнь я запомнил то, что так делать нельзя :)
можно.
но только один раз (ц)
В телескоп на Солнце можно посмотреть два раза — правым глазом и левым.
или один раз — если биноклем
В телескоп очень неудобно смотреть биноклем
Кстати реально. В древние времена как-то убили старый 10М-хаб таким образом. Он тупо провалялся с петлёй на столе несколько часов, а в третий порт был воткнут патчкорд с реальной передающей машины. Бедняга мигал, мигал и спёкся навеки :)
Да, по-моему такой эксперимент откладывается в памяти намного сильнее, чем какие-нибудь теоретические выкладки на тему того что и почему произойдёт.
Точно :)
Блин, никогда даже в голову не приходило так сделать!
Мне было то ли 14, то ли 15 лет — я уже не помню… но мне захотелось чтоб у меня в свитче было «как в фильмах, всё мигало» — ну я и не придумал ничего умнее ))
НЛО прилетело и опубликовало эту надпись здесь
Как-то удивлялся с какого-то невесть откуда взявшегося маршрутизатора USR: у него именно таким образом производился аппаратный сброс. Правда соединить надо было 1-й(вроде) LAN-порт с WAN-портом. Кнопки сброса не было в принципе(даже дорожек на плате).
Или еще например, соединив 1 и 2 порт в HP ProСurve 1700/1800 серии тоже можно сбросить конфиг. :)

Интересно, а никто кроме меня так патчкорд не проверяет на работоспособность?
НЛО прилетело и опубликовало эту надпись здесь
Наши монтажники так проверяли патчкорды на железках в домовых шкафах, научились у коллег из другого города. Но там по другому настроены домовые коммутаторы и сами коммутаторы другие. В моих настроен shutdown при loopback-detection. Обнаружил это после их звонка и наезда дескать у тебя весь коммутатор дохлый ни одного живого медного порта.
Можно конечно сделать авто подъем после таймаута, но лень и надо учить криворуких что loopback зло и делать так нельзя.
Ну так про то и правило, что нужно быть готовым к тому, что в любой момент кто-то может сделать тебе петлю.
Просто многие пишут, что можно забить и ничего страшного не случиться. Вот как раз с таким отношением всякое может случиться.
Да, только стоит уточнить, начнется broadcast storm. По кругу начнут бегать широковещательные ARP запросы. А коммутатора должен их рассылать на все порты с активным линком.
Есть решение ограничивать процент мультикаст броадкаст уникаст по отношению к другому трафику. Как правило 3-5% замечательно помогают.
Дык ни кто же не говорит, что проблема не решаема, просто если свитч тупой не умеет детектить brodcast storm, то сеть может упасть. Я на работе часто клал офисную сеть случайно (я разрабатываю всякие железки сетевые, поэтому часто провожу эксперименты разные).
Странно у вас сеть настроена, раз одной петлей её роняете.
Она маленькая, на 10 — 12 машин всего. Возиться с ней никому не охото, работает и ладно )).
А большую сеть широковещательный шторм не уронит разве? По-моему, это просто займет больше времени. Или я не прав?
Расскажу реальный случай, когда на 1G порту случайно не выспавшийся рубанул петлю. Аплинк на этом коммутаторе был 10G через DWDM в ядро сети.
Заметил ошибку только через минут пять когда увидел что попер трафик в 50 мегабит с порта тестового коммутатора. Но на этом коммутаторе не должно быть его в таком количестве.
Отработали супресы или как мы их называем штормилки, и ничего страшного не произошло.
После этого случая седлал себе отдельный стенд который идет к рабочим коммутаторам через спец порт с жестко прописаными штормилками.
Вы подумали что выпадут, а практика показывает что не выпадают.
Да нет, из таблицы коммутации они выпадут. Действительно, дело во всяких широковещательных запросах (например, ARP).
Обычно в простых свитчах при отсутствии мак-адреса в таблице, пакет просто идет на все порты. Потом уже при ответе мак занесется в таблицу, и будет уже обращение по конкретному порту. А что будет, если есть петелька и пришел пакет с неизвестным маком? Он уйдет на все порты, то есть скопируется в порты «А» и «В», которые взамкнуты между собой. Пакет, который ушел на «А», тут же придет из «В» и наоборот — и вот у нас уже 2 одинаковых пакета. Дальше рассказывать? :)
> А потом подумал, что тогда эти два порта выпадут из таблицы коммутации по идее, т.к. на них не будет хостов. Вот если петля хотя бы из 2х коммутаторов, то да.

Глупые свичи отправляют пакеты с неизвестными ему mac-адресами на все порты. Отсюда и шторм.
А что же делают умные?
Я почитал комменты выше и понял, что умные делают то же самое, только не пакет шлют, а arp-запрос, который точно так же циклится :)
Я вот точно уверен. Два раза в своё время сеть штормило.
У меня пользователи воткнули в розетку провод торчащий из за шкафа… я тогда был совсем юнцов этом деле… пол дня искал причину почему вся сеть легла… а это 70 компов. Сопоставил факты, в тот день 2 человека переезжали с этажа на этаж, пока я носился с одним второй сам «подключился к сети»…
1 — ответили выше.
2 — касается целесообразности использования протокола маршрутизацииRIP в современных реалиях.
для тех кто не сильно знаком с протоколами динамической маршрутизации:
RIP это как виндовс 98 в век вин7, MacOS X, Ubuntu 10.04.
HTTP, знаете ли, еще старше
А если ftp вспомнить, о…
знаете ли, я не про возраст…
еже 30 секундные апдейты полной таблицы маршрутизации и хоповая метрика…
если спроецировать OSPF & RIP на оси, то на мой взгляд оно и получится; )
Тем не менее, в некоторых местах использование RIP все равно предпочтительнее.
пример? даже если скорости каналов везде одинаковые, глупый рип не знает слово linkstate.
Передача маршрутов к клиентам между BRAS-ами и border-ом.
и чем же RIP тут предпочтительней перед ospf/eigrp/isis? Желателен ответ в духе «потому что из-за вот этой фичи <link-sate protocol> будет <вот такой гемор>, а у rip таких проблем нет»
В каком году наступил век вин7? Не в 2001?
Однажды клиенты так соединили.
Первое, что я увидел: не могли подключиться к терминальному серверу в другом здании.
Дальше заметил, что все индикаторы на свитче тупо мигают. Дальше — больше. При запуске на компьютере Windows Media Player'а и патчкорде, включенном в сетевую карту и в общую сеть, проигрывание mp3'шки было похоже на проигрывание кассеты, которую магнитофон очень-очень сильно тянет. Причем все описанное наблюдалось в нескольких зданиях, соединенных между собой.
А причина была проста: в одном из маленьких кабинетов два конца одного провода были включены в разные розетки, которые потом сходились в один свитч.
16 хопов это лимит RIP протокола маршутизации. Маршрутизация — функция маршрутизаторов (раутеров), свичи и сервера выполняют другие функции на других уровнях OSI модели.
>Никто никогда не соединит 2 сетевые розетки патчкордом.
Интересно сколько людей прочитав это попробует так сделать при первом же удобном случае? :)
Каких людей? Айтишники делать не будут. Пользователи, откуда у них патчкорд, если только не из своего ПК, да и как он поймет, что что-то случилось.
как он поймет, что что-то случилось.

Например по истошным криков сотрудников, оставшихся без интернета)
>Каких людей? Айтишники делать не будут
*пожимая плечами*

на моей памяти, в частности, был случай, когда невыспавшийся сервисдеск подключал пару принтеров и перепутал патчкорды.
или когда два абонента сидят на одном провайдерском коммутаторе, но до подключения к Интернету у них была собственная веревка из окна в окно. Решают вспомнить молодость (или просто на данном коммутаторе кто-то начинает лить торрент со 100Мбитной силой и задержка становится ни 1 мс, а 2) и петлят весь свой коммутатор ) Весь подъезд выходит курить
:) это я на тему «не будут»… не обязательно, кстати, патчкордом соединять розетки, достаточно неудачно обжать патчкорд, и закоротить пару… сам с таким сталкивался, правда в 98-м, что ли…

еще из той же серии… «митрофанушка». купивший модем с роутером для стрима, решил не заморачиваться патчкордом и воткнул его в ближайшую сетевую розетку, а там по-умолчанию DHCP сервер включен… говорят, админы далеко не сразу разобрались что это… но больше я удивился, когда такую же хрень сотворил кто-то из админов, настраивая киску что ли, для удаленного офиса…
начало конца :)
А что случиться? У меня на работе запросто можно попробовать…
Я знаю более весёлый вариант
godkillskitten.com/because/b26948

Но по-моему очевидно, что это просто опечатка.
Пункт 6 вовсе не смешной. Ip действительно удобнее. У серверов давно есть ipmi/ilo, давно есть ipkvm.
Только при первичной настройке какого-либо специализированного оборудования (чаще сетевого) пригождается, да и то, все реже. К моей нескрываемой радости. Да, можно, конечно и консольную сеть растянуть, с доступом по tcp/ip к ней, но это недешевое удовольствие. А бегать с ноутбуком и глючным перходником usb-com вообще не комильфо, разве что дешевому техсаппорту ок.
>Да, можно, конечно и консольную сеть растянуть, с доступом по tcp/ip к ней, но это недешевое удовольствие
да, к сожалению :(
но другого быстрого решения для случаев, когда ip-доступ к критичному сетевому оборудованию отсутствует — пока не придумано, насколько я знаю.
Специализированный management порт. А-ля ipmi, только для сетевого оборудования, т.е. где крутится отдельная микро-ОС с доступом к железу и питанию.
как вариант, да.
но подобное решение, к сожалению, есть далеко не у всех вендоров.
Это я так, в качестве светлой мечты. Ноута с компортом практически не найти, переходники глючные через раз, а под неwinными операционками вообще не работают, как правило.
Попался ровно один глючный переходник из полусотни используемых. Покупались в разное время, в разных городах, особо не заморачиваясь с производителями и моделями.
Большая часть переходников постоянно работает в линуксе.
Хз, мне дважды не повезло, я поставил крест на этой лабуде.
«Дважды не повезло» и «переходники глючные через раз», «под неwinными операционками вообще не работают» как то слабо корелирует между собой, вы не находите?
Цитируя, приводите фразу целиком, ок?
Два разных переходника не заработали на трех ноутбуках с разными линуксами. Для формирования некоего мения этого более чем достаточно.
К моей радости, я не инженер саппорта железяк сетевых, потому эти чудо-костыли в виде переходников serial-parallel мне пригождаются в худшем случае раз в год, в лучшем — два года уже не прикасался (сплюнул на луну через левую пятку).
Хм. активно использую компорт на ноуте через переходники. Под винду поставить как правило проблема. Под пингвином все они работали по принципу воткнул и у тебя всё работает.

А для управления операционками легко собирается такая фигня: переходник в девайс, другим хвостом в USB хаб, USB хаб втыкается в порт ближайшего сервера. Цена ~400 рублей на девайс.
Я под Linux использую и FTDI, и pl2303.
В своё время начитался о глючности оных, первые несколько штук выбирал придирчиво, договаривался если что вернуть.
Потом тупо стал брать самый дешевый.
кто бы что ни говорил, но когда циска ушла в rommon глючный usb-com становится самой нужной штучкой… )
Это как отказаться от ремонта компьютеров, мол отвертка — зло. Заглючило железо, на свалку!
Аналогии и аллегории — не ваш профиль.
— Зачем делать карту сети с описанием, вот же все видно.
— Зачем маркировать кабеля, вот же видно что откуда
— Безопасность? Да кому мы нужны?
> — Зачем маркировать кабеля, вот же видно что откуда
+ «СКC — это для крупных компаний» (ц)
а можно расшифровать для простых смертных, что за СКС?
структурированная кабельная система, вроде как…
google -> СКС?
Мне выдал в первом результате — «Структурированная кабельная система».
Очевидно что это и подразумевалось.
А так и есть.
Даже если аккуратненько проложить кабели, завести в панели-розетки и т.п. — это не обязательно СКС ;-)
Из этих строчек получатся отличные постеры/наклейки для администраторов. Я бы купил.
На лоб.
> Безопасность? Да кому мы нужны?

Продавайте футболки с этой надписью.
Если первый и третий пункт для начала требуют устных разъяснений и лишь потом — работы битой, если не понимают, то за второй пункт надо бить в челюсть сразу :)
как мне один безопасник говорил: перед тем как думать о безопасности, надо понять: что и от кого мы собираемся защищать, и только на этом строить нашу систему безопасности, а не как суицидальные ребята блочат все-все-все. но таки да, она нужна
Это называется — «Пока гром не грянет, мужик не перекрестится». Указанный безопасник к сожалению один из миллионов идиотов занимающих свою должность. Как там у lulz security было? Set Sail for Fail!
Ну, скорее наоборот. Любая безопасность стоит денег, которые всегда ограничены. Можно сделать длинный и низкий забор «против всех», который по факту защитит только от ламеров, а можно за те же деньги воздвигнуть сторожевой пост на самом опасном направлении.
И да, в ИТ самое опасное направление — это чаще всего инсайд.
никто не говорит о тотально отгораживании наперед. Дело именно в постановке вопроса. Это как написать deny from all, а потом уже разрешать что-то. А ваш безопасник просто сидит ждет, что нужно запретить…
Вот почему пользователь с ником чайник все сразу понял?
но VolCh думаю тоже дело говорит =)
Можно еще и такое добавить. Безопасники больше все же ощущают себя карающими органами, чем предотвращающими. То есть, не у вас там и тут дырочка осталась/образовалась, заделайте. А у вас тут дырочка осталась/образовалась, уволить.
Это называется составлением модели политики безопасности — см. ГОСТ Р ИСО/МЭК 15408-1-2002. И это необходимый (и если не ошибаюсь — первый) этап для получения сертификата соответствия ФСБ.
Мудрость приходит с годами))))
Чаше годы приходят одни.
4. Устная договоренность…
Это Россия, тут отношения строятся на «он отличный парень» и «мы вместе бухали/учились/работали».

5. Сертификация — незначима.
Не далеко от истины. Именно потому, что сертификаты можно получить с помощью дампов, они не играют решающей роли.

6. Прямой доступ через serial к оборудованию — анахронизм.
Кроме тех случаев, когда уже ничего не работает, зачем нужен сериал доступ?

7. С системой мониторинга должен работать соответствующий отдел.
Потому что так дешевле получается. Нечего занятых дядек отвлекать какой-то херней.

С остальным согласен.
Как рассказывал один преподаватель про контракты с немцами…
Однажды он уже попал на 100000 евро из-за того, что в Германии (по крайней мере в то время, когда имел место этот случай) было распространенной практикой просто пожать руки и начать работать. После этого случая он всегда заключает договоры и договоры составляются юридическим отделом фирмы.
>Именно потому, что сертификаты можно получить с помощью дампов, они не играют решающей роли.
решающей — нет, конечно.
но с сертификатами — лучше, чем без них, amiright?

>Потому что так дешевле получается. Нечего занятых дядек отвлекать какой-то херней.
вообщем-то да.
но в случаях, когда отделу мониторинга на контроль отдается _все_ оборудование, включая критичное — иногда бывает мучительно больно :(
>но с сертификатами — лучше, чем без них, amiright?
Лучше делать что? Устраиваться на работу? — так точно. Работать — уверены?
>Работать — уверены?
эээ…
мне сложно представить сертификат, который сам по себе, без сопутствующих знаний, увеличивает эффективность работы сетевика )

>Устраиваться на работу? — так точно
лично я отношусь к сертификатам как к хорошей и полезной пузомерке.
которая, имхо, дает +N к:
1. вероятности приглашения на собеседование
2. количеству примитивных вопросов на нем же
3. вероятности получения работы в иностранной компании.
Ну у меня примерно те же мысли, и так с любыми сертификатами, имхо. Грубо говоря, сертификат нужен, если некто принимает человека на работу, но при этом толком не может(или не хочет) проверять уровень компетентности соискателя — сертификат говорит хотя бы о том, что человек не посторонний на этой работе :)
Если бывает мучительно больно — видимо нужно менять отдел мониторинга.
НЛО прилетело и опубликовало эту надпись здесь
Кроме тех случаев, когда уже ничего не работает, зачем нужен сериал доступ?

Нередко бывает, что настроить что-либо в железке можно гораздо быстрее и удобнее при помощи сериального доступа, нежели через веб-админку.

Но это скорее относится к вопросу сетапа, дальше-то можно и через телнет/ssh настраивать с той же прыткостью, что и через serial, а вот в случае, если «уже ничего не работает», то да, и правда :)
«Кроме тех случаев, когда уже ничего не работает, зачем нужен сериал доступ?»
Когда перед вами железка на ХХ(Х) SFP а у вас под рукой нет конвертера. Оно же с xWDM и т.д. Всего лишь наличие/отсутствие доступного интерфейса под рукой.
>Одного гигабитного линка будет достаточно для всех.
Вспомнилось: «640кб хватит всем» ©
бл#дь, что я такого сказал?
некошерно эту фразу вспоминать.
если бы вы еще и указали БГ автором, то вообще набросились бы!
А, то есть упоминать М. и Б.Г нельзя? Ну ладно, спасибо что сказали (:
fixed
Это точно заблужения сетевого администратора? Скорее человека, который к этой области имеет довольно посредственное отношение или только начал работать.
да, заблуждения молодого сетевого инженера )
не без этого )
впрочем:
1. если бы таким образом заблуждались только молодые сетевики — , мир был бы гораздо совершеннее.
2. «хардкорные» заблуждения, имхо, требуют более подробного рассмотрения.
исходя из соотношения «отдельная статья на заблуждение», а не «5-минутная заметка на все » )
Мир бы был гараздо совершеннее, если бы в нем вообще было больше хороших специалистов :)
Чёт некоторые «заблуждения» весьма сомнительны. Например, сертификация просто идеально не нужна в российских реалиях, если ваш работодатель не смотрит на бумажки. COM-порт — это вообще анахронизм эпохи динозавров, со всем, с чем можно работать не через него, всегда нужно работать не через него. Про две розетки вообще не понял — N лет назад было актуально, но нонче я даже не знаю, можно ли в принципе купить свитч, которому от этого станет плохо.
Например, сертификация просто идеально не нужна в российских реалиях, если ваш работодатель не смотрит на бумажки.

… и если вы показываете сертификат, не пригодный для должности на которую претендуете.(Я к тому, что к любому условию, можно добавить много если. )
COM-порт — это вообще анахронизм эпохи динозавров,

Да вот когда все та же петля или просто ip не работает, динозавры восстают из мертвых. это один из примеров. Еще есть такая штука, как человеческий фактор, который может к примеру положить по запарке (или по опыту) порт в даун.
Про две розетки вообще не понял — N лет назад было актуально, но нонче я даже не знаю, можно ли в принципе купить свитч, которому от этого станет плохо.

такого железа немерено, к примеру те же catalyst естественно в не настроеном состоянии.
COM-порт — это вообще анахронизм эпохи динозавров

не говорите это инженерам, особенно, работающим с железом и проектирующим оборудование.
COM-порт — это вешь совершенно прекрасная во многих случаях, простая, как всё гениальное. Единственное, чего ему не достаёт — это гальванической развязки(и, соответственно, беспроблемного горячего подключения). Ну и скорости скромные, но часто огромные скорости и не нужны, а нужна именно простота и безотказность.
Классический ком порт, не те что час почти везде стоят (так называемые ТТЛ), по спецификации просто от втыкания не горит. А вот удешевление как раз привело к такой ситуации.
ТТЛ вынужденная мера, т.к. ТТЛ логика, ЕМНИП от 0 до +5 В, когда UART требует ±12 по понятным причинам. Многое встраиваемое оборудование, в особенности портативное, не даст вам таких мощностей, или убьет аккумулятор за раз.
Все верно, и поэтому и выгорают чаще.
COM-порт — это вообще анахронизм эпохи динозавров, со всем, с чем можно работать не через него, всегда нужно работать не через него.

Для настройки сетевого оборудования нет ничего удобней, чем COM-порт. Можно спокойно работать и не бояться отключить самого себя.
можно ли в принципе купить свитч, которому от этого станет плохо

Loopback detection в большинстве случаев требует STP. У 99% свитчей его либо нет, либо по дефолту отключен.
Да… Свич без STP в офисе — очень полезная штука. Касательно COM: я грешным делом не вижу практически ни у одного современного ноута и компьютера COM порта. Наверно, потому что сам по себе COM порт устарел ещё в 90-х. Поэтому производители оборудования, которые зачем-то вместо нормального отдельного managment порта делают ком меня сильно выбешивают. В какой-то момент в одном офисе сутки не было интернета, потому что ни одни из более чем 100 компов не был с COM портом, старый свитч сгорел, а новый нужным образом можно было настроить только через COM… И вот кому, блин, счёт выставлять? Техническому прогрессу или идиотам, не додумавшимся, что нету нигде уже COM портов в 2010 году, нехрен с ними оборудование производить. Делайте, блин, тогда уж USB или Fixed IP Ethernet, но блин COM…
Если не ошибаюсь у HP есть спец модели с ком портом. Выпускают именно для IT сигмента.
Много кто ставит в офисах хорошие свитчи с STP? Если кто и ставит — то для галочки, и даже не настраивают — тупо используют как мыльницу. Это реалии.

А насчет COM-порта… У большинства managed коммутаторов есть serial, и даже шнурок к нему в комплекте. Если Вы не озаботились в своё время купить FTDI за 10 баксов — это уже Ваш просчет.

Насчет USB: он будет либо с проприетарным протоколом и драйверами (оно вам надо?), либо тупо эмулятором COM-порта (читай: тот же FTDI/pl2303, но внутри и дороже).

Насчет Fixed IP: чтобы он работал, нужно одно из двух:
а) загрузить OS свитча. Если прошивка не работает — до свидания.
б) держать внутри отдельную железку. Опять-таки, дорого и ненадежно, а что получаем в итоге? Ту же консоль, но уже поверх IP.
В догонку к вашему комментарию. Сбросить забытый пароль или перепрошить Boot PROM убитой железки, производства D-Link можно только с COM-порта.
Перепрошить мертвый Boot PROM через COM-порт нельзя. Потому что прошивка через него как раз идет. Конечно, этим можно пренебречь, если Вы — Мюнхаузен ;).
А насчет паролей… По идее, их можно сбросить только в СЦ. Но мы-то с Вами знаем…
Очень даже можно — при запуске коммутатора с мертвым boot или прошивкой зажимается волшебная комбинация клавиш (Shift+3) и коммутатор переходит в режим Z-modem и ожидает загрузки на тот же самый COM-порт новой прошивки. Отключается консоль управления и заливается прошивка.
Если бы лично этого не делал — не говорил бы.
Погодите, как это? На shift+3 появляется менюшка с прошивкой, которую рисует как раз-таки boot. Или перед boot-ом есть еще что-то, вроде irom?
Видимо, я поторопился сказать про убитый boot, но поврежденная прошивка отсюда перешивается точно. И по сети это сделать будет невозможно — железка не стартует
Ну это я в курсе. Много раз приходилось делать.
> D-Link
как минимум — актуально еще для HP и Zyxel.
а разве не через JATG перепрошивается убитый пром?
Да, скорее JTAG. Я ниже поправился про boot prom.
>В какой-то момент в одном офисе сутки не было интернета, потому что ни одни из более чем 100 компов не был с COM портом, старый свитч сгорел, а новый нужным образом можно было настроить только через COM… И вот кому, блин, счёт выставлять?
имхо, сетевику, не озаботившемуся покупкой usb-to-serial и/или serial port server.
Могу Вас огорчить — не все эти приблуды годятся. Но Вы правы в распряжении админа это обязано быть.
Ну и что. К нам сервисник от НР приходил, натрахался со своим буком, шнурком, переходником, но так и не смог подключиться к оборудованию. Сказал, что ща метнется за другими. Сколькими вариантами покупки от производителей сетевику надо озаботиться?
Ни разу не попалось адаптера, который не заработал. Что USB, что PCMCIA или ExpressCard.
Под линуксом, правда, не все проверял.
Вас так компорт бесит — сразу видно, вы никогда не занимались embedded системами, я каждый раз желаю разработчикам здоровья, когда вижу в девайсине COM-порт или хотя бы пинхедеры UART'а
Loopback detection в большинстве случаев требует STP. У 99% свитчей его либо нет, либо по дефолту отключен.

Строили домовую сеть, на оборудование huawei и edge-core, первые после того как выпустили нормальную прошивку перестали требовать включения STP на абонентских портах, вторые же вообще этого не требовали.
А вот с D-Link было все сложнее…
Ихмо правильно настроенная сеть может ограничить все проблемы одним коммутатором/сегментом сети.
Когда вы захотите сделать резервирование между смежными районами дополнительным линком, от STP (RSTP, etc.) никуда не денетесь.
Вы не поверите, у меня вся схема кольцевая, и mstp настроен. Я имел в виду абонентские порты.
> COM-порт — это вообще анахронизм эпохи динозавров

Черт! еще 2 месяца каникул…
Про com порт — у Вас когда нибудь падало «ядро» сети? Как поднимали? Вот Вам и динозавр.
Про свичи — можно купить, везде. И без loopback detection, без storm control. Можно, 99 процентов офисных свичей такие.
>> Во внутренних маршрутах никогда не будет более 15 хопов
Я в это до сих пор верю… :(
Про 9. не совсем понял. Поясните.
>9. Остановка работы компании из-за разрыва линка со стороны ISP — не ваша вина.
ответственность за подобный инцидент лежит, в основном, на ISP.
тем не менее — должен возникнуть и ряд вопросов к сетевику.
на тему «почему отсутствовал / не был задействован резервный канал?»
Непосредственно обрыв — не вина сисадмина. А вот остановка работы — именно что вина.
В случае если не подавал служебку о необходимости резервного канала. Если подавал, но игнорировали — вины нет
> Одного гигабитного линка будет достаточно для всех.
напомнило «640 килобайт хватит всем»
5. Сертификация — незначима.

Это целиком и полностью от конторы зависит. Например я сейчас устроился в одну прекрасную компанию, так там на сертификаты всем наплевать, ибо на собеседовании все ясно станет.
Рассказывали мне, что были случаи сертифицированных сетевиков, которые высчитывали, сколько-же компов в подсети с маской /128 (v4)
Вы меня тоже сбили с толку. Запись /128 автоматом вызывает ассоциацию «128 бит». Секунд 30 пытался понять, то ли лыжи не едут, то ли я…
И до чего додумались? Я так и не понял, что ещё может означать эта запись.
Похоже, что запись должна была означать маску /25
Как по мне, это либо сокращенно от /128.0.0.0, либо уловка, т.е. наебахтунг.
НЛО прилетело и опубликовало эту надпись здесь
Я, простой монтажник, обслуживающий небольшую сеть провайдера, не додумался до такого.
Это сокращенный вариант записи сетевой маски (хотя и записанный немного не правильно, но до введения обозначения /25 довольно часто использовалась) и означает 255.255.255.128 ака /25. И ответ прост 126 компов максимум.
вот только во времена существования IPv6 он моет разве что ввести в транс и заставить почесать репу: что же именно имел в виду автор: опечатался в «v4» и было таки «v6» или же это такой вот анахронизм.
Больше последнее «анахронизм» — это во времена когда «v6» зарождалась.
НЛО прилетело и опубликовало эту надпись здесь
Можете рассказать зачем? В начале 2000-х прочитал в одной из статей, что он только лишь засоряет часть канала. С тех пор всегда его отключаю. Развейте моё представление.
Не засоряет, а резервирует.
Подробнее о механизме приоритезации трафика рассказать, к сожалению, не смогу.
Резервирует? Что, мле, за городская легенда еще?
А это из серии про «Windows по умолчанию резервирует 20% канала, если не отключить QoS в настройках» :-D
При разговоре о приоритизации трафика почемуто забывают что это палка о двух концах. А именно что эта технология работает когда она включена у всех по пути. Сколько провов ее используют на клиентских линках?
Ответ очевиден практически ни кто. Поэтому применение ее сомнительно и сводится на нет.
Не совсем так… Да, полноценный QoS мы можем получить только при соответствующей обработке тегированного трафика на всем маршруте пакета.

Но! На своем роутере мы можем управлять исходящей полосой, регулируя тем самым как исходящий трафик в целом, так и — задерживая определенные пакеты — влияя на входящий.

Это позволяет QoS работать даже в таких условиях.
Если Вас греет факт что голос у ушел первым — то пожалуйста. Но дальше все свалится в одну кучу и плюс ко всему вступят правила шейпинга и приколов оборудования то итог может получится совсем обратным. Как ни скорбно это признавать, но реалии жизни. И как Вы выше заметили что винда при включенной опции режит трафик — чистая правда (как дела обстоят с 7 не знаю но на ХР 100% было влияние).
Если зарезать свой исходящий канал немного ниже максимума, то трафик не будет попадать под шейпер/полисер провайдера, и в кучу не свалится. Вернее, свалится, но позже. Профит небольшой, но будет.
Зарезать — это зашейпить, а причем тогда здесь кос?
Блин… Управляя исходящими пакетами Вы влияете на скорость обмена, в т.ч. на входящий трафик. Есть в сети описание, искать лень.
QoS у себя можно делать только, если шейпить свой исходящий трафик. Т.е. алгоритм таков:
1. Берем где-то 80% от своей исходящей полосы, шейпим до этого значения. Получаем: наши пакеты не будут попадать под шейпер/полисер провайдера, следовательно, провайдер их не будет задерживать.
2. А вот уже внутри этих самых 80% приоритезируем как хотим.
80% от чего считаем? По дефу все роутеры считают от скорости подключения, в редких экземплярах видел ручное указание ширины канала.
Т.к. настраиваем вручную — то от фактической ширины канала.
Под Linux, кстати, для этого есть wondershaper. Указываем интерфейс и исходящую полосу, все сделает само.
Относится к этому коментарию.

Попадаем в сетку провайдера, он метит ваш трафик как хочет, и пускает ваш трафик, весь, под своими приоритетами (это про второй ваш пункт). Тут вася пупкин начинает качать торренты, тем самым завивая канал outbound трафиком, провайдер режет канал, до оговоренной в договоре скорости. И ваш резерв под исходящий трафик. да и как правило трафик inbound меньше outbound. Итого получаем от вашей схемы:
+ можно контролировать только inbound трафик. Полезен когда серверов в вашей сети, много, в тырнет смотрящих. И можно из них выделить более приоритетные и критичные к полосе, но это уже трафик шейпинг.
— загрузка маршрутизатора (или девайса выполняющего маршрутизацию)
— не рабочую приоритезацию.
— затраченное время на вашу работу.
— эффекта практически 0
И если резать то нужно тогда учитывать направление трафика и пр. бубны, а это уже почти мини провайдер дома выходит.
В некоторых домашних роутерах есть просто галочки типа «Включить повышенный приоритет». Как они работают, не знаю, но логика, видимо, та же.

В роутерах на базе Linux часто можно вручную настраивать все, что нужно.
Немного не понятно наверное выразился :( Про направлениями подразумевался трафик деленный по регионам к примеру местный, город, страна и все остальное. Т.е. как пример: подключение физики 10М локальный трафик на макс физ. канала, местный зашейпен 2М, а все остальное (весь мир типа главный инет) 640К.

Вот эта галачка в роутере откуда в курсе где какой ;)
Да, кнопочка скорее всего не в курсе. Но, повторюсь, не знаю как она работает — если по тому же принципу ограничения исходящих пакетов для управления входящими — может и будет работать как-то.

У меня, кстати, та же проблема — при стандартном тарифе в 6 мегабит из пиринга приходит 100, и резать их совершенно неохота. Надо рисовать таблицу исключений в моем микротике для всех подсетей из пиринга, но пока я до такого мазохизма не созрел.
А есть soho роутеры не на основе Linux? На чем они?
VRTX.
Где Вы его отключаете? В свойствах винды чтоль? :-D
Заходите в свойство нужной сетевухи и в списке, вместе с протоколами IP4 и IP6, видите родимый QoS. Берете и удаляете его нафик, именно удаляете — просто отключение результатов не давало (на ХР точно).
Значит уже исправили, молодцы. И данную тему можно смело отнести к разряду байки.
Да Вы сами подумайте — откуда Windows может знать, какая у пользователя полоса и от чего брать 20%?
От скорости соединения сетевухи.
Сетевуха — 100, фактический канал — пусть будет 0.5. Помогло? :)
Мне или КОСу? Если говорить за кос то в этом примере он не будет работать. Но если Вы ему на ухо шепнете что у Вас канал 0.5 то он заработает.

А если говорить за меня то ИМХО — в домашних условиях и на просторах инета кос не нужен (т.к. не работает фактически по разным причинам). А вот в корпоративном сегменте он обязателен.
«в домашних условиях» — «12 заблуждений сетевого администратора» не вижу взаимосвязи. Никто не говорит «о QoS должны знать абсолютно все и в обязательном порядке его использовать».
Ничего не исправляли. Не было никаких «резервов».
Очевидно, статью исправили. Имелось ввиду, что в статье эта байка раньше фигурировала.
В какой статье? В топике? Я его прочитал через 10 минут после публикации, не было там такого.
ZOMG
В википедии статью!
Посмотрите внимательно эту ветку комментариев вверх по дереву — с чего началось обсуждение.
А теперь внимательно читаем историю правок статьи в вики.
Видим, что как этот раздел впервые появился 31 января 2007 года, так и не изменялся существенно с тех пор.
Исправили? Что исправили?
Это была изначально выдумка чистой воды.
Для приоритезации важного трафика (VoIP, gaming, http, IM) перед мусорным (bittorrent и т.д.), конечно же.
Спасибо за разумный ответ человеку, который хочет получить информацию.
Про петлю на свиче/свичах — ОК, не будем об этом забывать. Только что толку, если помнить то будем — как защититься можно?
Не использовать старые говнокоммутаторы.
К сожалению, фирма использует новые говнокоммутаторы ценой > $10K. Не буду называть вендора (не кошка), но вешаются напрочь.
Передайте привет вендору.
регулярно посылаю лучи света… :)
Экстрим, что ли?
Тоже сталкивались?! ;)
Вскользь )
Я никогда не сопровождал коммутаторы/роутеры.
Ну я тоже не сетевик ни разу. Однако столкнулся.
саммиты (650 по крайней мере) вполне умеют как стп, так и свой вендороспецифичный Extreme Loop Recovery Protocol. С трудностями в настройке чего именно вам пришлось столкнуться?
вообще странно, что у вас экстримы работают на акцесе. Они себя тут и не позиционируют. Разве что в дц, но там вероятность лупов минимальна…

интересная задача, в общем. Еще более интересная тем, что настроенный стп (в любой его разновидности) отменяет loopback detection. А ненастроенный свитч за 20 штук баксов это из разряда ненаучной фантастики про планету обезьян. Ну или про Россию, что в принципе эквивалентно.
На коммутаторах есть механизм защиты от этих проблем. Конкретно D-Link этот механизм называет loopback detection. Достаточно включить эту функцию на абонентских портах, чтобы умник с патчкордом остался с задизабленым портом.
Если она есть, непонятно, почему по умолчанию не включена.
Потому что не всегда она полезна. Существует, например, протокол Spanning Tree (и более новый вариант Rapid Spanning Tree), позволяющий работать коммутаторам в кольце, не заваливая сетку ARP запросами в режиме шторма. При его использовании, LoopBack Detection надо выключать на аплинках, иначе коммутатор разорвет кольцо. Что будет, если засунуть абсолютно ненастроенный коммутатор в кольцо STP не проверял, если честно.
Если «тупой» коммутатор связывает два STP коммутатора и пропускает HBPDU без фильтрации — все ок.
Так системное администрирование или все же сетевики виноваты? Если не делится, то может в этом проблема?
Да, про сертификацию. Где получить пачку сертификатов для сетевиков, мы знаем. А где чему новому и интересному поучат уже довольно опытного системного администратора debian-based систем, подскажите? не рутконф и не хайлоад. Реально проблема.
Да нигде. Вот по редхату-сотоварищи — пожалуйста. А дебиан — некоммерческий. Может Шаттлворт чего-нибудь замутит подобное по убунте, вроде хорошо метят в кооммерческое русло. Но это будет по убунте.
> нового и интересного
если ваше желание не замыкается на конкретный дистрибутив — то нового и интересного вокруг хватает.
например, amarao нашел себя в R&D в области облачной xen-виртуализации.

алсо, остаются смежные области в (коммерческие юниксы / cети / vmware / программирование / etc).
проблема в том, что сферического «системного администратора» в вакууме не существует. Есть специализация, вот по ней сертификатов масса. Что по виртуализации, что просто по линуксу (я не вижу других причин, кроме религиозных в отказе от RHCE, даже если ты занимаешься дебианом), что по остальным отраслям. Ради интереса пробовал сдавать пробник рхце — процентов на 80 получалось. В основном заваливались, кстати, именно редхатоспецифичные вещи (я тоже дебианщик).

недавно решил перейти из просто сисадминов в телеком, сдал ццна, сейчас работаю инженером спд в провайдере.
К слову о петлях в сети.
Есть один вендор промышленного Ethernet, который наоборот говорит: Делайте петли.
В их коммутаторах используется технология turbo ring, отключающая порт с петлёй, но задействующая его обратно, если основной линк потерян.

Вот пример подобного коммутатора.
>Делайте петли.
ну, нечто подобное может сказать любой вендор, выпускающий свитчи с поддержкой stp.

другой вопрос, что в данном случае имеет место быть проприетарная фича с очень низким временем сходимости.
В большинстве это делается для уменьшения времени. Это есть у Cisco и Nortel в их протоколах для замены стандартного STP.
>Cisco и Nortel
вы uplinkfast имеете в виду?
У каждого протокол назывался/фича по своему, сейчас по памяти не смогу правильно написать.
В печь вендоров, да здравствует STP
Тогда уж хотя бы MSTP. Им можно не просто отключить порт, а сделать некоторый load balancing — маршрут рассчитывается для каждого VLAN-а отдельно.
Читал коменты про 2 розетки и плакал. Особенно про шторм в тупых свитчах. Час пойдут минусы, но не спешите.
Для понимания немного теории: в природе существуют 2 типа кабелей это патч-корд и кросовер или как в народе называют «перевертыш». Первый это кабель который соединяет один к одному, а второй меняет основные сигналы на своих разьемах и служит для соединения однотипных портов.
И ответ на вопрос что будет если соединить 2 розетки (для тупых свитчей) — не чего не будет. Причина проста — при соединении патч-кордом 2 одинаковых порта (а розетки это удлинение портов) соединяются между собой передатчики и приемники, поэтому линка не будет. А вот если вы примените кросовер то соединение будет корректным и дальше зависит все от самого свитча, вплоть до шторма.
На сегодняшний день в определенных свитчах ставят порты с авто детектом и ситуация со штормом возможна, но в большинстве своем эти свичи имеют защиту от шторма. Поэтому ответ «не чего не будет» 40-50% будет справедлив.
Если брать свитчи современные и класса выше среднего то ответ почти в 90% также будет — нечего. У разных производителей есть как фирменные защиты так и реализация STP протокола.
вы правы, конечно.
но есть нюансы (ц)
1. loopback-detect / stp по умолчанию включен далеко не у всех вендоров.
2. свитчи топовых вендоров на access ставятся далеко не всегда :(
У D-Link 2-3 серии есть и фирменная защита и поддержка STP и, самое главное, автоопределение.
Шторм будет.
Потому что loopdetection выключен по умолчанию, STP выключен по умолчанию, autonegotiation включен, пока скорость порта стоит в auto (а это тоже по умолчанию).
Вопрос, почему коммутатор без изменения настроек попал в сеть — к системному администратору. Тут он сам себе альтернативно добрый дендроантропоид.
Тогда ответим на вопрос так: 50/50% или будет шторм (не корректно настроен, всунули правильный провод и пр. нужное подчеркнуть или дописать) или не будет (хвала вендору или админу).
НЛО прилетело и опубликовало эту надпись здесь
Ко-ко-ко. Я знаю имеет ли еще значение кросовер или нет, ибо я уже давно соединяю компьютеры первым попавшимся кабелем. Современным сетевушкам просто уже плевать на это. У меня есть компьютер который кросовером соединен со свитчем и пара компьютеров соединенных патч-кордом.
правильно писать не че го
угу, а еще правильнее:
н е ч е г о
3. Бессмысленно проверять возможность удаленного управления оборудованием перед отправкой в удаленный офис.
Вы — профессионал и не могли ошибиться в настройке такой элементарной функции.

Из личной практике: только в 30% случаев можно на 100% проверить настройку удаленного оборудования перед отправкой. По этой причине предпочитал тунить по месту, предварительно ест. настраивая. А приколы даже в стандартной и многократной реализуемой схемой включения бывали в плоть до применения бубна.
>только в 30% проверить настройку удаленного оборудования
настройку — полностью — да.
но из личного опыта могу сказать, что работоспособность remote-mgmt проверять нужно в 100% случаем.
иначе — удаленный тунинг после установки может быть затруднителен.

или вы имели в виду физическое присутствие при монтаже железки?
Именно. И как показала практика лучше немного потратится конторе на командировки и развернуть базовую инфраструктуру на местах, чем отдавать на откуп местным админам (в дальних регионах как ни стыдно признавать класиф. низка и меняются часто). Вспомнился случай когда местный умудрился завалить цыску в полный ноль (не было даже иоса внутри), на его счастье в тот же день подключал в его регионе клиента и оказал братскую помаш :)
в дальних регионах как ни стыдно признавать…
В дальних регионах, как не прискорбно признавать, сильно экономят на расходах на классиф. персонал, оттуда большинство (хоть и не все) проблемы.
Вдогонку — вот в здесь какраз и пригодился компорт на все 100%. Поэтому ИМХО его списывать в со счетов истории рано.
+ английский мне ни к чему, много информации и на русском
Не по теме — народ когда минусуете хоть пишите свое мнение, а то выходит полная непонятка.
Тут это не принято.
Хоть на этом спасибо.
Жизнь слишком коротка, чтобы объяснять каждый — и +
Плюсы объяснять, обычно, не просят. Минусы — не хотят.
Никто никогда не соединит 2 сетевые розетки патчкордом. Зачем это делать?


Лол, недавно на работе ставили кондиционер прямо над моим рабочим местом. Доблестные рабочие вытащили патчкорды, чтобы не мешали, а по завершению установки воткнули ethernet-выход цискофона в порт, причем сам цискофон был включен в соседний.

Полчаса ушло на выяснение причины почему сеть у всех отвалилась :)
а насчет ISP не всегда миф =) там ведь такие же админы с такими же заблуждениями. Может у них кто-то розетки замкнул =)
13. Никто никогда «не подключит вход ИБП к его собственному выходу». Зачем это делать?
Вот теперь меня подмывает проверить, а что будет?
сыграли сценку по сценарию башорга: bash.org.ru/quote/393159

а так в гугле полно ответов на ваш вопрос
НЛО прилетело и опубликовало эту надпись здесь
А я так надеялся…
По поводу ISP — не совсем правда. Иметь своего человека в структуре провайдера, желательно повыше, чем просто саппорт — гораздо лучшее подспорье, чем куча бумажек с подписями и печатями. Проверено не однократно.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории