Recomendações para simplificar a migração de sistema operacional
Ontem, 12 de agosto de 2014, a internet atingiu um limite arbitrário de mais de 512K rotas . Este limite de 512K rota é algo que sabe sobre isso há algum tempo .
A correção para dispositivos Cisco - e possivelmente outros - é bastante simples . Prestadores de serviços de Internet e empresas de todo o mundo optou por não abordar esta questão com antecedência, como resultado causando grandes interrupções em todo o mundo.
Como parte da paralisação, os apostadores experientes irregular - ou mesmo nenhum - conectividade com a internet e perdeu o acesso a todos os tipos de serviços baseados em nuvem. A queda de LastPass está sendo acusado por muitos de 512KDay, embora a confirmação oficial deste ainda está pendente. Tenho vindo a seguir relatórios de incapacidade de acessar os serviços de nuvem, como o Office365 através de fenômenos mais localizados ao redor do mundo, muitos dos quais parecem muito com eles estão relacionados 512KDay.
Como exemplo deste último, enquanto eu ainda não ter a confirmação oficial ainda da canadense ISP Shaw, todas as indicações são de que a "doença encaminhamento mistério" que afetou sua rede (e que continua no momento da publicação) pode estar relacionado com o questão "512KDay".
Parece que os problemas que eu experimentei com Shaw é provável até roteadores dentro Shaw bater o limite de 512K. Esses roteadores atingiu o número mágico e, em seguida, foram incapazes de protocolos rota individuais (como RDP, por exemplo, embora não possamos confirmar isso é assim no caso de Shaw) para os (DPI) sistemas de inspeção profunda de pacotes que o ISP usa para criar um " pista lenta "melhorar a nossa experiência de internet *.
Como a correção para estas questões pode variar de "aplicar um patch ou configuração alteração e reiniciar uma peça central da infra-estrutura de rede crítico" para "comprar um novo widget, a demanda para a qual acaba de bater pico" não há qualquer chance de que as questões 512KDay vontade continuar por alguns dias (ou mesmo semanas) ainda está por vir.
Outros ao redor do mundo têm visto os problemas também. Considere os problemas relatados por Jeff Portador de Sistemas AVERE que diz "meu firewall começou notando perda de pacotes entre ele e seu roteador upstream. Ele não era tão ruim, até os funcionários começaram a aparecer para o trabalho, mas depois ficou em pé um pouco. Nós não tem nenhuma evidência real, mas eu fiz ir e voltar com as várias vezes ISP. Parece que ele provavelmente era [o evento 512KDay] que causou isso. "
Consciência
Portador faz uma pergunta crucial: "Por que não foi isso na imprensa, como Y2K ou IPv4?".
Talvez este seja o fantasma do Y2K. Globalmente, lidamos com os problemas reais colocados pelos computadores, sendo incapaz de compreender a passagem do milênio tão bem que o apostador médio não percebeu os poucos sistemas que não são atualizados. IPv4 tem sido um apocalipse altamente divulgado que se arrasta há mais de uma década ea internet ainda tem de entrar em colapso.
512KDay é simplesmente "mais uma questão limite arbitrário", que tem sido há anos arquivados ao lado do famoso Y2K, IPv4 ou 2.038 problemas. Se você estiver interessado em algum dos outros, a Wikipedia tem um breve resumo desses "tempo de formatação e armazenamento de bugs" que explica as grandes, mas não tem uma listagem para todos os conhecidos.
Não a mídia ter parte da culpa? Talvez. Eu tenho visto problemas 512KDay levantadas em muitos artigos IPv4 ao longo dos anos, mas raramente isso foi discutido em uma publicação importante como um problema em si mesmo. Talvez este seja um exemplo de fadiga crise trabalhando o seu caminho para a esfera tecnológica: como temos pressa de um fabricado "crise" para outro, deixamos de ter espaço e recursos do cérebro para lidar com os problemas reais que enfrentamos.
O dedo da culpa
Uma coisa que eu sei é que é o trabalho dos administradores de rede para saber sobre estas questões e lidar com eles. O que não foi na grande mídia tem sido no específico da rede imprensa especializada, na documentação do fornecedor e muito mais.
Fui contactado por centenas de administradores de rede nas últimas 12 horas com contos de aflição. O traço comum entre eles é que absolutamente fez levantar a bandeira sobre isso, com praticamente todos eles sendo orientados a deixar a visão do chefe de cabelos pontudos imediatamente.
Com base nas evidências até agora, eu absolutamente não aceitam o sacrifício inevitável de alguns sistemas de administrador júnior para as massas latindo. Jogando nerds sob o ônibus não cortá-la. O dedo de pontos culpa diretamente a ISPs e outras empresas que usam roteadores BGP indevidamente em toda a Internet.
É fácil fazer um boogyman de ISPs; eles estão entre os mais odiados indústrias do mundo, depois de tudo. É fácil apontar o dedo da culpa em empresas que optaram por não atualizar sua infra-estrutura, porque eu passei a vida inteira lutando aquela batalha do coalface e ele me fez uma pessoa amarga e rancorosa.
Não é problema meu
Infelizmente, apesar de toda angústia anti-corporativa compreensível que eu poderia manter, 512KDay era completamente evitável e - marque minhas palavras - este é o começo, não o fim.
Outro problema iminente é IPv6. Milhões de pequenas e médias empresas utilizam hoje dois links de internet e um simples roteador IPv4 NAT para fornecer redundância e failover. Tudo atrás do roteador NAT mantém o mesmo IP; apenas a borda IP muda se as coisas correrem em forma de pêra.
Com o IPv6 NAT funcionalmente proibido pelos tipos de torres de marfim que projetaram o protocolo, atualmente, não existe uma solução elegante para isso em IPv6 . Doutrina existente afirma que as PMEs devem simplesmente obter um número de AS, obter a sua própria sub-rede e, em seguida, gerenciar e manter seus próprios roteadores BGP, anunciando rotas para ambos os provedores.
Deixando de lado por um momento que a maioria dos ISPs voltado para o SMB não vai permitir que BGP através de ligações de baixa margem, as questões 512KDay acima devem demonstrar adequadamente que o próprio conceito é completamente batbleep bleeping insano.
As maiores empresas do mundo - fornecedores e serviços de internet em todo o mundo - não conseguiu ouvir os engenheiros de rede mais bem treinados do mundo. Automatizado empório rosquinha e orientada para a internet robobakery de Dolly não vai ter talento ou recursos em qualquer lugar perto o que essas organizações têm para oferecer.
Oh, há propostas nesse estado "em um mundo perfeito, onde todos joga fora a cada computador, roteador e aplicação que têm, tudo vai entender o conceito de múltiplos endereços, múltiplos caminhos e redundância. Supondo que todos concordamos com esta RFC e, em seguida, implementar que. " Nós não temos todos concordaram em um RFC, e quem acha que o mundo está lançando toda a sua base instalada de TI para alcançar em IPv6 que foi um-e-esqueça fogo $ 150 dual-porta WAN sob IPv4 está latindo louco.
Alternativamente, poderíamos abandonar a idéia de manter endereço coerência interna às nossas redes completamente e tornar-se total e completamente dependente do DNS, mesmo integrante de nossas próprias redes e até mesmo para esses pedaços críticos de nossa infra-estrutura como a gestão básica e ferramentas de diagnóstico.
E se tudo desabasse?
Dependência DNS absoluta é loucura. DNS faz falhar. Mesmo se você estiver feito de certificações de super-macho e ter cred lerdo que ondulações como os músculos de um super-homem-abusando de esteróides no ginásio. Ele falha para os mesmos tipos de razões que nos 512KDay bit em nossa proverbial coletiva: erro humano.
Os seres humanos cometem erros. Nós fazemos a chamada errada. Nós não gastar dinheiro onde devemos e podemos gastar dinheiro onde não deve. A aprendizagem é 20/20 ea previsão muito mais obscuro, e às vezes tomamos o que achamos que é um "risco aceitável" só para ter que vir a ser a coisa que nos morde.
Se 512KDay deve nos ensinar alguma coisa, é que nenhum ponto único de falha é aceitável, não importa o tamanho do seu negócio. No entanto, também temos de ter em mente que nem todas as empresas são empresas da Fortune 500, com o PIB de Brunei para gastar em rede a cada ano.
Se você apostar sua empresa na computação em nuvem para ser a coisa que lhe permite operar, havia uma boa chance de que 512KDay foi um banho de água fria da realidade em relação às promessas de marketing lisas de confiabilidade imbatível e 24/7 disponibilidade. O que é bom nada nuvem se a rede ligando-o a falhar?
Na mesma linha, a série de más escolhas e piores para pequenas e médias empresas que buscam implementar IPv6 vai levar muitos deles a escolher pontos únicos de falha, mesmo que eles não querem. Confiança absoluta no DNS ou um único ISP poderia custar-los no futuro.
O que dizer das outras vulnerabilidades ainda desconhecidas? Limites arbitrários e as decisões de design-a-fiat que simplesmente dizer pedaços significativos (mas geralmente não abastados) do mundo para fazer uma caminhada? Será que nós, como uma indústria, aprender alguma coisa com 512KDay, ou vamos continuar ao longo como se nada estivesse errado, culpando ninguém e todos, exceto aqueles que realmente têm a capacidade de afetar a mudança?
Deixo-vos com uma citação de Upton Sinclair: "É difícil fazer um homem entender algo quando seu salário depende de ele não entender isso."
512KDay era evitável. Será que vamos escolher para evitar o próximo? Respostas nos comentários, por favor. ®
* Para o registro, usando DPI em sessões RDP é apenas rude. El Reg observa que não podemos confirmar esta é uma prática de Shaw. Pedimos colocar várias perguntas para a empresa e será atualizado quando ouvimos mais.
Veja rotas em tempo real de CIDR aqui .