Posterior à definição das estratégias, que se deu por meio de aplicações distintas como apresentado na seção 3.1, elencaram-se as tarefas pertinentes à área funcional do modelo FCAPS que trata exclusivamente da gerência de configuração, comumente executadas pelos administradores de redes em seu cotidiano. Essas tarefas, enumeradas por um identificador e definidas por um escopo de utilização, são apresentadas no quadro 1.
Quadro 1 – Levantamento das tarefas de gerência de configuração de redes.
ID1 Tarefa Escopo de utilização
1 Recuperação da configuração
geral Retorna a configuração corrente do roteador.
22 Recuperação de todas as VLANs Retorna uma listagem de todas as VLANs contendo: VLANid, name e status.
3 Recuperação de VLAN
específica
Retorna as configurações de uma VLAN específica contendo: VLANid, name e status.
4 Criação de VLAN Informa os parâmetros vlanid, name e status para criação de uma nova
VLAN.
5 Alteração de estado de VLAN Altera o estado de uma VLAN entre active ou suspend.
6 Alteração de nome de VLAN Altera o nome de uma VLAN.
7 Exclusão de VLAN Exclui uma VLAN baseado no identificador (id) passado como
parâmetro. 83 Recuperação da tabela de
roteamento estático
Retorna uma listagem da tabela de roteamento estático com as redes e seus respectivos gateways.
9 Criação de rota estática
Informa os parâmetros destination, destinationPrefixMask e
forwardingRoutersAddress para criação de uma nova rota na tabela de roteamento.
10 Exclusão de rota estática Exclui uma entrada na tabela de roteamento baseado em destination e destinationPrefixMask passados como parâmetro.
11 Recuperação das configurações de interface
Retorna as configurações de uma porta específica passada como parâmetro.
12 Configuração de interface Configura uma interface de rede através dos parâmetros port, interfaceAddress, subnetMask, MTU e description.
13 Ativação de interface Ativação da interface de rede do roteador. 14 Desativação de interface Desativação da interface de rede do roteador.
Fonte: Elaborado pelo autor. Nota: 1 Identificador (ID).
Anterior à execução das tarefas 2 e 8 e com o objetivo de simular um cenário de produção foram criadas no roteador da marca Cisco modelo 2921:
2 48 VLANs (número máximo suportado pelo equipamento); 3
200 rotas estáticas no roteador (número máximo suportado pelo equipamento).
Após a execução dessas duas tarefas as VLANs e rotas criadas sinteticamente foram excluídas, retornando a uniformidade do ambiente.
Após a definição das tarefas foi necessário realizar o cruzamento dessas com seus devidos comandos CLI e NETCONF. O quadro 2 apresenta a listagem dos comandos CLI responsáveis por executar as tarefas apresentadas no quadro 1. Os comandos não listados neste quadro são encontrados no APÊNDICE A.
Quadro 2 – Comandos CLI responsáveis pelas tarefas 1, 2 e 12.
Tarefa Comando CLI
1 show running-config
2 show vlan-switch brief
12
conf t
interface GigabitEthernet interface ip address address subnetMask mtu MTU
description DESCRIPTION no shutdown
end
Fonte: Elaborado pelo autor.
Nota: Os trechos de configuração realçados em negrito são substituídos por parâmetros de métodos no momento da implementação.
Para o protocolo NETCONF, que se utiliza da linguagem de marcação XML nas camadas de mensagem, operação e conteúdo, os comandos de gerência de configuração são apresentados no quadro 3. As tarefas não listadas neste quadro são encontradas no APÊNDICE B.
Quadro 3 – Comandos NETCONF responsáveis pelas tarefas 1, 2 e 12.
ID Comando NETCONF
1
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-config> <source> <running/> </source> </get-config> </rpc>]]>]]> 2
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter>
<oper-data-format-text-block>
<show>vlan-switch</show>
</oper-data-format-text-block>
</filter>
</get> </rpc>]]>]]>
12
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <config> <cli-config-data>
<cmd>interface GigabitEthernet interface</cmd>
<cmd>ip address address subnetMask</cmd>
<cmd>mtu MTU</cmd> <cmd>description DESCRIPTION</cmd> </cli-config-data> </config> </edit-config> </rpc>]]>]]>
Fonte: Elaborado pelo autor.
Nota: Os trechos de configuração realçados em negrito são substituídos por parâmetros de métodos no momento da implementação.
Além da sintaxe XML apresentada por todos os comandos NETCONF, nota-se também na segunda linha de cada tarefa o elemento <rpc> que apresenta o modelo de
comunicação baseado no paradigma Remote Procedure Call – Chamada de Procedimento Remoto (RPC), onde um cliente (aplicação) codifica uma requisição RPC e a envia para um servidor (dispositivo de rede) com um atributo de identificação obrigatório denominado
message-id, também apresentado em cada tarefa NETCONF.
Seguindo os preceitos apresentados pela RFC 6241 que orientam o protocolo NETCONF, a camada de conteúdo também é definida em formato XML; porém, não é dependente de um padrão pré-estabelecido. Tomando por base a utilização do equipamento de rede que irá compor o cenário de testes (um roteador da marca Cisco modelo 2921 que será especificado nas seções seguintes), buscou-se em um primeiro momento a utilização da linguagem YANG para a modelagem da camada de conteúdo, porém sem êxito. Foi identificado então que a empresa Cisco, para esse equipamento, encapsula durante a execução de algumas tarefas NETCONF os comandos CLI dentro de tags XML baseada em uma definição proprietária4,5. Graças à divisão de camadas apresentada pelo protocolo NETCONF e, mesmo a camada de conteúdo sendo proprietária (fato permitido pelo padrão), a utilização do referido protocolo como forma de comparação para este trabalho é válida, pois para o equipamento suportar NETCONF deve basear-se única e exclusivamente nas imposições estabelecidas pelas camadas de transporte, mensagem e operação.
As tarefas e comandos elencados nos quadros 1, 2 e 3 serão utilizados na implementação das estratégias expostas na seção 3.3.