Pode ver unha sesión subir, unha ruta aparecer e aínda así estar lendo o servizo equivocado. O par de números ao comezo de cada anuncio, o identificador de familia de enderezos e o identificador de familia de enderezos seguinte, decide que analizador le a carga e que táboa garda o resultado. Equivoque o par e a política de importación, a coincidencia do obxectivo de ruta e a busca do seguinte salto execútanse todas contra unha estrutura que ninguén anunciou. O percorrido de abaixo comeza nese par e remata no resultado do reenvío.

Dous números deciden a que táboa pertence a ruta

O par aparece dúas veces: dentro da capacidade multiprotocolo, onde un falante anuncia unha familia, e diante de cada NLRI que esa familia transporta. Iso faino unha propiedade da ruta e non un axuste da caixa de orixe. Os fabricantes imprímeno como un nome do tipo Address family VPNv4 Unicast, e a redacción cambia entre versións mentres os números quedan no seu sitio.

Where you meet itFamily pairBoundary of what it proves
VPNv4 unicast capability on a neighbour1 / 128the peer will signal labelled VPN-IPv4, nothing about import
VPNv6 unicast capability on a neighbour2 / 128the peer will signal VPN-IPv6, silent about the transport below
VPLS NLRI with a VE ID and a label base25 / 65a pseudowire is signalled, not that a bridge learned a MAC
EVPN MAC/IP advertisement route25 / 70a binding is advertised, not that the host answers

Catro codificacións cobren case todos os casos empresariais: 1 con 128 para VPN-IPv4 etiquetada con MPLS, 2 con 128 para o equivalente IPv6, 25 con 65 para VPLS sinalizado con BGP e 25 con 70 para EVPN. O primeiro erro é supoñer que todo servizo Layer 2 vive detrás de 25 con 65, o que oculta EVPN. O segundo é tratar as dúas familias IP como unha soa familia cun enderezo máis longo, cando se negocian por separado e poden aceptarse en pares distintos. Un terceiro aparece cando se copia un modelo dunha versión que só coñece unha delas. Unha consulta ao rexistro resolve as tres máis rápido que unha conxectura baseada no nome do servizo.

Trate as catro filas como exemplos do rexistro IANA, non como o rexistro mesmo. Cando un número non coincida con nada que recoñeza, búsqueo antes de construír unha política ao seu redor.

AFI 25 transporta dous formatos NLRI sen relación

As dúas familias Layer 2 sentan baixo AFI 25, e o parecido remata aí. O NLRI de VPLS en RFC 4761 section 3.2.2 transporta unha lonxitude, un distinguidor de ruta, un VE ID, un desprazamento de bloque VE, un tamaño de bloque VE e unha base de etiquetas, que xuntos nomean un extremo de pseudowire e a súa etiqueta. EVPN conserva AFI 25 e pasa a SAFI 70, onde a carga é un tipo de ruta: descubrimento automático de Ethernet, anuncio MAC/IP, multicast inclusivo, segmento Ethernet, prefixo IP. Por iso o mesmo desprazamento de byte significa cousas distintas nas dúas familias. Un analizador escrito para unha le a outra sen queixarse e produce tolerías. O par é o único aviso de que a interpretación é incorrecta.

Un campo que nunha familia significa desprazamento de bloque VE non ten contrapartida na outra, e a ruta de anuncio MAC/IP só existe en EVPN. Citar un atributo como se se aplicase a ambas é como se estraga unha revisión de captura.

Cando alguén lle entregue unha captura ou unha táboa de provedor, pregunte a que familia pertence o atributo. Despois confirme que a implementación receptora admite esa familia, non o nome do servizo da folla de datos. Dúas plataformas poden reclamar ambas soporte de VPLS mentres implementan familias de sinalización distintas. O par sepáraas; a etiqueta do produto non.

A familia de enderezos da propia sesión é unha pregunta aparte

VPN-IPv6 anúnciase habitualmente por unha sesión cuxa conexión TCP vai sobre IPv4, e iso é deseño admitido, non un fallo. Por iso ler só o resumo da sesión non di nada sobre que familias VPN intercambian os pares.

Familia NLRI, familia de transporte e familia de reenvío son tres decisións independentes. Un encamiñador pode falar IPv4 co seu par, aceptar alcance de VPN-IPv6 e instalar unha ruta cuxo seguinte salto é un enderezo IPv6 alcanzable por un camiño que vostede non pretendía. Cada capa precisa a súa propia confirmación. Os sitios que informan de destinos IPv6 inalcanzables mentres os anuncios parecen correctos adoitan perder a resolución do seguinte salto, non a negociación de familias.

Probe a familia de enderezos da sesión por separado, despois as familias que transporta e despois o que o núcleo pode reenviar. Manter as tres separadas evita o diagnóstico erróneo habitual no que un anuncio correcto se le como proba de que IPv6 funciona de extremo a extremo. Só proba que un par lle dixo a outro algo sobre un prefixo.

Negociado, recibido, importado, instalado

Para unha ruta esperada, catro estados deben cumprirse en orde, e cada un é observable. A familia debe estar negociada con ese par, a ruta debe chegar, un obxectivo de ruta debe importala ao contexto previsto e o seguinte salto debe resolverse para que a ruta se instale. Saltarse o primeiro estado fai irrespondibles os outros tres, porque unha familia non negociada non produce rutas que inspeccionar. En plataformas de estilo Cisco os resumos de familia e as capacidades por par son comandos separados.

show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address family

A negociación aparece no intercambio de capacidades impreso por par, e unha sesión establecida sen ningunha familia listada non transporta nada do que vostede pediu. A importación decídema os obxectivos de ruta transportados como comunidades estendidas, así que un par correcto cun obxectivo mal escrito deixa a táboa baleira. A instalación depende despois de que o seguinte salto se resolva no contexto receptor, o que pode fallar mentres cada anuncio parece perfecto.

Confirme o plano de datos ao final, porque unha ruta na táboa é unha afirmación, non unha entrega. Os mesmos catro estados aplícanse a cada familia; só cambian os comandos e os nomes de táboa.

O que un par de familias nunca demostra

Ler ben o par dille como interpretar a información de encamiñamento que segue, e esa é toda a afirmación. Non di nada sobre alcance, nada sobre política e nada sobre a saúde do plano de datos. Confundir as dúas cousas produce afirmacións seguras sobre unha rede que ninguén verificou. Un desaxuste de obxectivo de ruta e un seguinte salto roto parecen idénticos só mirando o par. O par é unha instrución de lectura, nunca un veredicto.

Cando escale, poña o par, o obxectivo de ruta e o seguinte salto resolvido na mesma nota. O seguinte enxeñeiro ten entón tres cousas independentes que probar en lugar dun nome de servizo que reinterpretar. Se falta a negociación vén o de inmediato, un obxectivo errado deixa a importación visiblemente ausente e un seguinte salto sen resolver deixa a ruta presente pero inutilizable.

Artigos relacionados