Метка «маршрутизация»

Поднимаем VPN туннель из мира домой в обход NAT

Хочу рассказать вам про то как имея в интернете свой VPS-сервер можно поднять туннель в домашнюю сеть. И не платить при этом за статический IP провайдеру, и даже находясь за NAT, все равно сделать доступными в интернете свои домашние сервисы.
Читать полностью »

1. Введение в листы префиксов


Для управления обменом маршрутной информацией, ее приемом, отправкой или перераспределением, в Cisco IOS можно использовать различные методы фильтрации маршрутных обновлений, такие как листы распределения (distribute-list) и листы префиксов (prefix-list).
Использование листов распределения обладает определенными недостатками, такими как:

  • ACL (Access-List, листы управления доступом), используемые в листах распределения, изначально разрабатывались для фильтрации пакетов, а не для фильтрации маршрутов
  • Невозможность определения совпадения маски маршрута
  • Работа ACL достаточно мелена, так как они последовательно применяется к каждой записи в маршрутном обновлении
  • Использование расширенных ACL может оказаться громоздким для конфигурирования

Листы префиксов разрабатывались как альтернатива использованию ACL, их можно использовать во множестве команд предназначенных для фильтрации маршрутов.
Читать полностью »

1. Введение в ODR – On-Demand Routing


Прежде чем изучать технологию ODR, давайте вспомним два основных метода наполнения таблиц маршрутизации информацией:

  • Статическая маршрутизация – маршруты добавляются вручную администратором.
  • Динамическая маршрутизация – администратор настраивает протоколы динамической маршрутизации.

Но в каждом из этих случаев есть недостатки:

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

В принципе нельзя сказать что эти недостатки существенны в современных условиях. Навряд ли сети будут переконфигурироваться часто, современные каналы связи достаточно широки, что бы без проблем передавать относительно небольшой трафик, генерируемый протоколами маршрутизации. И даже проблему внешних динамических IP адресов, получаемых от провайдера можно решить путем использования технологии динамического DNS.
Но на самом деле есть еще один недостаток, общий для обоих вариантов – вам нужен обслуживающий персонал в каждой точке, где стоит маршрутизатор. Тот, кто будет прописывать статические маршруты или настраивать протокол динамической маршрутизации.
Именно для таких случаев компания Cisco разработала проприетарный протокол ODR, который по сути даже не является протоколом динамической конфигурации, это расширение еще одного проприетарного протокола – CDP. С помощью протокола ODR маршрутизаторы могут обмениваться маршрутной информацией специфическим образом (в результате объем передаваемой информации существенно меньше, чем у других протоколов динамической маршрутизации), и при этом конфигурация всех маршрутизаторов сети не требуется. Настраивается только один маршрутизатор – основной маршрутизатор компании, все остальные маршрутизаторы не требуют вообще никакой настройки маршрутизации, ни статической, ни динамической.
Таким образом, получается, что ODR не обладает выше указанными недостатками:

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

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

image
Пример XLS-таблицы, которая используется до внедрения системы – и отлично подходит в качестве источника первичных данных.

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

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

Фактически, задача сводится к двум:

  • Обобщенной задаче коммивояжера (TSP).
  • И построению оптимального расписания-плана.

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

Спасибо Хабру, много полезного тут для себя нашел. Думаю, пора «отдавать долги».
Хочу описать алгоритм, который работает больше года на моем шлюзе для балансировки каналов (Гбит трафика, 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.

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

137 тысяч километров сети с общей пропускной способностью 8 Тб/с
Прокладка кабеля в грунт.

137 тысяч километров сети с общей пропускной способностью 8 Тб/с
Стойки с магистральным оборудованием DWDM

Привет!
Я планирую магистральные сети «ВымпелКома» — куда идти, что строить и так далее. Сразу предупрежу – города для нас это как «материальные точки», внутри работают другие люди. В них мы заглядываем только для того, чтобы добраться до своих магистральных узлов.

Протяженность магистральной сети — 137 тысяч километров, пропускная способность уже более 8 Тб/с. Сейчас мы уже перешли Урал, находимся в Сибири, переходим Красноярск и планируем добраться до Читы.

Ниже — ещё фото, рассказ про оборудование и действия при обрывах. Читать полностью »

BGP community routing policy

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

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

Если кто ещё не знает, то 2ГИС — это бесплатный справочник организаций с картой города. И если про справочник уже написано много, то про карту и её возможности информации меньше. А рассказать есть чего. Например, про роутинг — почему мы не взяли существующие решения, а написали своё или зачем нужен единый алгоритм построения в разных продуктах.

Создание единого роутинга в офлайн и онлайн продуктах 2ГИС
Читать полностью »

С каждым днем сайты становятся все сложнее и динамичнее. Уже недостаточно просто «оживить» интерфейс — все чаще требуется создать полноценное одностраничное приложение. Ярким примером такого приложения является любая web-почта (например, Mail.Ru), где переходы по ссылкам приводят не к перезагрузке страницы, а только к смене представления. А это значит, что задача получения данных и их отображения в зависимости от маршрута, которая всегда была прерогативой сервера, ложится на клиент. Обычно эту проблему решают с помощью простенького роутера, на основе регулярных выражений, и дальше не развивают, в то время как на back-end этой теме уделяют гораздо больше внимания. В этой статье я постараюсь восполнить этот пробел.

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

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


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