wtyd

Тогда весь yuotube был бы заблокирован, а это не вариант, клиенты "съедят" Пока ни разу не съели. Так же ещё ни разу (когда проверял) ссылки на йутуп из запретинфо не вела на указанный там ойпи, всегда в какое-то то ли гугл-кеш, то ли какой-то другой йутуп.

А HTTPS это оборудование будет блокировать? Оффтоп: Рекомендации РКН вроде бы были такие: если не можете блокировать https, то блокируйте весь ойпи и порт 443, чтои было незамедлительно сделано :-).

Ну это не большая проблема, в качестве исключения можно ограничивать полностью домен а не URL. Либо делать проверку на длину, и если больше, то обрезать до домена. Интересно, а можно ли обрезать по длине и в конец звёздочку впендюрить ? Будет так работать ?

Почти год назад тоже озаботился данным вопросом. Потом забил ... так и не нашёл способа нормализовать url для SCE2000. Кстати, там есть ограничение на длину строки url, а при переводе в idn и обработке "русских" ссылок, получается больше этого ограничения. Получается, что на 100% выполнить требования РКН на SCE нельзя. Да и вообще, говорят, скоро заставят всех отечественное оборудование для этих целей покупать. Но я всёравно присоединяюсь к вопросу.

Либо ещё два порта на имеющемся коммутаторе, с петлёй между ними. Работает так же. Это ограниченное решение -- нельзя использовать в свиче под свои нужды те вланы, которые петлёй растегируются. Можно конечно использовать петли, кто ж спорит ? :-), но с указанными ограничениями.

это фича уровня selective-qinq selective-qinq хочет тегированный фрейм чтобы засунуть его в указанный SP-VLAN -- ему нужно откуда-то узнавать номер влана. На e-core сегодня попробовал, не получается двойной таг снимать на одном порту, пробовал разные native vlan на порту указывать -- на зависит от номера native. На форуме вимкома нашёл тему -- подтверждают (давно ещё это было :-)). Для технологии qinq нужет ещё один типа клиентский коммутатор, который будет второй тег снимать и фильтровать "остальные" клиентские вланы. add_inner_tag у длинка скорее всего только снимает указанный второй таг, но не фильтрует остальные клиентские вланы. Подходящего длинка под рукой нет, проверить это пока не могу.

Это косяк 3028 (и 1228/ME revision A, что то же самое) - он при включении qinq может ставить какой угодно tpid, но только не 8100.Прошивкой не исправляется, это недоработка чипа. На всех последующих моделях без проблем ставится 8100. А это называется add_inner_tag. Есть в относительно современных моделях.Но даже если его нет, это можно сделать петлёй, потратив два порта. Про 3028 так и подумал, что никак и ни при каких условиях это не исправить, спасибо, что подтвердили догадку. При add_inner_tag другие клиентские вланы по идее должны вылетать в сторону клиента в тегированном виде (например, тут походий вопрос http://forum.dlink.ru/viewtopic.php?f=2&t=164812), этого можно избежать ? Т.е. надо чтобы клиенту отдавался только один его влан какой клиент скажет. Было бы замечательно :-). Ещё интересует название аналогичной add_inner_tag фичи у других вендоров, у cisco и e-core, например.

ES3510ma более старая модель, там всё уже вылизано и проверено :-). Софт у нас в ECS3510-28T последний с фтп вимкома, конфиг почти дефолтный -- лаба же, только тестируемая конфигурация. Т.е. один транспортный влан и всё :-), это потом уже ради интереса стали qinq включать и смотреть. Интересно, можно ли как-то от длинков получить спец прошивку для DES-3028, где тип фрейма 0x8100 ? Или это в микросхеме так сделано, что 0х8100 нельзя выставить ? Другие номера, если правильно помню, можно поставить, но что из этого выйдет далее ... не можем же мы все виды свичей проверять :-).

Спасибо за ответ. Тоже в сторону 8100 стали уже думать. Прикрутили к стенду не-длинк -- работать перестало :-). Точнее так: поставили как бы просто транзитный свич e-core ECS3510-28T, прокинули через него транспортный влан и ... всё заработало, но через влан номер 1 :-). Почему-то кора при виде 88a8 скидывает фрейм в первый влан и потом обратно его "обувает" правильно. Смотрел по таблице мак-аддресов, может просто отображается неправильно, но всёравно это нам не подходит. Включать qinq на корке в данном случае не следует, т.к. свич-то транзитный, но ради интереса включали в разных комбинациях -- не работает :-). фреймы теряются в е-коре. В вимком письмо написал с описанием проблемы. Поэтому решили, что *надо* юзать 8100, хоть это и потребует замены с десяток мутаторов. Кстати, на самой корке ещё надо попробовать ... но скорее всего заработает нормально с 0x8100.

Раньше с ку-ин-ку не сталкивались. Собрали небольшой стенд. Пока понимание такое: придётся по всей сети раскинуть один влан, который в терминологии длинка называется SP-VLAN. В него на краях сети на уровне доступа будут инкапсулироваться все клиентские вланы. Во всех свичах доспута, куда подключен клиент, надо сделать все порты nni, а порты этого клиента как uni, так же надо подать в порты этого клиента его SP-VLAN в нетегированном виде. На этих портах клиент сможет заюзать все 4096 вланов, фильтрации со стороны провайдера никакой. 1. Это всё или ещё что-то надо сделать ? 2. Обязательно ли, чтобы тип фрейма был 0х88a8 ? Например, DES-3028 не позволяет задать 0x8100 для q-in-q. Пролезут ли фреймы типа 0х88a8 через промежуточные коммутаторы ? Это мы пока не проверяли. 3. Клиент почему-то хочет, чтобы в одном месте у него были вланы с номерами 3,5,7,9 , а в другом 4,6,8 , а в третьем ещё какой-то набор. Вланы надо отдать в теге там, где их несколько, где клиент хочет один влан -- надо отдать без тега. Это вообще можно сделать на одном провайдерском свиче доступа ? Я понял, что свич умеет снимать один тег и всё, дальше вся пачка вланов вылетает клиенту и дальше уже проблемы/оборудование клиента должно разгребать. Но клиент скорее всего захочет, чтобы у него вообще проблем не было и ничего делать с его стороны было бы не нужно :-). 4. Теоретический вопрос. Вот мы десятилетиями занимались сегментированием сети на вланы для наведения порядка и для уменьшения броадкастовых доменов, а тут один влан по всей сети надо раскидать -- один большой броадкаст домен. Понятно, что разные клиентские вланы друг друга не увидят, но броадкаста-то меньше не станет -- весь броадкаст со всех клиентских вланов будет носиться по всей сети в провайдерском влане. С этим можно что-то сделать ? Пока мы собрались просто забить на этот факт. С этим вообще бывают проблемы или все так и живут с броадкастом ?

Хорошо, а lldp чем обрабатывать ? Разные вендоры по-разному show lldp выводят.

В Т.З. lldp нельзя юзать не потому, что он плохой, а потому что он примерно только на 60% свичей есть, ещё он отключен, ещё его нет на цысках. Так то конечно было бы клёво на lldp всё собрать.

Алгоритм очень простой. 1. Получить с каждого коммутатора таблицу MAC-адресов. 2. Проанализировать таблицы и составить топологию соединений (на основе совпадения набора MAC-адресов). Напрасно. Строить топологию по MAC-адресам очень ресурсоемко. К тому же следует учитывать, что динамические MAC-адреса живут ограниченное время и к моменту опроса некоторых MAC-адресов может не оказаться в таблице. Много чего есть (например LanTopolog). Но советую разобраться с NOC. Вот пункт 2 как раз и интересует :-). Что ресурсоёмко это понятно, но это надо делать 1 раз в месяц или вообще 1 раз, пока не решили. NOC у нас есть, мы его даже использовали. Это наша самая большая и самая ресурсоёмкая виртуалка, ей всё время чего-то мало, она всё время растёт в размере. Возникает желание избавиться от такой виртуалки -- рано или поздно ресурсы закончатся. Ставил софт не я, деталей не знаю, спорить на эту тему бесполезно. Вот если бы она не росла и не жрала ресурсы, то моё мнение было бы другим. Жрёт проц с ОЗУ и диском, а из реального профита только более менее актуальные конфиги свичей. За lantopolog спасибо, посмотрим, хоть он и не для линукса.

ну тут сложно что-то советовать А что, кроме NOC ничего нет ? Я совета про другое спрашивал вообще-то.

Есть желание создать карту/таблицу коммутаций сети. Т.е. таблица есть, но в ней есть ошибки, т.к. её делали люди, которым очень свойственно ошибаться. В таблице есть связи, какой коммутатор с каким соединён какими портами. У руководства возникла идея: написать скрипт, который бы по таблицам мас-адресов составил бы такую же таблицу коммутаций. Потом надо будет сравнить таблицы и обратить внимание на несовпадения. Посоветуйте опенсорс софт для linux или хотя бы алгоритм для написания скрипта. NOC не предлагать (!), он наверное хороший, но разобраться в нём это выше моих сил :-), мы его не понимаем и поэтому использовать не будем. Из входных данных есть имена свичей, их ip-адреса, маки свичей, есть доступы по telnet и по snmp. Свичи в основном длинки, есть несколько цысок и совсем мало e-core с q-tech. cdp и lldp использовать нельзя. P.S. Я обычно пользуюсь имеющейся таблицей, но всегда отношусь к ней с сомнением и проверяю. Попробовал руками по таблицам mac-адресов что-то построить и понял, что запрограмировать такое в скрипте у меня с ходу не получится. Т.е. без знания примерной топологии сети у меня вообще не получается составить таблицу коммутаций правильно :-).

Например, в конкретном экземпляре тп-линка, который сейчас на лабе и через который не работает 5 сипов как надо одновременно, эта галка включена по-умолчанию -- не помогает :-). Не работает так: на fusionpbx настроена ринг-группа, сперва должен звонить один телефон, потом ещё два, потом все пять. Без роутера работает как описано, с роутером звонит один телефон, потом другой (но не одновременно), остальные молчат. Но после окончания звонка на всех трубках появляются пропущенные вызовы :-).

Занимаюсь ip-телефонией недавно, найти ответ на свой вопрос пока не смог. Есть такая проблема: периодически бывает нужно подключить несколько сип-телефонов через различные SOHO роутеры. Заметили, что через некоторые модели/прошивки несколько сип-регистраций работают нормально, а через другие модели/прошивки работает только одна сип-регистрация. Менять роутеры и париться с прошивками не вариант, но можно было бы указывать разные порты на разных сип-телефонах. Пока не проверяли, будет ли так работать -- в этой связи вопрос: как на freeswitch сделать так, чтобы он слушал не только 5060 порт, но и 5062,5063,5064,...5076 ? Вообще-то используется fusionpbx, там порт задаётся в переменной профиля, как задать несколько портов я не знаю. P.S. Может быть есть другое решение проблемы ?

Для графиков по SNMP не проще будет собирать стандартную статистику в какой-нибудь Cacti и подобных? Или "хочется странного"? В какти конечно есть скрипты для автоматического создания хоста, но это не то :-). По идее с sflow телодвижений должно быть в разы меньше. Зачем-то же придумали sflow, надо разобраться зачем :-). Затем же, зачем и NetFlow - собирать статистику по соединениям и трафику. Только с SFlow она будет с большой погрешностью, т.к. захватываются не все пакеты. Мы сейчас пишем свой сборщик с хранением в БД для анализа профиля трафика по портам и протоколам + разбор DDoS атак на полосе 20Гбит. 10 дней всех flow в БД занимает 60Гб. 13:25:41 total2 Speed 10606Mb/s Samples/s 669 Flows: 17240 Statistics by destination ip address and bytes: ===== IP: 92.157.41.209 Speed: 103 Mbit/s Flows:4 ===== IP: 92.157.87.151 Speed: 90 Mbit/s Flows:32 ===== IP: 82.224.161.204 Speed: 89 Mbit/s Flows:90 ===== IP: 92.31.148.33 Speed: 87 Mbit/s Flows:19 ===== IP: 82.224.206.156 Speed: 82 Mbit/s Flows:22 Statistics by source ip address and bytes: ===== IP: 95.142.201.66 Speed: 179 Mbit/s Flows:172 ===== IP: 95.142.201.67 Speed: 162 Mbit/s Flows:175 ===== IP: 31.13.72.53 Speed: 149 Mbit/s Flows:255 Еще в отличии от NetFlow нельзя отследить начало/конец TCP-сессии. Это всё понятно, но я вдруг захотел собирать именно COUNTERSSAMPLE :-). Т.е. просто собираем счётчики свичей, которые их шлют, складируем в базу. Когда нам надо что-то посмотреть по конкретному свичу, тогда и лезем в эту базу, строим графики, ищем CRC ошибки и другие действия. Вот такой софтины я не нашёл. Не подскажете софт который примерно так умеет ?

Для графиков по SNMP не проще будет собирать стандартную статистику в какой-нибудь Cacti и подобных? Или "хочется странного"? В какти конечно есть скрипты для автоматического создания хоста, но это не то :-). По идее с sflow телодвижений должно быть в разы меньше. Зачем-то же придумали sflow, надо разобраться зачем :-).

Тут ещё вопрос возник: чем собирать COUNTERSSAMPLE ? Замысел такой: берём кучу свичей, конфигурим их бесконечно долго раз в 5-30 минут слать COUNTERSSAMPLE'ы со всех портов вон в тот ойпи, а там складируем эти сэмплы и потом из этих данных можно сделать график любого порта. sflowtool в этом плане не совсем адекватен -- не разделяет данные, может только в текстовом виде показывать, демоном не запускается. К нему идут какие-то простые скрипты, есть какие-то ключи запуска, но для продакшена это не годится. sfcapd (из nfdump) складирует только пакеты, т.е. ловит сэмплы пакетов и делаетиз них такие же файлы, как деалет nfdump. Информации по каунтерам портов свиче там нет.

Спасибо за цитату из мануала. Я вчера методом научного тыка выяснил, что если не делать "create sflow counter_poller ...", то шлются сами пакеты. enable sflow create sflow analyzer_server 1 owner TEST1 config sflow analyzer_server 1 timeout 120 collectoraddress 192.168.253.237 create sflow flow_sampler ports 9 analyzer_server_id 1 rate 1 tx_rate 1 так работает. А можно этот множитель, который 256, сконфигурить поменьше ? Напрмиер, 1 или хотя бы 10 :-).

Иногда хотим смотреть, что шлёт абонент в порт. Для этих целей на свичах доступа включаем sflow на определённое время, смотрим, потом оно само отключается. На свичах edge-core 3528M такое даже работало -- прилетали сами семплы трафика (прям пакеты arp и другие), глядя на которые можно было сказать, что у абонента не так с настройками. Взял первый попавшийся длин (3200-10), пытаюсь с него получить то же самое -- фреймы с порта абонента. Делаю примерно так: enable sflow create sflow analyzer_server 1 owner TEST1 config sflow analyzer_server 1 timeout 120 collectoraddress 192.168.253.237 create sflow counter_poller ports 1-10 analyzer_server_id 1 interval 30 create sflow flow_sampler ports 1-10 analyzer_server_id 1 rate 1000 maxheadersize 128 Но при этом прилетают не сами фреймы, а статистика счётчиков коммутатора: $ sflowtool -p 6343 -g 13/Sep/2016:16:50:22 - 0 0 0:0 0:0 0:0 startDatagram ================================= 13/Sep/2016:16:50:22 - 0 0 0:0 0:0 0:0 datagramSourceIP 192.168.251.235 13/Sep/2016:16:50:22 - 0 0 0:0 0:0 0:0 datagramSize 1188 13/Sep/2016:16:50:22 - 0 0 0:0 0:0 0:0 unixSecondsUTC 1473760222 13/Sep/2016:16:50:22 - 0 0 0:0 0:0 0:0 datagramVersion 5 13/Sep/2016:16:50:22 192.168.251.235 1 0 0:0 0:0 0:0 agentSubId 1 13/Sep/2016:16:50:22 192.168.251.235 1 4 0:0 0:0 0:0 agent 192.168.251.235 13/Sep/2016:16:50:22 192.168.251.235 1 4 0:0 0:0 0:0 packetSequenceNo 4 13/Sep/2016:16:50:22 192.168.251.235 1 4 0:0 0:0 0:0 sysUpTime 363283770 13/Sep/2016:16:50:22 192.168.251.235 1 4 0:0 0:0 0:0 samplesInPacket 10 13/Sep/2016:16:50:22 192.168.251.235 1 4 0:0 0:2 0:0 startSample ---------------------- 13/Sep/2016:16:50:22 192.168.251.235 1 4 0:0 0:2 0:0 sampleType_tag 0:2 13/Sep/2016:16:50:22 192.168.251.235 1 4 0:0 0:2 0:0 sampleType COUNTERSSAMPLE 13/Sep/2016:16:50:22 192.168.251.235 1 4 0:0 0:2 0:0 sampleSequenceNo 4 13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:0 sourceId 0:1 13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 counterBlock_tag 0:1 13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 ifIndex 1 13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 networkType 6 13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 ifSpeed 0 13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 ifDirection 3 13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 ifStatus 0 13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 ifInOctets 408975010354 13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 ifInUcastPkts 55817378 13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 ifInMulticastPkts 308303574 13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 ifInBroadcastPkts 81077 13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 ifInDiscards 0 ... Она нафик не нужна, хочу трафик смотреть вот так: "$ sflowtool -p 6343 -t | tcpdump -r - -ne", но так ничего не показывает. Пару лет назад на е-корах делал примерно то же самое и видел трафик. Может быть можно как-то иначе настроить свич, чтобы видеть пакетики в tcpdump ? "sampleType COUNTERSSAMPLE" изменить ? Как ? Ещё я не нашёл в документации описания этих команд, взял с какой-то презентации. Непонятно, как конфигурить выбрку, "rate 1000" это один из тысячи пакетов или что-то другое означает ? На корках весь трафик видеть не получалось, но каждый второй пакет получалось. Ну может конечно это не каждый второй пакет был, но какие-то пакеты показывало :-) Обычно при проблемах у абонента на порту трафика практически нет и увиденного вполне хватало для диагностики.

http://www.ntop.org/products/traffic-recording-replay/nbox-recorder/ -- а это разве не то ? Пульт -- вебморда, nBox. Давно было подозрение, что Люка Дэри работает на ФСБ ;-). Сколько часов трафик надо хранить ? Т.е. про ЦПУ, память, сетевую карту вроде всё понятно, а вот с дисковой подсистемой -- только скорость линейной записи можно оценить, а вот объём не знаю. Ну и куратора на nBox уговорить же не получится ?

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

бред же. то, что неизвестный трафик начинает валить во все порты (включая cpu порт свичиипа) из-за чего контрол плейн начинает тупить. открою секрет - если контрол плейн умирает, свич как ни в чем не бывало будет продолжать свичевать трафик. не верите - можете попробовать покурить даташиты и попробовать подать ресет сугубо на проц. ну или взять tl-sl2210web, поставиь его в какой-то сегмент и флудонуть парой тысяч маков от которых его контрол плейн скукожится. а датаплейн свичевать будет так же как и раньше :) Ладно, бред, но чем это поможет в данном случае ? Всёравно ж трафик в ЦПУ попадает, ну заучиваются маки аппаратно и что ? ЦПУ капец от unknown unicast storm.