s.lobanov Опубликовано 8 сентября, 2016 · Жалоба есть сегменты где влан на 3-5 кварталов ну почти угадал. Разбивайте на вланы. на свитчах доступа режьте мусор (всякие suppression и т.п.) Я пока застопорился на том как в bash-скрипте реализовать вход по телнету, нужно через секундрую паузу передать пароль ведь. #!/usr/bin/env bash (sleep 1;echo login;sleep 1;echo password;sleep 1;echo COMMANG;sleep 1;echo exit) | telnet IP_switch Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Negator Опубликовано 8 сентября, 2016 · Жалоба Меня сейчас будут бить ногами, но если честно сегменты до 1000 абонентов в одном широковещательном домене на управляемых свичах работают вполне сносно. Включения traffic_segmentation и блокировки левых DHCP достаточно. Есть опыт покупки подобных провайдерских сетей - в первую очередь там ставились умные железки и включался traffic_segmentation - сразу почти все проблемы решались. Ну а потом уже всякие acl, сегментация по вланам и прочий план по интеграции клиентов купленного провайдера к нам. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sergsa Опубликовано 8 сентября, 2016 (изменено) · Жалоба Меня сейчас будут бить ногами, но если честно сегменты до 1000 абонентов в одном широковещательном домене на управляемых свичах работают вполне сносно. Включения traffic_segmentation и блокировки левых DHCP достаточно. Есть опыт покупки подобных провайдерских сетей - в первую очередь там ставились умные железки и включался traffic_segmentation - сразу почти все проблемы решались. Ну а потом уже всякие acl, сегментация по вланам и прочий план по интеграции клиентов купленного провайдера к нам. все это танцы с бубном. По факту нужно просто делать по нормальному, а это 1влан-1пользователь и все, и ни чего больше не нужно настраивать, QinQ 1порт-101 влан 24порт - 124 влан и так на всех свичах. А все эти обрезания это не правильно от них весь геморой, то там не то то здесь не так, потом помнить нужно зачем это порезал, а зачем то. ЗЫ скиньте сюда стандартный ACL который на всех свичах висит, ради интереса. чтоб нормально не настраивать придумали костыль traffic_segmentation Изменено 8 сентября, 2016 пользователем sergsa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EShirokiy Опубликовано 8 сентября, 2016 · Жалоба Включения traffic_segmentation и блокировки левых DHCP достаточно Я скажу больше, можно включить только traffic_segmentation, левые DHCP никуда не улетят. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 8 сентября, 2016 · Жалоба EShirokiy В деревянной структуре - да. А если кольца (кто ж знает какую сеть вы купите завтра) - там не спасет traf_seg от левых dhcp, если data-vlan на кольцо только один все это танцы с бубном. По факту нужно просто делать по нормальному, а это 1влан-1пользователь и все, и ни чего больше не нужно настраивать, QinQ 1порт-101 влан 24порт - 124 влан и так на всех свичах. кстати, по поводу qinq и vlan-per-user многие забывают, что как только навесили вторую метку, для последующих транзитный свитчей всё слилось в один влан, со всеми приколами типа mac-flapping ip gw/pppoe nas между аплинком и даунлинком и т.п. Так что надо смотреть как устроен транспорт от доступа до браса Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdc Опубликовано 8 сентября, 2016 · Жалоба застопорился на том как в bash-скрипте реализовать вход по телнету, нужно через секундрую паузу передать пароль ведь.Для примера - скрипт обновления прошивки длинков на старых платформах (две прошивки): #!/usr/local/bin/expect -f set host [lindex $argv 0] set file [lindex $argv 1] set timeout 1000 spawn telnet $host expect "ame:" send "InsertLoginHere\r" expect "ord:" send "InsertPasswordHere\r" expect "#" send "config firmware image_id 1 boot_up\r" expect "#" send "download firmware_fromTFTP InsertUpdateServerIpHere $file image_id 2\r" expect "#" send "config firmware image_id 2 boot_up\r" expect "#" send "download firmware_fromTFTP InsertUpdateServerIpHere $file image_id 1\r" expect "#" send "config firmware image_id 1 boot_up\r" expect "#" send "logout\r" Аргументы - адрес свича и имя файла прошивки. Логин/пароль и адрес сервера вбиваются в скрипт, можно и их в аргументы вынести. Лучше приведённого выше варианта тем, что не ждёт тупо по секунде, а реагирует на интерфейс. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EShirokiy Опубликовано 8 сентября, 2016 · Жалоба Я массовый конфиг свитчей делал через заббикс и все бэкапится там же на tftp-сервер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Butch3r Опубликовано 9 сентября, 2016 · Жалоба Я уже написал что делать. Проверьте для начало это. Вы написали только кто микротик главный подозреваемый. Что в нём смотреть надо? Процессоры загружены на 5-10%, в логе ничего подозрительного нет. Что ещё смотреть? Не надо никакое по на 256 коммутаторов- пару скриптов на шелле достаточно. Или вообще напишите генератор конфига и залейте все вручную. Эти пару скриптов заколебёшся писать. Я пока застопорился на том как в bash-скрипте реализовать вход по телнету, нужно через секундрую паузу передать пароль ведь. Что смотреть - не знаю. Я не работал с микротиком.Если в момент проблемы рубануть крупный сегмент сети (чтоб снизить нагрузку) - проблема уйдет? Я бы первым делом попробовал его заменить на что-нибудь другое. Если не на что - договаривайтесь, например, с НАГом, берите железку в тест и смотрите ситуацию. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShyLion Опубликовано 9 сентября, 2016 · Жалоба Если допустим где-то не включён loopdetect и там как раз образована петля, я бы wireshark-ом увидел наличие широковещательного шторма. А тут я вижу, что у меня 99% трафика - tcp-трафик А что, TCP траффик каким-то волшебным образом защищен от петель? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Zarin Опубликовано 9 сентября, 2016 · Жалоба Эти пару скриптов заколебёшся писать. Я пока застопорился на том как в bash-скрипте реализовать вход по телнету, нужно через секундрую паузу передать пароль ведь. Ключевое слово для поиска в гугле - expect(1) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sergsa Опубликовано 9 сентября, 2016 (изменено) · Жалоба вообще перечитал стартовое сообщение ТСа. Оно очень напомнило панические вопли фиговых сисадминов, которые ни чего не умеют и ни чего толком объяснить не могут. Выражения типа "лагает сеть" "падает скорость" и т.п. могут говорить юзеры и ламеры, а человек которому доверили управлять этим огромным хозяйством должен говорить конкретно что падает и в каком месте. Если проблема у всех, то ее нужно начинать искать сверху-вниз, т.е. впревую очередь смотреть загрузку внешнего канала и ппс на маршрутизаторе, а потом на хьюлете, загрузку процессора и памяти в момент появления проблем. Вместо микротика для теста можно уже собрать софтроутер и посмотреть что будет. Главное мерило это пинги с ноутбука который подключается в разрыв сначала за каналом провайдера рядом с микротиком, потом за микротиком перед хьюлетом, потом за хьюлетом. Проблема явно или в микротике (90%) или в хьюлете (10%), поэтому все эти рассуждения о коммутаторах и настройках сети к решению проблемы отношения не имеют. Изменено 9 сентября, 2016 пользователем sergsa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uk2558 Опубликовано 9 сентября, 2016 · Жалоба кстати, по поводу qinq и vlan-per-user многие забывают, что как только навесили вторую метку, для последующих транзитный свитчей всё слилось в один влан, со всеми приколами типа mac-flapping ip gw/pppoe nas между аплинком и даунлинком и т.п. Так что надо смотреть как устроен транспорт от доступа до браса +1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Iskatel_S Опубликовано 9 сентября, 2016 · Жалоба все это танцы с бубном. По факту нужно просто делать по нормальному, а это 1влан-1пользователь и все, и ни чего больше не нужно настраивать, QinQ 1порт-101 влан 24порт - 124 влан и так на всех свичах. А все эти обрезания это не правильно от них весь геморой, то там не то то здесь не так, потом помнить нужно зачем это порезал, а зачем то. ЗЫ скиньте сюда стандартный ACL который на всех свичах висит, ради интереса. чтоб нормально не настраивать придумали костыль traffic_segmentation Я уже слышал это мнение и сам прекрасно понимаю, что 1влан-1пользователь - это идеальная схема. Но вы же понимаете, что перейти на эту схему просто так нельзя, нужно приобретать различное ПО: во-первых нужно ПО для автоматического управления свитчами, во-вторых нужна интеграция этого ПО с биллингом, чтобы как только оператор заводит/изменяет в биллинге пользователя - для него сразу же прописывался влан. Вполне может быть так, что систему биллинга вообще придётся менять, а это значит - перенос абонентов в другой биллинг, заказ ПО, стоимость такой модернизации может быть до полумиллиона рублей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 9 сентября, 2016 · Жалоба Лол. Вера в некое ПО, которое всё сделает за вас - вот ваша проблема в абонентской сети. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 9 сентября, 2016 · Жалоба Меня сейчас будут бить ногами, но если честно сегменты до 1000 абонентов в одном широковещательном домене на управляемых свичах работают вполне сносно. Угу. Если схема "звезда" и включена изоляция портов, то отлично работает. Для каждого масштаба и случая есть своя оптимальная схема. Где-то оптимальным будет S-VLAN (VLAN на сервис) и PPPoE, где-то C-VLAN (VLAN на абонента) и IPoE, а где-то L3-доступ. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdc Опубликовано 9 сентября, 2016 · Жалоба чтобы как только оператор заводит/изменяет в биллинге пользователя - для него сразу же прописывался вланЕсть решение гораздо проще - прописывать вланы заранее, при установке свичей.В биллинге синхронно с этой пачкой вланов прописывается пачка учёток. Процедура подключения выглядит так - втыкаем абонента в первый попавшийся порт, далее смотрим, какой там номер договора, и активируем эту учётку. В итоге при работе с физлицами трогать настройки свичей не требуется вовсе. Где-то оптимальным будет S-VLAN (VLAN на сервис) и PPPoE, где-то C-VLAN (VLAN на абонента) и IPoEА где может быть оптимальным пппое, кроме сети с неуправляемыми свичами? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 9 сентября, 2016 · Жалоба А где может быть оптимальным пппое, кроме сети с неуправляемыми свичами? Много где. У нас изначально полностью управляемый доступ, по порту на абонента. Однако нам PPPoE удобнее, чем IPoE. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myth Опубликовано 9 сентября, 2016 · Жалоба ПППоЕ снимает многие геморрои, уходить с него особо не хочется Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sergsa Опубликовано 9 сентября, 2016 (изменено) · Жалоба Я уже слышал это мнение и сам прекрасно понимаю, что 1влан-1пользователь - это идеальная схема. Но вы же понимаете, что перейти на эту схему просто так нельзя, нужно приобретать различное ПО: во-первых нужно ПО для автоматического управления свитчами, во-вторых нужна интеграция этого ПО с биллингом, чтобы как только оператор заводит/изменяет в биллинге пользователя - для него сразу же прописывался влан. Вполне может быть так, что систему биллинга вообще придётся менять, а это значит - перенос абонентов в другой биллинг, заказ ПО, стоимость такой модернизации может быть до полумиллиона рублей. это даже UTM умеет за 30тр Изменено 9 сентября, 2016 пользователем sergsa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nik0n Опубликовано 9 сентября, 2016 · Жалоба это даже UTM умеет за 30тр Ну наговорите сейчас. Прямо вот САМА UTM5 (установленная из коробки) лезет на свич и прописывает туда VLAN? Это где сказка то такая :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sergsa Опубликовано 9 сентября, 2016 · Жалоба это даже UTM умеет за 30тр Прямо вот САМА UTM5 (установленная из коробки) лезет на свич и прописывает туда VLAN? ага и еще кофе наливает:) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Iskatel_S Опубликовано 9 сентября, 2016 · Жалоба вообще перечитал стартовое сообщение ТСа. Оно очень напомнило панические вопли фиговых сисадминов, которые ни чего не умеют и ни чего толком объяснить не могут. Выражения типа "лагает сеть" "падает скорость" и т.п. могут говорить юзеры и ламеры, а человек которому доверили управлять этим огромным хозяйством должен говорить конкретно что падает и в каком месте. Если проблема у всех, то ее нужно начинать искать сверху-вниз, т.е. впревую очередь смотреть загрузку внешнего канала и ппс на маршрутизаторе, а потом на хьюлете, загрузку процессора и памяти в момент появления проблем. Вместо микротика для теста можно уже собрать софтроутер и посмотреть что будет. Главное мерило это пинги с ноутбука который подключается в разрыв сначала за каналом провайдера рядом с микротиком, потом за микротиком перед хьюлетом, потом за хьюлетом. Проблема явно или в микротике (90%) или в хьюлете (10%), поэтому все эти рассуждения о коммутаторах и настройках сети к решению проблемы отношения не имеют. Ну все сисадмины когда-то были практикантами. По пингам с ноутбука... то есть вы хотите сказать, что простой пинг - более подходящий инструмент для тестирования чем ресурс speedtest.net и btest? И какой пинг в идеале должен быть? Я конечно да, подозреваю что я как раз неправильно средствами измерения пользуюсь. А что, TCP траффик каким-то волшебным образом защищен от петель? Опять про возможно-неправильное пользование средствами измерения. Логика такая: Петли порождают broadcast-шторм, так? broadcast-трафик - это в основном ARP-запросы и DHCP-запросы, так? DHCP работает по UDP-протоколу, ARP работает по ARP-протоколу, а TCP-протокол изначально чист от broadcast-трафика. ЗЫ скиньте сюда стандартный ACL который на всех свичах висит, ради интереса. create access_profile ip tcp dst_port_mask 0xFFFF profile_id 1 config access_profile profile_id 1 add access_id 1 ip tcp dst_port 135 port 1-9 deny config access_profile profile_id 1 add access_id 2 ip tcp dst_port 137 port 1-9 deny config access_profile profile_id 1 add access_id 3 ip tcp dst_port 138 port 1-9 deny config access_profile profile_id 1 add access_id 4 ip tcp dst_port 139 port 1-9 deny config access_profile profile_id 1 add access_id 5 ip tcp dst_port 445 port 1-9 deny create access_profile ip udp dst_port_mask 0xFFFF profile_id 2 config access_profile profile_id 2 add access_id 1 ip udp dst_port 135 port 1-9 deny config access_profile profile_id 2 add access_id 2 ip udp dst_port 137 port 1-9 deny config access_profile profile_id 2 add access_id 3 ip udp dst_port 138 port 1-9 deny config access_profile profile_id 2 add access_id 4 ip udp dst_port 139 port 1-9 deny config access_profile profile_id 2 add access_id 5 ip udp dst_port 445 port 1-9 deny create access_profile ip udp src_port_mask 0xffff profile_id 3 config access_profile profile_id 3 add access_id 1 ip udp src_port 67 port 1-9 deny create access_profile ethernet ethernet_type profile_id 4 config access_profile profile_id 4 add access_id 1 ethernet ethernet_type 0x86DD port 1-9 deny Мой предшественик делал так: create cpu_access_profile ip udp src_port_mask 0xffff profile_id 1 config cpu_access_profile profile_id 1 add access_id auto_assign ip udp src_port 67 port 1-9 deny Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sergsa Опубликовано 9 сентября, 2016 (изменено) · Жалоба По пингам с ноутбука... то есть вы хотите сказать, что простой пинг - более подходящий инструмент для тестирования чем ресурс speedtest.net и btest? И какой пинг в идеале должен быть? Я конечно да, подозреваю что я как раз неправильно средствами измерения пользуюсь. ну я хз, что на это ответить, может нанять человека который хоть что-то умеет А куда делся человек который все это настраивал? Изменено 9 сентября, 2016 пользователем sergsa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Iskatel_S Опубликовано 9 сентября, 2016 · Жалоба Да, и у меня появилась ещё одна версия. Прочитал недавно статью как правильно нужно настраивать шейпинг на микротике https://habrahabr.ru/post/188718/ Вобщем у нас всё не так как в статье: дерева очередей в Queue tree нет, наличествуют очереди в Simple Queue и всё, причём очереди типа SFQ. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zlolotus Опубликовано 9 сентября, 2016 · Жалоба Меня сейчас будут бить ногами, но если честно сегменты до 1000 абонентов в одном широковещательном домене на управляемых свичах работают вполне сносно. Включения traffic_segmentation и блокировки левых DHCP достаточно. Есть опыт покупки подобных провайдерских сетей - в первую очередь там ставились умные железки и включался traffic_segmentation - сразу почти все проблемы решались. Ну а потом уже всякие acl, сегментация по вланам и прочий план по интеграции клиентов купленного провайдера к нам. Можно мне чуть попинать? ) НЕ НАДО ЭТОГО Делать! Я как-то поверил, человеку. И выбрал эту схему, всю сеть лагало и штормило. Не делайте так. Каждый два три коммутатора, а лучше коммутатор в отдельном пользовательском вилане. На каждый район, отдельный управляемый вилан управления, и общий вилан управления. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...