Introdução
Especialista em Destaque
Você pode fazer o download da apresentação em formato PDF aqui
Configuração do IPv6 em roteadores Cisco
P: Como funciona exatamente a detecção de malware de tráfego criptografado feito pelo recurso Encrypted Traffic Analytics (ETA)?
R: Para este procedimento, é feita uma análise em tempo real de dados observáveis dos pacotes, incluindo dados iniciais dos pacotes, mapa de risco global, TCP/IP watchlist, DNS watchlist, fingerprint dos certificados, sequence of packet lenghts and time (SPLT), e análise cognitiva com machine learning baseado na nuvem com mais de 300 motores de classificação de riscos. É o que chamamos análise por telemetria de rede.
P: Qual é o caminho de migração para a base de switches existente para os novos switches da família Catalyst 9000?
R: Considerando a base instalada com modelos vigentes da Cisco, o caminho de transição seria: Catalyst 3850 --> Catalyst 9300, Catalyst 4500-E --> Catalyst 9400, Catalyst 4500X ou Catalyst 3850 Fiber 48 Port --> Catalyst 9500.
P: Quais são as vantagens dos ASIC UADP 2.0 com relação aos ASICs empregados tradicionalmente em switches?
R: Há diversos tipos de processadores e cada qual recomendado para uma missão mais específica, tais como processadores x86, ASIC, FPGA e outros, com vantagens e desvantagens para cada caso. Falando especificamente de ASICs, os "merchant silicon" e até mesmo os "custom silicon" existentes possuem pipeline fixo, ou seja, impossibilitando a reprogramação do ASIC para a acomodação de novas operações e recursos baseados integralmente em hardware. Os ASICs UADP 2.0 são inovadores e da categoria "programáveis", possibilitando "ensinar" o ASIC a realizar novas operações no futuro em cenários de curto, médio e longo prazos. Estes ASICs também se destacam pela maior capacidade e armazenamento de informações (contadores, TCAM, registros, etc.).
P: Qual é exatamente a relação entre estes novos switches da família Cisco Catalyst 9000 e a arquitetura Cisco DNA?
R: Há uma relação muito íntima entre o Catalyst 9000 e a arquitetura DNA, particularmente nas questões envolvendo os pilares de soluções que fomentam o DNA para as infraestruturas LAN cabeada e sem fio, tais como o SD-Access e ETA. As facilidades de programabilidade, automação, visibilidade e microssegmentação providas e suportadas pelos switches Cisco Catalyst 9000 habilitam a arquitetura Cisco DNA para as empresas com foco em redes corporativas intuitivas, preditivas, IoT, cloud e segurança, e em cenários de missão crítica.
P: Como funciona o licenciamento do Cisco ONE para o Catalyst 9000 no contexto da arquitetura Cisco DNA?
R: No caso do Cisco Catalyst 9000, relacionamos com a solução Cisco ONE Advantage for Switching. Essencialmente estão inclusos, e num único SKU, as soluções Stealthwatch, ISE Base + ISE Plus, e DNA Advantage (SD-Access, Assurance, Analytics, Security, IoT, Telemetry, Visibility e afins), além de todos os recursos já acomodados no DNA Essentials. Através do Cisco ONE Advantage em regime de subscrição (3, 5, 7 anos), estão inclusos também o suporte sobre o hardware e software base Cisco (switch e IOS XE), suporte sobre as aplicações da solução Cisco DNA (ex: ISE, Stealthwatch e afins), e atualizações de software. Ou seja, a Cisco fornecendo uma solução complexa nos moldes similares usados pelas principais empresas de software do mundo.
P: Se eu já tenho uma rede tradicional campus hoje,com 2x core 4500 e 120x 2960. Como funcionará a migração para a nova linha Catalyst, sendo que teremos que fazer essa migração em paralelo.
R: Os caminhos de transição tecnológica, especificamente os switches em si, incluem os seguintes cenários recomendados pela Cisco:
- Se você possui hoje o modelo Cisco Catalyst 3850 "copper", migre para o modelo Cisco Catalyst 9300.
- Se você possui hoje o modelo Cisco Catalyst 4500-E, migre para o modelo Cisco Catalyst 9400.
- Se você possui hoje o modelo Cisco Catalyst 4500X ou o Cisco Catalyst 3850 "Fiber", migre para o modelo Cisco Catalyst 9500.
O exposto acima esclarece uma estratégia de migração no aspecto mais prático da palavra e em termos de "equipamentos", ou seja, as recomendações de atualização do seu parque de switches para os modelos mais recentes, neste caso, os modelos da família Cisco Catalyst 9000 Series Switches. Sendo ainda mais objetivo no seu caso, os seus switches Catalyst 4500 em tese deverão ser migrados para o modelo Cisco Catalyst 9400 ou, dependendo da densidade de portas óticas, para o Catalyst 9500, enquanto as 120 unidades do seu switch Cisco Catalyst 2960 deverão ser portadas para o modelo Cisco Catalyst 9300.
No que diz respeito a migração de rede em si, ou seja, “como realizar a migração” da rede atual para a nova infraestrutura, isto é um tanto subjetivo e amplo. A proposta de você migrar a sua infraestrutura deve considerar algumas coisas óbvias: refresh do hardware descontinuado (EOL), maior capacidade, adoção de novos recursos e tecnologias, e diversos princípios funcionais. Como esta migração deverá ser feita ou executada isto somente poderá ser respondido apropriadamente quando um trabalho de planejamento é realizado prevendo este objetivo. Sugiro que todo o processo seja feito através de um ciclo de vida de projeto detalhado que vá identificar os cenários e possibilidades de migração entre o parque atual e a nova infraestrutura, até mesmo porque cada rede é uma rede diferente e com requisitos distintos. Ou seja, se haverá coexistência entre as duas redes - as quais deverão ser interconectadas - e a consequente migração pautada por fases dos dispositivos clientes da rede atual para a nova rede, ou se você terá que providenciar uma janela apropriada de migração onde os serviços de redes ficarão indisponíveis até que você conclua todo o processo de migração (o que certamente consumirá algumas horas). Este segundo cenário é um tanto comum quando, especialmente, não houver, por exemplo, espaço físico para acomodar nos racks, ao mesmo tempo, os switches legados e os novos switches, orçamento energético para manter as duas redes ligadas em paralelo, indisponibilidade de conexões óticas para interconectar os dois ambientes simultaneamente, overlapping e/ou insuficiência de VLAN Ids ou endereçamento IP; são muitas possibilidades aqui.
Todavia, independentemente do cenário a ser adotado – subir as duas redes em paralelo e migrar aos poucos, ou antecipar o máximo possível da migração com configurações nos equipamentos do novo ambiente, e executar a migração em uma única janela, etc. – procure executar todo o trabalho com base em processos bem estabelecidos. Ou seja, exercite bem a etapa de Planejamento. Exemplos de ações aqui incluiriam a análise de prontidão de sites, análise de prontidão de redes, revalidação do plano de numeração de VLANs e endereçamento IP, seleção e validação de software, mapeamento de requisitos técnicos, portabilidade das configurações vigentes para o novo ambiente, e aproveitando a oportunidade para realizar os aprimoramentos devidos de possíveis áreas funcionais do projeto técnico existente, etc. Em adição, capriche na etapa de Projeto, incluindo ações bem definidas para derivar conceitos e artefatos tais como o projeto executivo, projeto técnico detalhado, plano de instalação e configuração (roteiro de instalação física, roteiro de configuração lógica, roteiro de configuração do gerenciamento, roteiro de atualização de software, etc.), além do plano de migração em si (roteirizando corretamente como deverá ocorrer a migração, incluindo manobras de conexões físicas, ações em plano de configurações/software, plano de comunicação de indisponibilidade, plano de rollback, testes de validação sistêmica e de aceitação, matriz de responsabilidades/competências vs. recursos e profissionais empregados, etc.). Por último, a etapa de Implantação/Migração propriamente dita, e dispor de todos os recursos em mãos, devidamente identificados e disponíveis, para que a sua migração: a) provoque um mínimo de indisponibilidade possível, b) que o novo ambiente, uma vez comissionado, não introduza prejuízos no funcionamento da infraestrutura, c) que os objetivos técnicos pré-determinados sejam identificados e funcionais no pós-migração.
Moral da história: foque em fazer a migração funcionar com zero aborrecimentos, nem que você tenha que investir mais tempo no planejamento (etapas de Planejamento e Projeto), até mesmo porque, enquanto você planeja a migração, coleta requisitos, e desenha o plano, etc., todos os serviços estão disponíveis, clientes internos e externos funcionando sem problemas, o ar condicionado e o cafezinho na mesa...certo? Melhor ser organizado e metódico e viabilizar uma migração “trauma zero” do que você ser apressado ou precipitado, esquecer de detalhes funcionais críticos, e, no meio da janela, identificar estes imprevistos, sofrendo forte pressão de gestores e de clientes por conta destes problemas/imprevistos, e tudo isto no meio de uma janela de migração as 3 da manhã!
P: Como funcionará a integração com aplicacões rodando localmente nos switches e o próprio switch? Por exemplo, poderei rodar um software que entenderá as interfaces do switch? Como um wireshark por exemplo? Ou um Iperf rodando numa interface física específica do switch?
R: A família Cisco Catalyst 9000 Series Switches suporta um espaço de execução segregado rodando em um Linux Container (LXC) chamado "Guest Shell". A partir deste Guest Shell, o network-admin possui as seguintes capacidades:
- Acesso a rede sobre as interfaces de rede do Linux.
- Acesso ao bootflash do Cisco Catalyst 9000.
- Acesso ao Cisco API REST.
- Habilidade de instalar e rodar scripts Python
- Habilidade de instalar e rodar aplicações, ou seja, hospedar apps no switch em Linux Containers.
Esta separação entre os espaços de execução, ou seja, entre o sistema host nativo e o container onde reside o Guest Shell, permite uma customização do ambiente Linux de forma a atender a diversas exigências das aplicações que se deseja implantar sem que isto vá impactar o host system ou outras aplicações rodando em outros Linux Containers.
Um exemplo de como acessamos este ambiente:
EdgeNode1#guestshell
iox feature is not enabled
Caso o guestshell não esteja disponível, habilitaríamos assim:
EdgeNode1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
EdgeNode1(config)#iox
EdgeNode1(config)#exit
*Sep 26 15:16:35.403: %UICFGEXP-6-SERVER_NOTIFIED_START: Switch 1 R0/0: psd: Server iox has been notified to start
*Sep 26 15:16:36.585: %SYS-5-CONFIG_I: Configured from console by console
Acessando agora o Guest Shell:
EdgeNode1#guestshell
The process for the command is not responding or is otherwise unavailable
Error, guestshell is in disabled state, execute 'guestshell enable' before attempting this CLI
EdgeNode1#guestshell enable
Management Interface will be selected if configured
Please wait for completion
Guestshell enabled successfully
O acesso pode ser feito por guestshell ou guestshell run bash:
EdgeNode1#guestshell
[guestshell@guestshell ~]$ exit
EdgeNode1#
EdgeNode1#guestshell run bash
[guestshell@guestshell ~]$ exit
EdgeNode1#
Exemplo de instalação de Python, uma vez no Guest Shell:
[guestshell@guestshell bootflash]$ sudo su
[root@guestshell bootflash]# pip install Markdown
Collecting Markdown
/usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:318: SNIMissingWarning: (...)
Downloading Markdown-2.6.9.tar.gz (271kB)
100% |################################| 276kB 2.3MB/s
Installing collected packages: Markdown
Running setup.py install for Markdown ... done
Successfully installed Markdown-2.6.9
[root@guestshell bootflash]# pip list | grep Markdown
Markdown (2.6.9)
[guestshell@guestshell ~]$ sudo yum install python
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
(Truncated)
Resolving Dependencies
--> Running transaction check
---> Package python.x86_64 0:2.7.5-16.el7 will be updated
---> Package python.x86_64 0:2.7.5-58.el7 will be an update
--> Processing Dependency: python-libs(x86-64) = 2.7.5-58.el7 for package: python-2.7.5-58.el7.x86_64
--> Finished Dependency Resolution
Dependencies Resolved
(Truncated)
Transaction Summary
==========
(Truncated)
Updated:
python.x86_64 0:2.7.5-58.el7
Dependency Updated:
python-libs.x86_64 0:2.7.5-58.el7
Complete!
[guestshell@guestshell ~]$
Consulte os seguintes recursos para conhecer melhor as capacidades do Open IOS XE, especialmente a questão de hospedagem de aplicações no switch:
Desenvolvimento de aplicações em Cisco IOx e Cisco Fog Director
https://developer.cisco.com/site/iox/
Cisco IOS XE 16: Secure, Open, and Flexible
https://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/ios-xe/nb-09-ios-xe-secure-open-flex-aag-cte-en.pdf
Informação relacionada