Записи с меткой «Networks»

Заметка будет про китайское железо с бэкдорами и сетевую магию для нейтрализации подобной муйни.
(далее…)

Реклама

в сети штормило …

Posted: 2019-02-13 in IT, Networks
Метки:,

Иногда некоторые сервисы, использующие мультикаст, могут порождать массовую генерацию мультикаст-траффика.

мультикастовый шторм 2gbps

Вот эти два пика — случившийся в одном из сегментов сети мультикаст-шторм мощностью примерно в 1,5 — 2 гбит/сек, предположительно порожденный сглючившими процессами corosync. От такой херни весь сегмент сети начинает очень сурово колбасить, потери пакетов достигают 80%, любое сетевое взаимодействие становится крайне медленным и нестабильным, всё становится очень нехорошо.
Чтобы такой херни не происходило, необходимо включать такую вещь, как Storm Control.

На джунипере оно для мультикаста по умолчанию _выключено_.
Конфигурим:

Amin@EX3300> show configuration ethernet-switching-options storm-control
interface xe-0/1/0.0 {
bandwidth 65536;
multicast;
}
interface all {
bandwidth 16384;
multicast;
}

Можно задать максимально допустимое количество принимаемого в порт широковещательного траффика как в процентах от толщины канала (level), так и в абсолютных значениях (bandwidth), в килобитах/сек. Задаваемые значения зависят от используемых приложений, в штатном режиме в логах не должно быть ругани на срабатывание storm control.

Пара подводных камней:
1). Есть ELS и не-ELS версии. Для els версий настройка немного иная (forwarding-options storm-control-profiles):
https://www.juniper.net/documentation/en_US/junos/topics/example/rate-limiting-storm-control-configuring-els.html

2). Для broadcast и unknown-unicast траффика ограничения storm control могут применяться по умолчанию, но им может быть разрешено съедать до 80% полосы.

Такая простая настройка дополнительно убережёт вашу сеть от опасно сглючивших девайсов.

i2p

Posted: 2018-12-11 in IT
Метки:,

Вошел в довольно стабильное состояние и выпускается нормальными пакетами i2pd:

https://github.com/PurpleI2P/i2pd/releases

Он существенно легковеснее классической джава-софтины.

Веб-морда тоже существенно проще и легче. В отдельной ВМ попробовать рекомендую я.

1Gbps WAN UP !!

Posted: 2018-12-08 in IT, Networks
Метки:

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

(далее…)

Надо быстро слить крупный дамп неприватных данных.
В текущем каталоге запускаем такое:

python -m SimpleHTTPServer

И на 8000-м порту видим веб-сервер с индексом каталога. По завершении стопаем этот «фемтосервер :D» по Ctrl-C.
Это изумительно и прекрасно. Само собой, ценные базы и чувствительные данные так перекидывать не надо, для ценных данных есть SSH.

В порыве борьбы с телегой ркн слетел с катушек и начал применять массовые баны подсетей:

cat dump.xml | grep ipSubnet
68.171.224.0/19
74.82.64.0/19
103.246.200.0/22
178.239.88.0/21
203.104.152.0/22
203.104.144.0/21
203.104.128.0/20
91.108.4.0/22
91.108.8.0/22
91.108.12.0/22
91.108.16.0/22
91.108.56.0/22
149.154.160.0/22
149.154.164.0/22
149.154.168.0/22
149.154.172.0/22
52.56.0.0/16
18.130.0.0/16
13.125.0.0/16
52.57.0.0/16
35.180.0.0/16
18.144.0.0/16
52.32.0.0/16
18.218.0.0/16
52.58.0.0/15
18.196.0.0/15
18.194.0.0/15
18.184.0.0/15
54.228.0.0/15
35.178.0.0/15
18.236.0.0/15
54.212.0.0/15
13.230.0.0/15
35.176.0.0/15
35.156.0.0/14
13.56.0.0/14
18.204.0.0/14
35.160.0.0/13
34.248.0.0/13
34.240.0.0/13
54.64.0.0/13
54.160.0.0/12
54.144.0.0/12
52.64.0.0/12
52.192.0.0/11
34.192.0.0/10
109.239.140.0/24
23.251.128.0/19
139.59.0.0/16
35.184.0.0/13
35.192.0.0/12
35.224.0.0/12
35.208.0.0/12
174.138.0.0/17
188.166.0.0/17
46.101.128.0/17
167.99.0.0/16
206.189.0.0/16
159.89.0.0/16
165.227.0.0/16
159.203.0.0/16
128.199.0.0/16
159.65.0.0/16
51.136.0.0/15
195.154.0.0/17
51.15.0.0/16
185.166.212.0/23
178.63.0.0/16
91.121.0.0/16
64.137.0.0/17
47.91.64.0/19
94.177.224.0/21
159.122.128.0/18
174.104.0.0/15
98.158.176.0/20
176.67.169.0/24
185.229.227.0/24
45.76.82.0/23

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

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

Всем привет !
Я очень давно хотел поразбираться с двойным тегированием на домашнем роутере Juniper MX-серий, и вот этот момент настал. В отличие от EX, где настройки QinQ относительно немногочисленны, МХ-серия обладает просто огромным количеством настроек свитчинга, а поддержка виртуализованных инстансов и целой пачки технологий позволяет городить очень сложные конфигурации.
Задача этой заметки — разобрать средствами самого МХ-80 дважды тегированный траффик, пришедший в общем аплинке вместе с другими одиночно тегированными вланами и нетегированным траффиком, и после снятия верхнего тега сбриджить эти вланы с уже существующими вланами на МХ. Не забыть про native само собой. Если интересно — просим под кат.
(далее…)

В камерах и DVR (IP-видеорегистраторы) hikvision похоже нашли новую багу. Пару лет назад я уже писал очень матерно-ругательную статью про эти железки, но сейчас проблема приобрела серьёзный размах — наблюдались массовые взломы таких систем, сброс настроек (даже при сильных паролях), DDoS-атаки с них (DNS-/NTP-усиление) и использование хакнутого оборудования для атак на другие сети / подбор паролей к сервисам (telnet, ssh, vnc, rdp — точно) и прочему непотребству.

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

Если вам нужно повесить камеру на внешний адрес, то НЕ НАДО прифигачивать её сразу внешний адрес напрямую — ни в IPv4, ни в IPv6. Если есть роутер — затащите её за этот роутер и сделайте Port-forward для RTSP вида :

TCP+UDP: xy554 --> 192.168.x.y:554

Для получения видеопотока этого более чем достаточно. Если камера оказалась единственной на объекте (бывает такое) — применить IP-whitelist. Правда если этот вайтлист на камере обслуживает только веб-доступ, но не применяется для доступа по телнет/ссш (да, вам не приглючилось, телнет там живее всех живых и доступен на куче девайсов через интернеты) или иному кривому порту — то может не помочь.

Так что в случае хиквижена — именно big, именно факинг и именно фейл, и именно с секурити.

Всем привет. Технология DPI относится к инструментам двойного назначения, и может применяться как во благо (на домашнем роутере очень круто можно задетектить вредоносную активность или походы виндовс-ВМ по шпионским телеметрическим доменам), так и во зло (йопаная говноцензура).
Технология эта весьма сложна и затратна, а попытка реализовать её аналоги допотопно-пещерными методами легко приводит к былинным отказам.

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

Если вам интересно — вэлкам, постараюсь рассказать о том, как появились такие системы, какие бывают и что вообще там интересного.
(далее…)

Если ваш домашний роутер внезапно начал качать деццкое порно, призывать к беспорядкам или просто стал слать левый траффик, а в это время спецназ вам уже выпиливает дверь — не волнуйтесь, это лично Путен, под покровом ночи и прикрытием фсб, вас немного хакнул.
Хотя не, на этот раз не Путен.

На этот раз снова госдеп, а если точнее — коварные агенты ЦРУ.
викиликс как раньше аццки жгла, так и продолжает жечь сейчас.
Встречаем: http://nag.ru/news/newsline/31897/tsru-bolee-desyati-let-vzlamyivaet-domashnie-routeryi.html

В новой публикации рассказано об инструментарии под названием CherryBlossom, созданном специально для взлома домашних роутеров.

Благодаря CherryBlossom можно перехватывать управление над различными моделями роутеров. Заражение вредоносом может быть осуществлено как удаленно, так и сотрудником ЦРУ, работающим «в поле».

Список задач, которые может выполнять устройство, разнообразен. Заражённый роутер может сканировать локальную сеть жертвы, следить и контролировать трафик пользователя, перенаправлять его на необходимые ЦРУ сервисы. CherryBlossom может создать VPN-тоннель к сети жертвы, выполнять ещё ряд действий с URL, email и MAC-адресами.

В списке зараженных CherryBlossom устройств значатся более 200 моделей роутеров самых разных производителей:

Наивные хомячки домашние пользователи могут продолжать верить, что «они никому не нужны», им «нечего скрывать», а также продолжать не понимать ценность открытых/альтернативных прошивок.

То, о чём IT-специалисты предупреждали деятелей роскомпозора несколько лет назад, таки случилось. Полная ебанутость системы блокировок «запрещОнных сайтоФФ», полный ваккум в законодательстве по технической части и исключительная кривизна системы «ревизор» привели к тому, что опасающиеся неадекватно высоких штрафов (100к рублей за хуйню типа пары незаблоченных урлов) провайдеры по прямому указанию действующих властей заложили самую натуральную атомную бомбу под действующую сетевую инфраструктуру.

Немного поясню техническую часть. Реестр сайтов — это такая огроменная таблица примерно на 80 000 строчек, содержащаяся в полном беспределе и хаосе. Там есть и http-урлы, и https-урлы, есть домены, есть просто IP-адреса, есть списки адресов и прочее. Иногда ркн делает ошибки, добавляя неожиданные данные, типа конечной точки корневой зоны для одной записи из 80000, вставляя в поле «домен» значение IP-адреса и прочую вакханалию. Парсеры таким давятся, и попутно периодически что-либо ломают в провайдерской инфраструктуре, пока админ не найдет и не напишет очередную защитную обертку против такой херни.

При этом записи туда в основном только добавляются. Для выкидывания записи из списка либо владелец сайта должен выиграть судебную тяжбу (биткоиновцы, вы молодцы!), либо сам РКН может удалить относительно свежую запись, если посчитает, что ресурс таки пошёл им на уступки.

Но владельцы очень и очень многих заблоченных сайтов, особенно торгующих наркотой сайтов-однодневок, заблоченные домены просто забрасывали и регали всё новые и новые. За их разделегированием и выкидкой из реестра несуществующих в глобальном ДНС имён никто не следил — за это премий не дают.
В итоге в реестре скопились десятки тысяч записей о несуществующих доменах, для которых провайдеры по-прежнему осуществляют применение фильтрации.

А поскольку промышленный провайдерский DPI — игрушка зело дорогая, да и в законе по технической части весьма негусто (есть только один документ такого плана, и то рекомендательный), очень многие провайдеры делают не только DNS-, но и IP-блокировку, но до появления «ревизора» блокировка средствами днс в основном считалась достаточной (что вообщем-то так и есть — она достаточна для того, чтобы отшить 99% наркоманов от онлайн-покупки наркоты, а против остальных мало что поможет). Потом в реестре появились и IP-адреса — ушлые наркоторговцы просекли, что поднятый прямо на голом IP сайт, без доменного имени, тоже вполне ОК.

А потом появился «ревизор». Проблема этой кривой блядской коробочки (даже не сертифицированной как измерительное средство), что она не просто проверяет доступность сайтов «как есть», но и пытается делать прямые запросы по IP в обход провайдерского резолвинга, причём как по IP-адресам из реестра, так и по текущим IP из DNS. Естественно, с попутной выпиской «предписаний», руганью, штрафами и многомесячными судебными тяжбами.

В итоге провайдеры либо купили системы DPI, либо начали блочить любые полученные адреса, что из реестра (как изначально и было у тех, кто одним ДНС не ограничился), что из динамически обрабатываемого ДНС. Но в отличии от реестра, составляемого цензорами РКН и хоть как-то доступного для управления, в динамический ДНС изменения владелец домена вносит сам по своему желанию.

Bomb has been planted.

Таймер на бомбе тикал долго — аж несколько лет. За это время недовольство деятельностью РКН, давно вышедшей за всякие разумные рамки, достигло пред-критической величины (вообще идея отбирать у народа зрелища при отсутствии хлеба зело не здравая и мaйдaно-опасная). Предположу, что наезд на торрент-трекеры и анонимайзеры стал той последней каплей, после которой противостояние перешло в действительно активную фазу.

Прекрасно зная, что системы DPI стоят не у всех, а IP-блокировки весьма разрушительны, сетевые шутники массово начали заново регать те домены, которые были давно разделегированы регистраторами имён, но всё ещё оставались в блок-листах РКН, и в настройках DNS таких свежекупленных блоченных доменов прописывать IP-адреса враждебных или просто популярных ресурсов, чтобы даже самого ленивого хомячка хоть чуть-чуть, но зацепило.

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

Устроенная кибер-анархическая вакханалия вышла годной, и началось прописывание в заблоченные ДНС уже более важных адресов — служебных адресов самих систем РКН, банковских процессингов, и прочей мякотки.

Жутко обосравшись (и возможно даже получив серьёзный пропиздон от банкиров), ркн и даже один целый мвд начали нести полнейший бред, что сбои процессинга никак с днс-манипуляциями и кривыми блокировками не связаны, инфа типа ложная, а процессинг у сбербанка вообще самоубился без их участия, упав спиной на ножик 18 раз.

Tеrrоrists win.

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

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

Ркн в панике начал рассылать «белые списки» исключений, носящие, опять же, рекомендательный характер (в законе про такую муйню вообще ничего нет, как обычно), в попытках хоть как-то остудить оттраханную Сбербанком сраку (боюсь даже представить, какие претензии может вкатать Сбер за поблоченный карточный процессинг).

После этого читать тупые пафосные статьи про «доктрину информационной безопасности РФ», «цифровой суверинетет», «противодействие глобальным киберугрозам и кибершпионажу» — одновременно и грустно, и смешно.

Какое блять нахуй противостояние американской ИТ-разведке ?! Какие ещё нахуй доктрины безопасности ? РКН против вредоносных прошивок АНБ ? Яровая против закладок ЦРУ ?
Деревянные и некомпетентные в ИТ службы надзора в сфере связи против террористов из игил ?
Вы серьёзно ?!

Не смешите, нахрен, мои тапочки.

Уровень современного гос. управления ИТ в Роиссе — это повальные тупые блокировки, причём больше ради штрафов на ровном месте, чем ради реальной безопасности, и 14-летние восьмиклассники, простыми безобидными действиями ценой в 80 центов кладущие к хуям крупные банковские процессинги в масштабах страны руками самого ркн и самих же провайдеров.

Самое вкусное во всём этом — за такую «отаке» шутнику по закону даже предъявить ничего нельзя. Вообще.

Сайты регать можно ? Можно.
Запрещённого контента на сайте нет ? Нет.
Менять DNS на своём собственном домене можно ? Никаких проблем.

А что подложенная силами самого ркн бомба подорвала критически важную инфраструктуру (замечу, без всяких хакеров, хватило шутников из 8 класса) — вина исключительно самого ркн, и никого более. Профессионалы предупреждали.

Какая адская свистопляска может начаться в компьютерных системах РФ (до сих пор массово сидящих на старой винде) в случае реальной атаки силами АНБ или ЦРУ — можно пофантазировать самостоятельно. Думаю, что ванна-край и прочие безобидные конфикеры поблекнут весьма сильно.

P.S. И не надо пиздеть мне про Эльбрус — гос-органы файлы ODT до сих пор не научились принимать, просят ворд, причем 2003-й. Два компьютера на общем фоне погоды не делают.

Если у вас так или иначе реализован мониторинг, то в какой-то момент возникнет разделение событий и сведений мониторинга по степени важности. И почти наверняка вам потребуется отобразить данные из одной системы в другой системе. Суть данной статьи — как вытащить интересующие графики нагрузки, созданные системой Grafana, во внешнюю самописную систему максимально простым способом, например, для отображения на публичном сайте или в любой другой системе.
(далее…)

В прошлой статье про PXE я описал массу способов сетевой загрузки самых разнообразных осей с USB-флешки домашнего роутера.
С тех пор вышел новый кноппикс — 7.7.1, и помимо обновления (с выхода версии 7.6 прошёл год), мне хотелось иметь возможность грузить полноценное рабочее место с x64-ядром, поскольку объёмы памяти и аппетиты приложений только растут.
Что из этого вышло — читаем ниже.
(далее…)

Столкнулся тут с такой странной фигней — не поднялись линки по оптике. Оказалось, что из целого мешка патчкордов три оказались битые. Хотя на этикетке и были отмечены величины затухания, похоже, их то ли как-то странно померяли, то ли что-то треснуло/лопнуло/отслоилось в процессе транспортировки.

На один конец патчкорда вешаем специальную светилку:
http://laserbeam.ru/power/fiber/ft650

А второй конец направляем на любую ровную поверхность.

В случае исправного патчкорда на выходном разъёме будет слабо светится только точка выходного среза, вся световая мощность вылетит наружу:

cable_ok

Если направить его на стенку, что даже в полуметре от коннектора на стене будет наблюдаться яркое красное пятно.

Если у разъёма есть даже небольшой дефект, то свет из волокна конечно выйдет, пятно будет на освещенной поверхности, но ощутимая часть света рассеится в белой керамической вставке коннектора:

cable_half-ok-1
Линк через такой провод может быть нестабилен или вообще не подняться, если оптического бюджета не хватит на длинную линию.

А в совсем запущенном случае свет из среза вообще не может выйти, целиком рассеиваясь в белой вставке коннектора:
cable_bad
В этом случае светового пятна на выходе нет даже в двух сантиметра от коннектора, линка через такую фигню не получить.

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

Однако есть железки, у которых управляющих модулей внутри может быть больше одного. Например, в Juniper MX960

Juniper MX-960

может быть несколько (чаще всего два) так называемых routing-engine (RE, вертикальные модули в середине железки), представляющих из себя полностью независимые управляющие компьютеры со своими процами / памятью / дисками. В каждый момент времени работает только один такой комп, второй находится в горячем резерве и готов взять на себя все функции при отказе первого. Особенность в том, что заходя на такой джун по SSH, вы всегда будете попадать на Master-RE, и команда show config будет показывать именно текущий рабочий конфиг с мастера.

И хотя в штатных случаях конфиги и версии прошивок должны быть одинаковы (первое задается через set system commit synchronize в конфиге или ручками при commit synchronize, второе вопрос организационный), могут возникнуть ситуации, когда конфиги не совпадают. В этом случае лучше в бэкап записать конфиги с обоих устройств. Однако просто так по SSH зайти на Backup-RE нельзя — он не управляет никакими интерфейсами, и на нём даже не запущен роутинг. Также мы не можем заранее 100% знать, какой из RE сейчас мастер — это может менять в процессе использования / ребутов / обновлений прошивок и прочего.

Решение есть в самой джунос и оно прекрасно:

#!/bin/sh

# My backup script on backup-storage server; login over read-only class user to junipers

# Бэкапим текущий мастер-RE как обычно:
ssh {IP} "show configuration | display xml" > mx960-Master-RE.xml 2>/dev/null

# Бэкапим текущий резервный-RE более хитрой командой:
ssh {IP} "request routing-engine execute routing-engine other command \"cli show configuration | display xml\"" > mx960-Backup-RE.conf 2>/dev/null

# Бэкапим конфиг именно первого RE, независимо от его роли
ssh {IP} "request routing-engine execute routing-engine re0 command \"cli show configuration | display xml\"" > mx960-RE0.conf 2>/dev/null

То есть мы заходим таки сперва на текущий мастер, и говорим ему выполнить заданную команду (важный момент — под командой тут понимается команда FreeBSD-шелла, а не команда JunOS-консоли cli !), в данном случае — вызвать консоль JunOS, а ей уже передать команду отображения конфига на соседнем ядре. Вывод ловит уже наш SSH. Действо простое, понятное и безопасное. Не забываем заэкранировать кавычки для JunOS-команды.

Обнаружил тут, что после обновления битрикса появилась эта рекламная кнопка. Я немного охренел от того, что при апдейте КОММЕРЧЕСКОЙ цмс с очередным обновлением что-то вообще поменялось в макете сайта, и сперва подумал, а не хаканули проект случаем. Как оказалось нет, ничего не хакнули, просто один-цэ решила немного порулить чужими сайтами в выгодном для себя ключе за ваши деньги. Ведь не все же могут влезть в настройки.

(далее…)

Настраивая или проверяя какой-либо драндулет на никсах (неважно, десктопного или серверного применения), полезно знать, нет ли в системе старого уязвимого софта мохнатых версий.

Нашел для этого совершенно изумительный сервис:

https://vulners.com/#audit

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

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

Огромный плюс — не требуется ставить никакой софт, запускать мутные сркипты и вообще пускать кого-либо в свои владения. Поддерживается дебиан, федора, центос, редхат и оракля. И убунта, куда же без неё.

Фряха не поддерживается (да, оно ещё вполне себе живо), увы.

мистика и Juniper

Posted: 2016-05-29 in IT
Метки:

Ситуация :


May 29 11:00:03 ex4200-24f-sw1 chassism[1332]: AN_BYPASS Activated for port ge-0/0/2
May 29 11:00:03 ex4200-24f-sw1 chassism[1332]: AN_BYPASS: Link down, Restored config on bypass activated port ge-0/0/2
May 29 11:00:03 ex4200-24f-sw1 chassism[1332]: AN_BYPASS : Port ge-0/0/2 Saved time -75044563
May 29 11:00:04 ex4200-24f-sw1 chassism[1332]: AN_BYPASS : Port ge-0/0/2 Current -75043561 Saved time -75044563

Гуглинг даёт пару невнятных ссылок на англоязычные форумы. У нас нет ни LACP на этом порту, ни стекированных железок.

Симптомы — один из оптических линков лежит в дауне (Hardware Down), других флагов ошибок в show interface не фиксируется, после замены оптического модуля / перетыкания в соседний порт работает несколько часов и снова падает.

Первая идея: проверить синхронизацию времени. У нас время как раз было плохо синхронизировано, мантры deactivate / activate ntp (с последующими коммитами) в секции #system не помогли, делаем так:

> start shell
$ su
# which ntpdate
# /usr/sbin/ntpdate -u pool.ntp.org

После синхронизации времени линк мгновенно поднялся. Казалось бы, вот оно, решение.

Если прописано несколько NTP-серверов в #system ntp, то стоит проверить, что с каждого можно получить время командой ntpdate, и недоступные NTP-серверы либо поднять, либо удалить из конфига.

Помним главную заповедь админа:
«[После этого] ещё не означает [из-за этого]».

Но самый прикол в том, что хоть восстановление синхронизации времени и решило проблему, но снова лишь временно, пусть и на существенно больший промежуток времени.

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

Есть такая специализированная учётная система для провайдеров — UserSide. Хотя по мне так, она будет крайне полезна для любой более-менее крупной сети, например в бизнес-центрах. Штука совершенно замечательная в плане всякого учёта девайсов, линков, привязок абонентских портов, мониторинга состояния, учёта заявок и прочего. Софт — конфетка.
И там очень классно сделан опрос и мониторинг статусов портов на оборудовании.
Но если на железке число портов не фиксировано, то могут возникнуть сложности. О чём и расскажу.
(далее…)

QinQ — Часть_2, про Juniper

Posted: 2016-04-15 in IT, Networks
Метки:

Всем привет. Сегодня я расскажу об особенностях настройки Q-in-Q на джунипере, а конкретно — на Juniper EX-4200. Ну и про замеченные багофичи тоже не забуду упомянуть.
(далее…)

Перепостить это древнейший боянЪ меня сподвигла длительная изматывающая борьба с глюками мультикастового IPTV.
(далее…)

D-Link DVG-5402SP nano-howto

Posted: 2016-02-25 in Hardware, IT, Networks
Метки:,

Заметки для себя про этот гибрид говно-роутера и воип-шлюза начального уровня.

* Для сброса настроек ресет надо нажать при ВКЛЮЧЕННОМ девайсе и держать 5-8 секунд подряд, НЕ СБРАСЫВАЯ ПИТАНИЕ, пока не начнёт часто мигать индикатор [Prov./Alm.]
* default-IP :: WAN: DHCP, LAN: 192.168.8.254/24
* Фирмварь обновлять обязательно.
* Не забыть включить приоритет кодеков и прописать SIP-прокси строки, включение реги и Display Name (в статусе светится как Extension Number!!) в обе линии.

+ дешёвый
+ 4 порта LAN, для операторского места (инет на 1-3 компа + два теплых ламповых телефона) вполне ОК.
+ быстро грузится (секунд 10 с воип-регистрациями)
+ резервный FXO для переключения на аналоговую телефонию при отказе VoIP
+ даже IPTV/Multicast немного умеет
+ QoS для VoIP

— нет WiFi, совсем
— доступ из WAN по HTTP закрывается указанием порта 0 в настройках
— настройки файервола полное гуано
— Full-HD поток из IPTV ставит девайс раком, 40-60% потерь пингов через forward/nat, не-HD каналы ОК
— iperf по TCP показывает всего 9-12 Мбит, по UDP 70-82 Mbit
— Пароли длиннее 10 символов не умеет. Поставить можно, но потом будет на зайти веб-мордой
— телнет светит всему миру
— про SSH, L7-DPI и прочие страшные слова сей девайс даже не слышал.

Самый быстрый и простой тест отпичексого модуля.

Самый простой способ проверить, включился ли SFP/SFP+/XFP модуль, работающий в ближнем ИК-диапазоне, и проходит ли свет по волокну — это попробовать сфоткать его телефоном.
(далее…)

Всем привет.
В прошлой заметке я немного описал базовые настройки своего нового домашнего роутера, рассказал, чем он хорош, чем полезен домашний DPI и что мне вообще надо от такой девайсины. Как выяснилось, я использую значительную часть возможностей прошивки, значительная часть возможностей в планах на использование в будущем (прежде всего возможности VPN и модуля DPI), но потребовались и расширенные возможности, которые ставятся и настраиваются вне веб-морды.
Если вам интересно — ssh admin@192.168.1.1 -p 22 и поехали.
(далее…)

Всем привет.
Решил написать немного про домашние роутеры и те особенности, с которыми я столкнулся, выбирая себе домой железку такого класса. Статья будет длинная, и возможно, даже в нескольких частях. А может и в одну впишусь.
Если интересно — читаем дальше. ifup eth0 && service bwdpi start, поехали…
(далее…)