
Para artigos relacionados compartilhados por mim sobre automação de rede, consulte o catálogo "NetDevOps from Scratch"
Nos últimos anos, com o desenvolvimento contínuo do campo global de computação em nuvem e o crescimento contínuo dos negócios, a tecnologia de rede também continuou a se desenvolver e a tecnologia SDN surgiu. A partir da ideia central original de separação de encaminhamento e controle baseada em Openflow, as pessoas continuam a se expandir Na extensão do SDN, as pessoas podem atualmente chegar a um consenso de que Openflow não é mais uma condição necessária (mas a separação de encaminhamento e controle é ainda é uma condição central), e a programabilidade da rede tornou-se lentamente um dos critérios importantes para medir uma arquitetura SDN.
As operações programáveis de equipamentos de rede tradicionais são geralmente baseadas em protocolos CLI e SNMP. Sejam scripts ou software de gerenciamento de rede, todos eles são desenvolvidos nesta base para atingir a ampla gama de programabilidade de rede sobre a qual falaremos hoje. capacidades, realizando assim a automação de muitos cenários. Alguns dispositivos suportam a configuração de algumas interfaces web e a substituição da configuração geral através de xml. Estes são muito raros e não serão descritos em detalhes neste artigo.
CLI
CLI (Command-line Interface) realiza a interação humano-computador por meio da linha de comando. É uma habilidade necessária para trabalhadores de rede. As pessoas abrem o software SSH ou Telnet no dispositivo todos os dias, depois colam uma configuração, salvam-na e entram em vigor. Um dia, as pessoas se cansaram desse tipo de repetição e usaram um programa para gerar scripts de configuração automaticamente, fazer login no dispositivo em lotes e emitir configurações para entrarem em vigor, realizando a automação. Este é um método programável em rede. Vamos falar sobre as vantagens, que são muito consistentes com o pensamento, as ideias e os sistemas técnicos existentes das pessoas. Mas, em última análise, esta abordagem favorece as pessoas em detrimento dos dispositivos de rede. Tem as seguintes desvantagens:
-Existem enormes diferenças nos conjuntos de comandos entre os fabricantes. Não apenas os fabricantes, mas diferentes versões de software do mesmo modelo podem ter diferenças muito diferentes.
-Os desenvolvedores devem estar familiarizados com o conjunto de comandos e como usá-lo. Existem riscos de segurança no nível da configuração. Por exemplo, com um movimento da mão, a porta que eu queria abrir se transformou em fechar a porta…
-Não existem requisitos obrigatórios para protocolos de transmissão (SSH e Telnet) e existem riscos de segurança de produção.
-O processo de análise e geração de configurações é extremamente complicado. Em muitos casos, as regras regulares escritas só podem estar infinitamente próximas da “verdade”, mas não de toda a “verdade”.
-Não há transacionalidade e uma configuração pode entrar em vigor parcialmente e parte não.
-Não existe mecanismo de fiscalização automatizado e é totalmente dependente de pessoas. Por exemplo, quero testar se o script gerado está correto. Existe uma maneira, mas é muito difícil e muitas vezes difícil de implementar facilmente.
-Não tenho ideia de modelagem de dados
CLI é sempre uma forma de interação humano-computador. Ele pode fornecer à rede certas capacidades de programação por meio de programas, mas, afinal, não é um método inerentemente programável em rede. Na atual onda de computação em nuvem e SDN, não é adequado para implantação automatizada em larga escala na rede e sua programabilidade é limitada. É difícil para quem está de fora compreender a dificuldade do desenvolvimento.
SNMP
SNMP (SNMP, Simple Network Management Protocol), este protocolo pode suportar sistemas de gerenciamento de rede para monitorar se os dispositivos conectados à rede apresentam alguma situação que chame a atenção do gerenciamento. Consiste em um conjunto de padrões de gerenciamento de rede, incluindo um protocolo de camada de aplicação, um esquema de banco de dados e um conjunto de objetos de dados.
Para um conteúdo da Wikipedia, destacamos gerenciamento de rede, monitoramento e objetos de dados. É utilizado para gerenciar a rede, pode ser configurado e coletado e é utilizado principalmente para monitoramento. Possui modelagem de dados para estruturar alguns módulos, características e dados de status dos equipamentos de rede. É usado principalmente para sistemas de gerenciamento de rede (principalmente monitoramento). Então vamos falar sobre suas deficiências:
-Má legibilidade. Prefere a “máquina” em homem-máquina. Não é legível quando usado e os dados de modelagem também não são legíveis. Ele usa um superconjunto de ASN.1.
-A segurança é limitada. Existem três versões: v1, v2c e v3, e a segurança é aprimorada em sequência. No entanto, o mais comum é o v2c, que possui segurança limitada. A versão v3 é muito segura por design, mas não é universal. . .
-Não há mecanismo de backup, recuperação ou reversão. Também temos show run e outros métodos para fazer backup da linha de comando, mas snmp. . .
-Muito poucas escritas. Leia muito, escreva pouco, usado principalmente para monitoramento.
-Os itens de dados que podem ser coletados são limitados e a configuração de todo o dispositivo não pode ser obtida. Muitas vezes descobrimos que podemos usar cli para coletá-lo, mas não podemos usar snmp para coletá-lo.
-Há um gargalo de desempenho. O limite superior de dados coletados é de 64K e a granularidade da coleta é muito grande. Em redes grandes e complexas, pode demorar alguns minutos ou mais. Isso também destaca o ponto importante. Nossos requisitos de granularidade também são muito rigorosos. Muitas vezes esperamos coletar o tráfego portuário a cada poucos segundos. Em grandes redes, acho que o software de gerenciamento de rede tradicional é... Para expandir em mais uma frase, o método atual é a telemetria (como o gRPC), que pode atingir o nível de microssegundos, e alguns exigem uma combinação de software e hardware. Ainda não é popular, mas no futuro deverá ser uma tendência. Quanto a quando isso acontecerá no futuro…
-Desde o seu nascimento, o SNMP tem sido muito utilizado na área de monitoramento de redes para obter dados para monitoramento. A falta e a complexidade dos recursos de configuração levaram a pouco uso deles na configuração de rede. Rede somente leitura programável.
Protocolo Netconf e modelo YANG
Diante da próxima geração de redes, que tipo de protocolos de gerenciamento de rede precisamos para realizar melhor a programabilidade da rede e melhorar o nível de automação?
A IETF propôs as seguintes ideias na RFC3535 em 2002 (na verdade, existem 33 delas. Com base em informações online e no conhecimento do autor, escrevi as seguintes ideias):
1. Existe uma interface programável para configuração de rede
2. A mesma configuração pode ser usada entre fabricantes e modelos
3. Necessidade de unificar uma linguagem de modelagem com boa legibilidade
4. Funções completas de verificação e recuperação de erros
5. Transacional
Se você tem uma ideia, basta implementá-la. Em 2006, a IETF propôs o protocolo Netconf, que resolveu os problemas levantados pela RFC3535. O Netconf inicial estipulou apenas a estrutura básica e as operações do protocolo, e definiu soluções que levaram em conta alguns problemas do RFC3535. Não estipulou uma linguagem de modelagem unificada. Portanto, alguns equipamentos dos primeiros fabricantes suportavam apenas algumas operações básicas do Netconf e não usavam uma camada inferior unificada. Linguagem de modelagem de dados.
O RFC6020 foi lançado em 2010, propondo a linguagem de modelagem do modelo YANG e um método para combiná-lo com o NETCONF. Uma definição é uma linguagem de modelagem de dados que unifica a lógica de recursos subjacente entre os fabricantes, e a outra definição é um conjunto de comandos unificado para as operações de cada fabricante em dados de configuração e dados de status. As instâncias de dados criadas pelo modelo YANG são agrupadas no protocolo Netconf. Transmissão, os dois são combinados entre si para construir um novo conjunto de interfaces programáveis de rede universal para a nova era com base no modelo YANG e impulsionado pelo protocolo Netconf.
Depois de 2016, o protocolo Netconf foi intimamente integrado ao modelo YANG e tornou-se popular. Até agora, quando olhamos para alguns aspectos do software da arquitetura SDN, ouvimos mais ou menos esses dois termos.
YANG e Netconf, um é estático e o outro é dinâmico, assim como yin e yang. Os dois derivaram o mundo programável em rede da próxima era. (Quando olhamos para o armazém YANG no github, também descobriremos que seu ícone é Tai Chi, e a conexão entre seu nome e "Yang" revela um pouco as ideias de design do designer original).
A seguir, falaremos brevemente sobre o modelo YANG e o protocolo Netconf. Vamos primeiro falar sobre a linguagem de modelagem de dados YANG para ver como ela descreve o gêmeo digital deste mundo de redes.
Modelo YANG
No documento RFC6020, o capítulo de abertura afirma claramente, YANG, uma linguagem de modelagem de dados para o protocolo de configuração de rede. É a abreviatura de Yet Another Next Generation (Yang) Data Modeling Language. É uma linguagem de modelagem usada para descrever conceitos de rede.
Suporta definição de listas, dicionários e estruturas de dados ainda mais complexas, suporta restrições, enumerações, importações de referência, gerenciamento de versões e namespaces. Devido ao espaço, daremos uma breve explicação. Para obter informações detalhadas, você pode consultar:
Ele pode descrever este dispositivo de rede de forma muito simples em uma linguagem estruturada. Por exemplo, para a definição de uma porta:
Como pessoal profissional de operação e manutenção, com um pouco de noções básicas de rede e um pouco de noções básicas de programação, você pode entender a definição de uma porta de forma relativamente clara. É uma estrutura de lista e pode haver várias. Um de seus atributos é nome-da-interface (também uma chave). , exclusivo, não repetível), bem como o atributo speed e o atributo duplex, ambos strings.
Muitos atributos de um dispositivo de rede são descritos pelo modelo YANG, incluindo status de configuração e status operacional.
Desta forma, o Modelo YANG descreve o mundo online usando linguagem estruturada. Se estiver interessado, você pode ler a postagem acima no blog da Internet, que contém uma descrição muito detalhada.
Ele pode ser muito bem convertido em dados XML e encapsulado no protocolo Netconf para transmissão (explicaremos isso mais tarde):

Ao mesmo tempo, para nivelar as diferenças entre fornecedores, a Openconfig, liderada pelo Google, padronizou o modelo de dados. No site oficial, vemos o slogan "Gerenciamento de rede neutro em relação ao fornecedor e orientado por modelo, projetado pelos usuários", que é projetado pelos usuários e é multiplataforma. Programação de rede comum do fornecedor e orientada por modelo (vamos traduzir desta forma primeiro). Simplificando, trata-se de fazer com que a modelagem entre os vários fabricantes seja a mesma, de modo que, ao configurar determinados dados, você não precise examinar o modelo yang privado de cada fabricante, um por um. Mas a Internet sempre tem protocolos privados, e diferentes fabricantes sempre criarão novos e melhores protocolos privados para “melhor experiência do usuário” e “melhor estratégia de negócios” (este é realmente o pecado original dos fabricantes de redes). A imagem mostra algumas das implementações do modelo openconfig yang mais comumente usadas.


A julgar pela imagem, acho que existem muitos deles e as configurações comumente usadas são relativamente completas. Mas, na prática, depende se o fabricante também oferece suporte a esses modelos yang. Alguns dispositivos de versão superior de um determinado assunto são basicamente suportados. Ainda não olhei mais de perto os nacionais.
As redes não podem ser exatamente iguais. Para um engenheiro que atua no desenvolvimento de operação e manutenção de redes, é uma bênção poder atingir o mesmo objetivo!
openconfig pode ser encontrado em https://github.com/openconfig/public/tree/master/release/models
Você pode encontrar modelos yang privados em vários sites oficiais.
Protocolo Netconf
Depois de falar sobre o modelo yang, vamos falar sobre o protocolo Netconf. O modelo yang define a descrição digital do mundo da rede, e o Netconf define a aquisição (get) e ajuste (config) de dados.
O Netconf encapsula os dados do mundo descritos pelo modelo yang para realizar o gerenciamento do mundo da rede.

Os dados Yang são encapsulados em xml e gerenciados através do protocolo Netconf. É um protocolo com uma ótima ideia em camadas, descrevendo alguns detalhes do protocolo de forma hierárquica. Vejamos a foto acima.
-Transmissão: O Netconf é transmitido através do protocolo SSH, é orientado à conexão e possui garantias de segurança.
-Mensagem: Faça uma chamada remota para o dispositivo de rede por meio de RPC, o gerenciador de rede emite uma solicitação RPC e o dispositivo de rede retoma a resposta RPC.
-Operação: Esta é a alma do Netconf. Ele suporta get (dados de configuração e execução), get-config (obtenção de dados de configuração, e um dispositivo pode ter vários dados de configuração, um em execução, uma inicialização, vários candidatos), edit -config (configurar parâmetros de dispositivos de rede, suporta adição, exclusão e modificação), delete-config, copy-config (copiar a configuração para o destino, o destino pode ser ftp, arquivo ou configuração em execução, etc.), lock\unlock (bloquear a configuração para evitar conflitos de configuração ou falhas causadas por operações de multiprocessos) e assim por diante.
-Dados: os dados são dados yang agrupados em xml. Assim como a porta que descrevemos acima, os dados estruturados são fáceis de programar. Usado para descrever os dados a serem configurados, excluídos ou obtidos.
Estas são as quatro camadas do Netconf. A extremidade de controle e o dispositivo de rede se comunicam através do Netconf, através do protocolo ssh tradicional, utilizando o subsistema Netconf, e a porta padrão é 830. Conforme mostrado abaixo:

Esta figura demonstra a interação usando ssh bruto, mas na verdade implementamos esse processo por meio de programação. Demonstrarei o método de implementação de programação para você mais tarde.
Netconf configura dispositivos de rede. O processo de interação é aproximadamente o seguinte:

Essa imagem é tão baixa que você também pode ver que foi desenhada por mim… Meu entendimento do Netconf é o mesmo acima. Acho que há muitas fotos na Internet que não estão corretas e muitos comportamentos do agente servidor não estão corretos. Isso é o que sinto intuitivamente quando faço login no dispositivo e, claro, corresponde exatamente à documentação oficial.
Podemos ver alguns exemplos do Netconf:
Olá, crie um link.

Vimos várias palavras-chave, versão Netconf, modelo YANG compatível, ID de sessão. Ao mesmo tempo, hello indica em qual namespace estamos operando. Neste caso, é a versão correspondente do Netconf.
Obter configuração

Um parâmetro do get-cofig é source, que é onde os dados de configuração são obtidos (em execução, inicialização ou outros). Outro parâmetro é o filtro, ou seja, quais dados são obtidos do modelo de dados descrito por qual modelo yang. Isto corresponde à capacidade enviada originalmente pelo dispositivo de rede. Se for bem-sucedido, os dados de configuração correspondentes serão retornados.
Obtenha dados de configuração ou execução

Semelhante ao get-config, mas o que se obtém é a execução da configuração (entendimento pessoal) ou a execução dos dados. O filtro pode ser especificado.
Copiar configuração

A operação de cópia possui dois parâmetros, origem e destino. A resposta bem-sucedida é com a tag ok.
Editar configuração

Ao editar a configuração, especifique o item de dados a ser editado, o namespace da capacidade e o rótulo correspondente. Por exemplo, isso é para configurar o dhcp, que é descrito pelo modelo yang http://tail-f.com/ns/example/dhcp.
Fechar sessão normalmente

É esse tipo de mensagem que é transmitida e recebida no ssh. Apenas extraímos parte da mensagem para facilitar o entendimento de todos.
Em seguida, basta adicionar algum conteúdo para referência.
-Netconf é baseado em sessão, e todo sucesso terá um ID de sessão.
-Cada solicitação possui um ID de mensagem, desde que gradativamente aumente
-A configuração dos dados pode ser bloqueada, exclusiva e operada por meio de bloqueio.
-Netconf é transacional e as operações são todas implementadas ou nenhuma. Ao mesmo tempo, de acordo com a documentação do site oficial, essa transacionalidade é para a configuração de N dispositivos de rede, ou seja, o polimorfismo de configuração única pode suportar a transacionalidade. Mas ainda não fiz isso…
-Netconf suporta assinatura. Em termos de desempenho do dispositivo, a ordem de grandeza é de cerca de 5 sessões. Posso assinar um determinado item de dados e o dispositivo me notificará quando ele for alterado.
-Capacidade, é assim que eu entendo. O dispositivo de rede envia a versão do Netconf e do modelo YANG, e o terminal de controle envia a versão do Netconf. Somente quando a versão do Netconf corresponder às duas podemos continuar. Este é o meu sentimento intuitivo. Qualquer conselho é bem-vindo.
-Operações como obter edição especificarão os dados a serem alterados, que podem ser filtrados usando filtro.
-copy-config suporta a cópia de um conjunto completo de configurações de algum lugar para outro. O local pode ser um arquivo FTP, configurações de execução, inicialização e candidatas no dispositivo.
-Netconf também suporta verificação de configuração, usando a operação de validação.
Este artigo ainda espera popularizar a ciência e não entrarei em detalhes. Você pode ler os protocolos RFC relevantes, que na verdade não são muito longos.
Na prática, com base em alguns softwares de código aberto, como o ncclient do python, podemos configurar facilmente dispositivos de rede automaticamente e obter programabilidade de rede. Esta é a missão do Netconf e do Modelo YANG.
O pessoal da rede lê as definições bem formatadas do modelo YANG e usa linguagens de programação relevantes para realizar operações programáveis em dispositivos de rede com base nas operações definidas pelo Netconf. Desta forma, o caminho para a programabilidade da rede é forjado.
Vamos expandir e imaginar que o modelo YANG definiu a estrutura de dados do dispositivo de rede. Podemos operá-lo através do Netconf. Também pode ser operado através de outros protocolos?
A resposta é sim. Na verdade, muitos outros protocolos foram derivados do Netconf, como o RESTConf. Como mostrado abaixo,

O modelo YANG (público e nativo) define a estrutura de dados, acima da qual estão os novos protocolos de gerenciamento de rede, Netconf, RESTCon, gRPC, etc. Desta forma, podemos operar dispositivos de rede através de RESTConf baseado em HTTP RESTful API, também podemos operar rede dispositivos através do Netconf baseado em SSH, ou podemos operar dispositivos de rede através do gRPC baseado em HTTP2.0. Todos são baseados em YANG com boa estrutura de dados. Modele, escreva os dados correspondentes, encapsule-os em xml ou json para programar dispositivos de rede. Este é o futuro da programabilidade de rede. Para ser mais preciso, é um Programa Orientado a Modelo, programabilidade de rede baseada em modelo. Os engenheiros de rede concentram-se gradualmente nos parâmetros do dispositivo em vez do conjunto de comandos e configuram os parâmetros da rede lendo o modelo de dados correspondente.
No final, escrevo, por que deveria abrir esta conta pública. Estudei ciência da computação e tecnologia quando estava na escola. Depois de entrar no local de trabalho, estive envolvido em trabalhos de operação e manutenção de redes. Pensando bem, o motivo pelo qual fui dividido em equipes pode ser porque eu era aluno de pós-graduação no Network Technology Research Institute (manual engraçado). Desde o início, estive envolvido em operações de rede. Na fase posterior de operação e manutenção, foram utilizadas ferramentas para simplificar o trabalho e melhorar a eficiência com base no CLI. Mais tarde, as ferramentas foram gradualmente desenvolvidas em aplicações web estruturadas em BS. Eles foram constantemente expostos a novas tecnologias e continuaram a enriquecer novas funções.
Felizmente, eles acompanharam o desenvolvimento da tecnologia de código aberto e do SDN e, gradualmente, fiz a transição para o trabalho de NetDevOps e usei minhas habilidades de programação para melhorar as capacidades de operação e manutenção da equipe. Também gostei de escrever esta linha de código. À medida que a escrita avança, é gradualmente descoberto que NetDevOps deve ser uma habilidade que todo engenheiro de rede deverá ter no futuro (todos colocam lenha na fogueira), para que possam alcançar um planejamento de alto nível e uma implementação rápida. Olhando para algumas informações na Internet, para ser sincero, há muito pouca na China e o ambiente interno não é muito forte. Muitos softwares domésticos são baseados no antigo CLI e snmp, e todos ainda usam ferramentas de texto e SSH para trabalhar. Então eu espero que euposso ensinar outras pessoas a pescar, compartilhar minha experiência (poços) e habilidades com mais engenheiros de operação e manutenção de redee fazer o meu melhor. Xiao Chu disse que você pode aprender algo para reduzir sua carga de trabalho e, ao focar no futuro distante, a operação e manutenção da rede doméstica podem realmente evoluir em direção à automação.
Futuramente gravarei alguns vídeos e escreverei alguns artigos. É muito cansativo escrever um documento. Você está convidado a se inscrever, coletar, clicar em curtir e assistir.
apêndice: Operações comuns do Netconf

Design de solução DWDM OTN e cotação de custos, por favor, conecte-se comigo, Taylor Huang















































