Construção de Policy em Cisco SD-WAN
SD-WAN Policy pode ser considerada a magia que faz tudo fluir conforme planejado pelo administrador de redes ao utilizar a solução Cisco SD-WAN. Contudo, isso também traz um ar intimidador e que, além de gerar confusão, pode gerar aversão a esse avanço natural das redes WAN.
Baseando-me nas anotações que fiz durante os meus estudos irei mostrar que, ao entender a teoria, o processo de criação e definição das policies se torna algo bem mais simples. O primeiro ponto que podemos analisar é que todo esse processo é bastante similar a criação de routing policies em routers IOS tradicionais, nos quais seguimos três passos:
- Define a lista para identificar o grupo de interesse: Listas como access control list, IP prefix list e Autonomous System (AS) path list são comumente utilizadas para esse propósito.
- Define uma route map: Uma route map é uma estrutura de sequência de match e set onde o tráfego de interesse da lista criada anteriormente é comparado e uma sequência de ações especificas a serem tomadas é listada.
- Aplica a route map: Mesmo criada, para que a policy tenha qualquer efeito precisamos aplicá-la. Uma única route map pode ser aplicada de várias maneiras, como em uma interface para configurar policy routing no data plane ou em um neighbor de roteamento para manipular update de rotas no control plane. Lembre-se que configurar route maps sem aplicá-las não tem efeito algum no control plane ou data plane de um router IOS.
Se analisarmos agora as famosas Cisco SD-WAN policies, percebemos que, mesmo elas sendo muito mais flexíveis, seguimos basicamente os mesmo três passos:
- Define a lista para identificar o grupo de interesse: Por ter muito mais flexibilidade que o tradicional IOS, existem mais e diferentes tipos de listas que podem ser utilizados com Cisco SD-WAN. Falarei de cada uma com mais detalhes no decorrer desse artigo.
- Define a policy: A estrutura da policy é bem parecida com as route maps, sendo elas sequenciais com match de lista e set das ações necessárias. Contudo, existem diferentes tipos de policies que podem ser utilizadas para atingir diferentes objetivos. Para diferentes tipos de policies temos critérios específicos que podem ser utilizados para match e diferentes ações que podem ser tomadas.
- Aplica a policy: Assim como no IOS tradicional, em Cisco SD-WAN uma policy só terá efeito se for aplicada. Com Cisco SD-WAN, as centralized policies sempre serão aplicadas em uma site list que fará o match em um ou mais site Id. Se a SD-WAN fabric possuir múltiplos WAN Edge routers em um único site, cada router com o mesmo site ID estará sujeito a mesma centralized policy. Dependendo do tipo de policy pode-se aplicá-la em uma VPN ou em uma direção específica do tráfego.
A figura 1.1 ilustra os três passos do processo de criação de policy.
!Passo 2: Defina a control-policy para executar a ação necessária
policy
Control-policy PERMIT_DEFAULT_ROUTE
sequence 1
match route
prefix-list DEFAULT_ONLY
site-list DC_1
!
action accept
!
!
sequence 11
match tloc
site-list DC_1
!
action accept
!
!
default-action reject
!
! Passo 1: Defina a lista para identificar o grupo de interesse
list
prefix-list DEFAULT_ONLY
ip-prefix 0.0.0.0/0
!
site-list HQ_1
site-id 100
!
site-list DC_1
site-id 10
!
!
! Passo 3: Aplica a policy
apply-policy
site-list HQ_1
control-policy PERMIT_DEFAULT_ROUTE
!
!
Analisando as configurações acima sabemos que agora é esperado que os WAN Edge routers do site HQ_1 (site-id 100) recebam a rota default fornecida pelo DC_1 (site-id 10).
Note: Centralized policies sempre são plotadas no Manager ou na Controller mostrando primeiro a definição da policy (passo 2), seguida da definição da lista (passo 1) e por fim a aplicação da policy (passo 3). Normalmente para troubleshooting é mais rápida se analisar a policy de baixo para cima.
Tipos de listas
Listas são uma parte fundamental na construção de um policy pois proporcionam flexibilidade e extensibilidade tanto em como os itens são comparados quanto em nas ações que serão tomadas. Conforme vimos, existe uma grande variedade de listas que podem ser utilizadas para diferentes grupos de interesses no control e data plane. Em centralized policies podemos utilizar os seguintes tipos:
- Aplication List: Uma lista de aplicações ajuda o administrador a criar regras focadas em serviços relevantes para o seu negócio permitindo match em uma aplicação ou em uma família de aplicações (camada 7) ao invés de precisar definir, por exemplo, IP e Porta (camadas 3 e 4 respectivamente).
- Color List: Color list pode ser usada para especificar uma color ou um grupo de colors. Essa lista pode ser aplicada para control e data plane policies. Também pode ser utilizada como critério de comparação ou especificada em uma ação a ser tomada.
- Prefix List: Parecida com as utilizadas em Cisco IOS tradicionais, é utilizada para especificar um range de rotas em notação CIDR. É utilizada para comparar informações de rotas exclusivamente no control plane e só pode ser utilizada em control policies.
- Data Prefix List: Similar a prefix list, porém, uma data prefix list em Cisco SD-WAN só pode ser utilizada para comparar tráfego no data plane e é usada somente em data policies.
- Site List: Todo site em uma Cisco SD-WAN fabric recebe uma identificação chamada de site-id. Uma site list pode ter um, vários ou um range de site-id.
- Policers: Bastante similar aos tradicionais Cisco IOS, uma policer é utilizada para limitar a taxa de tráfego de entrada e saída. Policer só pode ser utilizada com parte da ação de uma policy e não como critério de comparação.
- SLA (Service Level Agreement) Class List: É usada juntamente com Aplication-Aware Routing (AAR) para definir o SLA em termos de loss, latência e jitter ou uma combinação dos três.
- TLOC List: TLOC list é a definição de next-hop addresses e pode ser utilizada com control e data policy para manipular o next-hop do tráfego que passa pela SD-WAN fabric.
- VPN List: VPN list é uma lista de VPNs de serviço (VRF) e é usada para especificar critérios de comparação na control plane para especificar para qual segmento de VPN uma data policy deverá ser aplicada.
Ativando uma Centralized Policy
Assim que uma centralized policy é construída no Manager ela é ativada. Quando uma centralized policy é ativada, o Manager escreve, via NETCONF, toda a policy dentro da configuração da Controller. Por ser um processo de mudança de configuração, isso leva alguns segundos, além de ser uma alteração permanente. Mesmo que a Controller reinicie por qualquer motivo, terá uma cópia da última policy que foi recebida do Manager.
Dependendo dos requisitos do negócio pode ser que se tenha mais de uma Controller. Nesses casos é de responsabilidade do Manager garantir que a configuração de policy esteja sincronizada em todas as Controllers. Caso uma mudança de policy não seja corretamente aplicada em todas as Controllers, o Manager irá automaticamente realizar o rollback da mudança.
Conforme podemos verificar na figura 1.2, mesmo tendo a administração e criação de policy centralizadas, diferentes tipos de policies são aplicadas em diferente locais na Cisco SD-WAN fabric.
Figura 1.1 – blocos de construção de policies
Data Policy e AAR policy são utilizadas para manipular o tráfego no data plane. Porém, essas policies também precisam ser propagadas até os WAN Edge routers. Todo o processo ocorre após a criação da policy no Manager, que por sua vez ativa a policy na Controller. A Controller, nesse caso, será responsável por codificar as parte necessárias da policy dentro de um OMP update e enviar para o WAN Edge router.
Control Policy e VPN Membership policies são utilizadas para manipular o control plane e não são enviadas aos WAN Edge routers. Já as Localized Policy e Security Policy são criadas no Manager e configuradas direto no WAN Edge router via device template. Esse tipos de policies não interagem diretamente com a Controller.
Por fim, é importante reforçar que para que todo esse processo ocorra nas controllers seguindo os processos que vimos acima, é obrigatório que as controllers estejam sendo gerenciadas e possuam um template aplicado pelo Manager, independente de ser um feature template ou um CLI template. Também é tecnicamente possível que se crie tudo diretamente dentro da Controller via CLI, apesar de raramente se ter redes administradas dessa forma.
Após essa sequência de publicações, acredito que tenha conseguido passar uma introdução teórica sobre a solução Cisco SD-WAN. Agora vamos seguir nas próximas semanas com algo mais prático trazendo use cases que justificam e fazem valer a implantação.
Para todos que leram até aqui deixo duas perguntas sobre o tema como forma de estudo e caso tenham dúvidas ou considerações, sintam-se à vontade para postar nos comentários.
1. Which types of policies are Applied to and enforced on the Controller? (Choose all that apply)
- VPN Membership policies
- Topology (control) policies
- Zone-Based Firewall (ZBFW) policies
- Cflow policies
2. Which types of policies are Applied to and enforced on the WAN Edge router? (Choose all that apply)
- Application-Aware Routing policies
- VPN Membership policies
- Security policies
- Localized policies
- Topology policies
