Tftpsher

Всем добрый день. Спасибо за советы. Решилось переключением канала в другой слот и отключением flow-control (хотя в новом порту и с flow-control ошибок не заметили)

v_r Скажите, пожалуйста, а как отключение flowcontrol может, в теории, повлиять на счетчик Input CRC на Huawei?

Всем спасибо за ответы. На самом деле я был не совсем внимательным и упустил очень важную деталь. При появлении трафика в сторону Huawei 8 Gbit/s и более, за один и тот же отрезок времени, на интерфейсе Huawei счетчик Input CRC увеличился на 3.6k ошибок и на интерфейсе ASR счетчик Total Output Drops увеличился на те же 3.6k ошибок. То есть теперь нужно понять что происходит на ASR в этот момент.

На стороне Huawei в момент роста трафика можно увидеть следующую картину: Input: Unicast: 56339451111 packets, Multicast: 2435 packets Broadcast: 2 packets, JumboOctets: 0 packets CRC: 12525 packets, Symbol: 0 packets Overrun: 0 packets, InRangeLength: 0 packets LongPacket: 0 packets, Jabber: 0 packets, Alignment: 0 packets Fragment: 521 packets, Undersized Frame: 0 packets RxPause: 0 packets

Добрый день, коллеги. Столкнулись с очень странной проблемой. Возможно, кто-то уже имел дело с этим и сможет помочь. Есть оптический 10G канал между оборудованием Cisco ASR9001 и Huawei NE40E-X16 На обеих сторонах канала порты в нормальном рабочем состоянии, счетчики ошибок на нуле, параметры вроде duplex, mtu и прочего согласованы. Обычная загрузка канала - 2.5 - 5 Gbit/s в сторону Huawei и 400-600 Mbit/s в сторону Cisco. Суть в том, что при увеличении трафика в сторону Huawei до 8 и более Gbit/s, на стороне Huawei начинает достаточно быстро расти счетчик Input CRC ошибок (примерно до 3.5 тысяч в момент времени). При этом на стороне Cisco все счетчики как и прежде на нуле. Пробовали менять оптические патч корды, модуль на стороне Cisco, протирали контакты. Ничего не помогло. Есть у кого-нибудь идеи на этот счет? Буду признателен.

На MX 240 сколько можно по максимуму 10G интерфейсов освоить?

Нужны 10G порты. Вход ~40-60Gb/s и соотв. выход ~40-60Gb/s. Минимум 3 BGP сессии FV. NAT не планируется. ACL по минимуму.

Всем привет, Посоветуйте, пожалуйста, L3 девайс на следующую задачу: Транзит 40-60Gb/s трафика без каких-либо существенных действий над ним. Условно принял 4-6 десяток и отдал в 2 и более устройства аплинка. Сейчас смотрю на asr 9000, но возможно есть более привлекательные варианты с точки зрения цены.

Спасибо за совет. Надо будет глянуть.

Возможно, я не совсем понятно высказался. Вот пример GRE пакета. В Netflow нужно видеть Original IP Header.

Всем доброго дня. Подскажите, пожалуйста, есть ли возможность собирать статистику о соединениях пользователей, работающих через туннельные протоколы? Если запустить на таких интерфейсах NetFlow, то в записях отображаются SRC-DST IP туннельного подключения, а не реальные SRC-IP пользователя и DST-назначения.. Каким инструментом, например в Cisco роутерах, можно "выдергивать" информацию именно по payload IP адресам?

to Bike: Думаю, что если нужно блокировать доступ по http, то для того же материала нужно ограничивать и https протокол. to alibek: Большое спасибо за разъяснения! Но как быть с тем фактом, что Ревизор считает ресурс не заблокированным, получая от DNS сервера IP адрес не из списка РКН и соотв. трафик к которому не отправляется на сервер блокировки. Получается, что блокировка по IP не может закрыть все вопросы по ограничению доступа?

Коллеги, а кто сталкивался вот с такой ситуацией: Осуществляем блокировку по IP. Анонсируем по BGP адреса из выгрузки на EDGE роутеры и заворачиваем весь трафик к этим адресам на блокирующий сервер. Для http отдаем страницу заглушки, а для https просто рвем tcp соединение. При такой схеме агент Ревизор показывает достаточно большой процент нарушений. Из разговора с РЧЦ узнали, что агент осуществляет проверку по URL и соотв. частенько получает от DNS серверов IP адрес, который не содержится в выгрузке РКН. Кроме того, в отчете большое кол-во записей по сервису YouTube, но данный сервис сейчас работает только по https. Значит ли это, что нужно блокировать YouTube целиком?

Попробовал собрать openssl как в статье https://www.evernote.com/shard/s185/sh/ceb0b021-47e7-4c61-ab43-bc6db27fe919/c535b6e5047ec69d304519fe81c2c9ac?noteKey=c535b6e5047ec69d304519fe81c2c9ac&noteGuid=ceb0b021-47e7-4c61-ab43-bc6db27fe919 - результат аналогичный UPD: При попытке проверить подпись самому Verification failure 139708241659552:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest failure:pk7_doit.c:1170: 139708241659552:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:pk7_smime.c:410: UPD: НАШЕЛ РЕШЕНИЕ Подписывать нужно с параметром -binary, пример: openssl smime -sign -binary -in zapros.xml -out zapros.xml.sign -signer p12.pem -outform DER

Почитайте тут, вариант полностью рабочий. Читал. Ничего нового для меня там нет. Экспорт ключа и его преобразование из pfx в pem проходит без ошибок. Пробовал на OpenSSL 1.0.1u под Windows и OpenSSL 1.0.1f под Linux. Во время подписи запроса ошибок не появляется. Издатель ключа: TENSORCA3, Удостоверяющий центр, ООО Компания Тензор