Cisco ACI — создание контрактов

Частью красоты инфраструктуры, ориентированной на приложения Cisco, является идея контрактов. В ACI мы много говорим об идее сети, управляемой политиками. Эти политики и есть то, что мы называем контрактами. Контракты не совсем отличаются от ACL, но между ними есть несколько существенных отличий. Во-первых, списки ACL обычно проходят между IP-адресами или подсетями, тогда как контракты заключаются между группами конечных точек и не связаны с конкретной IP-адресацией. ACI также является моделью белого списка, поэтому контракты обычно разрешают трафик, в то время как ACL тратят много времени на запрет трафика в традиционной сети. Наконец, их можно легко сделать двунаправленными, то есть они могут применять одну и ту же политику из вашего веб-EPG, например, к вашему приложению EPG, и наоборот. Вы можете сделать его двунаправленным, просто установив флажок, вместо того, чтобы писать еще несколько ACL, чтобы заставить его работать.

Давайте рассмотрим некоторые основные термины, прежде чем мы начнем.

Фильтр: трафик, которым вы хотите управлять, или, точнее, протоколы, которые вы хотите разрешить. Например, вы можете разрешить https-трафик.

Действие: что вы планируете делать с фильтром. Хотя я сказал, что обычно это действие разрешения, мы допускаем и другие действия.

• Разрешить – разрешает движение
• Запретить (Табу) — конкретный вариант использования, вероятно, при переходе от традиционной сети к ACI. В этом случае вы можете указать разрешить весь трафик в контракте, но установить табу для запрета определенного трафика.
• Перенаправление — это может быть полезно для отправки трафика из EPG на устройство уровня 4-7, такое как брандмауэр, балансировщик нагрузки или IPS/IDS.
• Отметить — вы можете пометить трафик по соображениям качества обслуживания.

Метка: необязательный расширенный идентификатор. Когда вы используете метки, вы можете указать более сложные отношения между конечными точками.

Тема: содержит фильтр, действие и необязательную метку.

Контракт: содержит один или несколько Субъектов.

Как указывалось ранее, между двумя EPG размещается контракт, как показано на рисунке ниже.

фигура 1

Эти контракты обеспечивают базовый межсетевой экран без сохранения состояния между двумя EPG. Мне часто задают вопрос: «А что, если мне нужны брандмауэры с отслеживанием состояния или больше брандмауэров следующего поколения для мониторинга трафика приложений?» Что ж, вы тоже можете это сделать, но вам нужно будет использовать сервисные графы, которые выходят за рамки этой статьи.

Давайте перейдем к тому, как мы заключаем контракты. Мы начнем с создания фильтров, представляющих собой протоколы, которые мы используем для разрешения трафика между двумя EPG. В этом примере мы создадим фильтр для контракта, который будет проходить между EPG базы данных и EPG приложения. В этом примере база данных EPG (DB-EPG) будет предоставлять службы базы данных для Application EPG (App-EPG), используя порт 1433 в качестве общего порта MS SQL.

Создать фильтр:

1. Войдите в свой APIC
2. Щелкните Арендаторы и обязательно выберите арендатора, который вы собираетесь использовать (дополнительная информация: https://techgenix.com/cisco-aci-creating-basic-network-constructs/).
3. Разверните Политики безопасности в левом дереве навигации
4. Выберите фильтры
5. Щелкните правой кнопкой мыши Фильтры и выберите Создать фильтр.
6. Во всплывающем окне дайте ему имя, например «DB-Filter».
7. Вы можете добавить дополнительное описание
8. Щелкните значок + рядом с пунктом «Записи», чтобы добавить новый фильтр.
9. Введите имя, например MSSQL
10. Конфигурации здесь будут зависеть от того, что вы пытаетесь сделать. Вы можете поговорить с администратором брандмауэра, чтобы узнать, что рекомендуется. В этом примере я буду использовать IP в качестве своего Ethertype.
11. Я выберу TCP в качестве своего IP-протокола
12. В качестве портов назначения я наберу 1433. Обратите внимание, что я могу использовать выпадающее меню, чтобы выбрать порты, которые уже доступны, но мне это не нужно. Я могу ввести все, что захочу, только будьте осторожны, не нажимайте TAB, иначе это изменит значение в этом поле.

фигура 2

13. Нажмите Обновить
14. Нажмите «Отправить».

Теперь, когда у нас есть созданный фильтр, мы можем создать контракт, в который его поместим. Имейте в виду, я предполагаю, что у вас уже есть две EPG, в данном случае мы используем DB-EPG и App-EPG. Для получения дополнительной информации о создании EPG см. здесь.

Создать договор:

1. Находясь в своем арендаторе, разверните Политики безопасности.
2. Выберите контракты
3. Щелкните правой кнопкой мыши «Контракты» и выберите «Создать контракт». Обратите внимание, что там также был экспортный контракт, который позволит вам экспортировать код XML или JSON для последующего использования с REST API (читай: автоматизация).
4. Дайте ему имя, например DB-Contract-MSSQL.
5. Дайте ему необязательное описание
6. Щелкните знак + рядом с темами (помните, что тема содержит фильтр, объект и необязательную метку).
7. Дайте теме имя, например MSSQL-Subject.
8. Мы можем оставить два флажка отмеченными, так как они допускают двунаправленность. Однако, если мы хотим применять эти фильтры только в одном направлении от поставщика к потребителю, мы можем отключить их.
9. Нажмите + Sign рядом с Filters и выберите фильтр, который мы создали на последнем шаге (DB-Filter).
10. Нажмите Обновить
11. Нажмите ОК
12. Нажмите «Отправить».

Рисунок 3

У нас есть App-EPG и DB-EPG, у нас также есть созданный контракт, поэтому для завершения нашего профиля сети приложений нам нужно прикрепить наш контракт между EPG.

Создание и применение сетевого профиля:

1. Щелкните правой кнопкой мыши на DB-EPG
2. Выберите Добавить предоставленный контракт
3. В раскрывающемся меню выберите контракт, который вы только что создали.
4. Нажмите «Отправить».

Рисунок 4

5. Теперь щелкните правой кнопкой мыши свое приложение-EPG.
6. Выберите Добавить потребительский контракт.
7. В раскрывающемся меню выберите контракт, который вы только что создали.
8. Нажмите «Отправить».

Теперь, если вы нажмете на профиль приложения, который содержит их для EPG и Contract, мы увидим топологию, в которой DB-EPG позволяет App-EPG видеть трафик через порт 1433.

Рисунок 5

Конечно, это то, как вы делаете все это вручную. Как я уже упоминал здесь, все это можно сделать с помощью REST API.

Вот как выглядит создание фильтра в XML. Вам нужно только ввести это во что-то вроде Postman, чтобы автоматически создать фильтр (а также иметь правильный URL-адрес для вашей среды).

{
«ВзФильтр»:{
«атрибуты»:{
«dn»: «uni/tn-Test_ACI/flt-MSSQL-фильтр»,
«имя»: «MSSQL-фильтр»,
«rn»: «flt-MSSQL-фильтр»,
«статус»: «создано»
},
"дети":[
{
«взэнтри»:{
«атрибуты»:{
«dn»: «uni/tn-Test_ACI/flt-MSSQL-Filter/e-MSSQL»,
«имя»: «MSSQL»,
«эфир»: «ip»,
«прот»: «tcp»,
«dFromPort»: «1433»,
«dToPort»: «1433»,
«rn»: «e-MSSQL»,
«статус»: «создано»
},
"дети":[

]
}
}
]
}
}

Вот как выглядит создание контракта после того, как мы создали фильтр. Опять же, это автоматически позволит вам сделать это. Конечно, вы можете повторно использовать одни и те же имена объектов, но очень легко найти что-то вроде MSSQL-Contract и изменить его, например, на Web-Contract.

{
«взБрКП»:{
«атрибуты»:{
«dn»: «uni/tn-Test_ACI/brc-MSSQL-Contract»,
«имя»: «MSSQL-контракт»,
«rn»: «brc-MSSQL-контракт»,
«статус»: «создано»
},
"дети":[
{
"ВзПодъ":{
«атрибуты»:{
«dn»: «uni/tn-Test_ACI/brc-MSSQL-Contract/subj-SUBJ-MSSQL»,
«имя»: «SUBJ-MSSQL»,
«rn»: «subj-SUBJ-MSSQL»,
«статус»: «создано»
},
"дети":[
{
«vzRsSubjFiltAtt»:{
«атрибуты»:{
«статус»: «создано»,
«tnVzFilterName»: «DB-Filter»
},
"дети":[

]
}
}
]
}
}
]
}
}

Не нервничайте, если вас смущает часть этой статьи, посвященная REST API. Это будет иметь смысл со временем. Попытайтесь понять первую часть, где вы проходите через графический интерфейс. Графический интерфейс может делать все, что угодно, и поможет вам понять логическую модель по мере продвижения вперед. Если у вас есть вопросы об этом блоге, оставьте свои комментарии ниже или свяжитесь со мной в Твиттере @malhoit.