Архитектура
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Сегодняшняя статья будет посвящена основному протоколу динамической маршрутизации – BGP (Border Gateway Protocol). Почему основному? – Потому что с именно с помощью BGP организована топология всего Интернета.
Итак, в данной статье разберем следующие моменты:
Основные термины протокола BGP
Принципы работы протокола BGP
Типы сообщений протокола BGP
Видео: Основы BGP за 7 минут
Терминология
Когда речь идёт BGP, первое на чем необходимо остановиться - это понятие автономной системы AS(Autonomus System). Автономная система - это совокупность точек маршрутизации и связей между ними, объединенная общей политикой взаимодействия, которая позволяет этой системе обмениваться данными с узлами, находящимися за ее пределами.
AS характеризуется (с недавних пор 32 битным) номером ASN (Autonomus System Number) и пулом IP-адресов. Выдачей и того и другого занимается организация IANA (Internet Assigned Numbers Authority), делегируя контроль за распределением ASN и других интернет ресурсов, региональным регистраторам.
Связность автономных систем достигается благодаря статической или динамической маршрутизации.
Со статической маршрутизацией всё просто. Вы заходите на устройство и вручную прописываете маршрут до его ближайшего соседа. На практике, связать даже 10 маршрутизаторов между собой уже представляется довольно сложной задачей.
Поэтому для больших сетей придумали динамическую маршрутизацию, при которой устройства автоматически делятся друг с другом информацией об имеющихся у них маршрутах и, более того, подстраиваются под изменения топологии.
Как известно, протоколы динамической маршрутизации классифицируются по двум основным признакам:
Тип работы протокола относительно AS
IGP (Interior Gateway Protocol) – работают внутри автономной системы. Сюда относятся: RIP, OSPF, EIGRP, IS-IS
EGP (Exterior Gateway Protocol) – работают вне автономных систем и обеспечивают их связность. Сюда относится BGP
Алгоритм работы протокола
Distance-Vector - знает маршруты только до своих ближайших соседей и обменивается с ними таблицей маршрутизации. (RIP, EIGRP)
Link State – знает всю топологию сети и обменивается таблицей топологии со своими соседями (OSPF, IS-IS)
Очевидно BGP не может быть Link State протоколом. Только представьте себе сколько автономных систем в Интернете, любой маршрутизатор просто выйдет из строя если получит такое количество информации.
Итак, BGP – это протокол внешней маршрутизации, использующийся для соединения двух AS. Схема выглядит примерно так:
Так как на BGP возложена великая задача – соединение автономных систем во всем Интернете, то он должен быть очень надежным. Для этих целей, в самом начале работы, BGP-маршрутизатор инициирует установление TCP сессии на 179 порт к своему соседу, происходит стандартных обмен SYN и ACK.
Соединения по протоколу BGP должно быть абсолютно согласовано администраторами автономных систем, желающих организовать стык. Если, скажем, администратор AS402 запустил процесс BGP на маршрутизаторе BR2 (Border Router), указав в качестве соседа BR1 и его ASN, а администратор AS401 никаких действий не произвел, то TCP-сессия не поднимется и системы так и останутся несвязными. Кроме того, должны соблюдаться следующие условия:
179 порт не блокируется ACL (Access Control List)
Маршрутизаторы пингуют друг друга
При запуске BGP процесса ASN удаленной стороны был указан верно
RouterID не совпадают
Если TCP-сессия установлена успешно, то BGP-маршрутизаторы начинают обмен
сообщениями OPEN, в котором сообщают свои ASN, RouterID и Hold timer. Hold timer это время, в течение которого будет поддерживаться TCP-сессия. Если условия, перечисленные ранее, не соблюдаются, например не совпадает информация о номере AS, то сообщением NOTIFICATION маршрутизатор, получивший неверный ASN уведомит об этом своего соседа и сбросит TCP-сессию.
Если же все условия соблюдаются, то маршрутизаторы, с определенным интервалом, начинают высылать друг другу сообщения KEEPALIVE, означающие подтверждение параметров, принятых в OPEN и уведомление “я ещё жив”.
Наконец, маршрутизаторы могут приступать к обмену маршрутной информацией по средствам сообщения UPDATE. Структура данного сообщения делится на две части:
Path Attributes (Атрибуты пути). Здесь указывается из какой AS поступил маршрут, его происхождение и Next Hop для данного пути.
NRLI (Network Layer Reachability Information). Здесь указывает информация непосредственно о сетях, подлежащих добавлению в таблицу маршрутизации, т.е IP-адрес сети и ее маска.
Сообщение UPDATE будет передаваться каждый раз, когда один из маршрутизаторов получит информацию о новых сетях, а сообщение KEEPALIVE на протяжении всей TCP-сессии.
Именно таким образом и работает маршрутизация во всем Интернете. Истории известно множество инцидентов, когда неправильная работа протокола BGP приводила к сбоям обширных частей глобальной сети, поэтому недооценивать его важность категорически нельзя.
Один из самых простых способов повысить общую производительность базы данных, а если конкретнее, производительность запросов, это использовать индексы баз данных. Но здесь главное – выбрать правильный тип индекса. Каждый индекс в SQL имеет свои собственные преимущества, и поэтому важно знать, когда и какой индекс использовать. Здесь мы рассмотрим самые распространенные индексы из самых популярных реляционных СУБД (СУБД - система управления базами данных) и выясним, когда их нужно использовать.
Что такое индексы баз данных?
Индекс базы данных – это дополнительная структура данных, которая создается наряду с данными в таблице. Вы определяете индекс для таблицы и столбца (или набора столбцов). Таким образом вы создаете новую структуру поиска данных, которая непосредственно связана с этой таблицей и набором столбцов.
В этой статье мы подробно распишем, что такое индекс, как его можно создать, какие есть типы индексов и когда их нужно использовать.
Для чего нужны индексы?
Индексы баз данных ускоряют процесс извлечения данных, и тем самым повышают производительность запросов. Это и есть главная задача таких индексов. Все это происходит за счет того, что для хранения b-дерева и указателей на фактические данные выделяется дополнительная память.
Индексы используются для того, чтобы при каждом запросе строки из таблицы у базы данных не было необходимости просматривать все строки. В общем-то, индексы обеспечивают довольно эффективный способ обращения к упорядоченным записям.
Как можно создать индекс?
У разных РСУБД разный синтаксис для создания индекса. Помимо этого, разные механизмы СУБД используют для этого разные параметры. Это мы с вами сможем увидеть чуть позже. И тем не менее, все же существует общий синтаксис создания самого примитивного индекса, который подходит для всех механизмов СУБД. Ниже приведена синтаксическая структура, с помощью которой можно создать в таблице самый примитивный индекс.
CREATE INDEX index_name
ON table_name (column_name_1, column_name_2, …)
А сейчас давайте воспользуемся этой структурой, чтобы создать индекс для реальной таблицы. Допустим, у нас есть таблица Customer (см. ниже), и мы хотим создать индекс для того, чтобы ускорить процесс поиска по имени клиента.
CREATE INDEX IX_CustomerName
ON Customer (FirstName, LastName)
После того, как мы запустим этот код, мы получим индекс для таблицы
Customer
под названием
IX_CustomerName
. За счет этого индекса поиск данных в столбцах
FirstName
и
LastName
будет проходить куда быстрее.
Индекс, который создается, что называется, за кадром, еще называют некластеризованным индексом или индексом бинарного поиска. С помощью этого индекса мы можем выполнять оптимизированные запросы для сценариев, где присутствуют такие запросы, как:
SELECT FirstName, LastName, Email
FROM Customer
WHERE FirstName = ‘Mark’ and LastName = ‘Thompson’
Как показывает опыт, каждый раз, когда мы хотим оптимизировать запрос, мы смотрим на столбцы, которые используются для выборки данных, и проверяем, есть ли у нас для них индекс. В случае, если столбцы в предложении SELECT аналогичны столбцам в предложениях для выборки данных, у нас появляется оптимизированный план действий, и, соответственно, поиск проходит быстрее.
Но это не то, что нам нужно. Индексирование – это гораздо большее, чем просто эти правила.
Какие бывают индексы в SQL?
Раз уж мы разобрались, как создавать индекс, теперь давайте обсудим основные типы индексов реляционных баз данных, с помощью которых вы сможете оптимизировать свои запросы. Для некоторых из них нужен определенный механизм СУБД, поэтому мы укажем, где их можно использовать.
Все индексы хранят указатели на строки данных в структуре данных под названием дерево поиска. Эта структура оптимизирована для поиска, и она же является главной опорой для индекса. С ее помощью мы можем выполнять что-то наподобие поиска в двоичном дереве поиска, но в нашем случае все немного сложнее.
Есть много различных индексов. У каждого из них своя внутренняя структура данных, а, соответственно, и назначение. Дальше мы рассмотрим их более подробно, а здесь пока кратко оговорим их названия.
С точки зрения характеристик атрибута:
Первичный индекс
Кластеризованный индекс
Вторичный индекс
С точки зрения количества ссылок на файл данных:
Плотный индекс
Разреженный индекс
Нестандартные индексы для очень специфичных сценариев:
Битовый индекс
Реверсивный индекс
Хэш-индекс
Отфильтрованный индекс
Индекс по функции
Пространственный индекс
Давайте для примера воспользуемся той же таблицей
Customer
, что мы использовали ранее. Для того, чтобы понять, как выглядят выборочные данные, давайте напишем простой запрос
SELECT
и вернем из таблицы все данные.
Кластеризованный индекс
Кластеризованный (или кластеризующий) индекс – это один из самых распространенных индексов, которые можно использовать во всех современных полнофункциональных СУБД. Этот индекс определяет порядок, в котором данные хранятся на странице (физически) и в таблице (неявно).
Давайте посмотрим на пример. Допустим, что первые две строки находятся на Странице №1, третья и четвертая строки – на Странице №2, а последняя пятая строка – на Странице №3 (см. ниже).
Задача кластеризованного индекса – физически хранить строки в порядке возрастания или убывания, беря в качестве основы столбец, который был выбран. Этот индекс нужен для того, чтобы хранить именно отсортированные данные. Это значительно упрощает поиск одного или нескольких значений в каком-нибудь диапазоне. Правда, кластеризованный индекс может помочь нам только в том случае, если мы ищем значения в каком-то диапазоне, а не среди всех данных.
Допустим, что список клиентов на нашей информационной панели всегда отображается по алфавиту. Так вот, мы хотим, чтобы наши данные хранились в нашей базе данных в отсортированном порядке по именам и фамилиям. И для того, чтобы создать кластеризованный индекс, мы пишем следующий запрос:
CREATE CLUSTERED INDEX CI_FirstName_LastName
ON Customer (FirstName ASC, LastName ASC);
Этот запрос сказывается на предыдущем, с помощью которого мы вернули все данные. Когда мы создали кластеризованный индекс с сортировкой по возрастанию по имени и фамилии, то мы физически переупорядочили данные на страницах. Если мы с вами взглянем на наши страницы, то увидим, что теперь они выглядят иначе:
Как мы видим, теперь данные отсортированы по имени, а потом по фамилии. Это может существенно упростить нам жизнь и улучшить производительность, так как, если мы сделаем запрос на сортировку строк по алфавиту, ничего не произойдет, поскольку строки и так хранятся в отсортированном порядке. Таким образом, мы можем обойтись без сортировки в самом запросе.
Если мы захотим получить данные о первых 10 клиентах с точки зрения алфавитного порядка, то база данных не будет искать их по всей таблице. Она просто вернет страницы с первыми 10 записями, так как они уже отсортированы.
Битовый индекс
Битовый индекс – это еще одна разновидность индексов. На момент написания статьи его можно было использовать только в Oracle. Этот индекс особо полезен в одном конкретном сценарии, когда вы хотите запросить и отфильтровать по столбцу какую-то часть таблицы, которая в сравнении со всей таблицей не такая уж большая.
Давайте вернемся к нашему примеру и попробуем применить этот битовый индекс. Представьте, что в нашей таблице
Customer
на самом деле не 5, а более 10 миллионов строк. И, допустим, мы хотим отфильтровать наш запрос, в результате которого мы получим данные о клиентах женского пола с фамилией Watson.
Мы можем написать запрос примерно вот так:
SELECT FirstName, LastName, Email
FROM Customer
WHERE Gender = 2 AND LastNamr = “Watson”;
Битовый индекс идеально подходит для этой ситуации, так как в сравнении с 10 миллионами записями строк, которые соответствуют какому-то определенному полу, гораздо меньше. Теперь ускорим наш запрос, создав битовый индекс:
CREATE BIMAP INDEX BMP_Gender
ON Customer (Gender)
А теперь мы выбираем «Kate Watson» и ее адрес электронной почты (см. ниже), а также все остальные подходящие строки из 10 миллионов в этой таблице.
Битовый индекс может оказаться еще более мощным, если вы создадите его в предложении
JOIN
. Например, если мы соединим две таблицы:
Customer
и
Sales
, и отфильтруем их по полу. В этом случае битовый индекс будет выглядеть примерно так:
CREATE BITMAP INDEX BMP_Gender_Sales
ON Customer (Gender)
FROM Customer, Sales
WHERE Customer.ID = Sales.Customer_ID;
Каждый раз, когда вы будете отправлять запрос на объединение этих двух таблиц и их фильтрации по полу, вы будете очень близки к максимальной производительности запроса.
Реверсивный индекс
Реверсивный индекс во многом похож на обычный индекс. Но он не создает двоичное дерево поиска для того, чтобы ускорить поиск данных в порядке возрастания, этот индекс оптимизирован для поиска данных в порядке убывания. Синтаксическая конструкция для создания реверсивного индекса очень похожа на синтаксическую конструкцию обычного некластеризованного индекса. Разница лишь в том, что мы должны указать, что данные должны быть в обратном (убывающем) порядке.
Предположим, что мы хотим оптимизировать запрос, с помощью которого хотим узнать имена клиентов, которые разместили 3 последних заказа. Создадим индекс:
CREATE INDEX IX_LastOrder_Customer
ON Customer (LastOrder DESC);
Самое важное слово в этой конструкции – это
DESC
. Оно сообщает механизму СУБД, что необходимо создать именно реверсивный индекс. Таким образом, каждый раз, когда мы будем запрашивать данные о трех последних заказах из таблицы
Customer
, мы будем получать наилучшую производительность запроса.
Какую структуру данных использует индекс?
Как мы уже упоминали, индексы создаются наряду с другими структурами данных для оптимизации операций поиска. Но что это за структуры данных?
Сбалансированное дерево
Самые распространенные индексы для того, чтобы ускорить запросы, используют, так сказать, за кадром сбалансированное дерево. Большинство механизмов СУБД используют либо сбалансированное дерево, либо его разновидность, например, b+-дерево. Ниже показано как выглядит структура обычного сбалансированного дерева.
Верхний узел – это корневой, а все остальные, которые расположены ниже, - это либо дочерние, либо конечные узлы. Поиск строки начинается с корневого узла. Мы сравниваем искомое значение со значением в текущем узле, больше оно или меньше. В зависимости от результата этого сравнения мы поймем, в какую сторону нам нужно идти, влево или вправо. Если мы посмотрим на пример выше, то увидим, что все значения меньше 8 ведут нас влево, а значения больше 8 – вправо, и т.д.
Хэш
Хэш используется хэш-индексами. Это структура данных, которая обеспечивает один из самых быстрых поисков. С помощью хэша индексы могут очень быстро находить данные, которые хранятся в таблице.
Основная идея хэша состоит в следующем: вместо того, чтобы перебирать все ключи поиска с помощью индексов или искать их по всей таблице, мы применяем к нему хэш-функцию. Этот ключ поиска преобразуется в хэш-значение, которое определяет соответствующе, так называемое, «ведро». Давайте посмотрим на пример ниже. В нем мы применяем хэш-функцию к ключу поиска «Mike», после чего оно ставит в соответствие определенное ведро.
Каждое такое ведро в массиве ведер содержит одинаковое количество записей. Неважно, сколько в столбце различных значений, каждая строка сопоставляется с отдельным ведром. После чего выбирается соответствующая строка и возвращается из этого ведра.
Реализация индексов с помощью механизмов РСУБД
Как вы уже могли понять, в реляционной базе данных есть несколько типов индексов. И у каждого механизма СУБД есть свои собственные реализации этих индексов. Давайте пройдемся по самым популярным механизмам СУБД, перечислим индексы, которые у них есть и обсудим, когда их лучше использовать.
Индексы в PostgreSQL
У PostgreSQL список индексов довольно большой. Каждый из них подходит для конкретных сценариев:
Самый распространенный индекс – индекс В-дерева. Он будет полезен в ситуациях, когда вам нужно сравнивать диапазоны в столбцах, которые можно сортировать.
Хэш-индекс хранит 32-битный хэш-код, который является производным от значений индексированных столбцов. Он будет полезен в тех случаях, когда вам нужно проводить простые сравнения.
GiST – это не один какой-то индекс, а скорее логическая структура, в которой могут быть реализованы несколько разных стратегий индексирования. Чаще всего эта структура используется в сценариях, в рамках которых вам нужно найти «ближайшего соседа» в геометрических типах данных.
SP-GiST, как и GiST, реализует несколько стратегий индексирования. В его основе лежат различные структуры данных, такие как деревья квадрантов, k-мерные и базисные деревья. Этот индекс используется в тех же сценариях, что и GiST.
GIN также называют «инвертированным индексом». Он используется в сценариях, в которых данные являются массивом. Инвертированный индекс содержит отдельную запись для каждого компонента массива.
BRIN расшифровывается как «Block Range INdex», что переводится как «блочно-диапазонный индекс». Он используется для хранения краткого описания значений на последовательных страницах физических данных внутри таблицы. Лучше всего он подходит для ситуаций, когда значения в строках перекликаются с физическим порядком страниц данных.
Индексы в Oracle
У Oracle список индексов чуть меньше. Но при этом они считаются более продуманными с точки зрения применимости.
В-дерево – это стандартный индекс. Он также есть и в других механизмах СУБД. В-дерево лучше всего подходит для представления первичных ключей и столбцов, у которых огромное количество различных значений относительно общего числа строк.
Битовый индекс нужен для обратных сценариев. Например, его можно использовать в сценариях, где количество различных значений в столбце не так велико относительно общего числа строк.
Индекс по функции – это индекс, в рамках которого значение, хранящееся в дереве поиска, определяется функцией. Таким образом он обеспечивает отличную производительность запросов, в которых есть предложения
WHERE
с функциями внутри.
Индексы в SQL Server
У SQL Server не так много индексов, но при этом у них очень много функциональных возможностей.
Кластеризованный индекс нужен не только для того, чтобы механизм СУБД мог выполнить поиск в запросе. Он физически реорганизовывает строки на страницах данных так, чтобы они были отсортированы либо по возрастанию, либо по убыванию.
Некластеризованный индекс – это эквивалент В-дерева, которое есть в других механизмах СУБД. В основном он хорошо подходит для ситуаций, когда нужно перебрать данные с огромным количеством различных значений.
Отфильтрованные индексы создаются для определенных групп данных. Они используются для того, чтобы оптимизировать поиск ассиметричных данных с заданными критериями. Например, мы хотим найти в столбце число 55. Но оно есть лишь в нескольких строках (относительно общего числа строк в таблице). Тогда вы можете создать отфильтрованный индекс по принципу кластеризованного, просто дополнительно указав условие
WHERE column = 55
.
Индексы в MySQL
В MySQL тоже есть несколько индексов, с помощью которых можно повысить производительность запросов.
Индекс первичного ключа – это уникальный индекс, с помощью которого можно быстро и эффективно обращаться к уникальным значениям. Также для него выгодной является оптимизация
NOT NULL
, так как у него не может быть значения
NULL
. Он всегда используется при определении первичного ключа и создается автоматически, когда вы указываете ключевые слова
PRIMARY KEY
.
Однозначный индекс во многом похож на индекс первичного ключа. Но он более гибкий в том смысле, что он позволяет многократно сохранять значения
NULL
. Он используется для того, чтобы обеспечить дополнительную уникальность в том случае, когда первичный ключ уже был создан.
Расширьте свой инструментарий с помощью индексов баз данных
Если вы дошли аж до сюда, то значит, вам понравилось читать про индексы баз данных! Я надеюсь, что эта информация была для вас полезной, и вы смогли найти здесь для себя что-то новое. Если вдруг ваши запросы начнут тормозить, то с помощью ваших знаний о том, какие есть индексы в различных механизмах СУБД, вы сможете повысить производительность запросов.
Иногда может быть так, что обычного В-дерева будет недостаточно, или он может не соответствовать схеме и/или данным. Поэтому иметь представление о том, какие еще есть типы индексов в реляционной базе данных, это все равно что иметь швейцарский армейский нож в своем ящике с инструментами.
Предыдущая статья из цикла про соответствие пакетов в IP ACL.
Обратные маски, такие как значения dotted-decimal number (DDN), фактически представляют собой 32-разрядное двоичное число. Как 32-разрядное число, маска WC фактически направляет логику маршрутизатора бит за битом. Короче говоря, бит маски WC (wildcard), равный 0, означает, что сравнение должно выполняться как обычно, но двоичный 1 означает, что бит является подстановочным знаком и может быть проигнорирован при сравнении чисел.
Кстати, наш калькулятор подсетей показывает и сам считает WC (wildcard) маску.
Вы можете игнорировать двоичную маску WC. Почему? Что ж, обычно мы хотим сопоставить диапазон адресов, которые можно легко идентифицировать по номеру подсети и маске, будь то реальная подсеть или сводный маршрут, который группирует подсети вместе. Если вы можете указать диапазон адресов с помощью номера подсети и маски, вы можете найти числа для использования в вашем ACL с помощью простой десятичной математики, как описано далее.
Если вы действительно хотите знать логику двоичной маски, возьмите два номера DDN, которые ACL будет сравнивать (один из команды access-list, а другой из заголовка пакета), и преобразуйте оба в двоичный код. Затем также преобразуйте маску WC в двоичную. Сравните первые два двоичных числа бит за битом, но также игнорируйте любые биты, для которых маска WC случайно перечисляет двоичный 1, потому что это говорит вам игнорировать бит. Если все биты, которые вы проверили, равны, это совпадение!
Нахождения правильной обратной маски, соответствующей подсети
Во многих случаях ACL должен соответствовать всем хостам в определенной подсети. Чтобы соответствовать подсети с помощью ACL, вы можете использовать следующие сочетания:
Используйте номер подсети в качестве исходного значения в команде access-list.
Используйте обратную маску, полученную путем вычитания маски подсети из 255.255.255.255.
Например, для подсети 172.16.8.0 255.255.252.0 используйте номер подсети (172.16.8.0) в качестве параметра адреса, а затем выполните следующие вычисления, чтобы найти обратную маску:
Продолжая этот пример, завершенная команда для той же подсети будет следующей:
access-list 1 permit 172.16.8.0 0.0.3.255
Соответствие любому/всем адресам
В некоторых случаях вам может понадобиться одна команда ACL для сопоставления всех без исключения пакетов, которые достигают этой точки в ACL. Во-первых, вы должны знать (простой) способ сопоставить все пакеты с помощью ключевого слова any. Что еще более важно, вам нужно подумать о том, когда сопоставить все без исключения пакеты.
Во-первых, чтобы сопоставить все пакеты с помощью команды ACL, просто используйте ключевое слово any для адреса. Например, чтобы разрешить все пакеты:
access-list 1 permit any
Итак, когда и где вы должны использовать такую команду? Помните, что все ACL Cisco IP заканчиваются неявным отрицанием любой концепции в конце каждого ACL. То есть, если маршрутизатор сравнивает пакет с ACL, и пакет не соответствует ни одному из настроенных операторов, маршрутизатор отбрасывает пакет. Хотите переопределить это поведение по умолчанию? Настроить permit any в конце ACL.
Вы также можете явно настроить команду для запрета всего трафика (например, access-list 1 deny any) в конце ACL. Почему, когда та же самая логика уже находится в конце ACL? Что ж, ACL показывает счетчики списка для количества пакетов, соответствующих каждой команде в ACL, но нет счетчика для этого не явного запрета любой концепции в конце ACL. Итак, если вы хотите видеть счетчики количества пакетов, совпадающих с логикой deny any в конце ACL, настройте явное deny any.
Внедрение стандартных IP ACL
В этой лекции уже представлены все этапы настройки по частям. Далее суммируются все эти части в единую конфигурацию. Эта конфигурация основана на команде access-list, общий синтаксис которой повторяется здесь для справки:
access-list access-list-number {deny | permit} source [source-wildcard]
Этап 1. Спланируйте локацию (маршрутизатор и интерфейс) и направление (внутрь или наружу) на этом интерфейсе:
Стандартные списки ACL должны быть размещены рядом с местом назначения пакетов, чтобы они случайно не отбрасывали пакеты, которые не следует отбрасывать.
Поскольку стандартные списки ACL могут соответствовать только исходному IP-адресу пакета, идентифицируйте исходные IP-адреса пакетов по мере их прохождения в направлении, которое проверяет ACL.
Этап 2. Настройте одну или несколько команд глобальной конфигурации списка доступа для создания ACL, учитывая следующее:
Список просматривается последовательно с использованием логики первого совпадения.
Действие по умолчанию, если пакет не соответствует ни одной из команд списка доступа, - отклонить (отбросить) пакет.
Этап 3. Включите ACL на выбранном интерфейсе маршрутизатора в правильном направлении, используя подкоманду ip access-group number {in | out}.
Далее рассмотрим несколько примеров.
Стандартный нумерованный список ACL, пример 1
В первом примере показана конфигурация для тех же требований, что и на рисунках 4 и 5. Итак, требования для этого ACL следующие:
Включите входящий ACL на интерфейсе R2 S0/0/1.
Разрешить пакеты, приходящие от хоста A.
Запретить пакеты, приходящие от других хостов в подсети хоста A.
Разрешить пакеты, приходящие с любого другого адреса в сети класса A 10.0.0.0.
В исходном примере ничего не говорится о том, что делать по умолчанию, поэтому просто запретите весь другой трафик.
В примере 1 показана завершенная правильная конфигурация, начиная с процесса настройки, за которым следует вывод команды show running-config.
R2# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)# access-list 1 permit 10.1.1.1
R2(config)# access-list 1 deny 10.1.1.0 0.0.0.255
R2(config)# access-list 1 permit 10.0.0.0 0.255.255.255
R2(config)# interface S0/0/1
R2(config-if)# ip access-group 1 in
R2(config-if)# ^Z
R2# show running-config
! Lines omitted for brevity
access-list 1 permit 10.1.1.1
access-list 1 deny 10.1.1.0 0.0.0.255
access-list 1 permit 10.0.0.0 0.255.255.255
Во-первых, обратите внимание на процесс настройки в верхней части примера. Обратите внимание, что команда access-list не изменяет командную строку из приглашения режима глобальной конфигурации, поскольку команда access-list является командой глобальной конфигурации. Затем сравните это с выводом команды show running-config: детали идентичны по сравнению с командами, которые были добавлены в режиме конфигурации. Наконец, не забудьте указать ip access-group 1 в команде под интерфейсом R2 S0/0/1, который включает логику ACL (как локацию, так и направление).
В примере 2 перечислены некоторые выходные данные маршрутизатора R2, которые показывают информацию об этом ACL. Команда show ip access-lists выводит подробную информацию только о списках ACL IPv4, а команда show access-lists перечисляет сведения о списках ACL IPv4, а также о любых других типах ACL, настроенных в настоящее время, например, списки ACL IPv6.
Вывод этих команд показывает два примечания. В первой строке вывода в этом случае указывается тип (стандарт) и номер. Если существовало более одного ACL, вы бы увидели несколько разделов вывода, по одной на каждый ACL, каждая со строкой заголовка, подобной этой. Затем эти команды перечисляют счетчики пакетов для количества пакетов, которые маршрутизатор сопоставил с каждой командой. Например, на данный момент 107 пакетов соответствуют первой строке в ACL.
Наконец, в конце примера перечислены выходные данные команды show ip interface. Эта команда перечисляет, среди многих других элементов, номер или имя любого IP ACL, включенного на интерфейсе для подкоманды интерфейса ip access-group.
Стандартный нумерованный список ACL, пример 2
Для второго примера используйте рисунок 8 и представьте, что ваш начальник в спешке дает вам некоторые требования в холле. Сначала он говорит вам, что хочет фильтровать пакеты, идущие от серверов справа к клиентам слева. Затем он говорит, что хочет, чтобы вы разрешили доступ для хостов A, B и других хостов в той же подсети к серверу S1, но запретили доступ к этому серверу хостам в подсети хоста C. Затем он сообщает вам, что, кроме того, хостам в подсети хоста A следует отказать в доступе к серверу S2, но хостам в подсети хоста C должен быть разрешен доступ к серверу S2 - и все это путем фильтрации пакетов, идущих только справа налево. Затем он говорит вам поместить входящий ACL на интерфейс F0/0 R2.
Если вы просмотрите все запросы начальника, требования могут быть сокращены до следующего:
Включите входящий ACL на интерфейсе F0/0 R2.
Разрешить пакеты от сервера S1, идущие к хостам в подсети A.
Запретить пакетам с сервера S1 идти к хостам в подсети C.
Разрешить пакетам с сервера S2 идти к хостам в подсети C.
Запретить пакетам с сервера S2 идти к хостам в подсети A.
Не было комментариев о том, что делать по умолчанию; используйте подразумеваемое отклонение всего по умолчанию.
Как оказалось, вы не можете сделать все, что просил ваш начальник, с помощью стандартного ACL. Например, рассмотрим очевидную команду для требования номер 2: access-list 2 permit 10.2.2.1. Это разрешает весь трафик с исходным IP-адресом 10.2.2.1 (сервер S1). Следующее требование просит вас фильтровать (отклонять) пакеты, полученные с того же IP-адреса! Даже если вы добавите другую команду, которая проверяет исходный IP-адрес 10.2.2.1, маршрутизатор никогда не доберется до него, потому что маршрутизаторы используют логику первого совпадения при поиске в ACL. Вы не можете проверить и IP-адрес назначения, и исходный IP-адрес, потому что стандартные ACL не могут проверить IP-адрес назначения.
Чтобы решить эту проблему, вам следует переосмыслить проблему и изменить правила. В реальной жизни вы, вероятно, вместо этого использовали бы расширенный ACL, который позволяет вам проверять как исходный, так и целевой IP-адрес.
Представьте себе, что ваш начальник позволяет вам изменять требования, чтобы попрактиковаться в другом стандартном ACL. Во-первых, вы будете использовать два исходящих ACL, оба на маршрутизаторе R1. Каждый ACL разрешает пересылку трафика с одного сервера в эту подключенную локальную сеть со следующими измененными требованиями:
Используя исходящий ACL на интерфейсе F0 / 0 маршрутизатора R1, разрешите пакеты с сервера S1 и запретите все остальные пакеты.
Используя исходящий ACL на интерфейсе F0 / 1 маршрутизатора R1, разрешите пакеты с сервера S2 и запретите все остальные пакеты.
Пример 3 показывает конфигурацию, которая удовлетворяет этим требованиям.
access-list 2 remark This ACL permits server S1 traffic to host A's subnet
access-list 2 permit 10.2.2.1
!
access-list 3 remark This ACL permits server S2 traffic to host C's subnet
access-list 3 permit 10.2.2.2
!
interface F0/0
ip access-group 2 out
!
interface F0/1
ip access-group 3 out
Как показано в примере, решение с номером ACL 2 разрешает весь трафик с сервера S1, при этом эта логика включена для пакетов, выходящих из интерфейса F0/0 маршрутизатора R1. Весь другой трафик будет отброшен из-за подразумеваемого запрета all в конце ACL. Кроме того, ACL 3 разрешает трафик от сервера S2, которому затем разрешается выходить из интерфейса F0/1 маршрутизатора R1. Также обратите внимание, что решение показывает использование параметра примечания списка доступа, который позволяет оставить текстовую документацию, которая остается в ACL.
Когда маршрутизаторы применяют ACL для фильтрации пакетов в исходящем направлении, как показано в Примере 2, маршрутизатор проверяет пакеты, которые он направляет, по списку ACL. Однако маршрутизатор не фильтрует пакеты, которые сам маршрутизатор создает с помощью исходящего ACL. Примеры таких пакетов включают сообщения протокола маршрутизации и пакеты, отправленные командами ping и traceroute на этом маршрутизаторе.
Советы по устранению неполадок и проверке
Устранение неполадок в списках ACL IPv4 требует внимания к деталям. В частности, вы должны быть готовы посмотреть адрес и обратную маску и с уверенностью предсказать адреса, соответствующие этим двум комбинированным параметрам.
Во-первых, вы можете определить, соответствует ли маршрутизатор пакетам или нет, с помощью пары инструментов. Пример 2 уже показал, что IOS хранит статистику о пакетах, соответствующих каждой строке ACL. Вдобавок, если вы добавите ключевое слово log в конец команды access-list, IOS затем выдает сообщения журнала со случайной статистикой совпадений с этой конкретной строкой ACL. И статистика, и сообщения журнала могут помочь решить, какая строка в ACL соответствует пакету.
Например, в примере 4 показана обновленная версия ACL 2 из примера 3, на этот раз с добавленным ключевым словом log. Внизу примера затем показано типичное сообщение журнала, в котором показано результирующее совпадение на основе пакета с исходным IP-адресом 10.2.2.1 (в соответствии с ACL) с адресом назначения 10.1.1.1.
R1# show running-config
! lines removed for brevity
access-list 2 remark This ACL permits server S1 traffic to host A's subnet
access-list 2 permit 10.2.2.1 log
!
interface F0/0
ip access-group 2 out
R1#
Feb 4 18:30:24.082: %SEC-6-IPACCESSLOGNP: list 2 permitted 0 10.2.2.1 -> 10.1.1.1, 1
Packet
Когда вы впервые устраняете неисправности на ACL, прежде чем вдаваться в подробности логики сопоставления, подумайте, как об интерфейсе, на котором включен ACL, так и о направлении потока пакетов. Иногда логика сопоставления идеальна, но ACL был включен на неправильном интерфейсе или в неправильном направлении, чтобы соответствовать пакетам, настроенным для ACL.
Например, на рисунке 9 повторяется тот же ACL, показанный ранее на рисунке 7. Первая строка этого ACL соответствует конкретному адресу хоста 10.1.1.1. Если этот ACL существует на маршрутизаторе R2, размещение этого ACL в качестве входящего ACL на интерфейсе S0/0/1 R2 может работать, потому что пакеты, отправленные хостом 10.1.1.1 - в левой части рисунка - могут входить в интерфейс S0/0/1 маршрутизатора R2. Однако, если R2 включает ACL 1 на своем интерфейсе F0/0 для входящих пакетов, ACL никогда не будет соответствовать пакету с исходным IP-адресом 10.1.1.1, потому что пакеты, отправленные хостом 10.1.1.1, никогда не войдут в этот интерфейс. Пакеты, отправленные 10.1.1.1, будут выходить из интерфейса R2 F0/0, но никогда не попадут в него только из-за топологии сети.