?

Log in

No account? Create an account
gul_tech
19 January 2011 @ 07:39 pm
Давненько ничего сюда не постил, сорри. Материалов достаточно, просто руки не доходят.
Постараюсь не уходить так надолго.

Пока свежо в памяти, расскажу, что у нас приключилось совсем недавно (а точнее - позавчера).

Ничто не предвещало беды, когда port-channel из нескольких 10GE интерфейсов (между cat6500 и extreme x650) упал с сообщением

Jan 17 16:07:01.581 marmot: %PM-SP-4-ERR_DISABLE: channel-misconfig error detected on Po2, putting Po2 in err-disable state

при том, что последнее изменение конфигурации этого шеститонника было за три дня до этого. Потом (через полминуты) он поднимался по autorecover и через пару минут падал опять с тем же сообщением. Пересоздание этого port-channel ситуацию не изменило. В дебаге тоже ничего путного.

На поиск причин и методов устранения ушло около часа.
Как оказалось, один из клиентов начал слать странные bpdu, а поскольку он был включен в x650, на его порту bpdu не фильтровались, а проходили дальше на 6500. А 6500 при этом укладывал port-channel со столь странной диагностикой.

Открыл для себя команду "no spanning-tree etherchannel guard misconfig". Точнее, это sha90w мне её открыл (и заодно себе). Всем рекомендую.

Выводы:
1. STP - зло. Если его использование необходимо, BPDU должны ходить только в пределах собственной сети, и фильтроваться на всех клиентских портах в обе стороны (не лениться делать это через mac acl, где более простых способов нет). Хотя даже в этом случае нельзя быть полностью спокойным.
2. Реализация L2 в Cisco IOS мягко говоря странная.

Приведу ещё один пример, на этот раз гипотетической ситуации, демонстрирующей эти два вывода.
Допустим, мы купили L2-транспорт у стороннего оператора, q-in-q. И этот оператор (по нашей просьбе или по своей инициативе) прописал для нас туннелирование bpdu, "l2protocol-tunnel stp" на каталистах. Мы аккуратно прописали bpdufilter на клиентских портах и используем stp на этом линке.

И тут один из наших клиентов прислал нам туннелированный bpdu-пакет (а фактически, произвольный пакет на мультикастовый мак 01:00:0c:cd:cd:d0). Этот пакет прошёл наш bpdufilter, потому что это не bpdu, и ушёл в этот транспорт. Тамошний каталист, туннелирующий bpdu, обнаруживает уже туннелированный пакет. Вместо того, чтобы его дропнуть, он что-то не очень внятное сообщает в лог и закрывает порт по err-disable, хоть там 8*10GE и 1000 виланов. И не сообщает, в каком вилане ему пришёл вызвавший такую его реакцию пакет. И этот errdisable не отключается.

Фактически имеем примерно то же самое, что в реальном позавчерашнем случае: незащищённость от активности с клиентских портов, крайне скудная диагностика свича и сложность диагностировать проблему вручную, укладывание всего порта (в т.ч. port-channel) из-за одного неожиданного пакета по err-disable вместо того, чтобы просто дропнуть этот пакет, на cisco ios (другие вендоры за этим не замечены).

Как-нибудь при случае расскажу ещё о всяких интересных граблях на mstp (из-за чего мы сейчас используем только pv-stp).
Tags: ,
 
 
 
gul_tech
22 April 2010 @ 03:33 pm
Публиковать скрипт на 50 строчек, конечно, смешно, но учитывая, что это скрипт на SLAX, надеюсь, что не засмеёте. Потому что пользователей JunOS по моим представлением гораздо больше, чем тех, кто пишет скрипты. Ну и написание/отладка существенно сложнее, чем perl или bash (по крайней мере, для меня).

В общем, скрипт - выводит "show bgp sum" в несколько другом формате и с дополнительной информацией. Формат - по одной строке на каждый пир (после поднятия IPv6 обычный "show bgp sum" стал рисовать пиров в две строки, из-за чего не получалось использовать "| match ..."); кроме того, для каждого пира пишет его группу и description. Длина выводимых строк около 100, соответственно, желательно, чтобы у терминала тоже строки были длиннее 80 символов. Может, кому пригодится. Скрипт.

Скрипт надо положить в /var/db/scripts/op/ и в конфиге прописать "set system scripts op file show-bgp-sum.slax", после чего будет работать команда "op show-bgp-sum".

UPD:
ver 0.2 - Process groups inheritance, support route-instances (заменил первую версию на эту)
ver 0.2.1 - Show advertised prefix count - Cougar 20100513
ver 0.2.2 - Added local interface name
ver 0.3 - Get additional info by "show bgp group", not from config (based on 0.2.1)
ver 0.3.1 - Add local interface information

Если информация о локальных интерфейсах не нужна, версии 0.3.1 и 0.2.2 использовать смысла нет, лучше вместо них брать 0.3 или 0.2.1.
Версии 0.3 и 0.3.1 не требуют прав чтения конфигурации пользователем. Соответственно, корректно отрабатывают случаи использования commit-scripts. Но при этом не показывают информацию про route-instance (только bgp group).
Версии 0.2.1 и 0.2.2 работают чуть медленнее, чем 0.2, т.к. делают дополнительный запрос (get-bgp-neighbor).
Версия 0.3.1 работает несколько медленнее, чем 0.3 по той же причине.
Что быстрее - 0.2.x или 0.3.x - в разных случаях по-разному.

Выбирайте наиболее подходящий для вас вариант. :) Лично я у себя использую 0.2.2 с выброшенной оттуда работой с bgp instances (для ускорения, я их не использую).
Tags:
 
 
gul_tech
22 April 2010 @ 03:09 pm
Изменение позиций в топе как России, так и Украины.
ReTN и ITSystems уступили лидерство. Сейчас среди российских провайдеров по размеру клиентского конуса (в пересчёте на IP-адреса) лидирует РосТелеком, среди украинских - ETT. Таблица ниже под катом.

Немного доделал движок, сейчас можно выбирать, сколько первых строк показывать, и (отдельно) минимальный ранг показываемых провайдеров в мировом рейтинге. Например, можно показать российских провайдеров с рангом не ниже 1000, но не более 100 штук. А то раньше многих сбивало с толку: вроде, задал показать 1000 украинских провайдеров, а многих нет - на самом деле, показывались украинские провайдеры с мировым рангом не ниже 1000, а таких не так уж много. Отсутствие ограничения означает показывать всех.

Нашлись таблицы BGP начиная с ноября 1997. Правда, только от Origon-IX, одного источника маловато для получения надёжных результатов, но, тем не менее, что-то получилось, вполне правдоподобное. Вот графики развития основных украинских провайдеров того времени, за 5 лет с 1997 по 2002 годы:


Тут можно напомнить, что в 2000 в результате рейдерства LuckyNet сменил владельца и ген.директора (с Сергея Гульчука на Артура Габовича).
Рейтинг провайдеров RU и UACollapse )
Tags:
 
 
gul_tech
10 March 2010 @ 06:42 pm
Прислали:

P.S. Этот пост не проплачен. ;-)
 
 
 
gul_tech
16 February 2010 @ 12:33 pm
Появилось новое явление (или я раньше про него не знал): без спроса автора сайта, расположенного на бесплатном хостинге вроде narod.ru, делается его зеркало на нормальном хостере и красивом домене.
Пример: http://dolotov.narod.ru - оригинал, возникшее зеркало: http://speleologist.ru, а вот мнение владельца этого сайта.
Как-то это для меня непонятно и неожиданно. Даже добавленных баннеров не заметил (может, спрятаны - искал не сильно).
Интересно, насколько это законно или наказуемо? Вроде как, авторство себе не приписывается, а копия - ну так она и в кеше поисковиков есть, и на web.archive.org. Но с другой стороны - что-то в этом есть неправильное, как будто контент спёрли.
 
 
gul_tech
17 December 2009 @ 01:10 am
В связи с появлением нового мультика про DNS вспомнился старый (примерно 10-летней давности) мультик про TCP/IP:



UPD: Кто испытывает трудности с английским, вот есть ролик (mpeg) и русские субтитры к нему.
 
 
gul_tech
Подумалось мне, что было бы очень полезно создать распределённый поисковик или распределённую же социальную сеть как альтернативу Google.

Для начала - что именно хотелось бы сделать? Я вижу такие цели:

  • поисковая система (много направлений - поиск файлов, поиск по иерархиям, по релевантности);
  • среда общения: IM (включая аудио и видео), социальная сеть; в том числе - общение людей за nat/proxy; проблема спама;
  • группы по интересам (по аналогии с форумами, коммьюнити или ньюсгруппами);
  • блоги, хостинг, wiki;
  • безопасность, аутентификация, криптование;
  • веб-интерфейс, нет необходимости ставить специализированный софт у пользователя.
Read more...Collapse )
 
 
gul_tech
04 December 2009 @ 09:59 pm
Человеку для определения чего-то естественно последовательно уточнять, а не наоборот. Город, улица, дом, квартира. Или час, минута, секунда. Или сотни, десятки, единицы. В общем, оно понятно.
При этом некоторые пишут/читают слева направо, некоторые справа налево, как у кого повелось, тут "интуитивно понятного" нет, это традиция, как есть страны с левосторонним и правосторонним движением. Арабы и евреи пишут справа налево, европейцы и американцы - слева направо.

Так вот. Почему интернетовские доменные имена имеют вид firma.kiev.ua, которые, чтобы было интуитивно понятное последовательное уточнение, нужно читать справа налево? Почему не ua.kiev.firma (как в иерархии конференций usenet, в фидошных эхах и во многих других местах)? Кто из авторов DNS был евреем или арабом? Ведь даже для резолвинга разбирать домен нужно последовательно справа налево (сначала ua, потом kiev.ua, потом firma.kiev.ua), что совершенно нелогично для английского языка.

Я уже молчу про интеловскую архитектуру с хранением чисел "левый байт самый младший" - такой записи нет ни у евреев, ни у арабов, насколько я знаю. И ведь каждый раз при приёме или отправке таких чисел в сеть нужно переставлять байты местами, а при получении - менять обратно, потому что в сети, благо, принят нормальный порядок (сначала старший байт, потом младший). В чём же фишка перевёрнутого порядка байт? Чтобы можно было записать четырёхбайтное число, а потом по тому же адресу прочитать двухбайтное, и, если число было небольшим, получить правильный результат? Как-то это несолидно выглядит в качестве аргумента.
 
 
gul_tech
17 November 2009 @ 04:24 pm
JONOScripts (в числе прочего) дают возможность автоматически реагировать на произвольные события. Например, при обнаружении более 2% потерь на линке увеличить ospf metric. Механизм мощный и гибкий.

В нашем случае понадобилось два применения:
1. Нужно резервирование L2-транспорта. Причём на одном из путей BPDU не проходят, так что любые варианты STP не подходят (bpdu tunneling тоже не работает).
2. Трафик на клиента распределяется на два линка, как multipath bgp, клиенту нужно ограничить полосу по сумме этих двух путей. Поскольку ограничение скорости у MX делается на каждом ICHIP независимо, а сабинтерфейсы клиента у нас принадлежали разным физическим 10GE-интерфейсам, ограничение полосы "в лоб" не получается.

Обе задачи успешно решаются через event scripts.
В первом случае - реакция либо на OSPF, либо на ping tests. При падении основного линка указанный список виланов из этого транка убирается, а в транк на резервный линк добавляется. При поднятии основного линка конфигурация возвращается в исходное состояние. Скрипт
Во втором - реакция на изменение состояния BGP с клиентом. Если обе сессии живы, на каждом из сабинтерфейсов прописывается ограничение в половину положенной клиенту полосы. Если одна из BGP упала - на оставшейся полисер увеличивается до полной полосы. Скрипт

В конфигурации event policy никаких хитростей нет, поэтому не привожу, да и просто лениво. Если кому интересно - покажу, тем более, что скрипты без описания, и, не ориентируясь в slax, понять, как и с какими параметрами их запускать, проблематично, сорри.

В целом, всё работает. Однако есть нюансы. ложка дёгтяCollapse )
Tags: