Pull to refresh
0
0
Send message

Подобная статья должна быть по каждой специальности, а четкий грейд и требования у каждой уважающей себя компании. А то такой бардак из-за тех, кто хочет вкатиться в IT/ИБ с курсов сразу в зарплату 200+

свежего софт в репозиториях к старой версии линукс дистрибутива не будет, будут актуальные для той версии - что на тот год было актуально. Именно поэтому нужен дистрибутив, который собирается под конкретную архитектуру из исходных кодов, пока в этих исходных кодах остается эта поддержка, а то уже и из ядра линукса IA-64 выдрали.

это не старый, у меня на работе серверам по 12 лет и они в продакшене отлично справляются со своими задачами с кучей контейнеров на борту.
Не старый он для меня, не старый он и из контекста статьи. В статье речь про компьютер 2004 года, на устаревшей для многих дистрибутивов архитектуре х86_32

Вижу люди разделились на два лагеря: "Круто!" и "Пушки и воробьи с прицепами"
Я автора немного понимаю.

Не понимаю только в выборе ограниченной опенврт, это легковестный линукс дистрибутив все же не раскрывает мощь миникомпа, который можно было подключить к ТВ и смотреть всякое.
К примеру KODI+квазар, а на роутере впн, то мы уже можем смотреть фильмы сразу с торрентов не дожидаясь их полной загрузки. Видео по запросу от пиратов выходит.
роутер лучше справится, чем х86 с 2 вещами: wifi и энергопотребление(важно не только при оплате коммуналки, но и при наличии умного дома и отдельного упса хоть на паре-тройке 18650)
на х86 поднимаем то, с чем он лучше справляется: умный дом(на мощный роутер можно запихнуть, но не всегда), твприставка, сетевой диск, да даже игровая консоль(если слабая, то ретроигровая консоль!)

Бывают люди, которые не хотят обучаться, или такие, которые не хотят тратить время и у них найдутся свои причины. И вот тогда от пряника придется переходить к кнуту - к обязательным аттестациям. А то ведь все вроде бы курс прослушали, расписались в журнале по пожарной безопасности, а склад горит, ну как так ? Может дело и в ответственности, вернее в безответственности сотрудников на местах, где может быть совершен даже непреднамеренно существенный ущерб.

Не понимаю практического опыта использования старого ПК, жесткие диски изнашиваются, элементы выходят из строя на матплате. Только как реставрация, поставил дистрибутив и забыл, потом достал и показал внукам.

Однако возникает множество проблем при работе в сети, теже CA сертификаты на системе устаревают, надо уметь их обновить и связанный с ним софт, возможно, тоже потребует обновления, библиотеки ssl/tls, без них тяжело в Интернете будет.

Все же наиболее рабочим вариантом и универсальным было бы сделать себе свой дистрибутив или дистрибутив на основе чего-то из исходников, вроде Gentoo. Собирать софт под нужную архитектуру, автор хоть и жалуется, что не смог, но рано как-то руки опустил.

Вот взять тот же Openwrt в его списке, он собирается аналогично при помощи кухни toolchain под множество платформ и архитектур, я сам собирал, главное иметь рабочую кухню. И пакет современный можно пересобрать обычно под нужную архитектуру. Проблема только возникнет, что может не пройти под минимальные системные требования, такие как оперативная память.

Пользователя еще бы не забыть создать и пароль ему навесить или rsa ключ для ssh добавить, или для рута, но в конфиге sshd не забыть разрешить вход от него.

Вообще странно использовать бинарные дистрибутивы на современных мощных процессорах, когда эти самые дистрибутивы в силу поддержки старых процессоров скомпилированы с кодом, который не использует avx или sse4.2... Хотя учитывая, что современные тенденции разработки ушли от оптимизации в сторону упрощения разработки и запуску всяких микросервисов или кода на питон - то тут выигрывать особо не на чем.

> Я могу по отдельности нагрузить одно зеленое и одно красное. TDP не будет превышено, но зеленое выше 3.8 не будет.
Вот именно этого статье и не хватало, при этом загружать надо без avx
То что турбобуст не на все ядра - это особенность моделей, в которые зашиты в микрокод режимы работы этого турбобуста.
Вот на таких ресурсах это все освещено https://xeon-e5450.ru/socket-2011-3/e5-1600-v3/e5-1650-v3/
Почему они так зашиты - это одному интелу известно, мб TDP, мб отбраковка ядер, на разных ревизиях тоже разная картина. Преодолеть зашитые режимы и разогнать ядра на процессоре тоже можно.

Мне кажется, вы сделали неправильные выводы.
Возьмем ваш график от rrd, в нем видно, что красные ядра выше зеленых на них, НО, как несложно понять, это явно заметно только при полной загрузке процессора, нет на графике момента, когда зеленые были бы ниже, и вверх ушли бы красные(например на красное ядро ушла тяжелая однопоточная задача).
Я все к чему это говорю: вполне вероятно, что процессор не может задать максимальную частоту этим ядрам не потому, что они медленные с рождения, а потому, что у вас нагрузка процессора превышена по TDP, поэтому он замедляет эти ядра. Истина где-то в микрокоде. Это мое предположение того, что происходит у вас, у меня же есть процессоры 26xx v3 и v4, при этом v3 с модифицированным bios на матери и анлоком турбобуста на все ядра, и на предыдущем поколении я не могу подтвердить существование медленных ядер. Однако эффект снижения на 100-200мгц частоты я видел уже, это происходило при выполнении avx/avx2 инструкций на ядрах.

Лет 10-12 назад у pf были проблемы с работой в многопоточных архитектурах, много времени утекло, может быть и решили эту проблему, но что там с тестами на 10Гбит ? Я помню проблема уже была заметна при 2.5-5Гбит транзитного трафика(т.е. по 5-10Гбит суммарно на два интерфейса) при nat трансляциях.
Ну и да, заголовок кликбейтный, я уж думал увидеть тут реализацию на dpdk, на которой многие фаерволы начали пилить как раз лет 10 назад, впрочем, и на малолитражки тоже есть спрос...

Циклы чаще всего возникают из-за неправильной настройки, либо из-за того, что запрашиваемый адрес из-за аварии стал недоступен, но до него есть настроенная маршрутизация (статическая, как правило, либо залипший бгп). И как только это становится проблемой, тогда это начинают чинить, прописывают маршруты в null, но везде солому подстелить нельзя, поэтому проблема в текущей версии IP и протоколов маршрутизации (статика, бгп, оспф) останется.

 

Что касается анализа, то делать это на неподконтрольном участке сети, прямой путь игры в угадайку. Ну например мы трейсим/пингаем адрес, а он находится за натом + в цепочке маршрутизаторов, у этих маршрутизаторов непубличные адреса могут быть, трейсим может быть мы вполне реальный публичный адрес, который, возможно даже(а может и нет), принадлежит конкретному хосту, но по пути маршрутизаторы будут нам отвечать со своих 192.168.0.1, 1.1, 2.1 и неизвестно каких адресов, нат это все дело оттранслирует, и мы получим ответ от адреса из NAT-пула :) Конечно, так мы поймем, что кольцо есть, но между кем и кем - эта информация будет покрыта мраком. Это может относиться к слайдам 32 и 33.

 

Еще мы можем захотеть потрейсить адрес, который находится за устройствами, которые не отвечают на ttl-exceeded - мы не получим информации о петле; не уменьшают ttl при проходе через маршрутизатор - не будем знать, что кто-то маршрутизировал пакет между узлами; специально меняет ttl на статический или заведомо уменьшает или увеличивает - это вовсе будет ломать картину и покрывать все мраком(слайд 29-30), что в добавок может приводить к бесконечным петлям, но случайно такое редко делают; может проходить через устройство, которое не маршрутизатор, но меняет ttl, чтобы уберечь себя от петель - например это может быть прозрачный NAT в режиме бриджа, он может уменьшать ttl и отвечать, а может не отвечать. Да и еще много чего может быть, может быть маршрутизация на основе не адреса назначения, а на основе адреса источника (сорс роутинг)(слайд 32-33), а адрес источника или назначения может поменяться на NAT(или если его развернуть на 180 градусов - на балансировщике).

Вообще в моей практике было так, что пакет приходил из Интернета, попадал на пограничный маршрутизатор, там был маршрут статический на NAT, проходил через NAT, там адрес назначения менялся(трансляция была создана исходящим пакетом из ЛВС в Интернет перед этим), дальше маршрутизатор в ЛВС получал пакет, но сеть, куда он должен был отправить его, стала внезапно недоступна, выпала из bgp, но у него был адрес по умолчанию - в Интернет! Теперь тот же пакет попадал в NAT уже со стороны локальной сети, но адрес назначения у него оставался старым (адрес из NAT-пула), поэтому пограничный маршрутизатор снова его отправлял в NAT, и так пока по ttl не убивал кто-то пакет.

 

Надо понимать, как работает трейс и ответы на ttl exceeded. Во-первых, проходя через маршрутизатор ttl уменьшается на единицу, но на это поле могут повлиять не только маршрутизаторы, да и они могут быть так настроены, чтобы не менять это поле, это лишь правило, которое работает по умолчанию, не всегда можно понять, особенно на неподконтрольном участке сети, что есть какие-то махинации с этим полем. Во-вторых, маршрутизатор (или другое устройство) нам отвечает не от того же ip интерфейса, с которого оно получило или отправит пакет дальше, оно отвечает нам с того интерфейса, с которого есть маршрут до вас (с запрашиваемого адреса), и путь пакета в одну сторону может отличаться от пути пакета в другую сторону, и не факт что в другую сторону пакет до вас дойдет.

Представим себе путь адрес1 -> маршрутизатор1 -> маршрутизатор2 -> маршрутизатор3 -> адрес2, в другую сторону путь будет как адрес2 -> маршуризатор3 -> маршрутизатор4 -> маршрутизатор1 -> адрес1. У маршрутизатора2 и 4 будут еще и другие интерфейсы (не зря же они - маршрутизаторы), и допустим, если на адрес1 у маршрутизатора3 будет неверный маршрут (или маршрут через линк, где есть авария), то ответный пакет с ttl-exceeded адрес1 не получит, но трафик при этом будет ходить в обе стороны исправно. А если и ответ все же дойдет, то он будет с ip интерфейса, который будет отличаться от адресов на линках с маршрутизатор1 и 3. Входящий и исходящий трафик в Интернете очень редко (ну очень) проходят симметричный путь.

А что касается того, что основные петли у AntiDDOS и CDN – то это может объяснить балансировщиками и прочим аналогичным оборудованием, на который маршруты прописаны статически на одном пути, а на другом нету маршрута в null, как в моей истории выше.

датчики сами делали, они подстраиваются под засветку и не реагируют на фон, а только под колебания.
Синхронизация похожа на ntp протокол, только выполняется поверх serial соединения. Внутренний таймер работает по тактовой частоте, который убегает не больше чем на 0.001с за пару часов, так что время от времени проводится синхронизация. Вообще чтобы так точно работала тактовая частота — пришлось подбирать кварцевые резонаторы и конденсаторы. Про диффузионные оптические датчики много информации в интернете, в двух словах: датчик посылает сигнал и смотрит на отражение сигнала.
Я с другом делал телеметрию, но у нас были другие приоритеты: ориентированность на драг-рейсинг или на единичные заезды.
Что в итоге получилось:
— система абсолютно автономна, не нужны никакие ноутбуки (вы в своей статье про это в итогах тактично «забыли» упомянуть)
— система компактна: всего два блока(старт и финиш), нет никаких датчиков через дорогу(используются датчики диффузионного типа)
— вывод результатов происходит в реальном времени на экран средних размеров
Ну и все остальное как у вас: работает долго, без проводов на расстоянии до 800м, точность до 0.001с
Бюджет тоже небольшой, но продавали мы ее гораздо дороже(надо же как-то окупить временные затраты на программирование и сборку).
Видео с первым прототипом вот(корпус был выполнен весьма грубо :))
http://www.youtube.com/watch?v=SJhjnycR8RE
По поводу идентификатора сети. Хосту вообще запрещается назначать адрес идентификатора его же сети, по правилам распределения адресов нельзя указывать идентификатор хоста, состоящий только из нулей или только из единиц. Почему? Думаю уже мало кто вспомнит, возможно из-за аппаратного обеспечения, чтобы хосты нумеровались с единицы и так далее, а не с нуля. А почему не с нуля — это надо глубоко лезть в аппаратное обеспечение, наверняка там найдется ответ у какого-нибудь вендора.
в моей практике в двух провайдерах на протяжении более 6 лет подключали по многопарнику как Бог на душу положит, брали любые две пары, в итоге никакого криминала, у всех все работает, расстояния были до 100м + использовался кросс. Да и в глаза не видел от производителя вообще каких либо рекомендаций по многопарникам.
нет проблем в выделении этого шума и его ликвидации при восстановлении сигнала, шум будет всегда, поэтому никто не заметит разницы для 100Base-T, а для 1000Base уже используется другая категория кабеля.Так что это не более чем позолоченные разъемы у HiFi акустики с обедненной медью.
не вижу катастрофы, дифференциальный метод передачи сигнала решает проблемы с этими маломощными наводками.
B. 14 Кроме вашего ответа, есть еще другая ситуация: когда ЦПУ маршрутизированного устройства загружено, а маршрутный процессор нет, то пакет маршрутизируется без задержек, когда как ответ от ЦПУ маршрутизатора на всякие icmp запросы может вызвать задержку.
Б. 17 — это дела вендора, у каждого вендора есть свои закидоны на эту тему и от железки к железке внутри вендора тоже.
это вы сейчас про многопарник или про витую пару 6ой категории? Не путайте одно округлое с другим продолговатым.

Information

Rating
Does not participate
Registered
Activity