Если с отдачей трафика все в принципе понятно, то контролировать ситуацию откуда пойдет входящий трафик намного сложнее. Для управления входящим трафиком мы должны влиять на принятие решения куда направлять трафик, по какому пути, маршрутизатора удаленной системы. Вообще то, актуальными параметрами влияющими на то куда пойдет трафик являются:
1. LocalPreferences – на удаленной автономной системы на этот параметр мы повлиять ну никак не сможем.
2. Длительность и стабильность bgp сессии отвечающей за маршрут
3. Размер сети. Чем меньше размер сети тем выше ее приоритет в таблице роутинга.
4. Количество автономных систем которые нужно пройти пакету для достижения автономной системы назначения. То есть длина AS-PATH.

Фактически повлиять мы можем только на поледние 2 пункта и если размер анонсируемой сети мы можем контролировать только в нескольких случаях, то длину AS-PATH нам контролировать проще. На этом методе мы и остановимся.
Читать далее »

Q-in-Q, так же это называют dot1q tunneling, это система двойного тегирования вланов. То есть, допустим у нас есть канал на некую техплощадку, на которой подключены клиенты, клиенты должны быть изолированы друг от друга с помощью vlan, но транспорт не позволяет обеспечить нужное количество вланов на каждого клиента, а владельцы транспорта дают один влан и как говорится крутись как хочешь. Вот для таких случаев замечательно подходит dot1q тунелирование, когда внутрь одного влана на входе упаковываются вланы, а на выходе транспорта распаковываются. Остается добавить, что не все виды коммутаторов поддерживают Q-in-Q, среди коммутаторов Cisco поддерживают Q-in-Q 35хх, 37xx, 45xx. Среди продуктов D-Link поддерживает Des-3825, тут Q-in-Q называется Double Vlan. И все коммутаторы производства ExtremeNetworks, они называют эту технологию vMan.
Читать далее »

Иногда выпадают такие нетривиальные задачи. Если вы обеспечиваете клиентам транспорт по второму уровню, объеденение оффисов и тому подобное, то мониторить работоспособность можно только с помощью подсчета маков во влане. Метод достаточно неточный, поскольку авария может уже случится, а мак еще может хранится в таблице. Но тем не менее, бывают такие клиенты, которых нужно хоть как то мониторить.
Я использую такую команду:

/usr/local/bin/snmpwalk -Os -c netstat@501 -v 1 192.168.5.5 .1.3.6.1.2.1.17.4.3.1.1

Здесь 192.168.5.5 – адрес свитча,
501 – номер влана который мониторится, а .1.3.6.1.2.1.17.4.3.1.1 – MiB котрый выводит маки которые присутствуют в этом влане.
Результат будет такой:

mib-2.17.4.3.1.1.0.20.169.37.168.40 = Hex-STRING: 00 A4 C9 25 D8 38 
mib-2.17.4.3.1.1.0.30.122.229.194.156 = Hex-STRING: 00 1F 7C E5 C5 9C

Как есть два мака, по одному с каждой стороны транспорта.
На свитчах отличных от catalyst 3750 этот MiB я не проверял, гарантировать что будет работать не могу.

Централизованная авторизация через radius server имеет ряд неоспоримых достоинств. Если у вас обслуживанием оборудования занимается несколько человек и штат сотрудников время от времени меняется, а не меняться он не может, то правильней всего завести один источник авторизации на котором можно завести пользователя или заблокировать одним движением, а не обходя оборудование по кругу и блокируя аккаунты. Во вторых источником авторизации может служить все что угодно, радиус сервера могут обращаться к SQL базам, к хранилищу в виде простого файла, и наконец к PAM, как мы сегодня и настроим.
Почему я выбрал авторизацию через PAM? Да просто потому что так исторически сложилось. И система мониторинга авторизуется через апачевский mod_auth_pam.
Читать далее »

В своем предыдущем примере мы рассматривали модель, когда по резервному каналу у нас приходит маршрут по умолчанию, схема эта вполне рабочая и жизнеспособная. Но есть одно но, я об этом уже писал, весь паразитный трафик к несуществующим адресам будет уходить на этот канал, то есть туда будет уходить паразитный, безсмысленный трафик. Вполне логично что это не совсем хорошо. То есть конечно можно работать и так, но все же. Если позволяет оборудование(маршрутизаторы), лучше всего принять два фуллвьюва и тут сбалансировать с помощью такой штуки как local-preference. Вот эту модель мы и рассмотрим. За основу берем прежнюю схему известную нам по статье BGP – route-map, as-path, prefix-list. Управляем анонсами. Мы оставляем по прежнему роутер C резервным, а роутер B приоритетным каналом, но через роутер С мы теперь примем полный список сети и сбалансируем отдачу в роутер B c помощью local-preference.
Читать далее »

Есть в портах FreeBSD полезная утилита bgpq, автор ее Александр Снарский и предназначена она для того, что бы облегчить жизнь системному администратору. Эта утилита незаменима, если вы управляете транзитной автономной системой у которой насчитывается больше десятка клиентов с которыми построены bgp сессии. Утилита эта автоматически строит префикс листы базируясь на номере автономной системы клиента. Такая автоматизация позволит вам забыть о том, что клиент может получить еще несколько префиксов(сетей) и забыть вам об этом сообщить, а потом включить на новые префиксы своих уже клиентов и удивляться что ничего не бегает.
Читать далее »

При построении взаимодействия с аплинками(провайдерами) и даунлинками (клиентами), есть несколько правил которые нужно соблюдать. Во первых нельзя принимать и отдавать анонсы «серых сетей» – тех сетей которые выделены для использования внутри локальных сетей, для этого на вход и исход следует применить такой префикс лист:

ip prefix-list GREY seq 10 deny 10.0.0.0/8
ip prefix-list GREY seq 20 deny 172.16.0.0/12
ip prefix-list GREY seq 30 deny 192.168.0.0/16

Второй важный момент заключается в том, что анонсировать наружу сети менее /24 запрещено, поэтому без особой нужды принимать анонсы и отдавать анонсы меньших сетей нельзя, вот мы их и обрежем таким префикс листом:

ip prefix-list LOW-NET-DENY seq 20 permit 0.0.0.0/0 le 24

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

С точки зрения BGP интернет представляет из себя совокупность автономных систем взаимодействующих между собой. При этом можно разделить два вида автономных систем, это транзитные, через которые проходит путь к другим автономным системам и тупиковые, которые только принимают маршруты, но не ретранслируют маршруты к другим автономным системам. Как мы уже говорили, все маршруты которые приходят от партнеров по BGP, будут, по умолчанию, переданы и другим партнерам. Но если у вас тупиковая автономная система, предоставляющая доступ к интернет своим клиентам в своем адресном пространстве, то анонсы пришедшие от внешних автономных систем передавать не нужно, для этого нужно используя директиву route-map установить фильтр на исходящие анонсы используя директиву as-path.
Читать далее »