Главная страница » Как с роутера bgp раздать ip адреса

Как с роутера bgp раздать ip адреса

  • автор:

Как с роутера bgp раздать ip адреса

Для работы сети необходимо, что бы был сконфигурирован обмен маршрутной информацией VRF между всеми PE маршрутизаторами. Для этого требуется настроить протокол маршрутизации MP-BGP.

Первым шагом назначаем номер автономной системы:

Router_B(config)#router bgp 1.

Назначаем идентификатор для BGP. Обычно это, как в нашем случае, адрес интерфейса Loopback0:

Router_B(config-router)# bgp router-id 192.168.254.39.

Отключаем одноадресатные аносы префиксов протокола IP v4. Теперь BGP будет переносить только информацию о VRF:

Router_A(config-router)# no bgp default ipv4-unicast.

Описываем соседа по протоколу BGP. IP адрес 192.168.254.40 принадлежит маршрутизатору Router_B, на котором будет настроен рефлектор маршрутной информации. Настройка рефлектора маршрутной информации будет рассмотрена ниже, а на этом этапе рассмотрим вариант точка-точка:

Router_B(config-router)# neighbor 192.168.254.40 remote-as 1.

Посылать пакеты будем от имени Loopback0:

Router_B(config-router)# neighbor 192.168.254.40 update-source Loopback0.

Поднимаемся в режим конфигурирования VPN:

Router_B(config-router)# address-family vpnv4.

Разрешаем обмен информацией с соседом 192.168.254.40:

Router_B(config-router-af)# neighbor 192.168.254.40 activate.

Разрешаем рассылку только расширенных атрибутов BGP:

Router_B(config-router-af)# neighbor 192.168.254.40 send-community extended.

При настройке маршрутизатора Router_C мы получим следующую конфигурацию.

route-target export 1:1

route-target import 1:1

ip address 192.168.254.40 255.255.255.255

ip vrf forwarding vpn_4

ip address 192.1168.12.1 255.254.255.0

ip address 192.168.253.185 255.255.255.252

ip address 192.168.253.189 255.255.255.252

address-family ipv4 vrf vpn_1

redistribute bgp 1 metric 1000 1000 1 255 1500

bgp router-id 192.168.254.40

no bgp default ipv4-unicast

neighbor 192.168.254.39 remote-as 1

neighbor 192.168.254.39 update-source Loopback0

neighbor 192.168.254.39 activate

neighbor 192.168.254.39 send-community extended

address-family ipv4 vrf vpn_1

redistribute eigrp 3

После ввода команды neighbor 192.168.254.39 send-community extended возможно отсутствие каких либо изменений в таблице маршрутизации vrf vpn_1. Протокол BGP отличается некоторой инертностью, возможна временная задержка обмена маршрутной информацией. Обмен маршрутной информацией между PE осуществляется через протокол MP-BGP. Самый простой вариант настроить соединения точка-точка между маршрутизаторами PE.За простоту приходится платить сложностью администрирования. Второй вариант заключается в настройке двух(редко более) маршрутизаторов как рефлекторов маршрутной информации. Режим рефлектора включается для каждого соседа BGP командой neighbor x.x.x.x peer-group route-reflector-client. Так как настройки для большинства соседей BGP однотипны, рекомендовано объединять соседей в группы, а уже группам присваивать необходимые настройки. В нашем случае в качестве рефлектора настроен маршрутизатор Router_C. Рассмотрим настройку протокола BGP на маршрутизаторе Router_C

Далее запускаем процесс маршрутизации BGP для автономной системы 1.

bgp router-id 192.168.254.40.

Назначаем идентификатор маршрутизатора для протокола BGP:

no bgp default ipv4-unicast.

Отключаем передачу одноадресатных анонсов протокола IPv4. Сейчас BGP будет переносить информацию только о VPN.

neighbor clients peer-group

Объявляем группу соседей clients:

neighbor clients remote-as 1.

Объявляем, что члены группы clients принадлежат автономной системе 1:

neighbor clients update-source Loopback0.

Весь обмен с членами группы clients будет происходить от адреса интерфейса Loopback0:

neighbor 192.168.253.252 peer-group clients.

Адрес 192.168.253.252 объявляется членом группы clients.

neighbor 192.168.254.39 peer-group clients

neighbor 192.168.254.45 peer-group clients

neighbor 192.168.254.254 peer-group clients

neighbor clients activate

Объявляется группа clients:

neighbor clients route-reflector-client

Для всех членов группы clients маршрутизатор Roгter_C является отражателем маршрутной информации:

neighbor clients send-community extended.

Разрешить посылать расширенные атрибуты членам группы clients.

neighbor 192.168.253.252 peer-group clients

neighbor 192.168.254.39 peer-group clients

neighbor 192.168.254.45 peer-group clients

neighbor 192.168.254.254 peer-group clients

address-family ipv4 vrf vpn_1

Произведем настройка BGP для vpn_1

redistribute eigrp 3

Настраиваем передачу информацию о маршрутах vpn_1 в процесс EIGRP 3.

address-family ipv4 vrf vpn_3

redistribute eigrp 2

Практически всю необходимую информацию о настроенных на маршрутизаторе VPN можно получить из вывода команды show ip bgp vpnv4 all.

Сети для самых маленьких. Часть восьмая. BGP и IP SLA

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

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

Сначала освежим в памяти основы протоколов динамической маршрутизации.
Бывает два вида протоколов: IGP (внутренние по отношению к вашей автономной системе) и EGP (внешние).
И те и другие опираются на один из двух алгоритмов: DV (Distance Vector) и LS (Link State).
Внутренние мы уже рассматривали. К ним относятся ISIS/OSPF/RIP/EIGRP. Нужны они для того, чтобы обеспечить распространение маршрутной информации внутри вашей сети.

EGP представляет только один протокол – BGP – Border Gateway Protocol. Он призван обеспечивать передачу маршрутов между различными сетями (автономными системами).
Грубо говоря, стык между Балаган-Телекомом и его аплинковым провайдером будет точно организован через BGP.
То есть схема применения примерно такая:

Автономномые системы – AS

BGP неразрывно связан с понятием Автономной Системы (AS – Autonomous System), которое уже не раз встречалось в нашем цикле.
Согласно определению вики, АС — это система IP-сетей и маршрутизаторов, управляемых одним или несколькими операторами, имеющими единую политику маршрутизации с Интернетом.

Чтобы было немного понятнее, можно, например, представить, что город – это автономная система. И как два города связаны между собой магистралями, так и две АС связываются между собой BGP. При этом внутри каждого города есть своя дорожная система – IGP.

Вот как это выглядит с небольшого отдаления:

В BGP AS – это не просто какая-то абстрактная вещь для удобства. Эта штука весьма формализована, есть специальные окошки в собесе, где можно в будние дни с 9 до 6 получить номер автономной системы. Выдачей этих номеров занимаются RIR (Regional Internet Registry) или LIR (Local Internet Registry).

Вообще глобально этим занимается IANA. Но чтобы не разорваться, она делегирует свои задачи RIR – это региональные организации, каждая из которых отвечает за определённую часть планеты (Для Европы и России – это RIPE NCC)

LIR’ом может стать почти любая желающая организация при наличии необходимых документов. Они нужны для того, чтобы RIR’у не пришлось напрягаться с запросами от таких мелких контор, как ЛинкМиАп.

Ну вот, например, Балаган-Телеком мог бы быть LIR’ом. И у него мы и взяли ASN (номер АС) – 64500, например. А у самого у него AS 64501.

До 2007 года были возможны только 16-ибитные номера AS, то есть всего было доступно 65536, номеров. 0 и 65535 – зарезервированы.
Номера 64512 до 65534 предназначены для приватных AS, которые не маршрутизируются глобально – что-то вроде приватных IP-адресов.
Номера 64496-64511 – для использования в примерах и документации, чем мы и воспользуемся.

Сейчас возможно использование 32битных номеров AS. Этот переход значительно легче, чем IPv4->IPv6.

Опять же нельзя говорить об автономных системах без привязки к блокам IP-адресов. На практике с каждой AS должен быть связан какой-то блок адресов.

PI и PA адреса

На самом деле PI – это Provider Independent.

В обычной ситуации, когда вы подключаетесь к провайдеру, он выдаёт вам диапазон публичных адресов – так называемые PA-адреса (Provider Aggregatable).
Получить их – раз плюнуть, но если вы не являетесь LIR’ом, то при смене провайдера придётся возвращать и PA-адреса. Тем более фактически допускается подключение только к одному провайдеру.
И если вы решите сменить провайдера, то старые адреса уйдут вместе с ним, а новый провайдер выдаст новые. Ну и где тут гибкость?

У LIR вы можете приобрести повайдеро-независимый блок адресов (PI) и обязательно ASN. В нашем случае пусть это будет блок 100.0.0.0/23, который мы будем анонсировать по BGP своим соседям. И эти адреса уже чисто наши и никакие провайдеры нам не страшны: не понравился один – ушли к другому с сохранением своих адресов.

Получить PI-адреса всегда было не очень просто. Вам нужно подготовить массу документов, обосновать необходимость такого блока итд.
Сейчас с исчерпанием IPv4 получить большие блоки становится всё сложнее. RIR их уже не выдаёт, а LIR раздают последнее.

Таким образом и номера AS и PI-адреса можно получить в одних их тех же конторах.

Предположим, что в нашем случае компания ЛинкМиАп получила блок адресов 100.0.0.0/23 и AS 64500. Возвращаясь к нашей аналогии, мы дали городу имя и снабдили его диапазоном индексов.

Так вот для того, чтобы нам из своей AS передать информацию об этих публичных адресах в другую AS (читай в Интернет) и используется BGP. И если вы думаете, что яндекс или майкрософт использует какие-то небесные технологии для подключения своих ЦОДов к Интернету, то вы ошибаетесь – всё тот же BGP.

Теперь главный вопрос, который интересует всегда новичков: а зачем BGP, почему не взять пресловутый OSPF или вообще статику?

Наверное, большие дяди могут очень подробно и обстоятельно объяснить это, мы же постараемся дать поверхностное понимание.

– Если говорить о OSPF/IS-IS, то это Link-State алгоритмы, которые подразумевают (внимание!), что каждый маршрутизатор знает топологию всей сети. Представляем себе миллионы маршрутизаторов в Интернете и отказываемся от идеи использовать Link State для этих целей вообще.

RIP, EIGRP… Кхе-кхе. Ну, тут всё понятно.

– IGP – это нечто интимное и каждому встречному ISP показывать его не стоит. Даже без AS ситуация, когда клиент поднимает IGP с провайдером, крайне редкая (за исключением L3VPN). Дело в том, что IGP не имеют достаточно гибкой системы управления маршрутами – для LS-протоколов это вообще знать всё или ничего (опять же можно фильтровать на границе зоны, но гибкости никакой).
В итоге оказывается, что придётся открывать кому-то чужому потаённые части своей приватной сети или настраивать хитрые политики импорта между различными IGP-процессами.
– В данный момент в интернете более 450 000 маршрутов. Если бы даже OSPF/ISIS могли хранить всю топологию Интернета, представьте сколько времени заняла бы работа алгоритма SPF.
Вот наглядный пример, чем может быть опасно использование IGP там, где напрашивается нечто глобальное.

Поэтому нужен свой специальный протокол для взаимодействия между AS.
Во-первых, он должен быть дистанционно-векторным – это однозначно. Маршрутизатор не должен делать расчёт маршрута до каждой сети в Интернете, он лишь должен выбрать один из нескольких предложенных.
Во-вторых, он должен иметь очень гибкую систему фильтрации маршрутов. Мы должны легко определять, что светить соседям, а что не нужно выносить из избы.
В-третьих, он должен быть легко масштабируемым, иметь защиту от образования петель и систему управления приоритетами маршрутов.
В-четвёртых, он должен обладать высокой стабильностью. Поскольку данные о маршрутах будут передаваться через среду, которая не всегда может обладать гарантированным качеством (за стык отвечают по крайней мере две организации), необходимо исключить возможные потери маршрутной информации.
Ну и логичное, в-пятых, он должен понимать, что такое AS, отличать свою AS от чужих.

Встречайте: BGP.

Вообще описание работы этого поистине грандиозного протокола мы разобьём на две части. И сегодня рассмотрим принципиальные моменты.

BGP делится на IBGP и EBGP.

IBGP необходим для передачи BGP-маршрутов внутри одной автономной системы. Да, BGP часто запускается и внутри AS, но об этом мы плотненько поговорим в другой раз.
EBGP – это обычный BGP между автономными системами. На нём и остановимся.

Установление BGP-сессии и процедура обмена маршрутами

Возьмём типичную ситуацию, когда у нас подключение к провайдерскому шлюзу организовано напрямую.

Устройства, между которыми устанавливается BGP-сессия называются BGP-пирами или BGP-соседями.

BGP не обнаруживает соседей автоматически – каждый сосед настраивается вручную.
Процесс установления отношений соседства происходит следующим образом:

I) Изначальное состояние BGP-соседства – IDLE. Ничего не происходит.

BGP находится в соcтоянии IDLE, если нет маршрута к BGP-соседу.

II) Для обеспечения надёжности BGP использует TCP.
Это означает, что теоретически BGP-пиры могут быть подключены не напрямую, а, например, так.

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

BGP-маршрутизатор (их также называют BGP-спикерами/speaker или BGP-ораторами) слушает и посылает пакеты на 179-й TCP порт.
Когда слушает – это состояние CONNECT. В таком состоянии BGP находится очень недолго.

Когда отправил и ожидает ответа от соседа – это состояние ACTIVE.

R1 отправляет TCP SYN на порт 179 соседа, инициируя TCP-сессию.

R2 возвращает TCP ACK, мол, всё получил, согласен и свой TCP SYN.

R1 тоже отчитывается, что получил SYN от R2.

После этого TCP-сессия установлена.

  • нет IP-связности с R2
  • BGP не запущен на R2
  • порт 179 закрыт ACL

На R2 не запущен BGP, и R2 возвращает ACK, что получен SYN от R1 и RST, означающий, что нужно сбросить подключение.

Периодически R1 будет пытаться снова установить TCP-сессию.

III) После того, как TCP-сессия установлена, BGP-ораторы начинают обмен сообщениями OPEN.

  • Версии протокола должна быть одинаковой. Маловероятно, что это будет иначе
  • Номера AS в сообщении OPEN должны совпадать с настройками на удалённой стороне
  • Router ID должны различаться

Получив OPEN от R1, R2 отправляет свой OPEN, а также KEEPALIVE, говорящий о том, что OPEN от R1 получен – это сигнал для R1 переходить к следующему состоянию – Established.

Вот примеры неконсистентности параметров:

а) некорректная AS (На R2 настроена AS 300, тогда, как на R1 считается, что данный сосед находится в AS 200):

R2 отправляет обычный OPEN

R1 замечает, что AS в сообщении не совпадает с настроенным, и сбрасывает сессиию, отправляя сообщение NOTIFICATION. Они отправляются в случае каких-либо проблем, чтобы разорвать сессию.

При этом в консоли R1 появляются следующие сообщения:

б) одинаковый Router ID
R2 отправляет в OPEN Router ID, который совпадает с ID R1:

R1 возвращает NOTIFICATION, мол, опух?!

При этом в консоли будут следующего плана сообщения:

После таких ошибок BGP переходит сначала в IDLE, а потом в ACTIVE, пытаясь заново установить TCP-сессию и затем снова обменяться сообщениями OPEN, вдруг, что-то изменилось?
Когда сообщение Open отправлено – это состояние OPEN SENT.
Когда оно получено – это сотояние OPEN CONFIRM.

Если Hold Timer различается, то выбран будет наименьший. Поскольку Keepalive Timer не передаётся в сообщении OPEN, он будет рассчитан автоматически (Hold Timer/3). То есть Keepalive может различаться на соседях
Вот пример: на R2 настроены таймеры так: Keepalive 30, Hold 170.

R2 отправляет эти параметры в сообщении OPEN. R1 получает его и сравнивает: полученное значение – 170, своё 180. Выбираем меньшее – 170 и вычисляем Keepalive таймер:

Это означает, что R2 свои Keepalive’ы будет рассылать каждые 30 секунд, а R1 – 56. Но главное, что Hold Timer у них одинаковый, и никто из них раньше времени не разорвёт сессию.

Увидеть состояние OPENSENT или OPENCONFIRM практически невозможно – BGP на них не задерживается.

IV) После всех этих шагов они переходят в стабильное состояние ESTABLISHED.
Это означает, что запущена правильная версия BGP и все настройки консистентны.

Для каждого соседа можно посмотреть Uptime – как долго он находится в состоянии ESTABLISHED.

V) В первые мгновения после установки BGP-сессии в таблице BGP только информация о локальных маршрутах.

Можно переходить к обмену маршрутной информацией.
Для это используются сообщения UPDATE

Разберём их поподробнее.
R1 передаёт маршрутную информацию на R2.
Первый плюсик в сообщении UPDATE – это атрибуты пути. Мы их подробно рассмотрим позже, но вам уже должны быть поняты два из них. AS_PATH означает, что маршрут пришёл из AS с номером 100.
NEXT_HOP – что логично, информация для R2, что указывать в качестве шлюза для данного маршрута. Теоретически здесь может быть не обязательно адрес R1.

  • IGP – задан вручную командой network или получен по BGP .
  • EGP – этот код вы никогда не встретите, означает, что маршрут получен из устаревшего протокола, который так и назывался – “EGP”, и был полностью повсеместно заменен BGP
  • Incomplete – чаще всего означает, что маршрут получен через редистрибьюцию

Второй плюсик – это собственно информация о маршрутах – NLRI – Network Layer Reachability Information. Собственно, наша сеть 100.0.0.0/23 тут и указана.

Ну и UPDATE от R2 к R1.

Нижеидущие KEEPALIVIE – это своеобразные подтверждения, что информация получена.

Информация о сетях появилась теперь в таблице BGP:

И в таблице маршрутизации:

UPDATE передаются при каждом изменении в сети до тех пор пока длится BGP-сессия. Заметьте, никаких синхронизаций таблиц маршрутизации нет, в отличии от какого-нибудь OSPF. Это было бы технически глупо – полная таблица маршрутов BGP весит несколько десятков мегабайтов на каждом соседе.

VI) Теперь, когда всё хорошо, каждый BGP-маршрутизатор регулярно будет рассылать сообщения KEEPALIVE. Как и в любом другом протоколе это означает: «Я всё ещё жив». Это происходит с истечением таймера Keepalive – по умолчанию 60 секунд.

Ещё один тип сообщений BGP – ROUTE REFRESH – позволяет запросить у своих соседей все маршруты заново без рестарта BGP процесса.

Подробнее обо всех типах сообщений BGP.

Полная FSM (конечный автомат) для BGP выглядит так:

Нашёл в сети подробное описание каждого шага.

Вопрос на засыпку: Предположим, что Uptime BGP-сессии 24 часа. Какие сообщения гарантировано не передавались между соседями последние 12 часов?

Теперь расширим наш кругозор до вот такой сети:
Картинки без подсетей

И посмотрим, что из себя представляет таблица маршрутов BGP на маршрутизаторе R1:

Как видите, маршрут представляет из себя вовсе не только NextHop или просто список устройств до нужной подсети. Это список AS. Иначе он называется AS-Path.
То есть, чтобы попасть в сеть 123.0.0.0/24 мы должны отправить пакет наружу, преодолеть AS 200 и AS 300.

AS-path формируется следующим образом:
а) пока маршрут гуляет внутри AS, список пустой. Все маршрутизаторы понимают, что полученный маршрут из этой же AS
б) Как только маршрутизатор анонсирует маршрут своему внешнему соседу, он добавляет в список AS-path номер своей AS.

в) внутри соседской AS, список не меняется и содержит только номер изначальной AS
г) когда из соседской AS маршрут передаётся дальше в начало списка добавляется номер текущей AS.

И так далее. При передаче маршрута внешнему соседу номер AS всегда добавляется в начало списка AS-path. То есть фактически это стек.

AS-path нужен не просто для того, чтобы маршрутизатор R1 знал путь до конечной сети – ведь по сути Next Hop достаточно – каждый маршрутизатор решение по-прежнему принимает на основе таблицы маршрутизации. На самом деле тут преследуются две более важные цели:
1) Предотвращение петель маршрутизации. В AS-Path не должно быть повторяющихся номеров

2) Выбор наилучшего маршрута. Чем короче AS-Path, тем предпочтительнее маршрут, но об этом позже

Настройка BGP и практика

В этом выпуске мы смешаем теорию с практикой, потому что так будет проще всего понять. Собственно сейчас обратимся к нашей сети ЛинкМиАп.
Как обычно, отрезаем всё лишнее и добавляем необходимое:

Внизу наш главный маршрутизатор msk-arbat-gw1. Для упрощения настройки и понимания, мы отрешимся от всех старых настроек и освободим интерфейсы.

Выше два наших старых провайдера – Балаган Телеком и Филькин Сертификат.

Разумеется, у каждого провайдера здесь своя AS. Мы добавили ещё одну тупиковую AS – до неё и будем проверять, пусть, это например, ЦОД в Интернете.

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

Мы поднимаем BGP-сессию с обоими провайдерами.
Нам важна следующая информация:
1) Номер нашей AS и блок IP-адресов. Их мы уже получили: AS64500 и блок: 100.0.0.0/23.
2) Номер AS «Балаган Телеком» и линковая подсеть с ним. AS64501 и линковая сеть: 101.0.0.0/30.
3) Номер AS «Филькин Сертификат» и линковая подсеть с ним. AS64502 и линковая сеть: 102.0.0.0/30.

При подключении по BGP в качестве линковых адресов используются обычно публичные с маской подсети /30 и выдаёт их нам вышестоящий провайдер.
Делается это по той простой причине, чтобы ваш трафик везде следовал по публичным адресам и в трассировке посередине не появлялись всякие 10.Х.Х.Х. Не то, чтобы это что-то запрещённое, но обычно-таки придерживаются этого правила.

Начнём с банального.

Настройка интерфейсов:

Теперь назначим какой-нибудь адрес на интерфейс Loopback, чтобы потом проверить связность:

Черёд BGP. Тут заострим внимание на каждой строчке.

Сначала мы запускаем BGP процесс и указываем номер AS. Именно тот номер, который выдал LIR. Это вам не OSPF – вольности недопустимы.

Теперь поднимаем пиринг.

Командой neighbor мы указываем, с кем устанавливать сессию. Именно на адрес 101.0.0.1 маршрутизатор будет отсылать сначала TCP-SYN, а потом OPEN. Также мы обязаны указать номер удалённой Автономной Системы – 64501.

Конфигурация с обратной стороны симметрична:

Уже по одному сообщению

можно судить, что BGP поднялся, но давайте проверим его состояние:

Вот они пробежали по всем состояниям и сейчас их статус Established.
Получал и отправлял наш маршрутизатор по одному OPEN и успел за это время отослать и принять уже 2 KEEPALIVE.

Командой sh ip bgp можно посмотреть какие сети известны BGP:

Пусто. Надо указать, что есть у нас вот эта сеточка 100.0.0.0/23 и передать её провайдерам?

Для этого существует три варианта:
– определить сети командой network
– импортировать из другого источника (direct, static, IGP)
– создать аггрегированный маршрут командой aggregate-address

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

Смотрим появилась ли наша сеть в таблице:

Странно, но нет, ничего не появилось. На R2 тоже.

А дело тут в том, что в ту сеть, которую вы прописали командой network должен быть точный маршрут, иначе она не будет добавлена в таблицу BGP – это обязательное условие. Конечно, такого маршрута нет. Откуда ему взяться:

Поскольку реально у нас некуда прописывать такой маршрут – кроме одного Loopback-интерфейса, нигде этой сети нет, мы можем поступить следующим образом:

Данный маршрут говорит о том, что все пакеты в эту подсеть будут отброшены. Но, не пугайтесь, нормальная работа не будет нарушена. Если у вас есть более точные маршруты (с маской больше /23, например, /24, /30, /32), то они будут предпочтительнее согласно правилу Longest Prefix Match.

И теперь в таблице BGP есть наш локальный маршрут:

Если настроить BGP и нужные маршруты на всех устройствах нашей схемы, то таблицы BGP и маршрутизации на нашем бордере (border – маршрутизатор на границе сети) будут выглядеть так:

Обратите внимание, что в таблице BGP по 2 маршрута к некоторым сетям, а в таблице маршрутизации только один. Маршрутизатор выбирает лучший из всех и только его переносит в таблицу маршрутизации. Об этом поговорим позже.
Это необходимый минимум, после которого уже будет маленькое счастье.

Условие:
Настройки маршрутизаторов несущественны. Никаких фильтров маршрутов не настроено. Почему на одном из соседей отсутствует альтернативный маршрут в сеть 195.12.0.0/16 через AS400?

Full View и Default Route

Говоря о BGP и подключении к провайдерам, нельзя не затронуть эту тему. Когда ЛинкМиАп, имея уже AS и PI-адреса, будет делать стык с Балаган-Телекомом, одним из первых вопросов от них будет: “Фул вью или Дефолт?”. Тут главное не растеряться и не сморозить чепуху.

То, что вы видели до сих пор – это так называемый Full View – маршрутизатор изучает абсолютно все маршруты Интернета, пусть даже в нашем случае это пять-шесть штук. В реальности их сейчас больше 400 000. Соответственно от одного провайдера вы получите 400k маршрутов, от второго столько же. Подчас бывает и третий резервный – плюс ещё 400k. Итого больше миллиона.
Ну не покупать же теперь маленькому недоинтерпрайзу циску старших серий только для этого?

* вывод таблицы маршрутизации с одного из публичных серверов (дуступен по telnet route-server.ip.att.net)

На самом деле, далеко не каждому, кто имеет AS, нужен Full View. Обычно для таких компаний, как наша вполне достаточно Default Route, по названиям вполне понятно, чем они отличаются. В последнем случае от каждого провайдера приходит только один маршрут по умолчанию, вместо сотен тысяч специфических (хотя вообще-то может и вместе).

    Full View. Вы обладаетe полным чистейшим знанием о структуре Интернета. До любого адреса в Интернете вы можете просмотреть путь от себя:

Вы знаете, какие к нему ведут AS. Через сайт RIPE можно посмотреть какие провайдеры обеспечивают транзит. Вы следите за всеми изменениями. Если вдруг у кого-то что-то упадёт через первый линк (даже не у вас или у провайдера, а где-то там, дальше), BGP это отследит и перестроит свою таблицу маршрутизации для передачи данных через второго провайдера.
При этом вы очень гибко можете управлять маршрутами, вмешиваясь в стандартную процедуру выбора наилучшего пути.
Например, весь трафик на яндекс вы будете пускать через Балаган Телеком, а на гугл через Филькин Сертификат. Это называется распределением нагрузки.
Достигается это путём настройки, например, приоритетов маршрутов для определённых префиксов.

В общем, очень грубый совет прозвучит так:
Если вы не собираетесь организовывать через себя транзит (подключать клиентов со своими АС) и нет нужды в тонком распределении исходящего трафика, то вам хватит Default Route.

Но уж точно нет смысла принимать от одного провайдера Full View, а от другого Default – в этом случае один линк будет всегда простаивать на исходящий трафик, потому что маршрутизатор будет выбирать более специфический путь.

При этом от всех провайдеров вы можете брать Default плюс определённые префиксы (например, именно этого провайдера). Таким образом до нужных ресурсов у вас будут специфические маршруты без Full View.

Вот пример настройки передачи Default Route нижестоящему маршрутизатору:

И вот как после этого выглядит таблица маршрутов на нашем бордере:

То есть помимо обычных маршрутов (Full View) передаётся ещё маршрут по умолчанию.

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

Looking Glass и другие инструменты

Одним из очень мощных инструментов работы с BGP – Looking Glass. Это сервера, расположенные в Интернете, которые позволяют взглянуть на сеть извне: проверить доступность, просмотреть через какие AS лежит путь в вашу автономную систему, запустить трассировку до своих внутренних адресов.

Это как если бы вы попросили кого-то: “слушай, а посмотри, как там мои анонсы видятся?”, только просить никого не нужно.

Существуют также специальные организации, которые отслеживают анонсы BGP в Интернете и, если вдруг происходит что-то неожиданное, может уведомить владельца сети – BGPMon, Renesys, RouterViews.
Благодаря им было предотвращено несколько глобальных аварий.

С помощью сервиса BGPlay можно визуализировать информацию о распространении маршрутов.

На nag.ru можно почитать о самых ярких случаях, когда некорректные анонсы BGP вызывали глобальные проблемы в Интернете, таких как ”AS 7007 Incident” и “Google’s May 2005 Outage”.

Очень хорошая статья по разнообразным прекраснейшим инструментам для работы с BGP.
Список серверов Looking Glass.

Control Plane и Data Plane

Перед тем, как окунуться в глубокий омут управления маршрутами, сделаем последнее лирическое отступление. Надо разобраться с понятиями в заголовке главы.
В своё время, читая MPLS Enabled Application, я сломал свой мозг на них. Просто никак не мог сообразить, о чём авторы ведут речь.
Итак, дабы не было конфузов у вас.
Это не уровни модели, не уровни среды или моменты передачи данных – это весьма абстрактное деление.
Управляющий уровень (Control Plane) – работа служебных протоколов, обеспечивающих условия для передачи данных.
Например, когда запускается BGP, он пробегает все свои состояния, обменивается маршрутной информацией итд.
Или в MPLS-сети LDP распределяет метки на префиксы.
Или STP, обмениваясь BPDU, строит L2-топологию.

Всё это примеры процессов Control Plane. То есть это подготовка сети к передаче – организация коммутации, наполнение таблицы маршрутизации.

Передающий уровень (Data Plane) – собственно передача полезных данных клиентов.

Часто случается так, что данные двух уровней ходят в разных направлениях, “навстречу друг другу”. Так в BGP маршруты передаются из AS100 в AS200 для того, чтобы AS200 могла передать данные в AS100.

Более того, на разных уровнях могут быть разные парадигмы работы. Например, в MPLS Data Plane ориентирован на создание соединения, то есть данные там передаются по заранее определённому пути – LSP.
А вот сам этот путь подготавливается по стандартным законам IP – от хоста к хосту.

Важно понять назначение уровней и в чём разница.

Для BGP это принципиальный вопрос. Когда вы анонсируете свои маршруты, фактически вы создаёте путь для входящего трафика. То есть маршруты исходят от вас, а трафик к вам.

Выбор маршрута

Ситуация с маршрутами у нас такая.
Есть BGP-таблица, в которой хранятся абсолютно все маршруты, полученные от соседей.

То есть если есть у нас несколько маршрутов, до сети 100.0.0.0/23, то все они будут в BGP-таблице, независимо от “плохости” оных:

А есть знакомая нам таблица маршрутизации, хранящая только лучшие из лучших. Точно также BGP анонсирует не все приходящие маршруты, а только лучшие. То есть от одного соседа вы никогда не получите два маршрута в одну сеть.

  1. Максимальное значение Weight (локально для маршрутизатора, только для Cisco)
  2. Максимальное значение Local Preference (для всей AS)
  3. Предпочесть локальный маршрут маршрутизатора (next hop = 0.0.0.0)
  4. Кратчайший путь через автономные системы. (самый короткий AS_PATH)
  5. Минимальное значение Origin Code (IGP
  6. Минимальное значение MED (распространяется между автономными системами)
  7. Путь eBGP лучше чем путь iBGP
  8. Выбрать путь через ближайшего IGP-соседа

Если это условие выполнено, то происходит балансировка нагрузки между несколькими равнозначными линками

Как видите, очень много критериев выбора. Причём они довольно сложные и с ходу их все понять непросто. Втягивайтесь потихоньку.
О некоторых упомянутых атрибутах мы поговорим ниже, а конкретно на выборе маршрутов остановимся в отдельной статье.

Схема: Общая схема сети
Условие: Full View на всех маршрутизаторах

Если вы сейчас посмотрите таблицу BGP на маршрутизаторе провайдера Балаган Телеком, то увидите 3 маршрута в сеть 102.0.0.0/21 – сеть Филькина Сертификата. И один из маршрутов ведёт через нашу сети ЛинкМиАп.

Это говорит о том, что наш бордер анонсирует чужие маршруты дальше, иными словами наша AS является транзитной.

Задание:
Настроить фильтрацию таким образом, чтобы наша AS64500 перестала быть транзитной.

Управление маршрутами

Прежде чем переходить к большой теме распределения нагрузки с помощью BGP просто необходимо разобраться с тем, каким образом мы вообще можем управлять маршрутами в этом протоколе.
Именно возможность такого управления обменом маршрутной информации делает BGP таким гибким и подходящим для взаимодействия нескольких различных провайдеров, в отличии от любого IGP.

  • AS-Path ACL
  • Prefix-list
  • Weight
  • Local Preference
  • MED

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

AS-Path ACL

Весьма мощный, но не самый популярный механизм.

С помощью AS-Path ACL вы можете, например, запретить принимать анонсы маршрутов, принадлежащих AS 200. Ну вот просто не хотите – пусть они через другого провайдера будут известны, а через этого нет.

Самое сложное в таком подходе – запомнить все регулярные выражения и научиться их использовать. Сначала голова от них кругом:

Знак Значение
. любой символ, включая пробел
* ноль или больше совпадений с выражением
+ одно или больше совпадений с выражением
? ноль или одно совпадение с выражением
^ начало строки
$ конец строки
_ любой разделитель (включая, начало, конец, пробел)
\ не воспринимать следующий символ как специальный
[ ] совпадение с одним из символов в диапазоне
| логическое или

Чтобы было чуть более понятно, приведём несколько примеров:

1

_200_ Маршруты проходящие через AS 200

До и после номера AS идут знаки “_”, означающие, что в AS-path номер 200 может стоять в начале, середине или конце, главное, чтобы он был.

2

^200$ Маршруты из соседней AS 200

“^” означает начало списка, а “$” – конец. То есть в AS-path всего лишь один номер AS – это означает, что маршрут был зарождён в AS 200 и оттуда сразу был передан нам.

3

_200$ Маршруты отправленные из AS 200

“$” означает конец списка, то есть это самая первая AS, из неё маршрут и зародился, знак “_” говорит о том, что неважно, что находится дальше, хоть ничего, хоть 7 других AS.

4

^200_ Сети находящиеся за AS 200

Знак “^” означает, что ASN 200 была добавлена последней, то есть маршрут к нам пришёл из AS 200, но это не значит, что родился он в ней же – знак “_” говорит о том, что это может быть конец списка, а может пробел перед следующей AS.

5

^$ Маршруты локальной AS

Список AS-path пуст, значит маршрут локальный, сгенерированный внутри нашей AS.

Пример

Вот в нашей сети отфильтруем маршруты, которые зародились в AS 64501. То есть мы будем от соседа 101.0.0.1 получать все интернетовские маршруты, но не будем получать их локальные.

Конфигурация устройств.

Prefix-list

Тут всё просто и логично. Ну почти.

Префикс-листы – это просто привычные нам сеть/маска, и мы указываем разрешить такие маршруты или нет.

Синтаксис команды:
list-name – название списка. Ваш КО. Обычно указывается, как name_in или name_out. Это подсказывает нам на входящие или исходящие маршруты будет действовать (но, конечно, на данном этапе никак не определяет).
seq – порядковый номер правила (как в ACL), чтобы проще было оперировать с ними.
deny/permit – определяем разрешать такой маршрут или нет
network/length – привычная для нас запись, вроде, 192.168.14.0/24.
А вот дальше, внимание, сложнее – возможны ещё два параметра: ge и le. Как и при настройке NAT (или в ЯП Фортран), это означает «greater or equal» и «less or equal».
То есть вы можете задать не только один конкретный префикс, но и их диапазон.

Например, такая запись

будет означать, что будут выбраны следующие маршруты.

10.0.0.0/10, 10.0.0.0/11, 10.0.0.0/12, 10.0.0.0/13, 10.0.0.0/14, 10.0.0.0/15, 10.0.0.0/16

Пример

Сейчас мы запретим принимать анонс сети 120.0.0.0/24 через провайдер Филькин Сертификат, а все остальные разрешим. Запись 0.0.0.0/0 le 32 означает любые подсети с любой длиной маски (меньшей или равной 32 (0-32)).

Route Map

До сих пор все правила применялись безусловно – на все анонсы от пира или пиру.
С помощью карт маршрутов (у других вендоров они могут называться политиками маршрутизации) мы можем очень гибко применять правила, дифференцируя анонсы.

Синтаксис команды следующий:
map_name – имя карты
permit/deny – разрешаем или нет прохождение данных, подпадающих под условия route-map
seq – номер правила в route-map
match – условие подпадания трафика под данное правило.

expression:

Критерий Команда конфигурации
Network/mask match ip address prefix-list
AS-path match as-path
BGP community match community
Route originator match ip route-source
BGP next-hop address match ip next-hop

set – что сделать с отфильтрованными маршрутами
expression:

Параметры Команда конфигурации
AS path prepend set as-path prepend
Weight set weight
Local Preference set local-preference
BGP community set community
MED set metric
Origin set origin
BGP next-hop set next-hop

Пример применения

Укажем, что в подсеть 120.0.0.0/24 предпочтительно ходить через Филькин Сертификат, а в 103.0.0.0/22 через Балаган Телеком. Для этого воспользуемся атрибутом Local Preference. Чем выше значение этого параметра, тем выше приоритет маршрута.

Сначала мы создали обычным образом prefix-list, которым выделили подсеть 120.0.0.0/24. Permit означает, что на этот префикс в будущем будут действовать правила route-map. Как и в обычных ACL далее идёт неявное правило deny для всего остального. В данном случае оно означает, что под действие route-map подпадёт только 120.0.0.0/24 и ничего другого.

В созданной карте маршрутов BGP1_IN мы разрешили прохождение маршрутной информации (permit), подпадающей под созданный prefix-list (match ip address prefix-list TEST1_IN).
Для этих анонсов установим local preference в 50 – ниже, чем стандартные 100 (set local-preferеnce 50). То есть они будут менее «интересными».

И в конечном итоге привяжем карту к конкретному BGP-соседу (neighbor 102.0.0.1 route-map BGP1_IN in).

Что же получается в результате?

Конфигурация устройств

Другие примеры рассмотрим в следующем разделе.

Схема: Общая схема сети
Условие: ЛинкМиАп получает Full View от обоих провайдеров.

Тема: Поиск неисправностей.
От провайдеров: полная таблица маршрутов BGP

На маршрутизаторе msk-arbat-gw1 настроено распределение исходящего трафика между провайдерами Балаган Телеком и Филькин Сертификат. Трафик идущий в сети провайдера Филькин Сертификат, должен идти через него, если он доступен. Остальной исходящий трафик, должен передаваться через провайдера Балаган Телеком, когда он доступен.
При проверке исходящего трафика, оказалось, что при отключении Балаган Телеком, исходящий трафик к ЦОД (103.0.0.1) не идет через Филькин Сертификат.

В остальном конфигурация стандартная.

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

Балансировка и распределение нагрузки

“А какие вы знаете способы балансировки трафика в BGP?”
Это вопрос, который любят задавать на собеседованиях.

Начиная готовиться к этой статьей, я имел разговор с нашей Наташей, из которого стало понятно, что в BGP балансировка и распределение – это две большие разницы.

Балансировка нагрузки

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

Включается она просто

  • Не менее двух маршрутов в таблице BGP для этой сети.
  • Оба маршрута идут через одного провайдера
  • Параметры Weight, Local Preference, AS-Path, Origin, MED, метрика IGP совпадают.
  • Параметр Next Hop должен быть разным для двух маршрутов.

Последнее условие обходится скрытой командой

В этом случае умаляется также условие полного совпадения AS-path, но длина должна быть по-прежнему одинаковой.

Как мы можем проверить это на нашей сети? Нам ведь нужно убедиться, что балансировка работает.

Балансировка обычно осуществляется на базе потоков (IP-адрес/порт отправителя и IP-адрес/порт получателя), чтобы пакеты приходили в правильном порядке. Поэтому нам нужно создать два потока.
Нет ничего проще:
1) ping непосредственно с msk-arbat-gw1 на 103.0.0.1
2) подключаемся телнетом на msk-arbat-gw1 (не забыв настроить параметры) с любого другого маршрутизатора и запускаем пинг с указанием источника (чтобы потоки чем-то отличались друг от друга)

После этого один пинг пойдёт через один линк, а второй через другой. Проверено

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

Схема: Общая схема сети
Условие: ЛинкМиАп получает от обоих провайдеров маршрут по умолчанию.

Задание:
Настроить балансировку исходящего трафика между маршрутами по умолчанию от провайдеров Балаган Телеком и Филькин Сертификат в пропорции 3 к 1.

Распределение нагрузки

Совсем другая песня с распределением – это более тонкая настройка путей исходящего и входящего трафика.

Исходящий

Исходящий трафик направляется в соответствии с маршрутами, полученными свыше.
Соответственно ими и надо управлять.
Напомним схему нашей сети

Итак, есть следующие способы:
1) Настройка Weight. Это цисковский внутренний параметр – никуда не передаётся – работает в пределах маршрутизатора. У других вендоров тоже часто бывают аналоги (например, PreVal у Huawei). Тут ничего специфического – не будем даже останавливаться. (по умолчанию – 0)

Применение ко всем маршрутам полученным от соседа:

Применение через route-map:

2) Local Preference. Это параметр стандартный. По умолчанию 100 для всех маршрутов. Если вы хотите трафик на определённые подсети направлять в определённые линки, то Local Preference незаменим.

Выше мы уже рассматривали пример использования данного параметра.

3) Вышеуказанная балансировка командой maximum-paths

Схема: Общая схема сети
Условие: ЛинкМиАп получает Full View от обоих провайдеров.

Задание:
Не используя атрибуты weight, local preference или фильтрацию, настроить маршрутизатор msk-arbat-gw1 так, чтобы для исходящего трафика Балаган Телеком был основным, а Филькин Сертификат резервным.

Входящий

Тут всё сложно.
Дело в том, что даже у крупных провайдеров исходящий трафик незначителен в сравнении со входящим. И там так остро не замечается неровное распределение.

Зато если речь идёт о Центрах Обработки Данных или хостинг-провайдерах, то ситуация обратная и вопрос балансировки стоит очень остро.

Тут мы крайне стеснены в средствах:

1) AS-Path Prepend

Один из самых частых приёмов – “ухудшение” пути. Нередко бывает так, что через одного провайдера ваши маршруты будут переданы с длиной AS-path больше, чем через другого. Разумеется, BGP выбирает первого, безапелляционно, и только через него будет передавать трафик. Чтобы выровнять ситуацию при анонсировании маршрутов можно добавить лишний “хоп” в AS-Path.

А бывает такая ситуация, что один провайдер предоставляет более широкий канал за небольшие деньги, но при этом путь через него длиннее и весь трафик уходит в другой – дорогой и узкий. Нам эта ситуация невыгодна и мы бы хотели, чтобы узкий канал стал резервным.
Вот её и разберём. Но придётся взять совершенно вырожденную ситуацию. К примеру, доступ из Балаган Телекома к сети ЛикМиАп.

Вот так выглядит таблица BGP и маршрутизации на провайдере Балаган Телеком в обычной ситуации:

Если мы хотим ухудшить основной путь (прямой линк между ними), то нужно добавить AS в список AS-Path:

Тогда выглядеть картинка будет так

Разумеется, выбирается путь с меньшей длиной AS-Path, то есть через Филькин Сертификат (AS6502)

Этот маршрут и добавится в таблицу маршрутизации.

Заметим, что обычно в AS-Path добавляют именно свой номер AS. Можно, конечно, и чужую, но вас не поймут в приличном обществе.

Таким образом мы добились того, что трафик пойдёт намеченным нами путём.

Естественно, при падении одного из каналов трафик переключится на второй, независимо от настроенных AS-Path Prepend’ов.

2) MED

Multiexit Discriminator. В cisco он называется метрикой (Inter-AS метрика). MED является слабым атрибутом. Слабым, потому что он проверяется лишь на шестом шаге при выборе маршрута и оказывает по сути слабое влияние.
Если Local Preference влияет на выбор пути выхода трафика из Автономной системы, то MED передаётся в соседние AS и таким образом влияет на пути входа трафика.
Вообще MED и Local Preference часто путают новички, поэтому опишем в табличке разницу

Local Preference MED
Определяет приоритет пути для выхода трафика Определяет приоритет пути для входа трафика
Действует только внутри AS. Никак не передаётся в другие AS Передаётся в другие AS и намекает через какой путь передавать трафик предпочтительнее
Может работать при подключении к разным AS Работает только при нескольких подключениях к одной AS
Чем больше значение, тем выше приоритет Чем больше значение, тем ниже приоритет

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

3) Анонс разных префиксов через разных ISP

Ещё один способ распределить нагрузку – раздавать разные сети разным провайдерам.

Сейчас в сети ЦОДа наши анонсы выглядят так:

То есть наша сеть 100.0.0.0/23 известна через два пути, но в таблицу маршрутизации добавится только один. Соответственно и весь трафик назад пойдёт одним – лучшим путём.

Но!
Мы можем разделить её на две подсети /24 и одну отдавать в Балаган Телеком, а другую в Филькин Сертификат.
Соответственно ЦОД будет знать про эти подсети через разные пути:

Настраивается это так.

Во-первых, мы прописываем все свои подсети – все 3: одну большую /23 и две маленькие /24:

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

А теперь создаём префикс-листы, которые разрешают каждый только одну подсеть /24 и общую /23.

Осталось привязать префикс-листы к соседям.

Привязываем мы их на OUT – на исходящий, потому что речь о маршрутах, которые мы отправляем вовне.

Итак, соседу 101.0.0.1 (Балаган Телеком) мы будем анонсировать сети 100.0.0.0/24 и 100.0.0.0/23.
А соседу 102.0.0.1 (Филькин Сертификат) – сети 100.0.1.0/24 и 100.0.0.0/23.

Результат будет таким:

Вроде бы, неправильно, потому что у нас по два маршрута в каждую сеть /24 – через Балаган Телеком и через Филькин Сертификат.
Но если приглядеться, то вы увидите, что согласно AS-Path у нас такие маршруты:

То есть, по сути всё правильно. Да и в таблицу маршрутизации всё помещается правильно:

Теперь осталось ответить на вопрос какого лешего мы тащили за собой большую подсеть /23? Ведь согласно правилу Longest prefix match более точные маршруты предпочтительней, то есть /23, как бы и не нужен, когда есть /24.

Но вообразим себе ситуацию, когда падает сеть Балаган Телеком. Что при этом произойдёт? Подсеть 100.0.0.0/24 перестанет быть известной в интернете – ведь только Балаган Телеком что-то знал о ней благодаря нашей настройке. Соответственно, ляжет и часть нашей сети. Но! Нас спасает более общий маршрут 100.0.0.0/23. Филькин Сертификат знает о нём и анонсирует его в Интернет. Соответственно, хоть ЦОД и не знает про сеть 100.0.0.0/24, он знает про 100.0.0.0/23 и пустит трафик в сторону Филькина Сертификата.

То есть, слава Лейбницу, мы застрахованы от такой ситуации.

4) BGP Community

C помощью BGP Community можно давать провайдеру указания, что делать с префиксом, кому передавать, кому нет, какой local preference у себя ставить и т.д. Рассматривать этот вариант сейчас не будем, потому что тему коммьюнити мы перенесём в следующий выпуск.

Схема: Общая схема сети

Условие: На маршрутизаторе msk-arbat-gw1 настроено управление входящим и исходящим трафиком. Основной провайдер Балаган Телеком, резервый – Филькин Сертификат. При проверке настроек оказалось, что исходящий трафик передается правильно. При проверке входящего трафика, оказалось, что входящий трафик идет и через провайдера Балаган Телеком, но когда отключается Балаган Телеком, входящий трафик не идет через Филькин Сертификат.

Задание: Исправить настройки.

Наташа Самойленко — автор xgu.ru подготовила для нас презентацию.

http://www.slideshare.net/NatashaSamoylenko/linkmeup-bgpipslaВы можете её качать и использовать, как пожелаете с указанием авторства.

Все технологии маршрутизации, которые мы применяли до этого момента в наших статьях, будь то статическая маршрутизация, динамическая маршрутизация (IGP или EGP), в своей работе принимали во внимание только один признак пакета: адрес назначения. Все они, упрощенно, действовали по одному принципу: смотрели, куда идет пакет, находили в таблице маршрутизации наиболее специфичный маршрут до пункта назначения (longest match), и переправляли пакет в тот интерфейс, который был записан в таблице напротив этого самого маршрута. В этом, в общем-то, и состоит суть маршрутизации. А что, если такой порядок вещей нас не устраивает? Что, если мы хотим маршрутизировать пакет, отталкиваясь от адреса источника? Или нам нужно мальчики HTTP направо, девочки SNMP налево?

  • Адрес источника (или комбинация адрес источника-адрес получателя)
  • Информация 7 уровня (приложений) OSI
  • Интерфейс, в который пришел пакет
  • QoS-метки
  • Вообще говоря, любая информация, используемая в extended-ACL (порт источника\получателя, протокол и прочее, в любых комбинациях). Т.е. если мы можем выделить интересующий нас трафик с помощью расширенного ACL, мы сможем его смаршрутизировать, как нам будет угодно.
  • Все нужно писать руками, отсюда много работы и риск ошибки
  • Производительность. На большинстве железок PBR работает медленнее, чем обычный роутинг (исключение составляют каталисты 6500, к ним есть супервайзер с железной поддержкой PBR)
  • Выделение нужного трафика. Осуществляется либо с помощью ACL, либо в зависимости от интерфейса, в который трафик пришел. За это отвечает команда match в режиме конфигурации route map
  • Применение действия к этому трафику. За это отвечает команда set

Имеем вот такую топологию:

В данный момент трафик R1-R5 и обратно идет по маршруту R1-R2-R4-R5, для удобства, адреса присвоены так, чтобы последняя цифра адреса была номером маршрутизатора:

Для примера, предположим, что нам нужно, чтобы обратно трафик от R5 (с его адресом в источнике) шел по маршруту R5-R4-R3-R1. По схеме очевидно, что решение об этом должен принимать R4. На нем сначала создаем ACL, который отбирает нужные нам пакеты:

Затем создаем политику маршрутизации с именем “BACK”:

Внутри нее говорим, какой трафик нас интересует:

И что с ним делать:

После чего заходим на интерфейс, который смотрит в сторону R5 (PBR работает с входящим трафиком!) и применяем на нем полученную политику:

Работает! А теперь посмотрим внимательно на схему и подумаем: все ли хорошо?

А вот и нет!
Следуя данному ACL, у нас заворачивается на R3 весь трафик с источником R5. А это значит, что если, например, R5 захочет попасть на R2, он, вместо короткого и очевидного маршрута R5-R4-R2, будет послан по маршруту R5-R4-R3-R1-R2. Поэтому, нужно очень аккуратно и вдумчиво составлять ACL для PBR, делая его максимально специфичным.

  • set ip next-hop
  • set interface
  • set ip default next-hop
  • set default interface

Условие: ЛинкМиАп использует статические маршруты к провайдерам (не BGP).

Схема и конфигурация. Маршрутизаторы провайдеров также не используют BGP.

Задание: Настроить переключение между провайдерами.
Маршрут по умолчанию к Балаган Телеком должен использоваться до тех пор, пока приходят icmp-ответы на пинг google (103.0.0.10) ИЛИ yandex (103.0.0.20). Запросы должны отправляться через Балаган Телеком. Если ни один из указанных ресурсов не отвечает, маршрут по умолчанию должен переключиться на провайдера Филькин Сертификат. Для того чтобы переключение не происходило из-за временной потери отдельных icmp-ответов, необходимо установить задержку переключения, как минимум, 5 секунд.

IP SLA

А теперь самое вкусное: представим, что в нашей схеме основной путь R4-R2-R1 обслуживает один провайдер, а запасной R4-R3-R1 – другой. Иногда у первого провайдера бывают проблемы с нагрузкой, которые приводят к тому, что наш голосовой трафик начинает страдать. При этом, другой маршрут ненагружен и хорошо бы в этот момент перенести голос на него. Ок, пишем роут-мап, как мы делали выше, который выделяет голосовой трафик и направляем его через нормально работающего провайдера. А тут – оп, ситуация поменялась на противоположную – опять надо менять все обратно. Будни техподдержки: “И такая дребедень целый день: то тюлень позвонит, то олень”. А вот бы было круто, если можно было бы отслеживать нужные нам характеристики основного канала (например, задержку или джиттер), и в, зависимости от их значения, автоматически направлять голос или видео по основному или резервному каналу, да? Так вот, чудеса бывают. В нашем случае чудо называется IP SLA.

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

Без лишних слов, сразу к настройке. Для начала, нам нужно сказать, что мы хотим мониторить. Создаем объект мониторинга, назначаем ему номер:

Так-с, что мы тут можем мониторить?

Как видите, список внушительный, поэтому останавливаться не будем, для интересующихся есть подробная статья на циско.ком.

Условие: ЛинкМиАп использует статические маршруты к провайдерам (не BGP).

Схема и конфигурация. Маршрутизаторы провайдеров также не используют BGP.

Задание:
Настроить маршрутизацию таким образом, чтобы HTTP-трафик из локальной сети 10.0.1.0 шел через Балаган Телеком, а весь трафик из сети 10.0.2.0 через Филькин Сертификат. Если в адресе отправителя фигурирует любой другой адрес, трафик должен быть отброшен, а не маршрутизироваться по стандартной таблице маршрутизации (задание надо выполнить не используя фильтрацию с помощью ACL, примененных на интерфейсе).
Дополнительное условие: Правила PBR должны работать так только если соответствующий провайдер доступен (в данной задаче достаточно проверки доступности ближайшего устройства провайдера). Иначе должна использоваться стандартная таблица маршрутизации.

Обычно, работу IP SLA рассматривают на простейшем примере icmp-echo. То есть, в случае, если мы можем пинговать тот конец линии, трафик идет по ней, если не можем – по другой. Но мы пойдем путем чуть посложнее. Итак, нас интересуют характеристики канала, важные для голосового трафика, например, джиттер. Конкретнее, udp-jitter, поэтому пишем

В этой команде после указания вида проверки (udp-jitter) идет ip адрес, куда будут отсылаться пробы (т.е. меряем от нас до 192.168.200.1 – это лупбек на R1) и порт (от балды 55555). Затем можно настроить частоту проверок (по умолчанию 60 секунд):

и предельное значение, при превышении которого объект ip sla 1 рапортует о недоступности:

Некоторые виды измерений в IP SLA требуют наличия “на той стороне” так называемого “ответчика” (responder), некоторые (например, FTP, HTTP, DHCP, DNS) нет. Наш udp-jitter требует, поэтому, прежде чем запускать измерения, нужно подготовить R1:

Теперь нам нужно запустить сбор статистики. Командуем

Т.е. запускаем объект мониторинга 1 прямо сейчас и до конца дней.

Round Trip Time (RTT) for Index 1
Latest RTT: 36 milliseconds
Latest operation start time: *00:39:01.531 UTC Fri Mar 1 2002
Latest operation return code: OK
RTT Values:
Number Of RTT: 10 RTT Min/Avg/Max: 19/36/52 milliseconds
Latency one-way time:
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds
Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds
Jitter Time:
Number of SD Jitter Samples: 9
Number of DS Jitter Samples: 9
Source to Destination Jitter Min/Avg/Max: 0/5/20 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/16/28 milliseconds
Packet Loss Values:
Loss Source to Destination: 0 Loss Destination to Source: 0
Out Of Sequence: 0 Tail Drop: 0
Packet Late Arrival: 0 Packet Skipped: 0
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 0
Mean Opinion Score (MOS): 0
Number of successes: 12
Number of failures: 0
Operation time to live: Forever

Теперь настраиваем так называемый track (неправильный, но понятный перевод “отслеживатель”). Именно к его состоянию привязываются впоследствии действия в роут-мапе. В track можно выставить задержку переключения между состояниями, что позволяет решить проблему, когда у нас по одной неудачной пробе меняется маршрутизация, а по следующей, уже удачной, меняется обратно. Указываем номер track и к какому номеру объекта ip sla мы его подключаем (rtr 1):

Это означает: если объект мониторинга упал и не поднялся в течение 15 секунд, переводим track в состояние down. Если объект был в состоянии down, но поднялся и находится в поднятом состоянии хотя бы 10 секунд, переводим track в состояние up.
Следующим действием нам нужно привязать track к нашей роут-мапе. Напомню, стандартный путь от R5 к R1 идет через R2, но у нас имеется роут-мапа BACK, переназначающая стандартное положение вещей в случае, если источник R5:

Если мы привяжем наш мониторинг к этой мапе, заменив команду set ip next-hop 192.168.3.3 на set ip next-hop verify-availability 192.168.3.3 10 track 1, получим обратный нужному эффект: в случае падения трека (из-за превышения показателя джиттера в sla 1), мапа не будет отрабатываться (все будет идти согласно таблице маршрутизации), и наоборот, в случае нормальных значений, трек будет up, и трафик будет идти через R3.

Как это работает: роутер видит, что пакет подпадает под условия match, но потом не сразу делает set, как в предыдущем примере с PBR, а промежуточным действием проверяет сначала состояние трека 1, а затем, если он поднят (up), уже делается set, если нет – переходит к следующей строчке роут-мапы.

Для того, чтобы наша мапа заработала, как надо, нам нужно как-то инвертировать значение трека, т.е. когда джиттер большой, наш трек должен быть UP, и наоборот. В этом нам поможет такая штука, как track list. В IP SLA существует возможность объединять в треке список других треков (которые, по сути, выдают на выходе 1 или 0) и производить над ними логические операции OR или AND, а результатом этих операций будет состояние этого трека. Кроме этого, мы можем применить логическое отрицание к состоянию трека. Создаем трек-лист:

Единственным в этом “списке” будет логическое отрицание значения трека 1:

Теперь привязываем роут-мап к этому треку

Цифра 10 после адреса некстхопа – это его порядковый номер (sequence number). Мы можем, к примеру, использовать его так:

Тут такая логика: выбираем трафик, подпадающий под ACL 100, затем идет промежуточная проверка track 1, если он up, ставим пакету некстхоп 192.168.3.3, если down, переходим к следующему порядковому номеру (20 в данном случае), опять же промежуточно проверяем состояние трека (уже другого, 2), в зависимости от результата, ставим некстхоп 192.168.2.2 или отправляем с миром (маршрутизироваться на общих основаниях).

Давайте теперь немножко словами порассуждаем, что же мы такое накрутили: итак, измерения джиттера у нас идут от источника R4 к респондеру R1 по маршруту через R2. Максимальное допустимое значение джиттера на этом маршруте у нас – 10. В случае, если джиттер превышает это значение и держится на этом уровне 15 секунд, мы переключаем трафик, генерируемый R5, на маршрут через R3. Если джиттер падает ниже 10 и держится там минимум 10 секунд, пускаем трафик от R5 по стандартному маршруту. Попробуйте для закрепления материала найти, в каких командах задаются все эти значения.

Итак, мы достигли цели: теперь, в случае ухудшения качества основного канала (ну, по крайней мере, значений udp-джиттера), мы переходим на резервный. Но что, если и там тоже не очень? Может, попробуем с помощью IP SLA решить и эту проблему?

Попробуем выстроить логику того, что мы хотим сделать. Мы хотим перед переключением на резервный канал проверять, как у нас обстоит дело с джиттером на нем. Для этого нам нужно завести дополнительный объект мониторинга, который будет считать джиттер на пути R4-R3-R1, пусть это будет 2. Сделаем его аналогичным первому, с теми же значениями. Условием переключения на резервный канал тогда будет: объект 1 down И объект 2 up. Чтобы измерять джиттер не по основному каналу, придется пойти на хитрость: сделать loopback-интерфейсы на R1 и R4, прописать статические маршруты через R3 туда-обратно, и использовать эти адреса для объекта SLA 2.

Теперь меняем условие трека 2, к которому привязана роут-мапа:

Вуаля, теперь трафик R5->R1 переключается на запасной маршрут только в том случае, если джиттер основного канала больше 10 и, в это же время, джиттер запасного меньше 10. В случае, если высокий джиттер наблюдается на обоих каналах, трафик идет по основному и молча страдает.

Состояние трека можно привязать также к статическому маршруту: например, мы можем командой ip route 0.0.0.0 0.0.0.0 192.168.1.1 track 1 сделать шлюзом по умолчанию 192.168.1.1, который будет связан с треком 1 (который, в свою очередь, может проверять наличие этого самого 192.168.1.1 в сети или измерять какие-нибудь важные характеристики качества связи с ним). В случае, если связанный трек падает, маршрут убирается из таблицы маршрутизации.

Также будет полезным упомянуть, что информацию, получаемую через IP SLA, можно вытащить через SNMP, чтобы потом можно было ее хранить и анализировать где-нибудь в вашей системе мониторинга. Можно даже настроить SNMP-traps.

Схема: как в других задачах по PBR. Конфигурация ниже.
Условие: ЛинкМиАп использует статические маршруты к провайдерам (не BGP).

На маршрутизаторе msk-arbat-gw1 настроена PBR: HTTP-трафик должен идти через провайдера Филькин Сертификат, а трафик из сети 10.0.2.0 должен идти через Балаган Телеком.
Указанный трафик передается правильно, но не маршрутизируется остальной трафик из локальной сети, который должен передаваться через провайдера Балаган Телеком.

Задание:
Исправить настройки таким образом, чтобы они соответствовали условиям.

MikroTik.by

For every complex problem, there is a solution that is simple, neat, and wrong.

  • Темы без ответов
  • Активные темы
  • Поиск
  • Список форумовФорум по операционной системе MikroTik RouterOSМаршрутизация, коммутация
  • Поиск

Раздача пула внешних ip адресов во внутреннюю подсеть.

Раздача пула внешних ip адресов во внутреннюю подсеть.

Сообщение monorels » 08 май 2018, 16:21

Re: Раздача пула внешних ip адресов во внутреннюю подсеть.

Сообщение Chupaka » 08 май 2018, 17:32

А как адреса предоставляются? BGP?

Re: Раздача пула внешних ip адресов во внутреннюю подсеть.

Сообщение monorels » 08 май 2018, 18:19

Re: Раздача пула внешних ip адресов во внутреннюю подсеть.

Сообщение monorels » 10 май 2018, 10:14

Re: Раздача пула внешних ip адресов во внутреннюю подсеть.

Сообщение Chupaka » 10 май 2018, 10:55

Есть два варианта раздачи: либо бридж (у провайдера висит адрес, например, х.х.х.1/24, клиенты прописывают себе х.х.х.у/24 и шлюзом указывают провайдерский .1, подключаются к провайдеру через обычный коммутатор), либо маршрутизация (между провайдером и роутером какая-нибудь сеть для интерконнекта, 1.2.3.2/30, а все остальные сети провайдер маршрутизирует на адрес роутера — тогда раздача адресов и поднятие шлюзов по умолчанию — задача роутера компании, а не провайдера).

Как включить DHCP на роутере — автоматическая раздача IP-адресов. Как включить DHCP в ОС Windows: простейшие решения Что такое клиент DHCP и зачем он нужен

Как включить DHCP на роутере — автоматическая раздача IP-адресов. Как включить DHCP в ОС Windows: простейшие решения Что такое клиент DHCP и зачем он нужен

  • Live Journal

В пользователей, в которых дома появляется несколько компьютеров, возникает потребность объединить все существующие ПК в локальную сеть. Этот процесс нужен, чтобы сделать взаимодействие между ними удобным.

Это даст возможность заходить в интернет, при этом используя одно подключение, пользуясь всеми возможностями локальной сети. Станет доступным обмен файлами, документами по сети, удаленно управлять разными компьютерами.

Это все стает возможным, воспользовавшись роутером, ADSL-модемом, любым другим устройством Главное, чтобы в нем был встроенный маршрутизатор. Сначала потребуется произвести включение DHCP на своем сетевом адаптере, отдельно на каждом из компьютеров. Затем включить соответствующую службу на своем роутере, модеме. Они будут исполнять функции сервера.

Данный протокол дает возможность компьютерам в автоматическом режиме проводить настройку взаимодействия с другими ПК. Это выполняется с помощью сервера или маршрутизатора. Многих пользователей ПК интересует вопрос, как включить DHCP, чтобы к локальной сети.

Как проверить работу службы «DHCP-сервер»

Перед тем, как включать DHCP на сетевом адаптере, нужно посмотреть, включена ли служба «DHCP-сервер» на роутере или, если вы используете ADSL-модеме, то на нем. Чтобы узнать это понадобится включить «Панель управления роутером». Чтобы запустить данный инструмент, необходимо воспользоваться веб-интерфейсом. При этом потребуется ввести логин и пароль. Нужны те данные, которыми пользуется администратор.

В сетевых настройках необходимо перепроверить поставлена ли галочка возле пункта под названием «Автоматически назначать IP адреса» или «Dynamic IP Address Mode», если англоязычная версия. Если данная утилита не активирована, то понадобится поставить птичку на соответствующем пункте. Сохранить измененные настройки. Затем перезагрузить устройство.

Включение DHCP

Когда dhcp не включен на сетевом адаптере, то сначала необходимо перепроверить, включен ли DHCP-клиент на всех используемых компьютерах. Для этого достаточно команду «services.msc» прописать в строку поиска инструмента «Выполнить». Его можно вызвать через поиск меню ПУСК.
В окне, которое откроется, есть возможность включить или же отключить DHCP. Стандартно, при запуске службы должен быть установлен автоматический тип. В случае, если там будет указано другое значение, его придется сменить на «Автоматически». Нажать «Ок» и перезагрузится.

Включить службу через командную строку

Для открытия командной строки, нужно просто нажать ПКМ по значку меню Пуск. Затем запустить её от имени администратора. Или прописав команду «cmd» в окошке «Выполнить». Затем в строке прописать значение «netsh interface ip set address «Подключение по локальной сети»dhcp». В данной команде, фраза «Подключение по локальной сети» означает название вашего подключения.
Таким образом произойдет переключение из статических параметров настроек подключения.


Чтобы переключить список статистических настроек dns серверов тоже в динамические, потребуется прописать значение «netsh interface ip set dnsserver «Подключение по локальной сети» dhcp».

Включение DHCP на сетевом адаптере

Чтобы выполнить данную операцию, нужно на сетевом адаптере войти в настройки своих сетевых подключений. Чтобы сделать такое, понадобится ввести команду «Ncpa.cpl», прописав её в строку поиска. Эта строка появляется при включении меню, после нажатия кнопки Пуск. Затем щелкнуть кнопку «Ввод» / «Enter» на своей клавиатуре.

В настройки сетевых подключений можно войти и без командной строки. Потребуется просто открыть «Панель управления».

В открывшемся окне, потребуется найти подключение, которое используется в локальной сети. Затем кликнуть ПКМ по его значку. Откроется контекстное меню, в котором потребуется выбрать пункт, называемый «Свойства».


Затем выбрать «Протокол Интернета версии 4 (TCP/IPv4). После чего щелкнуть кнопку «Свойства». Во вкладке «Общие» поставить значения под названием «Получить IP-адрес автоматически», а также «Получить адрес DNS-сервера автоматически». Нажать «Ок», после чего произойдет сохранение всех проделанных изменений.

После проделанных действий, роутер и сетевые адаптеры компьютеров будут настроены. Протокол DHCP будет полностью готовым к работе.

Так используя DHCP сервер, можно легко и быстро ускорить процесс соединения всех нужных ПК. В тоже время застраховаться от всех возможных ошибок, которые могут образоваться при подключении.

Немногие юзеры, использующие подключение к интернету, знают, что собой представляет DHCP-клиент, зачем он нужен и как его включить. Не вдаваясь в технические подробности, мы сейчас рассмотрим основные понятия и методику его включения (использования).

Что такое клиент DHCP и зачем он нужен

Если говорить понятным любому пользователю современной компьютерной системы языком, клиентская служба DHCP является тем сетевым протоколом, который позволяет производить настройки подключений к интернету или локальной сети в автоматическом режиме.

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

Предварительные настройки роутера

Если для доступа в Сеть используется маршрутизатор в виде роутера, сначала необходимо проверить, включен ли клиент DHCP именно в настройках роутера.

Для этого заходим в его меню через любой интернет-браузер (в адресной строке в большинстве случаев вводится 192.168.1.1) и находим раздел типа «DHCP-сервер» (в разных моделях разделы могут иметь отличающиеся названия). Здесь проверяем, задействован ли параметр разрешения доступа. Если таковой отключен, нужно DHCP включить. В принципе, тут же можно прописать начальный и конечный IP-адреса, но делать это рекомендуется только в том случае, когда по каким-либо причинам нужно ограничить доступ и количество одновременно подключаемых устройств.

Как включить DHCP через раздел служб?

Теперь посмотрим, что можно сделать, если этот протокол отключен. Включить DHCP можно через раздел служб в настройках администрирования.

Сделать это можно через панель управления, но проще использовать командную строку, вызываемую из меню «Выполнить» (Win + R) командой cmd, где прописывается сочетание services.msc.

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

Доступ к параметрам администрирования в некоторых версиях «операционок» Windows можно получить непосредственно через меню «Пуск» или через его подраздел «Средства администрирования» (к примеру, в Windows 10). Впрочем, какой именно путь использовать, роли не играет, ведь главное конечный результат.

Как включить DHCP через протокол TCP/IP?

Можно использовать более-менее простой способ. В данном случае нам понадобятся настройки протокола TCP/IP. Добраться к ним можно через раздел свойств локального подключения. Как включить DHCP в этом случае? Опять же, проще в командной строке задать команду ncpa.cpl с последующим переходом к свойствам (вызов осуществляется тем же способом, который был приведен выше).

Теперь из списка компонентов выбираем протокол TCP/IPv4 и в свойствах указываем автоматическое получение IP-адреса и адреса предпочитаемого DNS-сервера. Дополнительные настройки можно не трогать вообще. В устаревших версиях Windows протокола IPv4 нет. Вместо него присутствует общая настройка TCP/IP.

В некоторых случаях может понадобиться меню управления электропитанием, в котором нужно будет отключить все имеющиеся параметры.

Проверка автоматического подключения

Вот, собственно, мы рассмотрели вопрос о том, как включить DHCP. Теперь активные подключения необходимо проверить на работоспособность.

Для этого лучше всего использовать ту же командную строку с вводом сочетания ipconfig /all, после чего нажать клавишу ввода (Enter). Только и всего.

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

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

— как он работает и что будет, если его отключить. По умолчанию он включен на любом роутере, будь то TP-Link, Asus, Zyxel Keenetic и так далее. И в большинстве случаев не требует дополнительной настройки. Однако, если мы используем в сети сразу два маршрутизатора, то нужно включить режим DHCP Relay. То есть, чтобы второй работал как «Client» и получал адрес от первого.

Что такое DHCP сервер на роутере?

DHCP сервер — специальная функция, встроенная в wifi роутере, позволяющая ему в автоматическом режиме назначать IP адреса для каждого из подключаемых устройств.

Для чего нужен DHCP сервер?

Как известно, у каждого компьютера, ноутбука, телефона, ТВ, приставки, камеры или любого другого девайса, подключенного к маршрутизатору по кабелю или беспроводному сигналу, имеется свой IP адрес для обмена информацией между собой. Зная IP, можно, например, с компьютера-клиента с Windows подключиться к ТВ приставке на Android и транслировать на нее видео, которое находится в папке на жестком диске ПК.

Также на использовании IP адресов построена и много других более сложных конструкций. Наличие работающего DHCP сервера на роутере избавляет от необходимости вручную прописывать эти адреса для каждого устройства.

Представьте, что его бы не было — тогда каждый раз, когда бы мы подключались к wifi с ноутбука или любого другого гаджета, нужно было бы вручную задавать его в настройках. А если таких компьютеров десятки, сотни. Плюс еще держать где-то всю информацию, какому компьютеру какой адрес назначен. Про гостевой доступ, когда к сети подключаются не зарегистрированные ранее девайсы, вообще можно было бы забыть — не будут же ваши гости, ничего не понимающие в сетевых параметрах, сами настраивать свои ноутбуки и смартфоны на работу в вашей сети.

Если же на роутере включен DHCP сервер, то мы имеем то, к чему привыкли. Просто коннектимся к wifi, вводим пароль и пользуемся. А вся эта непонятная «кухня» с IP адресами и портами остается за кадром.

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

Настройка DHCP сервера на маршрутизаторе

По умолчанию на всех роутерах настройкой DHCP сервера заниматься не нужно. Он всегда включен и оптимизирован для работы. Но кое-что изменить все же можно.

На роутерах TP-Link настройка DHCP сервера находиnся в одноименном разделе меню в старой версии админки или в рубрике «Дополнительные настройки — Сеть — DHCP-сервер» в новой

Разберем каждый из параметров, доступных для настройки:

    Начальный и Конечный IP адрес, или Пул адресов — те значения, которые будут выдаваться вновь подключаемым устройствам. С помощью этого параметра можно ограничить количество одновременно подключаемых гаджетов, с которыми будет работать DHCP сервер.

Не хотим, чтобы к нашему wifi коннектилось более 5 клиентов, ставим от 100 до 104. Своим же собственным компьютерам и смартфонам можем задать IP вручную вне этого диапазона.

Сервер DHCP на маршрутизаторе ASUS

У роутеров ASUS параметры настройки DHCP находятся в разделе «Локальная сеть — DHCP»

Включаем DHCP в роутере Zyxel Keenetic

На маршрутизаторах Zyxel Keenetic DHCP сервер включается в разделе «Домашняя сеть», вкладка «Сегменты». Логика работы здесь основана на том, что можно его включить или отключить отдельно для каждого из типов сетей — основной или гостевой.

Изначально он так же включен, а для тонкой настройки DHCP на Zyxel Keenetic кликаем по строчке с нужной сетью. Здесь все то же самое, что и на других, только время аренды указывается не в минутах, а в секундах.

Если вы купили себе новый маршрутизатор Keenetic, то управление настройками DHCP сервера происходит в разделе «Домашняя сеть». Здесь много всего, поэтому нам нужно найти блока «Параметры IP»

Тут задается IP роутера и маска, а также активируется DHCP сервер. Можно также его отключить совсем или использовать в качестве оного другой роутер (Relay).

Если нажать на «Показать настройки DHCP», то откроются дополнительные параметры, такие как пул адресов, стартовый IP, шлюз и DNS сервера

По конфигурации сервера ДХЦП на Кинетике я нашел также неплохую статью на их сайте поддержки . Можете тоже ее почитать.

DHCP не включен на сетевом адаптере — как настроить клиент Windows 10?

После того, как включили DHCP сервер на роутере, нужно настроить сетевой адаптер компьютера с операционной системой Windows 10, или 7-8.

Бывает, что при попытке подключения к wifi выдаётся ошибка, что DHCP не включен на сетевом адаптере. Это означает, что параметры подключения были назначены вручную.

Для исправления нам надо зайти в «Центр управления сетями» в «Изменение параметров адаптера». Здесь открываем конфигурации «Беспроводного подключения», если ноутбук подключен по wifi, или «Подключения по локальной сети», если компьютер соединен с маршрутизатором кабелем. И в свойствах устанавливаем галочки на «Автоматическое получение» IP адреса и DNS серверов.

Сегодня это все, что я хотел рассказать про включение DHCP сервера на роутере и настройку подключения к нему на компьютере c Windows 10, 7 или 8. Если остались вопросы — можете задавать их в комментариях.

Видео, как включить DHCP сервер роутера

Многие из нас для подключения нескольких клиентов (компьютер, телевизор, планшет, смартфон…) к сети Интернет используют дома или в офисе сетевое устройство. Как правило, для выхода в глобальную сеть используют маршрутизатор, который присваивает каждому подключенному к нему устройству свой уникальный IP-адрес. Назначение уникального сетевого адреса устройству будет выполняться автоматически, если включить DHCP на роутере, а всем клиентам локальной сети в настройках созданного подключения активировать опцию «Получить IP-адрес автоматически».

После этого, все устройства, находящиеся в домашней или офисной сети, будут выходить в Интернет под одним IP-адресом, но в локальной сети они будут иметь разный IP. DHCP очень востребованная опция и если вы решите на втором устройстве с помощью медиа-сервера или захотите передать , то функцию DHCP на маршрутизаторе нужно активировать, иначе все придется настраивать вручную. Используя DHCP-сервер можно .

Чтобы активировать DHCP, нужно . Для этого введите в адресную строку браузера адрес шлюза (обычно 192.168.1.1 или 192.168.0.1), введите в форму логин, пароль и нажмите кнопку «Вход». Кстати, если сетевое устройство раньше использовалось для подключения к сети у другого интерне-провайдера, то рекомендую сначала сделать и подключиться к текущему представителю услуг.

Активация протокола автоматической конфигурации на роутере.

Как правило, по умолчанию данная опция на сетевом устройстве включена, но в силу разных причин у некоторых пользователей она находится не в активном состоянии. Я покажу как включить DHCP на роутере ASUS и TP-Link, а вы по аналогии сможете включить протокол динамической настройки узла на любой другой модели от какого-то ни было производителя. Принцип на всех устройствах один и тот же, лишь оболочка интерфейса разная.

ASUS. После активации в интерфейсе, перейдите в раздел «Локальная сеть» на вкладку «DHCP-сервер» и в пункте «Включить DHCP-сервер» переведите переключатель в положение «Да». На этой же странице вы можете задать начальный и конечный пул IP-адресов. По сути, это диапазон уникальных сетевых адресов, один из которых маршрутизатор будет присваивать устройству при подключении к нему.

Чтобы каждый раз при подключении устройства (компьютер, телевизор, смартфон…) к локальной сети роутер присваивал ему один и тот же сетевой адрес, нужно (описана процедура назначения статического IP детально). Таким образом у планшета, ноутбука и других устройств в домашней или офисной сети будет свой постоянный сетевой адрес, и вы гарантированно избежите любого рода конфликтов.

Например, чтобы дать постоянный IP-адрес ноутбуку, нужно сначала , а после в настройках активировать опцию «Включить назначения вручную» и выбрать из выпадающего списка это устройство. В соседнем поле прописать желаемый свободный IP из диапазона и нажать кнопку добавить. Изменения вступят в силу после нажатия кнопки «Применить» и перезагрузки. Как видите, у меня постоянный IP получает четыре клиента.

TP-LINK. После входа в интерфейс сетевого устройства перейдите на вкладку «DHCP» -> «Настройки DHCP» (Settings). На этой странице вы можете включить DHCP-сервер и задать начальный и конченый IP-адрес в одноименных полях для локальной сети. Обращаю ваше внимание, что на вкладке «Сеть» (Network) — «Локальная сеть» (LAN) указан текущий IP-адрес роутера, следовательно, назначить его какому-то другому устройству он не может.

Поэтому начальный IP- нужно задавать с учетом сетевого узла маршрутизатора и присваивать следующий за ним. Например, если стоит 192.168.1.1, то начальный IP-адрес может быть 192.168.1.2; 192.168.1.3 или как в моем случае 192.168.1.100. Все остальные настройки не являются обязательными, но если нужно, то можете уменьшить срок действия адреса.

По окончанию срока устройство которому был выдан IP попросит его продлить. Диалог происходит незаметно для вас и если в сети очень много клиентов, то в этом случае опция актуальна, поскольку не забивает таблицу. Срок действий адреса, имя, MAC- и IP-адрес вы можете посмотреть в списке подключенных к сети клиентов (DHCP Clients List). Если в локальной сети от 3 до 10 клиентов, то оставьте всё по умолчанию или задайте максимальное значение (2880 минут).

На роутере есть возможность прикрутить клиенту постоянный IP-адрес. Таким образом, при подключении к сети, сетевое устройство будет выдавать устройству один и тот же IP. Для этого нужно перейти на вкладку «Резервирование адресов» (Address Reservation) и нажмите кнопку «Добавить новую». Пропишите MAC-адрес устройства, задайте свободный IP-адрес из имеющегося диапазона. В выпадающем списке «Состояние» поставьте «Включить» и нажмите кнопку «Обновить». Все настройки вступят в силу после перезагрузки роутера.

После того как вы включите DHCP-сервер на роутере, убедитесь, что все клиенты (компьютер, телевизор, приставка…) в настройках имеют статус «Получить IP-адрес автоматически». Пока!

В локальной сети каждое устройство имеет свой уникальный IP-адрес — набор цифр, который идентифицирует его и позволяет другим устройствам обмениваться с ним данными. IP-адреса могут прописываться вручную для каждого устройства, однако это неудобно, так как требует отдельной настройки каждого компьютера для работы с сетью. Чтобы автоматизировать этот процесс, используется протокол динамического конфигурирования хостов – DHCP.

Что такое DHCP

В больших сложно структурированных сетях за раздачу IP-адресов отвечает специальный компьютер — сервер. Для домашней сети или сети небольшого офиса в этом нет необходимости, достаточно обычного роутера.

Все современные роутеры в своём функционале имеют встроенную службу DHCP. Если она настроена и включена, вам не потребуется отдельно настраивать сетевое подключение на компьютере, ноутбуке, планшете или смартфоне. Для беспроводных устройств просто нужно включить Wi-Fi, найти в списке беспроводных сетей свою и ввести пароль для подключения к ней. Если же соединение с сетью осуществляется через кабель, достаточно чтобы он был подключён к сетевой карте вашего компьютера.

Когда в сети появляется новое устройство, служба DHCP проверяет список свободных IP-адресов и присваивает ему один из них. При этом дублирование адресов исключено.

Как настроить DHCP

По умолчанию служба DHCP на роутерах уже настроена. Достаточно подключить клиентское устройство через Wi-Fi или кабель и ему будет автоматически присвоен IP-адрес. Однако может возникнуть потребность изменить настройки DHCP, отключить или включить его. Рассмотрим настройку DHCP на примере роутера TP-link. Для других маршрутизаторов алгоритм будет точно такой же.

Заходим в веб-интерфейс роутера и в меню справа видим пункт «DHCP» и подпункт «Настройка DHCP». На открывшейся вкладке можно изменить параметры, прописанные по умолчанию. Также здесь можно включить или выключить службу DHCP.

Для службы DHCP должен быть задан диапазон используемых IP-адресов, которые вписываются в соответствующие поля. Начальный IP-адрес это соответственно первый адрес диапазона, а конечный IP-адрес — последний. По умолчанию диапазон IP указан с 192.168.0.100 по 192.168.0.199. Но можно прописать, например, с 10.1.1.1 по 10.1.1.99. Можно вообще указать диапазон в пределах двух-трёх адресов, например, по количеству клиентских устройств.

Следующий обязательный пункт — срок действия адреса в минутах. Это время, на которое конкретный IP может присваиваться конкретному устройству. По его истечении IP может быть изменён или присвоен другому устройству.

Остальные пункты заполнять необязательно, DHCP сам укажет нужные параметры для клиентских устройств. Однако эти параметры при желании можно прописать вручную.

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

Домен по умолчанию — это доменное имя вашей сети. В небольших сетях, где используется небольшое количество клиентских устройств, настраивать его не имеет смысла.

Предпочитаемый и альтернативный DNS-сервер обычно указываются провайдером. Но можно вписать сюда публичные DNS-сервера Google – 8.8.8.8 и 8.8.4.4. Это, например, помогает устранить неполадки с доступом к интернету — бывает, что DNS провайдера глючат, подключение есть, но страницы не открываются. Также это часто позволяет обойти блокировки доступа к определённым ресурсам, например, торрентам.

После внесения изменений нажмите кнопку «Сохранить», чтобы применить новые настройки.

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

Чтобы клиентские устройства могли подключиться к службе DHCP, в настройках сетевого подключения у них должен быть установлен параметр «Получить IP-адрес автоматически».

Как включить DHCP

Если служба DHCP на вашем роутере отключена, включить её можно здесь же, в меню DHCP — настройки DHCP. Для этого нужно поставить галочку в пункте «Включить» и нажать кнопку «Сохранить» внизу страницы. Служба будет запущена. Если этого не произошло, перезагрузите роутер.

Как выключить DHCP

Если служба DHCP вам не нужна, когда, например, вы решили вручную прописать IP для всех своих устройств, отключить её можно точно так же. Переходим на вкладку «Настройка DHCP» и ставим галочку в пункте «Отключить». Сохраняем настройки. Теперь клиентские устройства при подключении к вашей сети не смогут получать IP-адреса автоматически.

Список клиентов

Для того, чтобы посмотреть какие именно устройства в данный момент подключены к вашей службе DHCP, в пункте меню «DHCP» веб-интерфейса вашего роутера перейдите в подпункт «Список клиентов DHCP». Здесь вы увидите таблицу с информацией о текущих подключениях.

ID — означает порядковый номер.

Имя клиента — это имя устройства, если оно ему присвоено.

МАС-адрес — соответственно МАС-адрес данного устройства.

Назначенный IP — адрес, который был присвоен устройству сервером DHCP.

Срок действия — соответственно, оставшееся время, в течение которого данный адрес будет действителен.

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

Резервирование адресов

Служба DHCP предоставляет IP-адреса клиентским устройствам на определённый промежуток времени. После этого адрес может быть изменён. Также, подключаясь к сети, каждый компьютер или смартфон каждый раз будет получать новый адрес. А тот адрес, который использовался им ранее, может быть предоставлен другому устройству. Обычно смена адресов происходит незаметно для пользователя и не влияет на работу сети. Однако может возникнуть необходимость сделать так, чтобы у конкретного компьютера IP-адрес не менялся. Это может быть актуально, если вы играете по локальной сети в игры или же данному компьютеру присвоены какие-то специфические функции, которые будут работать только при статичном IP.

Есть простой способ решить эту задачу с помощью DHCP — зарезервировать IP-адрес за конкретным компьютером.

Для этого переходим в подпункт «Резервирование адресов» пункта меню «DHCP». Если ранее вы уже резервировали адреса, здесь будет доступен список устройств, который можно редактировать по мере необходимости. Если же нет, жмём кнопку «Добавить».

В открывшемся окне нужно ввести МАС-адрес устройства и IP, который будет за ним зарезервирован.

Здесь же можно включить или выключить резервирование адреса для этого устройства, изменив соответствующий параметр в пункте «Состояние».

После сохранения параметров вы вернётесь в предыдущее окно. В списке устройств теперь будет видно то, которое вы только что добавили. Нажав «Изменить», вы можете отредактировать параметры резервирования адреса. А с помощью пункта «Удалить» удалить устройство из списка и отменить резервирование.

С помощью кнопок «Включить всё», «Отключить всё» и «Удалить всё» вы можете управлять резервированием адресов для всех устройств из списка.

Для применения сделанных изменений вам понадобится перезагрузить роутер. Напоминание об этом появится в нижней части окна.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *