APRENDER. PRATICAR. EVOLUIR.O endereço não identifica sozinho o caminho
Um pedido de conectividade deve indicar origem, destino, protocolo, porta e contexto de routing. Duas aplicações podem usar o mesmo endereço privado em VRFs diferentes sem representar o mesmo destino. Começa pela interface de entrada e pela VRF que lhe está associada; consulta depois as rotas desse contexto, a resolução do next hop e o retorno para a origem efetivamente usada. Num incidente, uma captura que omite a VRF pode parecer contraditória com o relatório de outra equipa. Preserva esse contexto nos logs, nos nomes dos monitores e na evidência da mudança, incluindo a família IPv4 ou IPv6.
Caso: serviço partilhado sem fundir redes
Num exemplo fictício de APS, FUNDS precisa de enviar logs para um coletor em SERVICES. Define o prefixo do coletor, a origem usada pelos agentes, o transporte, a porta, o caminho de retorno e o responsável pelo acesso. Importar uma rota cria uma possibilidade de encaminhamento; não autentica o agente nem valida que a mensagem chegou ao coletor. Se ambas as VRFs já usam o mesmo prefixo para destinos distintos, a partilha precisa de resolver essa ambiguidade no desenho. Uma importação adicional não escolhe magicamente o destinatário pretendido. Valida também que outras redes e serviços continuam inacessíveis segundo o contrato.
RD e RT respondem a perguntas diferentes
Quando o desenho usa distribuição BGP VPN-IPv4, o route distinguisher permite distinguir prefixos IPv4 iguais na representação VPN. O route target participa na política que torna uma rota elegível para importação numa VRF. Não concluas que dois RDs iguais ou diferentes definem por si a comunicação entre serviços. Mesmo um RT compatível não demonstra instalação final da rota, resolução do next hop, resposta do destino ou autorização da aplicação. Esta distinção ajuda a discutir propostas de fornecedores; o laboratório seguinte não executa BGP, MPLS nem importação por RT. A ausência desses mecanismos no ensaio deve acompanhar qualquer relatório de prontidão.
Ler a configuração antes de mudar a interface
O excerto de IOS XE abaixo é original e destina-se a leitura, sem execução Cisco neste ambiente. Mostra a criação do contexto IPv4 FUNDS, a associação de uma interface e a respetiva consulta. Não configura um serviço partilhado nem distribui rotas por BGP. Numa mudança real, regista os endereços e as dependências antes de associar a interface a outra VRF; confirma o estado final na versão e plataforma em uso. Se depois da alteração faltarem endereço ou rota conectada, investiga esses factos antes de mexer em preferências de rotas remotas. Mantém acesso de recuperação que não dependa exclusivamente da interface alterada.
Aceitação em camadas e entrega ao RUN
A equipa de produção precisa de saber onde observar falhas, não apenas que comando foi aplicado. O registo de aceitação deve relacionar interface, VRF, prefixo, next hop, origem de teste e resultado. Um ping do router mede um caminho com uma origem concreta e não equivale a uma transação do cliente. Testa o serviço esperado, o retorno e pelo menos um acesso que deve continuar bloqueado. Define responsável, limiar de paragem e reversão. Em ambientes internacionais, usa identificadores de VRF consistentes nos tickets para evitar que duas equipas consultem tabelas diferentes e declarem resultados incompatíveis.
! Original reading exercise only; not executed on Cisco IOS XE.
vrf definition FUNDS
rd 65000:10
address-family ipv4
exit-address-family
!
interface GigabitEthernet1
vrf forwarding FUNDS
ip address 192.0.2.1 255.255.255.0
! Operational inspection, not configuration commands:
show vrf definition FUNDS
show ip route vrf FUNDS
show ip arp vrf FUNDS
A rota do coletor existe em SERVICES; isso não demonstra que os agentes em FUNDS a podem usar.
Armadilhas comuns
Consultar a tabela global; omitir a origem; confundir RD com política de importação; aceitar uma rota como prova de entrega de logs.
Tópicos relacionados: VRF: laboratório de isolamento e recuperação · Virtualização, VRFs e overlays
Identifica o contexto e valida encaminhamento, retorno e serviço separadamente.
Referência: Configuring VRF-lite · 350-401 ENCOR v1.2, effective 2026-03-19; core component of CCNP Enterprise