Category: it

gul

Я знаю шутку...

Оригинал взят у bytebuster463 в Я знаю шутку...
1. Я знаю отличную шутку про UDP, но не факт, что она до вас дойдет.
2. Я знаю отличную шутку про TCP, но если она до вас не дойдет, то я повторю.
3. А кто знает отличную шутку про ARP?
4. А вы слышали шутку про ICMP?
5. Вам еще кто–то рассказывал шутку про STP?
6. Я подожду Антона и расскажу классную шутку про QoS.
7. Про MTU тоже есть кла
8. XML
9. А про FSMO роли шутить могут не более пяти человек.
10. Подождите все, я расскажу шутку о сети типа "шина".
11. Я бы рассказал отличную шутку про Token Ring, но сейчас не моя очередь.
12. Стой–стой, послушай сначала шутку о прерываниях.
13. Помню времена, когда шутка про модем пшшшшшшш.....
14. Только что, специально для сообщества пришла шутка про мультикаст.
15. Жаль, что шутка про Fault Tolerance не может состоять больше, чем из одного слова.
16. Настало время рассказать шутку про NTP.
17. Я сейчас расскажу отличную шутку про VPN, но ее поймет только один.
18. К шутке про SCTP вначале должны все подготовиться.
19. Из–за одного, кто зевнул, придётся заново рассказывать шутку про frame relay в топологии point–to–multipoint.
20. А шутки про HDLC обычно не понимают те, кто знает другие шутки про HDLC.
21. Про DWDM шутят сразу несколькими голосами.
22. Шутка про Е3 — это 30 одинаковых шуток про Е1 и еще две шутки, понятных только тем, кто в теме.
23. Лучшее в шутках про проприетарные протоколы это УДАЛЕНО.
24. Единственная проблема в шутках про Token Ring в том, что если кто–то начнёт рассказывать шутку пока говорите вы, обе шутки обрываются.
25. Все любят шутки про MitM. Ну, кроме Алисы и Боба, все.
26. идти Самое про BitTorrent — они могут порядке. в шутках лучшее в любом
27. Я бы рассказал шутку про CSRF, если бы ты САМ только что этого не сделал.
28. IGMP шутка; пожалуйста, передай дальше.
29. Нет… Нет ничего… Нет ничего забавного… Нет ничего забавного в шутках… Нет ничего забавного в шутках про определение MTU.
30. PPP шутки всегда рассказываются только между двумя людьми.
31. Шутки про RAID почти всегда избыточны.
32. Фрагментированные шутки…
33. … всегда рассказываются…
34. … по кусочкам.
35. Вы уже слышали шутку про Jumbo фреймы? Она о–очень длинная.
36. Самое клёвое в шутках про rsync, что вам её рассказывают только если вы не слышали её до этого.
37. Проблема с IPv6 состоит в том, что их трудно вспомнить.
38. DHCP шутки смешны, только если их рассказывает один человек.
39. Жаль никто не помнит шутки про IPX
40. У кого есть кабель? Есть смешная шутка про RS–232 и полусмешная про RS–485
41. Я сейчас всем расскажу шутку про бродкаст
42. У меня есть примерно 450 000 шуток про BGP
43. У кого есть пароли, приходите за шутками про RADIUS
44. Шутку про 127.0.0.1 каждым может пошутить себе сам
45. А что, шутки про IPv4 уже закончились?
46. Шутки про RFC1918 можно рассказывать только своим
47. Шутки про IPv6 плохи тем, что их мало можно кому рассказать
48. Шутки про SSH–1 и SSH–2 несовместимы между собой
49. Про Schema Master шутит только один в этом лесу
49. Шутки про MAC–адрес могут не дойти до тёзок
xx. Тут шутка про Banyan подросла
50. DNS–сервер не понял шутку про DDoS и ему её стали пересказывать сто тысяч раз в секунду
51. В шутках про IPSec надо говорить, кому их рассказываешь
52. И ГОСТ, и ISO согласны, что есть 7 уровней рассказывания шуток
52.1 Министерство обороны США понимает только четыре уровня шуток
53. Шутки про шутки про шутки часто звучат в туннелях
54. Шутки про 10/100/1000BASE–T вряд ли услышат с расстояния больше 100 м
Off: Шутки про TFT оставляют смазанное впечатление

gul

Cleanup juniper config

Лень всё же победила. :)
Вместо того, чтобы в очередной раз руками вычищать из конфига куски, которые перестали использоваться (policy-statements, firewall filters и т.п.) написал для этого перловый скрипт.
Ему параметром или на stdin даётся конфиг, он его анализирует, и на выходе выдаёт команды удаления неиспользуемых policy-statements, prefix-lists, community, as-path, firewall filters, firewall policers. Эти команды удаления можно потом копипастнуть в конфиг. Если используется dynamic-db, динамический конфиг можно дать вторым параметром - тогда скажет, что можно удалить и оттуда.

Сначала подумал, не сделать ли его как junoscript (на commit или как op script), но решил, что это и писать сложнее, и использовать менее удобно.
Написан за час (может, два) на коленке, написан неправильно (парсинг конфига, если по уму, нужно делать совсем не так), сделан исключительно под мои конфиги, так что корректную работу с другими конфигами не обещаю. Но может и сработать. :) У меня отработал и на MX, и на EX. Ловит inactive-части конфига, использование firewall filters как input/output на интерфейсе или вложенные, либо как fail-filter в urpf, полисеры - используемые из фильтров или непосредственно на интерфейсе (input/output/arp), policy-statements - в конфигурации протоколов или вложенные.
Если кому предложит удалить что-то лишнее или наоборот - не предложит удалить то, что надо бы - пишите, поправлю. Это только самая-самая первая версия.

Надо будет и для cisco ios такое тоже сделать.

Или это я велосипед изобретаю, и оно такое давно есть стандартное?
gul

Ужасы spanning-tree

Давненько ничего сюда не постил, сорри. Материалов достаточно, просто руки не доходят.
Постараюсь не уходить так надолго.

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

Ничто не предвещало беды, когда 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).
gul

Ещё про JUNOScripts

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 )
gul

DoS & DDoS

Все привыкли к тому, что время от времени случаются DoS и DDoS-атаки. Что с ними делать?
Владельцы ресурсов и админы корпоративных сетей пытаются защитить себя сами. Всякие IDS, IPS, PIX, ASA, Netscreen и много других умных слов. Этот подход логичен, но имеет очевидный недостаток: если атака уложила border router или забила канал к провайдеру, находящиеся внутри средства обнаружения и предотвращения атак бесполезны, нужно содействие ISP.
Что же делать ISP, как защитить клиентов? Ведь его задача - передавать IP-трафик максимально качественно (надёжно, быстро и без потерь), фильтрация в его функции не входит. На объёмах трафика ISP фильтрация (IPS) будет стоить неразумно, клиентам попросту не нужен такой сервис за такие деньги. Да и настройка фильтров - процесс трудоёмкий и индивидуальный, у каждого клиента свои потребности и особенности.
Реакция ISP нужна только тогда, когда атака уложила либо канал, либо border router клиента. Иначе клиент имеет возможность отфильтровать самостоятельно, и перекладывать эту функцию на ISP смысла нет. Автоматическая фильтрация на стороне ISP может быть и вредна. Например, трафик вполне легитимной видеоконференции может быть ошибочно расценен как DoS (большой поток UDP) и отфильтрован, что, очевидно, не вызовет благодарности клиента.
Collapse )
gul

Cisco: ограничение скорости транзитного вилана

Часто есть задача: ограничить скорость вилана, проходящего транзитом через свич из одного интерфейса в другой.
Каталисты легко поддерживают ingress policing на физическом интерфейсе, но если нужно ограничить не весь трафик из интерфейса, а отдельные виланы из транкового порта, всё становится сложнее. Особенно, если скорость должна быть ограничена не по сумме всех направлений вилана, а в каждую сторону независимо (а обычно оно именно так). Тем не менее, задача решается как на 3560 (3550, 3750, 3560-E и т.п.), так и на 6500.
Collapse )
gul

Что делать с вредными more specific routes

Есть такая старая проблема:
клиент анонсирует /23 апстриму и эту же сетку, как два /24, в IX (например, в UA-IX). В результате получается, что трафик из мира приходит апстриму по /23, а потом идёт клиенту уже по /24 (more specific) через IX. В итоге клиент получает внешний трафик через IX, без ограничений скорости, учёта и пр.
Collapse )
gul

Ликбез

Раньше я думал, что все, кто настраивает BGP или MTA, в общих чертах знают, как это делать. Сейчас вижу, что роут-лики - это не единичные случайные ошибки, а пугающе массовое явление. Поэтому думаю, что описание банальных и очевидных для многих вещей будет не лишним.
Collapse )
gul

Задачка

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