em 03-21-2025 04:25 AM
Se você tem pelo menos a minha idade, você sabe que o IOS-XR ou até mesmo o NX-OS não é o primeiro OS da Cisco né? Na verdade se me lembro bem, o primeiro switch que eu comprei da cisco era um Catalyst da série 1900 com o Catalyst OS (CatOS) e para a minha surpresa não tinha a famosa linha de comandos que eu estava acostumado (foi um choque inicialmente). Depois de alguns dias eu descobri que na ultima versão disponível do sistema havia a possibilidade de trabalhar com os menus de configuração ou com uma versão mais próxima do terminal que estava acostumado (isso lá por meados 2011). É interessante falar que os comandos eram diferentes, um simples show interfaces no CatOS era show port (e não para por ai as diferenças nos comandos).
Esquecendo o CatOS e avançando para o Cisco IOS (Cisco Internetwork Operating System), sempre comumente utilizado em roteadores, até os switches começarem a ter o seu sistema unificado ao IOS, temos o sistema clássico baseado em um kernel monolítico.
A principal característica de um kernel monolítico (único bloco) é o fato de ser um único conjunto rodando tudo e misturado. No caso do Cisco IOS, ele executa todos os módulos do sistema dentro do mesmo espaço de memória, sem separação de CPU ou memória. Então, no caso de ocorrer algum problema em um único processo ou módulo do sistema, o sistema todo é afetado e pode parar de responder por completo. Aqui nós temos um problema, em um ambiente de grande escala uma interrupção significativa dessa pode gerar um grande transtorno se a confiabilidade é crucial (e normalmente é o caso…).
A dor de cabeça em si é gerada pelo fato de não haver a proteção de memória entre processos, ou seja, se um processo entrar em falha e começar a consumir mais memória do que deveria, outros processos também serão afetados por esse consumo excessivo.
Partindo do ponto que o IOS-XE é uma evolução do Cisco IOS clássico, o IOS-XE veio com uma estrutura modular com o intuito de ser altamente disponível. O IOS é executado como um daemon no kernel do Linux (basicamente um processo que roda em segundo plano/background), assim tendo suas várias funções executadas em processos separados evitando assim interferência entre os processos.
Com essa modularização foi possível que cada um dos subpacotes do sistema fossem realmente isolados, evitando assim problemas da estrutura original do IOS clássico. Problemas de escopo de memória, falhas de processos, atualizações de módulos não afetariam mais todo o sistema como antigamente. Com toda a facilidade que a conteinerização nos trás nessa evolução do tradicional IOS, podemos contar com a atualização de módulos, permitindo que as correções de bugs sejam implementadas sem interromper toda a operação da rede.
Dentro do assunto da modularização, podemos ter em mente as seguintes áreas:
Algo importante mencionar, é que mesmo com essa modularização do IOS, o sistema permanece com a mesma “interface” conhecida, ou seja, os comandos e a estrutura de utilização seguiu a mesma do IOS clássico.
O IOS-XE já conta com suporte a separação de plano de controle e plano de dados, separação de núcleos de cpu e recursos programáveis. Um passo mais perto da automação de rede e SDN não acha?
Enfim chegamos no IOS-XR e eu quero lhe perguntar: “O IOS-XR é uma evolução do IOS-XE assim como o XE é do IOS?”
O IOS-XR tem uma arquitetura Distribuída focada em resiliência, escalabilidade e pronto para rodar em dispositivos com alta capacidade como Backbones de operadoras lidando com grandes volumes de tráfego sem deixar a desejar em nada.
Diante da sua arquitetura então temos:
O IOS-XR já apresenta diferenças em sua CLI, algumas muito significativas e outras mais brandas…
Seu primeiro nome foi SAN-OS (onde SAN significa Storage Area Network), originalmente pensado para 32bits mas evoluiu para 64bits. Um sistema bem próximo do IOS-XR, na verdade ambos compartilham de muitos recursos e estruturas, mas não confunda, o NX-OS foi feito principalmente para ambientes de Datacenter e para Switches da Família Nexus.
De forma a atender a demanda de ambientes de alta densidade, virtualização e automação, suas funcionalidades foram projetadas para atender demandas de datacenters modernos.
Como já falado anteriormente, há algumas diferenças na apresentação de informações, inserção de informações e inclusive um "commit” para que as configurações tornem-se efetivas…
Os comandos abaixo foram executados em instâncias do roteador Cisco IOS, switch NX-OS e roteador IOS-XR em execução no Cisco CML. Cada um dos exemplos a seguir mostra a versão atual do sistema operacional do roteador ou switch. Um show version, uma configuração de IP e um show das interfaces ip do dispositivo.
Passamos por todas as principais versões do Cisco IOS, desde o tradicional IOS até os mais modernos como IOS-XE, IOS-XR e o NX-OS para a família Nexus. É importante lembrar que muitos dispositivos ainda hoje rodam o IOS Clássico, ou seja, cada versão do IOS tem seus dispositivos alvos e ambientes, então só porque um roteador ainda usa Cisco IOS clássico não quer dizer que ele é obsoleto.
Mas, se você que implantar SDN na sua infra, talvez ele não seja a sua melhor opção
Att.
Weslley Silva
Muito bom @Weslley Silva ! Obrigada pelo conteúdo.
Encontre respostas, faça perguntas e conecte-se com nossa comunidade de especialistas da Cisco de todo o mundo.
Estamos felizes por você estar aqui! Participe de conversas e conecte-se com sua comunidade.
Navegue pelos links rápidos da Comunidade e usufrua de um conteúdo personalizado e em seu idioma nativo: