Перейти к содержимому
Калькуляторы

Проблемы в провайдерской сети

есть сегменты где влан на 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Включения traffic_segmentation и блокировки левых DHCP достаточно. Есть опыт покупки подобных провайдерских сетей - в первую очередь там ставились умные железки и включался traffic_segmentation - сразу почти все проблемы решались. Ну а потом уже всякие acl, сегментация по вланам и прочий план по интеграции клиентов купленного провайдера к нам.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Включения traffic_segmentation и блокировки левых DHCP достаточно. Есть опыт покупки подобных провайдерских сетей - в первую очередь там ставились умные железки и включался traffic_segmentation - сразу почти все проблемы решались. Ну а потом уже всякие acl, сегментация по вланам и прочий план по интеграции клиентов купленного провайдера к нам.

все это танцы с бубном. По факту нужно просто делать по нормальному, а это 1влан-1пользователь и все, и ни чего больше не нужно настраивать, QinQ 1порт-101 влан 24порт - 124 влан и так на всех свичах. А все эти обрезания это не правильно от них весь геморой, то там не то то здесь не так, потом помнить нужно зачем это порезал, а зачем то.

ЗЫ скиньте сюда стандартный ACL который на всех свичах висит, ради интереса.

чтоб нормально не настраивать придумали костыль traffic_segmentation

Изменено пользователем sergsa

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Включения traffic_segmentation и блокировки левых DHCP достаточно

Я скажу больше, можно включить только traffic_segmentation, левые DHCP никуда не улетят.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

EShirokiy

В деревянной структуре - да. А если кольца (кто ж знает какую сеть вы купите завтра) - там не спасет traf_seg от левых dhcp, если data-vlan на кольцо только один

 

все это танцы с бубном. По факту нужно просто делать по нормальному, а это 1влан-1пользователь и все, и ни чего больше не нужно настраивать, QinQ 1порт-101 влан 24порт - 124 влан и так на всех свичах.

 

кстати, по поводу qinq и vlan-per-user многие забывают, что как только навесили вторую метку, для последующих транзитный свитчей всё слилось в один влан, со всеми приколами типа mac-flapping ip gw/pppoe nas между аплинком и даунлинком и т.п. Так что надо смотреть как устроен транспорт от доступа до браса

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

застопорился на том как в 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"

 

Аргументы - адрес свича и имя файла прошивки.

Логин/пароль и адрес сервера вбиваются в скрипт, можно и их в аргументы вынести.

Лучше приведённого выше варианта тем, что не ждёт тупо по секунде, а реагирует на интерфейс.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я массовый конфиг свитчей делал через заббикс и все бэкапится там же на tftp-сервер.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я уже написал что делать. Проверьте для начало это.

Вы написали только кто микротик главный подозреваемый. Что в нём смотреть надо? Процессоры загружены на 5-10%, в логе ничего подозрительного нет. Что ещё смотреть?

Не надо никакое по на 256 коммутаторов- пару скриптов на шелле достаточно. Или вообще напишите генератор конфига и залейте все вручную.

Эти пару скриптов заколебёшся писать. Я пока застопорился на том как в bash-скрипте реализовать вход по телнету, нужно через секундрую паузу передать пароль ведь.

Что смотреть - не знаю. Я не работал с микротиком.

Если в момент проблемы рубануть крупный сегмент сети (чтоб снизить нагрузку) - проблема уйдет?

Я бы первым делом попробовал его заменить на что-нибудь другое. Если не на что - договаривайтесь, например, с НАГом, берите железку в тест и смотрите ситуацию.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если допустим где-то не включён loopdetect и там как раз образована петля, я бы wireshark-ом увидел наличие широковещательного шторма. А тут я вижу, что у меня 99% трафика - tcp-трафик

А что, TCP траффик каким-то волшебным образом защищен от петель?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Эти пару скриптов заколебёшся писать. Я пока застопорился на том как в bash-скрипте реализовать вход по телнету, нужно через секундрую паузу передать пароль ведь.

 

Ключевое слово для поиска в гугле - expect(1)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

вообще перечитал стартовое сообщение ТСа.

Оно очень напомнило панические вопли фиговых сисадминов, которые ни чего не умеют и ни чего толком объяснить не могут.

Выражения типа "лагает сеть" "падает скорость" и т.п. могут говорить юзеры и ламеры, а человек которому доверили управлять этим огромным хозяйством должен говорить конкретно что падает и в каком месте.

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

Вместо микротика для теста можно уже собрать софтроутер и посмотреть что будет.

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

Проблема явно или в микротике (90%) или в хьюлете (10%), поэтому все эти рассуждения о коммутаторах и настройках сети к решению проблемы отношения не имеют.

Изменено пользователем sergsa

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

кстати, по поводу qinq и vlan-per-user многие забывают, что как только навесили вторую метку, для последующих транзитный свитчей всё слилось в один влан, со всеми приколами типа mac-flapping ip gw/pppoe nas между аплинком и даунлинком и т.п. Так что надо смотреть как устроен транспорт от доступа до браса

+1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

все это танцы с бубном. По факту нужно просто делать по нормальному, а это 1влан-1пользователь и все, и ни чего больше не нужно настраивать, QinQ 1порт-101 влан 24порт - 124 влан и так на всех свичах. А все эти обрезания это не правильно от них весь геморой, то там не то то здесь не так, потом помнить нужно зачем это порезал, а зачем то.

ЗЫ скиньте сюда стандартный ACL который на всех свичах висит, ради интереса.

чтоб нормально не настраивать придумали костыль traffic_segmentation

Я уже слышал это мнение и сам прекрасно понимаю, что 1влан-1пользователь - это идеальная схема. Но вы же понимаете, что перейти на эту схему просто так нельзя, нужно приобретать различное ПО: во-первых нужно ПО для автоматического управления свитчами, во-вторых нужна интеграция этого ПО с биллингом, чтобы как только оператор заводит/изменяет в биллинге пользователя - для него сразу же прописывался влан. Вполне может быть так, что систему биллинга вообще придётся менять, а это значит - перенос абонентов в другой биллинг, заказ ПО, стоимость такой модернизации может быть до полумиллиона рублей.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Лол. Вера в некое ПО, которое всё сделает за вас - вот ваша проблема в абонентской сети.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Угу.

Если схема "звезда" и включена изоляция портов, то отлично работает.

Для каждого масштаба и случая есть своя оптимальная схема. Где-то оптимальным будет S-VLAN (VLAN на сервис) и PPPoE, где-то C-VLAN (VLAN на абонента) и IPoE, а где-то L3-доступ.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

В биллинге синхронно с этой пачкой вланов прописывается пачка учёток.

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

В итоге при работе с физлицами трогать настройки свичей не требуется вовсе.

 

Где-то оптимальным будет S-VLAN (VLAN на сервис) и PPPoE, где-то C-VLAN (VLAN на абонента) и IPoE
А где может быть оптимальным пппое, кроме сети с неуправляемыми свичами?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А где может быть оптимальным пппое, кроме сети с неуправляемыми свичами?

Много где.

У нас изначально полностью управляемый доступ, по порту на абонента.

Однако нам PPPoE удобнее, чем IPoE.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ПППоЕ снимает многие геморрои, уходить с него особо не хочется

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я уже слышал это мнение и сам прекрасно понимаю, что 1влан-1пользователь - это идеальная схема. Но вы же понимаете, что перейти на эту схему просто так нельзя, нужно приобретать различное ПО: во-первых нужно ПО для автоматического управления свитчами, во-вторых нужна интеграция этого ПО с биллингом, чтобы как только оператор заводит/изменяет в биллинге пользователя - для него сразу же прописывался влан. Вполне может быть так, что систему биллинга вообще придётся менять, а это значит - перенос абонентов в другой биллинг, заказ ПО, стоимость такой модернизации может быть до полумиллиона рублей.

это даже UTM умеет за 30тр

Изменено пользователем sergsa

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

это даже UTM умеет за 30тр

Ну наговорите сейчас.

Прямо вот САМА UTM5 (установленная из коробки) лезет на свич и прописывает туда VLAN?

Это где сказка то такая :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

это даже UTM умеет за 30тр

Прямо вот САМА UTM5 (установленная из коробки) лезет на свич и прописывает туда VLAN?

ага и еще кофе наливает:)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

вообще перечитал стартовое сообщение ТСа.

Оно очень напомнило панические вопли фиговых сисадминов, которые ни чего не умеют и ни чего толком объяснить не могут.

Выражения типа "лагает сеть" "падает скорость" и т.п. могут говорить юзеры и ламеры, а человек которому доверили управлять этим огромным хозяйством должен говорить конкретно что падает и в каком месте.

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

Вместо микротика для теста можно уже собрать софтроутер и посмотреть что будет.

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

Проблема явно или в микротике (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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

По пингам с ноутбука... то есть вы хотите сказать, что простой пинг - более подходящий инструмент для тестирования чем ресурс speedtest.net и btest? И какой пинг в идеале должен быть? Я конечно да, подозреваю что я как раз неправильно средствами измерения пользуюсь.

ну я хз, что на это ответить,

может нанять человека который хоть что-то умеет

А куда делся человек который все это настраивал?

Изменено пользователем sergsa

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да, и у меня появилась ещё одна версия. Прочитал недавно статью как правильно нужно настраивать шейпинг на микротике https://habrahabr.ru/post/188718/ Вобщем у нас всё не так как в статье: дерева очередей в Queue tree нет, наличествуют очереди в Simple Queue и всё, причём очереди типа SFQ.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Включения traffic_segmentation и блокировки левых DHCP достаточно. Есть опыт покупки подобных провайдерских сетей - в первую очередь там ставились умные железки и включался traffic_segmentation - сразу почти все проблемы решались. Ну а потом уже всякие acl, сегментация по вланам и прочий план по интеграции клиентов купленного провайдера к нам.

 

Можно мне чуть попинать? ) НЕ НАДО ЭТОГО Делать! Я как-то поверил, человеку. И выбрал эту схему, всю сеть лагало и штормило. Не делайте так.

 

Каждый два три коммутатора, а лучше коммутатор в отдельном пользовательском вилане. На каждый район, отдельный управляемый вилан управления, и общий вилан управления.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.