Resumo
- A Connectivity Inc era uma empresa de software de busca local e inteligência de clientes, não um provedor de acesso regional documentado. Seu site atual vende serviços de listagem, avaliações e dados; registros judiciais e de financiamento históricos descrevem YellowBot, publicidade, venda de dados e aplicativos web hospedados, em vez de fibra, wireless fixo ou planos de internet residencial.
- A rede por trás desse software era, no entanto, real. A ARIN atribuiu à Solfo Inc, nome anterior da Connectivity, o AS53582, um bloco IPv4 /22 e um bloco IPv6 /45. O PeeringDB lista a rede em One Wilshire e Telecom Center LA, com uma porta de 1 Gbps na Any2West e classificação como rede de conteúdo.
- As evidências operacionais atuais são negativas. A visão de roteamento da RIPE não mostrou anúncios IPv4 ou IPv6, vizinhos observados ou espaço de endereço visível para o AS53582 em 10 de julho de 2026; sua última rota observada foi em setembro de 2025. Os detalhes de tráfego, instalações e troca no PeeringDB são substancialmente mais antigos e não podem estabelecer uma rede ativa hoje.
- Os caminhos de falha economicamente relevantes eram, portanto, energia de colocation, falha de roteador ou óptica, falha de cross-connect ou fibra metropolitana, retirada de upstream e escassez de mãos remotas autorizadas. Não há evidências públicas que comprovem planta de acesso, torres, postes, equipamentos de instalações do cliente, uma pegada de serviço regional ou equipes de campo atendendo assinantes de banda larga.
O nome aponta para banda larga, mas as evidências apontam para conteúdo
Existem duas maneiras de interpretar a palavra conectividade na história desta empresa, e apenas uma é apoiada pelas evidências públicas. A primeira é o significado comum de telecomunicações: uma empresa conecta residências ou empresas à internet por meio de fibra, wireless fixo, cabo ou outra tecnologia de acesso. Essa leitura implica uma área de serviço geográfica, endereços instaláveis, drops de cliente, postes ou dutos, eletrônicos de rede próximos aos assinantes, planos de varejo e uma organização de reparo que pode alcançar a planta danificada.
O segundo significado é aquele que a Connectivity Inc usou comercialmente. Seu produto conectava empresas com informações sobre seus clientes. Osite atual da empresaapresenta gerenciamento de listagens, gestão de avaliações, licenciamento de dados, captação de leads sociais e ativação de clientes. Ele diz que a plataforma atende mais de 10.000 empresas. Adescrição de gerenciamento de listagensdo site trata da correção de detalhes de negócios em mecanismos de pesquisa, mapas e listagens online. Suapolítica de privacidadedescreve serviços de gerenciamento de reputação em nuvem, gerenciamento de listagens empresariais e serviços de relacionamento com o cliente. Nenhuma dessas páginas oferece um plano de acesso à internet, um verificador de endereço, uma taxa de instalação, um nível de velocidade ou um compromisso de nível de serviço para um circuito de dados.
Isso não é meramente uma distinção na linguagem de marketing. Isso muda todo o sistema físico que deve ser avaliado. Um provedor de banda larga regional possui ou aluga um caminho da borda da rede em direção a muitas instalações de clientes. Uma empresa de conteúdo pode possuir um conjunto relativamente pequeno de roteadores e servidores dentro de instalações neutras de operadoras, comprar trânsito upstream, fazer peering com redes selecionadas e entregar um aplicativo sobre redes de acesso operadas por outras empresas. Ambos dependem de fibra e eletricidade. Apenas o primeiro carrega a obrigação de acesso local.
A Connectivity pertence ao segundo grupo com base nas evidências disponíveis. Seucontrato de cliente de 2015identifica uma corporação de Delaware com sede na 100 East Tujunga Avenue, em Burbank, e descreve dois produtos proprietários: Listings Management e um Opinion Monitoring System. O contrato diz respeito ao uso desses serviços online e dados de negócios associados. Ele não contrata a transmissão do tráfego geral de internet de um cliente.
Um registro judicial federal anterior é ainda mais claro. Em uma disputa de patente de 2011, o tribunal descreveu o site YellowBot da Solfo Inc como umdiretório de negócios online. Ele afirmou que a Solfo obtinha receita com publicidade e venda de informações coletadas de outros sites, mantinha seu único escritório em Burbank, empregava oito funcionários em tempo integral na Califórnia e hospedava os computadores da Solfo e YellowBot no Condado de Los Angeles. O registro trata de uma questão legal diferente e é histórico, mas fornece evidências incomumente concretas do que a empresa fazia e onde sua computação estava localizada.
A narrativa corporativa continuou na mesma direção. Umrelatório de financiamento de 2014descreveu a Connectivity como uma fornecedora de software de inteligência de clientes, controladora da YellowBot e Weblocal, e a antiga Solfo renomeada. Ele relatou uma rodada de US$ 6,35 milhões e mais de 92.000 contas empresariais pagas. Em 2016, a SweetIQ anunciou que haviaadquirido a divisão de marketing local da Connectivity, descrevendo a operação adquirida como uma empresa de marketing local direto ao negócio que trabalhava com mais de 20.000 localizações físicas. Esses números referem-se a contas de software ou locais de marketing, não a instalações conectadas a uma rede de acesso da Connectivity.
Essa distinção deve governar toda inferência posterior. Uma empresa pode ter dezenas de milhares de contas e ainda ocupar apenas alguns racks. Ela pode alcançar usuários em toda a América do Norte sem possuir um único drop residencial. Pode registrar um sistema autônomo porque precisa de roteamento independente para seus sites, não porque vende trânsito ou banda larga. O nome, a contagem de clientes e o sistema autônomo da Connectivity, portanto, não são uma prova cumulativa de um ISP regional. Eles descrevem uma empresa de software que tinha motivo para operar infraestrutura de conteúdo.
AS53582 era um recurso de rede real, não uma licença de banda larga
A evidência mais forte de que a Connectivity controlava a infraestrutura da internet é oregistro ARIN para AS53582. A ARIN nomeia o sistema autônomo como SOLFO, fornece uma data de registro de 23 de junho de 2010 e o vincula à Solfo Inc em Burbank. O mesmo registro contém contatos técnicos, de operações de rede e de abuso da Solfo. Registros ARIN separados atribuem à Solfo obloco IPv4 199.15.176.0/22e obloco IPv6 2620:101:d000::/45. Esses são registros diretos de recursos numéricos, não uma suposição de terceiros baseada no nome de uma empresa.
Um número de sistema autônomo tem um significado preciso, mas limitado. A ARIN define um sistema autônomo como um ou mais prefixos IP operados sob uma política de roteamento única e claramente definida, e diz que o número permite a um operadortrocar informações de roteamento com outras redes. Isso não significa que o titular forneça acesso à internet no varejo. Universidades, bancos, plataformas de nuvem, agências governamentais e empresas de conteúdo podem todos precisar de uma identidade de roteamento independente.
A própria política da ARIN é explícita sobre a próxima limitação. O registro não garante que um prefixo será roteado por qualquer operador. OManual de Políticas de Recursos Numéricossepara a atribuição administrativa de recursos numéricos de sua alcançabilidade pública. Essa diferença é central para a Connectivity em 2026: os registros permanecem, mas o sistema autônomo não é visível como origem atual nos dados de roteamento público examinados aqui.
Informações históricas de interconexão preenchem o propósito original. Aentrada AS53582 do PeeringDBchama a rede de Connectivity Inc, lista Solfo, YellowBot e LocalRobot como nomes alternativos e a classifica como Content. Essa é a categoria do banco de dados para uma rede que entrega seu próprio material, em vez de uma operadora de acesso conectando usuários finais. A entrada afirma ter dez prefixos IPv4, um prefixo IPv6, tráfego balanceado de 1 a 5 Gbps e um escopo norte-americano. Também anuncia uma política de peering aberta.
Essas alegações são consistentes com um editor web que queria menor custo de entrega e melhor controle sobre como o tráfego chegava aos usuários. Uma rede de conteúdo com visualizações de página suficientes pode comprar trânsito de uma ou mais operadoras upstream enquanto troca tráfego diretamente com redes dispostas em um ponto de troca de internet. A troca direta pode encurtar o caminho para um ISP de consumo, reduzir a parcela do tráfego cobrada como trânsito e fornecer outra rota lógica. Uma faixa de tráfego de 1 a 5 Gbps é totalmente plausível para um grupo de sites de busca local movimentados.
Isso não diz nada sobre casas atendidas, assinantes de varejo ou receita de rede de acesso.
As datas importam tanto quanto os valores. O PeeringDB mostra que a entrada geral da rede foi atualizada pela última vez em julho de 2022. Os detalhes de troca pública listados foram atualizados pela última vez em março de 2016, e os registros de instalações na entrada também foram alterados pela última vez em 2016. O PeeringDB se descreve como umbanco de dados gratuito e mantido pelos usuários. É altamente útil para encontrar onde os operadores dizem que podem se interconectar, mas uma entrada antiga não é um feed de telemetria ao vivo e sua palavra Operational não equivale a um anúncio BGP atualmente visível.
A conclusão correta é mais restrita do que qualquer um dos extremos. AS53582 não era um registro decorativo: observações históricas de rotas, alocações de endereços, registros de instalações e uma porta de troca pública formam uma pegada operacional coerente. Também não era uma rede de acesso regional. As evidências públicas estabelecem um sistema autônomo de serviço de conteúdo que foi construído para dar suporte às propriedades web da Solfo e da Connectivity.
Dois prédios no centro definiram a superfície operacional física
O PeeringDB coloca o AS53582 em duas instalações em Los Angeles:CoreSite LA1 em One WilshireeTelecom Center LA. Também registra uma conexão de 1 Gbps para Any2West com endereço IPv4 206.72.210.92 e endereço IPv6 2001:504:13::92. As entradas das instalações não revelam a contagem de racks, consumo de energia, número de servidores, inventário de cross-connects ou se a Connectivity alugou espaço diretamente ou comprou serviço de um fornecedor de colocation. No entanto, elas fornecem o melhor limite público em torno da rede física da empresa.
One Wilshire não é um ponto abstrato em um mapa de peering. É um hotel de operadoras no 624 South Grand Avenue, no centro de Los Angeles. A própria descrição do prédio diz que suasala de meet-me room é operada pela CoreSitee fornece acesso a mais de 250 provedores de serviços de rede, serviços de nuvem, operadoras nacionais e internacionais e fibra iluminada e escura. A CoreSite descreve oLA1como um dos data centers mais densamente interconectados do mundo. Uma rede presente lá pode solicitar cross-connects físicos curtos para operadoras e infraestrutura de troca em vez de estender uma rota longa dedicada a cada contraparte.
O Telecom Center LA fica perto, no 530 West 6th Street. ODistrito de Melhoria de Negócios do Centroo descreve como um prédio de data center e telecomunicações com conectividade direta para One Wilshire. O PeeringDB atualmente lista apenas dez redes no prédio, mas a instalação oferece outro local a partir do qual o AS53582 historicamente dizia que poderia se interconectar. Como os dois prédios estão próximos, movimentar tráfego entre eles pode ser barato e operacionalmente conveniente. Proximidade não é o mesmo que independência geográfica.
Esse último ponto é importante. Dois nomes de instalações podem produzir uma aparência de redundância enquanto compartilham um pequeno domínio de falha no centro da cidade. Os prédios podem usar diferentes alimentações de concessionária, geradores, risers e operadoras, mas a rota entre eles pode passar por ruas comuns, dutos, bueiros ou infraestrutura de meet-me. Uma rede também pode ter equipamentos em ambos os prédios, mas depender de um único roteador de borda, um contrato de upstream ou um provedor de fibra.
Nenhum diagrama público da Connectivity identifica caminhos de entrada, nomes de operadoras, pares de roteadores ou pontos comuns de falha.
O registro da Any2West fornece outra peça do contexto físico. A CoreSite diz que aAny2Exchangeconecta redes em suas instalações e oferece portas em várias velocidades. Uma porta é uma interface real em um switch de troca, acessada por meio de um cross-connect e um roteador de propriedade ou controlado pelo participante. A porta de 1 Gbps listada da Connectivity, portanto, implica pelo menos uma interface de roteador, uma entrega óptica ou elétrica, um caminho de cabo e um relacionamento comercial com a troca ou um fornecedor.
Isso não estabelece um gigabit por segundo de tráfego sustentado, um gigabit de trânsito upstream ou um produto de cliente de um gigabit. A velocidade da porta é a capacidade da interface instalada. O tráfego real depende das sessões de peering, rotas aceitas, política de rede remota, demanda do servidor e a saúde de cada componente entre o aplicativo e a troca. A declaração de tráfego mais ampla de 1 a 5 Gbps do PeeringDB é auto-reportada e mais antiga do que a retirada de roteamento atual. Nenhum dos valores deve ser tratado como capacidade utilizável atual.
A declaração do tribunal de que os computadores host estavam no Condado de Los Angeles está alinhada com essa evidência de instalações. Burbank era o escritório e endereço corporativo; o centro de Los Angeles era a área de interconexão documentada. A distância entre eles é modesta, mas o limite de propriedade é nítido. A Connectivity podia administrar servidores e roteadores, enquanto os proprietários dos prédios, operadores de colocation, operadoras de fibra, o operador de troca e a concessionária de energia controlavam grande parte do ambiente que tornava essas máquinas alcançáveis.
A conta local era uma conta de rack e rota, não uma conta de última milha
Para um ISP de varejo, a conta física dominante geralmente começa na rua: postes, valas, dutos, torres, drops, equipamentos do cliente e técnicos distribuídos pelo território de serviço. A conta documentada da Connectivity começou dentro de um hotel de operadoras. Provavelmente combinava espaço em rack ou gaiola, energia, refrigeração, cross-connects, acesso à troca, transporte metropolitano, trânsito de internet, hardware e mão de obra. Os contratos e valores precisos não são públicos, portanto, os componentes podem ser identificados sem inventar um orçamento.
O rack é apenas a primeira camada. Um servidor que atende o YellowBot precisa de energia e refrigeração. Um switch top-of-rack precisa de um caminho para um roteador de borda. O roteador precisa de interfaces para trânsito upstream ou peers. Cada interconexão requer uma óptica, cabo e sessão configurada. Uma segunda instalação requer transporte entre os locais ou uma cópia independente do aplicativo e dos dados. Um domínio precisa de serviço de nomes autoritativo, certificados e saúde do aplicativo além da própria rede. Se qualquer elemento único for único, o sistema físico pode ser menos resiliente do que o número de fornecedores sugere.
O peering altera a parte variável dessa conta. Quando dois sistemas autônomos trocam tráfego diretamente, eles podem evitar enviar esse tráfego por um caminho de trânsito pago. A CoreSite descreve o peering Any2 como uma forma deencurtar rotas e trocar tráfego diretamente. Para um site de conteúdo, o valor depende do volume de tráfego e de quais redes de consumidores estão presentes. Um ponto de troca cheio de possíveis peers não economiza dinheiro automaticamente. A Connectivity precisava de sessões BGP ativas, proporções de tráfego aceitáveis, demanda suficiente para cada peer e uma rota de fallback para cada destino não alcançado diretamente.
O trânsito permaneceu essencial. O peering público normalmente cobre apenas a rede do peer e seus clientes, não toda a internet. Uma empresa de conteúdo ainda precisa de um ou mais upstreams dispostos a transportar tráfego para todos os outros destinos e propagar seus prefixos. O upstream também transporta solicitações de entrada de redes com as quais a empresa não faz peering. O sistema autônomo se torna publicamente útil apenas quando sua rota é aceita e propagada.
É aqui que a dependência de upstream do título se torna literal. A Connectivity pode ter possuído o registro 199.15.176.0/22 e o roteador que o originava, mas não podia tornar o bloco globalmente alcançável sozinha. Operadoras upstream e peers tinham que aceitar e anunciar caminhos. Filtros, registros de roteamento expirados, mudanças de contrato, uma sessão desabilitada ou uma falha física poderiam fazer com que endereços registrados desaparecessem. A ARIN ainda poderia mostrar o bloco como ativo enquanto os usuários não tinham rota para ele.
O reparo de campo também assume uma forma diferente dentro de um hotel de operadoras. Não há evidências de equipes da Connectivity emendando fibra de bairro. As mãos relevantes substituíriam uma óptica com falha, moveriam um cross-connect, recolocariam uma placa de linha, restaurariam a energia de um gabinete, inspecionariam um patch de fibra ou conectariam um cabo de console. Essas tarefas podem ser realizadas pela equipe da empresa, pela equipe de mãos remotas de um provedor de colocation ou por um contratante especializado.
O tempo de resposta depende da autorização de acesso, peças sobressalentes, pessoal no local e do contrato de serviço, nenhum dos quais aparece no registro público.
O resultado é uma economia física pequena, mas consequente. Uma empresa web pode evitar o enorme ônus de capital de uma construção de acesso regional ao se localizar em um prédio interconectado. Em troca, aceita cobranças recorrentes e concentra o risco operacional em algumas salas, cross-connects e pessoas. A pegada de rede da Connectivity parece ter seguido exatamente essa lógica.
A capacidade registrada e a capacidade utilizável divergiram
Vários valores públicos podem ser confundidos com capacidade: uma alocação /22, uma alocação IPv6 /45, dez prefixos IPv4 alegados, um prefixo IPv6 alegado, uma porta de troca de 1 Gbps e 1 a 5 Gbps de tráfego declarado. Eles descrevem coisas diferentes e não podem ser somados.
Os blocos de endereço descrevem espaço de numeração. O IPv4 /22 contém 1.024 endereços em termos aritméticos, embora o design de rede, reserva, filtragem e atribuições reais determinem quantos podem hospedar serviços. O IPv6 /45 é vastamente maior em contagem de endereços, mas não implica mais taxa de transferência. Endereços identificam endpoints; eles não movem bits sem uma rota.
A porta de troca descreve a taxa de linha superior de uma interface. A sobrecarga de protocolo e a direção do tráfego reduzem a carga útil prática, enquanto a política de peer limita quais destinos podem usá-la. Uma rede de conteúdo pode enviar respostas de saída substanciais e receber solicitações de entrada muito menores, apesar do antigo rótulo de tráfego balanceado do PeeringDB. Uma porta de troca não pode substituir o trânsito a menos que a troca forneça caminhos para todas as redes necessárias sob uma política aceitável.
O número alegado de prefixos é especialmente difícil de conciliar com o histórico observado. Avisão de histórico de roteamento do RIPE para AS53582mostra cinco prefixos de origem ao longo da vida do sistema autônomo: 64.235.248.0/24, 199.15.176.0/22, 207.171.7.0/24, 2607:f238:3::/48 e 2620:101:d000::/45. Alguns eram espaço de endereço de provedor e alguns eram atribuições diretas; eles não estavam todos presentes durante o mesmo período. A contagem de dez mais um do PeeringDB pode ter refletido anúncios operacionais mais específicos, uma convenção de inventário anterior ou informações que nunca foram atualizadas. A observação pública de rotas deve ter precedência para alegações sobre o que era globalmente visível.
A capacidade utilizável também depende do aplicativo. Um diretório web pode ser limitado por consultas ao banco de dados, armazenamento, eficiência de cache ou computação do servidor antes que uma porta de 1 Gbps se encha. Um ataque de negação de serviço distribuída pode esgotar estado, pacotes por segundo ou um limite de proteção upstream enquanto a largura de banda média permanece modesta. Uma única dependência de banco de dados pode interromper o serviço útil enquanto todas as sessões BGP permanecem saudáveis. A capacidade da rede é necessária, não suficiente.
A única declaração segura de capacidade no tempo presente é negativa: AS53582 não tinha espaço de endereço anunciado publicamente observado na visão atual do RIPE. O hardware e contratos antigos podem ter sido desativados, podem permanecer ociosos ou podem dar suporte à conectividade privada que não é visível para coletores públicos. Nenhuma dessas possibilidades cria capacidade IP pública sob AS53582 hoje.
A retirada de rota é o sinal mais claro de status operacional
Aresposta de routing-status do RIPE para AS53582registra a primeira rota observada em julho de 2010 e a última rota observada, 64.235.248.0/24, em 29 de setembro de 2025. Às 08:00 UTC de 10 de julho de 2026, mostrou zero prefixos IPv4, zero prefixos IPv6, zero vizinhos observados e nenhuma visibilidade entre 327 peers IPv4 e 321 peers IPv6 do RIS. Aresposta announced-prefixescomplementar retornou uma lista vazia.
Esta é uma evidência mais forte do estado atual da rede do que um perfil estático de empresa. Coletores BGP públicos não são oniscientes: eles veem rotas recebidas por peers participantes, não sessões privadas ou todos os anúncios de troca local. Uma rota aceita apenas por uma contraparte privada poderia escapar da observação ampla. Uma rede interna privada também pode continuar usando um ASN sem originar espaço público. Mas uma organização que serve sites públicos a partir de seus próprios endereços normalmente precisa que esses endereços sejam visíveis além de um grupo fechado.
Zero visibilidade ampla por mais de nove meses é um rebaixamento substancial.
O histórico de 64.235.248.0/24 ilustra a transferência. Avisão geral do prefixoatual do RIPE mostra que o endereço está sob a rota maior 64.235.224.0/19 originada pelo AS5580, associado à GTT, em vez do AS53582. Isso não identifica os antigos termos comerciais da Connectivity nem explica por que a rota mais específica terminou. Isso mostra que um agregado de provedor pode permanecer alcançável enquanto a origem independente do cliente desaparece.
Os próprios domínios da empresa reforçam a transição sem revelar a arquitetura de origem privada. ODNS público para connectivity.comretorna endereços dentro dasfaixas publicadas da Cloudflare, assim como oYellowBot. Essas respostas colocam a borda web pública atrás de outra rede; elas não revelam onde o servidor de aplicativos reside ou quem o possui. A entrega em nuvem pode continuar enquanto o AS53582 é retirado.
O domínio antigo da Solfo é mais revelador. ODNS público para solfo.comaponta para 199.15.177.178, dentro do /22 registrado pela Solfo. O RIPE mostra que esse /22 não está sendo anunciado atualmente. Um registro de endereço obsoleto não é prova de que toda a empresa está inativa, mas é consistente com uma rede de origem aposentada cujo nome de host legado não foi totalmente limpo.
Seria fácil contar uma história dramática de interrupção a partir dessas evidências, e isso seria exagerado. Não há aviso público de incidente vinculando a retirada de setembro de 2025 a uma falha. Isso pode representar uma migração intencional para hospedagem em nuvem, o fim de um contrato de trânsito, o descarte de equipamentos de colocation, uma mudança corporativa ou um erro operacional. A duração e a borda de terceiros atual tornam a aposentadoria planejada plausível, mas apenas o operador ou seus fornecedores poderiam confirmar a causa.
Para o status operacional, a conclusão medida ainda é firme: a Connectivity tem um site de software ativo, mas seu sistema autônomo registrado separadamente não se apresenta como uma rede pública ativa. A empresa não deve ser tratada como um ISP regional atualmente operante com base em campos antigos de instalações e tráfego.
Seis falhas mostram do que a rede realmente dependia
A ausência de uma rede de acesso não elimina a falha física. Ela concentra a falha em um conjunto diferente de componentes. Seis cenários explicam a superfície operacional com mais precisão do que um corte hipotético em uma rota de fibra residencial.
1. Uma falha de cross-connect ou fibra metropolitana
O roteador da Connectivity precisava alcançar upstreams e Any2West por meio de cabos físicos. Um cabo de patch dobrado, óptica com falha, conector sujo, jumper com etiqueta errada ou fibra do prédio danificada poderia remover um caminho. Uma falha na curta rota metropolitana entre Telecom Center LA e One Wilshire poderia afetar equipamentos em ambos os prédios se o segundo local dependesse do primeiro para trânsito ou acesso à troca.
A recuperação exigiria um identificador de circuito conhecido, medições ópticas, acesso a ambas as extremidades, uma óptica ou cabo de patch sobressalente e coordenação entre a Connectivity, a instalação e a operadora. Duas entradas de prédio não provam duas rotas de rua. A evidência necessária para diversidade seriam cartas de rota de operadora, entradas de prédio separadas, detalhes de risers e confirmação de que os caminhos não se fundem no mesmo duto antes de chegarem a um ponto upstream.
2. Perda de energia ou refrigeração no colocation
Roteadores, switches e servidores param quando sua cadeia de energia falha ou quando a perda de refrigeração força o desligamento. O prédio pode oferecer alimentações de concessionária, energia ininterrupta e geradores, mas o gabinete do locatário ainda pode ter uma única unidade de distribuição de energia, uma fonte conectada a ambas as entradas do dispositivo ou um disjuntor com folga insuficiente. O tempo de execução do gerador também depende da manutenção e do reabastecimento de combustível.
Aorientação de dependência de comunicações da CISAobserva que as instalações de comunicações dependem de eletricidade e de transporte para combustível do gerador de backup. A Connectivity não publicou design de energia do gabinete, arranjo de cordão duplo, tempo de execução da bateria ou evidência de teste do gerador. A presença em um hotel de operadoras proeminente reduz alguns riscos, mas deixa a cadeia de energia exata do locatário desconhecida.
A recuperação começaria com a decisão se a falha está dentro do rack, na suíte de colocation, no prédio ou na alimentação da concessionária. Telemetria remota, identificação de circuito derivado e uma pessoa autorizada no local importam tanto quanto a capacidade de servidor sobressalente. Um serviço pode permanecer inalcançável após o retorno da energia do prédio se um roteador ou servidor não inicializar corretamente.
3. Falha de roteador de borda ou hardware óptico
Um único roteador de borda pode tornar um diagrama multi-homed logicamente impressionante, mas fisicamente frágil. Se todas as sessões de trânsito e peering terminam em um chassi, uma falha no supervisor, fonte de alimentação, placa de linha ou imagem de software remove todas as rotas de uma vez. Dois roteadores em um rack ainda podem compartilhar uma alimentação de energia, switch de gerenciamento ou erro de configuração.
O registro do PeeringDB não identifica a contagem de roteadores. Também não diz se a Connectivity colocou um roteador em cada prédio, usou route reflectors redundantes ou manteve um sobressalente frio. A substituição de hardware requer equipamento compatível, configuração salva, credenciais atuais, acesso ao console e um técnico que possa distinguir o componente com falha de um problema upstream.
Aorientação de planejamento de contingência do NISTrecomenda equipamentos alternativos e locais alternativos como métodos de recuperação. Suaorientação detalhada de telecomunicaçõesinclui especificamente roteadores, switches e limites de propriedade no planejamento de recuperação. A Connectivity não divulga nenhum dos arranjos de recuperação associados.
4. Perda de upstream ou política de roteamento
Um roteador pode estar energizado, conectado e saudável enquanto a internet não tem caminho para seus prefixos. Um upstream pode desabilitar uma sessão por não pagamento, manutenção ou razões de política. Uma rota pode ser rejeitada porque um objeto IRR ou uma autorização de origem de rota está ausente ou é inconsistente. Uma mudança de configuração pode anexar a comunidade errada, anunciar o comprimento de prefixo errado ou retirar a rota completamente. Um provedor pode reter um agregado enquanto a origem mais específica do cliente desaparece, como a visão atual de 64.235.248.0/24 demonstra.
A melhor recuperação não é meramente um segundo nome de upstream. É um segundo upstream com um caminho físico separadamente projetado, anúncios testados, registros de segurança de roteamento válidos e capacidade suficiente para transportar o serviço completo. O operador deve testar se o tráfego realmente converge quando um caminho é retirado. Nenhum registro público do AS53582 identifica upstreams atuais, e o RIPE atualmente não vê vizinhos algum.
5. Congestionamento da troca ou perda de peer
A porta Any2West listada tinha uma taxa de linha de 1 Gbps. Se o tráfego se aproximasse dessa taxa, a perda de pacotes poderia degradar o carregamento de páginas mesmo enquanto a interface permanecesse ativa. Um ataque distribuído ou um pico repentino poderia saturá-la. Um peer poderia reiniciar uma sessão ou alterar a política. O peering público então deslocaria o tráfego para o trânsito pago apenas se essa rota permanecesse disponível e tivesse capacidade sobressalente.
Esta é a diferença entre capacidade instalada e capacidade recuperável. Uma rede com uma porta de troca de 1 Gbps e um circuito de trânsito de 1 Gbps pode parecer ter 2 Gbps, mas não se ambos compartilham uma interface de roteador de 1 Gbps, um circuito metropolitano ou uma entrega de provedor. Da mesma forma, o tráfego projetado para um peer pode fazer failover para um caminho mais longo com maior latência ou folga insuficiente. A antiga declaração de tráfego de 1 a 5 Gbps não revela demanda de pico, utilização da porta ou capacidade de failover.
6. Poucas mãos autorizadas
A Connectivity tinha oito funcionários na Califórnia no registro judicial de 2011, mas esse número é histórico e não identificava técnicos de rede. Empresas de conteúdo pequenas geralmente contam com um fundador tecnicamente habilidoso, um administrador de sistemas e mãos remotas da instalação, em vez de uma organização de campo 24 horas. Isso pode ser eficiente até que um incidente exija trabalho simultâneo em dois locais, uma peça de reposição não mantida localmente ou acesso fora do escopo padrão do fornecedor.
A cadeia de resposta importa. Quem recebe um alarme? Quem pode ligar para o upstream? Quem está listado na lista de acesso da instalação? Onde estão armazenados ópticas, cabos, fontes de alimentação e um roteador de reposição? O técnico pode alcançar ambos os prédios durante um fechamento do centro? A pessoa com credenciais BGP também tem acesso físico? Nenhum registro público responde a essas perguntas.
Mão de obra local nesse contexto significa mão de obra especializada concentrada, não uma frota de instaladores. Uma única pessoa experiente pode entender todo o patrimônio de roteamento e servidores. Esse conhecimento é valioso e também cria um risco de pessoa-chave. A evidência de recuperação incluiria uma escala de plantão, contatos de escalação documentados, acesso de console testado, peças sobressalentes em ambos os locais e um tempo medido para substituir um componente com falha.
Esses seis cenários levam a uma constatação maior. A rede documentada da Connectivity poderia ter sido redundante no nível do protocolo, mas permanecia exposta a prédios comuns, rotas metropolitanas curtas, cadeias de energia e um pequeno grupo de operações. Por outro lado, um design modesto de dois locais poderia ter sido robusto se caminhos, energia e equipe fossem genuinamente independentes. O registro público não apoia nenhuma das alegações. Ele apoia as perguntas.
Os usuários afetados eram usuários de aplicativos, não residências de banda larga encalhadas
O impacto da falha segue o limite do serviço. Quando um ISP regional perde uma rota de acesso, residências e empresas podem perder todo o acesso à internet, serviço de voz e a capacidade de alcançar aplicativos online não relacionados. Quando a rede de conteúdo da Connectivity falhava, o efeito direto provável era a perda ou degradação dos serviços Connectivity, YellowBot, Weblocal ou relacionados hospedados atrás das rotas afetadas. As próprias conexões de banda larga dos usuários continuariam a transportar tráfego para outros destinos.
A escala ainda poderia ser material. O registro judicial de 2011 descreveu milhões de visitas ao YellowBot apenas do Texas e milhares de páginas de negócios locais. O relatório de financiamento de 2014 alegou mais de 92.000 contas empresariais pagas. A venda da divisão de 2016 referiu-se a mais de 20.000 localizações físicas de negócios, e o site atual da empresa alega mais de 10.000 empresas atendidas. Esses números vêm de anos e medidas diferentes e não devem ser combinados. Eles mostram que uma interrupção poderia afetar um público comercial amplo, embora a Connectivity não controlasse a última milha dos usuários.
Falhas diferentes produziriam sintomas diferentes. A perda de um peer poderia tornar o acesso mais lento para clientes de uma rede, enquanto outros usuários não veriam mudança. A perda da rota de origem poderia tornar todos os serviços nos endereços afetados inalcançáveis. Uma falha de banco de dados ou servidor poderia retornar erros apesar do roteamento saudável. A perda de uma borda web pública poderia ocultar uma origem que permaneceu online. A análise precisa de incidentes, portanto, requer evidências de aplicativo, DNS, rota e instalação juntas.
O DNS atual reduz a relevância direta do AS53582 para os sites públicos ativos. Os endereços da Cloudflare respondem por connectivity.com e YellowBot, portanto esses nomes não exigem mais que um usuário encontre uma rota originada pelo AS53582. A origem por trás da Cloudflare ainda poderia depender de um único local ou provedor, mas esse caminho privado não é divulgado. A retirada da rota pode, portanto, ter movido o risco em vez de removê-lo: da interconexão pública operada pela empresa para contratos com uma borda de nuvem e um ambiente de hospedagem não divulgado.
Essa mudança pode melhorar a resiliência se o serviço for distribuído entre regiões e origens. Também pode criar uma nova concentração se cada domínio, servidor de nomes e origem depender de um fornecedor ou conta. Um logotipo em um serviço de nuvem não revela replicação de origem, qualidade de backup ou tempo de recuperação. As evidências públicas são suficientes para dizer que a borda web da Connectivity mudou; não são suficientes para pontuar a nova arquitetura.
O teste de ISP regional falha em todas as camadas da rede de acesso
A FCC descreve uma localização atendível por banda larga como uma residência ou empresa onde oacesso fixo à internet de mercado de massa pode ser instalado. Os provedores informam onde oferecem esse serviço em suas próprias instalações de rede, e oMapa Nacional de Banda Largaé organizado em torno de localizações, tecnologias e velocidades anunciadas. Este é um teste útil para o rótulo de ISP regional mesmo sem depender de uma pesquisa negativa de nome.
A Connectivity não publica arquivo de localizações atendíveis, verificador de endereço ou rótulo de banda larga para consumidores. Não fornece velocidade de internet residencial ou para pequenas empresas, intervalo de instalação, preço de acesso mensal, franquia de dados ou cobrança de equipamento. Não identifica nenhuma tecnologia fibra-até-a-premissa, coaxial, cobre, wireless licenciado ou fixo sem fio não licenciado. Não nomeia nenhuma central local, torre, hub, gabinete ou nó de acesso atendendo clientes.
Também não há área de serviço físico divulgada. Burbank é um endereço corporativo, não uma pegada de banda larga. Los Angeles é um local de hospedagem e interconexão, não uma prova de que prédios próximos poderiam comprar acesso à internet da Connectivity. O escopo América do Norte do PeeringDB descreve onde a rede de conteúdo esperava tráfego ou peers, não onde instalou serviço de última milha.
A evidência de propriedade falha no mesmo lugar. A ARIN prova o controle dos registros de recursos numéricos. O PeeringDB sugere presença em duas instalações e uma troca. Nenhum registro identifica postes, dutos, torres, fibra de rua, drops de cliente ou equipamentos de instalações do cliente. Nenhum registro público revisado aqui mostra a Connectivity possuindo, alugando ou operando qualquer um desses ativos de acesso.
A evidência de mão de obra também diverge. A equipe histórica operava um negócio web; um contratado do Texas mantinha o site YellowBot e outro tratava de questões de atendimento ao cliente. Isso não é evidência de equipes de linha, emendadores de fibra, técnicos de torre ou instaladores. O trabalho de campo implícito pelo sistema autônomo era dentro ou entre prédios de data center, com um regime de segurança, inventário de peças e raio de deslocamento muito diferentes.
Finalmente, a economia não se assemelha ao acesso regional. O financiamento relatado da Connectivity era destinado a uma plataforma de inteligência de clientes, e suas descrições de receita referem-se a publicidade, dados e contas de software. Não há divulgação de passagens de acesso, taxas de adesão, receita média por usuário de banda larga, custos de construção ou subsídios de rede. Chamar a empresa de ISP regional importaria toda uma estrutura de custo e cliente que o registro contradiz.
A classificação mais defensável é a de uma operadora de software e conteúdo com um sistema autônomo histórico. A categoria ISP regional deve ser tratada como um problema de classificação não resolvido, não como um fato a ser repetido.
O que estabeleceria uma rede operacional atual
A lacuna de evidências não é impossível de fechar. Um conjunto conciso de divulgações poderia distinguir aposentadoria, migração e operação privada contínua.
Primeiro, a Connectivity poderia declarar se o AS53582 permanece em serviço e explicar a retirada de rota de setembro de 2025. Se o sistema autônomo está intencionalmente adormecido, a empresa poderia identificar quais serviços públicos foram movidos e se ainda há dependência de clientes nos blocos de endereço registrados. Se for para estar ativo, um anúncio autorizado visível e registros atuais de segurança de roteamento forneceriam a primeira confirmação objetiva.
Segundo, poderia atualizar ou remover os detalhes do PeeringDB. A presença atual nas instalações, o status da porta de troca, a velocidade da porta e a política de peering devem ser datados. Se o equipamento em One Wilshire e Telecom Center LA se foi, deixar os registros marcados como operacionais cria uma falsa impressão. Se permanece, o operador poderia identificar se ambos os locais transportam tráfego de produção ou se um é apenas um local secundário.
Terceiro, alegações de resiliência exigiriam topologia em vez de uma contagem de locais. Fatos úteis incluem o número de roteadores de borda, operadoras upstream, entradas de prédio independentes, provedores de fibra metropolitana e alimentações de energia. Um diagrama não precisa expor endereços sensíveis. Pode mostrar se duas rotas lógicas compartilham um caminho físico e se qualquer uma das instalações pode transportar o serviço completo sozinha.
Quarto, a evidência de recuperação deve declarar quem pode agir. Cobertura de mãos remotas, ópticas e roteadores sobressalentes, autorização de acesso, contatos de escalação e tempos de restauração testados transformam uma lista de instalações em uma capacidade operacional. Um exercício de failover medido é mais informativo do que a palavra redundante.
Quinto, qualquer alegação de serviço de banda larga precisaria de um conjunto de evidências totalmente diferente: uma área de serviço em nível de endereço, tecnologia, termos de instalação padrão, plano de varejo, equipamento do cliente, propriedade da planta de acesso e responsabilidade de reparo de campo. Nada publicado atualmente fornece esse conjunto. Um anúncio de ASN sozinho também não forneceria.
Sinais de mercado não oficiais não podem preencher essas lacunas. Um perfil de rede em cache, um fornecedor de dados de IP ou uma listagem de instalação antiga pode sugerir que uma rede já operou. Não pode provar que o equipamento permanece em um rack, uma conta é paga, uma rota é aceita ou um técnico está disponível. Visibilidade BGP atual, confirmação de instalação e divulgação do operador resolveriam essas questões.
A mesma disciplina se aplica ao negócio de software ativo. Uma página inicial funcionando prova que um serviço web responde. Não prova que a resposta vem de equipamentos de propriedade da Connectivity ou do AS53582. O DNS atual mostra uma borda externa, mas apenas a empresa pode divulgar a origem, replicação e arranjos de recuperação por trás dela.
Uma rota aposentada pode ser mais informativa do que um registro ativo
A Connectivity Inc oferece um aviso útil sobre inferência de infraestrutura. Nomes, categorias e registros de registro descrevem camadas diferentes. O nome sugere uma operadora. As páginas comerciais descrevem software de marketing. A ARIN descreve direitos de recursos numéricos. O PeeringDB descreve uma rede de conteúdo histórica em duas instalações de Los Angeles. O RIPE descreve o que o sistema de roteamento público pode ver agora: nenhuma origem AS53582.
A rede antiga era substancial o suficiente para ser levada a sério. Tinha espaço de endereço registrado diretamente, um sistema autônomo, uma porta de troca de 1 Gbps listada e presença no denso ambiente de interconexão em torno de One Wilshire. Esse arranjo fez um produto web de alcance nacional depender de um conjunto surpreendentemente local de ativos: energia do centro, cross-connects, fibra metropolitana, política de upstream, roteadores, ópticas e mãos autorizadas.
Isso não fez da Connectivity um ISP regional. Não há evidência de uma rede de acesso, assinantes de banda larga, endereços atendíveis, postes, torres, drops ou equipes de instalação locais. As pessoas afetadas por uma falha eram usuários dos aplicativos da empresa, não clientes cuja linha de internet geral ficou inativa.
Hoje, até mesmo essa alegação de rede mais restrita precisa de uma marca de status operacional negativa. A rota pública desapareceu em 2025 enquanto campos antigos de interconexão permaneceram online. As propriedades web atuais da Connectivity podem continuar por trás de infraestrutura de terceiros, mas o AS53582 não deve ser apresentado como ativo até que uma rota, vizinho ou confirmação de instalação atual retorne.
A lição é prática. Infraestrutura instalada não é o que um perfil já listou; são os equipamentos, contratos e caminhos que podem transportar tráfego agora. Capacidade utilizável não é uma alocação de endereço ou rótulo de porta; é a capacidade que sobrevive a uma falha e pode ser restaurada por alguém com acesso e peças sobressalentes. Para a Connectivity Inc, as evidências públicas mostram a conta histórica com clareza suficiente. Também mostram que a rota que antes justificava essa conta não é mais visível.