Algunes rutes L2VPN desapareixen després d’afegir reflectors de ruta

Les sessions es mantenen, l’IGP és estable i, tot i així, un grapat de rutes L2VPN no apareixen mai a dues de les quatre vores del proveïdor. Aquest patró pertany a un problema de reflexió i no a un de transport, perquè una sessió trencada falla del tot mentre que una frontera de reflexió reutilitzada falla selectivament. L’anell físic no hi té res a veure; el graf lògic de distribució és on es van aturar aquestes rutes. Trobar aquest punt no requereix reconstruir el pla de control.

La pèrdua és selectiva, cosa que estreny la cerca

Quatre vores de proveïdor en un anell físic necessiten sis sessions lògiques per a una malla completa, ja que cada encaminador s’aparell amb els altres tres. Aquestes sessions viatgen pel transport encaminat, així que el cablejat no diu res sobre quantes adjacències existeixen ni quina d’elles reflecteix. Quan dues vores perden un conjunt concret de prefixos mentre la resta convergeix, el cable no és el sospitós.

La pèrdua selectiva apunta a la prevenció de bucles, a la política o a la direcció de la relació, on algunes rutes creuen una frontera i altres es descarten pel camí. La pèrdua total apunta a la sessió o a la família d’adreces. Decidir quina de les dues esteu mirant és el primer pas útil, i només cal una ordre.

Què canvia realment la reflexió

La reflexió de rutes relaxa la regla que un parlant iBGP no pot reanunciar una ruta apresa d’un altre parlant iBGP. RFC 4456 expressa l’excepció a través de la relació entre el parlant i l’origen de la ruta, i la direcció d’aquesta relació importa més del que suggereixen la majoria de resums. Una ruta apresa d’un client es pot reflectir a altres clients i a no-clients, mentre que una ruta apresa d’un no-client només es pot reflectir a clients. Llegiu l’asimetria dues vegades, perquè explica com afegir una relació de client pot amagar un error de disseny: obre un camí que la topologia mai no havia previst.

L’atribut CLUSTER_LIST registra l’historial de reflexió, i un reflector que troba el seu propi identificador de clúster en aquesta llista ha d’ignorar l’anunci. Això és la prevenció de bucles, i també és el mecanisme que esborra rutes quan els identificadors es reutilitzen per accident. ORIGINATOR_ID hi té un paper relacionat en nomenar l’encaminador que va anunciar la ruta per primera vegada.

Els identificadors de clúster reutilitzats són la manera com desapareixen les rutes

Una xarxa petita convida a una drecera: doneu a cada encaminador un identificador de clúster igual al seu loopback, afegiu-hi més tard un altre reflector i reutilitzeu un loopback existent perquè el teniu a mà. Si aquest identificador apareix ara en dues etapes de reflexió independents, la segona etapa veu el seu propi ID a CLUSTER_LIST i descarta la ruta. No es registra cap error, perquè descartar és la resposta correcta a un bucle.

Els reflectors redundants que serveixen un sol clúster són l’excepció legítima: comparteixen un ID a propòsit perquè qualsevol dels dos pugui servir els mateixos clients. L’identificador ha de coincidir amb el disseny de reflexió i no distingir noms de xassís.

Dibuixeu el graf previst abans de tocar cap configuració: qui origina el prefix, quina relació de client permet la primera reflexió, quin reflector el porta a l’etapa següent i on se situa l’últim client. Cada salt d’aquest graf és un lloc on un identificador reutilitzat, una relació de client absent o un filtre de política poden aturar la ruta. Amb el graf dibuixat, una ruta absent té una ubicació en lloc d’un misteri.

Resistiu la temptació de fer de cada veí un client

La reparació ràpida d’una ruta absent és fer de cada veí un client de cada reflector. La propagació torna i el disseny deixa de dir-vos res: multiplica les rutes que cada parlant porta mentre amaga quina relació havia de fer la feina.

Una xarxa petita normalment necessita una de dues formes. Una malla iBGP completa són sis sessions per a quatre encaminadors sense cap reflexió, i una parella designada de reflectors que serveix les vores restants és l’altra. Totes dues són més fàcils de raonar que una malla parcial en què cada encaminador reflecteix una mica. Trieu la forma per escala i comportament davant d’errors, no pel diagrama de cablejat.

Comproveu la família d’adreces abans de culpar la reflexió

Una sessió TCP al port 179 demostra que els dos parlants es poden parlar, i res sobre si la família d’adreces de VPN ha intercanviat una sola ruta. Establiu l’estat de la sessió, després la família i després el prefix individual.

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

Aquestes tres sortides separen un problema d’adjacència d’un problema d’intercanvi i d’un problema de prefix absent. Si la família no mostra cap prefix, inspeccioneu l’estat d’activació i la política d’exportació del veí abans de mirar la reflexió. Si els prefixos apareixen en una vora però no en una altra, compareu la llista de clústers i l’originador al costat receptor i després recorreu el graf de la secció anterior.

Manteniu l’accessibilitat del següent salt i l’estat d’enviament fora d’aquesta comprovació. Una ruta reflectida amb un següent salt inaccessible és present i inutilitzable, cosa que sembla un error de reflexió fins que mireu la columna del següent salt. Resoleu el següent salt, confirmeu l’entrada d’enviament i només llavors decidiu si el graf de distribució necessita un altre reflector.