OSPF ou iBGP para protocolo de roteamento interno?


8

Portanto, o plano é dois roteadores principais, cada um com uma sessão eBGP, para um dos dois ISPs com rotas completas. Ambos os roteadores publicam suas tabelas completas um para o outro, para que possam controlar o fluxo de tráfego de maneira mais inteligente via iBGP.

Por uma questão de argumento, três roteadores de acesso têm um caminho para cada roteador principal. Eu estava indo para configurar o iBGP e publicar uma rota padrão de cada roteador principal, para que eles tenham alguma resistência contra falhas de hardware e usem filtros para controlar quais rotas são realmente enviadas aos dispositivos de acesso.

Ouvi dizer que as pessoas usam o OSPF para o IGP em geral, é claro que há um elemento específico para o caso.

Minha pergunta é: Qual seria o benefício de substituir o iBGP pelo OSPF?


Alguma das respostas o ajudou? Nesse caso, você deve aceitar a resposta para que a pergunta não apareça para sempre, procurando uma resposta. Como alternativa, você pode responder sua própria pergunta e aceitar a resposta.
Ron Maupin

Respostas:


10

O iBGP requer uma malha completa ou uso de mitigação, como confederações ou refletores de rota, o BGP não converge com nada como a velocidade do OSPF, etc.

Cada roteador OSPF teria um entendimento completo de todas as rotas existentes na área em que reside, sem a necessidade de uma malha completa, e converge muito, muito rapidamente.

O uso de um IGP é recomendado com o iBGP. Sem o IGP, o iBGP deve vizinho nas interfaces externas, com um IGP, o iBGP pode vizinho nas interfaces de loopback que nunca caem e pode ter vários caminhos a serem alcançados.

Vi o iBGP-only para roteamento local, mas é mais difícil e frágil.


7

Primeiro, eu contestaria a afirmação de que outros fizeram que o OSPF converge mais rápido que o BGP, mas mais sobre isso mais tarde. Para responder à pergunta do OP primeiro.

Você quer os dois.

O iBGP foi projetado para rodar entre interfaces de loopback nos roteadores e (pelo menos sem alterar e girar alguns botões) não altera nenhum atributo (incluindo o salto seguinte) das rotas que está anunciando.

Então, quais são as implicações disso?

Vamos chamar o roteador de borda de roteador A e B e os três roteadores de acesso sem argumentos como roteador 1, roteador 2 e roteador 3.

Os roteadores A e B recebem feeds completos da Internet dos seus upstream, com o próximo salto definido para o endereço da interface do upstream no link de interconexão. Quando essas rotas são transmitidas via iBGP, novamente, a menos que você ajuste, o próximo salto da rota que os roteadores 1, 2 e 3 recebem ainda é o endereço IP no lado oposto do link de interconexão.

Os roteadores farão uma pesquisa recursiva para encontrar o caminho para esse endereço IP e, em seguida, usarão o salto seguinte quando a rota estiver instalada na tabela de encaminhamento. "Mas", você diz, "eu vou usar o self do próximo salto". Veja o próximo parágrafo para saber como isso funciona.

"Mas", você também pode dizer: "Estou apenas com padrões de publicidade nos roteadores 1, 2 e 3." OK, mas essa rota padrão tem que vir de algum lugar ... se já é um padrão já existente (digamos, estático), ele terá um salto seguinte que será usado. Se for um padrão gerado ... provavelmente usará o endereço de loopback no qual a sessão do iBGP está sendo executada como o próximo salto. Novamente, isso não será visto como uma interface ou rota diretamente conectada nos roteadores 1, 2 e 3, portanto eles ainda terão que fazer uma pesquisa recursiva para encontrá-lo.

Portanto, você precisa de algum tipo de IGP em execução, como OSPF, IS-IS ou EIGRP, ou até mesmo muita estatística estática para gerenciar, para que a acessibilidade funcione nas pesquisas recursivas.

"Mas", você diz novamente, "executarei as sessões do iBGP nos endereços da interface em vez dos loopbacks. OK, mas agora sua sessão de peering do BGP depende da interface estar" pronta "para funcionar. Portanto, por exemplo, se a interface entre o roteador 1 e o roteador A cair, a sessão de peering do iBGP será executada nessa interface, mas o roteador 1 ainda poderá enviar tráfego ao roteador A, mas apenas pelo roteador B. Então, você deseja que a sessão do iBGP permaneça ativa, mesmo quando essas interfaces caírem, porque seu próximo salto final ainda está além, e além disso ainda é alcançável por outro caminho ... OSPF (eu uso OSPF, mas você pode sub- IS e EIGRP em qualquer lugar que você veja o OSPF aqui) descobrirá esse outro caminho interno e cuidará de criar a tabela de encaminhamento corretamente nessa pesquisa recursiva.

Então, sim, você provavelmente pode ajustar botões suficientes e fazer com que uma configuração pura do iBGP funcione sem nenhuma configuração do IGP ... mas, por favor, não ... será muito trabalho, quase certamente será flakey.

Faça um favor a si mesmo e ative OSPF, IS-IS ou mesmo EIGRP se você é uma loja da Cisco pura (mas, por favor, considere se você realmente deseja aceitar esse aprisionamento de fornecedores, se o fizer ... considere possíveis decisões futuras para usar equipamentos de outro fornecedor ... mesmo que seja apenas para tentar manter a Cisco honesta nos preços com você). Ative-o para todas as suas interfaces entre seus roteadores e também configure-o na sua conexão upstream com a configuração passiva e, provavelmente, nos downstream dos seus roteadores de acesso com a configuração passiva. Em seguida, configure seus pares de iBGP entre seus loopbacks. Considere refletores de rota (provavelmente nos roteadores A e B) para reduzir o esforço de configuração necessário ... faz sentido em cerca de 5 roteadores começar a fazer isso.

É realmente a melhor maneira de fazer isso.

Agora, para protocolar velocidades de convergência.

A maioria das pessoas pensa que o BGP é lento e o OSPF (ou o que for) é rápido devido aos casos de uso comuns desses protocolos. As pessoas tipicamente puxam a Internet completa, ou pelo menos uma fração significativa dela, para o BGP, enquanto lidam apenas com rotas internas no OSPF (10s a 100s, talvez nas milhares de rotas baixas). Então, vamos supor que você esteja inserindo metade das rotas da Internet no BGP ... tente criar uma área OSPF com mais de 250.000 rotas e deixe-me saber como isso se aplica a você. Vamos ver se isso converge mais rápido que o BGP ... ou nunca, a menos que você tenha um plano de controle realmente robusto em seus roteadores.

O BGP, para uma determinada situação, pode convergir ou reconvergir frequentemente, mais rápido que o OSPF e outros, pelo menos dependendo de como você o mede. Se você incluir a descoberta de vizinhos do OSPF em uma rede de transmissão, é quase certo que o BGP vencerá por uma mistura semelhante de rotas.

A outra diferença é que o BGP começará a colocar rotas nas tabelas de roteamento e encaminhamento antes de sua (re) convergência final, o que pode ser um benefício, enquanto as implementações do OSPF quase certamente esperarão até o final antes de começar a colocar rotas nas tabelas de roteamento e encaminhamento . Às vezes, ter um conjunto de rotas parcial convergido pode ser útil. Às vezes não.


11
Eu acho que você está tornando isso mais complicado do que o necessário., Embora eu não discuta seus comentários em geral, neste caso, não há nada a ganhar com a adição de um IGP. Nesse cenário, o BGP anuncia uma rota padrão para os roteadores de acesso. Não importa se é uma rota interna ou externa. O tráfego está indo para o roteador A ou o roteador B. A adição do OSPF não tornará isso mais fácil ou rápido. Usando um endereço de auto-retorno para o peering iBGP não comprar muito, se você está anunciando uma rota padrão .-- se o link para um vai para baixo, não há nenhuma razão para enviar tráfego para A.
Ron Trunk

Mesmo que A seja o melhor caminho de saída, o tráfego ainda chegará lá via B. Isso é verdade se você usar o iBGP com um loopback, na interface ou usar um IGP.
Ron Trunk

11
Você não está errado, mas precisará ter algum tipo de "IGP", mesmo que esse "IGP" seja uma estática manual para o loopback do roteador A (e B). E, admito, estou bastante à vontade executando o BGP e o OSPF, então gostaria de configurá-lo para algumas provas futuras (ou seja, existem alguns argumentos muito bons para permitir que essas rotas da Internet atinjam os roteadores 1, 2 e 3, portanto eles podem tomar melhores decisões sobre qual saída usar e, portanto, para qual roteador A ou B encaminhar). E, sim, isso também pode ser feito sem um IGP completo, mas realmente não adiciona muita complexidade para torná-lo uma configuração mais limpa.
Jeff McAdams

Você não respondeu à pergunta do OP: "Qual seria o benefício de substituir o iBGP pelo OSPF?" A execução de um IGP com o iBGP é o método preferido, mas a pergunta é específica e não é o que você respondeu.
Ron Maupin

3

Embora tudo o que o @RonMaupin diga seja verdadeiro, no seu caso particular , com apenas cinco roteadores, não há muito a ser ganho com a adição de outro protocolo de roteamento.

Como você não possui uma malha completa, terá que configurar seus roteadores principais como refletores de rota.

A única desvantagem real é que o BGP converge mais lentamente que o OSPF, mas existem maneiras de minimizar essa deficiência.


Não tenho certeza de que haja efetivamente uma malha completa, a menos que os roteadores principais sejam configurados como refletores de rota. O OP não disse nada sobre cada um dos três roteadores de acesso que se conectam a cada um dos outros roteadores de acesso, apenas aos roteadores principais. Uma malha completa ou uma mitigação precisará ser implementada.
Ron Maupin

Você está certo. Eu interpretei isso errado. Vou editar minha resposta.
Ron Trunk

11
Não estou claro quanto às suas intenções em relação aos seus conselhos sobre malha completa, mas para tentar esclarecer ... o requisito de malha completa é para sessões do iBGP, não para conectividade. Mesmo se dois roteadores não tiverem um link diretamente entre eles, eles deverão ter uma sessão de emparelhamento de iBGP entre eles, porque o IGP resolverá recursivamente o próximo salto para qualquer roteador intermediário necessário para acessar o par de iBGP. O Route Reflection é uma boa idéia em cerca de 5 rotas apenas para reduzir o esforço de gerenciamento envolvido, realmente não tem nada a ver com caminhos de conectividade física.
Jeff McAdams

11
Sem uma malha completa (lógica ou física) ou mitigação, o iBGP pode ter problemas de roteamento porque o AS-PATH não é atualizado para que o iBGP não anuncie as rotas aprendidas de um parceiro do iBGP. O roteador de acesso A nunca aprenderá as rotas originadas dos roteadores de acesso B e C. Os refletores de rota atenuam isso. O iBGP sempre teve um requisito de malha completa.
Ron Maupin

2
Cenário: roteador de acesso Uma rota padrão ativa vai para o roteador Core 1 e o link do roteador de acesso B para o roteador Core 1 está inoperante. O que acontece quando um host no roteador Access A deseja enviar para um host no roteador Access B. O tráfego nunca alcançará o roteador Access porque o Core 1 não possui mais uma rota para o roteador Access porque não pode aprender essas rotas no Core roteador 2. Uma malha completa ou mitigação é exigida pelo iBGP e sempre foi exigida.
Ron Maupin
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.