Как у вас глючат vlan? Тег не добавляется, не убирается, не обрабатыватся? Даже на дешевых смартах годами работают без единого сбоя, на совсем дешевых поделках бывают проблемы с гибридным режимом, и то не часто, но без него почти всегда можно обойтись. Виланы — не панацея, от проблем в сети не спасают, но позволяют ее локализовать очень не плохо ну и нарезка брудкастдомена позволяет незначительным штормам умирать по ttl раньше, чем достигнут критичного масштаба.
Как правильно заметил casperrr STP нужно уметь готовить, сколько устройств было в кольце, какие таймеры выставлены и прочее?
Если так, то скорее всего и snmp статистику ваши свичи отдавать умеют, делаем мониторинг который собирает эту статистику со всех свичей со всех портов и выводит на графики, получаете во первых средство быстрой диагностики проблем, во вторых видите узкие каналы.
Следующий шаг — добавить в сеть фаирвол (вполне подойдет софтверный) и перед аггрегацией виланов проганять трафик через него, вырезая из траффика все не нужное, закрыв вирусные порты и т.д.
Мультивендорство не отмазка для администратора, у меня в сети 9 вендоров, а уж разных моделей железяк так вообще вагон (сложилось исторически, выкупали уже существующие сети и интегрировали в себя) и это почти не мешает, единственное на стыке таких железок нельзя использовать фирменные технологии, все же остальные вполне нормально работают, тот же IEEE 802.1Q открыт и везде работает одинаково.
Громкое название статьи, открывая надеялся увидеть что-то типа автоматически строящегося vlan-per-user с опцией 82, хитрый анализатор траффика с автоматическим управлением железом или что-то типа того, но никак не описание «как мы выключали взбесившийся демон»
Если так, то тут вопрос банальной некомпетентности сетевого администратора. Но я лично видел брудкаст домен на 1.5К хостов построенный на «мыльницах» — это чудовище еле ворочалось, загибалось от любого чиха в сети, на счетчики nonunicast пакетов было страшно смотреть, представил тут такую же структуру (следуя из описания). 802.1q + SNMP мониторинг уже решит 80% сетевых проблем, по крайней мере, вовремя предупредит о них. По поводу человека с STP, и правильно сделал, в чистом виде (не mstp или VRR) штука достаточно неповоротливая да и со стабильностью не очень, а включать не понимая всех возможных граблей только сделать хуже.
Каждый раз читая описания таких сетей у меня волосы шевелятся на всех возможных местах. Как эти сети работают в организациях для меня загадка, 500 машин и нет денег на бюджетные L2. Нет элементарного мониторинга состояния сети, проблему решают люди не имеющие прав доступа к головному коммутатору. Как, скажите мне как за 5 лет это первая проблема такого рода? Чем будете ловить ARP флуд или другие аномалии, для которых снифер на конечной машине ни как не поможет?
Для интереса проверил на телевизоре с IPS (матрица philips) тоже есть остаточный эффект, секунд 10, потом пропадает, похоже особенность IPS и с этим ничего не поделать.
Из сырцов собирают по 3м причинам:
1) Хочется текущую версию, вот прямо сейчас.
2) Нужны некоторые опции сборки, которые отсутствуют в версиях из репозиториев.
3) Несовместимость некоторых компонентов между собой в версиях из репов. (Как пример попробуйте одновременно поставить percona и ZendServer используя только версии из репозиториев).
А в чем собственно проблема? Я много собираю из репов и перекладываю в свой реп, для личного пользования. Чем это хуже чем подключать чужие и угадывать при какой фазе луны и с какими опциями собирался нужный пакет. При общей стабильности системы, стабильность некоторых компонентов не настолько критична, как появившийся функционал.
Апач работает от asterisk для того, чтобы FreePBX мог полностью управлять астером. Можно использовать apache2-mpm-itk, можно дать пользователю www-data права на asterisk, можно запилить отдельный пул для nginx — тут кому что роднее.
Не думал что достаточно новый роутер не умеет проброс бродкаста, все что попадались мне умели, включая совсем бютжетные. В любом случае на борту linux, можно зайти в консоль и настроить ручками (или он и это не умеет?). ИМХО решение напоминает страшный костыль, самый большой минус — невозможность включить домашний сервер автоматом, скриптом из другого сервера.
Вот некоторые варианты хаков
arp -s <target_ip_addr> <target_mac_addr>
или
ip neigh add <target_ip_addr> lladdr <target_mac_addr> dev <lan_iface>
, скорее всего удасться выполнить без модификации прошивки, если она так дорога.
как конвертируются oid'ы и в каком виде они еду в заббикс
Простите тогда не понял вашего комментария
Куда более интересно раскрыть тему мониторинга snmp-трапами в заббиксе: в официальной документации что-то есть, но чтобы от и до
А что конкретно не ясно из подробной официальной документации, я думал как заполнять — привел пример со скрином, если все ясно и Ваш пост был, чтоб отметить пристутствие, то простите.
Подключил к заббиксу огромный зоопарк разного хлама (около 300 свичей 8 разных вендоров в одной сети). По oid кратко могу рассказать:
1) Получи то, не знаю что.
Часто нужных трапов в документации нет, тогда
получаем все, что железка может отдать в виде id-трапа значение, по grep из известных значений получаем нужные трапы, если же производитель напрягся и написал вменяемую документацию, то переходим дальше.
Если id известен, то данные по нему можно считать так (для примера входящий трафик по 1 порту коммутатора):
snmpget -v 2c -c public IP-железки .1.3.6.1.2.1.2.2.1.10.1 -O Uvq
Мой рабочий вариант скрипта переключения каналов, принцип работы скрипта: пингуем шлюз каналов, если пинга до шлюза нет, значит канал лежит, ничего умнее не придумал.
#!/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
GW1=Шлюз первого аплинка
GW2=Шлюз второго аплинка
tester=0;
itest1=`/sbin/ping -c 3 $GW1 | grep "64 bytes" | wc -l`;
itest2=`/sbin/ping -c 3 $GW2 | grep "64 bytes" | wc -l`;
if [ ! -f "/tmp/countGW.tmp" ]
then
echo 3 > /tmp/countGW.tmp
fi
oldtest=`cat /tmp/countGW.tmp`
if (test $itest1 -gt "0")
then
let tester=tester+1
fi
if (test $itest2 -gt "0")
then
let tester=tester+2
fi
if [ $oldtest = $tester ]; then
exit;
#echo "Canali ne izmenilis"
else
if [ $oldtest = 3 ]; then
cp /etc/pf.conf /etc/pf.conf3
fi
if [ $tester = 3 ]; then
cp /etc/pf.conf3 /etc/pf.conf
/sbin/route change default $GW1
fi
if [ $tester = 2 ]; then
cp /etc/pf.conf2 /etc/pf.conf
/sbin/route change default $GW2
fi
if [ $tester = 1 ]; then
cp /etc/pf.conf1 /etc/pf.conf
/sbin/route change default $GW1
fi
/etc/rc.d/pf restart
fi
Скрипт изменяет шлюз по умолчанию если основной канал вдруг падает, если канал возвращается на место шлюз также возвращается. В pf имею 3 конфига, активен только канал 1, активен только канал 2 и активны оба канала, что там писать уж на свой вкус, мой вариант когда оба канала работают
ext_if1="ip канала 1"
ext_if2="ip канала 2"
ext_gw1="Шлюз канала 1"
ext_gw2="Шлюз канала 2"
#{Тут какую сеть на какой канал, либо текущий рабочий канал для всех сетей}
#Этих через канал 2
nat on $ext_if1 from 192.168.3.0/24 to !<no_nat> -> $ext_if2
nat on $ext_if1 from 192.168.4.0/24 to !<no_nat> -> $ext_if2
#Остальных через канал 1
nat on $ext_if1 from 192.168.0.0/16 to !<no_nat> -> $ext_if1
pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 to !<no_nat>
pass out on $ext_if2 route-to ($ext_if1 $ext_gw1) from $ext_if1 to !<no_nat>
Опоздала статья лет так на 15, домен коллизий, кроссовер кабеля, коаксиал, концентраторы — зачем все это? Те кто помнит и так разбираются в сетях, те кто только изучает — получит багаж устаревшего ненужного хлама знаний. Лучше бы про типы оптики и современные тенденции побольше. В средних и крупных городах уже и SOHO сегмент перетянут на оптику вплоть до «последней мили», а тут на тебе коаксиал.
Полностью согласен если мы говорим о местечковом провайдере на пару тысяч пользователей, но чем крупнее провайдер, тем накладнее ссорится с органами, да и зачем, какой интерес провайдеру? Анализ логов помогает например прогнозировать какие каналы расширять и какие маршруты приоритетней.
Ладно наш спор к теме топика относится косвенно, думаю можно закончить. Логи есть, никто отрицать не будет, а то в каком они виде оставим на совести провайдеров.
Пока провайдеру везет и из его сети не было ни одного серьезного инцидента, при первом же случае его нагнут вплоть до лишения лицензии и ответе за все не правомерные действия совершенные с его IP, если он не может предоставить нормальный лог. Я сисадмин интернет провайдера, про требования и логи знаю не по наслышке, примерно раз в 2-3 месяца мы получаем запрос из органов на определение того, кто в такое-то время сидел с такого-то ip или в определенный промежуток времени обращался к определенным адресам. Процедура выдачи такой информации отлажена, почти все биллинги это предусматривают штатно. Еще есть определенный список ресурсов, доступ к которым мониторится постоянно и все пользователи, которые туда обращались логируются и списком уходят на спец. ящик. По поводу «отказника» я не знаю как в России, но в Украине мы вынуждены соблюдать этот закон (Обращаем внимание на Статью 39 пункт 4, не путать со статьей 39 пункт 1 подпункт 4). Техтребование — это полный лог в формате NetFlow и линки не зеркалятся, а в ящик уходит только сам лог с оборудования, который в умелых руках предоставляет достаточно информации для анализа и нагибаня виновных. Пока вы «Неуловимый Джо» можно верить в некомпетентность провайдеров и органов, отказников и деда мороза, но попробуйте совершить что-то серьезное из сети своего провайдера и проверить настолько ли вы неуловимы.
Как правильно заметил casperrr STP нужно уметь готовить, сколько устройств было в кольце, какие таймеры выставлены и прочее?
Если так, то скорее всего и snmp статистику ваши свичи отдавать умеют, делаем мониторинг который собирает эту статистику со всех свичей со всех портов и выводит на графики, получаете во первых средство быстрой диагностики проблем, во вторых видите узкие каналы.
Следующий шаг — добавить в сеть фаирвол (вполне подойдет софтверный) и перед аггрегацией виланов проганять трафик через него, вырезая из траффика все не нужное, закрыв вирусные порты и т.д.
Мультивендорство не отмазка для администратора, у меня в сети 9 вендоров, а уж разных моделей железяк так вообще вагон (сложилось исторически, выкупали уже существующие сети и интегрировали в себя) и это почти не мешает, единственное на стыке таких железок нельзя использовать фирменные технологии, все же остальные вполне нормально работают, тот же IEEE 802.1Q открыт и везде работает одинаково.
Громкое название статьи, открывая надеялся увидеть что-то типа автоматически строящегося vlan-per-user с опцией 82, хитрый анализатор траффика с автоматическим управлением железом или что-то типа того, но никак не описание «как мы выключали взбесившийся демон»
1) Хочется текущую версию, вот прямо сейчас.
2) Нужны некоторые опции сборки, которые отсутствуют в версиях из репозиториев.
3) Несовместимость некоторых компонентов между собой в версиях из репов. (Как пример попробуйте одновременно поставить percona и ZendServer используя только версии из репозиториев).
А в чем собственно проблема? Я много собираю из репов и перекладываю в свой реп, для личного пользования. Чем это хуже чем подключать чужие и угадывать при какой фазе луны и с какими опциями собирался нужный пакет. При общей стабильности системы, стабильность некоторых компонентов не настолько критична, как появившийся функционал.
Апач работает от asterisk для того, чтобы FreePBX мог полностью управлять астером. Можно использовать apache2-mpm-itk, можно дать пользователю www-data права на asterisk, можно запилить отдельный пул для nginx — тут кому что роднее.
Вот некоторые варианты хаков
arp -s <target_ip_addr> <target_mac_addr>
или
ip neigh add <target_ip_addr> lladdr <target_mac_addr> dev <lan_iface>
, скорее всего удасться выполнить без модификации прошивки, если она так дорога.
Простите тогда не понял вашего комментария
А что конкретно не ясно из подробной официальной документации, я думал как заполнять — привел пример со скрином, если все ясно и Ваш пост был, чтоб отметить пристутствие, то простите.
1) Получи то, не знаю что.
Часто нужных трапов в документации нет, тогда
получаем все, что железка может отдать в виде id-трапа значение, по grep из известных значений получаем нужные трапы, если же производитель напрягся и написал вменяемую документацию, то переходим дальше.
Если id известен, то данные по нему можно считать так (для примера входящий трафик по 1 порту коммутатора):
2) Заполнение item в zabbix (по примеру выше)
Скрипт изменяет шлюз по умолчанию если основной канал вдруг падает, если канал возвращается на место шлюз также возвращается. В pf имею 3 конфига, активен только канал 1, активен только канал 2 и активны оба канала, что там писать уж на свой вкус, мой вариант когда оба канала работают
Ладно наш спор к теме топика относится косвенно, думаю можно закончить. Логи есть, никто отрицать не будет, а то в каком они виде оставим на совести провайдеров.