Início
Introdução
Para avançarmos é necessário entender o comportamento do BGP em um cenário como o da Figura 1, originado no texto (IV).
O BGP possui dois comportamentos diferenciados. Um é o eBGP, que basicamento é quem estamos analisando até agora e só existe ele na topologia da Figura 1. O outro é o iBGP. O eBGP é o protocolo para as relações inter-AS e, portanto, o alicerce da Internet. O iBGP é o protocolo responsável pelas relações entre roteadores dentro de um mesmo AS. É um pouco difícil separar os dois, mas nesse texto estamos forçando a abstração do iBGP. Não há na topologia da Figura 1, nenhum AS com infraestrutura interna visível. Mas, no devido tempo iremos tratar de iBGP. As dificuldades são – (a) os atributos do BGP possuem características de comportamento diferenciadas para cada um deles e (b) o BGP implementa os dois protocolos, automaticamente. Tais dificuldades implicam que quando retornarmos ao iBGP teremos de descrever novamente os atributos que estamos agora comentando somente para o eBGP.
Por outro lado, iremos usar um termo da RFC4271, em [1], que é usado para referenciar o roteador que implementa o BGP, nomeado por BGP speaker. Iremos insistir no Português, chamando-o de BGP que fala. No plural, BGPs que falam.
O teste de conectividade da topologia
A primeira coisa a fazer é verificar a conectividade de nossa topologia. Uma alternativa simples é o ping. O resultado desse teste está na Tabela 1.
O ping de MKi para sua própria Loopback é, realmente, um excesso de zêlo. O resultado final, não foi o esperado. Do MK2 não se consegue pingar a Loopback do MK6. E, do MK7, não se consegue pingar as Loopbacks de MK1, MK3 e MK4. À primeira vista parece estranho, principalmente considerando os anúncios e as tabelas de rotas de cada MKi. Sendo necessário uma verificação, entre as diversas alternativas, a primeira foi retirar o enlace MK7 com MK2. Feito isso, o resultado da tabela de pings foi completamente positivo. Retornamos com a conexão MK7/MK2. Eis algumas reflexões, que ocorreram depois do primeiro teste:
Análise das rotas
Antes de partir para a análise das rotas, propriamente ditas, há algumas informações importantes que devemos ter em mente.
Loop no BGP
No final da Parte IV chamei atenção para o laço formado em dois pontos da topologia apresentada na Figura 1, acima. A razão disso era para lembrar, aqui, o fato de que o BGP possui um mecanismo muito importante e eficaz de prevenção de laços infinitos (loops). Para executar esta função, o BGP usa o atributo as_path. Por exemplo, um BGP que fala não aceita um anúncio onde seu ASN está presente no as_path.
Devemos ficar tranquilos em relação à eficácia do mecanismo de prevenção de loop do BGP, mas atentos em relação ao fato de que o mecanismo é um software (mesmo o firmware). Software envolve o ser humano. Juntando esse fato com o Teorema da Parada, a noção de Gödel sobre sistemas formais e o fato de que as linguagens de programação são sistemas formais, então há necessidade de uma prevenção mental.
Ficaremos, portanto, com uma preocupação em mente em relação ao Mikrotik e a sua implementação da prevenção de loop no BGP. Sem estresse, contudo.
O atributo next_hop
A cada vez que um anúncio é recebido por um BGP que fala, o atributo next_hop é alterado para o endereço IP do par vizinho, que enviou o anúncio.
Um BGP que fala, nunca anuncia uma rota para o par que deu origem à rota. E, também, nunca, em uma tabela de roteamento do BGP que fala haverá uma rota para si mesmo (isto é, um next_hop com endereço de qualquer uma de suas interfaces). Aliás, já falamos sobre isto.
Conforme descrito em [1], o atributo next_hop é usado pelo BGP que fala, para determinar a interface e o próximo endereço que será usado para transmitir pacotes. O próximo endereço é determinado através de uma análise recursiva sobre o endereço IP que está especificado no atributo next_hop de cada rota contida na tabela de roteamento.
O atributo multi_exit_disc (MED)
O atributo multi_exit_disc ou, simplesmente MED provê um mecanismo para BGPs que falam influenciar sobre tráfego que chega a ele. Ele permite que um AS informe a outro AS sobre suas preferências em relação às alternativas de entrada. Um exemplo que veremos mais à frente usaremos o atributo MED para estabelecer uma rota de backup, oportunidade em que abordaremos mais detalhes.
MED é um atributo opcional. Há muita variação nas implementações entre um fabricante e outro, de roteadores. O valor do atributo MED é denominado métrica. Quando menor a métrica, maior a prioridade. O valor padrão da métrica varia por fabricante, embora as RFCs recomendem o valor equivalente a 0. Esse é o valor padrão para o Mikrotik. Há uma certa imprecisão nas informações sobre valores da métrica.
A RFC4451, em [5], trata exclusivamente desse atributo.
O atributo as_path
É um atributo que faz parte de uma mensagem UPDATE com o objetivo de anunciar prefixos/rotas. O as_path é representado, na mensagem UPDATE, por uma lista que indica ao BGP que fala, qual o caminho que deve ser percorrido, até que se chegue ao AS que originou o anúncio. A lista começa à esquerda com o ASN do AS que por último encaminhou o anúncio do prefixo/rota e termina à direita, com o ASN do AS que originou o anúncio. Um outro segmento da mensagem UPDATE, contem o endereço do next_hop, isto é, o endereço do AS que tem seu ASN mais à esquerda, da lista que compõe o as_path. O endereço do next_hop foi alterado pelo BGP vizinho que enviou a mensagem UPDATE. O BGP que fala instala as informações da rota na tabela de rotas, com alterações relacionadas ao melhor caminho para a rota, por exemplo.
O as_path é, portanto, uma lista que pode ser bem extensa. Na topologia do FFE não aparece, mas podemos imaginar quando o BGP que fala receber a tabela completa de rotas, da Internet. Para lidar com isto, a implementação do BGP divide a lista que compõe o segmento, em dois componentes, chamados de AS_SET e AS_SEQUENCE, respectivamente.
Tomado conhecimento desses fatos poderemos entender o mecanismo de propagação de rotas do BGP descrito em [1]. Quando um BGP que fala propaga uma rota, ele aprendeu tal rota via uma mensagem de UPDATE de um outro BGP que fala. Então, ele modifica o atributo as_path baseado na localização do BGP que fala (externo) para o qual a rota será enviada, da seguinte maneira:
Quando um BGP que fala origina uma rota, ele inclui seu próprio ASN no segmento (do tipo AS_SEQUENCE), do as_path de todas as mensagens de UPDATE enviadas para seus pares externos. Neste caso, o ASN do BGP que fala originador é a única entrada nesse segmento e, também, esse segmento é único no as_path.
Relembramos que só estamos abordando o comportamento do atributo as_path para eBGP. Também, um recurso precioso é aquele que permite ao BGP que fala, incluir mais de uma instância do seu próprio ASN. Usaremos em breve esse recurso para ilustrar uma outra alternativa de implementar caminhos alternativos para a entrada de pacotes em ambientes multihoming.
Finalmente, o atributo as_path ajuda na prevenção de loop já que o próprio ASN do BGP que fala não pode estar presente no as_path. Há um debate interessante sobre isso em [6], gerado a partir de uma pergunta intuitiva. Vale a pena olhar.
Rota padrão em BGP
Em BGP, quando pensamos em rota padrão (default) associamos logo à tal questão de tabela completa e tabela parcial de rotas recebidas pelos BGPs que falam. Se um BGP que fala recebe tabelas de roteamente de vários pares vizinhos, isso para nós não incomoda muito, pois o ASN de cada vizinho vem no as_path do anúncio feito por ele e, portanto, como veremos podemos separá-las. Se recebemos uma tabela completa imaginamos que qualquer destino desejado pelo BGP que fala está na tabela de roteamento (FIB). Se, entretanto, o BGP que fala recebe uma tabela parcial é provavel que um destino NÂO esteja na tabela de roteamento. Então é necessário a rota padrão nesse BGP que fala, sob o risco de um pacote ser encaminhado para um buraco negro.
Quando usamos rota padrão no BGP, diversas outras questões aparecem ou devemos pensar sobre. Eis alguma delas, com pequenas avaliações:
As indicações são de que o comando default-originate não obedece aos filtros de saida do BGP. Vale lembrar disso, portanto. Recomendamos as referências [3] e [4].
Análise final dos problemas de conectividade
Problema: MK2 não pinga a Loopback de MK6
Vamos começar a análise pelas rotas ativas de MK2. Eis a listagem, das rotas ativas e que nos interessa, obtida via o comando /ip route print where active:
Há um IP estranho nas rotas 8, 9 e 12 (estática). Do bloco 10.227.0.8/30. Esse bloco faz parte de uma rota estática entre MK2 e MK7 e, portanto, somente visíveis entre os dois, já que não anunciamos as rotas estáticas (embora isso possa ser feito). Na topologia do FFE, esse bloco não existe. Houve um erro no segundo octeto do IPv4, projetado para ser usado o bloco 10.207.0.8/30, agregado ao bloco /23 do MK7. É um erro muito comum e involuntário. Geralmente é percebido logo e fácil de corrigir. A falha, contudo, pode gerar problemas de conectividade e afetar a infraestrutura da Internet. Provavelmente ao corrigí-lo, resolve-se o impasse da Tabela 1. Vamos deixar assim, por enquanto e listar as rotas de MK7, pois o ping para a Loopback do MK6 tem de passar pelo MK7 (o melhor caminho):
A rota para o MK6 está correta, isto é, o next_hop confere com a topologia. Pela Tabela 1, MK7 não pinga MK1, MK3 e MK4. Para ambos, o melhor caminho é o MK2. Mas, os IPs do empareamento MK7 com MK2 estão errados. Os vizinhos do MK7 e MK2 não recebem a rota de 10.277.0.8/30. Vamos corrigir e ver o resultado.
MK2, agora pinga a Loopback do MK6 e os resultados dos ping a partir de MK7, mostram que a topologia tem conectividade.
Próximas mudanças no FFE
Eis a movimentação já em andamento no FFE:
Fonte: http://juliaobraga.wordpress.com/
Para avançarmos é necessário entender o comportamento do BGP em um cenário como o da Figura 1, originado no texto (IV).
O BGP possui dois comportamentos diferenciados. Um é o eBGP, que basicamento é quem estamos analisando até agora e só existe ele na topologia da Figura 1. O outro é o iBGP. O eBGP é o protocolo para as relações inter-AS e, portanto, o alicerce da Internet. O iBGP é o protocolo responsável pelas relações entre roteadores dentro de um mesmo AS. É um pouco difícil separar os dois, mas nesse texto estamos forçando a abstração do iBGP. Não há na topologia da Figura 1, nenhum AS com infraestrutura interna visível. Mas, no devido tempo iremos tratar de iBGP. As dificuldades são – (a) os atributos do BGP possuem características de comportamento diferenciadas para cada um deles e (b) o BGP implementa os dois protocolos, automaticamente. Tais dificuldades implicam que quando retornarmos ao iBGP teremos de descrever novamente os atributos que estamos agora comentando somente para o eBGP.
Por outro lado, iremos usar um termo da RFC4271, em [1], que é usado para referenciar o roteador que implementa o BGP, nomeado por BGP speaker. Iremos insistir no Português, chamando-o de BGP que fala. No plural, BGPs que falam.
O teste de conectividade da topologia
A primeira coisa a fazer é verificar a conectividade de nossa topologia. Uma alternativa simples é o ping. O resultado desse teste está na Tabela 1.
O ping de MKi para sua própria Loopback é, realmente, um excesso de zêlo. O resultado final, não foi o esperado. Do MK2 não se consegue pingar a Loopback do MK6. E, do MK7, não se consegue pingar as Loopbacks de MK1, MK3 e MK4. À primeira vista parece estranho, principalmente considerando os anúncios e as tabelas de rotas de cada MKi. Sendo necessário uma verificação, entre as diversas alternativas, a primeira foi retirar o enlace MK7 com MK2. Feito isso, o resultado da tabela de pings foi completamente positivo. Retornamos com a conexão MK7/MK2. Eis algumas reflexões, que ocorreram depois do primeiro teste:
- A topologia atual do FFE é bastante intuitiva. Sabemos exatamente qual é o melhor caminho em cada MKi para um outro MKj qualquer.
- Não há nenhum filtro de BGP, até porque não tratamos disso ainda.
- Muito menos havia firewall, pois nem estamos pensando nele, nesse momento.
- Repassamos todas as configurações. Nenhum erro de configuração foi encontrado… Processo cansativo …
- Cada um dos MKi da topologia do FFE, Figura 1, possue configuração BGP multihoming, isto é, conecta-se a pelo menos dois diferentes provedores de trânsito. Nessa proposta de topologia, não estamos interessados em identificar quem é provedor de trânsito e/ou quem é cliente. Em tese, todos são provedores de trânsito ou clientes (exceto o MK1), mas estamos nos abstraindo dessa questão, sem importância no momento. Multihoming possui características técnicas interessantes pois permite pensarmos em redundância e otimização das diversas interconexões. Por outro lado, há uma importante consideração a ser feita em uma topologia multihoming: um AS pode eventualmente se tornar um operador de tráfego de trânsito, sem que ele o queira. Ou saiba… Um documento interessante a esse respeito, entre muitos outros é o [4].
- Na topologia, não há implementação de iBGP, que será tratado em outra oportunidade, como já foi dito. Somente eBGP, sobre o qual focaremos nossas preocupações.
- Não se pode, infelizmente, descartar a hipótese de falha no Mikrotik. O mesmo pensaríamos em outros roteadores. Isso, sempre, nos é lembrado.
- A melhor alternativa é avaliar, em detalhes, os anúncios e rotas geradas .
Análise das rotas
Antes de partir para a análise das rotas, propriamente ditas, há algumas informações importantes que devemos ter em mente.
Loop no BGP
No final da Parte IV chamei atenção para o laço formado em dois pontos da topologia apresentada na Figura 1, acima. A razão disso era para lembrar, aqui, o fato de que o BGP possui um mecanismo muito importante e eficaz de prevenção de laços infinitos (loops). Para executar esta função, o BGP usa o atributo as_path. Por exemplo, um BGP que fala não aceita um anúncio onde seu ASN está presente no as_path.
Devemos ficar tranquilos em relação à eficácia do mecanismo de prevenção de loop do BGP, mas atentos em relação ao fato de que o mecanismo é um software (mesmo o firmware). Software envolve o ser humano. Juntando esse fato com o Teorema da Parada, a noção de Gödel sobre sistemas formais e o fato de que as linguagens de programação são sistemas formais, então há necessidade de uma prevenção mental.
Ficaremos, portanto, com uma preocupação em mente em relação ao Mikrotik e a sua implementação da prevenção de loop no BGP. Sem estresse, contudo.
O atributo next_hop
A cada vez que um anúncio é recebido por um BGP que fala, o atributo next_hop é alterado para o endereço IP do par vizinho, que enviou o anúncio.
Um BGP que fala, nunca anuncia uma rota para o par que deu origem à rota. E, também, nunca, em uma tabela de roteamento do BGP que fala haverá uma rota para si mesmo (isto é, um next_hop com endereço de qualquer uma de suas interfaces). Aliás, já falamos sobre isto.
Conforme descrito em [1], o atributo next_hop é usado pelo BGP que fala, para determinar a interface e o próximo endereço que será usado para transmitir pacotes. O próximo endereço é determinado através de uma análise recursiva sobre o endereço IP que está especificado no atributo next_hop de cada rota contida na tabela de roteamento.
O atributo multi_exit_disc (MED)
O atributo multi_exit_disc ou, simplesmente MED provê um mecanismo para BGPs que falam influenciar sobre tráfego que chega a ele. Ele permite que um AS informe a outro AS sobre suas preferências em relação às alternativas de entrada. Um exemplo que veremos mais à frente usaremos o atributo MED para estabelecer uma rota de backup, oportunidade em que abordaremos mais detalhes.
MED é um atributo opcional. Há muita variação nas implementações entre um fabricante e outro, de roteadores. O valor do atributo MED é denominado métrica. Quando menor a métrica, maior a prioridade. O valor padrão da métrica varia por fabricante, embora as RFCs recomendem o valor equivalente a 0. Esse é o valor padrão para o Mikrotik. Há uma certa imprecisão nas informações sobre valores da métrica.
A RFC4451, em [5], trata exclusivamente desse atributo.
O atributo as_path
É um atributo que faz parte de uma mensagem UPDATE com o objetivo de anunciar prefixos/rotas. O as_path é representado, na mensagem UPDATE, por uma lista que indica ao BGP que fala, qual o caminho que deve ser percorrido, até que se chegue ao AS que originou o anúncio. A lista começa à esquerda com o ASN do AS que por último encaminhou o anúncio do prefixo/rota e termina à direita, com o ASN do AS que originou o anúncio. Um outro segmento da mensagem UPDATE, contem o endereço do next_hop, isto é, o endereço do AS que tem seu ASN mais à esquerda, da lista que compõe o as_path. O endereço do next_hop foi alterado pelo BGP vizinho que enviou a mensagem UPDATE. O BGP que fala instala as informações da rota na tabela de rotas, com alterações relacionadas ao melhor caminho para a rota, por exemplo.
O as_path é, portanto, uma lista que pode ser bem extensa. Na topologia do FFE não aparece, mas podemos imaginar quando o BGP que fala receber a tabela completa de rotas, da Internet. Para lidar com isto, a implementação do BGP divide a lista que compõe o segmento, em dois componentes, chamados de AS_SET e AS_SEQUENCE, respectivamente.
Tomado conhecimento desses fatos poderemos entender o mecanismo de propagação de rotas do BGP descrito em [1]. Quando um BGP que fala propaga uma rota, ele aprendeu tal rota via uma mensagem de UPDATE de um outro BGP que fala. Então, ele modifica o atributo as_path baseado na localização do BGP que fala (externo) para o qual a rota será enviada, da seguinte maneira:
- Se o primeiro componente do segmento as_path for do tipo AS_SEQUENCE (um conjunto ordenado), o sistema local precede o seu próprio ASN no último elemento da sequência (mais à esquerda da lista). Se tal operação fizer com que o número de ASNs dessa lista ultrapasse de 255, ele então inclui um novo segmento do tipo AS_SEQUENCE no qual ele insere seu próprio ASN a esse novo segmento.
- Se o primeiro segmento do as_path é do tipo AS_SET (um conjunto não-ordenado), o sistema local precede com um novo segmento do tipo AS_SEQUENCE, incluindo nele, seu próprio ASN.
- Se o as_path está vazio, o sistema local cria um segmento do tipo AS_SEQUENCE, e coloca nele o seu próprio ASN.
Quando um BGP que fala origina uma rota, ele inclui seu próprio ASN no segmento (do tipo AS_SEQUENCE), do as_path de todas as mensagens de UPDATE enviadas para seus pares externos. Neste caso, o ASN do BGP que fala originador é a única entrada nesse segmento e, também, esse segmento é único no as_path.
Relembramos que só estamos abordando o comportamento do atributo as_path para eBGP. Também, um recurso precioso é aquele que permite ao BGP que fala, incluir mais de uma instância do seu próprio ASN. Usaremos em breve esse recurso para ilustrar uma outra alternativa de implementar caminhos alternativos para a entrada de pacotes em ambientes multihoming.
Finalmente, o atributo as_path ajuda na prevenção de loop já que o próprio ASN do BGP que fala não pode estar presente no as_path. Há um debate interessante sobre isso em [6], gerado a partir de uma pergunta intuitiva. Vale a pena olhar.
Rota padrão em BGP
Em BGP, quando pensamos em rota padrão (default) associamos logo à tal questão de tabela completa e tabela parcial de rotas recebidas pelos BGPs que falam. Se um BGP que fala recebe tabelas de roteamente de vários pares vizinhos, isso para nós não incomoda muito, pois o ASN de cada vizinho vem no as_path do anúncio feito por ele e, portanto, como veremos podemos separá-las. Se recebemos uma tabela completa imaginamos que qualquer destino desejado pelo BGP que fala está na tabela de roteamento (FIB). Se, entretanto, o BGP que fala recebe uma tabela parcial é provavel que um destino NÂO esteja na tabela de roteamento. Então é necessário a rota padrão nesse BGP que fala, sob o risco de um pacote ser encaminhado para um buraco negro.
Quando usamos rota padrão no BGP, diversas outras questões aparecem ou devemos pensar sobre. Eis alguma delas, com pequenas avaliações:
- Devemos anunciar a rota padrão?
Depende da topologia. Se você possui clientes, que estabelecem BGP e não deve receber nada mais do que as rotas locais (estáticas e padrão), então a rota padrão deve ser anunciada. Esse é um caso raro em alguns ambientes e comuns em outros. Depende muito do plano de negócios.
- Como se anuncia a rota padrão, em BGP?
Para anunciar a rota padrão no BGP, devemos usar o comando default-originate. No Mikrotik:
- Código:
/routing bgp peer set par_de_destino default-originate=always
As indicações são de que o comando default-originate não obedece aos filtros de saida do BGP. Vale lembrar disso, portanto. Recomendamos as referências [3] e [4].
- Deve-se anunciar rotas estáticas, em BGP?
Depende dos interesses de negócios do vizinho BGP, em questão. Usualmente, quando se anuncia uma rota padrão deseja-se anunciar as rotas estáticas.
- Deve-se filtrar a rota padrão na entrada de anúncios de todos os pares BGP vizinhos?
Se o BGP que fala é uma implementação normal, sem as restrições anteriores, sim! Faz parte das boas práticas filtrar a rota padrão na entrada de anúncios vindos de todos os pares vizinhos. Mesmo que se saiba que o BGP não anuncia a rota padrão por livre e espontânea vontade.
Análise final dos problemas de conectividade
Problema: MK2 não pinga a Loopback de MK6
Vamos começar a análise pelas rotas ativas de MK2. Eis a listagem, das rotas ativas e que nos interessa, obtida via o comando /ip route print where active:
- Código:
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADb 10.201.0.0/23 10.201.0.5 20
5 ADb 10.203.0.0/23 10.202.0.10 20
6 ADb 10.204.0.0/23 10.201.0.5 20
7 ADb 10.205.0.0/23 10.201.0.5 20
8 ADb 10.206.0.0/23 10.227.0.9 20
9 ADb 10.207.0.0/23 10.227.0.9 20
10 ADb 10.226.0.0/24 10.227.0.9 20
11 ADb 10.226.1.0/24 10.227.0.9 20
12 ADC 10.227.0.8/30 10.227.0.10 MK7 0
Há um IP estranho nas rotas 8, 9 e 12 (estática). Do bloco 10.227.0.8/30. Esse bloco faz parte de uma rota estática entre MK2 e MK7 e, portanto, somente visíveis entre os dois, já que não anunciamos as rotas estáticas (embora isso possa ser feito). Na topologia do FFE, esse bloco não existe. Houve um erro no segundo octeto do IPv4, projetado para ser usado o bloco 10.207.0.8/30, agregado ao bloco /23 do MK7. É um erro muito comum e involuntário. Geralmente é percebido logo e fácil de corrigir. A falha, contudo, pode gerar problemas de conectividade e afetar a infraestrutura da Internet. Provavelmente ao corrigí-lo, resolve-se o impasse da Tabela 1. Vamos deixar assim, por enquanto e listar as rotas de MK7, pois o ping para a Loopback do MK6 tem de passar pelo MK7 (o melhor caminho):
- Código:
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADb 10.201.0.0/23 10.227.0.10 20
1 ADb 10.202.0.0/23 10.227.0.10 20
2 ADb 10.203.0.0/23 10.227.0.10 20
3 ADb 10.204.0.0/23 10.227.0.10 20
4 ADb 10.205.0.0/23 10.206.0.29 20
5 ADb 10.206.0.0/23 10.206.0.29 20
8 ADb 10.226.0.0/24 10.206.0.29 20
9 ADb 10.226.1.0/24 10.206.0.29 20
10 ADC 10.227.0.8/30 10.227.0.9 MK2 0
A rota para o MK6 está correta, isto é, o next_hop confere com a topologia. Pela Tabela 1, MK7 não pinga MK1, MK3 e MK4. Para ambos, o melhor caminho é o MK2. Mas, os IPs do empareamento MK7 com MK2 estão errados. Os vizinhos do MK7 e MK2 não recebem a rota de 10.277.0.8/30. Vamos corrigir e ver o resultado.
- Código:
[admin@MK2] > ping 10.206.0.1
10.206.0.1 64 byte ping: ttl=63 time=15 ms
10.206.0.1 64 byte ping: ttl=63 time=2 ms
10.206.0.1 64 byte ping: ttl=63 time=1 ms
10.206.0.1 64 byte ping: ttl=63 time<1 ms
4 packets transmitted, 4 packets received, 0% packet loss
MK2, agora pinga a Loopback do MK6 e os resultados dos ping a partir de MK7, mostram que a topologia tem conectividade.
- Código:
[admin@MK7] > ping 10.201.0.1
10.201.0.1 64 byte ping: ttl=63 time=3 ms
10.201.0.1 64 byte ping: ttl=63 time=2 ms
10.201.0.1 64 byte ping: ttl=63 time<1 ms
10.201.0.1 64 byte ping: ttl=63 time=2 ms
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0/1.7/3 ms
- Código:
[admin@MK7] > ping 10.203.0.1
10.203.0.1 64 byte ping: ttl=63 time=10 ms
10.203.0.1 64 byte ping: ttl=63 time<1 ms
10.203.0.1 64 byte ping: ttl=63 time<1 ms
10.203.0.1 64 byte ping: ttl=63 time=2 ms
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0/3.0/10 ms
- Código:
[admin@MK7] > ping 10.204.0.1
10.204.0.1 64 byte ping: ttl=62 time=14 ms
10.204.0.1 64 byte ping: ttl=62 time=1 ms
10.204.0.1 64 byte ping: ttl=62 time=1 ms
10.204.0.1 64 byte ping: ttl=62 time=1 ms
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 1/4.2/14 ms
Próximas mudanças no FFE
Eis a movimentação já em andamento no FFE:
- O MK3 decide que a interconexão com MK1 deve ser mantida, somente como backup, na hipótese de falha no trânsito via MK2. Portanto, não quer tráfego em nenhuma direção, sob o enlace com o MK1, enquanto o trânsito via MK2 estiver vivo.
- O MK6 é contratado para atender trânsito em um cliente nas proximidades do MK2 com o qual faz um acordo de fornecimento de trânsito. MK6 irá emparear com MK2, localmente. MK6 planeja usar seu próprio ASN (65536) e solicita um novo bloco /23, pois enxerga perspectiva para o futuro. Em adição a tais novas facilidades, MK6 propõe a MK2 um acordo de troca de tráfego bilateral, entre eles. Nessa expectativa, surge uma questão, pois MK2 e MK6 estão geograficamente distantes (MK2 está em Imperatriz, MA e MK6, em São Paulo, SP, por exemplo).
- MK7 está com uma outra questão a ser resolvida. Ele quer tráfego para/via MK2 somente para seus clientes. E deseja balancear o tráfego de trânsito entre MK2 e MK6, pois tudo está saíndo via MK2.
- O FFE foi solicitado a abrir as portas para terceiros com vistas a exercícios de simulação. Essa é uma questão reconhecidamente complicada, mas considerada extremamente importante!
Fonte: http://juliaobraga.wordpress.com/
