По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
OSPF (Open Shortest Path First) – дословно переводится как «Сперва открытый короткий путь» - надежный протокол внутренней маршрутизации с учетом состояния каналов (Interior gateway protocol, IGP). Как правило, данный протокол маршрутизации начинает использоваться тогда, когда протокола RIP уже не хватает по причине усложнения сети и необходимости в её легком масштабировании.
OSPF наиболее широко используемый протокол внутренней маршрутизации. Когда идёт речь о внутренней маршрутизации, то это означает, что связь между маршрутизаторами устанавливается в одном домене маршрутизации, или в одной автономной системе. Представьте компанию среднего масштаба с несколькими зданиями и различными департаментами, каждое из которых связано с другим с помощью канала связи, которые дублируются с целью увеличения надежности. Все здания являются частью одной автономной системы. Однако при использовании OSPF, появляется понятие «площадка», «зона» (Area), которое позволяет сильнее сегментировать сеть, к примеру, разделение по «зонам» для каждого отдельного департамента.
Видео: протокол OSPF (Open Shortest Path First) за 8 минут
Для понимания необходимости данных «зон» при проектировании сети, необходимо понять, как OSPF работает. Есть несколько понятий, связанных с этим протоколом, которые не встречаются в других протоколах и являются уникальными:
Router ID: Уникальный 32-х битный номер, назначенный каждому маршрутизатору. Как правило, это сетевой адрес с интерфейса маршрутизатора, обладающий самым большим значением. Часто для этих целей используется loopback интерфейс маршрутизатора.
Маршрутизаторы-соседи: Два маршрутизатора с каналом связи между ними, могут посылать друг другу сообщения.
Соседство: Двухсторонние отношения между маршрутизаторами-соседями. Соседи не обязательно формируют между собой соседство.
LSA: Link State Advertisement – сообщение о состоянии канала между маршрутизаторами.
Hello сообщения: С помощью этих сообщений маршрутизаторы определяют соседей и формируют LSA
Area (Зона): Некая иерархия, набор маршрутизаторов, которые обмениваются LSA с остальными в одной и той же зоне. Зоны ограничивают LSA и стимулируют агрегацию роутеров.
OSPF – протокол маршрутизации с проверкой состояния каналов. Представьте себе карту сети – для того, чтобы ее сформировать, OSPF совершает следующие действия:
Сперва, когда протокол только запустился на маршрутизаторе, он начинает посылать hello-пакеты для нахождения соседей и выбора DR (designated router, назначенный маршрутизатор). Эти пакеты включают в себя информацию о соседях и состоянии каналов. К примеру, OSPF может определить соединение типа «точка-точка», и после этого в протоколе данное соединение «поднимается», т.е. становится активным. Если же это распределенное соединение, маршрутизатор дожидается выбора DR перед тем как пометить канал активным.
Существует возможность изменить Priority ID для, что позволит быть уверенным в том, что DR-ом станет самый мощный и производительный маршрутизатор. В противном случае, победит маршрутизатор с самым большим IP-адресом. Ключевая идея DR и BDR (Backup DR), заключается в том, что они являются единственными устройствами, генерирующими LSA и они обязаны обмениваться базами данных состояния каналов с другими маршрутизаторами в подсети. Таким образом, все не-DR маршрутизаторы формируют соседство с DR. Весь смысл подобного дизайна в поддержании масштабируемости сети. Очевидно, что единственный способ убедиться в том, что все маршрутизаторы оперируют одной и той же информацией о состоянии сети – синхронизировать БД между ними. В противном случае, если бы в сети было 35 маршрутизаторов, и требовалось бы добавить еще одно устройство, появилась бы необходимость в установлении 35 процессов соседства. Когда база централизована (т.е существует центральный, выбранный маршрутизатор - DR) данный процесс упрощается на несколько порядков.
Обмен базами данных – крайне важная часть процесса по установлению соседства, после того как маршрутизаторы обменялись hello-пакетами. При отсутствии синхронизированных баз данных могут появиться ошибки, такие как петли маршрутизации и т.д. Третья часть установления соседства – обмен LSA. Это понятие будет разобрано в следующей статье, главное, что необходимо знать – нулевая зона (Area 0) особенная, и при наличии нескольких зон, все они должны быть соединены с Area 0. Так же это называется магистральной зоной.
Типы маршрутизаторов OSPF
Разберем различные типы маршрутизаторов при использовании протокола OSPF:
ABR
Area Border Router – маршрутизатор внутри нулевой зоны, через который идет связь с остальными зонами
DR, BDR
Designated Router, Backup Designated Router – этот тип маршрутизаторов обсуждался выше, это основной и резервирующий маршрутизаторы, которые ответственны за базу данных маршрутизаторов в сети. Они получают и посылают обновления через Multicast остальным маршрутизаторам в сети.
ASBR
Autonomous System Boundary Router – этот тип маршрутизаторов соединяет одну или несколько автономных систем для осуществления возможного обмена маршрутами между ними.
Подведем итоги
OSPF является быстро сходящимся протоколом внутренней маршрутизации с контролем состояния каналов
Процесс соседства формируется между соседними маршрутизаторами через DR и BDR, используя LSA
Зоны в данном протоколе маршрутизации используются для ограничения LSA и суммирования маршрутов. Все зоны подключаются к магистральной зоне.
В этой статье мы рассмотрим процесс установки и настройки режима Docker Swarm на сервере Ubuntu 16.04.
Docker Swarm является стандартным инструментом кластеризации для Docker, преобразующий набор хостов Docker в один последовательный кластер, называемый Swarm. Docker Swarm обеспечивает доступность и высокую производительность работы, равномерно распределяя ее по хостингам Docker внутри кластера.
Установка Docker Swarm:
Перед началом обновите Ваш системный репозиторий до последней версии с помощью следующей команды:
sudo apt-get update -y && sudo apt-get upgrade -y
После обновления следует выполнить перезагрузку системы. Необходимо еще установить среду Docker. По умолчанию Docker не доступен в репозитории Ubuntu 16.04, поэтому сначала необходимо создать хранилище Docker и начать установку с помощью следующей команды:
sudo apt-get install apt-transport-https software-properties-common ca-certificates -y:
Добавляем GPG ключ для Docker:
wget https://download.docker.com/linux/ubuntu/gpg && sudo apt-key add gpg
Добавляем репозиторий Docker и обновляем с помощью команды:
sudo echo "deb [arch=amd64] https://download.docker.com/linux/ubuntu xenial stable" >> /etc/apt/sources.list sudo apt-get update -y
Установка среды Docker с помощью следующей команды:
sudo apt-get install docker-ce -y
После установки запустите службу Docker во время загрузки с помощью следующей команды:
sudo systemctl start docker && sudo systemctl enable docker
Для запуска Docker необходимы root права, а для других юзеров доступ получается только с помощью sudo. При необходимости запустить docker без использования sudo, есть возможность создать Unix и включить в него необходимых пользователей за счет выполнения следующих строк кода:
sudo groupadd docker && sudo usermod -aG docker dockeruser
Затем выйдя из системы, делаем вход через dockeruser.
sudo ufw allow 2376/tcp && sudo ufw allow 7946/udp && sudo ufw allow 7946/tcp && sudo ufw allow 80/tcp && sudo ufw allow 2377/tcp && sudo ufw allow 4789/udp
Затем перезагрузите брандмауэр, включив его при загрузке
sudo ufw reload && sudo ufw enable
Выполните перезагрузку “Докера”:
sudo systemctl restart docker
Создавая Docker Swarm кластер, необходимо определиться с IP-адресом, за счет которого ваш узел будет действовать в качестве диспетчера:
docker swarm init --advertise-addr 192.168.0.103
Вы должны увидеть следующий вывод:
Swarm initialized: current node (iwjtf6u951g7rpx6ugkty3ksa) is now a manager.
To add a worker to this swarm, run the following command:
docker swarm join --token SWMTKN-1-5p5f6p6tv1cmjzq9ntx3zmck9kpgt355qq0uaqoj2ple629dl4-5880qso8jio78djpx5mzbqcfu 192.168.0.103:2377
To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
Проверяем его состояние:
docker node ls
Если все работает правильно, вы должны увидеть следующий вывод:
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
iwjtf6u951g7rpx6ugkty3ksa * Manager-Node Ready Active Leader
Проверка статуса Docker Swarm Cluster осуществляется следующим образом:
code> docker info
Вывод должен быть следующим:
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 0
Server Version: 17.09.0-ce
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: active
NodeID: iwjtf6u951g7rpx6ugkty3ksa
Is Manager: true
ClusterID: fo24c1dvp7ent771rhrjhplnu
Managers: 1
Nodes: 1
Orchestration:
Task History Retention Limit: 5
Raft:
Snapshot Interval: 10000
Number of Old Snapshots to Retain: 0
Heartbeat Tick: 1
Election Tick: 3
Dispatcher:
Heartbeat Period: 5 seconds
CA Configuration:
Expiry Duration: 3 months
Force Rotate: 0
Autolock Managers: false
Root Rotation In Progress: false
Node Address: 192.168.0.103
Manager Addresses:
192.168.0.103:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 06b9cb35161009dcb7123345749fef02f7cea8e0
runc version: 3f2f8b84a77f73d38244dd690525642a72156c64
init version: 949e6fa
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 4.4.0-45-generic
Operating System: Ubuntu 16.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 992.5MiB
Name: Manager-Node
ID: R5H4:JL3F:OXVI:NLNY:76MV:5FJU:XMVM:SCJG:VIL5:ISG4:YSDZ:KUV4
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Узел теперь настроен правильно, пришло время добавить его в Swarm Cluster. Сначала скопируйте вывод команды «swarm init» из вывода результата выше, а затем вставьте этот вывод в рабочий узел для присоединения к Swarm Cluster:
docker swarm join --token SWMTKN-1-5p5f6p6tv1cmjzq9ntx3zmck9kpgt355qq0uaqoj2ple629dl4-5880qso8jio78djpx5mzbqcfu 192.168.0.103:2377
Вы должны увидеть следующий вывод:
This node joined a swarm as a worker.
Теперь выполните следующую команду для вывода списка рабочего узла:
docker node ls
Вы должны увидеть информацию следующего вида:
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
iwjtf6u951g7rpx6ugkty3ksa * Manager-Node Ready Active Leader
snrfyhi8pcleagnbs08g6nnmp Worker-Node Ready Active
Docker Swarm Cluster запущен и работает, теперь можно запустить веб-сервис в Docker Swarm Mode. За счет следующей строки кода выполнится развертывание службы веб-сервера:
docker service create --name webserver -p 80:80 httpd
Приведенная выше строка создаст контейнер веб-сервера Apache и сопоставит его с 80 портом, позволив иметь полный доступ к необходимому веб-серверу Apache из удаленной системы. Теперь запускаем проверку работающего сервиса с помощью команды:
docker service ls
Вы должны увидеть следующий вывод:
ID NAME
MODE REPLICAS IMAGE PORTS
nnt7i1lipo0h webserver replicated 0/1 apache:latest *:80->80/tcp
Запустите службу масштабирования веб-сервера с помощью строки:
docker service scale webserver = 2
А также проверьте состояние с помощью команды:
docker service ps webserver
Вы должны увидеть следующий вывод:
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
7roily9zpjvq webserver.1 httpd:latest Worker-Node Running Preparing about a minute ago
r7nzo325cu73 webserver.2 httpd:latest Manager-Node Running Preparing 58 seconds ago
Веб-сервер Apache работает. Теперь вы можете получить доступ к веб-серверу:
Служба веб-сервера Apache теперь распределена по двум узлам. Docker Swarm обеспечивает доступность вашего сервиса. Если веб-сервер отключается на рабочем узле, то новый контейнер будет запущен на узле менеджера. Для проверки доступности следует остановить службу Docker на рабочем узле:
sudo systemctl stop docker
Запустите службу веб-сервера с помощью команды:
docker service ps webserver
Вы должны увидеть следующую информацию:
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
ia2qc8a5f5n4 webserver.1 httpd:latest Manager-Node Ready Ready 1 second ago
7roily9zpjvq \_ webserver.1 httpd:latest Worker-Node Shutdown Running 15 seconds ago r7nzo325cu73 webserver.2 httpd:latest Manager-Node Running Running 23 minutes ago
С помощью данной статьи, вы смогли установить и настроить кластер Docker Swarm для ОС Ubuntu 16.04. Теперь вы можете легко масштабировать свое приложение в кластере до тысячи узлов и пятидесяти тысяч контейнеров без существенной потери производительности.
Мы продолжаем рассказывать про протокол DHCP (Dynamic Host Configuration Protocol) . Мы уже знаем про принципы работы протокола и про его настройку на оборудовании Cisco, и сегодня речь пойдет о том, как находить и исправлять проблемы (заниматься траблшутингом) при работе с DHCP.
Проблемы с DHCP могут возникать по множеству причин, таких как проблемы программного обеспечения, в операционных системах, драйверов сетевых карт или агентах ретрансляции, но наиболее распространенными являются проблемы с конфигурацией DHCP. Из-за большого числа потенциально проблемных областей требуется систематический подход к устранению неполадок.
Задача 1. Устранение конфликтов IP адресов
Срок действия адреса IPv4 может истекать у клиента, все еще подключенного к сети. Если клиент не возобновляет аренду, то сервер может переназначить этот IP-адрес другому клиенту. Когда клиент перезагружается, то он запрашивает адрес и если DHCP сервер не отвечает быстро, то клиент использует последний IP-адрес. Тогда возникает ситуация, когда два клиента используют один и тот же адрес, создавая конфликт.
Команда show ip dhcp conflict отображает все конфликты адресов, записанные сервером DHCP. Сервер использует команду ping для обнаружения клиентов. Для обнаружения конфликтов клиент использует протокол ARP. Если обнаружен конфликт адресов, адрес удаляется из пула и не назначается, пока администратор не разрешит конфликт.
Выгладит это так:
Router# show ip dhcp conflict
IP address Detection Method Detection time
192.168.1.33 Ping Feb 19 2018 10:33 AM
192.168.1.48 Gratuitous ARP Feb 19 2018 11:29 AM
В столбце IP address указывается конфликтный адрес, в строке Detection Method указывается метод обнаружения (Ping – адрес был обнаружен когда при назначении нового адреса получил положительный ответ на пинг, Gratuitous ARP – конфликт обнаружен в ARP таблице) и Detection time показывает время обнаружения.
Чтобы посмотреть список всех выданных адресов сервером используется команда show ip dhcp binding.
Задача 2. Проверка физического подключения
Сначала нужно проверить, что интерфейс маршрутизатора, действующий как шлюз по умолчанию для клиента, является работоспособным. Для этого используется команда show interface [интерфейс] , и если интерфейс находится в каком либо состоянии кроме как UP, то это означает что порт не передает трафик, включая запросы клиентов DHCP.
Задача 3. Проверка связности, используя статический IP адрес
При поиске проблем DHCP проверить общую работоспособность сети можно задав статический IP адрес у клиента. Если он может достичь сетевых ресурсов со статически настроенным адресом, то основной причиной проблемы является не DHCP.
Задача 4: Проверить конфигурацию порта коммутатора
Если DHCP клиент не может получить IP адрес с сервера, то можно попробовать получить адрес вручную, заставляя клиента отправить DHCP запрос.
Если между клиентом и сервером DHCP есть маршрутизатор и клиент не может получить адрес, то причиной могут быть настройки портов. Эти причины могут включать в себя проблемы, связанные с транками и каналами, STP и RSTP. Конфигурация PortFast и настройка пограничных портов разрешают наиболее распространенные проблемы клиента DHCP, возникающие при первоначальной установке коммутатора.
Задача 5: Проверка работы DHCP в одной и той же подсети или VLAN
Важно различать, правильно ли работает DHCP, когда клиент находится в одной подсети или VLAN, что и DHCP-сервер. Если DHCP работает правильно, когда клиент находится в одной подсети, то проблема может быть ретранслятором DHCP (relay agent). Если проблема сохраняется даже при тестировании в одной подсети, то проблема может быть с сервером DHCP.
Проверка конфигурации DHCP роутера
Когда сервер DHCP находится в отдельной локальной сети от клиента, интерфейс маршрутизатора, обращенный к клиенту, должен быть настроен для ретрансляции запросов DHCP путем настройки helper адреса.
Чтобы проверить конфигурацию маршрутизатора для начала нужно убедиться, что команда ip helper-address настроена на правильном интерфейсе. Она должна присутствовать на входящем интерфейсе локальной сети, содержащей DHCP клиентов, и должна быть направлена на правильный сервер DHCP. Для проверки используется команда show ip interface [интерфейс] . Далее нужно убедиться, что в глобальном режиме не была введена команда no service dhcp . Эта команда отключает все функции сервера DHCP и ретрансляции на маршрутизаторе. Для проверки используется команда show running-config | include no service dhcp. Если команда была введена, то она отобразится в выводе.
Дебаг DHCP
На маршрутизаторах, настроенных как DHCP-сервер, процесс DHCP не выполняется если маршрутизатор не получает запросы от клиента. В качестве задачи по траблшутингу нужно убедиться, что маршрутизатор получает запрос от клиента. Для этого дебага понадобится конфигурация ACL (Access Control List).
Нужно создать расширенный Access List, разрешающий только пакеты с UDP портами назначения 67 или 68. Это типичные порты, используемые клиентами и серверами при отправке сообщений DHCP. Расширенный ACL используется с командой debug ip packet для того чтобы отображать только сообщения DHCP.
Router(config)# access-list 100 permit udp any any eq 67
Router(config)# access-list 100 permit udp any any eq 68
Router(config)# end
Router# debug ip packet 100
IP packet debugging is on for access list 100
*IP: s-0.0.0.0 (GigabitEthernet1/1), d-255.255.255.255, len 333, rcvd 2
*IP: s-0.0.0.0 (GigabitEthernet1/1), d-255.255.255.255, len 333, stop process pak for forus packet
*IP: s-192.168.1.1(local), d-255.255.255.255 (GigabitEthernet1/1), len 328, sending broad/multicast
Результат в примере показывает, что маршрутизатор получает запросы DHCP от клиента. IP-адрес источника равен 0.0.0.0, поскольку клиент еще не имеет адреса, адрес назначения - 255.255.255.255, потому что сообщение об обнаружении DHCP от клиента отправляется в виде широковещательной передачи. Этот вывод показывает только сводку пакета, а не сообщение DHCP. Тем не менее, здесь видно, что маршрутизатор получил широковещательный пакет с исходными и целевыми IP-адресами и портами UDP, которые являются правильными для DHCP.
Другой полезной командой для поиска неполадок DHCP является команда событий debug ip dhcp server. Эта команда сообщает о событиях сервера, таких как назначения адресов и обновления баз.
Router(config)#debug ip dhcp server events
DHCPD: returned 192.168.1.11 to address pool POOL-1
DHCPD: assigned IP address 192.168.1.12 to client 0011:ab12:cd34
DHCPD: checking for expired leases
DHCPD: the lease for address 192.168.1.9 has expired
DHCPD: returned 192.168.1.9 to address pool POOL-1