Category Archives: bgp

Configuração da Nuvem MPLS em Provedores

tux_cisco

Olá pessoal hoje trago um post um pouco mais avançado que trata várias técnologias, tais como EIGRP /BGP / VRF / e o personagem principal “MPLS”

 

Softfware utilizado para simulação : GNS3 https://www.gns3.com/ faça seu cadastro faça a instalação, adicione o IOS 36xx no post abaixo, pra quem não conhece o GNS3 ou não usou veja um video no youtube para aprender usar IDLEPC responsável por deixar o processamento dos roteadores mais baixo.

Post de EIGRP caso queira mais teoria -> http://flexpabx.com.br/blog/?p=569

 

Utilizei como base de conhecimento o livro do professor Samuel Henrque Brito, lab de configração de nuvem MPLS

Abaixo o post completo.

Observações,  passos que tomaremos neste post

  1. Configuração Básica das Interfaces e Endereços IP ( Dica Flex, faça o desenho como no post desde o inicio anote os ips no excell ou bloco ne notas para evitar conflitos mentais, ligue interfaces similares sempre exemplo fast 0/0 com 0/0
  2. Roteamento IGP (EIGRP) na Nuvem da Operadora (AS 200)
  3. Criação e Associação da VRF e Configuração do RD/RT (Dica Flex, leia várias vezes o conceito dessa parte para fixar essa informação super importante.)
  4. Configuração do Roteamento EIGRP no PE e CE
  5. Configuração da Redistribuição de Rotas EIGRP e BGP ( Dica FLEX ATENÇÃO, isso aqui pode dar um crash nos leitores mas tentando ser didático e usar linguagem popular, nessa parte de nosa configuração é necessário redistribuir as rotas eigrp dentro do BGP e vice versa, acesse o BGP 200 e joguei dentro da VRF cliente 1 e 2 o eigrp e depois acesse o EIGRP 1 e jogue o BGP 200.
  6. Configuração do MP-BGP no(s) PE

Usei interfaces fast em todos routers, não vejo mais uso de serial hoje em dia, IOS utilizado Cisco IOS v12.4 Plataforma 3600

 

TOPOLOGIA-MPLS

 

Post original : https://labcisco.blogspot.com.br/2013/01/configuracao-da-nuvem-mpls-em-provedores

Esse post traz um assunto relevante no contexto atual das telecomunicações que é o MPLS.Atualmente a tecnologia MPLS (Multi-Protocol Label Switching) é comumente utilizada pelas operadoras de telecomunicações (ISP) como solução de conectividade de longa distância.
E antes de entrar na discussão técnica, uma primeira observação importante é que a configuração dessa tecnologia no ambiente corporativo (enterprise) é totalmente diferente da configuração na nuvem da operadora (ISP).
Aliás, quem possui um link MPLS na empresa sabe bem que ela é transparente, já que você simplesmente recebe a conectividade da operadora e pronto – é como se houvesse um link privado entra as unidades remotamente conectadas… Bom, então se a coisa é simples assim qual seria a razão da “novela” que se faz acerca dessa tecnologia?
A simplicidade de uns é a complexidade de outros! Os roteadores instalados na empresa cliente normalmente sequer têm noção do que é MPLS e por isso toda a complexidade da infraestrutura está na nuvem da operadora.
Diferente de outras tecnologias de Camada 2 (HDLC, ATM e Frame-Relay) que eram tradicionalmente utilizadas na longa distância (e ainda são), o MPLS surgiu como uma tecnologia de Camada 2¹/² que traz uma abordagem de operação totalmente nova: o chamado roteamento baseado em rótulos.
Essa tecnologia não utiliza mais o cabeçalho do datagrama IP na decisão de roteamento, fazendo o reencapsulamento do datagrama com um novo cabeçalho de 4 bytes que possui um rótulo de 20 bits. Toda a decisão de encaminhamento dos pacotes é determinada com base nesse rótulo, o que agiliza o processo de roteamento e permite a implementação de técnicas de engenharia de tráfego, entre outras coisas mais.
O assunto é extenso e obviamente que o meu objetivo não é substituir um bom livro sobre o assunto – por isso serei o mais objetivo possível e o foco é que vocês consigam reproduzir um cenário prático de MPLS. Vamos trabalhar com o  cenário observado na figura abaixo.
Antes de partir para a configuração, existem vários conceitos fundamentais que o leitor precisa ter em mente para entender o papel dos elementos envolvidos no cenário. Então que tal começar pelocomeço? Parece razoável… 😉
O Custormer Edge (CE) é o equipamento instalado nas unidades remotas da empresa que irão receber a solução de conectividade provida pela operadora. Outro elemento importante é oProvider Edge (PE) que se trata do roteador da operadora diretamente conectado a um (ou mais) roteador(es) do(s) cliente(s), ou seja, PEs são conectados a CEs. Por fim, o elemento P (Provider)são os demais roteadores distribuídos pela nuvem MPLS que representa a infraestrutura de rede da operadora.

Outro conceito fundamental é a tecnologia VRF (Virtual Routing and Forwarding) que traz consigo outros dois elementos igualmente importantes: o RD (Route Distinguisher) e o RT (Route Target). Através do VRF é possível criar múltiplas instâncias da tabela de roteamento, sendo que cada uma dessas tabelas virtuais é totalmente independente das demais. No contexto do MPLS é comum que cada cliente tenha sua própria VRF porque essa prática traz mais segurança e flexibilidade.

Sem as VRFs individuais o tráfego entre as sub-redes de todos os clientes da operadora iriam compor uma única tabela de roteamento, o que seria péssimo do ponto de vista de segurança. Outro benefício comum é que se torna possível que os clientes utilizem endereços de redes iguais, já que as instâncias VRF são independentes. E é muito comum que as empresas utilizem endereços privados da RFC1918 (192.168 /16, 172.16 /12 e 10 /8).

No entanto, em algum momento é necessário que as rotas entre o roteador da empresa (CE) e o roteador da operadora (PE) sejam redistribuídas para um processo BGP no PE. Isso porque deve existir um pareamento iBGP entre um PE e outro PE remoto para viabilizar na prática a chamada VPN MPLS, um túnel abstrato que só existe nas bordas da rede MPLS, já que os roteadores P sequer conhecem as várias VPNs.

Eis que surge um problema: Fica claro que é possível ter endereços repetidos através das VRFs porque elas representam tabelas de roteamento distintas, mas como fica a redistribuição das rotas iguais para o processo BGP!!!??? Isso só é possível através da adição de um identificador nas rotas para torná-las únicas que é denominado RD (Route Distinguisher). Também existe o RT (Route Target), uma community BGP que indica o membro de uma VPN, permitindo que rotas sejam importadas e exportadas das VRFs no processo de redistribuição.

Há alguns formatos para o RD/RT, sendo que sua forma mais comum consiste em:
ASN de 16 Bits + Número de 32 Bits ; Ex.: 65000:100.

No cenário apresentado nesse post teremos duas VRFs denominadas Cliente1 e Cliente2 que serão identificadas da seguinte forma:

– VRF Cliente 1, RD 65001:111, RT 65001:1
– VRF Cliente 2, RD 65002:222, RT 65002:2

Mesmo com “toda” essa carga teórica, acreditem que fui bastante sucinto e fiz o possível para “suavizar” essa postagem apresentando apenas os conceitos fundamentais. Como o processo de configuração consiste em várias linhas de comando, estarei dividindo o processo de configuração nas seguintes etapas:

  1. Configuração Básica das Interfaces e Endereços IP
  2. Roteamento IGP (EIGRP) na Nuvem da Operadora (AS 200)
  3. Criação e Associação da VRF e Configuração do RD/RT
  4. Configuração do Roteamento EIGRP no PE e CE
  5. Configuração da Redistribuição de Rotas EIGRP e BGP
  6. Configuração do MP-BGP no(s) PE

As etapas 1 e 2 não dizem respeito à configuração do MPLS propriamente dito, no entanto são pré-requisitos para o cenário funcionar devidamente. Como os roteadores da empresa (CE) nao têm ciência do MPLS, eles possuem apenas configurações básicas.

1) Configuração Básica das Interfaces e Endereços IPA única configuração que merece destaque nessa primeira etapa é que estamos habilitando o encapsulamento MPLS na interface que se conecta a outro roteador da nuvem da operadora.Reparem que as interfaces que se conectam aos roteadores CE não têm essa configuração, já queo tráfego até o PE é puramente IP.

2) Roteamento IGP (EIGRP) na Nuvem da Operadora (AS 200)

Essa segunda etapa também é bem básica, consistindo apenas na configuração de um protocolo de roteamento IGP qualquer na nuvem da operadora. Não há nenhum destaque especial, então apenas trarei os comandos:

3) Criação e Associação da VRF e Configuração do RD/RT

A configuração abaixo é necessária apenas nos roteadores de borda (PE), já que os roteadores da empresa (CE) não têm ciência do MPLS. Reparem que em cada roteador de borda criamos duas VRFs e informamos os valores RD/RT previamente definidos. Por fim, associamos cada VRF com sua respectiva interface (cliente).

4) Configuração do Roteamento EIGRP no PE e CE

A próxima etapa consiste na configuração de um protocolo de roteamento entre a empresa para que o provedor possa conhecer as rotas anunciadas pela empresa. Esse processo de configuração é bem simples nos roteadores da empresa (CE), no entanto há alguns comandos adicionais nos roteadores do provedor (PE) que são necessários para associar as rotas de cada cliente com sua respectiva VRF anteriormente criada.

Talvez a observação mais importante aqui é que o número de AS utilizado nos processos EIGRP do CE e PE não precisam ser iguais, uma vez que na configuração EIGRP do PE há uma sub-seção de configuração para cada VRF em que devemos informar o mesmo número utilizado no processo do roteador remoto (CE). Caso contrário, as rotas dos diversos clientes seriam todas compartilhadas na tabela de roteamento padrão, o que não é desejado…

***

(*)

(*) Obs.: No processo EIGRP dos roteadores PE que irão estabelecer vizinhança com os roteadores CE utilizamos o AS 1 para não misturar as rotas dos clientes com o processo EIGRP 200 que utilizamos nas primeiras etapas para trocar as rotas internas entre os roteadores da nuvem MPLS.  

5) Configuração da Redistribuição de Rotas EIGRP e BGP

Até agora os roteadores PE já aprenderam as rotas dos clientes diretamente conectados, no entanto não existe uma ligação entre as unidades remotas dos clientes porque o PE1 não está diretamente ligado ao PE2. Ou seja, PE1 conhece as rotas anunciadas por CE1A, mas não é capaz de receber as rotas de CE1B.

Na próxima etapa a gente vai configurar um pareamento iBGP entre PE1 e PE2 para criar a abstração do túnel da VPN/MPLS. No entanto, antes temos que configurar a redistribuição mútua entre o EIGRP estabelecido com os roteadores CE e o BGP que estará em execução nos roteadores PE.

6) Configuração do MP-BGP no(s) PE

O último passo consiste no estabelecimento do túnel virtual entre as unidades remotas da empresa para prover ao cliente a abstração de que existe uma conexão privada de longa distância (WAN) entre as unidades. Assim que essa configuração for feita, os roteadores CE1A e CE1B vão conhecer as rotas uns dos outros e a empresa terá conectividade remota!

Pronto! Depois de MUITAS linhas de comando já temos uma implementação básica de VPN/MPLS funcionando entre duas empresas clientes, cada uma com apenas duas unidades remotas. Aovisualizar a tabela de roteamento VRF Cliente1 no roteador PE1 é possível observar que a rota 192.168.2.0/24 da unidade remota foi aprendida via BGP.

PE1#show ip route vrf Cliente1

Routing Table: Cliente1
Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
o – ODR, P – periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/30 is subnetted, 2 subnets
C       172.16.1.0 is directly connected, Serial2/0
B       172.16.3.0 [200/0] via 2.2.2.2, 00:02:37
D    192.168.1.0/24 [90/2172416] via 172.16.1.2, 00:42:44, Serial2/0
B    192.168.2.0/24 [200/2172416] via 2.2.2.2, 00:02:37

Também vamos aproveitar que tivemos todo esse trabalho para observar a tabela BGP do PE1, já que assim fica evidente a importância do identificador RD.

PE1#show ip bgp vpnv4 all
BGP table version is 17, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65001:111 (default for vrf Cliente1)
*> 172.16.1.0/30    0.0.0.0                  0         32768 ?
*>i172.16.3.0/30    2.2.2.2                  0    100      0 ?
*> 192.168.1.0      172.16.1.2         2172416         32768 ?
*>i192.168.2.0      2.2.2.2            2172416    100      0 ?
Route Distinguisher: 65002:222 (default for vrf Cliente2)
*> 172.16.2.0/30    0.0.0.0                  0         32768 ?
*>i172.16.4.0/30    2.2.2.2                  0    100      0 ?
*> 192.168.1.0      172.16.2.2         2172416         32768 ?
*>i192.168.2.0      2.2.2.2            2172416    100      0 ?

Agora vamos observar a tabela de roteamento do roteador CE1A instalado na empresa. Observem que ele apenas conhece a rota remota como se as unidades estivessem diretamente conectadas entre si. Essa é a grande vantagem da implementação VPN do MPLS, afinal o cliente não enxerga a nuvem MPLS.

CE1A#show ip route
Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
o – ODR, P – periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/30 is subnetted, 2 subnets
C       172.16.1.0 is directly connected, Serial2/0
D       172.16.3.0 [90/2681856] via 172.16.1.1, 00:08:33, Serial2/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
D    192.168.2.0/24 [90/2684416] via 172.16.1.1, 00:08:34, Serial2/0

Para finalizar esse post (que já está extenso demais), há vários comandos de exibição (show) que podemos utilizar para verificar o efeito de todas as configurações realizadas em cada uma das etapas.  Por isso deixo registrada uma relação de comandos de exibição caso o leitor queira reproduzir o cenário e sugiro uma observação detalhada das tabelas VRF e BGP.

PE1# show ip route
PE1# show ip route vrf Cliente1
PE1# show ip route vrf Cliente2
PE1# show ip bgp 
PE1# show ip bgp summary
PE1# show ip bgp vpnv4 all  
PE1# show ip eigrp vrf Cliente1 neighbors
PE1# show ip eigrp vrf Cliente2 neighbors
PE1# show ip eigrp vrf Cliente1 topology
PE1# show ip eigrp vrf Cliente2 topology  

BGP – Básico

O BGP é um protocolo de roteamento advanced distance vector chamado de Path Vector desenvolvido para ISP’s trocarem rotas isentas de loops. Ele  antém uma tabela separada da tabela de roteamento “IP BGP Table” e “Route Table”, se não for bem configurado pode fazer com que o meio externo influencie nas decisões de roteamento. Sua conexão com vizinho é configurada manualmente e possui atualizações confiáveis via TCP na porta 179 com envio de keepalive periódico. Não exige topologia hierárquica.

Possui uma lista do caminho completo até a rede de destino incluindo os AS’s. O mecanismo para evitar loop é o Split Horizon, onde rotas aprendidas por um IBGP não são propagadas para os IBGPS vizinhos, sendo assim é necessário Full-Mesh ou o uso de roteadores refletores ou confederações.

Assim como os endereços IPs privados, os AS privados são 64512 to 65535. Seu roteamento não é aplicado nas interfaces e sim no router inteiro. Passive-interface não funciona.

O roteamento é baseado em políticas, porém, as políticas não podem influenciar como o AS vizinho irá rotear o seu tráfego, mas pode influenciar a forma como o seu trafego chega até o AS vizinho.

Quando não usar BGP? – Use rota estática

  • Tiver uma conexão simples com Internet (ISP) ou outro AS;
  • Não há preocupação com políticas e seleção de rotas;
  • Mesma política de roteamento utilizada pelo ISP (Bloco CIDR pertencente ao ISP);
  • Roteador com pouca memória;
  • Compreensão limitada de filtro de rotas e seleção de caminhos;
  • Baixa largura de banda entre AS’s.

Tipos de BGP

  • IBGP – Internal BGP opera entre vizinhos no mesma AS. Não necessariamente precisam estar conectados físicamente;
  • EBGP – External BGP opera entre dois vizinhos conectados em diferentes ASs, não precisam estar diretamente conectados;
  • Quando o EBGP anuncia uma rota do seu vizinho ele anuncia o vizinho como um next-hop;
  • Somente rotas originadas no router IBGP são passadas para um vizinho IBGP, rotas aprendidas não são;
  • Rotas IBGP aprendidas por outro IBGP são passadas apenas para o EBGP (solução: route-reflector).


Atributos

São informações sobre as métricas BGP incluídas nas mensagens de atualização do BGP
Well-Known mandatory – atributos bem conhecidos mandatórios – devem aparecer na descrição da rota. É aquele que todas as implementações do BGP devem reconhecer, se propaga para os vizinhos.

  • Origin – Tipo 1 – Indica a origem da rota. Na tabela BGP aparece como: I= quando aprendida por IGP, E= Quando aprendida por EGP e ?= Quando a origem da rota é desconhecida (para rotas estáticas e de redistribuição);
  • AS-path – Tipo 2 – Sempre que uma atualização de rota passa através de uma AS o N.º da AS é pré-anexado aquela atualização (colocado no inicio da lista de AS’s que foram atravessadas até chegar o destino. Os routers que divulgam para IBGP não mudam o atributo AS-Path. Garante o ambiente Isento os loops. Para manipular o tráfego com As-path usa-se o prepend.
  • Next-Hop – Tipo 3 – Anuncia o próximo salto para alcançar a rede de destino. Geralmente o Next-Hop é o endereço da rede /30. O router EBGP anuncia para o IBGP (routers internos) o Next-Hop como o endereço da rede /30 (endereço da rede entre os AS’s), os routers do IBGP tem que conhecer a rede /30 entre os As’s (EBGP) por um IGP ou rota estática. Em NBMA o router se anuncia.


Well-Known discretionary – atributos bem conhecidos arbitrário – Não precisa aparecer nas descrições de rotas.

  • Local Preference – Tipo 5 – Roda internamente na AS, não é passado para os peers EBGP e Informa no AS qual o melhor caminho para sair do AS. Um caminho com Local preference maior é preferido. Default Cisco = 100;
  • Atomic aggregate – Tipo 6 – Informa o AS vizinho que o router de origem agregou as rotas;


Optional Transitive – Opcional Transitivo – Opcional, caso o router não possua, deve ser passado inalterado. Propaga-se entre os AS’s. Apenas os Opcionais Transitivos podem ser marcados como parciais;

  • Community – Tipo 8 – Serve para filtrar rotas de entrada e saída baseado na comunidade, 32bits (community Filters);
  • Aggregator – Tipo 7 – Informa o ID do router e o AS que executou a agregação da rota.

Optional nontransitive – Opcional não-transitivo – Roda dentro da AS e deve ser excluído se não implementado

  • MED – Tipo 4 – Chamado de métrica. É a divulgação de um caminho preferido dentro de um AS para AS’s externos. É uma forma de influenciar outro AS onde ele deve optar para atingir determinada rota.  Utilizado quando tem 2 entradas para o mesmo AS, quanto mais baixo melhor. Se não estiver habilitado a opção de verificar o MED, em routers CISCO é colocado por default o 0 que indica a melhor rota, mas no padrão IETF é colocado como infinito, a pior rota. Pode-se configurar para manter o padrão: bgp bestpath missing-as-worst;
  • Originator-ID – Tipo 9 – Atributo que carrega o router ID e o AS de quem originou a rota;

Weight – Particular CISCO, uso local somente no router para definir o peso da rota (preferencia) 0 – 65535, default=32768 e 0 para rotas aprendidas por outro BGP speaker, mais alto melhor. Não é propagado para nenhum vizinho, é apenas para uso local. Esse atributo tem prioridade sobre o Local Preference.

Synchronization

  • Um router não deve anunciar uma rota fora da AS antes que todos os outros tenham aprendido;
  • Gera consistência das informações dentro da AS;
  • Evita buracos negros dentro da AS;
  • Ligado por Default;
  • Não é necessário se o AS não é um AS de transito (AS que liga ASs);
  • Desabilitado a convergência é mais rápida;
  • Pode ser desabilitado se todos os routers de trânsito estiverem em full-mesh;
  • Quando estiver implementado o multihome, deve-se usar a sincronização.

Tipos de Mensagens
Open – Primeira mensagem enviada após a conexão TCP ser estabelecida, e confirmada com um keepalive.

  • Holdtime – tempo máximo entre mensagens sucessivas de keepalive e update do remetente. 180s de default. Se o holdtime fo zero os routers não enviaram Keepalive;
  • BGP router ID – Identifica o remetente, é o maior ip da interface ou da loopback. Igual ao OSPF;
  • My AS – O numero da AS do remetente;
  • Version – Versão do BGP, a utilizada é a 4;
  • BGP identifier (Router ID) – É o identificador do remetente. O ID do router é definido igual no OSPF, pelo maior IP ativo de todas as interfaces a menos que exista um IP no loopback
  • Authentication – Se usado;

Keepalive – Mensagens trocadas de 60 em 60s para verificar se o router está OK, com tempo mais rápido que o holdtime;

Update – Contem informações sobre um caminho, diversos caminhos exige diversas mensagens   ;


Withdrawn routes – Lista dos prefixos de endereço IP que estão sendo retiradas de serviço, se houver uma;


Path attributes – Atributos de caminhos, são: As-Path, Origin, Local Preference,… todos os atributos;


Network layer reachability Information – Esse campo contém uma lista dos prefixos de endereço IP que podem ser atingidos por esse caminho;

Notification – Enviada quando ocorre um erro, a conexão é fechada imediatamente

Estado do vizinho BGP

O protocolo BGP é uma máquina de estados, que leva um router através dos seguintes estados:

  • Idle – Estado inicial;
  • Connect – Conexão TCP e aguardo;
  • Active – Realiza tentativas de conexão TCP;
  • OpenSent – Estado e espera da resposta de conexão do vizinho;
  • OpenConfirm – Conexão estabelecida;
  • Estabilished – Troca de mensagem de atualização, keepalive e notificação.

Processo de Seleção de Rotas
Depois do BGP receber todas as informações de todos os AS’s e destinos as começam a ser decididas. Apenas 1 rota para cada destino. A decisão das melhores rotas baseia-se nos atributos.

  1. Se o caminho for interno não deve preferir se a rota não estiver sincronizada, ou seja, não esta na tabela de roteamento IGP;
  2. Não deve preferir se o endereço de Next-Hop não puder ser acessado;
  3. Preferir rota de maior Peso (weight), Preferencia local para roteadores Cisco System;
  4. Preferir rota com Local Preference mais alto dentro da AS (melhor caminho pra sair da AS);
  5. Se o Local Preference for igual, preferir rota originada pelo router local;
  6. Se nenhuma rota foi originada localmente, preferir rota com o AS-Path mais curto para o destino;
  7. Se os caminhos de AS’s forem iguais, preferir o código de origem mais baixo sendo as rotas aprendidas por IGP o melhor (IGP (I) < EGP (E) < incompleto (?));
  8. Se todos os códigos de origem forem iguais, preferir o caminho com o MED mais baixo (MED é enviado por outro AS);
  9. Se as rotas têm o mesmo MED, preferir caminhos Externos (EBGP) em vez dos internos (IBGP);
  10. Se a sincronização estiver desativada apenas existirá caminhos internos, nesse caso escolher o caminho até o vizinho IGP mais próximo, caminho interno mais curto;
  11. Para caminhos externos EBGP escolher a rota mais antiga para minimizar o efeito flapping  (up down);
  12. Preferir o caminho com o ID do router vizinho mais baixo;
  13. Preferir a rota com o endereço IP do vizinho mais baixo.

Peer Groups
Muitos vizinhos são configurados com as mesmas políticas de atualização (por exemplo, mesmo filtro). Em routers CISCO os vizinhos com a mesma política de atualização podem ser agrupados em peer groups. É definida uma política para o peer Group e todos os vizinhos vinculados a esse peer group adotam as políticas.

O nome de um Peer Group é local do router onde ele é configurado e não é passado para nenhum outro router.

  • Simplifica a configuração dos vizinhos;
  • Utilizado nas conexões iBGP e eBGP;
  • Todos os vizinhos recebem o mesmo update;
  • Updates são gerados uma vez para cada  grupo.
  • Politicas podem ser modificadas individualmente somente para informações de rotas entrante e não para sainte.

Route Reflectors
Os refletores de rota modificam a regra do split-horizon que existe por default onde nenhum router replica as rotas aprendidas por um vizinho para outro vizinho, IBGP não replica para IBGP. No entanto uma rota BGP aprendida por um vizinho EBGP é replicada para vizinhos EBGP e IBGP.

Benefícios

  • Habilita um router para propagar as rotas aprendidas por um IBGP para seus vizinhos;
  • Resolve o problema do split horizon;
  • Retira a necessidade do Full-Mesh;
  • Diminui o n.º de relacionamentos entre vizinhos, minimizando assim o n.º de conexões TCP;
  • Muito usado por ISP’s quando o n.º de declarações internas de vizinhos se torna excessivo;
  • Não afeta os caminhos que os pacotes seguem, somente a atualização de rotas;
  • Dentro de um AS podem ter vários refletores de rotas;
  • Migração fácil, pois é protocolo aberto;
  • Pode-se ter mais de um route-reflector server em um Cluster. Todos devem ter o mesmo Cluster-ID.

Terminologias

  • Router reflector – O router refletor de rotas que tem a permissão de repassar as rotas aprendidas;
  • Clients – quem recebe os anúncios de rotas sempre;
  •  Cluster – A relação entre os clientes e o router refletor;
  • Nonclients – Não são cliente definidos pelo router refletor, mas recebe algumas atualizações de rotas;
  • Originator-ID – Atributo que carrega o router ID e o AS de quem originou a rota;
  • Cluster ID – Usado quando se tem mais de um router refletor, para reconhecer de quem veio a atualização. Default =Router ID.

Operação

  • Refletores recebem atualizações de peer clients e nonclients
  • Se a atualização for de um peer client ele reflete para os peer clients e nonclients (exceto para o router que originou);
  • Se a atualização for de um nonclient ele reflete para todos os peer clients do cluster;
  • Se a atualização for de um parceiro EBGP (outro AS) ele reflete para todos os peer clients e todos nonclients

Dicas de migração do Refletor de Rota

  • A primeira consideração é decidir quais routers devem ser os refletores e quais devem ser clientes observando a topologia, pois os refletores precisam de full mesh com os clientes.

Restrições

  • Os refletores de rota clientes não são compatíveis com os grupos de parceiros (peer-groups), isso acontece porque um router configurado com um peer-group deve enviar todas as atualizações para todos do peer-group.


Confederation

É a forma de dividir uma AS em várias ASs. Em determinado router configura-se o AS privado (confederation) e dentro do config-router se indica o AS Publico que esse AS privado pertence. Depois adiciona-se os vizinhos de acordo com os ASs privados ou publicos (no caso de uma conexão eBGP).

  • Cria-se Sub-AS privados dentro do AS principal;
  • Todos os vizinhos internos do AS pertencem ao mesmo Sub-Grupos ao qual estão relacionados.

Multihoming
É o termo usado quando um AS está conectado a mais de um ISP. Os ISP’s aos quais você conecta devem anunciar os seus prefixos na Internet:

  • Aumenta a confiabilidade da conexão com a Internet com redundância;
  • Aumenta o desempenho com distribuição.
  • Tipos de configuração Multihoming mais comuns:
  • Multihoming sem BGP usa um router conectado a 2 ISPs com configuração de rota statica e NAT;
  • Multihoming com BGP usa-se um AS privado para conectar aos ISPs;
  • Todos os ISPs passam somente as rotas default para o AS
  • O ISP que o AS usa para atingir a Internet será determinado pela métrica IGP, ou seja, do protocolo de roteamento interno;
  • Todos os ISPs passam as rotas default e as rotas específicas selecionadas (Clientes que o AS troca muito tráfego);

Anunciando Redes no BGP

 

  • Usando o comando Network ele permite anunciar uma rede que está na tabela IP. A lista de comandos Network deve incluir todas as redes do AS que você deseja anunciar;
  • Redistribuindo as rotas estáticas para null 0, usado para anunciar as rotas agregadas. O problema do uso do null 0 é a possível criação de black hole;
  • Redistribuição das rotas estáticas do IGP para o BGP. Não recomendado, pois causa instabilidade e propaga para a Internet as oscilações em rotas internas;
  • Redistribuição de rotas do BGP para o IGP, deve se tomar cuidado pois a tabela BGP é muito grande. Nos AS’s de ISP a redistribuição do BGP normalmente não é requerida.

Manipulação de Tráfego
Filtros de AS-Path – Muitas das coisas feitas em BGP é baseado na construção desses filtros. Ele cria um filtro para selecionar um caminho específico (rotas) através da rede. Funciona como Access-Lists onde o caractere “^” funciona como o início do path e o “$” como o final do path.

  • .*  –  Todas as rotas BGP
  • ^$ –  Rotas que se originam no meu AS
  • ^(100|200|300)$ – Rotas originadas no 100, 200 ou 300
  • ^1002$ – Rotas que se originam no AS 1002 , adjacente ao meu AS
  • _1002$ – Rotas que terminam no AS 1002
  • ^1002_ – Rotas originadas no AS 1002
  • _1002_ – Rotas que passaram no AS 1002
  • (…)+(…) – Uma ou várias ocorrências do caracter especificado antes ( + = ou )

Community Filters – O atributo Community habilita políticas de roteamento a serem aplicadas para o destino.

Pode-se criar communities de acordo com o tráfego que deseja-se anunciar para os peers ou usar algumas communities pré definidas:

  • No-export – Não anuncia para eBGP peers;
  • No-advertise – Não anuncia para todos os peers;
  • Internet – Anuncia para a comunidade Internet.
  • Método de se agrupar rotas com políticas comuns de roteamento;
  • Uma rota pode fazer parte de várias communities;
  • RFC 1997 – Descreve ações pré definidas;
  • 32 bits, sendo 16 bits para a AS e outros 16 específicos.

Route-map

  • Conjunto de instâncias numeradas;
  • Maior facilidade para criação e edição de conjuntos de comandos;
  • Normalmente cada instância é composta de comandos “match” e/ou “set”;
  • Pode se editar cada instância sem influenciar as demais da Route-map;
  • O número seqüencial padrão é 10, esses números são automáticos de 10 em 10 para cada regra;
  • Possui um Deny-all no final de cada lista;
  • Se uma entrada for criada sem permit ou Deny, o permit é colocado por padrão.

Prefix List – É uma política de controle que restringe as informações de roteamento que o IOS aprende ou anuncia.

Características:

  • Performance significante;
  • Suporta modificações incrementais;
  • Linha de comando mais amigável;
  • Maior flexibilidade;
  • Uma lista de prefixo vazia permite tudo;
  • Se um prefixo for permitido a rota é usada, caso contrario a rota não é usada;
  • O router inicia a pesquisa por uma coincidência na parte superior da lista, a qual é o numero de seqüência mais baixo;
  • Se ocorrer uma coincidência o router não procura o resto da lista;
  • Negativa implícita ocorre quando o prefixo não coincide com nada;
  • Deve ser numerada manualmente sendo o primeiro numero é automaticamente o 5

Cenário

Objetivo
Seis roteadores (R1, R2, R3, R4, R5 e R6) são conectados fisicamente R1-R2-R3-R4-R5-R6-R1 e devem ser configurados com roteamento BGP seguindo os criterios abaixo:

  • Os roteadores R1, R2 e R3 possuem como IGP o OSPF na área 0 divulgando suas interfaces físicas;
  • Os roteadores R4, R5 e R6 possuem como IGP o ISIS, Level-2 somente, na área 49.0456 divulgando suas interfaces físicas;
  • O R1 (AS 123) faz conexão EBGP com o R4 (AS 456);
  • O R3 (AS 123) faz conexão EBGP com o R6 (AS 456);
  • Os roteadores R2 e R4 deverão ser Router-reflectors dos seus respectivos AS;
  • O router-ID de todos os roteadores é o endereço IP das loopbacks;
  • Somente as interfaces loopbacks deverão ser divulgadas no BGP em todos os roteadores;
  • Os roteadores de borda do AS 123 deverão ser o next-hop para as rotas externas.

Topologia

BGP-basico

 

IOS utilizados

  • R1, R2, R3, R4, R5 e R6 – c7200-js-mz.123-7.T.bin

Configuração dos Roteadores
Em todos os roteadores, antes de configurar o roteamento BGP, deve-se configurar o IGP, ou seja, o roteamento interno para que os roteadores possam conhecer o endereço IP para fechar a conexão BGP e também para que a rota seja divulgada na tabela de roteamento BGP. Esse IGP pode ser OSPF, ISIS, estático, etc.

Configurações do OSPF
Para o OSPF a configuração é feita pelo comando “router ospf ” onde o “processo” é um numero do processo OSPF. Para adicionar interfaces usa-se o comando “network
area ”. Para o roteador fazer vizinhança OSPF é necessário que a rede da interface esteja no comando “network” e a interface não esteja configurada como “passive-interface”.

As interfaces de borda dos roteadores de borda são configuradas como “passive-interface” dentro das configurações de roteamento.

Configurações do ISIS
Para o ISIS, independente da área e level, é configurado pelo comando “router Isis” e não possui o número de área no comando principal como o OSPF. Na configuração de roteamento é adicionado o endereço NSAP, que é o endereço único do roteador no ISIS configurado pelo comando “net” com o formato “49.XXXX.0000.0000.000Y.00. O “49” indica ser uma área privada e o “Y” um valor diferente dos demais roteadores.

Por padrão, todos os roteadores são Level-1-2. Deve-se alterar o level do roteador dentro do “router Isis” ou nas interfaces.

As interfaces de borda dos roteadores de borda são configuradas como “passive-interface” dentro das configurações de roteamento.

Configurações do BGP
Voltando ao BGP, agora que os roteadores conhecem os endreços IPs de seus vizinhos pelo IGP, configura-se o BGP em todos os roteadores pelo comando “router bgp ” onde o “AS” é o Autonomous System do provedor. Dentro da configuração de BGP adicionam-se os vizinhos estaticamente com o comando “neighbor remote-as ”, onde se o “as_vizinho” for igual ao AS do roteador a conexão é IBGP, se for diferente será EBGP.

Adiciona-se o IP da interface loopback como Router-ID pelo comando “router-id ”. Para divulgar rede no BGP é necessário que a rede exista na tabela de roteamento interna adicionando o comando “network mask ” ou redistribuindo rotas para o BGP com o comando “redistribute”.

Os roteadores dentro do mesmo AS não divulgarão as rotas IBGP entre eles, pois o BGP só divulga para o vizinho rotas aprendidas por EBGP, ou seja, rotas externas. Para isso configura-se os roteadores centrais como Router-reflectors adicionando os demais roteadores como clientes pelo comando “neighbor router-reflector-client”.

Para que os roteadores de borda sejam o next-hop das rotas externas, usa-se o comando “neightbor next-hop-self”, assim as rotas são divulgadas com endereço de destino interno ao AS.

As configurações de BGP atualmente podem ser feitas dentro da família de endereçamento IPv4, ou seja, dentro da configuração de roteamento entra-se no “address-family ipv4” e configuram-se as vizinhanças, router-reflector, community, route-map, etc.

Observações e Bugs
Observe as tabelas de roteamento e o caminho das rotas.

Documentação: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml
Comandos Importantes de Verificação
R5#show ip bgp

BGP table version is 7, local router ID is 5.5.5.5

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,

r RIB-failure, S Stale

Origin codes: i – IGP, e – EGP, ? – incomplete

Network          Next Hop            Metric LocPrf Weight Path

* i1.1.1.1/32       36.36.36.3               0    100      0 123 i

*>i                 14.14.14.1               0    100      0 123 i

* i2.2.2.2/32       36.36.36.3               0    100      0 123 i

*>i                 14.14.14.1               0    100      0 123 i

* i3.3.3.3/32       36.36.36.3               0    100      0 123 i

*>i                 14.14.14.1               0    100      0 123 i

*>i4.4.4.4/32       45.45.45.4               0    100      0 i

*> 5.5.5.5/32       0.0.0.0                  0         32768 i

*>i6.6.6.6/32       56.56.56.6               0    100      0 i

R2#show ip bgp summary

BGP router identifier 2.2.2.2, local AS number 123

BGP table version is 14, main routing table version 14

6 network entries using 678 bytes of memory

9 path entries using 432 bytes of memory

4/3 BGP path/bestpath attribute entries using 464 bytes of memory

1 BGP AS-PATH entries using 24 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

BGP using 1598 total bytes of memory

BGP activity 9/3 prefixes, 12/3 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

12.12.12.1      4   123      21      28       14    0    0 00:12:06        4

23.23.23.3      4   123      24      32       14    0    0 00:08:53        4

R2#show ip bgp neighbors 12.12.12.1 advertised-routes

BGP table version is 14, local router ID is 2.2.2.2

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,

r RIB-failure, S Stale

Origin codes: i – IGP, e – EGP, ? – incomplete

Network          Next Hop            Metric LocPrf Weight Path

*>i1.1.1.1/32       12.12.12.1               0    100      0 i

*> 2.2.2.2/32       0.0.0.0                  0         32768 i

*>i3.3.3.3/32       23.23.23.3               0    100      0 i

*>i4.4.4.4/32       14.14.14.4               0    100      0 456 i

*>i5.5.5.5/32       14.14.14.4               0    100      0 456 i

*>i6.6.6.6/32       14.14.14.4               0    100      0 456 i

R2#sh ip route

Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP

D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area

N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2

E1 – OSPF external type 1, E2 – OSPF external type 2

i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2

ia – IS-IS inter area, * – candidate default, U – per-user static route

o – ODR, P – periodic downloaded static route

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets

B       1.1.1.1 [200/0] via 12.12.12.1, 00:12:20

2.0.0.0/32 is subnetted, 1 subnets

C       2.2.2.2 is directly connected, Loopback0

3.0.0.0/32 is subnetted, 1 subnets

B       3.3.3.3 [200/0] via 23.23.23.3, 00:12:24

4.0.0.0/32 is subnetted, 1 subnets

B       4.4.4.4 [200/0] via 12.12.12.1, 00:01:27

5.0.0.0/32 is subnetted, 1 subnets

B       5.5.5.5 [200/0] via 12.12.12.1, 00:01:27

36.0.0.0/24 is subnetted, 1 subnets

O       36.36.36.0 [110/2] via 23.23.23.3, 00:21:44, FastEthernet1/0

6.0.0.0/32 is subnetted, 1 subnets

B       6.6.6.6 [200/0] via 12.12.12.1, 00:01:27

23.0.0.0/24 is subnetted, 1 subnets

C       23.23.23.0 is directly connected, FastEthernet1/0

12.0.0.0/24 is subnetted, 1 subnets

C       12.12.12.0 is directly connected, FastEthernet0/0

14.0.0.0/24 is subnetted, 1 subnets
Configuração

R1

!router ospf 1

passive-interface FastEthernet1/0

network 12.12.12.0 0.0.0.255 area 0

network 14.14.14.0 0.0.0.255 area 0

!

router bgp 123

bgp router-id 1.1.1.1

network 1.1.1.1 mask 255.255.255.255

neighbor 12.12.12.2 remote-as 123

neighbor 12.12.12.2 next-hop-self

neighbor 14.14.14.4 remote-as 456

!

R2

!router ospf 1

network 12.12.12.0 0.0.0.255 area 0

network 23.23.23.0 0.0.0.255 area 0

!

router bgp 123

bgp router-id 2.2.2.2

network 2.2.2.2 mask 255.255.255.255

neighbor 12.12.12.1 remote-as 123

neighbor 12.12.12.1 route-reflector-client

neighbor 23.23.23.3 remote-as 123

neighbor 23.23.23.3 route-reflector-client

!

R3

!router ospf 1

passive-interface FastEthernet0/0

network 23.23.23.0 0.0.0.255 area 0

network 36.36.36.0 0.0.0.255 area 0

!

router bgp 123

bgp router-id 3.3.3.3

network 3.3.3.3 mask 255.255.255.255

neighbor 23.23.23.2 remote-as 123

neighbor 23.23.23.2 next-hop-self

neighbor 36.36.36.6 remote-as 456

!

R4

!clns filter-set AS-456 permit 49.0456.****.****.****.**

!

interface FastEthernet0/0

ip router isis

isis adjacency-filter AS-456

!

interface FastEthernet1/0

ip router isis

isis adjacency-filter AS-456

!

router isis

net 49.0456.0000.0000.0004.00

is-type level-2-only

passive-interface FastEthernet1/0

!

router bgp 456

bgp router-id 4.4.4.4

network 4.4.4.4 mask 255.255.255.255

neighbor 14.14.14.1 remote-as 123

neighbor 45.45.45.5 remote-as 456

!

R5

!clns filter-set AS-456 permit 49.0456.****.****.****.**

!

!

interface FastEthernet0/0

ip router isis

isis adjacency-filter AS-456

!

interface FastEthernet1/0

ip router isis

isis adjacency-filter AS-456

!

router isis

net 49.0456.0000.0000.0005.00

is-type level-2-only

!

router bgp 456

bgp router-id 5.5.5.5

network 5.5.5.5 mask 255.255.255.255

neighbor 45.45.45.4 remote-as 456

neighbor 45.45.45.4 route-reflector-client

neighbor 56.56.56.6 remote-as 456

neighbor 56.56.56.6 route-reflector-client

!

R6

!clns filter-set AS-456 permit 49.0456.****.****.****.**

!

!

interface FastEthernet0/0

ip router isis

isis adjacency-filter AS-456

!

interface FastEthernet1/0

ip router isis

isis adjacency-filter AS-456

!

router isis

net 49.0456.0000.0000.0006.00

is-type level-2-only

!

router bgp 456

bgp router-id 6.6.6.6

network 6.6.6.6 mask 255.255.255.255

neighbor 36.36.36.3 remote-as 123

neighbor 56.56.56.5 remote-as 456

!

 

Fonte: http://babarata.blogspot.com.br/2010/05/bgp-basico_28.html