Jump to content

Зашивается сервер MT. Помогите.


Recommended Posts

  • Replies 109
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

i7 умирает на 400Мбитах?? Это нонсенс какой-то, наймите админа который софт в порядок приведет. А лучше вообще снесет этот убогий МТ. Такое железо должно гиг вывозить даже на 1 ядре в самом ужасном с

Які мережеві і який трафік? Скільки клієнтів через нього ходить? NAT є?   Є 4 виходи із ситуації. 1. Спростити фаєрвол і шейпер. Якщо НАТ на цій машині - винести на іншу. 2. (не відміняє перший) -

викиньте нах@р компьютер. поставьте L3 коммутатор.

Posted Images

В linux для этого есть магическое слово 'ipset'. Как реализовать подобное в MT - думайте сами, хз.

Вообще абсолютно не обязательно доступ разрешать/запрещать в фаерволе. Есть разные дизайны BRASов, в своем новом soft-IPOE я вообще фаервол не использую(2 правила на доступ к самому серверу по ssh) - а значит машина без НАТа сможет жевать десятки гигабит и миллионы PPS - жизнь одмина будет спокойной и размеренной :)

Link to post
Share on other sites

А как тогда разрешать/ запрещать доступ в интернет если будет на группы?

 

Это очевидно. Создайте групу забаненых :)

 

Можно также маршрутизировать его в нуль

Edited by andryas
Link to post
Share on other sites

фаервол переписать что-бы правила были иерархичесими. сейчас у вас среднестатистически пакет проходит 900\2=450 правил. трехуровневая иерархия даст 10-30 правил.

акцеслист на 900 сравнений - эквивалент цепочки из 900 правил, если поиск в ней не оптимизирован, но я такого не встречал на программных роутерах.

убирите нахрен ДХЦП с трафиковых интерфейсов. ДХЦП парсит все транзитные пакеты на МАС уровне - это жрет производительность похлеще фаервола. вынесите ДХЦП на отдельный таз или хотя-бы на отдельный физический интерфейс (хотя в МТ так не катит вроде).  

Edited by ntil
Link to post
Share on other sites

фаервол переписать что-бы правила были иерархичесими. сейчас у вас среднестатистически пакет проходит 900\2=450 правил. трехуровневая иерархия даст 10-30 правил.

убирите нахрен ДХЦП с трафиковых интерфейсов. ДХЦП парсит все транзитные пакеты на МАС уровне - это жрет производительность похлеще фаервола. вынесите ДХЦП на отдельный таз или хотя-бы на отдельный физический интерфейс (хотя в МТ так не катит вроде).  

С фига ли DHCP чего-то там парсит и жрет? Он свой порт слушает и чихать ему на трафик, пакеты, маки и т.п.

Link to post
Share on other sites

 

С фига ли DHCP чего-то там парсит и жрет? Он свой порт слушает и чихать ему на трафик, пакеты, маки и т.п

"проверено электроникой" на себе - парисит на МАС уровне - что на МТ что на линуксе. подтверждено ковырятельством в сырцах.

кстате наверно не спроста требуется установленная опция "reorder MAC header" на VLAN интерфейсе в линксе для корректной работы ДХЦП, правда ?

МАС пакета кстате нужен для поддержки LEASE DB :) так-что он парсится, откуда ведь он берется?

Edited by ntil
Link to post
Share on other sites

 

фаервол переписать что-бы правила были иерархичесими. сейчас у вас среднестатистически пакет проходит 900\2=450 правил. трехуровневая иерархия даст 10-30 правил.

убирите нахрен ДХЦП с трафиковых интерфейсов. ДХЦП парсит все транзитные пакеты на МАС уровне - это жрет производительность похлеще фаервола. вынесите ДХЦП на отдельный таз или хотя-бы на отдельный физический интерфейс (хотя в МТ так не катит вроде).  

С фига ли DHCP чего-то там парсит и жрет? Он свой порт слушает и чихать ему на трафик, пакеты, маки и т.п.

 

Слухає, DHCP на окрему машину, однозначно.

Link to post
Share on other sites

 

 

С фига ли DHCP чего-то там парсит и жрет? Он свой порт слушает и чихать ему на трафик, пакеты, маки и т.п

"проверено электроникой" на себе - парисит на МАС уровне - что на МТ что на линуксе. подтверждено ковырятельством в сырцах.

кстате наверно не спроста требуется установленная опция "reorder MAC header" на VLAN интерфейсе в линксе для корректной работы ДХЦП, правда ?

МАС пакета кстате нужен для поддержки LEASE DB :) так-что он парсится, откуда ведь он берется?

Да нет, ерунда какая-то. Слушает себе сервис порт 67 на заданных интерфейсах, туда ему запросы с MACами и прилетают. И ничего оно не 'парсит' и не 'жрет'.

Link to post
Share on other sites

 

 

 

С фига ли DHCP чего-то там парсит и жрет? Он свой порт слушает и чихать ему на трафик, пакеты, маки и т.п

"проверено электроникой" на себе - парисит на МАС уровне - что на МТ что на линуксе. подтверждено ковырятельством в сырцах.

кстате наверно не спроста требуется установленная опция "reorder MAC header" на VLAN интерфейсе в линксе для корректной работы ДХЦП, правда ?

МАС пакета кстате нужен для поддержки LEASE DB :) так-что он парсится, откуда ведь он берется?

Да нет, ерунда какая-то. Слушает себе сервис порт 67 на заданных интерфейсах, туда ему запросы с MACами и прилетают. И ничего оно не 'парсит' и не 'жрет'.

 

Матчасть читайте. Нет никакого порта (и даже хоста), пока клиент не получил IP. Запрос на её получение широковещательный. Сначала работает 2-й уровень сети, вот поэтому DHCP сервер парсит широковещалку, которая к нему прилетает.

Link to post
Share on other sites

 

Да нет, ерунда какая-то. Слушает себе сервис порт 67 на заданных интерфейсах, туда ему запросы с MACами и прилетают. И ничего оно не 'парсит' и не 'жрет'.

 

дорогой мой, МАС-и это совсем другой уровень OSI. сетевой стек (программный фреймворк) не передает на верхний уровень МАС адрес - в стандартном, быстром,  "ядерном" исполнении. поэтому парсим RAW пакет и сокетами не пользуемся.

а вот чтоб DHCP пользовал сокеты (например для обработки релееных запросов) нужно компилить iscDHCP с опцией USE_SOCKETS. 

срочно учите матчасть.

Edited by ntil
Link to post
Share on other sites

Но песня сейчас не о том, проблема у ТС совсем другого порядка, ибо при нормальной работе сети с разбором DHCP запросов и первый пентюх справится.

Link to post
Share on other sites

 

Но песня сейчас не о том, проблема у ТС совсем другого порядка, ибо при нормальной работе сети с разбором DHCP запросов и первый пентюх справится.

прикол в том, что он разбирает на Л2 все что влетело в интерфейс - несколько сот М у топикстартера.

незнаю это баг или фича ISCDHCPD. но я спецом в исходник вставлял отладочный вывод в ДХЦП по приему пакета - все попадало в парсер. и учтите - у ТС в ДХЦП 900 правл - наверное статик лизы - оно ведь с ними всеми маки сравнивает на влёте пакета. трындец!

но в МТ скорее всего  ISCDHCPD или его форк. я просто на эти грабли наступал. 

Edited by ntil
Link to post
Share on other sites

В крайнем случае, в чём проблема погасить на минутку, ради эксперемента, DHCP сервер, в момент затыка сервера, дабы исключить его из цепочки?

 

Пускай погасит и посмотрит решило проблему или нет. Далее можно спокойно прийти к выводу, что виной всему кривописаный фаервол, через тыщу правил которого пролетает весь этот траффик.

Edited by andryas
Link to post
Share on other sites

да не гоните вы на ДХЦП, ему пофиг сколько там лиз прописано.. У меня около 7000 лиз и фигарит себе, без проблем, на 1 ядре загрузка 1%. У ТС проблема с трафиком, а именно с фаером. И самый дельный тут совет - убрать МТ и поставить туда линух или фряху. Ну танцы с бубнами на МТ !!! никогда оно стабильно работать не будет )

Link to post
Share on other sites

та нормально оно работает.... мт в смысле. вот килограмм правил в фаерволле это конечно ппц.

i5 нормально колбасит до гига, еще запас есть. NAT тоже присутствует....

Link to post
Share on other sites

 

 

Да нет, ерунда какая-то. Слушает себе сервис порт 67 на заданных интерфейсах, туда ему запросы с MACами и прилетают. И ничего оно не 'парсит' и не 'жрет'.

 

дорогой мой, МАС-и это совсем другой уровень OSI. сетевой стек (программный фреймворк) не передает на верхний уровень МАС адрес - в стандартном, быстром,  "ядерном" исполнении. поэтому парсим RAW пакет и сокетами не пользуемся.

а вот чтоб DHCP пользовал сокеты (например для обработки релееных запросов) нужно компилить iscDHCP с опцией USE_SOCKETS. 

срочно учите матчасть.

Плохо когда человек пытается прикрыть свою глупость умными словами. DCHP протокол работает полностью на уровне IP, используя UDP или TCP в качестве транспорта. Если хотите - на 3ем уровне модели OSI. Слушает себе сервис 1 порт да и все, ни в какой конфигурации даже на роутерах с сотнями интерфейсов и гигабитами трафика он не потребляет никаких ресурсов.

1. Изначальный запрос (DISCOVER) идет бродкастовым UDP пакетом, scr IP=0.0.0.0, dst IP=255.255.255.255, dst MAC ff:ff:ff:ff:ff:ff

2. Сервер шлет тем же UDP-бродкастом OFFER, но уже на мак клиента.

IP уровень? Таки да. Бред типа перевода интерфейса в promisc-режим и прослушивание всех пакетов выдуман вами, и в реальной жизни не используется.

 

Да, про сокеты, UDP и релеи сам подумаешь, или тоже разжевать?

Edited by KaYot
Link to post
Share on other sites

 

 

Да нет, ерунда какая-то. Слушает себе сервис порт 67 на заданных интерфейсах, туда ему запросы с MACами и прилетают. И ничего оно не 'парсит' и не 'жрет'.

 

Матчасть читайте. Нет никакого порта (и даже хоста), пока клиент не получил IP. Запрос на её получение широковещательный. Сначала работает 2-й уровень сети, вот поэтому DHCP сервер парсит широковещалку, которая к нему прилетает.

 

 

Во-во. И вам матчасть полезно будет почитать. Не повторяйте чужие глупости. Edited by KaYot
Link to post
Share on other sites

 

 

 

Да нет, ерунда какая-то. Слушает себе сервис порт 67 на заданных интерфейсах, туда ему запросы с MACами и прилетают. И ничего оно не 'парсит' и не 'жрет'.

 

дорогой мой, МАС-и это совсем другой уровень OSI. сетевой стек (программный фреймворк) не передает на верхний уровень МАС адрес - в стандартном, быстром,  "ядерном" исполнении. поэтому парсим RAW пакет и сокетами не пользуемся.

а вот чтоб DHCP пользовал сокеты (например для обработки релееных запросов) нужно компилить iscDHCP с опцией USE_SOCKETS. 

срочно учите матчасть.

Плохо когда человек пытается прикрыть свою глупость умными словами. DCHP протокол работает полностью на уровне IP, используя UDP или TCP в качестве транспорта. Если хотите - на 3ем уровне модели OSI. Слушает себе сервис 1 порт да и все, ни в какой конфигурации даже на роутерах с сотнями интерфейсов и гигабитами трафика он не потребляет никаких ресурсов.

1. Изначальный запрос (DISCOVER) идет бродкастовым UDP пакетом, scr IP=0.0.0.0, dst IP=255.255.255.255, dst MAC ff:ff:ff:ff:ff:ff

2. Сервер шлет тем же UDP-бродкастом OFFER, но уже на мак клиента.

IP уровень? Таки да. Бред типа перевода интерфейса в promisc-режим и прослушивание всех пакетов выдуман вами, и в реальной жизни не используется.

 

Да, про сокеты, UDP и релеи сам подумаешь, или тоже разжевать?

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

Хотя, возможно, файрвол на input позволит существенно снизить нагрузку. Но я не экспериментировал.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.


×
×
  • Create New...