Início
Introdução
O MK3 andou preocupado com a sua conexão com a Internet via MK2. Completa ausência de redundância. Trânsito é mais barato, via MK2, mas não suficientemente confiável. Não propriamente, por MK2, mas pelos dois enlaces até MK1. Então, MK3 resolveu negociar trânsito com MK1 (uma banda menor, talvez) e assim agregar valor ao seu serviço. Isso que MK3 fez chama-se inovação de valor. A Figura 1, abaixo, exibe a conexão desejada por MK3 e a inserção de uma interface Loopback em cada MKi, para i=1, …, 7. Servirá para exercícios, principalmente de conectividade.
Conectando MP3 a MP1, via Loopback.
Essa é uma alternativa ilustrativa somente. Primeiro porque é possível uma conexão, em BGP, via Loopback por haver acessibilidade. Segundo, não é uma conexão que resolve os interesses de MK3 sob o ponto de vista da confiabilidade do trânsito. Uma conexão via Loopback manterá o mesmo risco, pois o tráfego de trânsito segue o mesmo caminho dos BGPs construídos entre MK3, MK2 e MK1.
Mas, o interesse didático insiste no BGP via Loopback. Antecipando alguns problemas, vamos lembrar sobre os 6 estados que o BGP assume, para tomar decisões sobre suas operações. São eles: Idle, Connect, Active, OpenSent, OpenConfirm e Established. Tudo está explicado na RFC42711, a partir do item 8, e não repetiremos aqui, exceto o esquema da Máquina de Estado Finito (MEF), que o BGP usa para transitar entre seus diversos estados, durante o processo de entendimento com seus pares. O esquema está na Figura 2, e não é muito comum ver uma versão atualizada da MEF do BGP.
Vamos então usar o mesmo esquema para estabelecer a sessão BGP entre MK3 e MK1, via Loopback. Eis o resultado na Figura 3.
O estado (State) tanto no MK1 como no MK3, está active. Recorrendo à Figura 2 e à referência [1], podemos reconhecer alguma pista sobre porque o estado final, Established, não foi atingido. Os problemas que estão fazendo com que o BGP retorne insistemente ao estado active, podem ser:
Podemos descartar (1) e (2), pois não há firewall, nem em MK1 e nem em MK3. Podemos, também eliminar o item (4), já que usamos uma interface Loopback e, uma de suas vantagens é a de não produzir instabilidades. Além do mais, o BGP de MK1 para MK2 está Established. O mesmo acontece com o BGP de MK2 para MK3. Então, só nos resta o item (3): Configuração errada do BGP!! Essa é a alternativa mais difícil pois depende de prática. Mas, nesse caso o erro é bem comum e ocorreu por provocação didática. Temos um caso típico de uma sessão BGP entre dois pares não diretamente conectados! Tal fato é visível, pois os IPs das respectivas Loopbacks estão em redes diferentes (não conectadas diretamente), apesar de acessíveis entre si. Em outras palavras, temos um BGP multi-hop. Então podemos alterar a configuração dos MK1 e MK2. Após a inclusão do Multi-hop, o problema ainda não fica resolvido e os estados do BGP ficam trocando entre Idle, Active e OpenSent. A presença do estado Active, em nosso cenário, induz ao fato de que continua havendo um erro na nossa configuração BGP. Não é uma falha tão óbvia, como a do Multi-hop. Uma olhada nos possíveis problemas quando o estado OpenSent aparece, não ajuda a posição de quem não tem muita experiência em BGP. Mas vejamos as indicações expostas em [2]:
Em uma reflexão simplista podemos eliminar o item (4), pois não recebemos indicação de mudança de estado para OpenConfirm. Podemos ir em Logging e incluir uma opção de mensagens vindas do BGP. Veremos quase nenhuma indicação para nos auxiliar. Melhor alternativa talvez seja ir no Google e procurar por três palavras “bgp loopback opensent”. A referência da Cisco, na Parte I, desse tópico, também mostra a solução. Quando usamos Loopback para estabelecer um empareamento BGP é necessário forçar o BGP a usar a interface Loopback. Isso é feito com o recurso Update-source, na aba Advanced do BGP Peer, como nos mostra a Figura 4, logo abaixo.
BGP direto entre o MK1 e o MK3
Iremos supor que a Figura 1 está agora com o BGP entre MK1 e MK2, usando o bloco passado pelo MK1: 10.201.0.14/30 e assim daremos a continuidade na parte IV, onde veremos as bases iniciais do longo debate sobre filtros, em BGP. Então, a Figura 5 mostra essa configuração final de nossos membros da FFE.
Conclusão da Parte III
A FFE sempre irá representar topologias que estão na mesma rede. Mesmo que estejamos criando interfaces com IPs de redes diferentes, como foi o caso do exemplo da Loopback. Basta simplesmente nos abstrair desse fato, que tudo irá parecer como sendo roteadores interconectados remotamente.
Outra questão muito importante é que quando nos expressamos com a palavra BGP, com foi feito até o presente momento, a referência é exclusiva ao eBGP. Quem está acostumado com Cisco, verá que os comandos sempre conterão ebgp. Quando fizermos abordagens a iBGP não deixaremos o contexto nos confundir. Por outro lado, em iBGP os ASNs dos pares são sempre os mesmos.
Fonte: http://juliaobraga.wordpress.com/2011/03/08/bgp-em-mikrotik-parte-iii/
O MK3 andou preocupado com a sua conexão com a Internet via MK2. Completa ausência de redundância. Trânsito é mais barato, via MK2, mas não suficientemente confiável. Não propriamente, por MK2, mas pelos dois enlaces até MK1. Então, MK3 resolveu negociar trânsito com MK1 (uma banda menor, talvez) e assim agregar valor ao seu serviço. Isso que MK3 fez chama-se inovação de valor. A Figura 1, abaixo, exibe a conexão desejada por MK3 e a inserção de uma interface Loopback em cada MKi, para i=1, …, 7. Servirá para exercícios, principalmente de conectividade.
Conectando MP3 a MP1, via Loopback.
Essa é uma alternativa ilustrativa somente. Primeiro porque é possível uma conexão, em BGP, via Loopback por haver acessibilidade. Segundo, não é uma conexão que resolve os interesses de MK3 sob o ponto de vista da confiabilidade do trânsito. Uma conexão via Loopback manterá o mesmo risco, pois o tráfego de trânsito segue o mesmo caminho dos BGPs construídos entre MK3, MK2 e MK1.
Mas, o interesse didático insiste no BGP via Loopback. Antecipando alguns problemas, vamos lembrar sobre os 6 estados que o BGP assume, para tomar decisões sobre suas operações. São eles: Idle, Connect, Active, OpenSent, OpenConfirm e Established. Tudo está explicado na RFC42711, a partir do item 8, e não repetiremos aqui, exceto o esquema da Máquina de Estado Finito (MEF), que o BGP usa para transitar entre seus diversos estados, durante o processo de entendimento com seus pares. O esquema está na Figura 2, e não é muito comum ver uma versão atualizada da MEF do BGP.
Vamos então usar o mesmo esquema para estabelecer a sessão BGP entre MK3 e MK1, via Loopback. Eis o resultado na Figura 3.
O estado (State) tanto no MK1 como no MK3, está active. Recorrendo à Figura 2 e à referência [1], podemos reconhecer alguma pista sobre porque o estado final, Established, não foi atingido. Os problemas que estão fazendo com que o BGP retorne insistemente ao estado active, podem ser:
- 1. Porta TCP 179 não está aberta
- 2. Portas TCP, randômicas, acima de 1023 não estão abertas
- 3. Configuração errada do BGP
- 4. Instabilidade da interface de rede
Podemos descartar (1) e (2), pois não há firewall, nem em MK1 e nem em MK3. Podemos, também eliminar o item (4), já que usamos uma interface Loopback e, uma de suas vantagens é a de não produzir instabilidades. Além do mais, o BGP de MK1 para MK2 está Established. O mesmo acontece com o BGP de MK2 para MK3. Então, só nos resta o item (3): Configuração errada do BGP!! Essa é a alternativa mais difícil pois depende de prática. Mas, nesse caso o erro é bem comum e ocorreu por provocação didática. Temos um caso típico de uma sessão BGP entre dois pares não diretamente conectados! Tal fato é visível, pois os IPs das respectivas Loopbacks estão em redes diferentes (não conectadas diretamente), apesar de acessíveis entre si. Em outras palavras, temos um BGP multi-hop. Então podemos alterar a configuração dos MK1 e MK2. Após a inclusão do Multi-hop, o problema ainda não fica resolvido e os estados do BGP ficam trocando entre Idle, Active e OpenSent. A presença do estado Active, em nosso cenário, induz ao fato de que continua havendo um erro na nossa configuração BGP. Não é uma falha tão óbvia, como a do Multi-hop. Uma olhada nos possíveis problemas quando o estado OpenSent aparece, não ajuda a posição de quem não tem muita experiência em BGP. Mas vejamos as indicações expostas em [2]:
- O autômato do BGP está aguardando uma mensagem de Open de seu par
Recebida a mensagem de Open, o roteador verifica a sua validade
Se há um erro, um dos campos da mensagem de Open é incompatível entre os pares (versão do BGP, senha MD5 incompatível, informação de AS incompatível). O fato é que o roteador envia uma mensagem para o par, indicando o erro.
Não há erro. Uma mensagem de Keepalive é enviada várias vezes e o estado é alterado para OpenConfirm
Em uma reflexão simplista podemos eliminar o item (4), pois não recebemos indicação de mudança de estado para OpenConfirm. Podemos ir em Logging e incluir uma opção de mensagens vindas do BGP. Veremos quase nenhuma indicação para nos auxiliar. Melhor alternativa talvez seja ir no Google e procurar por três palavras “bgp loopback opensent”. A referência da Cisco, na Parte I, desse tópico, também mostra a solução. Quando usamos Loopback para estabelecer um empareamento BGP é necessário forçar o BGP a usar a interface Loopback. Isso é feito com o recurso Update-source, na aba Advanced do BGP Peer, como nos mostra a Figura 4, logo abaixo.
BGP direto entre o MK1 e o MK3
Iremos supor que a Figura 1 está agora com o BGP entre MK1 e MK2, usando o bloco passado pelo MK1: 10.201.0.14/30 e assim daremos a continuidade na parte IV, onde veremos as bases iniciais do longo debate sobre filtros, em BGP. Então, a Figura 5 mostra essa configuração final de nossos membros da FFE.
Conclusão da Parte III
A FFE sempre irá representar topologias que estão na mesma rede. Mesmo que estejamos criando interfaces com IPs de redes diferentes, como foi o caso do exemplo da Loopback. Basta simplesmente nos abstrair desse fato, que tudo irá parecer como sendo roteadores interconectados remotamente.
Outra questão muito importante é que quando nos expressamos com a palavra BGP, com foi feito até o presente momento, a referência é exclusiva ao eBGP. Quem está acostumado com Cisco, verá que os comandos sempre conterão ebgp. Quando fizermos abordagens a iBGP não deixaremos o contexto nos confundir. Por outro lado, em iBGP os ASNs dos pares são sempre os mesmos.
Fonte: http://juliaobraga.wordpress.com/2011/03/08/bgp-em-mikrotik-parte-iii/
