Как ускорить сходимость BGP с помощью отслеживания следующего перехода

Рубрики:

Метки:

AS, AS_PATH, BGP, blog, Cisco, Cisco CLI, Cisco IOS, Cisco IOS CLI, eBGP, iBGP, IP, IPV4, Routing, команды, сетевые технологии

Команды LINUX «от A до Z» — настольная книга с примерами

Рассмотрим, как ускорить сходимость BGP с помощью отслеживания следующего перехода. В таблице BGP для каждого маршрута должен существовать и быть доступен следующий переход (next hop). Если он отсутствует — маршрут будет недействителен. BGP использует инструмент, который проверяет все маршруты в таблице BGP каждые 60 секунд. Он выполняет поиск лучшего маршрута, проверяет адреса следующего перехода и определяет, достижим ли следующий переход.

Содержание:

Введение
Пример с iBGP
Пример с eBGP
Выводы

Введение

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

Отслеживание адреса следующего перехода в BGP — это функция, которая уменьшает время конвергенции BGP, отслеживая изменения адреса следующего перехода BGP в таблице маршрутизации. Функция основана на событиях, поскольку она обнаруживает изменения в таблице маршрутизации. Когда изменения обнаружены, сразу планируется проверка адреса следующего перехода для его установки в таблицу BGP.

После обнаружения изменения, сканирование адреса next hop имеет задержку по умолчанию в 5 секунд. Следующее отслеживание адреса перехода также поддерживает dampening penalties. Это увеличивает задержку сканирования адреса next hop, которые продолжают меняться в таблице маршрутизации.

Пример с iBGP

Топология

Исследуемая топология состоит из трёх маршрутизаторов (Cisco 1941 с образом Cisco IOS Release 15.4 IP Base). Допускается использование маршрутизаторов других моделей, а также других версий операционной системы Cisco IOS. В зависимости от модели устройства и версии Cisco IOS, доступные команды и результаты их выполнения могут отличаться от тех, которые показаны в этой статье.

Схема топологии следующая:

Курсы Python с нуля до DevOps на практике за 1,5 часа

В топологии представлены три маршрутизатора в AS 123 с настроенным протоколом iBGP. Каждый маршрутизатор имеет сеть loopback с адресами на интерфейсах, которые рассылаются в OSPF. Эти IP-адреса используются IGP в качестве адресов следующего перехода. Между R2 и R3 есть сеть 192.168.20.0/24, которая будет объявляться в BGP.

Настройка маршрутизатора R1

hostname R1
no ip domain-lookup
line con 0
logging synchronous
exec-timeout 0 0

interface GigabitEthernet0/0
ip address 192.168.10.1 255.255.255.0
no shutdown
exit

interface GigabitEthernet0/1
ip address 192.168.30.1 255.255.255.0
no shutdown
exit

interface Loopback0
ip address 1.1.1.1 255.255.255.0
no shutdown
exit

router ospf 1
network 1.1.1.0 0.0.0.255 area 0
network 192.168.10.0 0.0.0.255 area 0
network 192.168.30.0 0.0.0.255 area 0
exit

router bgp 1
neighbor 2.2.2.2 remote-as 1
neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 1
neighbor 3.3.3.3 update-source Loopback0

Настройка маршрутизатора R2

hostname R2
no ip domain-lookup
line con 0
logging synchronous
exec-timeout 0 0

interface GigabitEthernet0/0
ip address 192.168.10.2 255.255.255.0
no shutdown
exit

interface GigabitEthernet0/1
ip address 192.168.20.2 255.255.255.0
no shutdown
exit

interface Loopback0
ip address 2.2.2.2 255.255.255.0
no shutdown
exit

router ospf 1
network 2.2.2.0 0.0.0.255 area 0
network 192.168.10.0 0.0.0.255 area 0
exit

router bgp 1
network 192.168.20.0 mask 255.255.255.0
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 update-source Loopback0
neighbor 3.3.3.3 remote-as 1
neighbor 3.3.3.3 update-source Loopback0

Настройка маршрутизатора R3

hostname R3
no ip domain-lookup
line con 0
logging synchronous
exec-timeout 0 0

interface GigabitEthernet0/0
ip address 192.168.20.3 255.255.255.0
no shutdown
exit

interface GigabitEthernet0/1
ip address 192.168.30.3 255.255.255.0
no shutdown
exit

interface Loopback0
ip address 3.3.3.3 255.255.255.0
no shutdown
exit

router ospf 1
network 3.3.3.0 0.0.0.255 area 0
network 192.168.30.0 0.0.0.255 area 0
exit

router bgp 1
network 192.168.20.0 mask 255.255.255.0
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 update-source Loopback0
neighbor 2.2.2.2 remote-as 1
neighbor 2.2.2.2 update-source Loopback0

Применение отслеживания следующего перехода

Как объяснялось ранее, BGP использует инструмент, который запускается каждые 60 секунд. Посмотрим на следующий вывод маршрутизатора R1. В привилегированном режиме включим отладку:

debug ip bgp
BGP debugging is on for address family: IPv4 Unicast

Через несколько десятков секунд появятся следующие сообщения, которые будут повторяться каждые 60 секунд:

*Jan 5 12:30:35.447: BGP: topo global:IPv4 Unicast:base Scanning routing tables
*Jan 5 12:30:35.447: BGP: topo global:IPv4 Multicast:base Scanning routing tables
*Jan 5 12:30:35.448: BGP: topo global:L2VPN E-VPN:base Scanning routing tables
*Jan 5 12:30:35.448: BGP: topo global:MVPNv4 Unicast:base Scanning routing tables

Курсы Git за час: руководство для начинающих DevOps / DevNet инженеров

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

Отслеживание следующего перехода включено по умолчанию, поэтому его не нужно настраивать. Ниже можно увидеть две команды:

show run all | include nexthop trigger
bgp nexthop trigger enable
bgp nexthop trigger delay 5

Функцию можно отключить, добавив no к первой команде. Второе значение — задержка при запуске проверки следующего перехода (5 секунд) можно изменить.

Дальше необходимо видеть отслеживание следующего перехода в действии, поэтому включим следующие две отладки на R1:

debug ip routing
IP routing debugging is on

debug ip bgp events nexthop
BGP nexthop events debugging is on

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

Вот текущая таблица BGP R1:

show ip bgp

BGP table version is 2, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
* i 192.168.20.0 3.3.3.3 0 100 0 i
*>i 2.2.2.2 0 100 0 i

Сеть 192.168.20.0/24 рассылается как на R2, так и на R3, но использует путь через R3. Давайте отключим интерфейс loopback на R3, чтобы узнать, что произойдет далее:

interface loopback 0
shutdown

На R1 появляются следующие сообщения:

*Jan 5 12:59:46.068: RT: del 3.3.3.3 via 192.168.30.3, ospf metric [110/2]
*Jan 5 12:59:46.069: RT: delete subnet route to 3.3.3.3/32
*Jan 5 12:59:46.071: EvD: accum. penalty decayed to 0 after 265 second(s)
*Jan 5 12:59:46.071: BGP(0): IPv4 Unicast::base nexthop modified, reuse in 00:00:19, 19000 , scheduling nexthop scan in 5 secs
R1#
*Jan 5 12:59:51.071: BGP: BGP Event nhop timer
*Jan 5 12:59:51.071: BGP: tbl IPv4 Unicast:base Nexthop walk
*Jan 5 12:59:51.072: BGP(IPv4 Unicast): CHANGED Path metric 0 Path aigp-metric 0 nexthop: 3.3.3.3

Как только OSPF выяснит, что сеть 3.3.3.0/24 недостижима, маршрут удаляется из таблицы маршрутизации. Сразу же после этого события можно увидеть, что BGP планирует проверку следующего перехода через 5 секунд.

Как только эти 5 секунд истекли, он меняет адрес следующего перехода на 2.2.2.2 (R2) и добавляет это изменение в таблицу маршрутизации. Этот процесс намного быстрее, чем проверка перехода BGP, который запускается каждые 60 секунд.

Используем команду clear ip bgp * и проверяем как выглядит таблица BGP R1:

show ip bgp

BGP table version is 2, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*>i 192.168.20.0 2.2.2.2 0 100 0 i

Обратите внимание, теперь маршрутизатор использует адрес 2.2.2.2 для перехода к сети 192.168.20.0/24.

Попробуем сделать ещё одну вещь. Отключим loopback-интерфейс R2 так, чтобы следующий адрес перехода 2.2.2.2 был неверным:

interface Loopback 0
shutdown

Посмотрим на новые отладочные сообщения R1:

*Jan 5 13:03:32.544: RT: del 2.2.2.2 via 192.168.10.2, ospf metric [110/2]
*Jan 5 13:03:32.545: RT: delete subnet route to 2.2.2.2/32
*Jan 5 13:03:32.547: EvD: accum. penalty decayed to 0 after 226 second(s)
*Jan 5 13:03:32.547: BGP(0): IPv4 Unicast::base nexthop modified, reuse in 00:00:19, 19000 , scheduling nexthop scan in 5 secs
R1#
*Jan 5 13:03:37.548: BGP: BGP Event nhop timer
*Jan 5 13:03:37.549: BGP: tbl IPv4 Unicast:base Nexthop walk
*Jan 5 13:03:37.549: BGP(IPv4 Unicast): CHANGED Path metric 0 Path aigp-metric 0 nexthop: 2.2.2.2
*Jan 5 13:03:37.550: RT: del 192.168.20.0 via 2.2.2.2, bgp metric [200/0]
*Jan 5 13:03:37.551: RT: delete network route to 192.168.20.0/24

OSPF обнаружил изменение, и 2.2.2.0/24 удаляется из таблицы маршрутизации. Сразу после этого BGP планирует выполнить сканирование следующего перехода через 5 секунд, и по истечении таймера он удаляет маршрут 192.168.20.0/24 из таблицы маршрутизации.

Вот как теперь выглядит таблица BGP R1:

show ip bgp
BGP table version is 24, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
* i 192.168.20.0 2.2.2.2 0 100 0 i

Запись все ещё существует, поскольку таймер удержания iBGP ещё не истек, но сеть больше не существует. Можно проверить это, заглянув в таблицу маршрутизации R1:

show ip route 2.2.2.2
% Network not in table

show ip route 192.168.20.0
% Network not in table

Механизм BGP Route Dampening

Что делать, если в сети имеется нестабильный маршрут (flapping route), который заставляет меняться адрес следующего перехода снова и снова? Это означает, что таблица BGP будет обновляться через каждые 5 секунд снова и снова. Чтобы это предотвратить, можно использовать механизм BGP Route Dampening, его по умолчанию поддерживает отслеживание следующего перехода.

Каждый раз, когда меняется адрес next hop, к penalty добавляется значение 500. Когда penalty ниже 950, сканирование следующего перехода планируется каждые 5 секунд. Когда penalty выше 950, сканирование следующего перехода планируется на тот момент, когда значение penalty снизится на 100 или ниже.

Penalty уменьшается вдвое каждые 8 секунд. Если текущий penalty равен 2000, а через 8 секунд — 1000, то ещё через 8 секунд будет значение 500. Эти значения не могут быть настроены.

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

Отключим отладку IP-маршрутизации на R1:

no debug ip routing
IP routing debugging is off

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

ip route 2.2.2.0 255.255.255.0 null0
no ip route 2.2.2.0 255.255.255.0 null0

Теперь посмотрим на отладку R1. В первый раз инструмент проверки следующего перехода запланировал проверку через 5 секунд (scheduling next hop scan in 5 secs). Это нормальное поведение механизма:

*Feb 21 20:52:33.539: EvD: accum. penalty decayed to 114 after 21 second(s)
*Feb 21 20:52:33.540: BGP(0): IPv4 Unicast::base nexthop modified, reuse in 00:00:21, 21000 , scheduling nexthop scan in 5 secs
*Feb 21 20:52:34.699: EvD: accum. penalty decayed to 563 after 1 second(s)
*Feb 21 20:52:34.699: BGP(0): IPv4 Unicast::base nexthop modified, reuse in 00:00:28, 28000 , timer already running

Обратите внимание на временные метки. Спустя 5 секунд была произведена проверка следующего перехода:

*Feb 21 20:52:38.540: BGP: BGP Event nhop timer
*Feb 21 20:52:38.541: BGP: tbl IPv4 Unicast:base Nexthop walk

Снова пропишем и удалим статический маршрут следующего перехода 2.2.2.0, чтобы значение penalty продолжало расти:

*Feb 21 20:52:38.976: EvD: accum. penalty decayed to 751 after 4 second(s)
*Feb 21 20:52:38.976: BGP(0): IPv4 Unicast::base nexthop modified, reuse in 00:00:30, 30000 , scheduling nexthop scan in 30 secs
*Feb 21 20:52:39.530: EvD: accum. penalty decayed to 1147 after 1 second(s)
*Feb 21 20:52:39.530: BGP(0): IPv4 Unicast::base nexthop modified, reuse in 00:00:32, 32000 , timer already running

На данный момент penalty — 1147, что превышает значение по умолчанию 950. Теперь проверка следующего перехода запланирована через 30 секунд (scheduling nexthop scan in 30 secs). Именно тогда penalty должен иметь значение 100.

Как только эти 30 секунд истекли, выполнилась проверка:

*Feb 21 20:53:08.976: BGP: BGP Event nhop timer
*Feb 21 20:53:08.976: BGP: tbl IPv4 Unicast:base Nexthop walk

Если сеть продолжает «прыгать», значение penalty будет расти всё выше и выше, а проверка следующего перехода будет отложена на ещё больший срок.

Пример с eBGP

Топология

Схема топологии следующая:

Настройка маршрутизатора R1

hostname R1
no ip domain-lookup
line con 0
logging synchronous
exec-timeout 0 0

interface GigabitEthernet0/0
ip address 192.168.10.1 255.255.255.0
no shutdown
exit

interface GigabitEthernet0/1
ip address 192.168.30.1 255.255.255.0
no shutdown
exit

interface Loopback0
ip address 1.1.1.1 255.255.255.0
no shutdown
exit

ip route 2.2.2.0 255.255.255.0 192.168.10.2
ip route 3.3.3.0 255.255.255.0 192.168.30.3

router bgp 1
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 ebgp-multihop 3
neighbor 2.2.2.2 update-source loopback 0
neighbor 3.3.3.3 remote-as 3
neighbor 3.3.3.3 ebgp-multihop 3
neighbor 3.3.3.3 update-source loopback 0
network 192.168.10.0 mask 255.255.255.0
network 192.168.30.0 mask 255.255.255.0
network 1.1.1.0 mask 255.255.255.0

Настройка маршрутизатора R2

hostname R2
no ip domain-lookup
line con 0
logging synchronous
exec-timeout 0 0

interface GigabitEthernet0/0
ip address 192.168.10.2 255.255.255.0
no shutdown
exit

interface GigabitEthernet0/1
ip address 192.168.20.2 255.255.255.0
no shutdown
exit

interface Loopback0
ip address 2.2.2.2 255.255.255.0
no shutdown
exit

ip route 1.1.1.0 255.255.255.0 192.168.10.1
ip route 3.3.3.0 255.255.255.0 192.168.20.3

router bgp 2
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 ebgp-multihop 3
neighbor 1.1.1.1 update-source loopback 0
neighbor 3.3.3.3 remote-as 3
neighbor 3.3.3.3 ebgp-multihop 3
neighbor 3.3.3.3 update-source loopback 0
network 192.168.10.0 mask 255.255.255.0
network 192.168.20.0 mask 255.255.255.0
network 2.2.2.0 mask 255.255.255.0

Настройка маршрутизатора R3

hostname R3
no ip domain-lookup
line con 0
logging synchronous
exec-timeout 0 0

interface GigabitEthernet0/0
ip address 192.168.20.3 255.255.255.0
no shutdown
exit

interface GigabitEthernet0/1
ip address 192.168.30.3 255.255.255.0
no shutdown
exit

interface Loopback0
ip address 3.3.3.3 255.255.255.0
no shutdown
exit

ip route 1.1.1.0 255.255.255.0 192.168.30.1
ip route 2.2.2.0 255.255.255.0 192.168.20.2

router bgp 3
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 ebgp-multihop 3
neighbor 2.2.2.2 update-source loopback 0
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 ebgp-multihop 3
neighbor 1.1.1.1 update-source loopback 0
network 192.168.30.0 mask 255.255.255.0
network 192.168.20.0 mask 255.255.255.0
network 3.3.3.0 mask 255.255.255.0

Применение отслеживания следующего перехода

На R1 включим отладки для просмотра изменений в таблице маршрутизации и отслеживания следующего перехода:

debug ip bgp
BGP debugging is on for address family: IPv4 Unicast

debug ip routing
IP routing debugging is on

debug ip bgp events nexthop
BGP nexthop events debugging is on

Отключим интерфейс loopback на R2, чтобы запустить BGP Next Hop Address Tracking:

interface loopback 0
shutdown

На R1 видны следующие уведомления отладки:

*Feb 29 18:56:17.031: RT: updating bgp 2.2.2.0/24 (0x0) :
via 3.3.3.3 0 1048577

*Feb 29 18:56:17.032: RT: rib update return code: 17

Был запущен процесс отслеживания адреса следующего перехода. Посмотрим таблицу BGP R1:

show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 0.0.0.0 0 32768 i
r 3.3.3.0/24 2.2.2.2 0 2 3 i
r> 3.3.3.3 0 0 3 i
* 192.168.10.0 2.2.2.2 0 0 2 i
*> 0.0.0.0 0 32768 i
* 192.168.20.0 3.3.3.3 0 0 3 i
*> 2.2.2.2 0 0 2 i
* 192.168.30.0 3.3.3.3 0 0 3 i
*> 0.0.0.0 0 32768 i

Записи все ещё существуют, поскольку таймер удержания eBGP ещё не истек, но сеть больше не существует. Через некоторый промежуток времени Next Hop для записей поменяются. Также можно использовать команду clear ip bgp *:

show ip bgp
Network Next Hop Metric LocPrf Weight Path
* 1.1.1.0/24 0.0.0.0 0 32768 i
* 3.3.3.0/24 3.3.3.3 0 0 3 i
* 192.168.10.0 3.3.3.3 0 3 2 i
* 0.0.0.0 0 32768 i
* 192.168.20.0 3.3.3.3 0 0 3 i
* 192.168.30.0 3.3.3.3 0 0 3 i
* 0.0.0.0 0 32768 i

Механизм BGP Route Dampening

Проверим, как работате механизм dampening в eBGP, изменив адрес следующего перехода в таблице маршрутизации. Для этого удалим один ранее настроеный статический маршрут на R1:

no ip route 3.3.3.0 255.255.255.0 192.168.30.3

Теперь посмотрим на отладку R1. Инструмент проверки следующего перехода запланировал проверку через 5 секунд (scheduling next hop scan in 5 secs). Спустя 5 секунд была произведена проверка следующего перехода (обратите внимание на временные метки):

*Feb 29 18:59:45.719: EvD: accum. penalty decayed to 0 after 601 second(s)
*Feb 29 18:59:45.719: BGP(0): IPv4 Unicast::base nexthop modified, reuse in 00:00:19, 19000 , scheduling nexthop scan in 5 secs
*Feb 29 18:59:45.720: BGP_Router: unhandled major event code 128, minor 0
*Feb 29 18:59:45.723: EvD: accum. penalty decayed to 500 after 0 second(s)
*Feb 29 18:59:45.723: BGP(0): IPv4 Unicast::base nexthop modified, reuse in 00:00:27, 27000 , timer already running

*Feb 29 18:59:50.721: BGP: BGP Event nhop timer
*Feb 29 18:59:50.721: BGP: tbl IPv4 Unicast:base Nexthop walk
*Feb 29 18:59:50.723: BGP(IPv4 Unicast): CHANGED Path metric 0 Path aigp-metric 0 nexthop: 3.3.3.3

Снова пропишем и удалим статический маршрут следующего перехода 3.3.3.0, чтобы значение penalty продолжало расти:

*Feb 29 19:00:28.566: EvD: accum. penalty decayed to 350 after 5 second(s)
*Feb 29 19:00:28.566: BGP(0): IPv4 Unicast::base nexthop modified, reuse in 00:00:25, 25000 , scheduling nexthop scan in 5 secs
*Feb 29 19:00:28.567: BGP_Router: unhandled major event code 128, minor 0
*Feb 29 19:00:28.568: EvD: accum. penalty decayed to 850 after 0 second(s)
*Feb 29 19:00:28.568: BGP(0): IPv4 Unicast::base nexthop modified, reuse in 00:00:30, 30000 , timer already running

Снова как только 30 секунд истекут, выполнится проверка.

Выводы

Спасибо за уделенное время на прочтение статьи. Теперь Вы умеете настраивать сходимость BGP с помощью отслеживания следующего перехода на маршрутизаторах Cisco.

Если возникли вопросы, задавайте их в комментариях.

Подписывайтесь на обновления нашего блога и оставайтесь в курсе новостей мира инфокоммуникаций!

Чтобы знать больше и выделяться знаниями среди толпы IT-шников, записывайтесь на курсы Cisco, курсы по кибербезопасности, полный курс по кибербезопасности, курсы DevNet (программируемые сети) от Академии Cisco, курсы Linux от Linux Professional Institute на платформе SEDICOMM University (Университет СЭДИКОММ).

Курсы Cisco, Linux, кибербезопасность, DevOps / DevNet, Python с трудоустройством!

Спешите подать заявку! Группы стартуют 25 января, 26 февраля, 22 марта, 26 апреля, 24 мая, 21 июня, 26 июля, 23 августа, 20 сентября, 25 октября, 22 ноября, 20 декабря.

Что Вы получите?

Поможем стать экспертом по сетевой инженерии, кибербезопасности, программируемым сетям и системам и получить международные сертификаты Cisco, Linux LPI, Python Institute.
Предлагаем проверенную программу с лучшими учебниками от экспертов из Cisco Networking Academy, Linux Professional Institute и Python Institute, помощь сертифицированных инструкторов и личного куратора.
Поможем с трудоустройством и стартом карьеры в сфере IT — 100% наших выпускников трудоустраиваются.

Как проходит обучение?

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

А еще поможем Вам:

отредактировать или создать с нуля резюме;
подготовиться к техническим интервью;
подготовиться к конкурсу на понравившуюся вакансию;
устроиться на работу в Cisco по специальной программе. Наши студенты, которые уже работают там: жмите на #НашиВCisco Вконтакте, #НашиВCisco Facebook.

Чтобы учиться на курсах Cisco, Linux LPI, кибербезопасность, DevOps / DevNet, Python, подайте заявку или получите бесплатную консультацию.