APRENDER. PRATICAR. EVOLUIR.Descobrir antes de alterar
Uma sessão NETCONF começa por anunciar capacidades. A presença de NETCONF não garante candidate, confirmed-commit ou rollback-on-error. Num exercício fictício de APS, o script foi escrito para candidate, mas o equipamento de contingência anuncia um conjunto diferente. A decisão correta começa por guardar as capacidades e a versão e comparar o plano com o alvo. Mudar automaticamente para running altera o risco: uma edição pode passar a afetar a configuração ativa de imediato. Define antecipadamente o comportamento quando falta uma capacidade. Identifica também os modelos e namespaces usados pelo payload; XML bem formado não demonstra que o equipamento reconhece os dados. A equivalência entre dois modelos de equipamento exige evidência própria.
Candidate tem um âmbito
Candidate permite preparar configuração antes de a aplicar a running. Não o trates como uma cópia privada só por teres aberto uma sessão nova. Sem evidência de isolamento, considera que outras sessões podem editar o mesmo candidate. Obtém o lock apropriado e inspeciona o conteúdo antes de iniciar o teu trabalho. Um lock adquirido depois não elimina alterações pendentes de outro operador. Num caso de mudança de descrição, confirmar um candidate que já contém uma alteração de routing pode publicar mais do que o pedido aprovado. Coordena a propriedade dessas alterações. discard-changes repõe candidate a partir de running; não é uma operação que identifica e remove exclusivamente os teus campos.
Parar e repor são decisões diferentes
Num edit-config, stop-on-error manda parar ao encontrar um erro; não constitui uma promessa de repor tudo o que já foi alterado. Quando o servidor suporta rollback-on-error, essa opção solicita reposição ao estado no início daquela operação. O âmbito é o pedido, não toda a pipeline nem todos os equipamentos. Se três pedidos anteriores terminaram com sucesso, o quarto falhar não implica desfazer automaticamente os três. Regista a sequência, os identificadores e o resultado de cada passo, e prevê compensação quando necessário. Em datastores partilhados, o lock ajuda a evitar que a reposição interfira com mudanças de outros. Analisa ainda a resposta de erro e o estado observado; uma tentativa de rollback também pode falhar.
Confirmed commit precisa de uma prova
Se a capacidade estiver disponível, um confirmed commit permite aplicar temporariamente uma mudança e exigir confirmação antes do prazo. Escolhe o prazo a partir do tempo necessário para validar o serviço e recuperar acesso. A confirmação não deve ser enviada apenas porque o RPC inicial devolveu sucesso. Num exercício de alteração da gestão, abre uma nova ligação a partir da rede autorizada, observa o estado pretendido e testa também as recusas previstas. Distingue sessão antiga de novo acesso. A persistência entre sessões depende dos parâmetros e capacidades; perder a sessão não tem um resultado universal. A reposição de configuração também não recupera automaticamente sessões de aplicação interrompidas durante a experiência.
Aceitar por equipamento e por serviço
Um commit num router não cria uma transação distribuída com o router vizinho. Para uma mudança em dois lados, define a ordem permitida, os estados intermédios toleráveis e o que fazer se apenas um lado aceitar. Guarda evidência por alvo e por serviço, incluindo leitura da configuração e observação operacional. Uma interface administrativamente ativa pode continuar sem ligação física; o modelo de interfaces distingue enabled de oper-status. O handover deve indicar o que foi realmente testado, as dependências e as condições de reversão. Nesta aula, os fluxos NETCONF são exercícios de análise baseados no protocolo. O laboratório associado à próxima aula exercita HTTP local e não demonstra execução de NETCONF ou recuperação num equipamento Cisco.
# Reading exercise only; capability and ownership checks precede edits.
# 1. Inspect hello capabilities and models.
# 2. Lock the relevant datastore; inspect existing pending changes.
# 3. Edit candidate, validate, inspect the approved diff.
# 4. Use confirmed commit only if supported and recovery is planned.
# 5. Verify NEW management access and operational service checks.
# 6. Confirm within the deadline only after acceptance; release locks.
# An RPC result does not establish application health.
Uma mudança de descrição encontra uma rota pendente no candidate. O lock não torna essa rota parte da aprovação; a equipa tem de resolver a propriedade antes do commit.
Armadilhas comuns
Candidate como privado; lock como limpeza; stop-on-error como rollback; commit como teste funcional; dois dispositivos como uma transação única.
Tópicos relacionados: RESTCONF e concorrência · Acesso e recuperação
Define o âmbito de cada garantia e confirma o resultado onde o serviço é consumido.
Referência: NETCONF protocol · 350-401 ENCOR v1.2, effective 2026-03-19; core component of CCNP Enterprise