По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
У облачного провайдера нам необходимо арендовать пул виртуальных серверов для создания на его основе облачного аналога перечисленной серверной части сети. К организованной облачной виртуальной инфраструктуре будут иметь доступ все отделения организации посредством VPN-туннелей.
Все виртуальные машины создаются посредством гипервизора. Аналогичным образом виртуальные машины могут быть созданы и в обычной сети, но также могут использоваться и отдельные физические серверы. Для облачных же услуг технология виртуализации является основополагающей, поэтому в этом разделе подробнее будет рассмотрена технология виртуализации.
В данном случае для организации собственных виртуальных серверов мы пользуемся услугами IaaS (чаще всего в списке услуг именуется как
"аренда виртуальных серверов" или похожим образом). Но для организации серверов для, например, корпоративной почты или базы данных можно воспользоваться уже готовыми PaaS и SaaS-решениями, которые предлагаются некоторыми облачными провайдерами.
При организации облачной инфраструктуры для крупной организации имеет смысл строить частное облако. Даже пусть оно иногда не будет покрывать все потребности организации и периодически придется превращать его в гибридное. Крупным компаниям нужна не столько экономия, столько полный контроль над обрабатываемыми данными - чтобы конфиденциальные данные не вышли за пределы компаний.
Для небольших и средних организаций можно создать облачную инфраструктуру на базе публичного облака. Если компания только начинает свою деятельность, нет смысла покупать физические серверы - можно сразу
арендовать виртуальные и сэкономить средства, которые можно потратить с большей пользой.
Перевод в облако сразу всей инфраструктуры обусловлен еще и взаимосвязями между серверами и скоростью обмена данными между ними. Поэтому следует учитывать взаимосвязь серверов между собой и тот факт, что из любого офиса теперь скорость скачивания файла из того же облачного хранилища будет ограничиваться максимальной скоростью на сетях интернет-провайдера, однако обмен данными в сетях облачного провайдера будет гораздо выше в силу специализированности построенной сети ЦОД.
Виртуальные машины
Гипервизор - это программное или микропрограммное обеспечение, позволяющее виртуализировать системные ресурсы. Виртуальные машины в гипервизоре логически отделены друг от друга и не привязаны к аппаратному обеспечению, поэтому вирусы и ошибки на одной виртуальной машине никак не влияют на другие на том же гипервизоре и на аппаратную часть сервера, и могут быть легко перемещены с одного сервера на другой. Гипервизор по своей сути аналогичен операционной системе.
Существуют 2 типа гипервизоров: гипервизор 1-го типа устанавливается поверх аппаратной части оборудования, 2-й тип устанавливается поверх операционной системы, а также гибридные.
В таблице 1 приведены некоторые примеры гипервизоров.
Таблица 1 Примеры гипервизоров
Гипервизор
Тип
Требуемые ОС для установки
Гостевые ОС
KVM
2
Linux, FreeBSD, illumos
FreeBSD, Linux, Solaris, Windows, Plan 9
VMware:
ESX Server
1
Не требует ОС
Windows, Linux, Solaris, FreeBSD, OSx86 (as FreeBSD), virtual appliances, Netware, OS/2, SCO,
BeOS, Haiku, Darwin, others: runs arbitrary OS
ESXi Server
1
Не требует ОС
Fusion
2
macOS
Server
2
Windows, Linux
Workstation
2
Windows, Linux
VMware ESXi (vSphere)
1
No host OS
Same as VMware ESX Server
Microsoft Hyper-V
Hyper-V
2
Windows
FreeBSD, Linux
(SUSE 10, RHEL 6, CentOS 6)
Hyper-V Server
1
Не требует ОС
Xen
гиб- рид
GNU/Liux, Unix-like
GNU/Linux, FreeBSD, MiniOS, NetBSD, Solaris, Windows 7/XP/Vista/Server 2008 (requires Intel VT-x (Vanderpool) or AMD-V (Pacifica)-capable CPU), Plan 9
VirtualBox
2
Windows, Linux, macOS, Solaris, FreeBSD, eComStation
DOS, Linux, macOS, FreeBSD, Haiku, OS/2, Solaris,
Syllable, Windows, and OpenBSD (with Intel VT-x or AMD-V
PowerVM
?
PowerVM Firmware
Linux PowerPC, x86; AIX, IBM i
Таким образом при проектировании корпоративной сети с помощью виртуальных серверов, следует заранее определиться с типом виртуальной
машины и совместимых с ней операционных систем. Для облачных виртуальных серверов достаточно учитывать совместимые гостевые ОС, обеспечение работоспособности физических серверов и гипервизора берет на себя облачный провайдер.
Создание виртуальной машины или виртуальной сети
Для переноса элементов корпоративной сети в облако необходимо арендовать у облачного провайдера один или несколько виртуальных серверов, на которых будут развернуты необходимые нам системы. Часто достаточно обойтись моделью предоставления услуги VPS/VDS, описанной в разделе 2, арендовав несколько виртуальных серверов для каждого элемента инфраструктуры.
Готовая виртуальная машина (ВМ) на сервере, по сути, будет представлять из себя два файла: файл конфигурации аппаратной части машины и образ диска этой машины, предназначенный для размещения в нем операционной системы. На диске ВМ помимо ОС размещается все программное обеспечение и файлы пользователей. Оба файла, а значит и вся ВМ целиком, могут быть без особых сложностей перенесены или дублированы с одного гипервизора и сервера на другой, что позволяет гибко распределять серверные ресурсы, создавать и восстанавливать резервные копии данных пользователей, а также помогать в процессе миграции на облачную инфраструктуру с уже заранее заготовленными образами систем.
Для создания виртуальной машины на сайте почти любого облачного провайдера можно найти параметры конфигурации и "ползунки" для точной настройки вычислительных ресурсов арендуемой виртуальной машины, подобрав все параметры под цели и задачи сервера. Либо же можно воспользоваться "кейсами" - готовыми наборами настроек. А также часто клиентам предлагаются услуги тестирования, платного или бесплатного,
арендуемого сервера, чтобы оценить его возможности и соответствие требованиям.
Примеры параметров настройки виртуального сервера приведены на рисунке 1. В первом случае идет выбор именно ресурсов сервера, для дальнейшего развертывания на нем "целого парка виртуальных машин". Во втором случае настраивается конкретно виртуальный сервер данный вариант хорошо подойдет.
Разворачивание частного облака позволяет создать и настроить необходимое количество виртуальных машин со своими приложениями, но организация и сопровождение такой структуры будет требовать больших затрат по сравнению с выделенным сервером.
После создания виртуального сервера на рабочем столе рабочей станции появляется значок подключения к виртуальному серверу.
Далее рассмотрим подробнее облачные решения для необходимых нам серверных структур.
Терминальный сервер
Как уже было упомянуто в разделе 1, терминальный сервер будет представлять собой сервер с заранее установленным на него приложением для удаленной работы с ним посредством "тонкого клиента". Например, такая возможность будет востребована при групповой работе с 1С. В таком случае сервер должен быть связан с сервером базы данных. Это означает, что клиенты подключаются к серверу приложения, а сервер приложения взаимодействует с сервером базы данных. Оба сервера должны находиться в облаке, чтобы между ними была хорошая связь.
К терминальному серверу приложений сотрудники могут осуществлять подключение посредством протокола RDP.
К приложению (1С, например) может быть организован доступ посредством публикации базы через web-сервер и, соответственно, работой с web-интерфейсом 1С, подключением с помощью "тонкого" или "толстого" клиента 1С или же подключением ко всему серверу терминалов по протоколам удаленного доступа (RDP и другие).
Файловый сервер
По сути, работа с файловым сервером в облаке ничем не отличается от того, если бы он был в локальной сети. Подключение к файловому серверу обычно осуществляется через протокол FTP (File Transport Protocol) с помощью файлового проводника.
Однако следует тщательно взвесить решение о переносе файлового сервера в облако, т.к. объем данных при сообщении с сервером может сильно повлиять на тарифы услуг Интернет.
Почтовый сервер
В качестве почтового сервера, согласно перечню облачных сервисов, представленному в разделе 2, чаще всего облачные провайдеры используют Microsoft Exchange Server. Он является одним из самых распространенных ПО для корпоративной почты.
Подключение к почтовому серверу может осуществляться аналогично другим терминальный приложениям: web, клиенты или удаленный доступ.
Также требует доступа к базам данных
Виртуальное рабочее место
VDI или виртуальное рабочее место позволяет сотрудникам организации использовать рабочую станцию с любой конфигурацией для работы из любого места и в любое время.
Для подключения к VDI чаще всего используется специальное клиентское ПО, или же иногда это может осуществляться из браузера.
Web-сервер
Формально web-приложение также должно быть соединено c сервером базы данных и может быть разбито на 3 части:
исполняемый модуль на стороне браузера клиента;
исполняемый модуль на стороне сервера;
база данных.
База данных представляет собой систематизированный набор данных для сетей и пользователей и управляемый посредством системы управления базами данных (СУБД). Пример СУБД MySQL.
Сервер печати
Следует учесть, что сервер печати однозначно не требует переноса в облако, т.к. выполняет задачу сообщения с офисным оборудованием, таким как принтеры и факсы.
Конфигурация сервера
Развертывание терминального сервера, а в частности внедрение продуктов 1С одна из самых распространенных задач системны администраторов. И подбор серверной аппаратной конфигурации под данную задачу может служить хорошим примером требований серверных систем к техническим параметрам оборудования.
Рассмотрим несколько вариантов организации и аппаратной конфигураций для развертывания 1С сервера с базой данных.
Можно предложить 3 варианта:
Один сервер с файловой 1С;
Один сервер с виртуальными машинами 1С и БД;
Два физических сервера: один терминальный 1С, второй с БД.
В первом случае будет организован терминальный сервер, на котором будет использоваться файловая версия 1С, таким образом БД будет находиться в файловой системе самого сервера вместе с программой 1С. Для большого количества пользователей разработчик рекомендует использовать систему "клиент-сервер". Организовать терминальный сервер, сервер БД и сервер 1С на одной операционной системе все равно можно, но это будет подвергать сомнению стабильность и информационную безопасность такой системы.
Во втором случае как раз-таки и используется такая система, но оба сервера будут виртуальными на одном физическом. Данный вариант и используется в облачной инфраструктуре. Первый сервер будет содержать серверную часть 1С, второй базу данных.
В третьем случае будут отдельно использоваться два сервера, а базы данных и программа будут разделены.
Для конфигурации общего терминального сервера с двумя виртуальными машинами с расчетом работы примерно на 50 человек должно хватить следующей конфигурации:
10 ядер центрального процессора:
по 6-8 терминальных сессий на одно ядро примерно 8 ядер,
1-2 ядра на базу данных,
дополнительно еще запас, но для облачных серверов можно в любой момент докупить дополнительную вычислительную мощность;
64 Гб оперативной памяти:
операционная система (например, Windows Server) 2 Гб
база данных 4-6 Гб
сервер 1С 2-4 Гб
примерно 700 Мб на каждого пользователя 35 Гб
SSD (для быстрых операций) и SAS (для хранения) память данных в условиях облачной инфраструктуры выбор дисковой подсистемы сводится к выбору конкретного типа дисков и их объемов: быстрых твердотельных накопителей (SSD) для быстрых операций чтения/записи и/или более медленных, но вместительных жестких дисков жестких дисков с интерфейсов SAS, подходящих для хранения баз данных.
Подключение к облаку
Для подключения сотрудников к корпоративному облаку могут применяться комбинации сразу нескольких решений, каждое из которых более детально рассмотрено в таблице 2.
Таблица 2 Способы подключения к инфраструктуре в облаке
Способ подключения
Назначение
Требования со стороны сервера
Требования со стороны клиента
Веб-доступ
Доступ к сайту, расположенному на web-сервере через протокол HTTP/HTTPS
Наличие выделенного терминального сервера + служба TS Web Access
Использование адреса сайта для доступа к ресурсу с помощью браузера
RDP
Доступ к виртуальным серверам
Наличие выделенного терминального сервера
Запуск клиента
RDP
RemoteApp
Доступ к терминальным сессиям
Наличие конфигурационног о файла со списком программ, имеющим доступ к приложению
Запуск сконфигурированного rdp-файла или иконки приложения для подключения к приложению по RDP
Remote access VPN
Подключение каждого пользователя к серверу через VPN-туннель
Наличие сконфигурированного VPN- устройства/сервера.
Запуск ярлыка для подключения к VPN-серверу.
Продолжение таблицы 2
VPN site-to-site
Подключение офиса к серверу через VPN- туннель
Наличие двух сконфигурированных VPN-серверов. Пример: VPN-сервер в компании и VPN- сервер в облаке.
Отсутствие необходимости создания и запуска ярлыка VPN- подключения.
Обращение к ресурсам филиала / центрального офиса / облака напрямую. При обращении к
ресурсам VPN- подключение организуется автоматически на уровне серверов.
DirectAccess
Автоматическая установка связи со всей корпоративной сетью сразу
Наличие одного или более серверов DirectAccess в составе домена. Наличие центра сертификации (PKI). Windows - инфраструктура.
Только Windows
Компьютер клиента должен входить в состав домена.
Отсутствие необходимости в создании и запуске ярлыка подключения.
VDI
Доступ к отдельному виртуальному рабочему месту
Развернутая инфраструктура виртуальных рабочих столов VDI
Пользователь получает свой собственный виртуальный рабочий стол, к которому можно подключаться с помощью тонкого клиента с любой рабочей станции.
Выбор каждого конкретного способа подключения может зависеть от потребностей пользователей, что будет быстрее и удобнее для работы.
Облачная инфраструктура корпоративной сети
Теперь мы можем составить схему облачной инфраструктуры корпоративной сети. Это будет модифицированная схема из раздела 1. Схема представлена на рисунке:
GLBP (Gateway load Balancing Protocol) - это протокол, разработанный компанией Cisco, который обеспечивает распределение нагрузки на несколько роутеров, используя всего 1 виртуальный адрес.
Этот протокол входит в группу FHRP, а теперь давайте напомню какие протоколы в неё входят.
HSRP (Hot Standby Router Protocol) - проприетарный протокол, разработанный Cisco;
VRRP (Virtual Router Redundancy Protocol) - свободный протокол, сделан на основе HSRP;
GLBP (Gateway Load Balancing Protocol).
GLBP обеспечивает балансировку трафика одновременно на несколько роутеров, когда HSRP и VRRP работал только один из 2х роутеров.
Терминология протокола
AVG (Active Virtual Gateway) - активный роутер, который занимается раздачей MAC адресов устройствам. Некий начальник над роутерами в сети GLBP .
Это роль диспетчера, который указывает устройствам, как распределять трафик по средству раздачи им MAC адресов, когда приходит ARP запрос. То есть IP адрес у всех будет единый, а вот MAC адреса будут разные.
AVF (Active Virtual Forwarder) - активный роутер, который пропускает через себя трафик.
Роутер с ролью AVG только один может быть, а вот с ролью AVF любой, при этом AVG может быть и AVF одновременно.
Настройка этого протокола такая же, как и любого протокола группы FHRP на интерфейсе (в данном случает interface e0/0)
Теперь пройдемся по командам
Router(config-if)# glbp 1 ip 192.168.0.254 //включение GLBP
Router(config-if)# glbp 1 priority 110 //установка приоритета 110 (если приоритет будет выше остальных ,то он станет AVG по умолчанию 100)
Router(config-if)# glbp 1 preempt //установит режим приемптинга для AVG ( работает также как и в HSRP, VRRP)
Router(config-if)# glbp 1 weighting 115 //установить вес для AVF в 115 Router(config-if)# glbp 1 load-balancing host-depended | round-robin | weighted
Для чего требуется вес?
Для того, чтобы выбрать кто будет AVF. Чтобы при падении линка до провайдера мы могли передать эту роль кому-нибудь ещё. Далее рассмотрим механизм передачи:
Router(config-if)# glbp 1 weighting 130 lower 20 upper 129
Команда установит вес для Forwarder в 130, а нижняя граница будет 20, верхняя 129. Если вес упадет до 19, то он перестанет быть AVF, а если вес возрастет выше 129 после падения, то он снова превратиться в AVF. По умолчанию lower равен 1, upper равен 100.
Данная команда используется совместно с Track:
Router(config)# track 1 interface e0/1 line-protocol
Router(config)# int e0/0
Router(config-if)# glbp 1 weighting track 1 decrement 111
Как проверить стал ли роутер AVG?
R2(config)#do show glbp
Ethernet0/0 - Group 1
State is Active
...
Смотрим, состояние Active, а это значит он и стал AVG. Взглянем на второй:
R3(config-if)#do sh glbp
Ethernet0/0 - Group 1
State is Standby
...
Говорит о том, что он не стал AVG.
При просмотре команды нужно обращать внимание на State is Active / Listen / Standby. Где AVG это Active, запасной Standby, а тот, кто в выборах не участвует Listen. То есть если роутер State is Active накроется, то его место займет маршрутизатор с состоянием State is Standby. При этом каждый роутер является AVF.
3 режима AVG
Round Robin (по кругу) - это значит, что балансирует равномерно, раздавая каждому устройству новый MAC по списку, а как заканчивается список, начинает заново. Когда в сети просыпается устройство или ARP table устаревает, то у него нет mac шлюза по умолчанию. Он формирует ARP запрос, где запрашивает эти данные. Отвечает ему только AVG, который выдает виртуальные mac адреса за роутеры в группе glbp. Одному ПК он выдаст свой ,потому что он еще и AVF , следующему ПК - R3 mac-address выдаст ,следующему устройству R4 mac-address .
Weighted (утяжеленный) - когда AVF имеет больший вес, то принимает большую нагрузку, чем остальные роутеры.
Host dependent (Зависимое устройство) - присваивает постоянный MAC определенным устройствам. Допустим к нему обратился VPC10 за MAC адресом и AVG выдает его, а также запоминает, что ему выдает только этот адрес.
Как это работает? Представим, что в нашей топологии:
Роутер R3 (State is Listen) умрет, то тогда его клиентов возьмет любой из группы, либо R2, либо R4.
Роутер R2 (State is Active) умрет, то тогда роль AVG займет роутер R4 (State is Standby), а также возьмет его клиентов (или распределит между R3/R4). R3 станет запасным AVG.
Роутер R4 (State is Standby) умрет, то его клиентов возьмет один из R2/R3 и R3 (State is Listen) станет State is Standby.
show glbp на разных роутерах
R2(config-if)#do sh glbp
Ethernet0/0 - Group 1
State is Active
1 state change, last state change 00:06:48
Virtual IP address is 192.168.0.254
Hello time 3 sec, hold time 10 sec
Next hello sent in 2.176 secs
Redirect time 600 sec, forwarder timeout 14400 sec
Preemption disabled
Active is local
Standby is 192.168.0.3, priority 100 (expires in 8.576 sec)
Priority 100 (default)
Weighting 100 (default 100), thresholds: lower 1, upper 100
Load balancing: round-robin
Group members:
aabb.cc00.2000 (192.168.0.1) local
aabb.cc00.3000 (192.168.0.2)
aabb.cc00.4000 (192.168.0.3)
There are 3 forwarders (1 active)
Forwarder 1
State is Active
1 state change, last state change 00:06:37
MAC address is 0007.b400.0101 (default)
Owner ID is aabb.cc00.2000
Redirection enabled
Preemption enabled, min delay 30 sec
Active is local, weighting 100
Forwarder 2
State is Listen
MAC address is 0007.b400.0102 (learnt)
Owner ID is aabb.cc00.3000
Redirection enabled, 599.104 sec remaining (maximum 600 sec)
Time to live: 14399.104 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is 192.168.0.2 (primary), weighting 100 (expires in 9.216 sec)
Forwarder 3
State is Listen
MAC address is 0007.b400.0103 (learnt)
Owner ID is aabb.cc00.4000
Redirection enabled, 598.592 sec remaining (maximum 600 sec)
Time to live: 14398.592 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is 192.168.0.3 (primary), weighting 100 (expires in 10.016 sec)
В данный момент я подключил 3 роутера в группу glbp 1 и если посмотреть на вывод, то он показывает отношение 1 роутера к другому. То есть R2 по отношению к R3 и R4 является active, а остальные listen . Если глянуть на R3 и R4 ,то картина будет с точностью наоборот. Это сделано для того, чтобы наблюдать, какой роутер взял на себя роль AVF в случае падения, тогда при падении один из Forwarder будет в состоянии Active.
Режим preempt
Этот режим, как и в других протоколах типа FHRP помогает роутеру настроить нужную роль. В GLBP это будет касаться AVG и AVF. Для AVG по умолчанию он отключен, а для AVF по умолчанию включен, с задержкой 30 секунд.
preempt для AVG:
R2(config)# int e0/0
R2(config-if)# glbp 1 preempt
preempt для AVF:
R2(config)# int e0/0
R2(config-if)# glbp 1 forwarder preempt delay minimum 60
Настройка таймеров
Настройка интервалов в группе GLBP:
R2(config-if)# glbp 1 timers 3 10
Настройка пароля
//Аутентификация через md5 по хешу
R2(config-if)#glbp 1 authentication md5 key-string CISCO
//Аутентификация в открытом виде
R2(config-if)#glbp 1 authentication text CISCO
Диагностика
R2# show glbp //показать общую информацию по протоколу группы FHRP
R2# show glbp brief //показывает краткую таблицу по всем роутерам группы GLBP
----------------------------------------------------------------------------------------------------------------------------
R2#show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Et0/0 1 - 110 Standby 192.168.0.254 192.168.0.4 local
Et0/0 1 1 - Active 0007.b400.0101 local -
Et0/0 1 2 - Listen 0007.b400.0102 192.168.0.2 -
Et0/0 1 3 - Listen 0007.b400.0103 192.168.0.3 -
Et0/0 1 4 - Listen 0007.b400.0104 192.168.0.4 -
Важное
В топологии GLBP может пропускать максимум 4 роутера, если подключить 5, то он попадет в таблицу GLBP, но пропускать через себя трафик не станет. А будет просто ждать, пока умрет какой-либо AVF.
В этой статье мы рассмотрим настройку BGP-оповещения для Network Layer Reachability Information (NLRI), а также конфигурацию политики маршрутизации BGP.
Предыдущие статьи цикла про BGP:
Основы протокола BGP
Построение маршрута протоколом BGP
Формирование соседства в BGP
Видео: Основы BGP за 7 минут
Оповещения NLRI
Прежде чем мы начнем настраивать оповещения NLRI, используя различные команды, давайте сначала обсудим старую функцию BGP, которую Cisco отключает по умолчанию. Эта функция называется синхронизацией BGP. Для проверки того, что Cisco отключила эту функцию на вашем устройстве, выполните команду show running-configuration на одном из устройств BGP, и в выводимой информации, под пунктом «процессы» BGP, вы увидите сообщение no synchronization. Если эта функция включена, функция синхронизации не позволяет спикеру BGP вводить префиксы в BGP, если нет коррелированной записи для префикса в базовом IGP (или статических маршрутах). Это помогает предотвратить ситуации типа "черная дыра" (black hole), когда устройства на маршруте не работают с BGP и не могут переадресовать префикс BGP, потому что у них нет маршрута к этому префиксу из их IGP. Эта функция отключена по умолчанию из-за создания множества различных механизмов масштабируемости, существующих в BGP, которые позволяют настроить топологию iBGP без требования полной сетки одноранговых узлов iBGP. Еще одна причина, по которой он отключен, заключается в том, что он поощряет перераспределение префиксов BGP в базовый IGP, и это не безопасно.
Существует причина, по которой Cisco уходит от использования команды network для настройки IGPs в CLI. Не очень хорошая идея в программировании, чтобы одна команда выполняла очень разные вещи, и когда она используется в разных областях. Это относится и к команде network. При использовании в IGP команда включает протокол на интерфейсе (а также влияете на то, какие префиксы объявляются), но в BGP у команды network другое назначение. Она не включает BGP на определенных интерфейсах, вместо этого она объявляет префикс, который существует (каким-то образом) на локальном устройстве, и вводит его в BGP.
Хотя префикс, который вы могли бы объявить в BGP, чаще всего встречается в вашем IGPs в таблице маршрутизации. Вы можете использовать другие методы для создания префикса для оповещения. Например, вы можете создать интерфейс обратной связи, который обладает префиксом сети, который вы хотите объявить. Или вы можете создать статический маршрут или даже статический маршрут, указывающий на Null0.
Одна маленькая хитрость, связанная с командой network в BGP, заключается в том, что, если ваша маска подсети для вашего префикса не находится на классовой границе IP- адреса (например, 10.0.0.0/8), то вам нужно не забыть использовать ключевое слово mask и указать правильную маску при использовании команды. Пример 1 показывает создание двух петлевых интерфейсов и объявление их префиксов в BGP. Обратите внимание, что этот пример также показывает проверку этих префиксных объявлений на маршрутизаторе ATL.
Пример 1: Использование команды Network в BGP
TPA1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
TPA1(config)#interface loopback 192
TPA1(config-if)#ip address 192.168.1.1 255.255.255.0
TPA1(config-if)#exit
TPA1(config)#interface loopback 172
TPA1(config-if)#ip address 172.16.10.1 255.255.255.0
TPA1(config-if)#exit
TPA1(config)router bgp 100
TPA1(config-router)#network 192.168.1.0
TPA1(config-router)#network 172.16.10.0 mask 255.255.255.0
TPA1(config-router)#end
TPA1#
ATL#
ATL#show ip bgp
Хотя команда network проста и удобна, она не была бы эффективной, если бы у вас было много префиксов для оповещения. Другой вариант- перераспределить префиксы в BGP из IGP или статических маршрутов. Пример 2 демонстрирует перераспределение префиксов, которые были получены через EIGRP, в BGP. Обратите внимание при проверке, что исходный код для этих префиксов отображается как (?) указывает на неизвестность.
Пример 2: перераспределение префиксов в BGP
TPA1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
TPA1(config)router bgp 100
TPA1(config-router)#redistribute eigrp 100
TPA1(config-router)#end
TPA1#
ATL#show ip bgp
Когда вы начинаете объявлять (оповещать) NLRI в BGP, вы можете столкнуться с префиксами в вашей таблице BGP (показанной с show ip bgp), которые имеют код состояния (r) вместо ожидаемого допустимого кода состояния (*). Код состояния (r) указывает на сбой RIB, означающий, что BGP попытался поместить префикс в таблицу BGP, но не смог из- за какой-то проблемы.
Наиболее распространенной причиной отказа RIB является административное расстояние (AD). Например, IBGP узнал префиксы несущие ужасные объявления AD из 200. Это означает, что если ваш маршрутизатор получил префикс через IGP (даже такой плохой, как RIP с AD 120), то он будет предпочтительнее префикса IBGP. В результате протокол BGP получивший это объявление AD, не отметит префикс как действующий. Обратите внимание, что это, как правило, не происходит с префиксами EBGP-learned, поскольку они имеют очень предпочтительное объявление 20 (по умолчанию).
Очень часто, если желательно иметь префикс в IGP и BGP, администраторы будут манипулировать значениями AD на своих маршрутизаторах, чтобы улучшить AD IBGP. Например, в случае RIP и BGP администратор мог бы установить AD изученных маршрутов IBGP на 119, чтобы сделать их предпочтительными по сравнению с используемым IGP.
В дополнение к выявлению сбоев RIB в результатах команды show ip bgp, вы можете использовать более прямую команду show ip bgp rib-failure, чтобы увидеть любые префиксы в этом состоянии. Это особенно полезно в случае массивных таблиц BGP.
Настройка политики маршрутизации BGP
Довольно часто встречаются топологии, в которых вы явно не хотите объявлять префиксы в своей таблице BGP, или вы не хотите получать определенные префиксы от узла BGP. К счастью, в вашем распоряжении есть много инструментов для этого. Например, вот только некоторые методы, которые вы могли бы использовать для фильтрации префиксов:
Distribute lists
Extended ACLs
Prefix lists
AS Path filters
Route maps
Пример 3 демонстрирует один из методов фильтрации. Выбран подход route map, потому что все (и это правильно) любят карты маршрутов.
Пример 3: Использование route map в качестве префиксного фильтра в BGP
ATL# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
ATL(config)#ip access-list standard MYPREFIX
ATL(config-std-nacl)#permit 192.168.1.0 0.0.0.255
ATL(config-std-nacl)#exit
ATL(config)#route-map MYMAP deny 10
ATL(config-route-map)#match ip address MYPREFIX
ATL(config-route-map)#exit
ATL(config)#route-map MYMAP permit 20
ATL(config-route-map)#exit
ATL(config)#router bqp 200
ATL(config-router)#neighbor 10.10.10.1 route-map MYMAP in
ATL(config-router)#end
ATL#
ATL# clear ip bqp * soft
ATL# show ip bqp
Обратите внимание, перед проверкой я запускаю команду clear ip bgp * soft. Это гарантирует, что устройство сразу же обновит информацию BGP для меня, так что мне не придется ждать истечения таймера, когда дело дойдет до конвергенции BGP на новых манипуляциях с политикой, которые мы сделали.
Помните, что BGP использует множество различных атрибутов пути вместо простой метрики, чтобы предоставить вам возможность легко настроить способ, по которому происходит маршрутизация. Ниже приведены некоторые из атрибутов пути, которыми вы могли бы манипулировать, чтобы настроить политику:
Weight
MED
Local Preference
AS Path
Можно спросить себя, как AS Path могут быть использованы в целях маршрутизации. Поскольку манипуляция AS Path часто выполняется с помощью AS Path Prepending. Вы отравляете префикс, добавляя свой собственный номер AS к пути, чтобы сделать более длинным (менее предпочтительным) AS Path. Как и большинство наших манипуляций с атрибутом пути, это легко сделать с помощью карты маршрута.
Давайте рассмотрим пример использования Local Preference для манипулирования политикой. Мы часто используем Local Preference, чтобы повлиять на то, как мы будем направлять исходящий трафик к префиксу BGP. Мы делаем это, устанавливая значения Local Preference, входящие по нескольким путям. Прежде чем мы начнем, поймите, что Local Preference - это значение, которое рассматривается довольно высоко в процессе принятия решения о наилучшем пути BGP, более высокое значение предпочтительно, и значения передаются только в обновлениях IBGP. Именно так имя LOCAL вошло в название Local Preference.
Для начала я объявил тот же префикс в AS 200 (ATL и ATL2) от маршрутизаторов TPA1 и TPA2 AS 100. Глядя на пример 4, Вы можете видеть, что этот префикс (192.168.1.0) может быть достигнут с помощью следующего прыжка 10.10.10.1 и что это предпочтительный путь. Альтернативный путь, который будет использоваться в случае неудачи этого пути, будет проходить через следующий переход 10.21.21.1.
Пример 4: Подготовка к использованию Local Preference
ATL# show ip bqp
Теперь пришло время поэкспериментировать и изменить данное поведение с помощью примера манипуляции атрибутом пути. Мой подход будет состоять в том, чтобы определить префикс, которым мы хотим манипулировать (192.168.1.0), и поднять значение локального предпочтения, чтобы оно было больше, чем значение по умолчанию 100 для пути к TPA2 на следующем прыжке 10.21.21.1. Я делаю это, манипулируя префиксом, когда он входит через путь 10.21.21.1 .
Пример 5 показывает эту конфигурацию.
ATL# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
ATL(config)#ip access-list standard OURPREFIX
ATL(config-std-nacl)#permit 192.168.1.0 0.0.0.255
ATL(config-std-nacl)#exit
ATL(config)#route-map SETLOCALPREF permit 10
ATL(config-route-map)#match ip address OURPREFIX
ATL(config-route-map)#set local-preference 110
ATL(config-route-map)#exit
ATL(config)#route-map SETLOCALPREF permit 20
ATL(config-route-map)#exit
ATL(config)#router bqp 200
ATL(config-router)#neighbor 10.21.21.1 route-map SETLOCALPREF in
ATL(config-router)#end ATL#
ATL# clear ip bqp * soft
ATL# show ip bqp
Обратите внимание, что предпочтительный путь теперь проходит через следующий переход 10.21.21.1, как мы и хотели. Для этого префикса также отображается значение Local Preference - 110. Это более высокое значение является предпочтительным и изменяет выбор, сделанный процессом выбора наилучшего пути BGP.