Привет! В этой статье я расскажу про интересные особенности протокола маршрутизации EIGRP.
Основы EIGRP отлично описаны в одной из статей цикла СДСМ: 6. Сети для самых маленьких. Часть шестая. Динамическая маршрутизация.
В первой половине статьи кратко описаны некоторые факты об этом протоколе, а во второй — несколько интересных примеров с топологией и командами.

Факты про EIGRP

• В феврале 2013 года Cisco решила открыть EIGRP. Стоит отметить, что был открыт не исходный код, а лишь информация, необходимая для реализации протокола. В итоге появился драфт RFC. Последнее обновление 10.04.2014. В этом документе не была раскрыта ключевая особенность — Stub, без которой пользоваться протоколом практически бесполезно. Интересна реакция других вендоров: на сегодняшний день никто, кроме Cisco, не внедрил поддержку этого протокола в своём оборудовании.
• EIGRP для расчёта метрики использует 5 K-values, которые являются лишь модификаторами (коэффициентами), и 4 значения метрики. Надёжность (reliability) и загрузка линка (load) являются динамическими параметрами, поэтому эти значения пересчитываются только при изменении в сети. K5 — это дополнительный коэффициент надёжности, и никакого отношения к MTU он не имеет! Напомню общую формулу расчёта метрики:
  
  
  
  А если K5 = 0, то формула имеет такой вид:
  
  
  
  
  
  
  
  где min_bandwidth — это пропускная способность наихудшего линка в kbps,
  а total_delay — это сумма задержек всех линков в мкс (микросекундах).
  
  Для изменения метрики обычно меняют delay, так как bandwidth влияет на QoS, кроме этого, изменение bandwidth не всегда меняет метрику (если наихудший линк не изменился).
  Минимальное значение MTU действительно подсчитывается, но не принимает никакой роли в определении лучшего пути. В своей топологии в GNS3 я тестировал несколько десятков раз с помощью команд redistribute connected metric и maximum-paths 1. Несмотря на различное значение MTU, лучший путь выбирается тот, который был изучен ранее. Также интересно, что в драфте RFC упоминается дополнительный коэффициент K6 и 2 дополнительных значения метрики: джиттер (jitter) и энергия (energy).
• Feasibility Condition не всегда легко понять в первый раз. Но логика очень простая: если ты говоришь мне, что у тебя метрика больше, чем метрика моего лучшего пути, значит есть шанс, что твой путь проходит через меня, что в свою очередь означает петлю. Из-за этого часто очевидные для инженера «пути-без-петли» могут не рассматриваются протоколом как feasible successors. Помните, EIGRP не видит всей сети — а лишь то, что говорят соседи.
• EIGRP — Distance Vector протокол, никакой гибридности в нём нет.
• С помощью show ip eigrp neighbors detail можно посмотреть, является ли сосед тупиковым (stub) роутером.
• Помните, с помощью команды show ip eigrp topology видны лишь successors и feasible successors. Чтобы посмотреть все возможные пути, необходимо добавить ключевое слово «all-links»: show ip eigrp topology all-links.
• В IOS 15 наконец-то отключена по умолчанию автоматическая суммаризация, ура! Прощай команда no auto-summary!
• Значения таймеров (hello и hold) могут быть неодинаковыми. Кстати, значение таймера hold передаётся соседу и означает: «если в течение X секунд ты от меня не получишь hello, значит я больше недоступен».
• EIGRP использует свой транспортный протокол (IP protocol number: 88) — RTP (Reliable Transport Protocol). Не стоит путать его с другим известным протоколом Real-time Transport Protocol (тоже RTP), который используется для передачи потоков реального времени, например VoIP (в связке с SIP). EIGRP также использует мультикаст адрес: 224.0.0.10. Не забывайте во входящем ACL разрешать EIGRP трафик, например с помощью записи: permit eigrp any any.
• Из-за различных значений административной дистанции (AD) для внутренних (90) и внешних (170) маршрутов, EIGRP позволяет избежать некоторых проблем при редистрибьюции (redistribution).
• Помните, что 2 роутера могут быть соседями, и при этом у них может не быть adjacency. С помощью команды show ip eigrp neighbors показываются лишь соседи. В выводе этой команды стоит обратить внимание на поле Q Cnt: если там не ноль, то вполне возможно, что у вас есть проблема в сети (например, неустановленное adjacency).
• EIGRP кроме суммарного маршрута может отправить и конкретный специфический маршрут. Эта особенность называется EIGRP Leak Map. Это полезно, если мы хотим сделать traffic engineering. Идея очень похожая на bgp unsuppress-map. Для этого необходимо применить команду: ip summary-address eigrp as-number summary-address summary-mask leak-map leak-map-route-map.
• Как верно добавил alk0v, в отличие от OSPF, EIGRP поддерживает балансировку нагрузки при разной метрике (unequal cost load balancing). Для этого необходимо использовать команду variance. Стоит помнить две вещи: это работает только для successors/feasible successors и, по умолчанию, CEF выполняет балансировку per-destination. Последнее значит, что 2 пакета, у которых соответствующие IP адреса отправителя и получателя одинаковые, всегда будут выходить из одного и того же интерфейса, что заметно усложняет проверку. Если вы всё же хотите это проверить, то можно переключить CEF в режим per-packet (в режиме конфигурации интерфейса используйте команду ip load-sharing per-packet) или вообще его отключить (команда no ip cef в глобальном конфигурационном режиме, не рекомендуется).

Ну что, пора заняться практикой?

Wordpress в стандартной установке довольно медленный. По умолчанию движок не использует некоторые возможности современного Веба для значительного своего ускорения. Существует целая куча плагинов для оптимизации Wordpress'a. Давайте наведем в них порядок и проведем капитальную оптимизацию.

На работе мы активно используем виртуализацию на базе qemu/kvm через libvirt. Сам я давно пересел на linux и также использую qemu/kvm на своей локальной машине, при этом, часто применяю графический virt-manager для настройки различных параметров ВМ. Хотелось использовать его и для управления гипервизорами на удаленных серверах. О том как это сделать и будет статья в виде пошаговой инструкции(по факту это перевод и «сведение в едино» официальной документации).

В этом посте я хотел бы поделиться не совсем обычным, для мира PHP, способе построения приложения, если угодно — архитектурой. Данный подход позволяет средствами PHP увеличить количество обрабатываемых запросов в разы. Так же я поделюсь своими наработками в этом направлении. Конечно данный подход не бесплатен, в плане требований к коду, но давайте всё по порядку.

Abstract: Изоляция приложения на уровне сети использованием network namespaces Линукса. Организация SSH-туннелей.

Традиционно, большая часть статьи будет посвящена теории, а скучные скрипты — в конце статьи. В качестве субъекта для экспериментов будет использоваться Steam, хотя написанное применимо к любому приложению, включая веб-браузеры.

Вместо вступления. Я просто покажу эту картинку:

147%… Что-то мне это напоминает. Впрочем, хабр не для политики.

Цена на игры в Стиме зависит от региона. Регион — от IP'шника. Есть желание иметь цены в рублях, а не в евро.

Для этого мы используем VPN через SSH с использованием tun-устройств, плюс network namespaces для изоляции приложения от всех остальных сетевых устройств.

Network namespaces

Традиционно, приложение, запускающееся даже с правами пользователя, имеет полный доступ в сеть. Оно может использовать любой сетевой адрес, существующий в системе для отправки пакетов.

Более того, большинство десктопных приложений вообще ничего не понимает в интерфейсах, так как предполагают, что у системы есть только один сетевой интерфейс и не даёт возможности указать, каким из интерфейсов надо пользоваться. Серверное ПО обычно имеет эту опцию (какой адрес использовать в качестве адреса отправителя), но для десктопов это непозволительная роскошь.

Если у нас есть несколько интерфейсов (один из которых относится к VPN), то нет штатных методов сказать стиму, что надо использовать его, а не eth0/wlan0. Точнее, мы можем «завернуть» весь трафик в VPN, но это не всегда желательно. Как минимум — рост latency и снижение скорости (даже если VPN ведёт на супербыстрый сервер, увеличение latency, оверхед от туннеля и фиксированная ширина локального канала ставят TCP в положение, когда приходится резать скорость). Как максимум — одно дело «покупать через русский VPN», другое дело — пускать туда весь трафик. Меня совсем не прельщает использование VPN для получения защиты роскомнадзором от оппозиции и вольнодумства.

В этих условиях возникает большое желание оставить один на один конкретное приложение и заданный сетевой интерфейс. Один. Сконфигурированный для нужд только этого приложения.

Для решения этой задачи в Linux, уже довольно давно (аж с 2007 года) существует технология, называемая network namespaces, то есть пространства имён для сетей. Суть технологии: над сетевыми интерфейсами создаётся подобие «каталогов», в каждом каталоге может быть несколько сетевых интерфейсов и приложений. Приложение, оказавшееся в заданном сетевом пространстве имён, может использовать (и видит) только те сетевые интерфейсы, которые отнесены к этому пространству.

Картинка ниже поясняет происходящее:

Полтора месяца назад, chr13 обнаружил способ произвести DDoS любого сайта с помощью Google Spreadsheet, а теперь же он применил такой способ в Facebook Notes. И он сработал!

Способ эксплуатации совершенно такой же, как и в Google Spreadsheet:

1. Сделайте список «уникальных» «картинок»
   

   <img src=http://targetname/file?r=1></img>
   <img src=http://targetname/file?r=2></img>
   ...
   <img src=http://targetname/file?r=1000></img>

2. Создайте заметку через m.facebook.com. Сервис обрежет заметку после какой-то фиксированной длины
3. Создайте несколько таких заметок под одним или несколькими пользователями. Каждая заметка будет делать 1000+ HTTP-запросов
4. Откройте все заметки одновременно. Указанный сервер получит гору HTTP-трафика. Тысячи запросов уйдут на сервер в течение пары секунд.

Присказка

Было счастье, производство и офис находились на одной территории (за городом). Но фирма росла и стало тесно. Решили открыть офис в городе. Так как на предприятие уже имелось большое кол-во телефонных линий и стояла мини-АТС Panasonic TDA-600 ставить новую АТС в офис не хотелось. Выбрали вариант модернизации TDA 600 до TDE 600, любит начальство железные решения. Так как я уже давно раскидываю отдельные системы (видеонаблюдение, wifi, АСУТП) по VLAN'ам, то и телефонию вынес в отдельный VLAN. Для маршрутизатора был приобретён очередной Mikrotik.

Как только я заинтересовался Netmap’ом, меня сразу же стало одолевать любопытство, сколько пакетов в секунду можно будет «выжать» на обычном железе в режиме генерации пакетов и/или в режиме приёма и фильтрации пакетов? С какой производительностью можно будет фильтровать трафик различных, популярных на сегодняшний день атак и какие при этом будут потери пакетов.



Данные, которые показывает автор Netmap Luigi Rizzo весьма впечатляют. Как известно, по опубликованным Luigi тестам, Netmap легко генерирует 14Mpps и позволяет «поднять» поток в 14Mpps из сетевого кабеля в userspace, используя только одном ядро процессора Core i7. Стало интересно применить эту технологию в фильтрах очистки трафика.
Итак, на прошедшей в сентябре выставке InfosecurityRussia 2013 мы представили стенд, на котором по запросу всех желающих генерировали различные атаки и демонстрировали защиту от них, собирая статистику и отрисовывая различные графики Zabbix’ом.
В статье мы сконцентрируемся на некоторых особенностях архитектуры NETMAP, а также показателях скорости обработки пакетов, которые с его помощью получены на «обычном» железе.

Большинство реализаций списков доступа подразумевает под собой поведение «всё что не разрешено, то запрещено». Разумный подход, с учётом того, что при проектировании мы заранее ожидаем тот или иной тип трафика в определённом направлении: если у нас подключен абонент или пиринговый партнёр, значит данных с других IP на этом интерфейсе быть не должно, а если у нас подключен Интернет, откуда там взяться частным адресам? А может зря всё это? Может и нет никакого паразитного трафика и безусловный запрет в ACL это только перевод ресурсов. Ведь клиентам оператор сам выдаёт адреса, а пиринговые партнёры и апстрим провайдеры братья связисты, которые должны понимать всю сложность и щекотливость ситуации. К сожалению, это совсем не так.
Участники круглого стола посвящённому DDoS, прошедшего на YaC2013 очень сетовали на то, что при всех существующих рекомендациях никто не старается заниматься безопасностью своих сетей. То есть начинать надо в первую очередь с себя (с операторов связи), как минимум бороться с IP-спуфингом.
От чего же защищает deny ip any any можно посмотреть далее, просто примеры из журналов мониторинга.

Каждый веб-разработчик, выбравший Mac, после первичной настройки системы ищет рабочий инструментарий. И если c IDE и редакторами всё понятно, то что-либо подобное по удобству win-довым OpenServer или Denwer за бесплатно найти трудно. Есть отличное решение MAMP PRO, но оно стоит две тысячи деревянных. Да и работа через Apache некоторых может смутить.

Занимаясь решением этого вопроса, набрёл на интереснейший материал, который рассказывает о том, как при помощи консольного пакет-менеджера Homebrew настроить рабочее пространство буквально за 5-10 минут. Публикую его перевод, потому что кому-нибудь подобная инструкция по настройке веб-окружения на Mac обязательно пригодится.

Это короткое руководство, возможно, поможет кому-то, кто использует AWS (и, в частности, MySQL на инстансе EC2), восстановить данные в MySQL из снимка EBS (регулярное создание которых любой предусмотрительный системный администратор, конечно же, настраивает заблаговременно — с помощью ec2‑consistent‑snapshot, например)

Прежде всего нужно открыть EC2 Management Console, и в разделе ELASTIC BLOCK STORE → Snapshots найти подходящий снимок (обычно это последний снимок раздела).

Далее нужно щёлкнуть на снимке правой кнопкой мышки и выбрать «Create Volume». В Availability Zone при этом нужно выбрать тот же регион, в котором находится инстанс EC2.

После этого нужно перейти в раздел ELASTIC BLOCK STORE → Volumes и, опять же, щёлкнуть правой кнопкой мышки на появившийся раздел. В меню нужно выбрать пункт «Attach Volume», после чего в появившемся модальном окне выбрать инстанс EC2 и нажать «Yes, Attach».

Всё — на сервере должно появиться новое блочное устройство. Теперь можно запустить dmesg | tail и посмотреть, какой идентификатор был присвоен для подключённого блочного устройства. Допустим, это xvdg. Тогда ФС может располагаться, например, на /dev/xvdg1 (зависит от предпочтений того, кто создавал таблицу разделов).

Назрела необходимость замены медленного rdiff-backup на более шустрое решение для инкрементальных бекапов на удаленый сервер. Сперва рассматривался Rsnapshot, но причине того, что он не умеет без костылей делать бекапы именно на удаленные серверы от него отказались. Прочие аналоги нам также не подошли по тем или иным причинам. Искать что-то готовое на просторах github и допиливать под себя мы не захотели, поэтому было решено написать новый скрипт с нуля своими силами. Главная цель сделать решение для инкрементального бекапа на удаленный сервер схожее с rdiff, но с использованием жестких ссылок rsync.

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

Думаю, что все разработчики на PHP (включая меня) так или иначе проходили через период, когда код представляет из себя жуткую смесь html и php, напиханных в одном файле. И речь не о шаблонах, а вообще о всей логике в лапше/спагетти-коде.
И в качестве концепта я решил к первому апреля набросать реализацию чего-то подобного, но на lua под nginx. Прямо как на картинке.

Сегодня существует довольно много профессиональных инструментов для мониторинга состояния серверов с обилием настроек, плагинов, поддержкой сразу множества машин и т.д., это известные Nagios, Zabbix, Munin, Cacti и многие другие.


Но в этом посте речь пойдет об очень маленьком и простом, но от этого не менее полезном инструменте: инструменте для мониторинга Scout Realtime. Этот написанный на Ruby open source проект позиционируется разработчиками как современная замена консольной утилите top с выводом статистики использования диска, памяти, сети, CPU и запущенных процессов. Все это отображается в реальном времени с плавными графиками. Во время диагностики работы сервера, иногда полезно пару минут понаблюдать за показателями, и проследить их изменение во времени (в отличие от гирлянды мерцающих чисел в терминале, отображающих данные исключительно на текущий момент).

Решил пополнить копилку статей на Хабре про такой замечательный ЯП, как lua, парой примеров его использования под капотом nginx. Разбил на два независимых поста, второй тут.

В этом посте nginx используется как «горячий кеш» неких постоянно пополняемых данных, запрашиваемых клиентами по интервалу с опциональным группированием (некий аналог BETWEEN и GROUP BY/AGGREGATE из SQL). Подгрузка данных в кеш осуществляется самим же lua+nginx из Redis. Исходные данные в Redis складываются ежесекундно, а клиенты хотят их от сих до сих (интервал в секундах, минутах, часах...) с агрегацией по N (1<=N<=3600) секунд, отсортированные по дате и в json формате.
С хорошим hitrate на имеющейся машине получается обеспечить 110-130к «хотелок» в секунду, правда с плохим — только 20-30к. Что, в общем-то, тоже приемлемо для нас на одной инстанции nginx.

Данный пост является продолжением применения lua в nginx.

Там обсуждалось кеширование в памяти, а тут lua будет использоваться для фильтрации входящих запросов в качестве этакого фаервола на nginx-балансере. Нечто подобное было у 2GIS. У нас свой велосипед :) В котором разделяем динамику и статику, стараемся учесть NAT и белый список. И, конечно же, всегда можно навернуть еще специфичной логики, что не выйдет при использовании готовых модулей.
Данная схема сейчас спокойно и ненапряжно (практически не сказывается на использовании cpu) обрабатывает порядка 1200 запросов/сек. На предельные величины не тестировалось. Пожалуй, к счастью :)

В первой части мы установили MySQL и собрали Астериск из исходников с поддержкой res_config_mysql (Asterisk Realtime Architecture)

Настройка DHCP-сервера

У меня в двух рабочих средах развёрнуты разные DHCP-серверы, покажу настройки для трёх самых (имхо) популярных: Windows Server DHCP, Mikrotik, DNSMasq

В одно прекрасное утро я просматривал логи и задал себе ряд вопросов:

1. А жду ли я письма из Юго-Восточной Азии? (когда смотрел логи почты)
2. И с какого перепугу ко мне стучатся ssh брутфорсеры из Штатов?
3. Мне надо терпеть сетевые сканеры из Австралии?
4. Кто мне звонит из Африки? (когда разглядывал логи asterisk)
5. С какой стати к моему POP-серверу обращаются из Латинской Америки?

Почему бы не забанить по континентам? Оставив только нужный континент(ы)?

Часто попадали в ситуацию когда на мобильном обнаруживаешь пропущенный звонок с городского и при попытке перезвонить попадаешь на голосовое меню какой-нибудь фирмы и совершенно непонятно кто тебе звонил? Я часто, а также и клиенты нашей компании каждый день сталкиваются с этим… С этим решено было что-то делать. Все последующие действия актуальны для trixbox v2.8.0.4 (с некоторыми корректировками или, возможно, даже без них можно реализовать и на других системах)

В это статье хочу поделиться одним интересным на мой взгляд способом проверки доступности sip провайдера, или другого устройства, особенно он актуален когда по какой-либо причине нельзя проверить сторону icmp запросами, и основывается на OPTIONS запросах протокола SIP. Кого заинтересовала данная тема прошу под кат.