Push, no poll
La única fuente que viene a usted, y las dos cosas que eso cambia respecto a lo que le está permitido creer
Michel Wijnberg
Toda fuente de esta serie hasta ahora es algo que Osprey va y pregunta. Un grabador GRE se une a un área y pide una base de datos. Un recorrido SNMP le pide una tabla a un dispositivo. Preguntar, esperar, recibir, repetir.
BMP es la única que llega por su cuenta. El router abre una sesión TCP hacia la estación de monitorización y empieza a hablar, y sigue hablando mientras tenga algo que decir (RFC 7854). Nadie hace polling de nada.
Eso suena estrictamente mejor, y en una dimensión lo es. En otras dos cambia lo que usted tiene derecho a concluir, y ambas son más interesantes que la velocidad.
Qué compra el llegar por su cuenta
El polling tiene un intervalo de muestreo, y un intervalo de muestreo tiene todas las propiedades de un intervalo de muestreo. Cualquier cosa que ocurra y se revierta dentro de un ciclo no ha ocurrido, en lo que respecta a sus datos. Una ruta que hace flapping dos veces entre dos recorridos parece una ruta que nunca se movió.
Un flujo empujado no tiene ciclo. Una retirada llega porque hubo una retirada, y la marca de tiempo que lleva es la del router, no la del poller.
Para BGP eso importa más que para casi cualquier otra cosa, porque BGP cambia muchísimo más que la topología. Un recorrido de cinco minutos de una tabla completa es a la vez enormemente caro y, para todo lo efímero, ciego. El modelo push es el único en el que la pregunta “¿cuándo cambió este prefijo?” tiene una respuesta en la que valga la pena confiar.
Coste uno: el silencio deja de significar nada
Ahora la parte que el polling recibe gratis.
Un poller que pregunta y no recibe nada sabe exactamente qué pasó: preguntó y no recibió nada. La ausencia es en sí misma una observación, con marca de tiempo, y se puede reintentar.
Un oyente que no oye nada no tiene ese lujo. El silencio es el mismo en el cable tanto si la red está tranquila como si la sesión ha desaparecido, y el segundo caso es indistinguible del primero hasta que otra cosa se lo diga.
El peligro concreto merece nombrarse, porque invierte la métrica a la que uno recurriría. Si trata una sesión caída como ausencia de cambio, entonces el peer del que ha dejado de oír se convierte en el peer más estable de su informe. La línea más silenciosa de la pantalla es la que ha perdido. Toda clasificación que ordene por churn pone su punto ciego arriba del todo, etiquetado como su relación más sana.
El artículo doce cubre qué hace Osprey al respecto, que es registrar la caída de sesión como un hueco de monitorización en lugar de como una retirada masiva, y no lo voy a repetir aquí. El punto para esta serie es más estrecho: el push traslada la carga de interpretar el silencio del protocolo a usted. El modelo de polling le daba esa respuesta y usted no tenía que pensarlo.
Coste dos: está leyendo la conversación de otro
El segundo coste es más sutil y produce bugs de parseo reales.
BMP no le da una sesión BGP. Le da una copia de los mensajes de la sesión de otro, envueltos y reenviados. Usted no estuvo presente en la negociación, y los mensajes BGP no son autodescriptivos: cómo se decodifica un UPDATE depende de lo que los dos peers acordaron en su OPEN.
El enfoque obvio es reconstruir el contexto. Peer Up lleva los dos mensajes OPEN, así que puede leer lo que se negoció y recordarlo durante la sesión. Osprey hace eso.
Y entonces la cabecera por peer de cada mensaje posterior lleva un flag A, que indica si la PDU encapsulada usa el formato heredado de AS_PATH de dos bytes (RFC 7854 §4.2). Es por mensaje, así que el parser decodifica ese mensaje según él, en lugar de asumir el formato a partir del contexto del Peer Up.
Esos dos pueden discrepar. Cuando lo hacen, Osprey decodifica según el flag y registra la discrepancia en vez de resolverla en silencio, y el razonamiento merece enunciarse porque generaliza: la capacidad registra lo que dos routers acordaron hacer, y el flag describe lo que este exportador hizo con este mensaje. Cuando la evidencia sobre un acuerdo y la evidencia sobre los bytes que tiene en la mano entran en conflicto, los bytes en la mano son los que se están parseando.
Hay una sutileza equivalente con Add-Path, y tiene la misma forma. Que el NLRI encapsulado lleve identificadores de camino depende de una negociación que es direccional, y qué dirección se aplica depende de qué RIB se está monitorizando: la Adj-RIB-In por defecto, o la Adj-RIB-Out que añadió el RFC 8671 y que se señaliza con otro flag de esa misma cabecera por peer. Así que el parser lee ese flag primero y elige a partir de él qué negociación creer. El mismo campo, dos lecturas, seleccionadas por un bit que usted no consultaría si fuera parte de la sesión.
Nada de esto surge cuando hace polling a un dispositivo. Le está preguntando a un dispositivo sobre sí mismo, en un protocolo del que usted es parte de primera clase. BMP le entrega la visión propia del router y le quita el contexto en que fue negociada, y cada campo que reconstruye ese contexto es portante.
Los dos métodos de adquisición caen en una sola tabla, y la diferencia se ve en dos columnas. Las filas BMP se vieron por última vez hace un día, y eso no es un fallo: nada cambió en esas sesiones, y una fuente que empuja calla cuando no cambia nada. Las filas SNMP dicen justo ahora porque alguien fue y preguntó. La misma afirmación, dos razones muy distintas para creerla, y solo en una de ellas el silencio es información.
El informe que nunca llega si no lo pide
Una última cosa, y es la más pequeña y la más irritante.
BMP define los Statistics Reports: contadores periódicos por peer, incluidos los de rechazo y de tratar-como-retirada que le dicen qué está descartando la política de un peer. Datos excelentes. Justo lo que quiere para un cuadro de mando.
No llegan.
No por un bug de parseo, y no porque el exportador esté roto. IOS sencillamente no envía
Statistics Reports salvo que se le haya indicado un periodo de reporte, y no hay valor por
defecto. Sin stats-reporting-period bajo la configuración del servidor BMP, ese tipo de
mensaje no aparece nunca en el cable, y todos los campos de estadísticas por peer se quedan
vacíos para siempre sin ningún error en ninguna parte.
El laboratorio funcionó así durante un tiempo, y la lectura honesta de las columnas vacías no era “este peer no rechaza nada”. Era “nadie le ha dicho nunca a este router que lo diga”. El arreglo fue una línea de configuración en seis routers, escrita a la startup-config para que un reload no deshaga calladamente la medición.
Es un pequeño detalle operativo con una forma general: una fuente push solo puede decirle lo que fue configurada para enviar. Con polling usted controla cuándo se hace la pregunta. Con push usted observa solo lo que el exportador fue configurado para emitir, y un mensaje no enviado es indistinguible de uno que nunca se generó.
La idea
El push es mejor y no es gratis.
Usted gana la única línea temporal en la que vale la pena confiar para algo que cambia tan rápido como BGP, y renuncia a las dos cosas sobre las que el polling nunca le hizo pensar: que el silencio solía ser una observación, y que usted solía ser parte de la conversación que estaba leyendo.
Ambas aparecen en este código como piezas de cuidado pequeñas y concretas. Una caída de sesión registrada como hueco. Un ancho de AS_PATH tomado del flag en vez de de la capacidad. Una columna de estadísticas que se queda vacía y sabe por qué. Ninguna es ingeniosa. Todas son la misma admisión, que es que un mensaje que llega por su cuenta le dice menos sobre su propia ausencia que una pregunta que usted mismo hizo.
Con esto se cierra esta serie. El hilo conductor, si es que hay uno, es que toda respuesta de este producto vale exactamente lo que valga la cuenta que pueda dar de cómo se obtuvo.