Igore

благодарю

Добрый день, подскажите как возможно через Jun MX 204 сбросить сессию сразу пулу адресов , по сессии получается сбрасывать так clear network-access aaa subscriber session-id "номер сессии" , а как сбрасывать сессию именно по сетке адресов например 192.168.1.0/24 или по имени пула адресов . перерыл все мануалы . подскажите решение ?

Доброе утро, подскажите на OLT-Huawei 5608 t , как настроить блокировку левых dhcp , не могу найти есть вообще dhcp snooping ?

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

насколько знаю igmp должен быть выключен так просит клиент . bridge multicast filtering по сути не нужен если по сети не проходит конкретно настройка самого потока ?

дело не в mtu т.к ранее все работало и mtu там используют 1500

клиенты разные и точки включения кто знает как работает на елтексе bridge multicast filtering ??? , есть подозрения что когда выключаем на главном , режит полностью мультикаст . оспф вроде как вообще теряем мультикаст , а когда включем отпадает но хоть трафик есть

так по мультикасту бегает

это клиента железо ничего не будут переключать , просят решит вопрос , а у нас все как было и ранее вот неделю назад все работало ))) MTU 1560 на olt максимальное а на елтексах везде 9000 jumbo frame уже везде сняли даже storm control интерфейсы чистые только вланы проходят .

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

максимальное mtu стоит 1560 , на агг Елтекс откуда бошка включена , jumbo frame 9000 mtu

Добрый день , обратился клиент с проблемой при переключение на наш канал оспф автоматом переключается на резерв , диагноз потеря hello пакетов по мультикасту . как то проверить оспф нет возможности , клиент берет просто выделенный влан и гоняет OSPF все внутри влана . у нас просто выделен влан и подается на клиента в режиме access . проблема обнаружена у нескольких клиентов , закономерность то что они подключены по gpon OLT Huawei 5608T , онушку меняли не помогает . на агрегации стоят свитчи eltex там все проверили нет ограничений мультикаста самое интересное что все работало ранее , пару дней назад просто пошли потери , подняли интерфейс проверить физику . потерь icmp нет канал работает без потерь , потери только по мультикасту . одного их клиентов переключили на FTTH поставили просто медик и включили прямым линком , и проблема ушла , т.е проблема идет на конечноv узле видимо olt не пропускает . Подскажите как быть кто сталкивался ?

ну вы наверно не читали что я спрашиваю , мы так и делаем чтобы отрубить плохой сигнал , а я спрашиваю как найти ону какими способами еще с головы программно , чтобы не ломать волокна   и опять же я ж написал что это происходит не постоянно , есть случаи когда монтер загибает но смысла в этом нет потому что ону посылает сигнал в определенное время не всегда   а сколько ну на магистральные волокна на другие сплитеры и абонентские с корня ну где то 30 волокон примерно ))) , загибай с монтером без толку по 1 волокну )0

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

спасибо большое, я это давно уже включал, и без переводчика понятно что они изолируют ону , только толку от этого ? если на поне 128 онушек , голова автоматом изолирует допустим 50 онушек они отпадают и что дальше как должен понять какая срет ?? в этом то и вопрос   я изолирую онухи вручную они отпадают сигнал пропадает , перезагрузка и ону опять в сети , тоже самое при втоматическом обнаружении автоматом блокируется пачка онушек , одна из них есть мошенник и что какая из них ?   меня интересует как найти именно нужную онуху чтобы не ездить по абонентам и не менять все онухи   ложим по 1 ону , вы думаете я это не делал ? я с этим боримся уже очень давно   я вырубаю 128 онушек и включаю по 1 ону , и чсто получается в итоге : часть онушек сами не стартуют надо перегружать , т.е ждать заявки от абона или мониторить пока он ее перегрузит , и есть тонкость что ошибка про мошшеник ону вылазит не всегда а рандомно . она шлет сигнал паразитный не всегда , например прошлый раз нашли онуху по времени она слала сигнал только когда включалась . случайно нашли   а теперь ситуация другая . сигнал идет в разное время в этот момент отпадает много ону , я попадал когда это происходило примерно пол часа . и что я вырубил все ону включал по 1 и ничего это не дало. в эти момент ошибку не выдавало . прошло время опять начала срать

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

и как дальше найти срущую ? на поне 128 абонов , и что мне все вырубать и искать одну это не реально

когда включаю anti-rogueont isolate отпадают онухи , они наглухо отваливаются это для поиска срущей ? или должна появится ону которая срет в логах ?

anti-rogueont isolate 0/3/3 10 каждую ону изолировать ? в логах будет писаться какая онуха срет после этого ?

подробнее можно не совсем понял, указать онухе отключить gpon sfp порт , это как вообще , есть такая команда на huawei olt 5608 t или так от фонаря написали ?   я даже не представляю каким образом это сделать и вообще для чего это делать если при срани на поне он и так падает . какой смысл мне shutdown порт делать если онухи и так отпадают ?   ALARM 450817 RECOVERY CLEARED 0x2e324021 EQUIPMENT 2021-07-08 10:29:26+02:00 ALARM NAME : The illegal incursionary rogue ONTs under the port have been cleared SRVEFF : NSA PARAMETERS : FrameID: 0, SlotID: 1, PortID: 3 DESCRIPTION : The illegal incursionary rogue ONTs under the port have been cleared CAUSE : All illegal incursionary rogue ONTs have been replaced under the port ADVICE : No need to deal with it --- END ALARM 450815 FAULT MAJOR 0x2e314021 EQUIPMENT 2021-07-08 10:29:21+02:00 ALARM NAME : There are illegal incursionary rogue ONTs under the port SRVEFF : SA PARAMETERS : FrameID: 0, SlotID: 1, PortID: 3 DESCRIPTION : There are illegal incursionary rogue ONTs under the port, it will interrupt service of other ONT(s) CAUSE : There is illegal incursionary rogue ONT under the port ADVICE : Detect rogue ont manually, and then replace it --- END   ПИШИТ ВЫЯВИ САМ МОШЕННЕЧЕСКУЮ ОНУ И ОТКЛЮЧИ ВОЛОКНО , ВОТ И ВЕСЬ ЛОГ . КАК Я ДОЛЖЕН ЗНАТЬ КАКАЯ ОНУ СРЕТ ,

разделение на вланы и виртуальные порты gpon 128 мест епон -64 , каждый виртуальный порт идет на access vlan , магистральные порты под trunk все просто

MES2324FB 28-port 1G/10G

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

я не видел ниразу чтобы серийник при таких ошибках светился , уже обрыл все форумы чтобы найти способ отловить именно серийник , в сети был случай такой же ошибки в итоге таким же способом нашил волокно которое светило сигналом в голову , это окалась онуха picotel и лог серийник не выдавал   может есть способ в нас тройках что то добавить чтобы ловило онуху которая срет в сеть .ю я больше чем уверен что это ону   я пробиваю модели онушек на поне и вижу такое 0/ 1/ 3/ 0 MONU 0/ 1/ 3/ 1 EPON 0/ 1/ 3/ 2 FORA 0/ 1/ 3/ 3 HWTC 0/ 1/ 3/ 4 RC 0/ 1/ 3/ 5 RC 0/ 1/ 3/ 6 MONU 0/ 1/ 3/ 7 HWTC 0/ 1/ 3/ 8 PICO 0/ 1/ 3/ 9 XPON 0/ 1/ 3/ 10 - 0/ 1/ 3/ 11 PHIC 0/ 1/ 3/ 12 XPON 0/ 1/ 3/ 13 XPON 0/ 1/ 3/ 14 XPON 0/ 1/ 3/ 15 XPON 0/ 1/ 3/ 16 PICO 0/ 1/ 3/ 18 HWTC 0/ 1/ 3/ 19 XPON 0/ 1/ 3/ 20 XPON 0/ 1/ 3/ 21 xPON 0/ 1/ 3/ 22 XPON 0/ 1/ 3/ 23 HWTC 0/ 1/ 3/ 24 MONU 0/ 1/ 3/ 25 ZTE 0/ 1/ 3/ 26 MONU 0/ 1/ 3/ 27 ZTE 0/ 1/ 3/ 28 HWTC 0/ 1/ 3/ 29 HWTC 0/ 1/ 3/ 30 HWTC 0/ 1/ 3/ 31 HWTC 0/ 1/ 3/ 32 HWTC   весьо пон в сети , в логах выдает аларм что есть мошенническая ону отпадает пон и поднимается , при этом они все в сети . по моделям это онухи   единственно есть вариант что висит волокно расторженца и там втыкнут медик . ну как это мало вероятно ...

добрый день. стоит голова Huawei olt 5608t . выдает на пон такой аларм ALARM 443190 FAULT MAJOR 0x2e314021 EQUIPMENT 2021-07-01 09:23:05+02:00 ALARM NAME : There are illegal incursionary rogue ONTs under the port SRVEFF : SA PARAMETERS : FrameID: 0, SlotID: 1, PortID: 3 DESCRIPTION : There are illegal incursionary rogue ONTs under the port, it will interrupt service of other ONT(s) CAUSE : There is illegal incursionary rogue ONT under the port ADVICE : Detect rogue ont manually, and then replace it --- END Определяет что на поне обнаруженная мошенник ону . я так понимаю это кто то медик вставит 1310 или 1550 в пон ? либо онуха битая ? как с этим бороться ? кто сталкивался ? как найти ону которая срет чтобы волокно отрезать ? или только мерять сигнал и идти по сплитерам ? МНЕ НАДО КАК ТО НАЙТИ МЕСТО НА ПОНЕ КОТОРОЕ ГАДИТ И ОТРЕЗАТЬ КАБЕЛЬ , голова не показывает какая ону только алармит что сторонняя ону на поне