Faz sentido implantar o OSPF na Metro Ethernet?

Quando preciso conectar vários sites de filial para um cliente, normalmente recomendo uma VPN MPLS por meio de uma operadora confiável. O CE em cada site fala BGP com seu PE upstream e cada site é numerado com seu próprio ASN privado. Isso é muito conveniente para nós, pois o BGP fornece inúmeras ferramentas de engenharia de tráfego e nossas adjacências são limitadas a n + 1 para n sites (o +1 é o nosso ambiente colo).

Ultimamente, no entanto, notei um interesse crescente do cliente em soluções Metro Ethernet. Muitos de nossos clientes têm filiais em uma área metropolitana comum e as cotações da MetroE chegam a várias centenas de dólares (USD) a menos do que o serviço MPLS para circuitos nas mesmas velocidades. Embora isso seja atraente, não sei como estabelecer melhor o roteamento através de um backbone de camada dois, evitando transformar uma topologia de malha em hub-and-spoke.

O BGP exigiria uma malha completa de adjacências entre os sites das filiais para manter a conectividade da malha, o que obviamente é indesejável do ponto de vista da escalabilidade. A outra opção é implantar um IGP, o OSPF, e fazer com que todos os sites formem adjacências na WAN. Gostaria de abordar cada site como sua própria área, o que parece um exagero, mas quero preservar a capacidade de resumir as rotas anunciadas em cada site e isso só pode ser feito nas fronteiras da área.

Isso faz sentido? Há algumas ressalvas a serem observadas ao implantar o OSPF dessa maneira (por exemplo, devo considerar desativar a inundação do LSA)? Ou existe outra solução que eu tenha esquecido?

Essa é uma pergunta complexa, pois os dois produtos diferentes são muito diferentes. Um circuito MPLS L3VPN é inerentemente uma malha completa entre todos os locais que participam, enquanto uma conexão MetroE geralmente é um link ponto a ponto entre dois sites específicos.

Na minha experiência, um circuito MetroE é um caminho provisionado diretamente, sem serviços de proteção, a menos que seja contratado com um caminho de proteção. Isso significa que a falha de uma interface ou roteador ao longo do caminho específico interromperia o tráfego entre os dois sites diretamente vinculados pelo serviço MetroE. O MPLS L3VPN solucionará falhas de interface / roteamento para mantê-lo em uma malha completa entre seus sites. Isso geralmente explica a diferença de preço entre os dois.

Não há nada de errado em criar seus próprios serviços sobre uma plataforma MetroE - você só precisa trabalhar com os requisitos do cliente para determinar que tipo de roteamento é apropriado. Se você estiver trabalhando com uma rede de pequenos escritórios, o OSPF / IS-IS / EIGRP pode ser uma maneira maravilhosa de trocar informações de roteamento entre os sites conectados diretamente que você estabeleceu. Se você é mais um NSP / ISP / * SP, separar a infraestrutura e as rotas do cliente entre IGP e EGP se torna muito mais importante à medida que você escala.

Como engenheiro de ISP, usamos extensivamente os links MetroE e EWAN para construir nosso backbone e utilizamos nosso conhecimento dos links físicos para projetar nosso ambiente iBGP / eBGP. Em muitos casos, usamos refletores de rota e refletores de rota dupla (cliente-refletor de rota em ambos os lados do peering) para reduzir nossa contagem de pares de iBGP. No entanto, a menos que você esteja lidando com mais de 6 roteadores em um POP, o iBGP se adapta muito bem.

Em resumo - se for para um único cliente, isso não está oferecendo serviços de rede para clientes próprios - fique com um IGP. Se a conectividade externa precisar ser compartilhada entre sites, com failover / redundância / etc, examine atentamente os caminhos físicos que você possui e projete seu eBGP / iBGP para refletir isso. Não faz sentido ter um roteador em um local remoto com apenas 1 link fora do site para o iBGP ponto a ponto com todos os outros roteadores no AS - use um refletor de rota dupla.

Mudar de um L3VPN gerenciado (o que eu suponho que você quis dizer com "MPLS VPN") para um L2VPN é um bom passo, pois você pode executar protocolos não IP e obter controle total dos protocolos e plataformas de roteamento que definem seu roteamento topologia.

Supondo que você coloque apenas um endereço MAC Ethernet no lado CPE de cada um dos seus sites, é muito mais simples para o equipamento do provedor aprender e encaminhar 1 endereços MAC por site, do que aprender e rotear potencialmente muitas sub-redes por site.

Em termos de protocolo, essa é uma pergunta difícil de responder sem muito mais informações, pois a melhor opção depende de seus planos de tráfego e crescimento.

Esse é apenas um grande cliente que precisa de conectividade interna e da Internet ou também vende conectividade? Supondo que tudo seja interno, você estará implantando um IGP e talvez executando algum eBGP para anunciar os caminhos.

Se você não tiver muitos sites ou prefixos internos, um protocolo de estado de link como OSPF ou IS-IS faz mais sentido, pois convergirá rapidamente e poderá criar o FIB a partir do RIB rapidamente, se houver apenas alguns prefixos. .

Se você tiver muitos sites ou muitos prefixos, isso começará a tributar suas plataformas de roteamento, pois cada uma delas precisa processar cada uma. Isso é algo que começa a demorar ² vezes. Se você tem sites que surgem e diminuem com frequência, essa rotatividade no estado do link também pode começar a tributar o pool de roteadores.

Se você quiser ter muitos sites, muitos sites grossos (um caminho "upstream", nenhum outro roteador downstream) ou muita rotatividade de rotas, precisará procurar outros protocolos ou topologias.

Em um caso como esse, recomendo usar o BGP com alguns refletores de rota. Dessa forma, você pode provisionar mais de 2 refletores de rota pesados ​​que os raios anunciam e para os quais os outros raios podem pegar uma tabela de roteamento. Dessa forma, você pode implantar CPEs leves em muitos sites de comunicação que acabam de se conectar, anunciar seu espaço e obter uma tabela interna ou rota padrão para um roteador que o faça.

Aproximadamente, sugiro algumas escalas e equipamentos (e assumindo taxas de sub-Gigabit):

• 1 - 20 raios - OSPFv3 entre todos os sites. Juniper SRX240 ou similar para todos os sites.
• 20 - 100 raios - iBGP com refletores de rota. Juniper SRX240 nos raios, Juniper MX5 / 10/40/80 para reflexão de rota (ou Debian Linux / BIRD).
• 100 - 500 raios - comece a dividi-los em diferentes redes L2, ASes ou áreas

Apenas para adicionar dois bits geralmente ignorados à discussão do BGP:

• Se você executar o iBGP, normalmente precisará de outro protocolo de roteamento para estabelecer a conectividade entre os próximos saltos do BGP. Da perspectiva do design, o iBGP é mais uma ferramenta de escalabilidade do que um protocolo de roteamento;
• Se você executa o eBGP, não precisa de uma malha completa de sessões de BGP para otimizar os fluxos de tráfego de ponta a ponta; O processamento do próximo salto do BGP resolve bem esses problemas.

Consulte http://blog.ioshints.info/2011/08/bgp-next-hop-processing.html para obter mais detalhes

Você pode muito bem executar o OSPF (ou outro IGP) em um serviço metro-Ethernet multiponto, e deve funcionar muito bem.

Entretanto, pode haver razões para continuar executando o BGP ... embora eles sejam os mesmos argumentos de por que você também pode querer executar o BGP em sua própria rede.

Você não precisa necessariamente colocar todos os seus alto-falantes BGP no mesmo AS em uma rede de "transmissão" como essa. Pense nisso como uma espécie de IXP interno executado pela telecomunicação, onde seus ASes privados podem se interconectar por meio de uma malha de camada 2. Você não precisaria necessariamente manter uma malha completa de pares de BGP, pois as atualizações do BGP podem dar um salto seguinte na mensagem de atualização que não é a mesma de onde a sessão de pares é proveniente.

Portanto, por exemplo, se você tiver uma malha de camada 2 com os roteadores A, B e C e tiver pares de BGP entre A e B e entre B e C, quando C receber atualizações para rotas originadas em A, será tenha A como próximo salto, mesmo que tenham sido aprendidos durante a sessão de emparelhamento com B. Obviamente, você desejaria mais emparelhamento de rotas do que apenas um único hub-and-spoke, para que você não dependa do único hub, mas você não precisa de uma malha completa por qualquer meio.

Você ainda obtém todos os benefícios da política de roteamento da execução do BGP se o fizer dessa maneira ... e também, como outro entrevistado mencionado, pode usar o mesmo espaço numérico de AS privado e pode até se interconectar com o L3VPN existente para que seu modelo e mecanismos de suporte não precisam mudar.

Dito isto, eu tenho alguns links metro-E (ponto a ponto no meu caso) pelos quais eu corro o OSPF e o iBGP e funciona muito bem.

Que tal uma configuração de servidor de rota com 'spokes' sendo clientes rs dos roteadores hub / principal?

Embora os pares de bgp sejam como uma topologia de hub e spoke, todos os raios devem poder enviar tráfego diretamente para todos os outros.

Você pode até reutilizar os mesmos números AS privados daqueles usados ​​com o provedor MPLS para facilitar a migração de um serviço para outro.

Eu recomendo ler e tomar uma decisão sobre topologias OSPF alternativas, como iniciar como NBMA em vez de padrão. Você logo perceberá que não há como o OSPF selecionar corretamente entre dois caminhos que vão para o mesmo roteador / site na mesma Ethernet do metrô, devido à maneira como o custo é calculado via interface de saída, os links principal e de backup da WAN parecerão os mesmos custo no OSPF padrão. No entanto, se você optar por usar o NBMA, por exemplo, poderá definir manualmente os custos vizinhos - mas agora precisará definir manualmente a malha / adjacências.

Seja o que for que você faça, ROTATE SOBRE ELE NÃO REPETIR NÃO JUNTO NA CAMADA 2, você só está pedindo problemas mais tarde, se precisar de interconectividade da camada 2, use OTV ou outro recurso da camada 2 sobre a camada 3.

Você descobrirá rapidamente que aprenderá muito mais sobre o OSPF (e precisará saber muito mais) do que em comparação com um simples provedor MPLS-VPN em que o núcleo da WAN está oculto.

O OSPF sobre metroE funciona bem, mas você precisa garantir que ele atenda às suas necessidades e que você faça a arquitetura de acordo. Uma ressalva que não vi mencionada é garantir que você saiba o MTU suportado pelo seu provedor. Vi uma queda de MTU em um link metroE durante uma manutenção do provedor, pois o vizinho OSPF não apareceu. Provavelmente apenas um problema, porque eles realmente não suportam jumbo-frames, mas sim para nós :) Ser gentil às vezes não compensa.