Рубрика «BGP» - 9

Спасибо Хабру, много полезного тут для себя нашел. Думаю, пора «отдавать долги».
Хочу описать алгоритм, который работает больше года на моем шлюзе для балансировки каналов (Гбит трафика, 8k клиентов, 2 провайдера, AS на 1k адресов, большинство клиентов за NAT). Возможно, кому-то пригодится. Во всяком случае, ничего похожего не встречал и когда специально искал — не нашел. Так что полностью мое детище.
Конечно, указанный алгоритм нельзя считать универсальным, подойдет только в подходящих условиях.

Итак, исходные:
— Шлюз на Linux (Debian 6). Используется пакет quagga (бывший zebra).
— Два провайдера (пусть будут ТТК и РТК). Каждый дает канал определенной толщины, «лишнее» режет.
— AS на 1k адресов (пусть будет 1.1.144.0/22). AS0000.
— Большинство клиентов имеют серые адреса (пусть будет 192.168.0.0/16), «клиентские» сети 192.168.1-99.0/24, на шлюзе натятся.
— Небольшая часть клиентов имеют белые адреса в пространстве моей AS.

Задача:
Обеспечить равномерную загрузку каналов ТТК и РТК входящим трафиком для исключения перегрузки каналов.
Читать полностью »

До сих пор мы варились в собственном соку – VLAN’ы, статические маршруты, OSPF. Плавно росли над собой из зелёных студентов в крепких инженеров.
Теперь отставим в сторону эти игрушки, пришло время BGP.

Сегодня мы

  • Разбираемся с протоколом BGP: виды, атрибуты, принципы работы, настройка
  • Подключаемся к провайдеру по BGP
  • Организуем резервирование и распределение нагрузки между несколькими линками
  • Рассмотрим вариант резервирования без использования BGP – IP SLA

Читать полностью »

BGP community routing policy

В этой статье пойдёт речь об использовании атрибута community протокола BGP для управления анонсированием сетей. Статья будет полезна новичкам в BGP, имеющим базовое представление об этом протоколе. Тут не будет листингов с конфигами, которые всё равно никто не читает, да и у разных вендоров они отличаются, но будет объяснение принципов и возможностей использования community.

Читать полностью »

Миллион PPS в секунду — связанность и балансировка
На последней конференции РИТ++ мне посчастливилось стать впервые докладчиком конференции такого масштаба и такой значимости. В этой статье я не просто хочу пересказать всё, о чём я докладывал. Выступать впервые перед такой большой аудиторией для меня было непривычно и я половину забыл рассказать, нервничал немного. Речь пойдет о создании с нуля собственной отказоустойчивой структуры для веб-проектов. Мало кому из системных администраторов дается возможность с нуля запустить в production крупный проект. Мне повезло.

Как я уже написал, я не смог рассказать всё, что планировал со сцены, в этой статье я восполню эти пробелы, да и для того, кто не смог там присутствовать — это будет приятно, видео с конференции так и не дали бесплатно всем. Да и стать пользователем Хабра я хотел давно, вот только не было времени. Майские праздники дали время и силы. Статья будет не столько технической с кучей конфигов и графиков — статья будет принципиальная, все пробелы мелких технических вопросов можно будет восполнить в комментариях.
Читать полностью »

Привет! Моя первая статья и в ней я хочу представить небольшую лабораторную работу по конфигурации протокола BGP (Border Gateway Protocol) на маршрутизаторах Cisco. Многие из вас слышали что такое BGP, но не всем довелось опробовать данный протокол на практике. Именно для них и будет интересна данная лабораторная работа.
В статье будет мало теории, поэтому для тех кто впервые слышит о BGP отправляю сначала посетить это, это или, собственно, это.
Читать полностью »

Недавно в интернетах вызвала бурное обсуждение информация, что The Pirate Bay захостился в Северной Корее и это якобы подтверждалось трассировкой и таблицами BGP. Довольно скоро появилось опровержение (1, 2) с подробным техническим разбором. Изначально я хотел перевести статью по ссылке, но решил написать свою, с исследованием ситуации.
Что же всё таки случилось с TPB
Читать полностью »

В сети любого большого content/eyeball провайдера возникает необходимость управления трафиком. И чем больше сеть, тем острее эта необходимость ощущается. В этой статье я попытаюсь описать основной принцип управления трафиком в сети компании, непосредственное отношение к которой я имею. Сразу оговорюсь, что в этой статье упоминается множество торговых марок, терминов и «жаргона». Здесь не будет ни примеров конфигурации роутеров, ни описания этих самых терминов.

Мы привыкли считать, что транспортная MPLS-сеть необходима, в основном, для applications, которых существует множество: L3VPN, L2VPN/VPLS, и т.д. О Traffic Enigineer'инге в сетях MPLS вспоминают или от «хорошей» жизни, или, скорее, теоретически.

Также принято считать, что backup capacity — это роскошь и, как правило, кариеры/транспортники биллят за backup-порт также, как за обычный. Назревает резонный вопрос: зачем покупать капасити, которые будет просто простаивать и, возможно, несколько раз в месяц на короткое время использоваться? Но, с другой стороны, говорить о том, что «backup'ы для трусов» тоже нельзя, backup'ная емкость должна быть. Как же быть? Об этом и пойдет речь в статье.

Читать полностью »

Использование BGP при наличии двух каналов в Интернет для выборочного анонсирования

Вводные данные

При наличии двух собственных подсетей /24, столкнулся с необходимостью стандартной работы BGP, и погуглив, обнаружил минимальное количество информации по этой теме. На просторах рунета, в основном рассматриваются случаи, когда имеется одна сетка /24, и 2 провайдера, один из которых используется, как резервный. Да даже и этот случай рассмотрен некорректно, либо разрознено, нормально встретил описания только на англоязычных ресурсах.

Сразу же оговорюсь — рассматриваемые фичи CiscoOS: EXIST-MAP и NON-EXIST-MAP не поддерживаются UNIX-аналогами (типа Quagga).

В данной статье я рассмотрю два примера конфигов, исходя из следующих данных.

  1. У нас есть два канала: основной рабочий и резервный. Оба провайдера анонсируют нам дефолт. Использование обоих каналов для нас нежелательно. Мы, в свою очередь, будем анонсировать им свои подсети, но если жив основной канал — анонс наших префиксов в резервный канал мы принудительно запретим, и будем анонсировать, только в случае падения рабочего канала
  2. У нас есть два рабочих канала. И нам необходимо, чтобы через первый канал всегда работала (анонсировалась) наша первая подсеть, а через второй канал — наша вторая подсеть. Оба провайдера при этом анонсируют нам дефолты. В случае, если падает один из каналов — мы переносим анонс с этого канала, на оставшийся в живых. При возобновлении работы упавшего канала — возвращаем анонсы в начальный вид — по одной подсети через каждого провайдера

Теория:
Читать полностью »

Дано:
• Крупная корпоративная сеть на базе разнообразных железок Cisco с развернутым MPLS/VPN.
• PI блок адресов /22, в котором есть незанятая сеть /24, BGP пиринг с провайдерами.
• Несколько доступных из интернета ресурсов, падение которых несет либо репутационные, либо прямые финансовые потери. Соответственно, есть риск атаки на них, а каналы в интернет хоть и широкие, но вовсе не резиновые. В нормальной ситуации трафик от/до этих ресурсов копеечный, несколько мегабит.
• Некий очень ленивый сетевик, который не хочет, чтобы его будили посреди ночи из-за каких-то там атак.

Требуется подготовить сеть к тому, чтобы при атаке трафик мгновенно перемаршрутизировало через одну из компаний, предоставляющих защиту от DDoS.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js