По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Временные списки доступа ACL (Time Based Access-List) – это такие ACL, которые позволяют ограничивать или разрешать доступ до ресурсов в зависимости от времени. Например, запретить выход в интернет для компьютеров в нерабочее время.
Настройка на оборудовании Cisco
Про настройку стандартных ACL можно прочесть тут;
Про настройку расширенных ACL можно прочесть здесь;
Для реализации списков доступа, основанных на времени, существует несколько простых шагов:
Определить временной диапазон когда должен действовать ACL
Определить что должен ограничивать и разрешать ACL и применить к нему временной диапазон
Применить ACL к нужному интерфейсу
Сначала на маршрутизаторе создадим временной диапазон, используя команду time-range [имя_диапазона] . Затем определяем, будет он периодическим (задаем периоды работы) или абсолютным (задаем начало и конец). Если он будет периодическим, то мы используем команду periodic [день_недели][час:минуты]to[день_недели][час:минуты] (также можно использовать аргументы weekend - Суббота и Воскресенье, weekdays - с Понедельника по Пятницу, и daily - Каждый день), а если абсолютным, то используем команду absolute [дата_начала] [дата_конца] .
Пример создания периодического временного диапазона:
Router#conf t
Router(config)#time-range weekends
Router(config)#periodic weekend 08:00 to 22:00
Либо можно указать отдельные дни:
Router#conf t
Router(config)#time-range mwf
Router(config)#periodic Monday Wendsday Friday 08:00 to 16:00
Пример создания абсолютного временного диапазона:
Router#conf t
Router(config)#time-range cisco
Router(config)#absolute start 00:00 1 May 2018 end 00:00 1 April 2019
Далее создаем ACL и указываем в нем созданный диапазон при помощи аргумента time-range [название]
Router(config)#ip access-list extended deny-weekends
Router(config)#deny tcp any any eq 80 time-range weekens
И после этого применим этот лист на интерфейсах:
Router(config)#interface fa0/1
Router(config)#ip access-group deny-weekends out
После этого лист контроля доступа будет применяться в зависимости от времени, выставленном на маршрутизаторе, поэтому очень важно, чтобы оно было выставлено верно. Посмотреть созданные временные диапазоны можно при помощи команды show time-range.
В этой статье мы рассмотрим настройку 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.
В продолжение статьи про Docker, сегодня мы расскажем про Dockerfile — скрипт, который позволяет автоматизировать процесс построения контейнеров — шаг за шагом, используя при этом base образ.
Докерфайлы и синтаксис для их создания
Как уже было сказано выше, каждый Докерфайл — по сути скрипт, который автоматически выполняет определенные действия или команды в base образе, для формирования нового образа.
Все подобные файлы начинаются с обозначения FROM — также как и процесс построения нового контейнера, далее следуют различные методы, команды, аргументы или условия, после применения которых получится Docker контейнер.
Для начала, быстренько пройдемся по синтаксису — он, кстати говоря, крайне простой, с командами, говорящими самими за себя.
В Докер файлах содержится два типа основных блоков — комментарии и команды с аргументами. Причем для всех команд подразумевается определенный порядок — подробнее об этом ниже.
Ниже типичный пример синтаксиса, где первая строка является комментарием, а вторая — командой.
# Print «Hello from Merionet!»
RUN echo «Hello from Merionet!!»
Перед тем, как переходить к собственно написанию собственно Докерфайла, сначала разберем все возможные команды.
Все команды в Докерфайлах принято указывать заглавными буквами — к примеру RUN, CMD и т.д.
Команда ADD — данная команда берет два аргумента, путь откуда скопировать файл и путь куда скопировать файлы в собственную файловую систему контейнера. Если же source путем является URL (т.е адрес веб-страницы) — то вся страница будет скачена и помещена в контейнер.
# Синтаксис команды: ADD [исходный путь или URL] [путь назначения]
ADD /my_merionet_app /my_merionet_app
Команда CMD — довольно таки похожая на команду RUN, используется для выполнения определенных программ, но, в отличие от RUN данная команда обычно применяется для запуска/инициации приложений или команд уже после их установки с помощью RUN в момент построения контейнера.
# Синтаксис команды: CMD %приложение% «аргумент», «аргумент», ..
CMD «echo» «Hello from Merionet!».
Команда ENTRYPOINT устанавливает конкретное приложение по умолчанию, которое используется каждый раз в момент построения контейнера с помощью образа. К примеру, если вы установили определенное приложение внутри образа и вы собираетесь использовать данный образ только для этого приложения, вы можете указать это с помощью ENTRYPOINT, и каждый раз, после создания контейнера из образа, ваше приложение будет воспринимать команду CMD, к примеру. То есть не будет нужды указывать конкретное приложение, необходимо будет только указать аргументы.
#Синтаксис команды: ENTRYPOINT %приложение% «аргумент»
# Учтите, что аргументы опциональны — они могут быть предоставлены командой CMD или #во время создания контейнера.
ENTRYPOINT echo
#Синтаксис команды совместно с CMD:
CMD «Hello from Merionet!»
ENTRYPOINT echo
Команда ENV используется для установки переменных среды (одной или многих). Данные переменные выглядят следующим образом «ключ = значение» и они доступны внутри контейнера скриптам и различным приложениям. Данный функционал Докера, по сути, очень сильно увеличивает гибкость в плане различных сценариев запуска приложений.
# Синтаксис команды: ENV %ключ% %значение%
ENV BASH /bin/bash
Команда EXPOSE используется для привязки определенного порта для реализации сетевой связности между процессом внутри контейнера и внешним миром — хостом.
# Синтаксис команды: EXPOSE %номер_порта%
EXPOSE 8080
Команда FROM — данную команду можно назвать одной из самых необходимых при создании Докерфайла. Она определяет базовый образ для начала процесса построения контейнера. Это может быть любой образ, в том числе и созданные вами до этого. Если указанный вами образ не найден на хосте, Докер попытается найти и скачать его. Данная команда в Докерфайле всегда должна быть указана первой.
# Синтаксис команды: FROM %название_образа%
FROM centos
Команда MAINTAINER — данная команда не является исполняемой, и просто определяет значение поля автора образа. Лучше всего ее указывать сразу после команды FROM.
# Синтаксис команды: MAINTAINER %ваше_имя%
MAINTAINER MerionetNetworks
Команда RUN - является основной командой для исполнения команд при написании Докерфайла. Она берет команду как аргумент и запускает ее из образа. В отличие от CMD данная команда используется для построения образа (можно запустить несколько RUN подряд, в отличие от CMD).
# Синтаксис команды: RUN %имя_команды%
RUN yum install -y wget
Команда USER — используется для установки UID или имени пользователя, которое будет использоваться в контейнере.
# Синтаксис команды: USER %ID_пользователя%
USER 751
Команда VOLUME — данная команда используется для организации доступа вашего контейнера к директории на хосте (тоже самое, что и монтирование директории)
# Синтаксис команды: VOLUME [«/dir_1», «/dir2» ...]
VOLUME [«/home»]
Команда WORKDIR указывает директорию, из которой будет выполняться команда CMD.
# Синтаксис команды: WORKDIR /путь
WORKDIR ~/
Создание своего собственного образа для установки MongoDB
Для начала создадим пустой файл и откроем его с помощью vim:
vim Dockerfile
Затем мы можем указать комментариями для чего данный Докерфайл будет использоваться и все такое — это не обязательно, но может быть полезно в дальнейшем. На всякий случай напомню — все комментарии начинаются с символа #.
########
# Dockerfile to build MongoDB container images
# Based on Ubuntu
########
Далее, укажем базовый образ:
FROM ubuntu
Затем, укажем автора:
MAINTAINER Merionet_Translation
После чего обновим репозитории(данный шаг совершенно необязателен, учитывая, что мы не будем их использовать ) :
RUN apt-get update
После укажем команды и аргументы для скачивания MongoDB (установку проводим в соответствии с гайдом на официальном сайте):
RUN apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 7F0CEB10
RUN echo 'deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen' | tee /etc/apt/sources.list.d/mongodb.list
RUN apt-get update
RUN apt-get install -y mongodb-10gen
RUN mkdir -p /data/db
После чего укажем дефолтный порт для MongoDB:
EXPOSE 27017
CMD [«--port 27017»]
ENTRYPOINT usr/bin/mongod
Вот как должен выглядеть у вас финальный файл — проверьте и, затем, можно сохранить изменения и закрыть файл:
#########
# Dockerfile to build MongoDB container images
# Based on Ubuntu
#########
FROM ubuntu
MAINTAINER Merionet_Translation
RUN apt-get update
RUN apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 7F0CEB10
RUN echo 'deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen' | tee /etc/apt/sources.list.d/mongodb.list
RUN apt-get update
RUN apt-get install -y mongodb-10gen
RUN mkdir -p /data/db
EXPOSE 27017
CMD ["--port 27017"]
ENTRYPOINT usr/bin/mongod
Запуск контейнера Docker
Итак, мы готовы создать наш первый MongoDB образ с помощью Docker!
sudo docker build -t merionet_mongodb .
-t и имя здесь используется для присваивания тэга образу. Для вывода всех возможных ключей введите sudo docker build —help, а точка в конце означает что Докерфайл находится в той же категории, из которой выполняется команда.
Далее запускаем наш новый MongoDB в контейнере!
sudo docker run -name MerionetMongoDB -t -i merionet_mongodb
Ключ -name используется для присвоения простого имени контейнеру, в противном случае это будет довольно длинная цифро-буквенная комбинация. После запуска контейнера для того, чтобы вернуться в систему хоста нажмите CTRL+P, а затем CTRL+Q.
Заключение
Всем спасибо за внимание, теперь вы можете очень много экспериментировать с созданием Докерфайлов и ваших собственных образов, не бойтесь пробовать упростить привычные вам процессы установки приложений с помощью контейнеров — возможности крайне велики, и мы постараемся охватить их в следующих статьях.