Пояснение

среда, 31 января 2018 г.

Logstash and netflow.

The fastest way to load flow data into Elasticsearch.

Hello everyone, I will try to describe my own way to load LOTS of netflow data into Elasticsearch.

At first time I tried to use logstash-codec-netflow. It's work fine but relatively slow. With real data we couldn’t reach more than 7000 EPS on dedicated 16 core server. What’s a shame. This codec is really CPU hungry and 7000 EPS is lesser than third of our netflow data.

So the simplest way I found is “nfcapd + nfdump + filebeat + redis + logstash”. I use logstash mostly for filtering. I will add some details about the implementation in future. But in the few words:

nfcapd - lightweighted daemon for netflow capture. It handles more than 30000 EPS without noticeable CPU using;
nfdump - helpful tool for converting binary into csv data. It’s really fast;
filebeat - the fastest way to read and send text data. The default logstash output for filebeat is slow (it’s even slower than usual logstash file input). You must use the redis output for higher speed;
redis - in memory message broker. It’s the fastest way I know to load something into logstash;
logstash - the great and simple thing for filtering and parsing data.

The nfcapd saves flows on disk in binary for every five minutes. You should use -x option with it to run nfdump and convert files to csv format. After it you can read and send the csv files to the redis by filebeat.

It will looks like nfcapd -w -D -S 1 -l /var/log/basedir/ -p 2055 -x ‘shellscript.sh %d %f %t’

And the script will looks like:
#!/bin/bash  
nfdump -q -o csv -r $1/$2 > /other/$3.log

I used bash because I couldn’t redirect the output from nfdump inside the -x statement. 

So now you can read the resulted csv files by filebeat without any problems! 

среда, 30 сентября 2015 г.

OSPF PE-CE Protocol, part II

Это даже скорее не часть два, а небольшое дополнение касающееся работы loop prevention механизмов, написано по горячим граблям так сказать

Раньше, Cisco действительно довольно своеобразно реализовывала RFC4576, просто не выставляя DN-бит для всех LSA кроме summary. Однако, это поведение было исправлено и в современных софтах она таки блюдет RFC. Что приводит иногда к странным ситуациям, например топология успешно работающая на IOS 12.2(33), может совсем не заработать в 15.x или NX-OS. 

А всё дело в волшебных пузырьках! То есть, в функции capability vrf-lite, если она действительно помогала вам ранее в Cisco IOS, то в NX-OS её уже нет. Возникла ситуация, что мы хотим получать маршруты из MPLS-облака как прежде, но capability vrf-lite здесь нет. Да, есть опция down-bit ignore, но работает она по другому. Она просто отключает проверку DN-бита, но не отключает проверку domain-tag как прежде делала capability vrf-lite превращая наш PE роутер в CE.

Всё получается несколько сумбурно. Главное для меня не забывать о тонкостях редистрибьюции в OSPF. В нашем случае мы в итоге обошли loop prevention механизм в NX-OS, вручную управляя domain-tag, что приводило к порой очень внезапным последствиям.

воскресенье, 5 апреля 2015 г.

Sennheiser HD 439, моддинг.

Оффтопик.

Что мы делаем на работе помимо всего прочего? :) Слушаем музыку конечно. Так вот, у наушников Sennheiser HD 439 есть существенный недостаток. Они очень специфично отрабатывают бас, его по ощущениям мало и всё такое. Однако, для исправления ситуации есть довольно просто мод найденный на просторах Head-Fi.

Достаточно разобрать наушники сняв амбушюры и вытащив драйвер:



На правой фотографии видна черная лента. Под ней есть пара отверстий, если сняв ленту отставить их открытыми, то объем баса вырастет просто в разы. Даже с одним отверстием он сильно лишний и размазанный, а вот если оставить примерно половину... То качество звучания просто преобразится в лучшую сторону.

После модификации не происходит изменений в воспроизведении средний и высоких частот. Только баса становится ровно как надо. Например трек "Speak To Me" знаменитый своими низкими частотами, звучит теперь как надо .


четверг, 12 февраля 2015 г.

vPC и динамическая маршрутизация.


Существует один любопытный нюанс, с которым пришлось однажды столкнуться. Дело в том, что использование vPC весьма специфично ограничивает применение OSFP. Если подойти к этому делу без должного внимания, то это может привести к частичной недоступности узлов.

Подобная проблема возникает при попытке организации OSPF пиринга поверх vPC. Как и с остальными MLAG решениями это довольно нетривиально. Самое главное, надо запомнить следующее правило:

VPC peers are expected to forward a frame received on a member link out any other member link that needs to be used. Only if they cannot do so due to a link failure, is forwarding across the VPC  peer link and then out a member link allowed, and even then, the cross-peer-link traffic can only go out the member link that is paired with the member link that is down.

Из него не следует вывод, что нельзя организовывать L3 связность поверх vPC peer-link. Это с определенными ограничениями возможно. Данное правило один из элементов построения безпетлевой топологии. Оно же и ограничивает возможное множество решений.

суббота, 17 января 2015 г.

Взаимодействие OSPF и BGP.


Недавно нашел одну любопытную особенность в BGP. Существует механизм по оптимизации редистрибьюции, известный как route tagging. Довольно широко применяется и всем надеюсь понятен. Но есть нюанс, представим, что у нас есть следующая простая топология:

R1
   |   \
             |     R3---
   |   /
R2
Маршрутизаторы R1 и R2 анонсируют несколько внешних префиксов в OSPF, а R3 редистрибьютит OSPF в BGP. При этом, наша задача отфильтровать маршруты полученные от R2, но нельзя использовать route-map на R3. Как это сделать?

Как оказалось, существует отдельный стандарт регламентирующий взаимодействие между OSPF и BGP, RFC 1364 (1992 год). Так вот, в нем указано следующее: 
      These are routes imported from routing protocols with complete
      path information and carry the AS path information as part of the
      routing information.

      The OSPF tag must be set to
                        a=1,c=1,pl=10,as=don't care

      These routes must not be exported into BGP because these routes
      are already imported from BGP into the OSPF RD. 


Таким образом, изменив route tag на роутере R2 на значение >= 3 758 096 384 (что в hex представлении равно 0xE0000000). Мы, согласно озвученному правилу, предотвратим дальнейшую редистрибьюцию подсетей в BGP.

суббота, 4 октября 2014 г.

E1 vs. E2


Этот вопрос отлично разжевал Брайан в своей статье "Understanding OSPF External Route Path Selection". Для себя попробую изложить её содержимое тезисно и кратко.

Первое, вне зависимости от метрик и AD, OSPF всегда выбирает маршруты в следующем порядке:

    1. Intra-Area (O)
    2. Inter-Area (O IA)
    3. External Type 1 (E1)
    4. External Type 2 (E2)
    5. NSSA Type 1 (N1)
    6. NSSA Type 2 (N2)
В случае E1, внешняя метрика напрямую суммируется с внутренний, это суммирование подразумевает сравнимость внутренних и внешних маршрутов. Обычно E1 используется в рамках одной AS для редистрибьюции сетей из разных процессов маршрутизации. При использовании же E2, наоборот, решение о next-hop будет принято только на основе внешней метрики и лишь при равенстве оных, внутренняя стоимость будет играть роль.

четверг, 25 сентября 2014 г.

DPD и Split Tunneling.

Кстати, именно при работе с DPD мы столкнулись с новым циско багом. В нашей компании применялась следующая конфигурация EzVPN:

crypto ipsec client ezvpn PRIMARY
  connect auto
  group PRIMARY key <removed>
  local-address FastEthernet0/0
  mode network-extension
  peer A.A.A.A default
  peer B.B.B.B
  virtual-interface 1
  xauth userid mode interactive

Ключевое слово default после адреса VPN пира, активирует фичу под названием Reactivate Primary Peer. Из документации становится ясно, что данная настройка позволяет с помощью DPD обнаружить неактивный пир, переключиться на резерв, а после восстановления основного, вернутся на него. Красиво? Красиво! Но почему-то не работает в связке со split-tunneling'ом. Точнее переключение происходит, но статические маршруты образованные в результате работы split-tunneling'а пропадают.

Такая вот багофича.




вторник, 23 сентября 2014 г.

DPD, Dead Peer Detection.

crypto isakmp keepalive

Итак, DPD или Dead Peer Detection, что же это такое? Как видно из названия, это механизм обнаружения неработающего пира в рамках IKE и IPSec. Но механизм признаться чудной.

DPD был призван решить проблему периодических keepalive, которые при значительном числе spoke роутеров могут вызвать проблемы на центральных VPN-хабах. Да и вообще, это как-то не комильфо и требует внимания к интервалам keepalive запросов.

Стандартизированный в RFC 3706 протокол обнаружения "залипших" пиров, избавлен от этого недостатка и в сути своей непериодичен и асинхронен. А всё потому, что главным критерием определения нерабочего пира является собственно простой установленной IPSec сессии.

Но как это работает?


пятница, 12 сентября 2014 г.

MAC-адреса и свитчи.



Для чего нужны mac-адреса свитчу? По мимо userspace адресов есть несколько типов необходимых для обеспечения функционирования L2 сегмента. Их можно выделить в несколько групп:

  • Адреса портов, жестко привязаны каждый к своему порту и применяются только для передачи сontrol plane информации. Т.е. выступают в качестве source address для BPDU и CDP сообщений, и тому подобному.
  • Адреса общего назначения, используются в более абстрактных штуках (BID для STP, MAC для SVI и т.д.). Количество их зависит от модели коммутатора.
  • Специализированные адреса протоколов, например CDP, LLDP, 802.1x, OAM и различные версии STP. При получении фрейма с таким адресом в качестве назначения, свитч должен будет произвести его обработку направив в CPU.

пятница, 22 августа 2014 г.

Что делает qos pre-classify?

Иногда встречаются недопонимания этой команды. По сути, pre-classify позволяет использовать данные из оригинального IP заголовка для обеспечения QoS в IPSec VPN окружении. Под данными здесь подразумевается не просто значение ToS байта, которое по умолчанию будет скопировано в IPSec, а остальные заголовки оригинального пакета. По сути, эта информация извлекается и передается в исходящий интерфейс параллельно с уже зашифрованным пакетом. Что соответственно позволяет использовать её для service policy.

Стоит учитывать, что pre-classify используется только на spoke роутерах и эффективно ограничивает лишь исходящий трафик. Со стороны же центрального vpn-концентратора, традиционно советуют реализовывать per-tunnel qos policy.

воскресенье, 6 июля 2014 г.

Петли и MPLS

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

  • Построением loop-free окружения занимается лежащий в основе MPLS сети протокол динамической маршрутизации, например OSFP или IS-IS.

Этого должно хватить, такой вариант даже в экзаменационных тестах встречается. Но если появляется желание как следует разобраться в вопросе, то:
  • Простейшее дополнение: MPLS заголовок имеет поле TTL значение которого копируется из оригинального IP заголовка (или не копируется в случае no mpls ip propagate-ttl). Это не спасет от появления петель, но позволит справиться с их последствиями.
  • Сложное дополнение: может показаться надуманным, но существует способ избежать кратковременных петель возникающих после падения линка. Это механизм MPLS RSVP-TE. Ему можно посвятить отдельный раздел|книгу|религию.
  • Архивные дополнения: давным-давно, во времена ATM и Frame-Relay, в MPLS успешно уживались и другие способы избавления от петель. К ним относятся Hop Count TLV, Path-Vector TLV и алгоритм Coroled Thread.


среда, 19 марта 2014 г.

Быть или не быть, succesor или feasible succesor?


Всем известный алгоритм DUAL позволяет протоколу EIGRP получать оптимальную, свободную от петель топологию. В русскоязычных блогах ему обычно уделяется не так много места, типа вот так:
Если маршрут через successor становится недействительным (изменилась топология) или у соседа изменилась метрика, DUAL проверяет, есть ли для данного маршрута feasible successor.
Если feasible successor есть, DUAL использует его в качестве successor-а, что позволяет избежать перерасчет маршрута.
Если feasible successor-а для маршрута нет, производится перерасчет маршрута. Хотя перерасчет не сильно загружает процессор, он занимает определенное время, поэтому желательно избегать ненужных перерасчетов.
На первый взгляд всё так и есть. Но если попытаться разобраться в том, как работает DUAL, станет понятно, что данное описание неполно. Рассмотрим следующую топологию в качестве примера:

вторник, 11 марта 2014 г.

Редистрибуция в IPv4 и IPv6.

Нюансы, нюансы.
Если в OSPFv2 мы решим редистрибутить сети из соседнего EIGRP, то ввод команды "redistribute eigrp 1 subnets" приведет к запуску следующего процесса:
  • Все маршруты имеющиеся в show ip route eigrp станут кандидатами для редистрибуции. 
  • Все connected сети на интерфейсах которых работает eigrp так-же будут редистрибутированы.
А вот в IPv6 окружении, несколько иначе. Собственно само различие весьма небольшое, по умолчанию не будут подвержены редистрибуции connected сети, для их включения в него создан ключ include connected. Поведение этого механизма несколько отличается в раличных версиях IOS и для протоколов, особенно это касается BGP.

среда, 12 февраля 2014 г.

Оптимизация SPF в OSPF.


Как известно, в OSPF для нахождения кратчайших intra-area маршрутов используется алгоритм Дейкстры. Он же используется и в IS-IS, тем не менее эти протоколы по разному реагируют на изменения топологии. Так, добавление нового stub-роутера или изменение/добавление ip-адреса, приводит в случае OSPF (имеем в виду v2 если не указано обратное) к полному пересчету SPT. Однако, в случае IS-IS такого не происходит. Отчего и почему рассмотрим далее.

пятница, 7 февраля 2014 г.

Cisco и таблица маршрутизации.

sh ip route

Известная всем команда выводит текущение содержимое таблицы маршрутизации. Но стоит задуматься, откуда там появляются маршруты? Как они удаляются оттуда? Что вообще черт побери происходит? Рассмотрим ответы на эти вопросы далее.

вторник, 4 февраля 2014 г.

Познакомимся поближе с virtual-link

Virtual-link?

Общее предназначение виртуал-линков думаю всем известно. Обычно ими соединяют разделенную нулевую область или присоединяют "оторванную" область к нулевой через транзитную. Но это только одно из предназначений, про другое обычно забывают.

Рассмотрим следующую топологию:



воскресенье, 2 февраля 2014 г.

LSA четвертого типа в OSPF. Откуда?

Откуда же берутся LSA 4 в OSPF? Их назначение известно хорошо, т.к. LSA 5 проникают сразу во все области нашего OSPF, требуется как-то находить источник внешних маршрутов. Довольно часто встречается ошибочное мнение (например в статьях на хабре), что ASBR генерирует LSA 4 прямо совместно с LSA 5. Что есть совсем неправда. Рассмотрим простую топологию:

MPLS VPN, OSPF PE-CE Protocol



Введение.

Рассмотрим несколько особенностей OSPFv2 как PE-CE протокола в MPLS VPN окружении. Для этого нам понадобится горсть различных роутеров да немного энтузиазма.
Итак, зачем же нам именно MPLS VPN? Почему просто не экспортировать маршруты в обычный BGP бэкбон? Это действительно можно сделать, но проблема в том, что BGP не сохранит значение route type, что в конечном итоге приведет к экспорту нашего маршрута в целевой OSPF с типом «внешний». Казалось бы, что в этом плохого? А вот целый список минусов такого подхода: