Comments 22
Потрясающе. Как бывший админ сетки в общаге КПИ очень хорошо вас понимаю :).
Больше всего толку (для мозгов!) именно когда гугление не помогает а делать чтото надо
Я рад, что еще есть люди, которые имеют время на такие оптимизации. Но сегодняшние реалии таковы, что чаще дешевле купить новое оборудование, чем стоимость труда инженера. Хотя, наверное, может быть иначе, раз в вашем случае это работает.
А я вот не очень понял. Зачем нужно было бриджом объединять на сервере? Неужели не было подходящих свитчей в то время? Я как помню — были. Как дальше бороться с халявщиками — другой вопрос. На самом деле, наверное в этом стыдно признаться, но в сети на 1000 клиентов, где я админ, есть простая привязка по dhcp ip-mac и никакого контроля, в случае если абонент ip пропишет чужой. Случаи появления халявщиков бывают — но с помощью управляемых свитчей на раз вычисляется кто халявит и применяются административные наказания типа отключения от сети и платного подключения. Если всё же требуется 100% защиты от халявщиков — можно было поставить vpn (сейчас более модно pppoe).
Ещё интересно, какие порядки трафика были, когда сервера не справлялись?
Ещё интересно, какие порядки трафика были, когда сервера не справлялись?
Бридж был интересен тем, что создавалась «плоская» сеть, и большое количество ПО (игры, «сетевое окружение», бродкаст-чаты, и тому подобное, что использует бродкаст-пакеты для обнаружения) работало нормально. При этом можно было ограничивать доступ заблокированным абонентам до некоторых выборочных ресурсов сети (или наоборот, оставлять выборочные) которые находятся в его «псевдосегменте» сети.
К примеру:
-у шлюза адрес a.b.c.1/24
-у вас адрес a.b.c.2/24
-у вебсервера1 адрес a.b.c.3/24
-у вебсервера2 адрес a.b.c.4/24
В можете попасть на вебсервер2, а при попытке зайти на вебсервер1 попадаете на «страничку-информатор». При этом вроде как трафик даже через шлюз не проходил с точки зрения клиентской ОС.
Управляшки в то время были, но 300$ стоила управляшка с RS232+WEB (без snmp и telnet/ssh) которая умела поднимать/опускать порты, показывать статистику на портах и ТОЛЬКО port-based VLAN (без 802.1q). То есть по сегодняшним меркам даже недолевел2. Ни о каком ограничении доступа на уровне этих железок речи идти не могло, во всяком случае за вменяемые деньги.
К примеру:
-у шлюза адрес a.b.c.1/24
-у вас адрес a.b.c.2/24
-у вебсервера1 адрес a.b.c.3/24
-у вебсервера2 адрес a.b.c.4/24
В можете попасть на вебсервер2, а при попытке зайти на вебсервер1 попадаете на «страничку-информатор». При этом вроде как трафик даже через шлюз не проходил с точки зрения клиентской ОС.
Управляшки в то время были, но 300$ стоила управляшка с RS232+WEB (без snmp и telnet/ssh) которая умела поднимать/опускать порты, показывать статистику на портах и ТОЛЬКО port-based VLAN (без 802.1q). То есть по сегодняшним меркам даже недолевел2. Ни о каком ограничении доступа на уровне этих железок речи идти не могло, во всяком случае за вменяемые деньги.
да управляшки и не сильно нужны (хотя они конечно очень помогли). у вас проблема халявщиков решалась для 1/6 сети всё равно. т.е. не полностью. чем 1/6 сети отличается от единой сети, в случае даже тупого свитча, если проблему всё равно не решить полностью? и я не понял, какие всё таки порядки трафика были?
и да. тупым свитчём можно было сделать плоскую сеть. и интересно, сколько вы платили за такой канал, как вы описали в то врёмя?
Вообще-то не для 1/6, а для 5/6. То есть злоумышленник имел возможность подставить только примерно 16% МАС из общего числа, причем он в точности не знал, какие пары MAC-IP относятся к его сегменту. А тут уже была возможность мониторить, на каком порту бриджа вдруг стали появляться нелигитимные МАСи (brctl showmacs br0) и принимать какие-либо административные меры.
После установки свичей, которые могли слать SNMP-traps этот функционал был расширен таким образом:
в случае, если МАС «перепрыгнул» с порта на порт, то адрес блокировался, и клиентов заворачивало на спец-страничку, где для разблокировки предлагалось ввести логин/пароль. В этом случае получалось уже не 5/6 отсекалось, а выбор у злоумышленника оставался примерно в 5-7 МАС-адресов (соседи по неуправляемому свичу, компьютеры которых в данный момент выключены) из 1000 клиентов, или менее 1%. И такой подход очень сужал территориальное место поиска злоумышленника, единственное, что нужно было дойти ногами до конкретного свича и по очереди выключать кабели с активным линком. А иногда удавалось и без этого: пропал один МАС на порту — и тут же появился другой (у которого «пропажа трафика»). Что наводило на вполне обоснованные подозрения, и отключение кабеля было уже только для того, чтобы окончательно убедиться.
После установки свичей, которые могли слать SNMP-traps этот функционал был расширен таким образом:
в случае, если МАС «перепрыгнул» с порта на порт, то адрес блокировался, и клиентов заворачивало на спец-страничку, где для разблокировки предлагалось ввести логин/пароль. В этом случае получалось уже не 5/6 отсекалось, а выбор у злоумышленника оставался примерно в 5-7 МАС-адресов (соседи по неуправляемому свичу, компьютеры которых в данный момент выключены) из 1000 клиентов, или менее 1%. И такой подход очень сужал территориальное место поиска злоумышленника, единственное, что нужно было дойти ногами до конкретного свича и по очереди выключать кабели с активным линком. А иногда удавалось и без этого: пропал один МАС на порту — и тут же появился другой (у которого «пропажа трафика»). Что наводило на вполне обоснованные подозрения, и отключение кабеля было уже только для того, чтобы окончательно убедиться.
Привет Максу от Онибаки 8)
Нескромный вопрос — и сколько там трафика при изображенной на графичках нагрузке?
Тяжело сказать, «сколько трафика», потому как не ясна методика подсчета :)
Начать с того, что в данной ситуации влияние оказывает не столько трафик в мегабитах, сколько пакетрейт (pps), так как именно пакетики каждый раз генерировали прерывания, и проходили цепочки iptables и других структур ядра. Особенно портили жизнь кольца на свичах, так как loopdetect отрабатывал не сразу (а порой вообще не отрабатывал) и весь закольцованный трафик, перекидываемый быстрыми специализированными микрухами коммутаторов, летел через многострадальный бридж.
Статистики по пакетрейту, к сожалению, у меня нет. Зато есть данные по трафику в мегабитах, в rrd.
Методику подсчета «общего трафика» использовал такую: брал для каждого физического интерфейса среднее значение входящих байт за час, и прибавлял к нему среднее значение исходящих байт за час. За час — потому что так ужимает rrd, пиковые безусловно могли быть заметно больше, но данных не осталось. Потом сложил получившиеся значения для всех интерфейсов.
В итоге получилось 3.1Гбит/с
Посмотрев текущую загрузку на загруженном порту одного из коммутаторов, выявил, что средний размер пакета где-то 900 байт плюс-минус.
Следовательно, при 3.1Гбит/с и размере пакетика около 900байт получаем пакетрейт 450 тысяч пакетов в секунду.
Наверное, правильнее было бы его разделить на 2, так как при суммарном битрейте использовался входящий и исходящий трафик, а сам сервер пакеты практически не генерирует, то есть весь трафик — транзитный. Значит средний пакетрейт за час выходит около 250 тысяч пакетов в секунду, без учета возможных кратковременных всплесков.
Начать с того, что в данной ситуации влияние оказывает не столько трафик в мегабитах, сколько пакетрейт (pps), так как именно пакетики каждый раз генерировали прерывания, и проходили цепочки iptables и других структур ядра. Особенно портили жизнь кольца на свичах, так как loopdetect отрабатывал не сразу (а порой вообще не отрабатывал) и весь закольцованный трафик, перекидываемый быстрыми специализированными микрухами коммутаторов, летел через многострадальный бридж.
Статистики по пакетрейту, к сожалению, у меня нет. Зато есть данные по трафику в мегабитах, в rrd.
Методику подсчета «общего трафика» использовал такую: брал для каждого физического интерфейса среднее значение входящих байт за час, и прибавлял к нему среднее значение исходящих байт за час. За час — потому что так ужимает rrd, пиковые безусловно могли быть заметно больше, но данных не осталось. Потом сложил получившиеся значения для всех интерфейсов.
В итоге получилось 3.1Гбит/с
Посмотрев текущую загрузку на загруженном порту одного из коммутаторов, выявил, что средний размер пакета где-то 900 байт плюс-минус.
Следовательно, при 3.1Гбит/с и размере пакетика около 900байт получаем пакетрейт 450 тысяч пакетов в секунду.
Наверное, правильнее было бы его разделить на 2, так как при суммарном битрейте использовался входящий и исходящий трафик, а сам сервер пакеты практически не генерирует, то есть весь трафик — транзитный. Значит средний пакетрейт за час выходит около 250 тысяч пакетов в секунду, без учета возможных кратковременных всплесков.
что-то у вас не здоровое число трафика для студентов, которые по идее должны пользоваться научным контентом.у нас от тысячи абонентов с безлимитами меньше трафика в разы. какое количество пользователей у вас было?
В самом начале статье есть упоминание про кол-во пользователей:
сервер до сих пор живет и обслуживает сетку из 1000 машинНасколько мне известно, в разные времена оно плавало вокруг этой цифры: было больше во времена мегабайтного трафика, стало меньше сейчас во времена анлима. Раньше довольно крупную часть трафика генерили пиринг с локалкой, щас в пиринг летит малая часть (около 15% по nsk-ix), остальное внешка. То есть, несмотря на добавление в пиринг новых операторов, студентам стало проще находить нужный «научный контент» на ютубе и торрентах ;-)
что-то у вас не здоровое число трафика для студентов, которые по идее должны пользоваться научным контентом.
Хорошая шутка. По-вашему, студенты не играют в игры, не смотрят видео? А если учесть, что интернет помегабайтный, то локальный p2p становится только важнее.
Например, в Харьковском Политехническом в 2009-м году до сих пор была жива помегабайтная оплата и невероятно популярен DC++ с локальными серверами.
Первый безлимитный тариф в стенах общаг вышеописанного универа появился в апреле 2010 емнип, у него даже название было «весенний» и народ шутил, что к лету отменят и вернут мегабайты. Не вернули.
Правда Макс вполне может возразить, что анлим был на заре описанной в статье эпохи. Я те времена не застал.
Правда Макс вполне может возразить, что анлим был на заре описанной в статье эпохи. Я те времена не застал.
Сел читать статью и с каждой строкой глаза все больше лезли на лоб! Я уж было подумал, что кто-то из старой гвардии (green, madmax, abs) решил тряхнуть стариной и рассказать как это все было в НГУ. Всё было точно так же — и воздушки П270, и сервера с OSPF и тремя сетевухами, и грозди неуправляемых свичей и тд. А потом настал 2004 год, когда университет по проложенной еще при царе горохе на деньги Сороса оптике стал организовывать нормальную сеть в общежитиях.
Надо будет как-нибудь собраться с духом и написать историю про наш вуз, благо еще не все забыто и не все контакты потеряны.
Надо будет как-нибудь собраться с духом и написать историю про наш вуз, благо еще не все забыто и не все контакты потеряны.
очень интересно. а можно вопрос:
local6.info -/var/log/dhcpd.log — эта строчка отключает лог dhcpd?Нет. Указание минуса перед именем файла отключает sync на диск при каждой записи в лог, что повышает производительность, но может привести к тому, что при сбое данные могут оказаться фактически не записанными на диск.
Выдержка из man syslog.conf на эту тему:
Выдержка из man syslog.conf на эту тему:
You may prefix each entry with the minus ''-'' sign to omit syncing the file after every
logging. Note that you might lose information if the system crashes right behind a write
attempt. Nevertheless this might give you back some performance, especially if you run
programs that use logging in a very verbose manner.
Странная идея использовать user-space утилиты подсчёта трафика, игнорируя ipt_netflow на основании того, что «Netflow и так использует верхний провайдер для СОРМ».
Поподробнее, пожалуйста, про ipt_netflow в 2004-2009 гг
Ну либо Вы невнимательно читали статью. Имелось ввиду, что необходимость в учете трафика на описываемой машине пропала к моменту выхода Ipt_NETFLOW, а до этого приходилось пользоваться юзерспейс утилитами за неимением ничего другого. В данный момент на этом сервере сбор netflow не ведется.
Ну либо Вы невнимательно читали статью. Имелось ввиду, что необходимость в учете трафика на описываемой машине пропала к моменту выхода Ipt_NETFLOW, а до этого приходилось пользоваться юзерспейс утилитами за неимением ничего другого. В данный момент на этом сервере сбор netflow не ведется.
Sign up to leave a comment.
Девятилетняя оптимизация маршрутизатора