Empurre, não pergunte
A única fonte que vem até você, e as duas coisas que isso muda no que você tem permissão de acreditar
Michel Wijnberg
Toda fonte desta série até aqui é algo que o Osprey vai lá e pergunta. Um gravador GRE entra numa área e pede uma base de dados. Uma varredura SNMP pede uma tabela a um equipamento. Perguntar, esperar, receber, repetir.
BMP é a única que chega por conta própria. O roteador abre uma sessão TCP para a estação de monitoramento e começa a falar, e continua falando enquanto tiver algo a dizer (RFC 7854). Ninguém faz polling de nada.
Isso soa estritamente melhor, e numa dimensão é. Em outras duas, muda o que você tem direito de concluir, e essas duas são mais interessantes que a velocidade.
O que chegar por conta própria compra
Polling tem um intervalo de amostragem, e um intervalo de amostragem tem todas as propriedades de um intervalo de amostragem. Qualquer coisa que aconteça e se reverta dentro de um ciclo não aconteceu, no que diz respeito aos seus dados. Uma rota que faz flapping duas vezes entre duas varreduras parece uma rota que nunca se moveu.
Um fluxo empurrado não tem ciclo. Uma retirada chega porque houve uma retirada, e o carimbo de tempo nela é o do roteador, não o do poller.
Para BGP isso importa mais que para a maioria das coisas, porque BGP muda muito mais que a topologia. Uma varredura de cinco minutos de uma tabela cheia é ao mesmo tempo enormemente cara e, para qualquer coisa efêmera, cega. O modelo push é o único em que a pergunta “quando este prefixo mudou” tem uma resposta em que vale a pena confiar.
Custo um: o silêncio deixa de significar qualquer coisa
Agora a parte que o polling ganha de graça.
Um poller que pergunta e não recebe nada sabe precisamente o que aconteceu: ele perguntou e não recebeu nada. A ausência é ela mesma uma observação, com carimbo de tempo, e pode ser retentada.
Um ouvinte que não ouve nada não tem esse luxo. O silêncio é o mesmo no fio quer a rede esteja quieta, quer a sessão tenha sumido, e o segundo caso é indistinguível do primeiro até que outra coisa lhe diga o contrário.
O perigo específico merece ser nomeado, porque ele inverte a métrica que você buscaria. Se você trata uma sessão caída como ausência de mudança, então o peer de quem você parou de ouvir vira o peer mais estável do seu relatório. A linha mais silenciosa da tela é a que você perdeu. Todo ranking que ordena por churn põe o seu ponto cego no topo, rotulado como o seu relacionamento mais saudável.
O artigo doze cobre o que o Osprey faz a respeito, que é registrar uma queda de sessão como uma lacuna de monitoramento em vez de como uma retirada em massa, e não vou recontar aqui. O ponto para esta série é mais estreito: o push transfere o ônus de interpretar o silêncio do protocolo para você. O modelo de polling lhe entregava essa resposta e você não precisava pensar nisso.
Custo dois: você está lendo a conversa de outra pessoa
O segundo custo é mais sutil e produz bugs de parsing reais.
BMP não lhe dá uma sessão BGP. Dá uma cópia das mensagens da sessão de outra pessoa, embrulhadas e encaminhadas. Você não estava presente na negociação, e mensagens BGP não são autodescritivas: como você decodifica um UPDATE depende do que os dois peers combinaram no OPEN deles.
A abordagem óbvia é reconstruir o contexto. O Peer Up carrega as duas mensagens OPEN, então você pode ler o que foi negociado e guardar isso para a sessão. O Osprey faz isso.
E aí o cabeçalho por peer de cada mensagem seguinte carrega uma flag A, indicando se a PDU encapsulada usa o formato legado de AS_PATH de dois bytes (RFC 7854 §4.2). Ela é por mensagem, então o parser decodifica aquela mensagem conforme ela, em vez de assumir o formato a partir do contexto do Peer Up.
Esses dois podem discordar. Quando discordam, o Osprey decodifica pela flag e registra a discrepância em vez de resolvê-la em silêncio, e o raciocínio vale ser enunciado porque generaliza: a capacidade registra o que dois roteadores concordaram em fazer, e a flag descreve o que este exportador fez com esta mensagem. Onde a evidência sobre um acordo e a evidência sobre os bytes em mãos entram em conflito, os bytes em mãos são os que estão sendo interpretados.
Há uma sutileza correspondente sobre Add-Path, e ela tem o mesmo formato. Se o NLRI encapsulado carrega identificadores de caminho depende de uma negociação que é direcional, e qual direção se aplica depende de qual RIB está sendo monitorada: a Adj-RIB-In padrão, ou a Adj-RIB-Out que a RFC 8671 acrescentou e que é sinalizada por outra flag no mesmo cabeçalho por peer. Então o parser lê essa flag primeiro e escolhe a partir dela em qual negociação acreditar. Mesmo campo, duas leituras, selecionadas por um bit que você não consultaria se fosse parte da sessão.
Nada disso aparece quando você faz polling num equipamento. Você está perguntando a um equipamento sobre ele mesmo, num protocolo do qual você é parte de primeira classe. O BMP lhe entrega a visão própria do roteador e tira o contexto em que ela foi negociada, e todo campo que reconstrói esse contexto é estrutural.
Os dois métodos de aquisição caem numa só tabela, e a diferença vê-se em duas colunas. As linhas BMP foram vistas pela última vez há um dia, e isso não é uma falha: nada mudou naquelas sessões, e uma fonte que empurra cala-se quando nada muda. As linhas SNMP dizem agora mesmo porque alguém foi lá perguntar. A mesma afirmação, duas razões muito diferentes para acreditar nela, e só numa delas o silêncio é informação.
O relatório que nunca vem a menos que você peça
Uma última coisa, e é a menor e a mais irritante.
BMP define Statistics Reports: contadores periódicos por peer, incluindo os contadores de rejeição e de tratar-como-retirada que lhe dizem o que a política de um peer está descartando. Dados excelentes. Exatamente o que você quer para um painel.
Eles não chegam.
Não por causa de um bug de parser, e não porque o exportador esteja quebrado. O IOS
simplesmente não envia Statistics Reports a menos que tenha recebido um período de
reporte, e não há padrão. Sem stats-reporting-period sob a configuração do servidor BMP,
aquele tipo de mensagem nunca aparece no fio, e todo campo de estatística por peer fica
vazio para sempre sem erro algum em lugar nenhum.
O laboratório rodou assim por um tempo, e a leitura honesta das colunas vazias não era “este peer não rejeita nada”. Era “ninguém nunca mandou este roteador falar”. A correção foi uma linha de configuração em seis roteadores, escrita na startup-config para que um reload não desfizesse silenciosamente a medição.
É um pequeno detalhe operacional com um formato geral: uma fonte push só pode lhe dizer o que foi configurada para enviar. Com polling você controla quando a pergunta é feita. Com push você observa apenas o que o exportador foi configurado para emitir, e uma mensagem não enviada é indistinguível de uma que nunca foi gerada.
O ponto
Push é melhor e não é de graça.
Você ganha a única linha do tempo em que vale confiar para algo que muda tão rápido quanto BGP, e abre mão das duas coisas em que o polling nunca lhe fez pensar: que o silêncio já foi uma observação, e que você já foi parte da conversa que estava lendo.
As duas aparecem nesta base de código como pedaços pequenos e específicos de cuidado. Uma queda de sessão registrada como lacuna. Uma largura de AS_PATH tirada da flag em vez da capacidade. Uma coluna de estatística que fica vazia e sabe por quê. Nenhuma delas é esperta. São todas a mesma admissão, que é a de que uma mensagem que chega por conta própria lhe diz menos sobre a própria ausência do que uma pergunta que você mesmo fez.
Isto encerra esta série. O fio condutor, se é que existe um, é que toda resposta neste produto vale exatamente o quanto valer a prestação de contas que ela consegue dar de como foi obtida.