Category Archives: Linux

Использование Source Specific Multicast (SSM) (IGMPv3)

Введение (можно пропустить)

Отличие Source Specific Multicast от “обычного”(Any Source Multicast(ASM)) в его сигнализации и фильтрации. Формально, существует 3 модели распространения multicast – ASM, SFM(source filtered multicast) и SSM. Но в действительности, с точки зрения запроса мультикаст-трафика со стороны клиента, SSM можно рассматривать как частный случай SFM. Модель SSM подразумевает, что мультикаст группы принадлежат к диапазону адресов 232.0.0.0/8, а IGMPv3 exclude mode запросы не отправляются клиентом и игнорируются свитчами и роутерами, их обрабатывающими.

В классическом варианте, внутри сети оператора используется протокол PIM для распространения мультикаста между роутерами, при этом задействуются RP(точка(и) рандеву) для регистрации источников (S,G) и получения информации о них роутерами, у которых клиенты запросили мультикаст. Использование IGMPv3 в режиме include mode и отказ от exclude mode позволяет избавиться от этих RP, что упрощает конфигурацию сети и, вообще говоря, повышает надёжность(за счёт понижения сложности). Использование адресов 232.0.0.0/8 позволяет роутерам понять что от них хотят, когда вещают или запрашивают мультикаст от них. Получая такой мультикаст(data-трафик), роутер знает, что его не надо регистрировать на RP (сеть может быть смешанная и использовать 1, 2 или 3 модели распространения multicast), а получая IGMPv3 запрос от клиента(include mode) на запрос канала из сети 232.0.0.0/8, роутер не пытается его интерпретировать как ASM с фильтром(т.е. SFM), а сразу шлёт PIM JOIN для построения SPT, если канал (S,G) ранее не был подключен. В терминологии SSM канал определён как (S,G). В общем случае(в зависимости от оборудования) можно изменить диапазон адресов, относящийся к SSM.

IGMPv3 клиент и генератор multicast

Рассмотрим IGMPv3 в контексте CE-устройства, т.е. как запросить SSM по IGMPv3 и как его обработать. Continue reading

Advertisements

VXLAN в Linux (unicast mode)

VXLAN это L2 over L3, некий аналог mpls псевдопровода и vpls, но поверх L3 сети, без использования mpls. В последнее время, всё больше и больше вендоров склоняются именно к этому варианту L2 поверх L3, многие реализуют vxlan на аппаратном уровне.

В классическом случае, vxlan использует multicast для передачи broadcast и unknown unicast, т.е. широковещательный трафик инкапсулируется в multicast и передаётся всем маршрутизаторам, участвующем в vxlan. Пример такой конфигурации для Cisco CSR1000V можно найти здесь.

Использование мультикаст влечёт за собой очевидную проблему – ограничение области применения. Если речь идёт про public internet, то про multicast можно забыть. Однако, существует вариация vxlan, не использующая multicast, при этом vxlan либо вырождается в псевдопровод, либо требуется сигнализация, чтобы участники vxlan знали друг о друге. В этой заметке речь пойдёт именно об использовании vxlan для организации L2 точка-точка поверх L3. При написании статьи использовалось ядро linux 3.15.3 и iproute2 3.15 Continue reading

QoS в Linux: tbf (token bucket filter)

TBF является классовой дисциплиной, предназначенной для шейпинга(shaping) трафика, т.е. подразумевается наличие буфера пакетов, в отличии от полисинга(policing). В Linux дисциплина tbf имеет следующие ключевые возможности: ограничение средней и максимальной скоростей, возможность задания другой дисциплины для управления очередью(буфером пакетов), что позволяет распределить трафик внутри заданной полосы, например с помощью абсолютной приоритезации или честного(fair) распределения потоков.

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

tbf token bucket
Continue reading

QoS в Linux: pfifo, prio, tc filter, SO_PRIORITY socket

В этой заметке будут рассмотрены две дисциплины – бесклассовая pfifo(самая простая дисциплина в Linux) и классовая prio(абсолютная приоритезация). В отличии от pfifo_fast, дисциплина prio имеет возможность параметризации – задание количества очередей(bands) и priomap(маппинг Linux Priority(LP) в очередь), а также (ввиду того, что prio является классовой дисциплиной) позволяет применить какую-либо другую дисциплину к каждой своей очереди, например для различных очередей можно задать разные значения размера буфера(длины очереди), ограничить по полосе или сделать “справедливое”(fair-queue) распределение трафика между потоками(tcp/udp/icmp-flows) внутри очереди.

С помощью tc filter будет продемонстировано каким образом можно поместить трафик(например, по критерию l4protocol=icmp) в определённый класс(в случае prio, номер класса однозначно соответствует номеру очереди). Кроме того, будет показано как можно устанавливать LP(linux priority) или tc class непосредственно из локального приложения (для языков программирования C и PHP(условно недокументированная возможность)). Continue reading

QoS в Linux: 802.1p, net_prio cgroups

В реальной сети трафик окрашивается тремя способами – IPv4/IPv6 TOS(DSCP), MPLS TC Field (старое название MPLS EXP bits) и 802.1p. Поскольку mpls на текущий момент отсутствует в ванильном ядре, вопрос об окраске mpls-трафика на Linux пока нет смысла рассматривать.

В прошлой заметке было рассказано о том, как linux priority(он же internal priority или skb->priority) может быть использован для приоритезации трафика((!) а не раскраски его). В этой заметке будет рассмотрен вопрос о том, каким образом можно использовать linux priority(далее LP) для установки 802.1p(окраска трафика на втором(ethernet) уровне), а также будет показано как можно установить LP для конкретного локального процесса средством net_prio cgroup(а не с помощью классификации по типу трафика).

Использование 802.1p актуально, как минимум, в двух случаях:
– коммутатор, к которому подключен сервер(или где-то дальше) не умеет учитывать TOS/DSCP
– для раскраски non-IP трафика (например pppoe, arp)
Continue reading

QoS в Linux: поведение по умолчанию: pfifo_fast, mq

Этой заметкой начинается цикл статей на русском языке о QoS в Linux с актуальностью на момент времени 2014Q2. Базовой user space утилитой для управления трафиком является tc(traffic control), документация к которой устарела и содержит неточности. Различные HOWTO в большинстве своём датируются началом 2000-ых годов. Единственным достоверным источником о том как оно работает являются исходники ядра. Предполагается, что читатель владеет такими понятиями как классификация, маркировка, планирование(scheduling).

В качестве linux-дистрибутива будет использоваться Ubuntu 14.04(ядро 3.13.0-24-generic, но в один момент будет заменено на 3.14.1-031401-generic)

В Linux управление трафиком сосредоточено на исходящих интерфейсах, что вполне логично, поскольку напрямую мы не можем влиять на то, сколько трафика приходит на интерфейс; управление входящим трафиком, вообще говоря, может быть осуществлено только косвенно. По отношению к входящему(ingress) трафику тоже можно применять некоторые действия(в основном, policing, т.е. тупое удаление лишнего трафика), но в данной заметке это рассмотрено не будет. В действительности, для применения более сложных методов(чем простое удаление лишнего трафика) по отношению к входящему трафику существует два подхода – использование виртуальных интерфейсов ifb(с перенаправлением входящего трафика на ifb, а с ifb уже на исходящий интерфейс) или управление трафиком на исходящем интерфейсе(второй способ неудобен тем, что может быть два активных исходящих интерфейса и тем, что требуется классификация входящего трафика(в случае ISP, это уметь классифицировать абонента)). Таким образом, достаточно научиться управлять исходящим(egress) трафиком. Continue reading

Маршрутизация multicast в Linux

В современных реалиях, скорее всего, нет смысла заниматься маршрутизацией(репликацией) multicast-трафика с помощью софтроутеров(будь то ядро Linux или что-то иное). Причина довольно простая – даже дешёвые свитчи умеют L2/L3-multicast(хоть и с ограничениями по количеству групп/маршрутов, но всё же это делается в asic-ах). Однако, существует ряд задач, которые могут быть не решены в “железе” (нет поддержки со стороны ПО/невозможно реализовать ввиду возможностей asic), например ренамберинг(изменение destination ip), внесение случайных задержек(перемешивание), отправка multicast в тунель, резервирование источника по произвольному критерию.

Зачем может потребоваться ренамберинг мультикаст группы? Во-первых, маппинг IP-mac неодназначен(например, группам 238.1.1.1 и 239.1.1.1 соответствует один и тот же mac-адрес), что может вызвать проблемы в L2-сегменте. Конечно, такая коллизия маловероятна, однако возможна, когда вы берёте multicast из разных внешних источников(в принципе, IP-адреса могут даже полностью совпасть). Во-вторых, вы можете захотеть скрыть свой источник, изменив и destination и source адрес. В destination может быть “спрятан” номер AS источника(RFC3180), по source тоже можно догадаться об источнике, если он не серый. В третьих, перенумеровать группу может потребоваться для избежания коллизии на оборудовании, где заканчивается TCAM под multicast (как временное решение до замены оборудования/изменения схемы сети). И наконец, вы решили зарезервировать ТВ-каналы путём их получения из разных источников(т.е. вливать на сервер 2 разных группы(но одинаковых по контенту) и забирать из него одну, результирующую(работающую))

Внести случайную задержку(reordering) или потери может потребоваться для проверки поведения используемых STB/soft-плееров. Например, вам интересно, как будет выглядеть картинка, если где-то на сети мультикаст пройдёт через per-packet балансировку и не зависнет ли плеер при наличии потери пакетов, будут ли издаваться неприятные скрипящие звуки или же просто квадратики и тишина. Continue reading