Resumo

  • Em 4 de abril de 2023, a Virgin Media UK, identificada por observadores técnicos como AS5089, sofreu duas grandes interrupções que prejudicaram o alcance de sua rede e serviços a partir da Internet em geral. [1][2]
  • A Cloudflare observou o tráfego caindo próximo de zero por volta das 00:30 UTC, seguido por uma recuperação instável. A ThousandEyes descreveu um primeiro incidente aproximadamente das 00:30 às 07:00 UTC e um segundo entre cerca de 15:20 e 17:30 UTC. [1][2]
  • A ThousandEyes atribuiu a maior parte da perda de tráfego observada à ausência de rotas BGP viáveis para a rede da Virgin Media. Também observou uma condição diferente: alguns provedores mantiveram rotas em direção ao AS5089, mas o tráfego foi descartado na borda da Virgin Media. [2]
  • Essas observações estabelecem modos de falha de roteamento e encaminhamento. Elas não estabelecem o comando inicial, dispositivo, fornecedor, pessoa, atividade de manutenção, ataque cibernético ou outra causa raiz.
  • A recorrência mais tarde no mesmo dia torna a evidência de restauração central. Uma rota reaparecendo não é o mesmo que uma recuperação estável do serviço, e um status verde interno não é prova de que diversas redes externas podem alcançar e atravessar a borda.
  • A responsabilização segue o controle prático. A Virgin Media controlou a originação das rotas, a retirada, a política de borda, o encaminhamento interno, a sequência de restauração, a divulgação do incidente e a reparação para os clientes. Os peers controlaram sua própria seleção de caminhos e evidências. Os provedores de medição forneceram observações independentes, mas não puderam reconstruir o estado interno não divulgado.
  • Os registros atuais do PeeringDB, derivados do RIPE e de roteamento identificam o AS5089 e seu contexto de interconexão. Eles não são cópias congeladas da rede em 4 de abril de 2023 e não devem ser usados como telemetria do incidente. [6][7][8][9][10][11]
  • A RFC 4271, a RFC 7454, a RFC 8212 e o MANRS fornecem contexto de protocolo e operacional. Nenhum prova quais controles a Virgin Media havia implantado ou que um controle teria evitado o evento. [12][13][14][15]
  • Um registro de responsabilização confiável deve alinhar três relógios: disponibilidade de rotas, encaminhamento de pacotes e serviço visível ao cliente. Deve preservar observações exatas, rotular inferências, expor desconhecidos e documentar as evidências que apenas a operadora poderia ter produzido.

O incidente consistiu em duas interrupções, não um vago dia de indisponibilidade

Grandes falhas de rede são frequentemente resumidas como um horário de início, um horário de término e uma contagem de clientes. Esse formato é conveniente, mas pode apagar o mecanismo que determina a responsabilidade. A interrupção da Virgin Media é melhor compreendida como dois períodos observados, vários estágios de recuperação instável e pelo menos duas condições de falha externamente visíveis.

A visão de tráfego da Cloudflare colocou o primeiro grande colapso por volta das 00:30 UTC de 4 de abril. O tráfego associado à Virgin Media caiu para perto de zero. O serviço não retornou através de uma transição limpa. O gráfico e o relato que o acompanha descreveram recuperação parcial, quedas adicionais e outra interrupção posterior. A importância desse registro não é que a Cloudflare pudesse ver todos os clientes da Virgin Media. Não podia. Seu valor está no fato de uma grande rede externa ter observado uma mudança acentuada no tráfego envolvendo o sistema autônomo da Virgin Media. [1]

A ThousandEyes descreveu o primeiro incidente como ocorrendo aproximadamente das 00:30 às 07:00 UTC. Registrou retiradas de rotas BGP, perda de tráfego e períodos intermitentes de recuperação. O segundo incidente começou por volta das 15:20 UTC e foi resolvido em torno das 17:30 UTC. Compartilhou características externas semelhantes. Essa cronologia corrobora a afirmação de que a alcançabilidade falhou duas vezes. Não prova que o mesmo componente interno ou alteração iniciou ambos os eventos. [2]

Relatos contemporâneos capturaram a dimensão voltada ao cliente. O The Register noticiou uma interrupção generalizada de banda larga e uma confirmação da Virgin Media de que os clientes estavam enfrentando problemas. Essa evidência ajuda a estabelecer que as observações de roteamento correspondiam ao impacto no serviço. Não transforma relatos de mídia social ou uma declaração da empresa em um post-mortem técnico completo. [3]

A distinção entre as duas interrupções é importante porque a recuperação ocorreu entre elas. Uma operadora que relata a restauração do serviço após o primeiro evento está fazendo uma afirmação operacional: a rede está novamente acessível, encaminhando corretamente e estável o suficiente para transportar o tráfego esperado. Uma recorrência posterior pode revelar que o gatilho não foi removido, que os critérios de recuperação eram muito restritos ou que uma falha separada, mas relacionada, permaneceu. O registro público não nos diz qual explicação está correta.

Este artigo, portanto, não combina todos os sintomas em uma sequência inventada. Trata os períodos observados como um caso delimitado de responsabilização. A primeira pergunta é o que o mundo exterior podia ver. A segunda é o que apenas a Virgin Media podia saber. A terceira é quais evidências deveriam conectar essas duas visões.

O AS5089 é uma fronteira operacional, não um detalhe de marca

Um número de sistema autônomo identifica uma rede que apresenta uma política de roteamento coerente para outras redes. Não descreve todos os roteadores internos, cabos, segmentos de acesso ou produtos comerciais. Estabelece, no entanto, uma fronteira útil para a responsabilização entre domínios: outras redes trocam informações de alcançabilidade com o sistema autônomo e encaminham o tráfego de acordo com os caminhos resultantes.

Fontes técnicas identificam a Virgin Media UK com o AS5089. Os dados atuais do PeeringDB descrevem a Virgin Media sob esse ASN e registram uma pegada de interconexão, um AS-SET e informações de peering público. Ferramentas atuais de BGP e derivadas do RIPE também associam o AS5089 à Virgin Media Limited e mostram os recursos de rede anunciados. Esses registros ajudam a vincular o evento à identidade de rede correta. [6][7][8][9][10][11]

Eles devem ser usados com cuidado. Uma página atual do PeeringDB pode mudar após uma operadora atualizar seu registro. Os prefixos atuais podem diferir daqueles anunciados em abril de 2023. Um status de RPKI atual nada diz por si só sobre o status de uma rota durante a interrupção. Um objeto de registro registra informações administrativas e de roteamento; não prova que os pacotes atravessaram uma borda em um determinado minuto.

Registros e diretórios de rede são registros de evidências. Ajudam a identificar detentores de recursos, objetos de roteamento e caminhos de contato. Não são declarações que tornam a rede em funcionamento saudável. A verdade operacional aparece nas rotas que os peers realmente recebem e nos pacotes que a rede realmente aceita e encaminha.

A fronteira do AS também impede que a responsabilidade se dissolva na palavra "Internet". A Internet é uma coleção de redes operadas de forma independente. Um provedor de conteúdo remoto pode ter servidores funcionando. Um provedor de trânsito pode transportar um caminho em direção ao AS5089. Um dispositivo de cliente pode funcionar localmente. No entanto, se as rotas para a rede de acesso desaparecerem, as redes remotas não podem entregar o tráfego. Se as rotas permanecem, mas a borda da operadora descarta os pacotes, o caminho visível ainda não produz serviço.

A Virgin Media não controlava todos os peers remotos, resolvedores, aplicações ou dispositivos de clientes. Controlava, no entanto, sua própria originação de rotas, comportamento de borda, encaminhamento interno e processo de recuperação. Essa é a fronteira prática de controle sobre a qual uma análise justa de responsabilização deve começar.

A retirada de rotas fez a alcançabilidade desaparecer

O BGP permite que sistemas autônomos troquem informações sobre quais prefixos de endereço eles podem alcançar e por quais caminhos. A RFC 4271 define o modelo do protocolo. Uma rota não é uma garantia de que uma aplicação funcionará, mas sem uma rota utilizável, o tráfego geralmente não tem para onde ir. [12]

A ThousandEyes observou que a maior parte da perda de tráfego durante os incidentes de 4 de abril estava associada à falta de rotas BGP viáveis para a rede da Virgin Media. Quando as rotas eram retiradas, outras redes não podiam mais selecionar esses caminhos. Os pacotes destinados a endereços dentro dos prefixos afetados seriam descartados a montante ou falhariam após repetidas tentativas de conexão. [2]

Isso não é meramente um sintoma técnico incidental. A originação de rotas é uma das principais maneiras pelas quais um provedor de acesso torna sua rede alcançável a partir da Internet global. A retirada pode ser uma ação de segurança intencional, uma consequência da perda de sessão, um resultado de política, um efeito de automação ou o resultado de outra falha. As fontes públicas não estabelecem qual mecanismo operou aqui.

A ausência de detalhes sobre a causa raiz não torna a responsabilização impossível. Muda as perguntas. Quais prefixos desapareceram? Quais peers receberam as retiradas primeiro? Todos os caminhos externos desapareceram juntos ou em grupos? O IPv4 e o IPv6 se comportaram da mesma maneira? Quais sistemas de monitoramento detectaram a mudança? Qual sinal de saúde interno autorizou o reanúncio? Qual teste de aceitação precisou ser aprovado antes que a recuperação voltada ao cliente fosse declarada?

Essas perguntas são solicitações de evidências, não acusações. Elas mapeiam o comportamento observável para os registros que uma operadora deve possuir. Um servidor de rotas, roteador de borda, controlador de automação ou sistema de monitoramento pode registrar mudanças com carimbos de data/hora. O gerenciamento de mudanças pode registrar se uma implantação estava em andamento. Coletores de rotas externos podem mostrar uma visão externa parcial. Nenhum registro isolado é completo, mas juntos podem estabelecer uma cronologia defensável.

O risco operacional é maior do que uma sessão de protocolo. As redes de acesso podem anunciar muitos prefixos em várias bordas. Uma falha que retira um amplo conjunto de rotas pode isolar serviços, espaço de endereçamento de clientes, infraestrutura de DNS, sistemas de gerenciamento e canais de suporte de uma só vez. A população afetada então experimenta diferentes erros de aplicação, embora a falha compartilhada seja a alcançabilidade.

A responsabilização, portanto, requer escopo e também tempo. Uma operadora deve ser capaz de dizer quais recursos de endereço foram afetados, quais bordas mudaram de estado, quais serviços dependiam desses recursos e quais caminhos permaneceram disponíveis. Uma declaração ampla de que "a banda larga caiu" não é suficiente para distinguir uma falha de acesso regional de um isolamento em todo o sistema autônomo.

Uma rota visível nem sempre produzia encaminhamento funcional

O detalhe mais importante no relato da ThousandEyes é que a retirada de rotas não explicou todas as falhas observadas. Alguns provedores ainda conseguiam, segundo relatos, rotear o tráfego em direção à rede da Virgin Media. Nesses casos, o tráfego era descartado na borda da Virgin Media. A ThousandEyes descreveu esse padrão como sugerindo um estresse sistêmico, provavelmente envolvendo o plano de controle. [2]

A palavra "sugerindo" importa. Um observador externo pode ver que um caminho permanece e os pacotes falham perto de uma fronteira. Não pode inspecionar o estado de controle interno da operadora. As quedas na borda podem surgir de várias classes de condição: o estado de encaminhamento pode estar ausente, as rotas internas podem estar indisponíveis, as interfaces podem estar comprometidas, a política pode rejeitar o tráfego, a capacidade pode entrar em colapso ou as dependências podem falhar. Escolher um mecanismo sem evidências converteria a observação em ficção.

A conclusão delimitada ainda é forte. A presença da rota e a entrega de pacotes haviam divergido. Para esses caminhos, o sistema de roteamento global carregava uma promessa aparente de que o AS5089 era alcançável, enquanto a borda da operadora não entregava o serviço correspondente.

Essa divergência é um risco de rede recorrente. O estado do plano de controle pode parecer válido enquanto o plano de dados falha. Uma sessão BGP pode permanecer estabelecida enquanto um próximo salto está inutilizável. Um prefixo pode permanecer em uma tabela de roteamento enquanto os pacotes são descartados. Um painel interno pode marcar uma borda como disponível porque o processo está ativo, mesmo que as sondas ponta a ponta falhem.

A resposta da responsabilização é exigir evidências pareadas. A saúde da rota pergunta se os prefixos esperados estão visíveis através dos peers esperados. A saúde do encaminhamento pergunta se pacotes representativos atravessam a borda e alcançam os destinos. A saúde da aplicação pergunta se os serviços reais completam as transações. Uma operadora não deve colapsar essas camadas em um único indicador verde.

As sondas externas são valiosas porque testam o serviço de fora do sistema alterado. Devem ser diversificadas o suficiente para evitar confundir a visão de um peer com toda a Internet. As medições devem incluir provedores que receberam retiradas e provedores que mantiveram as rotas. Devem cobrir regiões relevantes, famílias de endereços e classes de serviço.

O resultado deve ser uma matriz, não um único número de tempo de atividade. Uma rota pode estar ausente ou presente. Um pacote pode falhar antes da borda, na borda ou após a entrada. Uma aplicação pode falhar apesar do transporte bem-sucedido. Essa matriz ajuda os respondedores a decidir se devem restaurar os anúncios de rota, reparar o encaminhamento interno, reduzir a carga, isolar uma borda com falha ou comunicar um escopo mais restrito.

A recuperação precisa ser comprovada em três relógios

A recorrência de 4 de abril torna o significado de "recuperado" central. A recuperação não é um carimbo de data/hora único. É um acordo entre pelo menos três relógios: roteamento, encaminhamento e serviço visível ao cliente.

O relógio de roteamento registra quando os prefixos foram retirados, reanunciados e aceitos pelos peers. Pode incluir fluxos de atualização BGP, observações de coletores de rotas e verificações de looking-glass. Como a propagação do BGP é distribuída, diferentes observadores podem ver mudanças em momentos diferentes. O primeiro reaparecimento de uma rota não prova a convergência global.

O relógio de encaminhamento registra se o tráfego realmente atravessou a fronteira da operadora e alcançou destinos representativos. Inclui perda de pacotes, latência, traços de caminho e sondas ativas. Pode ficar atrasado em relação ao reanúncio de rota se o estado de encaminhamento estiver incompleto. Também pode falhar independentemente enquanto as rotas permanecem visíveis.

O relógio do cliente registra quando os usuários perderam o serviço, quando os canais de suporte reconheceram o problema, quando os avisos de status mudaram, quando os clientes puderam concluir tarefas reais e quando os processos de compensação ou reclamação se tornaram disponíveis. Reflete consequências comerciais e sociais, não apenas o estado da rede.

Uma restauração responsável deve alinhar esses relógios. A operadora deve especificar um intervalo de estabilização durante o qual a visibilidade da rota permaneça consistente, as sondas de encaminhamento tenham sucesso a partir de diversas redes e os indicadores de impacto no cliente retornem às faixas esperadas. Se a primeira recuperação foi aceita antes que esse intervalo decorresse, o registro deve explicar o porquê.

As fontes públicas não revelam os critérios internos de aceitação da Virgin Media. Elas mostram que o serviço melhorou e, em seguida, uma grande interrupção semelhante ocorreu novamente. Isso é suficiente para perguntar se a restauração foi definida como um retorno transitório do tráfego ou como uma alcançabilidade estável de ponta a ponta.

A resposta não deve ser adivinhada. Um registro pós-incidente poderia fornecê-la publicando uma linha do tempo delimitada: o que foi alterado, quais sinais desencadearam a recuperação, quais sinais depois se deterioraram, se os mesmos componentes estavam envolvidos e qual validação adicional foi adicionada. Se preocupações de segurança ou comerciais impedirem a divulgação da configuração, evidências agregadas de rota e de saúde ainda podem ser publicadas.

Essa abordagem evita a transparência performativa. Uma longa narrativa sem carimbos de data/hora de rota e encaminhamento pode soar franca, mas deixa a principal alegação impossível de testar. Um registro mais curto que alinhe os três relógios pode fornecer mais responsabilização.

Uma segunda interrupção transforma o rollback em um problema de evidência

A recorrência após uma recuperação parcial apresenta aos respondedores uma escolha difícil. Eles podem acreditar que removeram a causa, ou podem ter apenas restaurado os sintomas. A distinção determina se a rede deve retornar à operação normal ou permanecer em um estado de vigilância.

Um rollback é frequentemente tratado como um evento binário: o novo estado foi removido, portanto, o estado antigo deve ser seguro. As redes distribuídas não são tão simples. A configuração antiga pode retornar enquanto as sessões reconvergam a taxas diferentes. O estado em cache ou gerado pode persistir. As dependências internas podem não se recuperar juntas. Uma falha separada pode ter sido exposta pelo evento original.

Por esse motivo, o rollback deve estar vinculado a invariantes observáveis. Os prefixos esperados devem estar presentes. As retiradas inesperadas ou a instabilidade de caminhos devem cessar. O encaminhamento de borda deve funcionar a partir de várias redes externas. Os próximos saltos internos devem ser válidos. A capacidade deve suportar a carga que retorna. As taxas de erro visíveis ao cliente devem permanecer estáveis por um intervalo definido.

A RFC 7454 discute práticas operacionais e de segurança em torno do BGP. A RFC 8212 propõe uma postura explícita de rejeição padrão para a política de eBGP. O MANRS descreve práticas de filtragem, coordenação, validação e validação global. Essas fontes são úteis para definir famílias de controle. Não estabelecem que um controle específico da Virgin Media falhou, nem provam que aplicar uma recomendação teria evitado essa interrupção. [13][14][15]

A lição é mais restrita: a política de rota e a recuperação precisam de condições explícitas e testáveis. Uma operadora deve saber quais rotas um peer está autorizado a anunciar, o que exportará, qual alcançabilidade interna deve existir antes que um agregado seja anunciado e quais medições independentes podem bloquear ou reverter uma implantação.

Para um provedor de acesso nacional, o design canário é especialmente importante. Uma mudança pode ser limitada a uma borda, uma região, uma família de endereços ou um grupo de prefixos controlados antes de uma implantação mais ampla. O canário deve ser observado de fora do domínio administrativo. Se as invariantes de rota ou encaminhamento falharem, a automação deve interromper a expansão e preservar as evidências.

Nada disso exige que o artigo afirme que uma mudança causou o incidente de 4 de abril. Estabelece um padrão para qualquer explicação. Se a causa foi uma implantação, a operadora deve mostrar a fronteira e o rollback. Se foi uma falha de dispositivo ou dependência, deve mostrar por que a redundância não preservou o serviço de rota e encaminhamento. Se várias condições se combinaram, deve mostrar como a detecção e a recuperação foram alteradas.

A interconexão transforma operações privadas em risco compartilhado

O AS5089 não opera isoladamente. Sua alcançabilidade depende de sessões e políticas com outras redes. O registro atual do PeeringDB identifica instalações de interconexão e participação em trocas associadas à Virgin Media. Esses detalhes são contexto atual, não uma reconstrução da topologia de 2023, mas demonstram o número de fronteiras operacionais envolvidas para alcançar uma grande rede de acesso. [7]

Quando uma rede retira rotas, os peers devem processar as atualizações e selecionar alternativas, se existirem. Quando uma borda aceita tráfego, mas não pode encaminhá-lo, os peers podem continuar enviando pacotes para um caminho com falha até que medições ou a coordenação da operadora revelem o problema. O incidente, portanto, criou obrigações de evidência em ambos os lados da interconexão.

A Virgin Media controlava a precisão e a usabilidade das rotas que originava e o comportamento de encaminhamento por trás de sua borda. Os peers controlavam o que aceitavam, como monitoravam o caminho e se podiam contatar a operadora. Os provedores de medição observavam apenas os pontos de vantagem disponíveis para eles.

Essa divisão de controle deve aparecer na coordenação de incidentes. Um relatório de um peer deve declarar quais rotas recebeu, quais sessões permaneceram ativas, onde os pacotes falharam e quando o comportamento mudou. A operadora deve reconhecer se essa visão corresponde à sua própria telemetria. As observações conflitantes devem ser preservadas, em vez de serem normalizadas em uma linha do tempo única muito cedo.

Os dados de contato são importantes aqui. Os registros do registro e do PeeringDB podem fornecer contatos de NOC ou de política. Seu valor é prático: uma rede afetada pode alcançar alguém autorizado a agir? Um endereço que existe, mas não é monitorado, não é um controle operacional. Um caminho de contato deve ser testado e mantido sem transformar o registro em uma reivindicação de governança sobre a operadora.

A coordenação também afeta a recuperação do cliente. Redes de conteúdo e clientes empresariais com vários provedores podem desviar o tráfego de um caminho com falha. Os clientes residenciais geralmente não podem escolher um sistema autônomo de última milha alternativo durante um incidente. Essa assimetria coloca mais responsabilidade de continuidade no provedor de acesso.

Os clientes não devem ser culpados por não conseguirem contornar uma interrupção de acesso em todo o AS que não podem controlar. Grandes peers ainda devem testar seus próprios procedimentos de roteamento e escalonamento, mas sua preparação não apaga a responsabilidade da operadora pela precisão do estado de rota e encaminhamento.

O monitoramento deve ser independente da rede com falha

Uma falha que afeta o roteamento também pode isolar as ferramentas usadas para diagnosticar e comunicar sobre ela. Sistemas de status, coletores de telemetria, serviços de autenticação e portais de suporte podem compartilhar o mesmo caminho de rede. Se o fizerem, a operadora pode perder o serviço e as evidências de uma só vez.

O monitoramento independente deve, portanto, situar-se fora do domínio de falha da produção. Coletores de rotas externos, sondas ativas e medições de terceiros podem testar o que outras redes veem. A telemetria interna permanece necessária porque explica o estado do dispositivo e da política. Nenhuma visão é suficiente por si só.

O relato da Cloudflare e a análise da ThousandEyes ilustram o valor da observação externa. Eles puderam detectar o colapso do tráfego, a retirada de rotas e a falha de borda sem acesso aos sistemas internos da Virgin Media. Seus dados, no entanto, não puderam identificar o evento interno iniciador. [1][2]

A operadora deve correlacionar as evidências externas e internas por tempo, prefixo, borda e família de endereços. As fontes de tempo devem ser confiáveis o suficiente para que os respondedores possam comparar os registros. Um erro de cinco minutos no relógio pode distorcer a ordem aparente da retirada de rota, falha de encaminhamento e ação da operadora.

O monitoramento também precisa de testes negativos. Não basta confirmar que uma rota existe. As sondas devem testar destinos dentro de prefixos representativos. Não basta confirmar que uma borda responde. Os testes devem verificar se o tráfego do cliente pode atravessá-la. Não basta confirmar que um portal carrega a partir do interior da rede. Os clientes externos devem ser capazes de alcançá-lo.

O objetivo do design não é produzir uma visão global perfeita. Isso é irrealista. É tornar explícitos os pontos cegos e garantir que nenhum domínio de falha único forneça todas as evidências usadas para declarar a recuperação.

A divulgação pública deve preservar os desconhecidos

Os post-mortems de rede frequentemente enfrentam pressões concorrentes. Os clientes querem uma explicação. Os engenheiros precisam de tempo para verificar. As equipes de segurança podem restringir detalhes. As equipes jurídicas podem evitar declarações que possam criar responsabilidade. O resultado pode ser uma linguagem tão ampla que não ofereça nenhuma evidência operacional.

Uma divulgação responsável pode permanecer delimitada sem ser vazia. Pode declarar os serviços e prefixos afetados em um nível apropriado, o modo de falha observado, o período de retirada de rotas, o período de falha de encaminhamento de borda, as etapas de restauração, o intervalo de validação e os controles alterados posteriormente.

Deve distinguir observação de inferência. "As rotas para esses grupos de prefixos foram retiradas" é uma observação. "Uma dependência do plano de controle estava sob estresse" pode ser uma inferência. "Um processo específico de fornecedor falhou" requer evidência direta.

As fontes públicas usadas aqui preservam essa distinção. A ThousandEyes disse que o comportamento da borda sugeria um estresse sistêmico provavelmente afetando o plano de controle. Este artigo não reescreve essa declaração como uma causa raiz confirmada no plano de controle. [2]

Os desconhecidos devem permanecer visíveis: o evento iniciador, o responsável pela decisão interna, o conjunto exato de dispositivos, o escopo completo de clientes, se ambas as interrupções compartilharam uma causa e a remediação duradoura não são estabelecidos pelo conjunto de fontes. Preservá-los é uma forma de precisão, não uma fraqueza.

A questão da responsabilização é, então, se a parte com acesso às evidências faltantes produziu um registro adequado. Os analistas externos não devem preencher uma lacuna de divulgação com especulação confiante. As operadoras não devem usar a impossibilidade de certeza externa como motivo para não publicar nada.

As soluções para os clientes fazem parte da responsabilização da rede

As evidências de roteamento e encaminhamento podem parecer distantes do faturamento e do suporte ao cliente, mas determinam se os clientes podem comprovar uma perda de serviço qualificável. Um provedor de acesso controla tanto o registro técnico quanto grande parte do processo inicial de reparação.

O quadro de compensação automática do Ofcom destina-se a fornecer reembolso para falhas especificadas de serviços de banda larga e telefonia fixa sem exigir que os clientes façam uma reclamação convencional. A Virgin Media está listada como participante. A Virgin Media também publica suas próprias orientações de compensação e informações sobre trabalhos planejados. [16][17][18]

Essas páginas são atuais. Este artigo não presume que todos os valores, regras ou condições de elegibilidade atuais se aplicavam inalterados em abril de 2023. Qualquer uso da política deve indicar a data e não deve afirmar que todos os clientes afetados pelo evento de roteamento se qualificaram automaticamente.

O princípio de responsabilização é mais amplo do que um pagamento único. A operadora deve preservar evidências suficientes do estado do serviço para determinar quando uma perda total começou e terminou, quais produtos foram afetados e se uma exceção se aplica. Os clientes não devem precisar fazer engenharia reversa do BGP para estabelecer que seu serviço falhou.

Os canais de comunicação também devem sobreviver ao incidente. Se uma página de status, portal de suporte ou serviço telefônico depende da mesma rede com falha, os clientes podem ser incapazes de relatar a falha ou ver as atualizações. A página atual de trabalhos planejados da Virgin Media direciona os clientes para serviços alternativos durante interrupções planejadas. Os incidentes não planejados precisam de um caminho de comunicação igualmente independente. [17]

Os dados de reparação podem melhorar a responsabilização da engenharia. O número e a duração dos registros validados de perda de serviço mostram o impacto em termos do cliente. Os padrões de reclamação podem revelar diferenças regionais ou de produto que os gráficos de tráfego agregados ocultam. Essas informações devem alimentar a revisão pós-incidente sem substituir as evidência técnicas.

O padrão correto é a rastreabilidade. Um período de interrupção voltado ao cliente deve ser conciliável com as evidências de rota e encaminhamento, enquanto as exceções devem ter um motivo documentado. Isso reduz disputas e desencoraja declarações de recuperação que são tecnicamente restritas, mas comercialmente prematuras.

As evidências de registro e de segurança de roteamento devem permanecer em seu papel adequado

Um ASN, registro de prefixo, objeto de rota ou autorização RPKI ajuda a estabelecer quem está autorizado a originar espaço de endereçamento e como outras redes podem validar as reivindicações. Esses registros são importantes para a superfície de responsabilização, mas não garantem a disponibilidade.

As ferramentas atuais mostram a identidade de rede do AS5089 e os recursos anunciados. O PeeringDB identifica a operadora e o contexto de interconexão. Os serviços derivados do RIPE expõem informações de registro e prefixos. As ferramentas BGP mostram as observações de roteamento atuais. [6][7][8][9][10][11]

O artigo não deve usar essas páginas atuais para afirmar quais rotas estavam presentes em todos os momentos de 2023. A análise histórica do incidente deve se basear nas observações datadas da Cloudflare e da ThousandEyes. Os registros atuais são usados para vincular a entidade e explicar a superfície de controle.

O RPKI também tem um papel delimitado. A validação de origem de rota pode ajudar as redes a avaliar se um ASN de origem está autorizado para um prefixo. Não prova que a origem autorizada pode encaminhar pacotes, que suas rotas internas estão saudáveis ou que sua borda aceitará o tráfego. Uma rota pode ser válida por origem e ainda assim levar a um buraco negro.

Essa distinção se alinha com a camada de realidade. Os metadados de segurança melhoram a qualidade das decisões de roteamento. Não substituem as evidências de código em execução. A responsabilização requer tanto registros precisos quanto o serviço observado.

A mesma cautela se aplica à abordagem de rejeição padrão da RFC 8212 e às práticas do MANRS. Elas reduzem classes de propagação acidental de rotas e melhoram a coordenação. Não são explicações universais para um colapso de alcançabilidade, e um controle geral não pode estabelecer um diagnóstico retrospectivo.

Um padrão prático de evidências para recuperação de redes de acesso

O incidente da Virgin Media sugere um registro de recuperação concreto que outras redes de acesso podem adotar. O registro deve ser projetado antes de uma interrupção, porque as evidências reunidas posteriormente são facilmente incompletas.

Primeiro, preserve o estado das rotas. Para cada grupo de prefixos afetado, registre os anúncios, retiradas, sessões de peers, versões de política e carimbos de data/hora. Inclua informações suficientes para mostrar quais caminhos externos desapareceram e quais permaneceram. Não publique configurações sensíveis do cliente, mas retenha-as para revisão interna e regulatória.

Segundo, preserve o estado de encaminhamento. Execute sondas de diversas redes externas para destinos representativos. Registre onde o tráfego parou, se a borda o aceitou e se os destinos internos responderam. Separe IPv4 e IPv6. Separe as dependências residenciais, empresariais, de DNS e de gerenciamento onde seus caminhos diferem.

Terceiro, preserve o estado de mudança. Registre implantações, manutenção, decisões de automação e ações de rollback em torno da janela do incidente. Se nenhuma mudança causou o evento, afirme isso somente após verificar o registro. Se a causa permanecer desconhecida, preserve esse status e o limite da investigação.

Quarto, defina critérios de recuperação. Exija estabilidade de rota, sucesso de encaminhamento, saúde da aplicação e melhoria do impacto no cliente por um intervalo nomeado. Evite declarar a recuperação total a partir da primeira sonda bem-sucedida ou do primeiro reanúncio de rota.

Quinto, teste o risco de recorrência. Compare o estado restaurado com o estado antes do incidente. Identifique as dependências que permaneceram degradadas. Continue o monitoramento intensificado durante pelo menos um ciclo de carga normal. Se ocorrer uma segunda interrupção, preserve as diferenças em vez de substituir a primeira linha do tempo.

Sexto, coordene com os peers. Forneça um caminho de NOC testado e uma maneira estruturada para que outras redes relatem observações de rota e encaminhamento. Reconheça evidências conflitantes. Relatórios externos podem expor falhas invisíveis do interior da operadora.

Sétimo, comunique em camadas. Dê aos clientes uma declaração concisa de serviço e um caminho de reparação. Dê às partes interessadas técnicas uma cronologia delimitada de roteamento e encaminhamento. Dê aos reguladores evidências suficientes para avaliar a duração, o escopo e a resposta.

Oitavo, reconcilie as soluções. Vincule os períodos validados de perda de serviço aos sistemas de compensação e reclamação sem exigir que os clientes entendam o mecanismo de rede. Declare as datas da política e os limites de elegibilidade.

Nono, revise a concentração. Identifique os sistemas de suporte, status, autenticação e telemetria que compartilham a rede afetada. Mova as evidências críticas e os caminhos de comunicação para fora do domínio de falha sempre que prático.

Décimo, publique a remediação duradoura. Uma promessa de melhorar o monitoramento não é suficiente. Declare qual sinal foi adicionado, qual limite foi alterado, qual fronteira de implantação foi introduzida, qual teste de recuperação se tornou obrigatório e como o controle será auditado.

Esse quadro não presume que toda interrupção pode ser evitada. Exige que a operadora possa identificar a fronteira da falha, restaurar o serviço com segurança e provar o que mudou.

A responsabilização deve seguir a capacidade, não a retrospectiva

Uma interrupção de uma grande rede de acesso afeta milhões de relacionamentos entre clientes, serviços e outras redes. Essa escala cria a tentação de atribuir responsabilidade ilimitada a uma operadora ou, inversamente, chamar o evento de falha inevitável da Internet. Nenhuma das abordagens é precisa.

A Virgin Media deve ser responsabilizada pelos controles que possuía: originação de rotas, encaminhamento de borda, recuperação interna, comunicação operacional e reparação ao cliente. Não deve ser responsabilizada por fatos que as evidências públicas não estabelecem, como uma falha de fornecedor nomeado ou ato malicioso.

Os peers devem ser responsabilizados por sua própria aceitação de rotas, monitoramento e escalonamento. Os provedores de conteúdo devem ser responsabilizados pelo design realista de dependências e comunicação. Os reguladores devem ser responsabilizados por quadros de reparação que possam usar evidências técnicas sem colocar ônus de prova impossíveis sobre os clientes.

Os provedores de medição devem declarar os limites de seus pontos de vantagem. Suas observações são valiosas porque são independentes, não porque são oniscientes. Os analistas e jornalistas devem preservar esses limites.

Os clientes têm o menor controle sobre a fronteira do sistema autônomo. Os usuários residenciais geralmente não podem redirecionar em torno de seu provedor. Sua principal responsabilidade é relatar o impacto e usar os recursos de reparação disponíveis, não projetar uma segunda rede de acesso.

A responsabilização baseada em capacidade evita a retrospectiva. Pergunta o que cada parte podia observar, decidir, mudar e provar na época. Também expõe as evidências faltantes sem inventar uma causa.

Conclusão

As interrupções da Virgin Media de 4 de abril de 2023 foram eventos de infraestrutura de rede porque o estado das rotas e do encaminhamento determinou se o AS5089 existia como um caminho utilizável a partir da Internet mais ampla. A maior parte da perda de tráfego observada acompanhou a falta de rotas BGP viáveis. Algumas rotas permaneceram, mas o tráfego ainda falhou na borda da operadora. O serviço retornou e depois falhou novamente mais tarde no mesmo dia. [1][2]

Esses fatos são suficientes para definir um padrão de responsabilização mesmo que a causa raiz permaneça não divulgada. A recuperação deve ser comprovada em termos de disponibilidade de rotas, encaminhamento de pacotes e serviço visível ao cliente. Os dados de registro devem identificar a rede sem serem confundidos com a verdade operacional. As medições externas devem testar as afirmações da operadora sem fingir revelar o estado interno. As soluções para os clientes devem se conectar à mesma linha do tempo de evidências.

O registro pós-incidente mais forte não reivindicaria certeza que as fontes não podem apoiar. Ele mostraria quais rotas mudaram, o que os pacotes fizeram, o que os clientes experimentaram, o que a operadora mudou e como a recuperação estável foi verificada. Essa é a diferença entre uma rede que retorna brevemente e uma operadora que demonstra que o serviço foi restaurado.

Para incidentes futuros, essa prova deve ser reunida à medida que as operações prosseguem, em vez de ser reconstruída após o aumento da preocupação pública. As atualizações de rota, as sondas de encaminhamento, os sinais de impacto no cliente, os registros de mudança e os avisos de status devem compartilhar uma linha do tempo conciliada. A operadora deve publicar o suficiente desse registro para mostrar o modo de falha, o teste de recuperação e a mudança de controle duradoura, protegendo ao mesmo tempo os detalhes sensíveis do cliente e de segurança.

Uma rede que pode produzir essa evidência está mais bem posicionada para aprender com as falhas, coordenar com os peers e oferecer soluções justas. Uma rede que não pode produzi-la pode restaurar os pacotes, mas não pode demonstrar por que as mesmas condições não retornarão.

Fontes

  1. Cloudflare, "Visão da Cloudflare sobre a interrupção da Virgin Media no Reino Unido":https://blog.cloudflare.com/virgin-media-outage-april-4-2023/
  2. ThousandEyes, "Análise da interrupção da Virgin Media UK: 4 de abril de 2023":https://www.thousandeyes.com/blog/virgin-media-uk-outage-analysis-april-4-2023
  3. The Register, "Virgin Media do Reino Unido sofre grande interrupção de banda larga":https://www.theregister.com/on-prem/2023/04/04/uks-virgin-media-suffers-massive-broadband-outage/1495714
  4. ThousandEyes, "As principais interrupções da Internet em 2023":https://www.thousandeyes.com/blog/top-internet-outages-2023
  5. Cloudflare, "Resumo das interrupções da Internet no 2º trimestre de 2023":https://blog.cloudflare.com/q2-2023-internet-disruption-summary/
  6. Cloudflare Radar, tráfego do AS5089:https://radar.cloudflare.com/traffic/as5089
  7. PeeringDB, AS5089 Virgin Media:https://www.peeringdb.com/net?asn=5089
  8. bgp.tools, AS5089 Virgin Media Limited:https://bgp.tools/as/5089
  9. RIPEstat, informações de rede do AS5089:https://stat.ripe.net/data/network-info/data.json?resource=AS5089
  10. RIPEstat, prefixos anunciados pelo AS5089:https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS5089
  11. RIPE Database, consulta AS5089:https://apps.db.ripe.net/db-web-ui/query?searchtext=AS5089
  12. RFC 4271, "Um Protocolo de Gateway de Fronteira 4 (BGP-4)":https://www.rfc-editor.org/rfc/rfc4271
  13. RFC 7454, "Operações e Segurança do BGP":https://www.rfc-editor.org/rfc/rfc7454
  14. RFC 8212, "Comportamento de Propagação de Rotas BGP Externo (EBGP) Padrão sem Políticas":https://www.rfc-editor.org/rfc/rfc8212
  15. MANRS, Programa de Operadores de Rede:https://manrs.org/netops/
  16. Ofcom, "Compensação automática: O que você precisa saber":https://www.ofcom.org.uk/phones-and-broadband/service-quality/automatic-compensation-need-know
  17. Virgin Media, "Estamos melhorando a rede na sua área":https://www.virginmedia.com/help/planned-work
  18. Virgin Media, "Compensação automática":https://www.virginmedia.com/help/billing-and-payments/automatic-compensation