Algunhas rutas L2VPN desaparecen tras engadir reflectores de ruta

As sesións seguen activas, o IGP é estable e, aínda así, un feixe de rutas L2VPN nunca aparecen en dúas das catro arestas do provedor. Ese patrón pertence a un problema de reflexión e non a un de transporte, porque unha sesión rota falla por completo mentres que unha fronteira de reflexión reutilizada falla de forma selectiva. O anel físico non ten nada que ver; o grafo lóxico de distribución é onde se detiveron esas rutas. Atopar ese punto non esixe reconstruír o plano de control.

A perda é selectiva, o que estreita a busca

Catro arestas de provedor nun anel físico necesitan seis sesións lóxicas para unha malla completa, xa que cada router se emparexa cos outros tres. Esas sesións viaxan sobre o transporte enrutado, así que o cableado non di nada sobre cantas adxacencias existen nin cal delas reflicte. Cando dúas arestas perden un conxunto concreto de prefixos mentres todo o demais converge, o cable non é o sospeitoso.

A perda selectiva apunta á prevención de bucles, á política ou á dirección da relación, onde algunhas rutas cruzan unha fronteira e outras descártanse polo camiño. A perda total apunta á sesión ou á familia de enderezos. Decidir cal das dúas está a mirar é o primeiro paso útil, e custa un só comando.

Que cambia realmente a reflexión

A reflexión de rutas relaxa a regra de que un falante iBGP non pode reanunciar unha ruta aprendida doutro falante iBGP. RFC 4456 expresa a excepción mediante a relación entre o falante e a orixe da ruta, e a dirección desa relación importa máis do que suxiren a maioría dos resumos. Unha ruta aprendida dun cliente pode reflectirse a outros clientes e a non clientes, mentres que unha ruta aprendida dun non cliente só pode reflectirse a clientes. Lea a asimetría dúas veces, porque explica como engadir unha relación de cliente pode ocultar un erro de deseño: abre un camiño que a topoloxía nunca pretendeu.

O atributo CLUSTER_LIST rexistra o historial de reflexión, e un reflector que atopa o seu propio identificador de clúster nesa lista debe ignorar o anuncio. Iso é a prevención de bucles, e tamén é o mecanismo que borra rutas cando os identificadores se reutilizan por accidente. ORIGINATOR_ID desempeña un papel relacionado ao nomear o router que anunciou a ruta por primeira vez.

Os identificadores de clúster reutilizados son a forma en que desaparecen as rutas

Unha rede pequena invita a un atallo: dea a cada router un identificador de clúster igual ao seu loopback, engada despois outro reflector e reutilice un loopback existente porque o ten á man. Se ese identificador aparece agora en dúas etapas de reflexión independentes, a segunda etapa ve o seu propio ID en CLUSTER_LIST e descarta a ruta. Nada rexistra un erro, porque descartar é a resposta correcta a un bucle.

Os reflectores redundantes que serven un só clúster son a excepción lexítima: comparten un ID a propósito para que calquera dos dous poida servir os mesmos clientes. O identificador debe coincidir co deseño de reflexión e non distinguir nomes de chasis.

Debuxe o grafo previsto antes de tocar calquera configuración: quen orixina o prefixo, que relación de cliente permite a primeira reflexión, que reflector o leva á seguinte etapa e onde se sitúa o último cliente. Cada salto dese grafo é un lugar onde un identificador reutilizado, unha relación de cliente ausente ou un filtro de política poden deter a ruta. Co grafo debuxado, unha ruta ausente ten unha localización en lugar dun misterio.

Resista a tentación de facer cliente a cada veciño

A reparación rápida dunha ruta ausente é facer que cada veciño sexa cliente de cada reflector. A propagación volve e o deseño deixa de dicirlle nada: multiplica as rutas que carga cada falante mentres oculta que relación debía facer o traballo.

Unha rede pequena adoita necesitar unha de dúas formas. Unha malla iBGP completa son seis sesións para catro routers sen reflexión algunha, e un par designado de reflectores que serve as arestas restantes é a outra. Ambas son máis fáciles de razoar que unha malla parcial na que cada router reflicte un pouco. Escolla a forma por escala e comportamento ante fallos, non polo diagrama de cableado.

Comprobe a familia de enderezos antes de culpar a reflexión

Unha sesión TCP no porto 179 demostra que os dous falantes poden falar, e nada sobre se a familia de enderezos VPN intercambiou unha soa ruta. Estableza o estado da sesión, despois a familia e despois o prefixo individual.

vtysh -c "show bgp summary"
vtysh -c "show bgp l2vpn evpn summary"
vtysh -c "show bgp l2vpn evpn"

Esas tres saídas separan un problema de adxacencia dun problema de intercambio e dun problema de prefixo ausente. Se a familia non mostra ningún prefixo, inspeccione o estado de activación e a política de exportación do veciño antes de mirar a reflexión. Se os prefixos aparecen nunha aresta pero non noutra, compare a lista de clústeres e o originador no lado receptor e logo percorra o grafo da sección anterior.

Manteña a accesibilidade do seguinte salto e o estado de reenvío fóra desa comprobación. Unha ruta reflectida con un seguinte salto inaccesible está presente e é inservible, o que parece un fallo de reflexión ata que mira a columna do seguinte salto. Resolva o seguinte salto, confirme a entrada de reenvío e só entón decida se o grafo de distribución necesita outro reflector.