[nik1209]

Здравствуйте, коллеги. Прошу помощи по некоторым вопросам, относящимся к увеличению стабильности оптической сети небольшого интернет-провайдера.

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

Кратко о сети:

Схемы логического построения сети - звезды и кольца.

Коммутаторы агрегации - D-Link DGS 3120-24SC, D-Link DGS 3100-24TG.

Коммутаторы доступа - D-Link DES-3028, 3526, 3200-26, 3200-28, 1228/ME, 1210-28/ME.

Ядра - Mikrotik.

Во всех населенных пунктах реализована схема "VLAN на пользователя", авторизация клиентов по IPoE.

На агрегации и магистральных портах коммутаторов доступа включен STP и VLAN Trunk. Управление коммутаторами вынесено в отдельный VLAN.

А теперь к сути. Меня интересуют вопросы по увеличению стабильности магистральной сети.

Каким образом лучше всего реализовать мониторинг сети? Сейчас мониторим только по логам.

Какие еще полезные функции необходимо настроить на коммутаторах агрегации и доступа.

За любую полезную информацию буду признателен.

[bos9]

Правильно было бы сначала выделить факторы негативно влияющие не стабильность ваше сети, а потом уже планомерно с ними бороться =)

По мониторингу nagios/zabbix/cacti... Опять же исходя из того, что конкретно вы хотите мониторить.

[andryas]

2 hours ago, nik1209 said:

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

 

Беги оттуда...

 

По сабжу - можно начать с ICMP мониторинга (скрипт, выводящий "упавшие" узлы, просто GUI пинговалка, сообщения в мессенджер), со временем можна и полноценную систему, как советовали выше.

[nixx]

4 часа назад, nik1209 сказал:

Ядра - Mikrotik.

в качестве мониторинга прямо напрашивается The Dude.

разобраться, как начинающему, будет в разы проще, чем с cacti/zabbix'ом.

только не поднимайте сервер Dude на ядре ) заведите под него отдельный микротик или вообще винду (старая Dude версий 3.6/4.0 ставится на win).

[nik1209]

Благодарю за подсказку по вариантам мониторинга.

Вообще от мониторинга еще хотелось бы добиться оповещения об упавших линках между домами в кольце, здесь icmp уже не подойдет как вариант. К тому же заметил постоянную смену топологии в кольцах, хотя stp включена только на магистральных портах и физически линки не падают и коммутаторы продолжают работать.

Можете ли дать рекомендации по правильной настройке stp?

В кольцах максимум по 15 коммутаторов.

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

 

[nixx]

20 минут назад, nik1209 сказал:

Вообще от мониторинга еще хотелось бы добиться оповещения об упавших линках между домами в кольце, здесь icmp уже не подойдет как вариант. К тому же заметил постоянную смену топологии в кольцах, хотя stp включена только на магистральных портах и физически линки не падают и коммутаторы продолжают работать.

dude вам покажет падающие линки без проблем (если умеете snmp).

по смене топологии смотрите ошибки на линках, загрузку процессоров на свитчах.

Изменено 21 марта, 2018 пользователем nixx

[VolanD666]

На мониторинг я бы поставил Zenoss, управление в отдельный врф, правда у микротика с врф-ами не очень хорошо. Должны быть схемы сети в порядке. Дальше смотрите что отваливается и решайте проблемы. Должна быть система фиксации заявок. Клиентов сколько в сети?

[Adim]

11 часов назад, nixx сказал:

напрашивается The Dude.

плюсану

как дополнительно ставил для себя

машинка два ядра два гига как говорится. Мониторит более 500 устройств

начиная от узлов и заканчивая отдельными абонентами (типа звонят ничего не открывается, а трафик на порту в полку)

плюс можно уведомления смс или на почту

плюс можно веб интерфейс включить и прямо с телефона смотреть что упало

[nik1209]

Активных клиентов примерно 1300. Теперь вопрос касаемо коммутаторов d-link. Может ли сказываться высокая загрузка процессора коммутатора на смену топологии в кольце?

[bos9]

bpdu обрабатываются cpu, так что при очень большой загрузке могут быть дропы/задержки bpdu и как следствие перестроение топологии.

а от чего такая большая загрузка на длинках то? 

[Saab95]

Если у вас ядро на микротике, то может посмотреть в сторону перехода на L3 транспорт? Те же CCR1016 есть с кучей оптических портов. Если на узлах агрегации установить L3 упаковку абонентского L2 трафика, то уйдете от очень большого количества проблем сразу, в том числе и с резервированием центрального узла. При этом не обязательно сводить все на микротики - можно прокидывать и через коммутаторы каналы на промежуточный микротик.

 

Все эти STP, куча вланов - тупиковое развитие. Дальше что - QinQ, а там свои проблемы, опять же в центре, если все по L2 сводить - будет помойка из трафика, вланы управления - все неудобно.

[NiTr0]

В 22.03.2018 в 15:16, Saab95 сказал:

Все эти STP, куча вланов - тупиковое развитие

ну да, потому что некротики так и не научились ни в нормальный RSTP/MSTP, ни в GVRP :)

 

ну а ядро сети на стопке некротиков - таки самое что ни есть тупиковое развитие.

 

потому прошлый админ и сбежал с этого дурдома :)

 

В 21.03.2018 в 16:05, nik1209 сказал:

Каким образом лучше всего реализовать мониторинг сети?

zabbix. как минимум - утилизация линков, трапы по link up/link down, пинг, CPU usage софтроутеров (типа некротика).

 

поднимается с полпинка, настраивается элементарно, заниматься онанизмом с дудкой на венде (а тем более - на каком-то из некротиков) смысла не вижу.

 

В 21.03.2018 в 16:05, nik1209 сказал:

Какие еще полезные функции необходимо настроить на коммутаторах агрегации и доступа.

на доступе - loop detect (если нет), ну и бродкаст/мультикаст рейтлимит на доступе либо агрегации (очень помогает при флуде от абона либо лаге стп - особенно учитывая что все это смотрит в чахлый некротик, который от флуда может и окочуриться).

[Saab95]

40 минут назад, NiTr0 сказал:

ну да, потому что некротики так и не научились ни в нормальный RSTP/MSTP, ни в GVRP :)

Я вам уже предлагал нарисовать часть схемы сети из 1000 промежуточных узлов и 100000 абонентов, при условии что надо все абонентские каналы по L2 иметь в центре и полностью все резервировать.

 

Сможете это методами L2 технологий сделать?

[YuryD]

1 час назад, Saab95 сказал:

Сможете это методами L2 технологий сделать?

 Тыщи и не надо, киска с pvst+ такие картинки делает, это у меня не городское кольцо, а кривая ромашка с несколькими ногами и кривыми лепестками,  у кого-то три ноги, у кого-то пара. Сходимость моей сети - два пинга :) На кисках - вопрос только денег. Остальное глюкало от блинка со своим мстп/рстп такой топологии не пережуёт. Мое ограничение - номера влан, их количество :)

[GrandPr1de]

у сааба весеннее обострение

[Saab95]

22 часа назад, YuryD сказал:

На кисках - вопрос только денег.

Так тут и ответ на выпады в сторону микротика. Все советуют циску, а она, вернее решение на сети, стоит раз в 10 больше, чем если то же самое реализовывать на микротике.

 

22 часа назад, YuryD сказал:

Остальное глюкало от блинка со своим мстп/рстп такой топологии не пережуёт.

Ну вот - STP на коммутаторах в реальной сети создает только проблемы, максимум, что ей можно делать - это одно кольцо из коммутаторов. Все что больше уже нормально не работает.

[zhenya`]

Работает. Но лучше erps использовать.

[YuryD]

17 часов назад, Saab95 сказал:

Ну вот - STP на коммутаторах в реальной сети создает только проблемы, максимум, что ей можно делать - это одно кольцо из коммутаторов. Все что больше уже нормально не работает.

 Сферический конь в вакууме :)  stp у каждого вендора свой, увы... Но у меня опорная сеть на кисках, поэтому pvst+ был единственным выбором. Не агитирую за киску, но она у меня нормально работает при хитровыгнутой топологии. И не жужжит, однажды я заметил падение канала второго  из трёх, только при аварии. Оказалось - первый помер два месяца назад... Ну не пишут киски письма, как блинк.

 

 Насчет совместимости *stp от разных вендоров :) Не забывайте фильтровать bpdu на не своих или клиентских портах. А то был случАй, забыл на стыке фильтрануть, и блинк охкакого крупного провайдера, присоединённого, вдруг впал в коматоз. Они два дня искали траблему, ибо управление издалека, а коммутатор в коме. Т.о. при снятии линка они не смогли найти причину, пока я не догадался :)

[NiTr0]

В 23.03.2018 в 16:34, Saab95 сказал:

100000 абонентов, при условии что надо все абонентские каналы по L2 иметь в центре и полностью все резервировать.

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

 

и да, 100к абонов - это где-то 100 гбит трафика есличо. что там у некротика есть с 100G портами? или хотя бы 40G?

[Saab95]

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

[NiTr0]

4 часа назад, Saab95 сказал:

достаточно в центре поставить десятка два устройств и распределить на них трафик.

схему в студию. с резервированием и распределением, да. и чтобы 100 гбит лопатило.

[GrandPr1de]

Обожаю эту ограниченность. У него знания на длинках, микротиках, PC Роутерах и элтехах кончились. Хотя когда идет речь о 100G что-то из этого списка учавствовать вряд ли будет.

[Saab95]

12 часов назад, NiTr0 сказал:

схему в студию. с резервированием и распределением, да. и чтобы 100 гбит лопатило.

Я вас просил предоставить как ярого противника микротика.

 

11 часов назад, GrandPr1de сказал:

Обожаю эту ограниченность

В топике был конкретный вопрос, что ядро на микротиках, остальное на коммутаторах. И стоит задача повысить отказоустойчивость транспорта. Отсюда можно использовать простые тезисы:

 

1. Если в центре микротик и он справляется с задачей, то установка промежуточных микротиков на промежуточных узлах сети не ухудшит производительность.

2. Если уже есть оборудование, например коммутаторы, а в ядре микротик - то использовать циску не подразумевается.

[GrandPr1de]

Окей, циски мы тоже знаем. Вижу. Только не одной циской едины.

[NiTr0]

14 часов назад, Saab95 сказал:

Если в центре микротик и он справляется с задачей,

так покажите же этот волшебный микротик который справится со 100 гбитами трафика. слабо?