Configurando o Direct Link on Classic

Configurando o Direct Link on Classic

Configurando o Direct Link on Classic

Após a conectividade do seu IBM Cloud® Direct Link on Classic ser estabelecida, será possível seguir as etapas que são dadas neste documento para configurar sua sub-rede a fim de interagir com o IBM Cloud.

Em geral, para que a sua conexão do Direct Link on Classic funcione, deve-se fazer algumas etapas básicas de configuração de rede e, em seguida, configurar o Protocolo de Roteamento de Borda (BGP). Durante o processo de instalação, um engenheiro da IBM trabalha com você para permitir que sua rede use a capacidade de Virtual Routing Function (VRF), o que é necessário.

Configuração básica de rede

  1. Defina sua rede remota que usa o espaço de endereço privado RFC1918 padrão.

    • Para novos ambientes, o espaço 10.0.0.0/8.
    • Para ambientes existentes que usam o intervalo de endereços 10.0.0.0/8, recomenda-se que você obtenha uma avaliação mais detalhada para garantir que não haja conflito com a rede de serviços IBM Cloud ou com as redes já atribuídas à sua conta. Essa recomendação só se aplica se uma rede Classic estiver conectada a Direct Link ou a um Transit Gateway que também esteja conectado a uma rede Classic. Se o seu ambiente usa apenas a infraestrutura VPC, isso não se aplica.

  2. Nossa equipe em IBM Cloud atribui uma rede /31 ou /30 para cada conexão e configura um endereço IP de interface na infraestrutura do roteador de conexão cruzada (XCR) IBM Cloud. No entanto, nossa equipe não configura conexões Direct Link 2.0. Para Direct Link 2.0, o cliente seleciona e configura as redes necessárias durante o processo de pedido.

  3. Configure a interface no seu customer edge router (CER) usando o endereço IP fornecido: use o IP do XCR do IBM Cloud como um próximo hop para qualquer tráfego que esteja destinado ao IBM Cloud.

  4. Para o tráfego de retorno, o IBM Cloud usa o IP de CER designado como um próximo hop para qualquer tráfego destinado à rede remota, como anunciado via BGP.

Configurando o BGP

Para trocar informações de rota com seu ambiente, o IBM Cloud requer que o BGP seja configurado. As opções são as seguintes:

  • ASN: o IBM Cloud designa um ASN privado para cada uso do cliente. Como alternativa, é possível usar o seu próprio ASN público. Sua preferência é solicitada no momento em que faz seu pedido. Seu ASN privado designado é fornecido para você durante o processo de implementação.

  • VRF: usando VRF, o IBM Cloud divulga as sub-redes privadas específicas que são designadas para a sua conta de cliente. Deve-se anunciar as redes remotas que deseja que sejam alcançáveis por meio da rede privada do IBM Cloud. É sua responsabilidade como cliente gerenciar as propagandas para e da rede do IBM Cloud. (Mais detalhes sobre o VRF estão incluídos na próxima seção).

    As redes a seguir são filtradas e não podem ser aceitas: 10.0.0.0/14, 10.198.0.0/15, 10.200.0.0/14, 169.254.0.0/16, 224.0.0.0/4.

Especificações do BGP para o IBM Cloud Direct Link

As especificações do BGP são as seguintes:

Conforme indicado na seção anterior, o BGP é obrigatório para gerenciar seu roteamento por meio do Direct Link. Uma conta que pede o Direct Link é migrada para um ambiente de VRF.

Um cliente deve anunciar seu ponto de extremidade do túnel GRE em IBM Cloud para que esse endereço IP seja acessível a partir de ambientes IBM Cloud. O endereço IP diretamente conectado nem sempre está instalado nas tabelas de roteamento do site IBM Cloud.

Ressalvas para VLANs e VRF:

  • A ampliação de VLAN entre contas não é permitida no ambiente de VRF.
  • O serviço de VPN IPsec é limitado.

O VRF não impede o acesso de VPN de SSL, mas o comportamento muda. Sem o VRF, uma conexão VPN é suficiente para ver todos os servidores em sua conta. Com o VRF, é possível acessar recursos apenas no mercado que está associado à sua VPN. Assim, se você se conectar à VPN de DAL, poderá se conectar a servidores DAL apenas.

O ASN do IBM Cloud é 13884, para serviços públicos e privados.

  • O ASN padrão para um cliente ao pedir é 64999, mas o padrão pode ser mudado por solicitação do cliente.
  • Opcionalmente, um ASN privado de 4 bytes 4201000000- 4294967294 pode ser suportado.
  • ASNs excluídos: 0, 13884, 36351, 64512, 64513, 65100, 65201-65234,65402-65433, 65500 e ASNs de 4 bytes: 4201065000-4201065999
  • Se você está usando o Direct Link Connect com um serviço de camada 3, como VPN de IP, o IBM Cloud estabelece BGP com o ASN do provedor do Direct Link Connect.

** Recomendações, Padrões e Limites: **

  • O tunelamento (ou seja, GRE) será suportado e recomendado se a sobreposição de IP se tornar um problema.
  • Os padrões de cronômetro de BGP são Keepalive:30, Holdtime:90.
  • A autenticação não é ativada por padrão.
  • O BFD do BGP não é ativado por padrão.
  • O limite máximo de prefixo recebido (do cliente ou provedor) é de 200 por VRF.

Limitações estritas em designações de IP

  • Se você usar a rede 10.x.x.x, ainda não poderá criar sobreposição com seus hosts em IBM Cloud nem com a rede de serviços IBM Cloud, que ocupa 10.0.0.0/14, 10.198.0.0/15 e 10.200.0.0/14. Essa limitação se aplica apenas ao Classic, não ao VPC.

  • Os intervalos a seguir não são permitidos no sistema Federal e eles são rejeitados por servidores IBM: 169.254.0.0/16, 224.0.0.0/4.

Redundância e diversidade

O IBM Cloud Direct Link fornece diversidade e os clientes são responsáveis por implementar a redundância por meio de seus esquemas do BGP.

Compreensão das decisões de encaminhamento do BGP

IBM Cloud O BGP Routing and Forward varia de acordo com a implementação do fornecedor no local. Isso é fundamental para entender como você configura seu equipamento local para trabalhar com Direct Link. O não entendimento e o não planejamento podem resultar em comportamentos indesejados, como caminhos de roteamento assimétricos ou escolhas de roteamento preferenciais incorretas. A tabela a seguir está ordenada da mais importante para a menos importante. Isso se aplica a caminhos únicos. O uso de vários caminhos altera esse comportamento. Siga o guia de configuração do roteador para saber se há desvios em relação a essas regras gerais.

Figura 1.BGP
Considerações sobre o BGP Significado Valor preferencial
Próximo salto alcançável O BGP não selecionará uma rota com a qual não possa se comunicar. N/A
Peso (somente Cisco) Métrica específica da Cisco para preferir um caminho. Preferencial de maior valor
Local_Pref Métrica independente do fornecedor para preferir um caminho. Preferencial de maior valor
Rotas injetadas localmente Se o seu roteador estiver originando as rotas, prefira-o a iBGP/eBGP. N/A
Comprimento do caminho AS Número de ASs pelos quais uma rota deve passar. Valor mais baixo Preferido
Origem Qual protocolo originou a rota. O BGP interno tem preferência sobre o BGP externo
MÉDIO Multi Exit Discriminator, que pode preferir um caminho de saída entre ASs. O valor mais baixo é o preferido
Tipo de vizinho Qual é a relação de protocolo entre dois ASs? Preferir BGP interno a BGP externo
Métrica IGP Qual era a métrica IGP da rota? O valor mais baixo é o preferido
Idade da rota Qual é a idade das rotas? Preferir a rota mais antiga

Mais sobre o uso do VRF

Todas as contas que usam uma solução do IBM Cloud Direct Link devem migrar para um VRF. Para obter mais informações, consulte Perguntas mais frequentes sobre a migração da conta do VRF

Usando o VRF, os clientes anunciam as rotas disponíveis para suas redes remotas autodefinidas. Essa configuração não permite que você use endereços IP autodefinidos na rede do IBM Cloud.

A migração para um VRF requer uma janela de interrupção curta (até 30 minutos para contas grandes com várias VLANs/localizações), durante a qual as VLANs da rede de back-end perdem a conectividade mútua enquanto são movidas para o VRF.

O VRF elimina a opção "Ampliação de VLAN" por sua conta, incluindo qualquer capacidade de ampliação da VLAN de conta para conta, pois todas as VLANs são capazes de se comunicar, a menos que um dispositivo de gateway seja introduzido para gerenciar o tráfego. O VRF também limita a capacidade de usar os serviços de VPN do IBM Cloud porque ele não é compatível com os serviços de SSL e VPN de IPsec do IBM Cloud.

Uma alternativa é usar a própria oferta do IBM Cloud Direct Link para gerenciar os seus servidores ou executar a sua própria solução de VPN (como um Vyatta) que pode ser configurado com diferentes tipos de VPN. Após migrar para um VRF, a VPN SSL geralmente funciona quando uma conexão VPN é estabelecida no mesmo local do data center no qual uma VM de cálculo está em execução, mas não permite acesso globalmente.

Usando BYOIP e NAT com o Direct Link

O IBM Cloud Direct Link não oferece BYOIP na rede privada. Portanto, o tráfego com um endereço IP de destino que não foi designado por IBM Cloud é eliminado. No entanto, os clientes podem encapsular o tráfego entre a rede remota e sua rede do IBM Cloud que usa GRE, IPsec ou VLAN.

Mais comumente, o ambiente BYOIP é implementado dentro do escopo de uma implementação do Network Gateway (Vyatta) ou NSX do VMWare. Essa configuração permite que os clientes usem qualquer espaço de IP desejado no lado do IBM Cloud e roteiem de volta através do túnel para a rede remota. Essa configuração deve ser gerenciada e suportada pelo cliente, independente do IBM Cloud. Além disso, essa configuração poderá quebrar a conectividade com a rede de serviços do IBM Cloud se o cliente designar um bloco 10.x.x.x que o IBM Cloud utiliza para serviços.

Esta solução também requer que cada host que precise de conectividade com a rede de serviços do IBM Cloud e a rede remota deve ter dois endereços IP designados: um do bloco IBM 10.x.x.x e um do bloco de rede remota. As rotas estáticas devem ser configuradas no host para garantir que o tráfego seja roteado. Não é possível designar espaço de IP diretamente nos hosts do IBM Cloud (BYOIP) e tê-lo roteável na rede do IBM Cloud inerentemente. A única maneira de implementar essa capacidade é conforme descrito anteriormente, mas esse processo não é suportado pelo IBM Cloud.

Como alternativa, os clientes frequentemente designam um bloco de rede remota para uso em uma tabela NAT que esteja configurada em seu roteador de borda remota. Essa configuração permite que os clientes limitem as mudanças que são necessárias para ambas as redes, enquanto ainda convertem o tráfego em um espaço de endereço de rede compatível com ambas as redes.