Podemos trabalhar com roteadores normais (appliance físico) e também com roteadores virtuais no SD-WAN. Neste segundo caso uma opção é o CSR1000V-SD-WAN (versão com software específico para SD-WAN). O CSR1KV pode ser instalado em hypervisors como ESXI e HyperV, além das clouds Azure e AWS. Considerando que você já tem o ambiente funcionando, com controllers, vManage e outros sites em produção, estes seriam os passos para adicionar um roteador virtual na estrutura existente. Roteador virtual no SD-WAN 1) Adicione o roteador virtual na SmartAccount. Acesse o site software.cisco.com, faça o login e clique em Plug and Play Connect. 2) Clique em Add Software Device e cadastre o novo roteador, informando o modelo (CSR1KV) e a quantidade. Aponte a controller onde este equipamento será registrado/gerenciado. Opcionalmente pode colocar uma descrição. Clique em Save, Next, Done. O roteador ficará com o status “Pending for publish” por alguns minutos. 3) Depois do status mudar para “Provisioned”, vá para o vManage e em Configuration > Devices, clique em Sync Smart Account. Informe as credenciais da Smart Account e clique em Sync para o vManage buscar os roteadores cadastrados no Plug and Play Connect. O CSR1KV será listado. 4) Com o roteador disponível no vManage podemos fazer a configuração. Considerando que o template de configuração já está criado, basta associar ao novo roteador indo em Configuration > Templates > Device. Ache o template desejado e escolha a opção Attach Device. Na sequencia forneça as informações para a configuração do novo CSR1KV, clique em Next e faça o deploy da configuração. Neste momento o roteador ainda não está na gerência, então o template não é enviado para o roteador, mas ficará a disposição. 5) Vá em Configuration > Devices > WAN Edge List e encontre o CSR1KV. Selecione a opção Generate Bootstrap Configuration. Copie todo o texto da caixa de dialogo. 6) Acesse o roteador pela console (considerando que ele ainda não tem nenhuma configuração) e cole o script. Pode colar tudo, ignore as linhas que serão rejeitadas. 7) Para finalizar ative o CSR1KV usando o comando request platform software sdwan vedge_cloud activate chassis-number NRO_CHASSI token TOKEN. As informações de número de chassi e token estão no vManage (Configuration > Device, veja o item3). 8) Em menos de 1 minuto a comunicação com as controllers deve iniciar. Para confirmar pode usar o comando show sdwan controll connections. Importante: Para a comunicação entre o CSR1KV e o vManage funcionar é importante que o horário esteja certo, caso contrário o certificado não será aceito. Até a próxima.
Templates e Policies no Cisco SD-WAN
No SD-WAN as configurações são feitas no vManage, através de policies e templates. As policies são usadas para determinar como o tráfego de dados e de controle será encaminhado, e também para configurar as regras de segurança (Firewall, IPS, AMP, Filtro de URL e Umbrella). E usamos os templates para fazer as configurações dos roteadores (hostname, interfaces, rotas e demais opções). Data e Control Policies, Centralized e Localized As Políticas de Dados e Controle são destinadas a controlar o Plano de Dados (tráfego propriamente) e o Plano de Controle (roteamento), respectivamente, sendo que as políticas centralizadas impactam em todo o ambiente (ou em parte, de acordo com os filtros utilizados), enquanto as políticas locais afetam devices ou sites específicos. Podemos ver as Control Policies como regras de roteamento, como filtros aplicados no OSPF em uma rede tradicional, que impactam como as rotas são aprendidas e divulgadas. Já a Data Policy é equivalente as access-lists, que aplicamos em uma interface para bloquear um determinado tráfego. As políticas centralizadas são aplicadas nas controladoras (vSmart) enquanto que as políticas locais são aplicadas diretamente nos roteadores. Os principais componentes usados na construção das políticas centralizadas (mais comuns no SD-WAN) são: Lists: Podemos criar listas de sites, de prefixos, de VPNs, de SLA,…, que serão usadas nas políticas. Policy Definition: Tipo de política que será criada, como Control Policy, Data Policy, App Route Policy,…, e onde criamos as regras (match and action). Policy Application: Onde a política será aplicada, por exemplo um lista de sites, ou VPNs. Também podemos definir a direção se for uma Control Policy. Security Policy Security Policy é outro tipo de política que temos no SD-WAN, e onde fazemos as configurações de segurança, usadas quando temos cEdges. cEdge são os appliances Cisco, rodando IOS-XE-SD-WAN. Também temos os vEdges, equipamentos herdados da Viptella, e que não suportam todas as funcionalidades de segurança. Neste tipo de política temos a possibilidade de criar regras de firewall (IP/Porta de origem x IP/Porta de destino, por exemplo), ativar o IPS e a proteção contra malware (AMP), além de fazer filtro de URL localmente ou ainda configurar a integração com o Cisco Umbrella. O firewall utilizado é do tipo “Zone Based”, e suporta regras de camada 7 inclusive. Templates Diferente do que estávamos acostumados, a configuração dos roteadores não é mais via linha de comando. Todos os parâmetros dos roteadores são definidos via templates, no vManage. Na verdade você pode configurar o roteador manualmente, via linha de comando, desde que não coloque ele como vManage Mode, mas isso não faz muito sentido quando falamos de SD-WAN. Esta opção (CLI mode) é importante para casos específicos, mas em geral trabalhamos no modo vManage, aproveitando todos os benefícios da solução. Os dois principais tipos de templates são: Feature Template: Templates para cada parte da configuração. Temos Features Templates para configurar interfaces, NTP, logging e AAA, rotas, e assim por diante. Device Template: Template onde agregamos todos os Features Templates que precisamos. É o Device Template que aplicamos ao roteador, e é necessário criar um Device Templates para cada modelos de roteador, mas podemos usar o mesmo Device Templates para equipamentos do mesmo modelo. Também é no Device Template que chamamos a Security Policy. Os templates podem engessar um pouco nossas opções, porém eles nos trazem grandes ganhos, principalmente em ambientes homogêneo. Podemos, por exemplo, ter um único Device Template aplicados a todos os roteadores do ambiente (se forem todos do mesmo modelo, e os locais tiverem exatamente as mesmas necessidades), agilizando a configuração, minimizando possíveis erros de configuração e principalmente garantindo a padronização do ambiente. Também existe o CLI Template, que podemos usar criar configurações para os cEdges, herdadas dos vEdges mas que ainda não estão no Feature Template. Podemos olhar os templates como formulários onde temos as definições de campos que serão preenchidos. Os campos podem ser preenchidos com valores Default, podem ser preenchidos globalmente, com valores que serão aplicados para todos os roteadores (NTP server por exemplo), ou ainda criar campos do tipo variáveis (Device Specific). Neste caso o “campo” é preenchido na hora que template é associado ao roteador. É bastante comum o uso de variáveis, já que cada equipamento tem hostname, IPs, rotas,… e outros itens que são específicos de cada device. Tem muito mais conteúdo para cada um destes itens, mas imagino que esse post é um bom ponto de partida para quem esta interessado em SD-WAN. Para conhecer mais sobre policies e templates no Cisco SD-WAN acesse os links abaixo: Policies Configuration Guide Security Configuration Guide Templates Systems and Interfaces Configuration Guide Até a próxima.
Conceitos e Componentes Cisco SD-WAN
Há uns 5 ou 6 anos tivemos a explosão do SDN – Software Defined Network. Não importava a pergunta a resposta era SDN. No entanto, naquele momento, tínhamos a visão mas não muitas opções maduras no mercado. O tempo passou e as soluções foram melhorando, outras surgindo, em várias áreas. Para a WAN a Cisco adquiriu um empresa chamada Viptela, e vem trazendo as funcionalidades, bem como criando novas, para os roteadores. A solução é bastante interessante, e também muito diferente do que nós, acostumados com a “tela preta”, conhecemos. Arquitetura e Componentes Como toda solução SDN que se preze, o SD-WAN Cisco é composto por planos separados de orquestração, gerenciamento, controle e dados. Plano de Gerenciamento: É responsável pela configuração e monitoramento centralizado. Plano de Orquestração: Auxilia na integração automática dos roteadores no overlay SD-WAN. Plano de Controle: Cria e mantém a topologia da rede, e toma decisões sobre encaminhamento do tráfego Plano de Dados: Responsável pelo encaminhamento de pacotes com base nas decisões do plano de controle. Temos componentes específicos para cada plano: vManage (Gerenciamento): Sistema de gerenciamento (appliance virtual) da rede SD-WAN, fornece interface gráfica para monitorar e configurar a solução. vBond (Orquestração): Componente baseado em software, executa a autenticação inicial dos dispositivos WAN Edge e orquestra a conectividade vSmart, vManage e WAN Edge. É um tipo de controladora. vSmart (Controle): Baseado em software, mantém uma conexão segura com cada roteador e distribui informações de rotas e políticas por meio do OMP. Também orquestra a conectividade segura do plano de dados entre os roteadores, enviando informações de chave de criptografia. Também é uma controladora. vEdge/cEdge (Dados): Disponível em hardware ou em software, fornece conectividade segura do plano de dados entre os sites em um ou mais transportes WAN. É responsável pelo encaminhamento de tráfego, segurança, qualidade de serviço (QoS), e muito mais. Os softwares que compõem a gerência (vManage, vBond e vSmart) podem ser instalados “on primeses”, ou na cloud Cisco (alías recomendado, facilita muito a montagem do ambiente além de todos os benefícios de usar a cloud). E quando falamos de soluções SDN, normalmente temos também os conceitos de Underlay e Overlay. No caso do SD-WAN podemos considerar que: Underlay: É a infraestrutura de rede física que conecta os roteadores e roteia o tráfego entre dispositivos. Geralmente composto pelas conexões do roteador WAN à rede de transporte e à própria rede de transporte. As interfaces conectadas à rede underlay fazem parte da VPN 0 (VPN de transporte) e fornecem conectividade entre os TLOCs para que os túneis IPSec possam ser construídos. Overlay: Os túneis IPsec entre os sites formam a rede de overlay SD-WAN, garantindo a conectividade e abstraindo o caminho físico. OMP e BFD: A base do SD-WAN Como podemos perceber a solução conta com vários elementos, todos importantes, mas a base é formada pelos protocolos OMP e BFD. OMP – Overlay Management Protocol: Protocolo de roteamento que possui uma estrutura semelhante ao BGP, gerencia o overlay SD-WAN. É executado entre os vSmarts e entre os vSmarts e os roteadores, onde as informações do plano de controle, como prefixos, gateways, chaves de criptografias e informações de política, são trocadas usando uma conexão DTLS ou TLS. O controlador vSmart funciona como um refletor de rota; recebe rotas dos roteadores WAN Edge, processa e aplica as políticas, e depois anuncia as rotas para outros roteadores na rede overlay. BFD – Bidirectional Forwarding Detection: Protocolo executado entre os roteadores, em todos os transportes, encapsulado nos túneis IPSec. O BFD opera no modo de eco (um roteador envia o pacote e o receptor devolve sem processá-lo). Seu objetivo é detectar quedas e também medir várias características do caminho, como perda, latência e jitter. Essas medições são comparadas e usadas na escolha do melhor caminho. Terminologia e itens específicos SD-WAN Neste novo mundo, temos novos termos, específicos da solução. Site ID: Identificador exclusivo de um site na rede SD-WAN, com um valor numérico de 1 a 4294967295. Identifica o local de origem de um prefixo anunciado. System IP: Um endereço IP persistente que identifica o vEdge (semelhante ao router ID. e usado como router ID no OSPF e BGP) independente de qualquer endereço de interface. Transport Color: Tag usada pelo control plane, identifica um TLOC. Pode ser 3g, biz-internet, blue, bronze, custom1, custom2, custom3, default, e outras pré definidas. TLOC: O Transport Location é o ponto de conexão do roteador com o transporte WAN. Um TLOC é identificado e representado exclusivamente pelo System IP, Color e encapsulamento (GRE ou IPsec). Quando um TLOC é marcado como restrito, ele stabelece túneis com um TLOC remoto somente se tiver a mesma cor. VPN: As VPNs (ou como conhecemos, VRFs) dividem a rede em diferentes segmentos. Por padrão temos a VPN 0 (transport) e VPN 512 (managment). Outras VPNs/VRFs são criadas no Servise Side (“LAN”). Túnel: Conexão virtual entre os roteadores, criptografada usando IPSec. DIA: Direct Internet Access, configuração que permite acesso à internet sem passar pelo site concentrador. Mais informações nos links abaixo: Design Guide Deployment Guide Documentation Até a próxima.
Certificação Cisco com 50% de desconto
Por conta da pandemia do COVID19, a Cisco mudou a política de certificação. Provas que antes eram realizadas em centros de treinamentos, agora podem ser feitas de casa. Boa medida para quem estava terminando os estudos e não poderia sair para fazer a prova. Agora, a Cisco também está dando 50% de desconto nas certificações. Basta fazer o cadastro neste link e fazer o agendamento da prova entre 16 e 26 de Junho 2020. A prova TEM que ser feita até o dia 22 de Julho de 2020. Se você estava se preparando, não será o Corona que vai te atrapalhar. Até a próxima
Principais componentes no Cisco Umbrella
O Umbrella é uma das soluções da Cisco que mais gosto atualmente. É simples e funciona muito bem. Como sabemos o Umbrella é uma espécie de filtro de conteúdo baseado em resolução de nome. Simplificando, quando vamos acessar um site o cliente DNS (normalmente integrado ao sistema operacional) consulta o servidor DNS local, que por sua vez consulta um servidor externo. No caso do Umbrella este servidor externo além de resolver nome também compara o IP obtido na resolução com sua base de dados. Com o resultado desta comparação, a solução sabe à qual categoria o IP pertence. Então o acesso pode ser permitido ou negado, de acordo com as políticas definidas. Existem algumas formas de implantação do Umbrella. Na mais simples, basta apontar o servidor DNS interno para os IPs públicos do Umbrella (208.67.222.222 e 208.67.220.220), e cadastrar seus IPs públicos (usados para navegação) na console. Neste caso temos visibilidade de resolução de nomes e proteção, mas não temos informações de IP interno nem de usuário. Por isso, neste caso, não é possível criar regras por grupos. Outra forma, mais completa, é utilizando VAs – Virtuais Appliances como DNS internos. Com o uso destes appliances (2 para redundância) passamos a ter visibilidade dos IPs internos, e também a possibilidade de integração com o AD. Isso nos permite criar regras por grupos de usuários. E agora temos também a possibilidade de fazer o “full proxy”, enviando todo o tráfego para a nuvem, onde a inspeção é feita. Neste caso, além de filtro de URL (HTTP e HTTPS tradicionalmente), a solução pode atuar como um firewall na nuvem, bloqueando/liberando o acesso por IP e por porta. Principais componentes da solução Dashboard: Console na nuvem onde é feita a monitoração e configuração da solução. VA: Appliance virtual, utilizado como encaminhador DNS condicional. Registra as informações de IP interno (e usuário, quando integrado com o AD) para uso em relatórios, e para aplicação das políticas. Também faz a criptografia e autenticação das requisições DNS envidas para nuvem. AD Connector: Instalado em uma máquina do domínio, é responsável por monitorar um ou mais controladores de domínio (lê os logins através dos logs de eventos de segurança), posteriormente faz o mapeamento IP para usuário/computador nas VAs. Sincroniza os grupos do AD com a Cloud Umbrella. Identity: Uma entidade sobre a qual você aplica políticas e relatórios. Pode ser um IP público, ou um grupo do AD, por exemplo. Site: Um site refere-se a um conjunto formado por VAs, conectores e controladores de domínio, com a mesma saída para internet. Não é o mesmo conceito de site do AD. Múltiplos sites AD podem fazer parte do mesmo site Umbrella. Roaming Client: Cliente DNS (não é um cliente VPN nem antivírus), opcional. Permite que políticas sejam aplicadas mesmo com o usuário/computador fora da empresa. As consultas DNS são criptografadas, autenticadas e sujeitas à filtragem de conteúdo, conforme regras criadas. Intelligent Proxy: Apesar de trabalhar na resolução de nomes, eventualmente, se configurado, parte do tráfego pode ser tunelado até a cloud, para inspeção. São enviados para inspeção tráfego destinado a domínios sem reputação clara. Com isso é possível identificar a URL e também fazer a inspeção de arquivos. Certificado: Parte do tráfego HTTPS pode ser inspecionado, de acordo com o Intelligent Proxy. Para fazer a descriptografia do tráfego para inspeção usamos o Certificado Umbrella. Por isso é necessário distribuir este certificado para os dispositivos que estão sujeitos a esta inspeção. Network: IPs públicos que podem chegar à nuvem Umbrella para consulta DNS. Com base nesses IPs suas consultas são associadas à sua conta. Domínios Internos: Domínios que devem ser resolvidos internamente e não encaminhados para a cloud Umbrella. Componentes relacionados a Políticas Para a criação das regras de filtragem também temos alguns componentes. Listas: A solução conta com duas listas (uma do tipo Blocked e uma do tipo Allowed) nativamente e ainda podemos criar outras de acordo com as necessidades. Nestas listas podemos cadastrar domínios que queremos bloquear ou permitir. Categorias: O Umbrella conta com mais de 80 categorias, que podem ser liberadas ou bloqueadas para acesso, como um filtro de URL convencional. Listas de Aplicações: Também temos a possibilidade de trabalhar com aplicações, bloqueando ou liberando de acordo com as políticas da empresa. Security Settings: Categorias “especiais” para conteúdo malicioso. Normalmente devemos bloquear todas essas categorias. Intelligent Proxy: Como já mencionado, ativando esta opção (necessário usar VAs) tráfego destinado aos “grey domains” é interceptado e enviado para a nuvem para inspeção. AMP e AV: Os arquivos que passam pelo proxy são scanneados pelas engine AMP – Adanced Malware Protection (reputação, baseda em hash e checksum) e pela engine de antivírus. Policies: Os itens descritos anteriormente são associados as políticas, onde também associamos os grupos do AD. Mais informações neste link, e informações sobre licenciamento aqui. Até a próxima.
Upgrade cEdge (SD-WAN)
Falamos anteriormente como fazer a atualização dos roteadores Cisco com IOS-XE SDWAN via linha de comando. No entanto, se o roteador estiver no vManage, podemos fazer a atualização pela interface gráfica. Nesse outro post falamos como atualizar os equipamentos da gerência (vManage, vSmart e vBond). É recomendado atualizar parte dos roteadores (10%), e testar o novo software por pelo menos 24h, antes de aplicar para todos os equipamentos da planta. Upgrade cEdge via vManage 1) Baixe o novo software do site da Cisco. 2) Faça o upload do novo software para o vManage acessando Maintenance > Software Repository > Add New Software > vManage, selecione a imagem e clique em Upload. 3) Vá em Maintenance > Software Upgrade > WAN Edge, selecione o roteador que quer atualizar, clique em Upgrade, escolha a nova imagem e clique em Upgrade. O software será enviado para o roteador. 4) De volta a tela de upgrade selecione o roteador, clique em Set Default Version, selecione a nova imagem e clique Set Default. 5) Selecione o roteador novamente, cliquem em Activate, selecione a versão e clique Activate. O roteador vai reiniciar e voltar com a nova versão de software. Opcionalmente podemos deletar softwares que não estão mais em uso. Para isso, na tela de upgrade, selecione o rotedor e clique em Delete Available Software. Escolha o software que não vai usar e clique em Delete. Até a próxima.
