nixx

блочил dst порт 123 в сторону циски на вышестоящем бордере ) ntp-флуд шёл.

нарисуйте графики pps по интерфейсам - нет ли там ощутимых всплесков? и на интерфейсах, которые в эту циску смотрят - тоже. если есть - то вас досят, у меня аналогично выглядело.

по первой ссылке, увы, ничего нового не увидел, а вторую нагуглил еще месяц назад, вдумчиво прочитал, и в целом согласен с высказанным тезисом о "К примеру, ограничивать/лимитировать кол-во arp от абонентов приведет к нестабильному сервису у абонентов - снизим нагрузку на CPU, а у абонентов будут возникать "мифические пропадание инета", отловом которого заниматься ой как не просто." я просто уже нарвался на такое с микротиководами, у которых лимитированный icmp до этой самой 4500х вызывал отвалы микротиков по причине включенного "check gateway". ну понятное дело, что настраивателю лимитов надо было включать моск и осознавать, что можно поставить лимиты более мягкие, но тем не менее факт наблюдался, и мне он крайне не нравится, как и заметное приподнятие занятости cpu при повышении лимита. но, к сожалению, судя при приведенному примеру конфига, все сводится именно к тому, что разрешаем только нужное, и то далеко не "на всю катушку", а все остальное режем нахрен. "какой ты чувствительный мальчик" - хочется сказать процессорам цисок. а что у вас попадает в этот класс? мне не кусок конфига, мне смысл интересен - что сюда попадает и как лимитируется (режется совсем или же есть какой-то transmit). и про CoPP-Unwanted аналогичный вопрос. ну и глядя на посты от 2015 года осознаю, что не тем я занимаюсь, и надо всё же думать в сторону апгрейда на что-то более современное/быстрое.

Стоит в качестве L3-молотилки c4500x, много чего роутит. Много абонентов с белыми адресами. Загрузка процессора скачет, как хрен пойми что. В течение дня может меняться от 60 до 100 процентов (из 200), причем без корреляции с объемом проходящего трафика. В основном жрет процесс "k5cpuman review" Полез дампить трафик с проца, искать причины Вижу, что (судя по симптомам и гуглу - в списках в инете находится) один абонент с белым адресом поднял у себя dns, открыл всему миру и спустя какое-то время ушел в оффлайн. Вижу, что на процессор циски извне летит охулиард DNS-запросов в сторону абонента (ну не прям так много, но явно выделяются из остального трафика). Блокирую на бордере (выше циски) весь трафик к этому абоненту - загрузка проца падает процентов на 12-15. Собственно, вопрос - это лечится, скажем так, встроенными средствами циски, или же оно обречено умирать от любого чиха в сторону ненайденных в arp-записях абонентов? Настроить на CoPP какие-нибудь лимиты для 53 порта я думал, но это лечение конкретной ситуации... а их может быть сотня, и все разные. ну и со сниффером около циски особо сидеть неохота каждый день. Посидеть, подумать о реально нужном трафике и тупо зарезать всё, что кроме? Какие-то варианты шаманства с CoPP, которые я пока не знаю, на тему "игнорить всё, что никому"? У меня ощущение, что старый добрый мангал sup720 был гораздо дубовей в плане реакции на подобные раздражители. ps: есть у кого-нибудь опыт с brocade vdx6740 или чем-то подобным? на замену 4500 думаю. ну или послушал бы чью-то success-story с апгрейдом на что-то другое. апгрейд хочется просто потому, что сейчас на циске порты кончились, а нужно еще много. вариант либо городить vss со второй, либо что-то колхозить с дополнительным L2-железом, либо всё же апгрейд до 48 портового чего-нибудь, да и 40гбит хотелось бы. попутно при апгрейде и с занятостью процессора решить бы вопрос. pps: реально там проц загружен всем подряд, всякой фигни нашел типа реалтековского и микротиковского лупдетектов, ipv6-флуда от глючных роутеров, и т.п. Но это всё более-менее классифицируется и режется на доступе.

переслал конфиги в личку. меня в сложившейся ситуации удручает то, что задание sla upload не вылечивает глюк, а обходит/уменьшает его. ну то есть возникшая зарезка скорости не пропадает, а просто я ее приподнимаю заданием sla upload. пропадает же глюк в результате не совсем понятных действий - либо при передергивании порта OLT, либо после ребута ONU. а в прошлый раз (примерно неделю назад) глюк пропал сам по себе - ночью тормозило, а на следующий день начал тестить - скорость опять нормальная. никто ничего не делал. если бы гарантированно лечилось - то я бы и не чесался особо - задал эту команду на все онушки, и вперед с песней.

очередные научные изыскания показали следующее 1) на этот раз последовательный ребут всех онушек на порту не дал увеличения скорости 2) задавал sla последовательно такими командами и имел в соответствии с ними следующие скорости upload (скорость показывал постоянно включенный iperf3) epon sla upstream pir 110000 cir 1000 - 46,7 epon sla upstream pir 130000 cir 1000 - 54,4 epon sla upstream pir 150000 cir 1000 - 62,2 epon sla upstream pir 170000 cir 1000 - 70,0 epon sla upstream pir 190000 cir 1000 - 77,8 epon sla upstream pir 210000 cir 1000 - 85,4 epon sla upstream pir 230000 cir 1000 - 93,2 epon sla upstream pir 250000 cir 1000 - 101 изменения cir не влияют на upload-скорость никак. пробовал и 5000, и 10000, 100000. напомню, без epon sla скорость от абонента - 42,8-43 мбита прошивка 101750 на OLT P3608B в свете приведенных наблюдений мне так видится, что голова по какой-то причине косеет, и у неё откуда-то вылезает коэффициент уменьшения скорости, равный примерно 2,4-2,5 - то есть задаваемое в pir значение голова делит на 2,5 и выдает в таком виде абоненту. для дефолтного значения, которое тут приводили, этот коэффициент тоже подходит (100 дефолтно - 42,8 реально). @Nikita Devyatyarov можете попинать разработчиков на тему "чтозафигня" с озвучиванием коэффициента? или уже пробовали, и тишина в ответ? )

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

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

))) у меня один коллега настроил злодейский CoPP на шлюзе сети, так что там пролезало хорошо если 10-20 icmp в секунду (не помню цифры, но мало очень). а другие коллеги-микротиководы включают check gateway в настройках, хотя у них вообще всего один gateway, никаких других нет. это, если что, каждые 10 секунд пинг-понг летит. причем каждые 10 секунд шлюз - это еще фигня. я одного такого попингуя отснифал, что ему яндекс unreachable возвращает на каждый второй пинг, вот задолбать как можно. и посыпались че-то жалобы от этих микротиководов (реально штук десять за день от разных абонентов), мол, у вас сеть падает. полез я разбираться и... это не у нас сеть падает, это у вас микротик ее рубит к черту, не получая ответа на пинг. маленько увеличил лимиты, позвонил особо страдающим. вроде устаканилось. но вообще такое вот бездумное "мы тут нажмем галочку, пусть проверяется, а зачем - мы сами не знаем" огорчает крайне.

не можете. C3KX-NM-10G - это либо 4 SFP (1г), либо 2 SFP+ (10г). в случае втыкания 10г соседний 1г отключается. соответственно, на четыре свитча у вас 8 портов 10г.

500 мбит. 70 пк. 7 мбит на пк в среднем. по третьему пункту - вопрос в том, какая реальная скорость нужна? ну, допустим, я вполне поверю, что между серверами виртуалок нужно >1гбита, и оно будет изредка использоваться. но в локалке-то? повторю свой вопрос - в чем смысл переделки сети? у вас что-то не работает/медленно работает/глючит/пакеты пропадают? вы вешали мониторинг на все интерфейсы и видите, что у вас есть узкие места? (где?) чего вы хотите добиться? чтобы вам санкционировали поездки за хлебом на тесле, а не на жигулях? или, всё же, скорость разгона от 1 до 100 в вашем случае играет роль? я бы сделал треугольник с "головой" в виде 1036, если серверам нужен инет независимо от работы вашей локалки юзерской. на нексусе дефолт-роут в сторону 1036, отдельные роуты на абонсети в сторону 3750. на 3750 симметрично. все эти лацпы - от лукавого. повесьте мониторинг, померяйте трафик за неделю работы, потом оцените, нужно ли вам вообще 10г )) я не против мощного железа, я против усложнения конфигурации там, где оно никуда не впилось. ps: у меня, например, хосты виртуалок двумя десятками смотрят в отдельный изолированный свитч для междусобойчика, а двумя 1г портами - в абонентов.

зачем переделывали-то "10 раз"? в чем смысл переделываний был и остается? чего вы хотите добиться? у вас есть узкие места, где все тормозит? у вас просто что-то тормозит непонятно почему? иначе зачем переделывать то, что и так работает? у меня была "коллега" на работе - она раз в 3-5 месяцев передвигала мебель в кабинете. ну просто потому, что хотелось че-то новенького в обстановке. 1036 у вас какая модель? если там есть 10г - зачем городить LACP, который дополнительно кушает проц? у вас реально суммарного трафика от обоих ISP больше 1г? или оба ISP воткнуты в 10г, и свободными остаются только 1г? ps: от меня на одном скромном заводе настойчиво требовали везде делать агрегацию магистральных портов, потому как "у нас очень много трафика". ну сделал... "очень много" в дальнейшем, когда поднял мониторинг, оказалось до 300мбит редкими всплесками.

нет, убрал родителя вообще. все очереди теперь одного уровня.

дабы закрыть вопрос, если вдруг кто-то с тем же столкнется - конкретная причина так и осталась невыясненной, но в процессе переконфигурации конкретно этих, про которые писал, а так же выводка других микротиков, были выявлены следующие забавности 1) все очереди сидели под одной родительской. в силу неумения микротика корректно балансировать по ядрам такую конфигурацию, наблюдались стремительные взлеты занятости процессора при достижении трафиком какого-то относительно небольшого значения 2) зверинец с мту, который вел к перепаковке пакетов и сказочным тормозам в совершенно неожиданных местах. ну то есть, к примеру, download у абонента 50, upload - 2. меняем мту на всех портах по пути к ядру (приводим к общему значению) - все нормализуется. 3) разнобой в файерволлах мне сразу бросился в глаза, но никакой конкретики я не смог из этого вывести. теперь же, по итогам - во-первых, местами был включен маскарадинг вообще не абонентского трафика (просто делали тестовые подключения, и за собой не убирали после тестов), местами был включен фасттрак, очереди присутствовали везде. что в это время думал микротик, пытаясь одновременно оценить надобность ната, прошейпить и отфасттрачить трафик - наверное это было прикольно. 4) input-файерволл в 80% конфигураций отсутствовал вообще. также были включены все сервисы, mndp и прочее. думаю, понятно, что не лез в микротик только ленивый. 5) микротики, где их было больше одного, были подключены друг за дружкой, т.е. первый роутил трафик для второго, третьего и далее. я поудивлялся такой концепции и включил все напрямую. наверное было еще что-то, сейчас пока не вспоминается. как итог избавления от перечисленных недостатков - с ноября-декабря полет нормальный, подобных глюков не вылезает, трафик понемножку лезет вверх (а где-то и не понемножку), в паре мест снял 1036, т.к. мощи 1009 хватило за глаза. зато вылезли глюки с бдкомами, которые раньше были незаметны на фоне остальных ))) ps: еще на текущий момент очень интересует рабочий и малоресурсоемкий метод редиректа заблоченных абонентов на соцсайты и личный кабинет с помощью микротиков при условии, что закрывается инет абоненту выключением его очереди. upd: во, вспомнилась еще одна пакость. после вылизывания конфигов, приведения их к общему виду и т.д. и т.п. микротик стал переставать быть DNS )) т.е. он и до моих вмешательств, и после них работал в качестве DNS-форвардера на сервера яндекса, гугла, клаудфлара, абонентам выдавался адрес микротика в качестве DNS. ну и либо через день, либо через три, либо вообще через полдня после полного причесывания конфига и контрольного ребута от абонентов начинали сыпаться заявки о неработе интернета, которые после начала разбирательств оказывались отсутствием DNS-ответов от микротика. причина, опять-таки, непонятна... просто переставал, и всё. ребут помогал, но не более, чем на пару суток. на третьем-четвертом "причесывании" я уже не заморачивался и сразу вписывал в DHCP выдачу яндексовских днсов, а сейчас поднял пару своих isc-bind и выдаю их абонентам. вообще проблемы с DNS были и до меня, но так... очень эпизодически на трех-четырех узлах. после моих же действий они наступали быстро и гарантированно везде.

дык вот и я в мануале ничего не нашел про "разность", но такая упертость в одну сторону наводит на подозрения. на SFP-порту ошибки - как? )) моя модель не показывает ничего, только FRM красным мигает, если действительно ошибки (было плохое волокно, потом поменяли - потоку не помогло, но уровень стал нормальный и моргать перестало). прошивки - нет. для моих не бывает. я вроде бы с их сайта, когда он еще был жив, стянул список версий прошивок. там даже намёка нет (у меня v3.02.3e73)

в очередной раз подумал, что я чего-то не знаю. но нет, наоборот )) "export" и "export compact" выдают идентичные текстовики конфигов на выходе. и их совершенно неудобно парсить (по крайней мере, мне - не знаю, как вам).

кто-нибудь обладает воспоминаниями, или может у кого оно еще в работе стоит - имеется ли у таких конвертеров/мультиплексоров зависимость master/slave? или еще какие-то тараканы? конкретно интересует модель T501.116, вот такая: https://shop.nag.ru/catalog/02601.voip-telefoniya-ip-domofoniya/02335.opticheskie-multipleksory-e1/28361.t501116804 поднимал E1-поток с их помощью между собой и "аплинком". сам поток поднимался нормально, но внутри все время колбасились каналы - и D-канал, и обычные. то работают, то нет. поменял один из конвертеров - все заработало. ну "паламатый" подумалось. сейчас понадобилось между теми же конвертерами поднять еще один E1-поток в другом направлении (ну т.е. "аплинк" с другой стороны). и "снова здорово" - точно так же колбасится D-канал. при этом с первым потоком проблем нет.

@passer спасибо. мне, вот, тоже кажется, что ситуация вряд ли индивидуальна для нас, наверняка кто-то сталкивался, и неоднократно, если у нас она вылезает достаточно массово при отсутствии каких-либо извращений с конфигурациями. и это хороший повод для нас таки начать использовать шаблоны )) и перестать присваивать онушкам айпишники заодно. но пока подожду ответа от @Nikita Devyatyarov, может у bdcom'а/snr какие-то еще рекомендации или подсказки по поиску причины есть по этому случаю. сейчас попробовал с разным cir - вплоть до 1000 - пофигу, все равно скорость становится нормальной, лишь бы что-то указать. делаю no epon sla upstream - опять падает до 43. но все-таки интересно знать причину - что виновато )

дождался своих любимых 43мбит на upload написал онушке одну команду: epon sla upstream pir 200000 cir 60000 и сразу локальный спидтест показал мне 80 мбит в обе стороны (на шейпере стоит 80 ограничение). потом сказал no epon sla upstream и мой аплоад вернулся в прежние 43мбита. то есть по логике работы, озвученной вами, кто-то отъедает upload-полосу (временнЫе слоты или как их назвать?) и не отдает ее другим? и по моим дерганиям других абонентов прошлый раз предположительно выходит, что это кто-то один. кто именно этот один - я выясню, подергаю еще раз. что дальше (или до выяснения) делать? )) как лечить и в чем может быть причина? кривая онушка?

из личного опыта - попробуйте делать не "export", а "export terse" - такой формат удобнее парсить в случае необходимости.

насколько я понял из чтения всяких докладов гуру микротиков, ОДНА очередь верхнего уровня (пусть будет родительская) крайне хреново балансируется между ядрами вместе со всеми своими детьми. родителей нужно минимум по числу ядер (в случае 1036), а лучше вдвое больше в случае ccr1009. ну или вообще их не использовать, да - т.е. все очереди должны быть одного уровня, никаких родителей-детей. переход от "один родитель - много детей" к "много очередей одного уровня" дал снижение нагрузки со 100% в чнн до 40-60% на 1009-х ccr. речь про simple queue.

это ядра, выделенные на виртуалку с ZS. на хосте гипертрейдинг включен. процы типа E5-2670, 2680. количество ядер выделяю такое, чтобы нагрузка выше 50% не поднималась. ну то есть считайте, что в ЧНН примерно 40-45% нагрузка.

про гарантированную я не подумал, пробовал крутить pir'ы ранее и bandwidth. ну теперь жду очередного падения скорости. если по предыдущим разам сопоставлять, то это не раньше, чем через неделю.

спасибо, попробую в ближайшие пару дней. или тройку, в праздник не буду трогать. IPSG и DAI всю жизнь (кажется) имели ограничение на число вланов, где они включены, оно не мешает. нужен только снупинг. причем я сам офигел, когда мне рассказали причину, зачем он используется - есть абоненты с роутерами Asus, которые ни в какую не хотят получать по dhcp адрес от микротика, роутящего трафик с OLT. а вот если включить на голове снупинг, то... начинают получать. что-то с микротиками, по всей видимости, не так. но что - пока не дошли руки доковыряться. upd: перешил, вторые сутки - всё норм, абоненты не ругаются, снупинг включён на все вланы (500 шт).

ну если динамически меняется, то хотя бы в 4 ночи, когда в целом по PON-порту бежит не больше 50 мбит суммарно ко всем абонентам и мегабит 10-20 от них - может же мне голова выделить больше, чем 43 мбита? ) или существуют еще какие-то причины, почему не может? то, что 100мбит по дефолту - это я в курсе. но серьезно, что может быть не так? я себе уже свою голову сломал, пытаясь понять, где проблема, особенно с моими "знаниями", как работает PON, основанными лишь на органолептических исследованиях ) вот прислали прошивку на ONU CData (причем сильно свежЕе, чем у меня залита), буду пробовать, как высплюсь. upd: перешивка ONU ничего не дала. рестарт по питанию делал, ресет зажимал. скорость без изменений. upd2: начал ребутить последовательно абонентские ONU на порту в ночи. после ребута очередных трёх штук скорость на моей поднялась до 100мбит. в связи с этим более другой вопрос - куда копать - в сторону оптики/физики, или же в сторону кривой ONU у абонента?