Isso pode ser visto como muito fácil para alguns de vocês, mas vamos fazer uma pequena filosofia, o que significa que vamos projetar em torno do roteamento ideal.
Os engenheiros de rede sabem que uma das vantagens do projeto de rede é o roteamento ideal. Queremos que o tráfego de nosso aplicativo siga o roteamento ideal, certo?
Não exatamente certo. Vou explicar por que nem sempre é certo, mas vamos entender exatamente o que queremos dizer com "Roteamento ideal".
Com base em qual parâmetro de otimização estamos procurando?
A resposta a esta pergunta é a métrica IGP. Da origem do tráfego ao destino, entre os nós da rede, custo cumulativo/total. Pode ser protocolo de Camada 2 ou Camada 3, preferimos o caminho mais curto. O caminho mais curto, na maioria das vezes é calculado com base na “largura de banda”. Assim, no geral, qual caminho fornece mais largura de banda, esse caminho é considerado o caminho mais curto, portanto, Roteamento Ideal.
Este não é necessariamente sempre o caso, por exemplo, o BGP usa o comprimento AS-Path mais curto, não a largura de banda para roteamento entre domínios, mas OSPF, e o IS-IS, por exemplo, observe a largura de banda total para o cálculo de custo dentro do domínio/AS.
Alguns de vocês podem pensar que, além do custo IGP mais curto, talvez a distância física mais baixa (geralmente chamada de distância por milha de fibra) ou o custo monetário mais barato que possamos usar para fins de otimização, vocês estão certos. Você pode ter um caso de negócios válido para isso e, de fato, temos soluções técnicas para fazer isso.
RSVP-TE e engenharia de tráfego baseada em roteamento por segmentos fornecem funcionalidade para você ter diferentes políticas na rede.
Como entendemos que o roteamento ideal é considerado principalmente como o custo IGP cumulativo mais curto entre os nós da rede de origem e de destino, vamos falar sobre por que talvez não queiramos enviar o tráfego pelo caminho que fornece otimização.
A imagem acima é famosa como "Diagrama/Topologia de Peixe"
A razão é; que parece um peixe, mas para nós é importante entender que com esta topologia básica, podemos entender por que podemos precisar de engenharia de tráfego.
Se cada interface entre os roteadores tiver a mesma métrica IGP, entre os roteadores de origem e de destino na topologia acima, sempre o caminho superior será escolhido devido à métrica IGP cumulativa/total mais curta.
O caminho inferior não seria usado se confiássemos nos protocolos de roteamento IGP para a seleção do caminho.
Se quisermos utilizar o caminho inferior para parte do tráfego de nosso aplicativo, precisaremos de mais do que funcionalidade de roteamento IGP. RSVP e roteamento por segmentos fornecem capacidade de engenharia de tráfego, mas esses não são os tópicos desta postagem.
Quando começamos a fazer Engenharia de Tráfego, estamos na verdade aceitando fazer “Roteamento Sub Ótimo”.
Enviamos apenas parte do nosso tráfego pelo custo IGP mais curto (lembre-se de nossa definição de roteamento ideal) e, intencionalmente, enviamos algum outro tráfego por um caminho de custo IGP mais longo, que é o caminho de roteamento subótimo.
A propósito, o caminho mais curto de custo do IGP não precisa ser um caminho mais barato em termos monetários, ou pode não ser o caminho de menor atraso, etc.
Você pode ter um link de satélite com a órbita GEO, que vem com latência de mais de 500 ms, mas pode ter mais largura de banda em comparação com outro caminho.
Deixe-me resumir.
- Usamos o Optimal Routing para definir o caminho de custo IGP mais curto.
- Este caminho pode não ser o caminho ideal de acordo com sua política
- O roteamento ideal pode não ser desejado para todos os seus aplicativos ou tráfego de serviço
- Tecnologias como RSVP e Roteamento por Segmento são usadas para Engenharia de Tráfego que viola intencionalmente o Caminho de Roteamento Ideal
- Enviamos intencionalmente parte do tráfego de nossos aplicativos pelo caminho de roteamento abaixo do ideal, mas esse caminho satisfaz a restrição dos aplicativos que se sobrepõem a esse caminho
- Não existe uma resposta correta para todos os requisitos de rede!
Se você gostou deste post e gostaria de ver mais, por favor me avise na seção de comentários abaixo. Compartilhe suas idéias para que eu possa continuar escrevendo outras semelhantes.