Azamat

Еще позавчера все было в порядке. Кто-то видимо перегнул палку в тех. составе ТТК ? Наш вышестоящий из КЗ.

Уважаемые коллеги, есть ли кто то из ТТК ? Сами мы не местные, страна дружественная, но не РФ. Для ТТК наш трафик транзитный, он оператор нашего вышестоящего оператора. Они начали фильтровать наш транзитный трафик, на какие-то весьма популярные ресурсы клиенты получают заглушку от ТТК - мол по решению мосгорсуда от такого то года ресурс заблокирован. Доступ к Интернет-ресурсу заблокирован по решению органов государственной власти Посмотреть причину блокировки можно в едином реестре В нашей стране этот же ресурс вполне себе открыт и пошли жалобы регулятору о незаконном блокировании доступа. Попытка обращения в ТТК натыкается на бюр. процедуры - мол не наш клиент и тд. Как бы побороть данный случай ? Готов предоставить в личку все необх. данные о себе, если бы это помогло решить проблему. Заранее спасибо и все такое.

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

Сегодня на живом 40 гб линке между двумя Нексусами 3064 словили какой-то жуткий косяк: вдруг на хорошей линии (по отп. показателям с модулей)начал мигать оранж/зеленый светодиод qsfp порта. На порту начали быстро расти input ошибки и что самое прикольное, одновременно начали падать/подниматься еще 4 гнезда по 10Гбит/с. Примерно раз в минуту, а то и чаще. Но, сам линк 40 гиг в логах не отражался как down/up. И показатель last flap по нему был порядка 4 недель. 2017 Aug 14 22:07:43 nex3064-mainpop.1 %ETHPORT-5-IF_DOWN_LINK_FAILURE: Interface Ethernet1/2 is down (Link failure) 2017 Aug 14 22:07:43 nex3064-mainpop.1 %ETHPORT-5-IF_DOWN_LINK_FAILURE: Interface Ethernet1/48 is down (Link failure) 2017 Aug 14 22:08:02 nex3064-mainpop.1 %ETHPORT-5-SPEED: Interface Ethernet1/2, operational speed changed to 10 Gbps 2017 Aug 14 22:08:02 nex3064-mainpop.1 %ETHPORT-5-IF_DUPLEX: Interface Ethernet1/2, operational duplex mode changed to Full 2017 Aug 14 22:08:02 nex3064-mainpop.1 %ETHPORT-5-IF_RX_FLOW_CONTROL: Interface Ethernet1/2, operational Receive Flow Control state changed to off 2017 Aug 14 22:08:02 nex3064-mainpop.1 %ETHPORT-5-IF_TX_FLOW_CONTROL: Interface Ethernet1/2, operational Transmit Flow Control state changed to off 2017 Aug 14 22:08:02 nex3064-mainpop.1 %ETHPORT-5-IF_UP: Interface Ethernet1/2 is up in mode trunk 2017 Aug 14 22:08:04 nex3064-mainpop.1 %ETHPORT-5-SPEED: Interface Ethernet1/48, operational speed changed to 10 Gbps 2017 Aug 14 22:08:04 nex3064-mainpop.1 %ETHPORT-5-IF_DUPLEX: Interface Ethernet1/48, operational duplex mode changed to Full 2017 Aug 14 22:08:04 nex3064-mainpop.1 %ETHPORT-5-IF_RX_FLOW_CONTROL: Interface Ethernet1/48, operational Receive Flow Control state changed to off 2017 Aug 14 22:08:04 nex3064-mainpop.1 %ETHPORT-5-IF_TX_FLOW_CONTROL: Interface Ethernet1/48, operational Transmit Flow Control state changed to off 2017 Aug 14 22:08:05 nex3064-mainpop.1 %ETHPORT-5-IF_UP: Interface Ethernet1/48 is up in mode trunk 2017 Aug 14 22:08:10 nex3064-mainpop.1 %ETHPORT-5-IF_DOWN_LINK_FAILURE: Interface Ethernet1/32 is down (Link failure) 2017 Aug 14 22:08:22 nex3064-mainpop.1 %ETHPORT-5-IF_DOWN_LINK_FAILURE: Interface Ethernet1/2 is down (Link failure) 2017 Aug 14 22:08:26 nex3064-mainpop.1 %ETHPORT-5-IF_DOWN_LINK_FAILURE: Interface Ethernet1/48 is down (Link failure) 2017 Aug 14 22:08:30 nex3064-mainpop.1 %ETHPORT-5-IF_DOWN_LINK_FAILURE: Interface Ethernet1/41 is down (Link failure) 2017 Aug 14 22:08:36 nex3064-mainpop.1 %ETHPORT-5-SPEED: Interface Ethernet1/2, operational speed changed to 10 Gbps 2017 Aug 14 22:08:36 nex3064-mainpop.1 %ETHPORT-5-IF_DUPLEX: Interface Ethernet1/2, operational duplex mode changed to Full 2017 Aug 14 22:08:36 nex3064-mainpop.1 %ETHPORT-5-IF_RX_FLOW_CONTROL: Interface Ethernet1/2, operational Receive Flow Control state changed to off 2017 Aug 14 22:08:36 nex3064-mainpop.1 %ETHPORT-5-IF_TX_FLOW_CONTROL: Interface Ethernet1/2, operational Transmit Flow Control state changed to off 2017 Aug 14 22:08:37 nex3064-mainpop.1 %ETHPORT-5-IF_DOWN_LINK_FAILURE: Interface Ethernet1/32 is down (Link failure) 2017 Aug 14 22:08:38 nex3064-mainpop.1 %ETHPORT-5-SPEED: Interface Ethernet1/48, operational speed changed to 10 Gbps 2017 Aug 14 22:08:38 nex3064-mainpop.1 %ETHPORT-5-IF_DUPLEX: Interface Ethernet1/48, operational duplex mode changed to Full 2017 Aug 14 22:08:38 nex3064-mainpop.1 %ETHPORT-5-IF_RX_FLOW_CONTROL: Interface Ethernet1/48, operational Receive Flow Control state changed to off 2017 Aug 14 22:08:38 nex3064-mainpop.1 %ETHPORT-5-IF_TX_FLOW_CONTROL: Interface Ethernet1/48, operational Transmit Flow Control state changed to off 2017 Aug 14 22:08:38 nex3064-mainpop.1 %ETHPORT-5-IF_UP: Interface Ethernet1/2 is up in mode trunk 2017 Aug 14 22:08:38 nex3064-mainpop.1 %ETHPORT-5-IF_UP: Interface Ethernet1/48 is up in mode trunk 2017 Aug 14 22:08:40 nex3064-mainpop.1 %ETHPORT-5-SPEED: Interface Ethernet1/41, operational speed changed to 10 Gbps 2017 Aug 14 22:08:40 nex3064-mainpop.1 %ETHPORT-5-IF_DUPLEX: Interface Ethernet1/41, operational duplex mode changed to Full Если вытащить из гнезда модуль QSFP - остальные 4 гнезда по 10гиг перестают падать/подниматься. Вставляешь обратно QSFP - снова глюки. В конце концов разобрали линк 40 гиг на два по 10, благо хватило по полосе. И после этого снова полет нормальный. Сам линк на 40 был запущен с полгода назад, все это время работал без нареканий. А сегодня прям взбесился. Мистика какая-то.

у нас 4 шт, на всех такой косяк. Может быть вы кол-во циклов туда/сюда не набирали, чтобы на всех ваших проявился :) Видимо что то аппаратное действительно.

Доброго дня, коллеги. Наткнулся на какой-то лютый косяк у nexus N3K-C3064PQ-10GE (на 4 шт точно), может кто-то сталкивался - побеждал/как именно ? При втыкании/извлечении (бывает сразу, бывает с 2-3 цикла) модуля QSFP гнездо на шасси "засыпает", далее при втыкании модуля перестает работать (что опт. трансивер, что медный кабель). Когда гнездо "заснуло" светодиод занятости горит или в оранжевом (мол гнездо пустое) или не горит вообще - мол модуль есть, но линк не поднимается. Лечится только перезагрузкой. Никакие shut/no shut не помогают. После перезагрузки гнезда работают нормально до след. цикла извлечения по какой-либо надобности. Хорошо их там 4, уже пара штук в работе, у которых по 2-3 гнезда "уснули", но линк на 40 работает в последнем гнезде. При этом 10Гб гнезда работают без нареканий.

Еще вопрос - находится ли абонентская приставка в заказанной группе в момент фриза ? show mvr members показывает абонентский порт в целевой группе ? Если приставка в группе, а коммутатор не выливает в порт ТВ траффик - проблема может быть аппаратная, igmp здесь будет не причем. А если у абонента две приставки - фризы одновременно на обеих приставках ? в случае если заказана одна и та же группа или разные группы на каждую из приставок дамп на самой приставке показывает получение GQ И GSQ и ответный report по целевой группе ?

На 4948 типичный график по памяти выглядит так (Version 15.1(1)SG, RELEASE SOFTWARE (fc3)) : Таких порядка 7 из 12, остальные уже на 12.2.54

наверное лечится. Но, после ребута может и вообще не подняться. Так одна померла 4900. Поэтому будем ждать пока не сдохнет и заменим. Может еще год поработает.

4900 нормально. Но там свои тараканы, сейчас на одной не работает арп подсистема. Замену подготовили, ждем когда окончательно сдохнет.

вот с одного из 4948 uptime is 20 weeks, 6 days, 11 hours, 12 minutes Processor Pool Total: 974059152 Used: 424027520 Free: 550031632 138 0 250317320 232 184079236 43717152 0 Spanning Tree вообще процессы разные лопают память, где спт, где пим

У нас на всех 4948 на 15.1 утекает память примерно за 4-6 мес до подвисания - ребутим ночью на уровне 40М оставшейся памяти. Размещал здесь топик, но не нашлось решения. Некоторые процессы набирают память, но не возвращают в пул свободной. Зато подходят любые DA кабеля на 10гб. На 12.56 подошел только 1 типа DA кабеля из 6 что у нас используются. Потихоньку переводим на 12.56

copp наверное бы по порогам работал. Текущий арп поток в сторону ЦПУ мизерный, никакой copp бы его не заметил. ACL тоже никаких не прибавилось. ARP ответы есть на входящем порту 4900. Но в таблицу арп не заносятся.

Включал, и не на секунду. Не показывает :( Типа запрос ушел, через время - запрос истек. Проц 4900 arp запросы отправляет исправно, их видно в дампах. Хосты ему так же исправно отвечают, reply тоже видны в дампах на соотв. интерфейсах целевых серверов. Маки серверов есть на соотв. портах на 4900. А арп записей нет. Как будто дропаются арп ответы - но где и чем ..

В логах вообще ничего не пишет по этой теме. Всякая ерунда по уровням на оптике и редкие мак-флэп. show ip cef вполне себе кажет массу установленных маршрутов. по памяти - все вроде в порядке Processor Pool Total: 429251536 Used: 273263496 Free: 155988040 MAC Entries for all vlans: Dynamic Unicast Address Count: 43569 Раздражающую строку Adj SameIf Fail практически закрыл, убрав небольшой левый трафик. Но, динамически arp так и не хочет работать. Статиком - все ОК.

Коллеги, доброго дня. Плз подскажите, кто в курсе. Глухой ночью отвалился доступ к 4900М. Случайно так помогла восстановить доступ привязка arp (ip mgmt интерфейса коммутатора к его мак-адресу) на соотв. сервере доступа. Из консоли 4900 видно, что все динамические арп в состоянии - incomplite. На коробке несколько бгп сессий, они были в down по недоступности соседей. Поднять сессии помогла статическая привязка arp соседей уже на самой 4900, а также на соседях арп записи бгп интерфейсов 4900. При этом, дамп показывает, что сама 4900 рассылает арп запросы, но видимо, не принимает по какой-то причине ответы от хостов. Похоже что то приключилось с arp подсистемой - но, что именно ? Как-то можно вылечить ? Хотя бы как диагностировать болячку ? Из странного вижу только, но не могу связать с проблемой. Adj SameIf Fail 1095012 364 460 377 75 Заранее спасибо и все такое :)

Доброго дня, Коллеги Плз подскажите по такой проблеме: с LNB снят сигнал в DVB карту на сервере, там упакован в IP и нужно его передать на заметное расстояние (60 мс). Пол-дня все работает хорошо - в это время полоса 1 сессии ТСП составляет 8-10Мбит/с, пол-дня - полоса одной сессии tcp падает до 5-6 мбит (не знаю почему) и после приема потока идут ошибки RTP/TS. Самой свободной полосы в канале больше гига в любое время. Собственно вопрос: можно ли транслировать поток с ДВБ карты в 2 tcp потока ? если да - то чем. В 2 потока полосы будет хватать в любое время дня. Заранее спасибо спецам.

Сегодня закончил вывод "серых" сетей из под НАТ-а, из 20+ Гиг ю-туба через НАТ осталось порядка 1 гига. Матросу отдельное спасибо за наводку.

Там есть ограничение на 2 сессии SPAN, может быть мало для подачи трафика в СОРМ. На 3064 так.

Матрос, плз подскажите, GGC для серых адресов можно сделать без НАТ-а ? Надо какой-то тикет размещать в портале, чтобы помогли ? Мы пару лет назад запрашивали такую возможность, гуглы сказали что на тот момент невозможно было.

Готовы предоставить демо-доступ к нашей системе ГИС/инвентаризации. Сделано много необходимого для кабельного оператора - ибо мы сами такие. Более 3 тыс. км опты мелкими участками в нескольких городах. Заранее ничего не расхваливаем. Будет желание потестировать - пишите в личку.

китайские модули с правильной прошивкой работают и на 6 версии. А с корявой вряд ли бы запустились и на 7. Остальное видать не критично настолько.

А есть ли разница между 7 и 6 ветками ОС, чтобы ради этого в обязательном порядке переводить на 7 ?

3064 есть Х, а есть Е. Лучше брать Х - написано что потребление снижено на 30 проц. Может и еще что то, но сходу не замечено. E версия весьма капризно ведет себя с некоторыми QSFP. Если не понравился модуль, само гнездо падает и уже не поднимается, даже если кормишь нормальный модуль. В этом случае помогает релоад. Поэтому весь подбор желательно делать еще на стенде, а в работу только гарантированно совместимое. Х версия выглядит так - N3K-C3064PQ-10GX E - N3K-C3064PQ-10GE service unsupported tranciver - с этим проблем нет. по набору лицух - надо такое: N3K-BAS1K9 N3K-LAN1K9

Нет, все что можно - отсмотрено. Видать какая-то аппаратная особенность. Fast-leave вообще здесь не при делах, это только на клиентских портах и то осмотрительно.