NETCONF & YANG API Orchestration
Guía
Publicado
2023-07-07
VERSIÓN 4.2
Introdución
Obxecto deste documento
Esta documentación describe como integrar Paragon Active Assurance cun orquestrator de servizos de rede a través da API NETCONF e YANG do Centro de control. Práctica exampOfrécense ficheiros das principais tarefas implicadas, incluíndo: crear e despregar axentes de probas virtuais, executar probas e monitores e recuperar os resultados destas actividades.
Neste documento, o cliente ncclient de Python NETCONF dispoñible de xeito gratuíto úsase no papel de orquestrador.
Convencións
Neste documento utilízanse as seguintes abreviaturas:
| Abreviatura | Significado |
| CLI | Interface de liña de comandos |
| EM | Xestor de elementos |
| ES | Segundo erro |
| MEP | Punto final MEG (grupo de entidades de mantemento) (definición ITU-T Y.1731) ou punto final de mantemento (definición Cisco) |
| NFV | Virtualización de funcións de rede |
| NFVO | Network Function Virtualization Orchestrator |
| NSD | Descriptor de servizo de rede |
| RPC | Convocatoria de procedemento remoto |
| SIP | Protocolo de inicio da sesión |
| SLA | Acordo de nivel de servizo |
| S-VNFM | Xestor especial de VNF |
| VNF | Función de rede virtual |
| vTA | Axente de proba virtual |
Notas sobre compatibilidade con versións anteriores
Nas versións 2.35.4/2.36.0 da API NETCONF e YANG, a validación de certas solicitudes fíxose máis estrita para cumprir co estándar NETCONF. Isto significa que agora se pode rexeitar o código de cliente baseado en versións antigas desta guía.
Por example, en Python anterior exampcódigo do le, non se proporcionou ningún atributo de espazo de nomes. O espazo de nomes agora debe proporcionarse no XML de solicitude sempre que queira modificar un recurso de ConfD.
Requisitos previos e preparacións
Instalación de ConfD
ConfD (un produto de Tail-f) úsase como intermediario entre o sistema Paragon Active Assurance e NETCONF. ConfD conecta a configuración e os datos operativos de Paragon Active Assurance coa API NETCONF e YANG.
ConfD debería estar instalado xunto co software do Centro de control, tal e como se describe na Guía de instalación.
Verificando que ConfD se está a executar
Para verificar que o ConfD está en funcionamento, execute o comando
ssh -s @localhost -p 830 netconf
para comprobar que ConfD responde no porto 830. No comando, é o definido polo usuario netconf create
comando na Guía de instalación, sección Instalación de ConfD. Dea o contrasinal definido polo mesmo comando.
Na saída, verifique que o módulo do Centro de control está incluído. A saída debe conter unha liña como a seguinte:
http://ncc.netrounds.com?module=netrounds-ncc&revisión=2017-06-15
Sincronización da base de datos de configuración co Centro de control
Finalmente, necesitamos actualizar a base de datos de configuración a través de NETCONF. Farémolo aquí mediante unha biblioteca Python chamada ncclient (Cliente NETCONF). Non obstante, a tarefa tamén se pode realizar nunha linguaxe de programación diferente sempre que utilice o protocolo NETCONF/YANG.
O papel de ncclient é actuar como cliente para o servidor ConfD que aloxa a API NETCONF/YANG.
Cabe sinalar que ncclient non está relacionado de ningún xeito co Control Center (anteriormente "Netrounds Control Center"), aínda que o nome comeza por "ncc".
Aquí tes como instalar ncclient:
- Descarga o software de https://github.com/ncclient/ncclient.
- Executa este comando: pip install ncclient
Agora podemos realizar a sincronización do seguinte xeito. Teña en conta que isto debe facerse nun ordenador separado e non no propio servidor do Centro de control:
#
# NOTA:
# Este script actúa como cliente para ConfD que se executa no servidor NCC.
# Usará a API NETCONF/YANG para a comunicación.
NOTA: Este procedemento tamén é necesario sempre que os axentes de proba foron instalados e rexistrados independentemente de NETCONF. Vexa a nota na sección “Encimaview de Test Agent Orchestration” na páxina 17 para obter máis información.
Configurar varias contas de Paragon Active Assurance controladas por NETCONF
Os pasos seguintes son necesarios só se desexa configurar outras contas de Paragon Active Assurance para que sexan controladas por NETCONF, ademais da conta configurada deste xeito na Guía de instalación, sección "Instalación de ConfD".
Para cada unha destas contas, proceda do seguinte xeito:
- No Centro de control, inicie sesión na conta e navegue ata Conta > Permisos.
- Engade o usuario "confd@netrounds.com", e concede a este permiso de administrador de usuario de ConfD na GUI facendo clic no botón Invitar.
- Sincronice a base de datos de configuración co Centro de control como se describe na sección "Sincronizar a base de datos de configuración co Centro de control" na páxina 4.
Agora deberías poder controlar varias contas de Paragon Active Assurance co mesmo usuario de ConfD.
NOTA: Unha vez que comece a controlar unha conta de Paragon Active Assurance a través de ConfD, NON debe facer cambios nesta conta a través do web GUI con respecto a calquera función de Paragon Active Assurance que estea "configurada" (consulte o capítulo "Funcións admitidas en Paragon Active Assurance" na páxina 9). Se o fas, producirase unha perda de sincronización.
Introdución á API de orquestración NETCONF
Acabadoview
Un NFVO ou un orquestrator de servizos de terceiros adoita ser o compoñente que inicia sesións de proba e seguimento mediante a API do Centro de control. Este orquestrator tamén recupera os resultados de medición agregados das actividades do axente de proba. Os KPI de rendemento poden ser recuperados por sistemas de xestión de rendemento de terceiros, mentres que os eventos, unha vez desencadeados por infraccións dos limiares establecidos no Centro de control, pódense enviar a sistemas de xestión de erros de terceiros.
Para resumir, a seguinte figura mostra como Paragon Active Assurance interactúa con outros sistemas de terceiros no panorama OSS.
- NFVO/Orquestrador de servizos: indícalle ao xestor de VNF que despregue os vTA e configure Paragon Active Assurance na cadea de servizo. Unha vez que se activa o servizo, o orquestrator usa a API cara ao Centro de control para activar as probas de activación do servizo e recuperar os resultados de aprobación ou falla. Se as probas son superadas, o orquestrator utilizará a API cara ao Centro de control para iniciar a monitorización activa do servizo. Os KPI do seguimento son recuperados continuamente polo orquestrador ou por unha plataforma de xestión de rendemento separada.
- Centro de control: implementa, escala e finaliza o vTA segundo as instrucións da NFVO ou o orquestrator de servizos.
- Sistema de xestión do rendemento ou sistema de xestión da calidade do servizo: le os KPI da supervisión activa a través da API do Centro de control.
- Sistema de xestión de fallos: recibe notificacións de NETCONF, SNMP ou correo electrónico do Centro de control se se infrinxen os SLA.
Definicións de conceptos en Paragon Active Assurance
- Axentes de proba: os compoñentes que realizan medicións (para probas e monitores) nun sistema de garantía activa de Paragon. Os axentes de proba consisten en software coa capacidade de xerar, recibir e analizar o tráfico de rede real.
- O tipo de axente de proba que se comenta neste documento é o axente de proba virtual (vTA), unha función de rede virtual (VNF) implantada nun hipervisor. Tamén existen outros tipos de axente de proba.
- Existen dous tipos básicos de medición en Paragon Active Assurance, probas e monitores.
- Proba: unha proba consta dun ou varios pasos, cada un dos cales ten unha duración determinada e finita. Os pasos execútanse secuencialmente. Cada paso pode implicar executar varias tarefas ao mesmo tempo.
- Monitor: un monitor non ten unha duración especificada pero execútase indefinidamente. Como un paso nunha proba, un monitor pode executar varias tarefas simultáneas.
- Modelo: cando Paragon Active Assurance está controlado por un orquestrador, as probas e monitores sempre se executan mediante modelos nos que se define a proba ou monitor. Os axustes dos parámetros pódense pasar como entradas ao modelo no tempo de execución.
Fluxo de traballo para automatización
Tempo de deseño
No momento do deseño, prepara as medicións creando modelos para probas e monitores en Paragon Active Assurance. Como facelo está descrito no capítulo "Modelos de proba e monitorización" na páxina 15.
Tempo de execución
No tempo de execución, configura os seus dispositivos e realiza as medicións reais.
- Un máisview de todos exampas dadas atópase no capítulo “Examparchivos de Control de Paragon Active Assurance mediante NETCONF & YANG API” na páxina 15.
- No capítulo "Examples: Axentes de proba” na páxina 16.
- Como importar artigos de inventario como TWAMP reflectores e canles IPTV recóllese no capítulo “Examples: Elementos de inventario” na páxina 29.
- Como configurar as alarmas explícase no capítulo “Examples: Alarmas” na páxina 35.
- Como executar probas e monitores executando modelos de Paragon Active Assurance a través de NETCONF descríbese nos capítulos "Examples: Probas” na páxina 43 e “Examples: Monitores” na páxina 54.
Funcións admitidas en Paragon Active Assurance
Todos os tipos de probas e monitores en Paragon Active Assurance pódense crear e executar mediante o uso de modelos. Como facelo está descrito na axuda da aplicación en "Probas e monitores" > "Creación de modelos".
Actualmente non se admite a creación de contas de Paragon Active Assurance; non obstante, teranse configurado unha ou varias contas predefinidas para o usuario.
As táboas seguintes detallan cales son as funcións de Paragon Active Assurance dispoñibles nesta versión e como se representan estas funcións en YANG.
Explicación das construcións YANG
Por comodidade, aquí se dan definicións das construcións YANG ás que se fai referencia na táboa de características.
- Config (config=true): datos de configuración, necesarios para transformar un sistema dun estado a outro.
- Estado (config=false): datos de estado: datos adicionais dun sistema que non son datos de configuración, como información de estado de só lectura e estatísticas recollidas.
- RPC: unha chamada de procedemento remoto, tal e como se usa no protocolo NETCONF.
- Notificación: notificacións de eventos enviadas desde un servidor NETCONF a un cliente NETCONF.
Táboas das funcións de garantía activa de Paragon dispoñibles para a orquestración
Recurso: Seguimento
Ruta YANG:/contas/conta/monitores
| Característica | Subfunción | Construción YANG |
| Crear/modificar/eliminar monitor | Baseado no modelo de monitor | Config |
| Monitor de inicio/parada | – | Config |
| Modelos de monitor | Lista os modelos de monitor existentes con entradas | Estado |
| Notificacións NETCONF | O estado da alarma cambiou | Notificación |
| Supervisar os resultados | Contador SLA/ES para o nivel superior (%) Contador SLA/ES para o nivel de tarefa (%) |
Estado |
A diferenza das probas (compare Recurso: Probas a continuación), os monitores non se inician cun RPC senón comprometendo a configuración do monitor.
Recurso: Tests
Ruta YANG: /accounts/account/tests
| Característica | Subfunción | Construción YANG |
| Comezar a proba | Baseado no modelo de proba | RPC |
| Xestionar probas | Lista de probas co estado | Estado |
| Modelos de proba | Lista os modelos de proba existentes con entradas | Estado |
| Notificacións NETCONF | O estado da proba cambiou | Notificación |
| Resultados da proba | Obter o estado do paso da proba (aprobado, fallado, erro,...) | Estado |
Recurso: Test Agents
Camiños YANG:
- /accounts/account/test-agents (Configuración)
- /accounts/account/registered-test-agents (Estado)
Os axentes de proba en /accounts/account/test-agents son os que están configurados nunha conta. Só estes axentes de proba poden ser configurados e usados en probas e monitores a través de NETCONF polo orquestrator.
Despois de ter configurado un axente de proba e rexistrado na conta, o axente de proba aparecerá en /accounts/account/registered-test-agents. Podes atopar todos os axentes de proba rexistrados usando un comando "get" en NETCONF (compare o capítulo Examples: Axentes de proba).
En /accounts/account/registered-test-agents tamén pode atopar axentes de proba que aínda non foron configurados. Calquera axente de proba deste tipo debe configurarse antes de poder utilizarse.
Nun escenario de orquestración, en xeral recoméndase que faga toda a configuración da súa conta de Paragon Active Assurance a través de NETCONF. Isto garante que os axentes de proba e os axentes de proba rexistrados non diverxen.
| Característica | Subfunción | Construción YANG |
| Pre-crear axente de proba no servidor | – | Config |
| Configurar o axente de proba sen conexión | (O Centro de control envía a configuración ao axente de proba cando está en liña) |
Config |
| Use axentes de proba existentes/configurados externamente | Uso en proba/monitor | Config |
| Configurar interfaces | Config | |
| Obter estado | Estado | |
| Configurar o axente de proba (só o dispositivo de proba) | Configurar NTP | Config |
| Configurar pontes | Config | |
| Configurar interfaces VLAN | Config | |
| Configure as claves SSH | Config | |
| IPv6 | Config | |
| Utilidades | Reinicie | RPC |
| Actualizar | RPC | |
| Notificacións NETCONF | O estado en liña cambiou | Notificación |
| Estado | Obter o estado do sistema (tempo de funcionamento, uso da memoria, carga media, versión) |
Estado |
Recurso: Inventario
Ruta YANG: /accounts/account/twamp- reflectores
Capacidades NETCONF soportadas
A táboa seguinte apunta aos RFC IETF que describen as capacidades NETCONF utilizadas para a orquestración de Paragon Active Assurance.
- ietf-netconf.yang
- IETF RFC 6241, Protocolo de configuración de rede (NETCONF), https://tools.ietf.org/html/rfc6241
- O único método de tratamento de erros compatible é a recuperación ante un erro.
- O único almacén de datos compatible é escribible.
- ietf-netconf-notifications.yang
- IETF RFC 5277, notificacións de eventos NETCONF, https://tools.ietf.org/html/rfc5277
Modelos de proba e monitor
Os modelos para os tipos de proba e monitores deben configurarse manualmente a través da interface de usuario de Paragon Active Assurance. Como facelo está descrito na axuda da aplicación en "Probas e monitores" > "Creación de modelos".
Examparchivos de Control de Paragon Active Assurance mediante NETCONF e YANG API
Nos capítulos seguintes, asúmese que se definiron modelos de proba e monitores axeitados segundo as instrucións que se indican no capítulo "Modelos de proba e monitor" na páxina 15.
Ferramentas utilizadas en Examples
Todos os exampOs ficheiros dos capítulos seguintes foron construídos utilizando as seguintes ferramentas de libre disposición:
- Pang: Úsase para visualizar e navegar polos modelos YANG.
- Dispoñible en https://github.com/mbj4668/pyang (clone desde git e execute python setup.py install).
- Cliente Python NETCONF "ncclient": Úsase para comunicarse co Centro de control mediante NETCONF.
- Dispoñible en https://github.com/ncclient/ncclient (executa pip install ncclient).
O modelo de datos netrounds-ncc.yang atópase en /opt/netrounds-confd unha vez que se instalou ConfD segundo a Guía de instalación).
Acabadoview de tarefas clave realizadas
(No que segue tamén se exemplifican algunhas tarefas máis.)
- "Creación e implantación dun novo axente de proba" na páxina 16
- "Creación de elementos de inventario (por exemplo, reflectores)" na páxina 29
- "Configuración de modelos de alarma e onde enviar alarmas" na páxina 35
- “Crear e executar unha proba” na páxina 45
- "Recuperación dos resultados da proba" na páxina 50
- "Inicio dun monitor (inclúe a configuración de alarmas)" na páxina 60
- “Recuperación do estado de SLA para un monitor” na páxina 67
- “Traballando con tags” na páxina 71
Examples: Axentes de proba
Acabadoview de Test Agent Orchestration
Os axentes de proba en Paragon Active Assurance considéranse como "configuración" no contexto da orquestración. Isto significa que a creación, o control e a eliminación dos axentes de proba deberían facerse a través do orquestrator e NETCONF en lugar da GUI de Paragon Active Assurance.
IMPORTANTE: se un técnico instala un axente de proba e rexistrase no Centro de control sen que se crease previamente a través da API NETCONF e YANG, o axente de proba non existirá na base de datos de configuración e o sistema perderase de sincronización. Para que ConfD teña coñecemento do axente de proba neste caso, será necesario realizar unha nova sincronización co Centro de control, tal e como se detalla na sección "Sincronización da base de datos de configuración co Centro de control" na páxina 4.
Polo tanto, a orquestración de axentes de proba virtuais (vTA) debería facerse nos seguintes pasos:
- Cree o axente de proba virtual, incluída a súa configuración de interface, usando a interface NETCONF e YANG para o Centro de control. O nome do axente de proba será a súa clave única.
- Implementa o vTA nunha plataforma de virtualización. Siga as instrucións da axuda en liña en Axentes de proba > Instalación. A configuración básica da interface que permite que o vTA se conecte ao Centro de control, así como as credenciais para a autenticación, ofrécese no vTA mediante datos de usuario iniciados na nube.
Unha vez que se inicie o vTA, conectarase automaticamente ao Centro de control mediante unha conexión OpenVPN cifrada. Envíase unha notificación NETCONF xa que o valor do parámetro test-agent-statuschange do vTA agora cambiou a "en liña".
NOTA: Dado que o nome do vTA é o seu identificador no Centro de control, este nome debe ser o mesmo que o definido no Centro de control no "paso 1" na páxina 17. - Unha vez que o vTA se conectou e se autenticou no Centro de control, a configuración da interface envíase ao vTA. Esta é a configuración da interface proporcionada no "paso 1" na páxina 17 cando se creou o vTA no Centro de control.
- Despois de que o vTA cumpre o seu propósito, elimine o vTA.
Creación e implantación dun novo axente de proba
Primeiro necesitamos crear un axente de proba usando a interface NETCONF e YANG para o Centro de control. Cando se crea un axente de proba deste xeito, non é necesaria ningunha sincronización co Centro de control.
O modelo YANG para un axente de proba é o que se mostra a continuación. Obtense como saída do comando
pyang -f árbore netrounds-ncc.yang
O modelo YANG completo aparece no "Apéndice: Estrutura en árbore do modelo YANG completo" na páxina 81, que tamén contén unha lenda que explica as convencións utilizadas nesta e outras ilustracións do modelo YANG no presente documento.
Seguimos os seguintes pasos, que se detallan a continuación:
- Ao principio, a conta "demo" de Paragon Active Assurance non ten axentes de proba no seu inventario.
- Un axente de proba chamado "vta1" créase usando ncclient. Neste stage, aínda non existe ningún axente de proba real (é dicir, aínda non se iniciou).
- O axente de proba está implantado en OpenStack. (O despregamento nesa plataforma elíxese aquí como unha posibilidade entre outras).
- O axente de proba conéctase á conta "demo" do Centro de control e agora está listo para o seu uso.
Paso 1: ao principio, non hai axentes de proba na conta "demo". Vexa a seguinte captura de pantalla desde a GUI do Centro de control.
Paso 2: créase un axente de proba no Centro de control usando o cliente Python NETCONF "ncclient". Abaixo amósase o código ncclient para crear un axente de proba cunha interface física cun enderezo DHCP:
importar argparse
do xestor de importación de ncclient
parser = argparse.ArgumentParser(description='Proba creando axente de proba')
parser.add_argument('–host', help='O nome do host onde se atopa ConfD', required=True)
parser.add_argument('–port', help='O porto para conectarse a ConfD', require=True)
parser.add_argument('–username', help='O nome de usuario para conectarse a ConfD', require=True)
parser.add_argument('–contrasinal', help='Contrasinal da conta de ConfD', requirido=Verdadero)
parser.add_argument('–netrounds-account', help='O nome curto da conta NCC', requirido=Verdadero)
parser.add_argument('–test-agent-name', help='Nome do axente de proba', requirido=Verdadero)
args = parser.parse_args()
con manager.connect(host=args.host, port=args.port, username=args.username,
password=args.password, hostkey_verify=False) como m:
# Crear axente de proba no Centro de control
xml = """
)print m.edit_config(destino='en execución', config=xml)
NOTA: O código que precede a manager.connect(…) omítese do exampfragmentos de código de le.
Un servidor NTP está configurado en eth0 e eth0 tamén é a interface de xestión (é dicir, a interface que se conecta ao Centro de control).
Unha aplicación de axente de proba non permite actualmente configurar interfaces. Por este motivo, a partir da versión 2.34.0, é posible omitir a configuración da interface no esquema YANG. Polo tanto, o XML correspondente simplifícase radicalmente neste caso:
Unha vez creado o axente de proba, existe na base de datos de configuración e no Centro de control. Vexa a seguinte captura de pantalla do inventario do axente de proba, que mostra o axente de proba "vta1":
Paso 3: agora é hora de implementar o axente de proba "vta1" en OpenStack.
O axente de proba usará os datos de usuario de inicio na nube para recuperar a información sobre como conectarse ao Centro de control. En concreto, o texto dos datos do usuario file ten o seguinte contido (ten en conta que as liñas #cloud-config e netrounds_test_agent deben estar presentes e que as liñas restantes deben estar sangradas):
Para obter máis información, consulte o documento Como implementar axentes de proba virtuais en OpenStack.
Unha vez que se implantou o axente de proba e conectouse ao Centro de control, a configuración enviarase desde o Centro de control ao axente de proba.
Paso 4: o axente de proba está agora en liña no Centro de control e obtivo a súa configuración. O axente de proba está preparado para o seu uso en probas e seguimento. Consulta estas seccións:
- "Iniciar unha proba" na páxina 45
- “Inicio dun monitor” na páxina 60
Lista dos axentes de proba na súa conta de garantía activa de Paragon
Abaixo está o example ncclient código Python para listar os axentes de proba nunha conta de Paragon Active Assurance:
Executar este código dá unha saída como a seguinte:
Eliminación dun axente de proba
Despois de completar unha proba, pode ser relevante nalgúns casos de uso eliminar o axente de proba.
A continuación móstrase un fragmento de código que mostra como facelo con ncclient:
Notificacións NETCONF
A continuación, presentamos un sinxelo example script para escoitar todas as notificacións NETCONF entrantes do Centro de control. Estas notificacións envíanse sempre que teñan lugar certos eventos, como un axente de proba que non está conectado ou que se completa unha proba iniciada polo usuario. A partir da información levada nas notificacións, os usuarios poden asignar accións de seguimento automatizadas no orquestrator.
Cando se execute o script anterior, o cliente NC presentará a notificación recibida en XML estruturado. Ver o exampa saída do ficheiro a continuación, que mostra un axente de proba que se desconecta de forma inesperada.
2017-02-03T15:09:55.939156+00:00</eventTime>
<test-agent-status-change xmlns=’http://ncc.netrounds.com'>
demostración
HW1
fóra de liña
Examples: artigos de inventario
Creación (importación) e xestión de elementos de inventario como TWAMP reflectores e Y.1731 MEPs realízase dun xeito similar ao dos axentes de proba. A continuación móstrase código XML e NETCONF para definir tales entidades en Paragon Active Assurance mediante a API NETCONF e YANG e para recuperar listas dos elementos definidos.
Creando un TWAMP Reflector
Creando un MEP Y.1731
Creación dunha canle IPTV
Creando un host de ping
Creación dunha conta SIP
Recuperación de elementos de inventario
Abaixo está o código de Python para recuperar todos os elementos de inventario definidos nunha conta. (Todos os tipos de elementos de inventario obtéñense dunha soa vez aquí para evitar algunha repetición no documento. Por suposto, calquera subconxunto de elementos de inventario pódese obter deixando fóra algunhas das liñas da conta a continuación.)
Executar este código dá unha saída como a seguinte:
Examples: Alarmas
Os modelos de alarmas e os elementos asociados (xestores SNMP, listas de correo electrónico de alarmas) créanse e xestionanse dun xeito similar aos elementos de inventario. Este capítulo contén código XML e NETCONF para definir tales entidades en Paragon Active Assurance a través da API NETCONF e YANG e para recuperar listas dos elementos definidos.
Listas de correo electrónico de alarma
Creación dunha lista de correo electrónico de alarma
Recuperando todas as listas de correo electrónico de alarmas
Xestores SNMP
Creación dun xestor SNMP
Recuperando todos os xestores SNMP
Modelos de alarma
Creación dun modelo de alarma
Recuperando todos os modelos de alarma
Examples: Chaves SSH
Podes engadir chaves públicas SSH a un axente de proba a través da API NETCONF e YANG. Usando a clave privada correspondente, pode iniciar sesión no axente de proba a través de SSH.
A lista completa de operacións dispoñibles nas claves SSH é a seguinte:
- Engade unha chave SSH
- Modificar unha chave SSH
- Inspeccionar unha chave SSH
- Lista de claves SSH
- Eliminar unha chave SSH.
A continuación, exemplifícanse as operacións de engadir e eliminar.
Eliminando unha chave SSH
Se desexa eliminar unha chave SSH, use o seguinte comando:
Examples: Probas
Suponse aquí que os axentes de proba (tantos como sexan necesarios para as probas) foron creados segundo a sección "Creación e implantación dun novo axente de proba" na páxina 17.
Camiños do modelo YANG para probas
| Elemento | Ruta do modelo YANG: /accounts/account/tests... |
| probas | /. |
| proba[id] | /proba |
| id | /test/id |
| nome | /test/nome |
| estado | /test/status |
| hora de inicio | /proba/hora de inicio |
| tempo final | /proba/hora final |
| informe-url | /informe de ensaio-url |
| pasos | /test/pasos |
| paso[id] | /proba/pasos/paso |
| nome | /test/pasos/paso/nome |
| id | /test/pasos/paso/id |
| hora de inicio | /proba/pasos/paso/hora de inicio |
| tempo final | /test/steps/step/end-time |
| estado | /test/steps/step/status |
| mensaxe de estado | /test/steps/step/status-message |
| modelos | /modelos |
| modelo [nome] | /modelos/modelo |
| nome | /modelos/modelo/nome |
| descrición | /modelos/modelo/descrición |
| parámetros | /templates/template/parameters |
| parámetro [clave] | /templates/template/parameters/parameter |
| chave | /templates/template/parameters/parameter/key |
| tipo | /templates/template/parameters/parameter/type |
Requisitos previos para a orquestración da proba
- Para iniciar unha proba a través de NETCONF usando o cliente NC, primeiro é necesario crear un modelo de proba usando a GUI do Centro de control, tal e como se detalla na axuda da aplicación en "Probas e monitores" > "Creación de modelos". Todos os campos especificados nese modelo como "Entrada do modelo" serán necesarios como parámetros no XML ao orquestrar o inicio do modelo de proba.
- Realizar probas en Paragon Active Assurance considérase "estado" no contexto da orquestración. Os datos de estado son datos non escribibles que non se almacenan na base de datos de configuración, a diferenza dos datos de configuración mencionados na secciónview da orquestración do axente de probas” na páxina 17. Isto significa basicamente que os cambios nas probas ou nos modelos na GUI do Centro de control non provocarán ningún problema relacionado coa sincronización entre o Centro de control e a base de datos de configuración.
- Para obter un informe-URL directamente nos informes de proba, debes asegurarte de que o Centro de control URL está configurado correctamente. Isto faise no file /opt/netrounds-confd/settings.py. De forma predeterminada, o nome de host do Centro de control obténse mediante socket.gethostname(): vexa a continuación. Se isto non dá o resultado correcto, cómpre establecer o nome do servidor (ou o nome completo URL) manualmente neste file.
# URL do Centro de control sen barra oblicua.
# Isto é por exemploample usado no informe de proba-url.
HOSTNAME = socket.gethostname()
REDES_URL = 'https://%s' % HOSTNAME
Comezando unha proba
Como se describe na sección "Creación e implantación dun novo axente de proba" na páxina 17, execute o comando pang -f tree netrounds-ncc.yang
desde o directorio /opt/netrounds-confd/ para sacar o modelo YANG. Neste modelo, o RPC para iniciar unha proba usando o cliente NC é o seguinte:
Para explicacións, consulte a sección "Lenda" na páxina 81 no Apéndice.
A continuación móstranse os seguintes pasos:
- Os axentes de proba rexistráronse na conta de Paragon Active Assurance, pero aínda non se iniciaron probas.
- Os parámetros de entrada necesarios identifícanse no modelo de proba que se executará.
- Iníciase unha proba HTTP de 60 segundos usando ncclient.
Paso 1: ao principio, non se iniciaron probas na conta de Paragon Active Assurance. Vexa a seguinte captura de pantalla desde a GUI do Centro de control.
Paso 2: O modelo que usaremos para iniciar a proba neste example é un modelo de proba HTTP. Ten dous campos de entrada obrigatorios (Clientes e URL) que especificamos como tal ao crear o modelo na GUI do Centro de control.
Definiremos estes parámetros (entre outros) na configuración XML comunicada á base de datos de configuración polo noso xestor NETCONF (ncclient).
Paso 3: a proba HTTP iníciase usando ncclient.
Abaixo está o exampcódigo de ficheiro onde se especifica a información de configuración e os parámetros necesarios para o modelo de proba HTTP. Dependendo de como se construíu o modelo, os detalles aquí poden variar.
Para cada parámetro, o debe proporcionarse o atributo. A clave é idéntica á do parámetro
Nome da variable no Centro de control. Podes inspeccionar os nomes das variables do seguinte xeito:
- Fai clic en Probas na barra lateral e selecciona Nova secuencia de probas.
- Fai clic en Os meus modelos.
- Fai clic na ligazón Editar debaixo do modelo de interese.
- Fai clic no botón Editar entrada na esquina superior dereita.
No noso exampe, por defecto, os nomes das variables son simplemente versións en minúscula dos nomes de visualización que se ven no Centro de control ("url" vs "URL", etc.). Non obstante, na GUI do Centro de control, pode cambiar o nome das variables ao que queira.
Ademais da clave, cada parámetro debe ter o seu tipo especificado: por exemploample, para o URL.
Teña en conta que cómpre volverview o modelo completo YANG para obter información completa sobre os tipos. Para as interfaces de axente de proba, o tipo ten unha estrutura máis complexa, como se demostra a continuación no código a continuación.
Agora podemos executar o script usando ncclient. Asumindo que todo é correcto, iniciarase a proba e a súa execución mostrarase no Centro de control:
Se a proba se inicia con éxito, o Centro de control responderá co ID da proba. Neste example, o ID da proba é 3:
O ID da proba tamén se pode atopar na páxina URL para a proba na GUI do Centro de Control. Neste example, iso URL é https://host/demo/testing/3/.
Recuperación dos resultados das probas
A forma máis sinxela de recuperar os resultados da proba é apuntando ao ID da proba.
Abaixo está o código Python para obter os resultados da proba HTTP anterior con ID = 3:
co xestor. Conectar(host=args.host, port=args.port, username=args.username, password=args.password, hostkey_verify=False) como m:
A saída terá un aspecto así:
Exportación e importación de modelos de proba
Os modelos de proba pódense exportar en formato JSON e reimportarse nese formato ao Centro de control. Isto é útil se queres usar modelos de proba nunha instalación diferente do Centro de control. (A creación inicial dos modelos é mellor xestionada a través da GUI do Centro de control).
Abaixo está o código para realizar a exportación e importación.
Exportando modelos de proba
# Obter a configuración json da resposta
raíz = ET.fromstring(resposta._raw)
json_config = raíz[0].text
imprimir json_config
O modelo está contido no obxecto json_config.
Importación de modelos de proba
Un obxecto de configuración JSON que contén modelos de proba pódese volver importar ao Centro de control do seguinte xeito.
Examples: Monitores
Esta sección asume que os axentes de proba (tantos que sexan requiridos polos monitores) foron creados segundo a sección "Creación e implantación dun novo axente de proba" na páxina 17.
Camiños do modelo YANG para monitores
| Elemento | Ruta do modelo YANG: /accounts/account/monitors... |
| monitores | /. |
| monitor [nome] | /monitor |
| nome | /monitor/nome |
| descrición | /monitor/descrición |
| comezou | /monitor/iniciado |
| modelo | /monitor/modelo |
| configuración de alarma | /monitor/alarm-configs |
| Elemento | Ruta do modelo YANG: /accounts/account/monitors/monitor/alarm-configs... |
| alarma-config[identificador] | /alarm-config |
| identificador | /alarm-config/identifier |
| modelo | /alarm-config/template |
| correo electrónico | /alarm-config/email |
| snmp | /alarm-config/snmp |
| tr-es-crítico | /alarm-config/thr-es-critical |
| thr-es-critical-clear | /alarm-config/thr-es-critical-clear |
| tr-es-maior | /alarm-config/thr-es-major |
| tr-es-maior-clear | /alarm-config/thr-es-major-clear |
| tr-es-menor | /alarm-config/thr-es-minor |
| tr-es-menor-claro | /alarm-config/thr-es-minor-clear |
| tr-es-advertencia | /alarm-config/thr-es-warning |
| thr-es-warning-clear | /alarm-config/thr-es-warning-clear |
| sen gravidade dos datos | /alarm-config/no-data-severity |
| tempo de espera sen datos | /alarm-config/no-data-timeout |
| acción | /alarm-config/action |
| tamaño da fiestra | /alarm-config/window-size |
| intervalo | /alarm-config/interval |
| enviar só unha vez | /alarm-config/send-only-once |
| snmp-trap-por-stream | /alarm-config/snmp-trap-per-stream |
| Elemento | Ruta do modelo YANG: /accounts/account/monitors... |
| parámetros | /monitor/parameters |
| Elemento | Ruta do modelo YANG: /accounts/account/monitors/monitor/parameters... |
| parámetro [clave] | /parámetro |
| chave | /parámetro/clave |
| (tipo de valor) | /parámetro |
| :(número enteiro) | /parámetro |
| enteiro | /parámetro/entier |
| :(flotar) | /parámetro |
| flotar | /parámetro/float |
| :(cadea) | /parámetro |
| Elemento | Ruta do modelo YANG: /accounts/account/monitors/monitor/parameters... |
| corda | /parámetro/cadea |
| :(test-agent-interfaces) | /parámetro |
| interfaces de axente de proba | /parameter/test-agent-interfaces |
| test-agent-interface[“1” na páxina 58 | /parameter/test-agent-interfaces/ |
| conta | /parámetro/test-agent-interfaces/test-agent-interface/account |
| axente de proba | /parameter/test-agent-interfaces/test-agent-interface/test-agent |
| interface | /parameter/test-agent-interfaces/test-agent-interface/interface |
| versión ip | /parameter/test-agent-interfaces/test-agent-interface/ip-version |
| :(dosamp- reflectores) | /parámetro |
| twamp- reflectores | /parámetro/twamp- reflectores |
| twamp-reflector[nome] | /parámetro/twamp-reflectores/twamp-reflector |
| nome | /parámetro/twamp-reflectores/twamp-reflector/nome |
| :(y1731-meps) | /parámetro |
| y1731-meps | /parámetro/y1731-meps |
| y1731-mep[nome] | /parameter/y1731-meps/y1731-mep |
| nome | /parameter/y1731-meps/y1731-mep/nome |
| :(contas-sip) | /parámetro |
| contas sip | /parámetro/contas-sip |
| sip-count[“2” na páxina 58] | /parámetro/contas-sip/conta-sip |
| conta | /parámetro/contas-sip/conta-sip/conta |
| axente de proba | /parámetro/contas-sip/conta-sip/axente-de-proba |
| interface | /parámetro/contas-sip/conta-sip/interface |
| dirección de sorbo | /parámetro/contas-sip/conta-sip/enderezo-sip |
| :(canles-iptv) | /parámetro |
| canles iptv | /parámetro/canles-iptv |
| canle-iptv[nome] | /parámetro/canles-iptv/canle-iptv |
| nome | /parámetro/iptv-channels/iptv-channel/nome |
- interface de proba de conta-axente
- interface de axente de proba da conta enderezo sip
| Elemento | Ruta do modelo YANG: /accounts/account/monitors... |
| estado | /monitor/status |
| últimos 15 minutos | /monitor/status/últimos-15-minutos |
| estado | /monitor/status/last-15-minutes/status |
| estado-valor | /monitor/status/last-15-minutes/status-value |
| última hora | /monitor/status/last-hour |
| estado | /monitor/status/last-hour/status |
| estado-valor | /monitor/status/last-hour/status-value |
| últimas 24 horas | /monitor/status/last-24-hours |
| estado | /monitor/status/last-24-hours/status |
| estado-valor | /monitor/status/last-24-hours/status-value |
| modelos | /modelos |
| modelo [nome] | /modelos/modelo |
| nome | /modelos/modelo/nome |
| descrición | /modelos/modelo/descrición |
| parámetros | /templates/template/parameters |
| parámetro [clave] | /templates/template/parameters/parameter |
| chave | /templates/template/parameters/parameter/key |
| tipo | /templates/template/parameters/parameter/type |
Requisitos previos para a orquestración do monitor
Antes de poder iniciar un monitor a través de NETCONF usando ncclient, cómpre crear un modelo de monitor na GUI do Centro de control tal e como se explica na axuda da aplicación en "Probas e monitores" > "Creación de modelos". Todos os campos especificados como "Entrada de modelo" nese modelo serán necesarios como parámetros no XML ao orquestrar o inicio do modelo.
Obtención de parámetros de entrada de modelos de monitor
A continuación móstranse dous modelos. O primeiro é para a supervisión de UDP entre dúas interfaces de axente de proba e o segundo é para HTTP mediante unha única interface de axente de proba.
Para coñecer os parámetros de entrada dun modelo, faga clic na caixa que representa o modelo. Para o modelo HTTP, os parámetros poden verse así:
Necesitamos definir estes parámetros no seguinte paso ao iniciar un monitor.
Iniciando un monitor
Usando os axentes de proba que definimos e implantamos na sección "Creación e implantación dun novo axente de proba" na páxina 17, podemos iniciar un monitor desde o modelo "HTTP", como se mostra a continuación.
Para cada parámetro, o debe proporcionarse o atributo. A clave é idéntica ao nome da variable do parámetro no Centro de control. Podes inspeccionar os nomes das variables do seguinte xeito:
- Fai clic en Monitorización na barra lateral e selecciona Novo monitor.
- Fai clic en Os meus modelos.
- Fai clic na ligazón Editar debaixo do modelo de interese.
- Fai clic no botón Editar entrada na esquina superior dereita.
No noso exampe, por defecto, os nomes das variables son simplemente versións en minúscula dos nomes de visualización que se ven no Centro de control ("url" vs "URL", etc.). Non obstante, na GUI do Centro de control, pode cambiar o nome das variables ao que queira.
Ademais da clave, cada parámetro debe ter o seu tipo especificado: por exemploample, para o URL. Teña en conta que a información completa sobre o tipo de parámetro atópase no modelo YANG. Para as interfaces de axente de proba, o tipo ten unha estrutura máis complexa, como se evidencia no código a continuación.
No exampque segue, non se asocia ningunha alarma co monitor. Por exampficheiros que impliquen alarmas, vaia á sección "Iniciar un monitor cunha alarma" na páxina 62.
Iniciando un monitor cunha alarma
Para asociar unha alarma cun monitor, pode apuntar a un modelo de alarma que se definiu ou proporcionar toda a configuración da alarma ao crear o monitor. Daremos un example de cada enfoque a continuación.
Configurar unha alarma de monitor apuntando a un modelo de alarma
Para poder facer uso dun modelo de alarma, debes coñecer o seu ID. Para iso, primeiro recupere todos os modelos de alarma tal e como se describe na sección "Recuperación de todos os modelos de alarma" na páxina 39 e anote o nome do modelo correspondente. Despois podes consultar ese modelo do seguinte xeito:
Configurar unha alarma de monitor configurándoa Directly
Alternativamente, pode configurar unha alarma para un monitor proporcionando a súa configuración completa ao crear o monitor, sen facer referencia a un modelo de alarma. Isto faise como se mostra no seguinte example.
Recuperación de monitores en execución
Para recuperar todos os monitores que se están executando actualmente, execute este script:
co xestor. connect(host=args.host, port=args.port, username=args. nome de usuario, contrasinal=args.password, hostkey_verify=False) como m:
A saída é unha lista de todos os monitores en execución como se mostra a continuación:
Recuperando o estado de SLA para un monitor
Aquí tes como recuperar o estado do SLA dun monitor. Neste example, estamos recuperando o estado de SLA para o monitor "Calidade da rede" durante tres intervalos de tempo: os últimos 15 minutos, a última hora e as últimas 24 horas.
A saída terá un aspecto así:
Notificacións NETCONF
As notificacións NETCONF para monitores desenvólvense por infraccións do SLA. Estes ocorren cando o SLA para o monitor cae por debaixo dun limiar SLA ("Bo" ou "Aceptable") dentro dunha xanela de tempo determinada, por defecto os últimos 15 minutos. Nótese que as notificacións de violación do SLA aparecen rapidamente despois de que un servizo se vexa afectado por un problema, mentres que o estado do SLA volverá a ser "Bo" só despois de 15 minutos, e só se non se producen máis infraccións.
A xanela de tempo pódese cambiar editando a configuración SLA_STATUS_WINDOW (valor en segundos) en /etc/netrounds/netrounds.conf.
Exportación e importación de modelos de monitor
Isto faise exactamente do mesmo xeito que para os modelos de proba; compare a sección "Exportación e importación de modelos de proba" na páxina 52. Os fragmentos de código que aparecen a continuación ilustran como exportar e importar modelos para monitores.
Exportando modelos de monitor
Importación de modelos de monitor
Tags definido en Paragon Active Assurance pódese aplicar a:
- monitores
- modelos de monitor
- Axentes de proba
- TWAMP reflectores
- Anfitrións de ping.
Por example, podes tag un monitor co mesmo tag como un subconxunto de axentes de proba que executarán o monitor. Esta función é especialmente útil se tes un gran número de monitores e modelos definidos.
Se configurou unha alarma con trampas SNMP para un monitor, as trampas SNMP asignaranse o mesmo tags como monitor, se é o caso.
Creando Tags
A continuación mostramos como crear un tag co nome e cor definidos polo XMLtag> subestructura.
Asignando a Tag
Para asignar a tag a un recurso, engádeo como novotag> elemento baixo otags> elemento para ese recurso.
Aquí tes como asignar un tag a un axente de proba:
Para asignar a tag a un TWAMP reflector, faga o seguinte:
Asignando a tag a un monitor trátase de xeito similar:
Alternativamente, pode asignar un existente tag a calquera destes tipos de recursos ao crear o recurso, incluíndo otags> elemento que contén o tag en cuestión.
Actualizando a Tag
Actualizando un existente tag con novos atributos é análogo á creación dun tag:
Anular a asignación a Tag
Para anular a asignación a tag desde un recurso, engade o atributo nc:operation="delete" aotag> elemento pertencente ao recurso. A continuación, anulamos a asignación dun tag dun monitor.
Eliminando a Tag
Para eliminar a tag desde o Centro de control, utilízase de novo o atributo nc:operation="delete", pero esta vez aplícase ao tag en si, definido baixo .
Resolución de problemas
Problema: Orchestrator e Paragon Active Assurance fóra de sincronización
O orquestrator e Paragon Active Assurance poden acabar sen sincronizarse, por exemploample se se fixeron cambios na configuración na GUI do Centro de control ou se a aplicación dunha configuración non foi exitosa e non se puido recuperar o estado anterior.
No caso de que se produza unha recuperación fallida, o servidor NETCONF xa non aceptará cambios de configuración; responderá cunha mensaxe de erro que indica que a configuración está bloqueada ata que se sincronice de novo. Para volver sincronizarse e desbloquear os cambios de configuración, cómpre executar o comando rpc sync-from-ncc que sincroniza toda a configuración do Centro de control á base de datos de configuración.
NOTA: O confd@netrounds.com o usuario (ou o que teña configurado) debe ter privilexios de superusuario para que todo se sincronice correctamente. Isto pódese conseguir co comando ncc user-update confd@netrounds.com –is-superusuario Se o usuario non é un superusuario, aparecerá un aviso que indica que non se puido sincronizar todo, pero que todo o que se puido manexar foi.
NOTA: Se o teu orquestrador tamén almacena a configuración, terás que volver sincronizar esta, xa que a configuración solicitada (a configuración que o orquestrador espera que teña o Centro de control) non se aplicará.
Problema: Fallou a sincronización inicial (sync-from-ncc) debido a recursos non compatibles
Se tentas executar rpc sync-from-ncc nunha conta que ten a súa configuración creada na GUI do Centro de control, pode ter problemas se a conta contén recursos non compatibles. Recoméndase que comece cunha conta baleira e faga toda a súa configuración a través de NETCONF. En caso contrario, se atopas problemas con conflitos de recursos, terás que eliminar os recursos en conflito da conta.
Problema: os comandos NETCONF fallan con ncclient.operations.rpc.RPCError: fallo de comunicación da aplicación
O servidor NETCONF non restaura a conectividade ao servidor do Centro de control automaticamente se se reinicia o Centro de control. Para restaurar a conexión ao Centro de control, reinicie o proceso NETCONF: sudo systemctl restart netrounds-confd
Notas sobre aplicacións de axente de proba e aparellos de axente de proba
Aplicacións de axentes de proba en ConfD
Entre os axentes de proba, a aplicación de axente de proba (máis recente) funciona de forma un pouco diferente á aplicación de axente de proba (máis antiga).
As aplicacións do axente de proba non admiten actualmente a configuración da interface. Polo tanto, o esquema YANG permite especificar unha configuración de interface baleira para tales axentes de proba. Vexa "esta pasaxe" na páxina 23 para ver un exemploample.
Ao sincronizar a base de datos ConfD co Centro de control mediante o comando sync-from-ncc, quere que a configuración da interface permaneza baleira e non se sobrescriba co que se atopa no Centro de control. Polo tanto, cómpre usar unha marca especial –without_interface_config con ese comando cando traballes con Aplicacións de axente de proba.
Configuración da interface baleira para o dispositivo de axente de proba
Como se indicou anteriormente, a aplicación de axente de proba non admite a configuración de interfaces e, polo tanto, é posible omitir interfaces no esquema YANG.
Pero tamén hai casos de uso nos que pode querer omitir a configuración da interface dun dispositivo de axente de proba. Un exampIsto podería ser un escenario de orquestración no que está a crear un axente de proba usando cloud-init e quere que se use a configuración da interface a partir de aí, en lugar de deixar que ConfD o sobrescriba cando o axente de proba se pon en liña.
Cambios do esquema YANG en relación ás interfaces non definidas
Dado que agora se permite unha configuración de interface baleira (a partir da versión 2.34.0), é posible especificar calquera nome de interface como entrada para unha tarefa executada como parte dunha proba ou monitor.
Isto é necesario para poder utilizar unha aplicación de axente de proba, xa que para estes non se definen nomes de interface en ConfD. Teña en conta, non obstante, que isto tamén significa que pode ter problemas se por accidente configura unha proba ou monitor para utilizar unha interface inexistente. Entón, teña en conta isto.
Limitacións ao rexistrar un axente de proba creado en ConfD
Ao crear un axente de proba a través da API REST ou NETCONF/YANG, non podemos saber de antemán de que tipo é: Aplicación de axente de proba ou aplicación de axente de proba. Isto queda claro só despois de rexistrarse o axente de proba.
Unha vez que o axente de proba foi rexistrado e converteuse nun destes tipos concretos, non podes rexistralo de novo como un tipo diferente de axente de proba. Isto significa que non podes rexistralo primeiro como unha aplicación de axente de proba e despois rexistrala de novo como unha aplicación de axente de proba ou viceversa. Se precisa un axente de proba dun tipo diferente, terá que crear un novo axente de proba.
Apéndice: Estrutura en árbore do modelo YANG completo
Neste apéndice, a sección "Lenda" na páxina 81 explica a sintaxe da estrutura da árbore do modelo YANG xerada co comando pyang -f tree.
A sección "Estrutura da árbore do modelo YANG" na páxina 82 dá a saída dese comando aplicado a netrounds-ncc.yang. Partes desta saída reprodúcense noutro lugar do documento.
Lenda
Estrutura da árbore modelo YANG
Juniper Networks, o logotipo de Juniper Networks, Juniper e Junos son marcas rexistradas de Juniper Networks, Inc. nos Estados Unidos e noutros países. Todas as outras marcas comerciais, marcas de servizo, marcas rexistradas ou marcas de servizo rexistradas son propiedade dos seus respectivos propietarios. Juniper Networks non asume ningunha responsabilidade por calquera imprecisión neste documento. Juniper Networks resérvase o dereito de cambiar, modificar, transferir ou revisar esta publicación sen previo aviso. Copyright © 2023 Juniper Networks, Inc. Todos os dereitos reservados.
Documentos/Recursos
 |
Juniper NETWORKS NETCONF & YANG API Software [pdfGuía do usuario NETCONF YANG API Software, YANG API Software, API Software, Software |