IP : Roteamento IP

Estudos de caso do BGP

3 Abril 2008 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (29 Julho 2013) | Inglês (30 Outubro 2008) | Feedback


Índice

Introdução
Pré-requisitos
     Requisitos
     Componentes Usados
     Convenções
Estudos de caso do BGP 1
     Como funciona o BGP?
     eBGP e iBGP
     Ativar roteamento de BGP
     Forme vizinhos de BGP
     Interface de loopback e de BGP
     eBGP multihop
     eBGP Multihop (Balanceamento de carga)
     Mapas de rotas
     Comandos de configuração corresponder e definir
     Comando de rede
     Redistribuição
     Redistribuição e rotas estáticas
     iBGP
     O algoritmo de decisão do BGP
Estudos de caso do BGP 2
     Atributo AS_PATH
     Atributo de origem
     Próximo atributo de nó do BGP
     Backdoor de BGP
     Sincronização
     Atributo de ponderação
     Atributo de preferência local
     Atributo de métrica
     Atributo de comunidade
Estudos de caso do BGP 3
     Filtragem de BGP
     Expressão regular do AS
     Vizinhos de BGP e mapas de rotas
Estudos de caso do BGP 4
     Endereços agregados e de CIDR
     Confederação de BGP
     Refletores de rota
     Retarndamento de sincronismo de rota
     Com o BGP seleciona um caminho
Estudos de caso do BGP 5
     Exemplo de projeto prático
Discussões relacionadas da comunidade de suporte da Cisco
Informações Relacionadas

Introdução

Este documento contém cinco estudos de caso do Protocolo de gateway limite (BGP).

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Usados

Este documento não está restrito a versões específicas de software e de hardware.

Convenções

Consulte Convenções de Dicas Técnicas da Cisco para obter mais informações sobre as convenções de documentos.

Estudos de caso do BGP 1

O BGP, que o RFC 1771 leavingcisco.com define, permite que você crie roteamentos de interdomínio sem loop entre sistemas autônomos (ASs). Um AS é um conjunto de roteadores em uma única administração técnica. Roteadores em um AS podem usar vários Gateway Protocols interiores (IGPs) para trocar informações de roteamento dentro do AS. Os roteadores podem usar um protocolo de gateway exterior para rotear pacotes fora do AS.

Como funciona o BGP?

O BGP usa TCP como o protocolo de transporte na porta 179. Dois roteadores BGP formam uma conexão TCP entre um e outro. Esses roteadores são de peer. Os roteadores de peer trocam mensagens para abrir e confirmar os parâmetros de conexão.

Roteadores BGP trocam informações de alcançabilidade de rede. Esta informação é principalmente um indício dos caminhos completos que uma rota deve tomar para alcançar a rede de destino. Os camihos são números de AS de BGP. Esta informação ajuda na construção de um gráfico de ASs sem loop. O gráfico também mostra onde aplicar políticas de rota para reforçar algumas restrições ao comportamento de roteamento.

Quaisquer dois roteadores que formem uma conexão TCP para trocar informaç~es de roteamento BGP são "peers" ou "vizinhos". Peers BGP inicialmente trocam todas as tabelas de roteamento BGP. Após esta troca, os peers enviam atualizações incrementais conforme as tabelas de roteamento mudam. BGP mantém um número de versão da tabela BGP. O número de versão é o mesmo para todos os peers BGP. O número de versão muda quando o BGP atualiza a tabela com mudanças de informação de roteamento. O envio de pacotes de manutenção de atividade garante que a conexão entre os peers BGP está ativa. Pacotes de notificação são enviados em resposta a erros ou condições especiais.

eBGP e iBGP

If an AS has multiple BGP speakers, the AS can serve as a transit service for other ASs. Conforme o diagrama nesta seção mostra, AS200 é um AS de trânsito para o AS100 e o AS300.

Para enviar as informações a Ass excternos, é preciso ter uma garantia de alcançabilidade para redes. Para garantir a alcançabilidade de redes, ocorrem os seguintes processos:

  • Correspondência de BGP interno (iBGP) entre roteadores dentro de um AS

  • Redistribuição de informações de BGP para IGPs que executam no AS

Quando o BGP é executado entre roteadores que pertencem a dois ASs diferentes, é chamado BGP exterior (eBGP). Quando o BGP é executado entre roteadores que no mesmo AS, é chamado iBGP.

bgp-toc1.gif

Ativar roteamento de BGP

Conclua essas etapas para ativar e configurar o BGP.

Suponha que você deseja que dois roteadores, RTA e RTB, comuniquem-se por BGP. No primeiro exemplo, RTA e RTB estão em ASs diferentes. No segundo exemplo, ambos os roteadores pertencem ao mesmo AS.

  1. Defina o processo de roteador e o número de AS para o qual os roteadores pertencem.

    Emita este comando para habilitar O BGP em um roteador:

                      router bgp autonomous-system
                      
    RTA#
    router bgp 100
    
    RTB#
    router bgp 200

    Estas instruções indicam que o RTA executa o BGP e pertence ao AS100. O RTB executa BGP e pertence a AS200.

  2. Defina vizinhos de BGP.

    A formação de vizinhos de BGP indica os roteadores que tentam comunicar-se através de BGP. A seção Forme vizinhos de BGP explica este processo.

Forme vizinhos de BGP

Dois roteadores BGP tornam-se vizinhos após estabelecerem uma conexão TCP um com o outro. A conexão TCP é essencial para que os dois roteadores peer iniciem a troca de atualizações de roteamento.

Após estabelecerem a conexão TCP, os roteadores envuam mensagens abertas para trocar valores. Os valores trocados pelos roteadores incluem o número de AS, a versão de BGP executada pelos roteadores, a ID dos roteadores BGP e o tempo de espera da manutenção de atividade. Após a confirmação e aceitação destes valores, é estabelecida a conexão vizinha. Qualquer status diferente de Estabelecido é uma indicação de que os dois roteadores não tornaram-se vizinhos e que não podem trocar atualizações de BGP.

Emita este comando neighbor para estabelecer uma conexão TCP:

            neighbor ip-address remote-as number
            
         

O número no comando é o número de AS de um dos roteadores aos quais você deseja conectar-se com BGP. O endereço de ip é o próximo endereço de nó com conexão direta para eBGP. Para iBGP, o endereço de ip é qualquer endereço de IP no outro roteador.

Os dois endereços de IP que você usa no comando neighbor dos roteadores peer precisam ser capazes de alcançar um ao outro. Um jeito de verificar a alcançabilidade é um ping extendido entre os dois endereços de IP. O ping extendido força o roteador excutando o comando ping a usar como fonte o endereço de IP que o comando neighbor especifica. O roteador precisa usar este endereço em vez do endereço de IP da interface de onde vem o pacote.

Se houver qualquer alteração na configuração do BGP, você precisará reiniciar a conexão vizinha para permitir que os novos parâmetros entrem em vigor.

  • clear ip bgp address

    Observação: O endereço é o do vizinho.

  • clear ip bgp *

    Este comando limpa todas as conexões vizinhas.

Por padrão, sessões de BGP iniciam-se com o uso da versão 4 do BGP e negociam para versões anteriores, se necessário. Você pode impedir negociações e forçar a versão de BGP utilizada pelos roteadores a comunicar-se com um vizinho. Emita este comando no modo de configuração de roteador:

            neighbor {ip address | peer-group-name} version value
            
         

Segue um exemplo de configuração do comando neighbor:

bgp-toc2.gif

RTA#
router bgp 100
neighbor 129.213.1.1 remote-as 200

RTB#
router bgp 200
neighbor 129.213.1.2 remote-as 100
neighbor 175.220.1.2 remote-as 200

RTC#
router bgp 200
neighbor 175.220.212.1 remote-as 200

Neste exemplo, RTA e RTB executam eBGP. RTB e RTC executam iBGP. O número de AS aponta para um AS interno ou externo, o que indica se eBGP ou iBGP. Além disso, os peers de eBGP têm conexão direta, mas os peers de iBGP não têm conexão direta. Roteadores iBGP não precisam de conexão direta. Mas é necessário haver algum IGP que executa e permite que os dois vizinhos alcancem um ao outro.

Esta seção fornece um exemplo das informações que o comando show ip bgp neighbors exibe.

Observação: Preste muita atenção ao estado do BGP. Qualquer status diferente de Estabelecido Isso indica que os peer não estão ativados.

Observação: Além disso, observe estes itens:

  • A versão BGP, que é 4

  • A ID de roteador remoto

    Este número é o endereço IP mais alto do roteador ou a interface de loopback mais alta, se existente.

  • A versão de tabela

    A versão de tabela fornece o estado da tabela. Sempre que chegar novas informações, a tabela aumenta a versão. Uma versão que continua a incrementar indica que há algum sincronismo de rota que causa a atualização contínua dos roteadores.

# show ip bgp neighbors
     BGP neighbor is 129.213.1.1, remote AS 200, external link
     BGP version 4, remote router ID 175.220.12.1
     status do BGP = Estabelecido, table version = 3, up for 0:10:59
     Last read 0:00:29, hold time is 180, keepalive interval is 60 seconds
     Minimum time between advertisement runs is 30 seconds
     Received 2828 messages, 0 notifications, 0 in queue
     Sent 2826 messages, 0 notifications, 0 in queue
     Connections established 11; dropped 10 

Interface de loopback e de BGP

O uso de uma interface de loopback para definir vizinhos é comum com o iBGP, mas não com o eBGP. Normalmente, utiliza-se a interface de loopback para garantir que o endereço de IP do vizinho permanece ativo e é independente de hardware que funciona apropriadamente. No caso do eBGP, roteadores de peer freqüentemente possuem conexão direta e loopback não se aplica.

Se você usar o endereço de IP de uma interface de loopback no comando neighbor , precisará de configurações extras no roteador vizinho. O roteador vizinho precisa informar o BGP da utilização de uma interface de loopback em vez de uma interface física para iniciar a conexão de TCP do vizinho de BGP. Para indicar uma interface de loopback, emita este comando:

            neighbor ip-address update-source interface
            
         

Este exemplo ilustra a utilidade deste comando :

bgp-toc3.gif

RTA#
     router bgp 100
     neighbor 190.225.11.1 remote-as 100
     neighbor 190.225.11.1 update-source loopback 1
RTB#
     router bgp 100
     neighbor 150.212.1.1 remote-as 100 

Neste exemplo, RTA e RTB executam iBGP dentro do AS100. No comando neighbor, o RTB utiliza a interface de loopback do RTA, 150.212.1.1. Neste caso, o RTA deve forçar o BGP a utilizar o endereço de IP do loopback como fonte na conexão vizinha de TCP. Para forçar esta ação, o RTA adiciona update-source interface-type interface-number para que o comando seja neighbor 190.225.11.1 update-source loopback 1. Estas instruções forçam o BGP a usar o endereço de IP da interface de loopback quando o BGP comunica-se com o vizinho 190.225.11.1.

Observação: O RTA utilizou o endereço de IP da interface física do RTB, 190.225.11.1, como um vizinho. O uso deste endereço de IP é a razão porque o RTB não precisa de configurações especiais. Consulte Configuração de exemplo para iBGP e eBGP com ou sem um endereço de loopback para a configuração de exemplo de um cenário de rede completo.

eBGP multihop

Em alguns casos, um roteador Cisco pode executar eBGP com um roteador de terceiros que não permite conexão direta dos dois peers externos. Para alcançar a conexão, você pode usar o eBGP multihop. O eBGP multihop permite uma conexão vizinha entre dois peers externos que não possuem conexão direta. O multihop serve apenas para o eBGP e não para o iBGP. Este exemplo ilustra o eBGP multihop:

bgp-toc4.gif

RTA#
router bgp 100
neighbor 180.225.11.1 remote-as 300
neighbor 180.225.11.1 ebgp-multihop
RTB#
router bgp 300
neighbor 129.213.1.2 remote-as 100

O RTA indica um vizinho externo que não possuem conexão direta. O RTA precisa indicar sua utilização do comando ebgp-multihop. Por outro lado, o RTB indica um vizinho que tenha conexão direta, que é 129.213.1.2. Por causa desta conexão direta, o RTB não precisa do comando ebgp-multihop. Você também deve configurar um roteamento de IGP ou estático para permitir que vizinhos sem conexão alcancem um ao outro.

O exemplo na seção eBGP multihop (Balanceamento de carga) mostra como alcançar o balanceamento de carga sem BGP em um caso em que você tenha um eBGP sobre linhas paralelas.

eBGP Multihop (Balanceamento de carga)

bgp-toc5.gif

RTA#
int loopback 0
ip address 150.10.1.1 255.255.255.0
router bgp 100
neighbor 160.10.1.1 remote-as 200
neighbor 160.10.1.1 ebgp-multihop
neighbor 160.10.1.1 update-source loopback 0
network 150.10.0.0

ip route 160.10.0.0 255.255.0.0 1.1.1.2
ip route 160.10.0.0 255.255.0.0 2.2.2.2
RTB#
int loopback 0
ip address 160.10.1.1 255.255.255.0
router bgp 200
neighbor 150.10.1.1 remote-as 100
neighbor 150.10.1.1 update-source loopback 0
neighbor 150.10.1.1 ebgp-multihop
network 160.10.0.0

ip route 150.10.0.0 255.255.0.0 1.1.1.1
ip route 150.10.0.0 255.255.0.0 2.2.2.1

Este exemplo ilustra a utilização de interfaces de loopback, atulizar-fonte e ebgp-multihop. O exemplo é uma solução para alcançar o balanceamento de carga entre dois interlocutores eBGP sobre linhas seriais paralelas. Em situações normais, o BGP escolhe uma das linhas para enviar pacotes e o balanceamento de carga não ocorre. Com a introdução de interfaces de loopback, o próximo nó para o eBGP é a interface de loopback. È possível utilizar rotas estáticas ou um IGP para apresentar dois caminhos de custo igual para atingir o destino. O RTA possui duas opções para alcançar o próximo nó 160.10.1.1: um caminho através do 1.1.1.2 e o outro através do 2.2.2.2. O RTB possui as mesmas opções.

Mapas de rotas

Há utilização extensa de mapas de rotas com o BGP. No contexto do BGP, o mapa de rotas é um método usado para controlar e modificar informações de roteamento. O controle e a modificação de informações de roteamento ocorrem pela da definição de condições para redistribuição de rotas de um protocolo de roteamento para o outro. Ou o controle das informações de roteamento pode ocorrer em uma injeção dentro e fora do BGP. Segue o formato do mapa de rotas:

            route-map map-tag [[permit | deny] | [sequence-number]] 
         

O caractere de mapa é somente um nome que você dá ao mapa de rotas. Você pode definir diversas instâncias do mesmo mapa de rotas, ou do mesmo caractere de nome. O número de seqüência é simplesmente uma indicação da posição que um novo mapa de rotas terá na lista de mapas de rotas que já está configurada com o mesmo nome.

Neste exemplo, duas instâncias do mapa de rotas estão definidas com o nome MEUMAPA. A primeira instância possui um número de seqüência de 10 e a segunda tem um número de seqüência de 20.

  • route-map MYMAP permit 10 (O primeiro conjunto de condições vai aqui.)

  • route-map MYMAP permit 20 (O segundo conjunto de condições vai aqui.)

Ao aplicar o mapa de rotas MEUMAPA A rotas de entrada ou de saída, o primeiro conjunto de condições é aplicado pela instância 10. Se o primeiro conjunto de condições não for atingido, siga até uma instância maior do mapa e rotas.

Comandos de configuração corresponder e definir

Cada mapa de rotas consiste de uma lista de comandos de configuração match e set. Corresponder especifica um critério match, e definir especifica uma ação set se o critério que o comando match aplica não for atingido.

Por exemplo, é possível dfinir um mapa de rotas que verifica atualizações de saída. Se houver uma correspondência para o endereço de IP 1.1.1.1, a métrica para esta atualização está configurada para 5. Estes comandos ilustram o exemplo:

            match ip address 1.1.1.1
            
            set metric 5
            
         

Agora, se os critérios de correspondência forem atingidos e você possuir uma permissão, haverá redistribuição ou controle das rotas, conforme especificado pela ação configurada. Você sairá da lista.

Se os critérios de correspondência forem atingidos e você possuir uma negação, não haverá redistribuição ou controle das rotas. Você sairá da lista.

Se os critérios de correspondência não forem atingidos e você possuir uma permissão ou negação, a próxima instância do mapa de rotas será verificada. Por exemplo, a instância 20 é verificada. Esta verificação de próxima instância continuará até que você saia ou termine todas as instâncias do mapa de rotas. Se a lista terminar e não houver correspondência, a rota não será aceita ou encaminhada.

Em versões do Cisco IOS® Software anteriores à versão 11.2 do Cisco IOS Software, ao utilizar os mapas de rota para filtrar atualizações de BGP em vez de redistribuir entre protocolos, você não pode filtrar na entrada quando utilizar um comando match no endereço de IP. Um filtro na saída é aceitável. Versões 11.2 e posteriores do Cisco IOS Software não possuem essa restrição.

Os comandos relacionados para match são:

  • match as-path

  • match community

  • match clns

  • match interface

  • match ip address

  • match ip next-hop

  • match ip route-source

  • match metric

  • match route-type

  • match tag

Os comandos relacionados para set são:

  • set as-path

  • set clns

  • set automatic-tag

  • set community

  • set interface

  • set default interface

  • set ip default next-hop

  • set level

  • set local-preference

  • set metric

  • set metric-type

  • set next-hop

  • set origin

  • set tag

  • set weight

Veja alguns exemplos de mapas de rota:

bgp-toc6.gif

Exemplo 1

Suponhamos que RTA e RTB executam RIP (Protocolo de informações de roteamento), e que RTA e RTC executam BGP. O RTA é atualizado pelo BGP e redistribui aa atualizações para o RIP. Suponhamos que o RTA deseje redistribuir para o RTB sobre 170.10.0.0 com uma métrica 2 e todas as outras rotas com uma métrica 5. Neste caso, é possível utilizar esta configuração:

RTA#
router rip
network 3.0.0.0
network 2.0.0.0
network 150.10.0.0
passive-interface Serial0
redistribute bgp 100 route-map SETMETRIC

router bgp 100
neighbor 2.2.2.3 remote-as 300
network 150.10.0.0

route-map SETMETRIC permit 10
match ip-address 1
set metric 2

route-map SETMETRIC permit 20
set metric 5

access-list 1 permit 170.10.0.0 0.0.255.255

Neste exemplo, se uma rota corresponde ao endereço de IP 170.10.0.0, ela possui métrica 2. Assim, você sai da lista de mapas de rotas. Se não há correspondência, você continua a descer a lista de mapas de rotas, o que indica configurar tudo mais para a métrica 5.

Observação: Sempre faça a pergunta "O que acontece a roteadores que não correspondem a nenhuma das instruções de correspondência?" Estas rotas são descartadas, por padrão.

Exemplo 2

Suponhamos que, no Exemplo 1, você não queira que o AS100 aceite atualizações sobre 170.10.0.0. Não é possível aplicar mapas de rotas na entrada quando você corresponde a um endereço de IP como base. Então, você deve utilizar um mapa de rota de saída no RTC:

RTC#

router bgp 300
network 170.10.0.0
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 route-map STOPUPDATES out

route-map STOPUPDATES permit 10
match ip address 1

access-list 1 deny 170.10.0.0 0.0.255.255
access-list 1 permit 0.0.0.0 255.255.255.255

Agora que você está mais familiarizado com o processo de como iniciar o BGP e como definir um vizinho, veja como iniciar a troca de informações de rede.

Há diversas maneiras de enviar informações de rede com a utilização do BGP. Estas seções percorrem os métodos um por um:

Comando de rede

O formato do comando network é.

            network network-number [mask network-mask]
         

O comando network controla as redes que originam desta caixa. Este conceito é diferente da configuração familiar com IGRP(Protocolo de roteamento de gateway interior) e RIP. Com este comando, não tente executar o BGP em certa interface. Em vez disso, tente indicar ao BGP que redes ele deveria originar desta caixa. O comando utiliza uma porção de máscara pois a versão 4 do BGP (BGP4) suporta sub-rede e super-rede. Um máximo de 200 entradas do comando network é aceitável.

O comando network funciona se o roteador conhece a rede que você está tentando anunciar, quer esteja conectada, seja estática, ou obtida dinamicamente.

Um exemplo do comando network é:

RTA#
router bgp 1
network 192.213.0.0 mask 255.255.0.0
ip route 192.213.0.0 255.255.0.0 null 0

Este exemplo indica que o roteador A gera uma entrada de rede para 192.213.0.0/16. O /16 indica que você utiliza uma super-rede do endereço de classe C e você anuncia os dois primeiros octetos, ou os primeiros 16 bits.

Observação: Você precisa de uma rota estática para fazer o roteador gerar 192.213.0.0 pois a rota estática coloca uma entrada correspondente na tabela de roteamento.

Redistribuição

O comando network é um modo de anunciar suas redes pelo BGP. Outro modo é redistribuir seu IGP no BGP. Seu IGP pode ser IGRP, protocolo Open Shortest Path First (OSPF), RIP, Protocolo de roteamento de gateway interior melhorado (EIGRP) ou outro protocolo. Esta redistribuição pode parecer assustadora, pois você descarrega todas as suas rotas internas no BGP; algumas dessas rotas foram obtidas por BGP e você não precisa enviá-las de novo. Aplique um filtro cuidadoso para garantir o envio para rotas somente internet que você queira anunciar e não para todas as rotas que você possui. Segue um exemplo:

O RTA anuncia 129.213.1.0 e o RTC anuncia 175.220.0.0. Observe a configuração do RTC:

bgp-toc7.gif

Se emitir o comando network você possui:

RTC#
router eigrp 10
network 175.220.0.0
redistribute bgp 200
default-metric 1000 100 250 100 1500

router bgp 200
neighbor 1.1.1.1 remote-as 300
network 175.220.0.0 mask 255.255.0.0

               !--- Isso limita as redes que o seu AS origina para 175.220.0.0.
            
         

Se, em vez disso, utilizar a redistribuição, você possui:

RTC#
router eigrp 10
network 175.220.0.0
redistribute bgp 200
default-metric 1000 100 250 100 1500

router bgp 200
neighbor 1.1.1.1 remote-as 300
redistribute eigrp 10

               !--- O EIGRP injeta 129.213.1.0 novamente no BGP.
            
         

Essa redistribuição provoca a origem de 129.213.1.0 pelo seu AS. Você não é a origem de 129.213.1.0; AS100 é a origem. Portanto você deve utilizar filtros para impedir a origem de sair daquela rede pelo seu AS. A configuração correta é:

RTC#
router eigrp 10
network 175.220.0.0
redistribute bgp 200
default-metric 1000 100 250 100 1500

router bgp 200
neighbor 1.1.1.1 remote-as 300
neighbor 1.1.1.1 distribute-list 1 out
redistribute eigrp 10

access-list 1 permit 175.220.0.0 0.0.255.255

Você utiliza o comando access-list para controlar as redes que originam do AS200.

Redistribuição de OSPF no BGP é ligeiramente diferente de distribuição para outros IGPs. Simplesmente executar redistribute ospf 1 sob router bgp não funciona. Palavras-chave específicas, como internal, external, e nssa-external são necessárias para redistribuir as respectivas rotas. Consulte Compreensão de redistribuição de rotas do OSPF no BGP para obter mais detalhes.

Redistribuição e rotas estáticas

É sempre possível utilizar rotas estáticas para originar uma rede ou sub-rede. A única diferença é que o BGP considera que essas rotas possuem uma origem incompleta ou desconhecida. É possível chegar ao mesmo resultado a que o exemplo na seção chegou Redistribuição com isto:

RTC#
router eigrp 10
network 175.220.0.0
redistribute bgp 200
default-metric 1000 100 250 100 1500

router bgp 200
neighbor 1.1.1.1 remote-as 300
redistribute static
...
ip route 175.220.0.0 255.255.255.0 null0
....

A interface null0 significa ignorar o pacote. Portanto, se você receber o pacote e houver uma correspondência mais específica do que 175.220.0.0, que existe, o roteador envia o pacote para a correspondência específica. Caso contrário, o roteador ignora o pacote. Este método é um bom modo de anunciar uma super-rede.

Este documento discutiu como utilizar diferentes métodos para originar rotas do seu AS. Lembre-se que essas rotas são geradas além de outras rotas de BGP que o BGP aprendeu através de vizinhos, internos ou externos. O BGP passa informações que aprende de um peer para outros peers. A diferença é que rotas que geram do comando network, redistribuição, ou estática indicam seu AS como a origem destas redes.

Redistribuição é sempre o método de injeção de BGP no IGP.

Segue um exemplo:

bgp-toc8.gif

RTA#
router bgp 100
neighbor 150.10.20.2 remote-as 300
network 150.10.0.0

RTB#
router bgp 200
neighbor 160.10.20.2 remote-as 300
network 160.10.0.0

RTC#
router bgp 300
neighbor 150.10.20.1 remote-as 100
neighbor 160.10.20.1 remote-as 200
network 170.10.00

Observação: Você não precisa da rede 150.10.0.0 ou 160.10.0.0 no RTC a não ser que deseje que o RTC gere essas redes quando passá-las adiante conforme elas vêm de AS100 e AS200. Novamente, a diferença é que o comando network adiciona um anúncio extra para essas mesmas reds, o que indica que AS300 também é uma origem para essas rotas.

Observação: Lembre-se que BGP não aceita atualizações originadas de seu próprio AS. Esta recussa garante uma topologia de interdomínio sem loop.

Por exemplo, suponhamos que o AS200, do exemplo nesta seção, tenha uma conexão de BGP no AS100. O RTA gera uma rota 150.10.0.0 e envia a rota para AS300. Depois, o RTC passa essa rota para o AS200 e mantém a origem como AS100. O RTB passa 150.10.0.0 para AS100 com a origem ainda AS100. O RTA percebe que a atualização originou de seu próprio AS e ignora sua própria atualização.

iBGP

Utilize o iBGP se um AS desejar agir como sistema de trânsito para outro ASs. É verdade que você pode fazer o mesmo ao aprender por eBGP, redistribuir no IGP e então redistribuir novamente em outro AS? Sim, mas o iBGP oferece mais flexibilidade e mais modos eficientes de trocar informações em um AS. Por exemplo, o iBGP fornece modos de controlar o melhor ponto de saída do AS utilizando a preferência local. A seção Atributo de preferência local fornece mais informações sobre preferência local.

bgp-toc9.gif

RTA#
router bgp 100
neighbor 190.10.50.1 remote-as 100
neighbor 170.10.20.2 remote-as 300
network 150.10.0.0

RTB#
router bgp 100
neighbor 150.10.30.1 remote-as 100
neighbor 175.10.40.1 remote-as 400
network 190.10.50.0

RTC#
router bgp 400
neighbor 175.10.40.2 remote-as 100
network 175.10.0.0

Observação: Lembre-se que quando um interlocutor de BGP recebe uma atualização de outros interlocutores de BGP em seu próprio AS (iBGP), o locutor de BGP que recebeu a atualização não redistribui essas informações para outros interlocutores de BGP em seu próprio AS. O interlocutor de BGP que recebe a atualização redistribui as informações para outros interlocutores de BGP fora de seu AS. Portanto, sustenta uma malha cheia enre os locutores de iBGP dentro de um AS.

No diagrama nesta seção, RTA e RTB executam iBGP. RTA e RTD também executam iBGP. As atualizações do BGP que vêm do RTB para o RTA transmitem para o RTE, que fica fora do AS. As atualizações não transmitem para o RTD, que fica dentro do AS. Portanto, faça uma correspondência de iBGP entre RTB e RTD para não quebrar o fluxo das atualizações.

O algoritmo de decisão do BGP

Após o BGP receber atualizações sobre diferentes destinos de diferentes sistemas autônomos, o protocolo deve escolher caminhos para alcançar um destino específico. O BGP escolhe apenas um único caminho para alcançar um destino específico.

O BGP baseia a decisão em diferentes atributos, como próximo nó, influências administrativas, preferência local, origem de rota, comprimento de caminho, código de origem, métrica e outros atributos.

O BGP sempre propaga o melhor caminho para os vizinhos. Para obter mais informações, consulte Algoritmo de Seleção de Melhor Caminho BGP .

A seção Estudos de caso do BGP 2 explica estes atributos e seus usos.

Estudos de caso do BGP 2

Atributo AS_PATH

bgp-toc10.gif

Quando uma atualização de rota passa por um AS, o número de AS é anexado à atualização. O atributo AS_PATH é, na verdade, a lista de números de AS que uma rota percorreu para alcançar um destino. Um AS_SET é um conjunto matemático ordenado {} de todos os ASs que foram percorridos. A seção Exemplo de CIDR 2 (as-set) deste documento fornece um exemplo de AS_SET.

No exemplo nesta seção, o RTB anuncia a rede 190.10.0.0 no AS200. Quando a rota percorre o AS300, o RTC anexa seu prórprio número de AS à rede. Portanto, quando 190.10.0.0 alcança o RTA, a rede possui dois números de AS anexados: primeiro 200, depois 300. Para o RTA, o caminho para alcançar 190.10.0.0 é (300, 200).

O mesmo processo aplica-se a 170.10.0.0 e 180.10.0.0. O RTB precisa pegar o caminho (300, 100); o RTB percorre o AS300 e depois o AS100 para alcançar 170.10.0.0. O RTC precisa percorrer (200) para alcançar 190.10.0.0 e o caminho (100) para alcançar 170.10.0.0.

Atributo de origem

A origem é um atributo imperativo que define a origem das informações do caminho. O atributo de origem pode assumir três valores:

  • IGP — Informação de alcançabilidade de camada de rede (NLRI) é interior ao AS de origem. Isso normalmente acontece ao emitir o comando bgp network. Um i na tabela BGP indica IGP.

  • EGP — NLRI foi aprendida pelo EGP (protocolo de gateway exterior). Um e na tabela BGP indica EGP.

  • INCOMPLETO — NLRI é desconhecida ou foi aprendida por outros meios. INCOMPLETO normalmente ocorre ao redistribuir rotas de outros protocolos de roteamento no BGP e a origem da rota está incompleta. Um ? na tabela BGP indica INCOMPLETO.

bgp-toc11.gif

RTA#
router bgp 100
neighbor 190.10.50.1 remote-as 100
neighbor 170.10.20.2 remote-as 300
network 150.10.0.0
redistribute static

ip route 190.10.0.0 255.255.0.0 null0

RTB#
router bgp 100
neighbor 150.10.30.1 remote-as 100
network 190.10.50.0
RTE#
router bgp 300
neighbor 170.10.20.1 remote-as 100
network 170.10.0.0

O RTA alcança 170.10.0.0 por 300 i. O "300 i" significa que o próximo caminho de AS é 300 e a origem da rota é IGP. O RTA também alcança 190.10.50.0 por i. Este "i" significa que a entrada é no mesmo AS e a origem é IGP. O RTE alcança 150.10.0.0 por 100 i. O "100 i" significa que o próximo de AS é 100 e a origem é IGP. O RTE também alcança 190.10.0.0 por 100 ?. O "100 ?" significa que o próximo AS é 100 e que a origem está incompleta e vem de uma da rota estática.

Próximo atributo de nó do BGP

bgp-toc12.gif

O próximo atributo de nó do BGP é o próximo endereço de IP de nó a ser usado para alcançar certo destino.

Para eBGP, o próximo nó é sempre o endereço de IP do vizinho especificado pelo comando neighbor. No exemplo nesta seção, o RTC anuncia 170.10.0.0 para o RTA com um próximo nó de 170.10.20.2. O RTA anuncia 150.10.0.0 para o RTC com um próximo nó de 170.10.20.1. Para iBGP, o protocolo determina que o próximo nó anunciado pelo eBGP deve ser carregado para o iBGP. Por causa dessa regra, o RTA anuncia 170.10.0.0 para seu peer do iBGP, RTB, com um próximo nó de 170.10.20.2. Portanto, de acordo com o RTB, o próximo nó a alcançar 170.10.0.0 é 170.10.20.2 e não 150.10.30.1.

Certifique-se de que o RTB pode alcançar 170.10.20.2 pelo IGP. Caso contrário, o RTB descarta pacotes com o destino de 170.10.0.0, pois o endereço do próximo nó é inacessível. Por exemplo, se o RTB executar o iGRP, também é possível executar o iGRP na rede 170.10.0.0 do RTA. Você deve tornar o iGRP passivo no link ao RTC para que o BGP seja apenas trocado.

RTA#
router bgp 100
neighbor 170.10.20.2 remote-as 300
neighbor 150.10.50.1 remote-as 100
network 150.10.0.0
RTB#
router bgp 100
neighbor 150.10.30.1 remote-as 100
RTC#
router bgp 300
neighbor 170.10.20.1 remote-as 100
network 170.10.0.0 

Observação: O RTC anuncia 170.10.0.0 para o RTA com um próximo nó equivalente a 170.10.20.2.

Observação: O RTA anuncia 170.10.0.0 para o RTB com um próximo nó equivalente a 170.10.20.2. O próximo nó do eBGP é carregado no iBGP.

Tome cuidade especial ao lidar com redes de multiacesso e de multiacesso sem broadcast (NBMA). As seções Próximo nó de BGP (Redes de multiacesso) e Próximo nó de BGP (NBMA) fornecem mais detalhes.

Próximo nó de BGP (Redes de multiacesso)

bgp-toc13.gif

Este exemplo mostra como o próximo nó comporta-se em uma rede de multiacesso com a Ethernet.

Suponhamos que RTC e RTD em AS300 executam OSPF. O RTC executa o BGP com o RTA. O RTC pode alcançar a rede de 180.20.0.0 pelo 170.10.20.3. Quando o RTC envia uma atualização de BGP para o RTA relacionado a 180.20.0.0, o RTC utiliza como próximo nó o 170.10.20.3. O RTC não utiliza seu próprio endereço de IP, 170.10.20.2. O RTC utiliza este endereço porque a rede entre RTA, RTC, e RTD é uma rede de multiacesso. O uso que o RTA faz do RTD como um próximo nó para alcançar 180.20.0.0 é mais sensato do que o nó extra pelo RTC.

Observação: O RTC anuncia 180.20.0.0 para o RTA com um próximo nó 170.10.20.3.

Se o meio comum para RTA, RTC, e RTD não é multiacesso, mas sim NBMA, ocorrem mais complicações.

Próximo nó do BGP (NBMA)

bgp-toc14.gif

O meio comum aparece como uma nuvem no diagrama. Se o meio comum for uma frame relay ou qualquer nuvem de NBMA, o comportamento exato será como se você estivesse conectado à Ethernet. O RTC anuncia 180.20.0.0 para o RTA com um próximo de 170.10.20.3.

O problema é que o RTA não possui um circuito virtual permanente (PVC) direto para o RTD e não pode alcançar o próximo nó. Neste caso, o roteamento falhará.

O comando next-hop-self remedia esta situação.

Comando next-hop-self

Para situações com o próximo nó, como no exemplo Próximo nó de BGP (NBMA), é possível utilizar o comando next-hop-self. A sintaxe é:

            neighbor {ip-address | peer-group-name} next-hop-self
         

O comando next-hop-self permite forçar o BGP a utilizar um endereço de IP específico como o próximo nó.

Para o exemplo Próximo nó do BGP (NBMA), esta configuração resolve o problema:

RTC#
router bgp 300
neighbor 170.10.20.1 remote-as 100
neighbor 170.10.20.1 next-hop-self 

O RTC anuncia 180.20.0.0 com um próximo nó equivalente a 170.10.20.2.

Backdoor de BGP

bgp-toc15.gif

Neste diagrama, RTA e RTC executam eBGP. RTB e RTC executam eBGP. RTA e RTB executam algum tipo de IGP, seja RIP, IGRP, ou outro protocolo. Por definição, atualizações do eBGP têm uma distância de 20, que é menos que as distâncias de IGP. As distâncias padrão são:

  • 120 para RIP

  • 100 para IGRP

  • 90 para EIGRP

  • 110 para OSPF

O RTA recebe atualizações sobre 160.10.0.0 por dois protocolos de roteamento:

  • eBGP com uma distância de 20

  • IGP com uma distância maior que 20

Por padrão, o BGP possui as seguintes distâncias:

  • Distância externa — 20

  • Distância interna — 200

  • Distância local — 200

Mas você pode utilizar o comando distance para alterar as distâncias padrão:

            distance bgp external-distance internal-distance local-distance
            
         

O RTA escolhe o eBGP pelo RTC por causa da distância mais curta.

Se desejar que o RTA aprenda sobre 160.10.0.0 pelo RTB (IGP), você tem duas opções:

  • Alterar a distância externa do eBGP ou a distância do IGP.

    Observação: Essa alteração não é recomendada.

  • Utilize o backdoor do BGP.

O backdoor do BGP transforma a rota IGP na rota preferida.

Emita o comando network address backdoor.

A rede configurada é a que você deseja alcançar pelo IGP. Para o BGP, esta rede obtém o mesmo tratamento que uma rede assinada localmente, exceto que atualizações do BGP não anunciam esta rede.

RTA#
router eigrp 10

network 150.10.0.0

router bgp 100
neighbor 2.2.2.1 remote-as 300
network 160.10.0.0 backdoor 

A rede 160.10.0.0 é tratada como uma entrada local, mas não é anunciada como uma entrada de rede normal.

O RTA aprende 160.10.0.0 do RTB pelo EIGRP com distância 90. O RTA também aprende o endereço do RTC pelo eBGP com distância 20. Normalmente, o eBGP é o preferido, mas por causa do comando backdoor, o EIGRP é o preferido.

Sincronização

bgp-toc16.gif

Antes de discutir a sincronização, observe este cenário. O RTC no AS300 envia atualizações sobre 170.10.0.0. RTA e RTB executam iBGP, portanto o RTB recebe a atualização e é capaz de alcançar 170.10.0.0 pelo próximo nó, 2.2.2.1. Lembre-se que o próximo nó é carregado pelo iBGP. Para alcançar o próximo nó, o RTB deve enviar o tráfego para o RTE.

Suponhamos que o RTA não tenha redistribuído a rede 170.10.0.0 no IGP. Nesse ponto, o RTE não faz idéia de que 170.10.0.0 sequer existe.

Se o RTB começar a anunciar para o AS400 que pode alcançar 170.10.0.0, tráfego que vem do RTD para o RTB com destino 170.10.0.0 flui e descarrega no RTE.

A sincronização determina que, se o seu AS passa tráfego de outro AS para um terceiro AS, o BGP não deve anunciar uma rota antes que todos os roteadores no seu AS aprenderam sobre a rota pelo IGP. O BGP espera até que o IGP tenha propagado a rota dentro do AS. Depois, ele anuncia a rota para peers externos.

No exemplo nesta seção, o RTB espera escutar sobre 170.10.0.0 pelo IGP. Então, o RTB começa a enviar a atualização ao RTD. É possível fazer o RTB acreditar que o IGP propagou as informações se você adicionar no RTB uma rota estática que aponta para 170.10.0.0. Certifique-se de que outros roteadores podem alcançar 170.10.0.0.

Desabilitar sincronização

Em alguns casos, a sincronização não é necessária. Se você não passar tráfego de um AS diferente pelo seu AS, pode desabilitar a sincronização. Também é possível desabilitar a sincronização se todos os roteadores no seu AS executarem o BGP. A desabilitação deste recurso pode permitir que você carregue alguns roteadores no seu IGP e que o BGP convirja mais rapidamente.

A desabilitação da sincronização não é automática. Se todos os seus roteadores no AS executarem o BGP e você não executar o IGP, o roteador não tem como saber. Seu roteador aguarda indefinidamente por uma atialização do IGP sobre certo roteador antes de enviar a rota a peers externos. Neste caso, é preciso desabilitar a sincronização manualmente para que o roteamento funcione corretamente:

router bgp 100
no synchronization

Observação: Certifique-se de emitir o comando clear ip bgp address para reiniciar a seção.

bgp-toc17.gif

RTB#
router bgp 100
network 150.10.0.0
neighbor 1.1.1.2 remote-as 400
neighbor 3.3.3.3 remote-as 100
no synchronization

               !--- O RTB coloca 170.10.0.0 em sua tabela de IP Routing e anuncia a rede
!--- para o RTD, ainda que o RTB não possua um caminho de IGP para o 170.10.0.0.
            
RTD#
router bgp 400
neighbor 1.1.1.1 remote-as 100
network 175.10.0.0

RTA#
   router bgp 100
   network 150.10.0.0
   neighbor 3.3.3.4 remote-as 100

Atributo de ponderação

bgp-toc18.gif

O atributo de ponderação é um atributo definido pela Cisco. Este atributo utiliza ponderação para selecionar um caminho melhor. A ponderação é atribuída localmente ao roteador. O valor só faz sentido para o roteador específico. O valor não é propagado ou carregado por nenhuma das atualizações de rota. O peso pode ser um número de 0 a 65,535. Caminhos originados pelo roteador têm um peso de 32,768 por padrão e outros caminhos pesam 0.

Rotas com mesmo valor de ponderação têm preferência quando existem diversas rotas para o mesmo destino. Veja o exemplo nessa seção. O RTA aprendeu sobre a rede 175.10.0.0 do AS4. O RTA propaga a atualização para o RTC. O RTB também aprendeu sobre a rede 175.10.0.0 do AS4. O RTB propaga a atualização para o RTC. O RTC agora possui duas maneiras de alcançar 175.10.0.0 e tem que decidir o caminho que seguir. Se definir a ponderação das atualizações no RTC que vêm do RTA para que seja maior do que a ponderação das atualizações que vêm do RTB, você forçará o RTC a utilizar o RTA como próximo nó para alcançar 175.10.0.0. Diversos métodos de alcançar esse conjunto de ponderações:

  • Utilize o comandoneighbor.

    • neighbor {ip-address | peer-group} weight weight

  • Utilize listsa de acesso AS_PATH.

    • ip as-path access-list access-list-number {permit | deny} as-regular-expression neighbor ip-address filter-list access-list-number weight weight

  • Utilize mapas de rotas.

    RTC#
    router bgp 300
    neighbor 1.1.1.1 remote-as 100
    neighbor 1.1.1.1 weight 200
    
                         !--- A rota para o 175.10.0.0 do RTA tem ponderação 200.
                      
    neighbor 2.2.2.2 remote-as 200
    neighbor 2.2.2.2 weight 100
    
                         !--- A rota para o 175.10.0.0 do RTB tem ponderação 100.
                      
                   

O RTA, que possui um valor de ponderação maior, possui preferência como o próximo nó.

É possível alcançar o mesmo resultado com as listas de filtro e AS_PATH do IP.

RTC#
router bgp 300
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 filter-list 5 weight 200
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 filter-list 6 weight 100
...
ip as-path access-list 5 permit ^100$

               !--- Isso permite somente o caminho 100.
            
ip as-path access-list 6 permit ^200$
... 

Também é possível alcançar o mesmo resultado com a utilização de mapas de rotas.

RTC#
router bgp 300
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 route-map setweightin in
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 route-map setweightin in
...
ip as-path access-list 5 permit ^100$
...

route-map setweightin permit 10
match as-path 5
set weight 200

               !--- Qualquer coisa que se aplica para acessar a lista 5, como pacotes do AS100, possui ponderação 200.
            

route-map setweightin permit 20
   set weight 100

               !--- Qualquer outra coisa possui ponderação 100.
            
         

Atributo de preferência local

bgp-toc19.gif

Preferência local é uma indicação ao AS sobre que caminho tem preferência para sair do AS para alcançar certa rede. Um caminho com preferência local mais alta é preferido. O valor padrão da preferência local é 100.

Diferente do atributo de ponderação, que só é relevante para o roteador local, a a preferência local é um atributo que os roteadores trocam no mesmo AS.

É possível configurar a preferência local com a emissão do comando bgp default local-preference value . Também é possível configurar a preferência local com mapas de rotas, como demonstrado no exemplo desta seção:

O comando bgp default local-preference configura a preferência nas atualizações de fora do roteador que vão para peers no mesmo AS. No diagrama desta seção, o AS256 recebe atualizações sobre 170.10.0.0 de dois lados diferentes da organização. A preferência local ajuda você a determinar de que lado sair do AS256 para alcançar aquela rede. Suponhamos que o RTD seja a preferência do ponto de saída. Esta configuração detetermina a preferência local para atualizações que vão do AS300 para o 200 e para atualizações que vão do AS100 para o 150:

RTC#
router bgp 256
neighbor 1.1.1.1 remote-as 100
neighbor 128.213.11.2 remote-as 256
bgp default local-preference 150

RTD#
router bgp 256
neighbor 3.3.3.4 remote-as 300
neighbor 128.213.11.1 remote-as 256
bgp default local-preference 200

Nesta configuração, o RTC determina a preferência local de todas as atualizações como 150. O mesmo RTD determina a preferência local de todas as atualizações como 200. Há uma troca de preferências locais no AS256. Portanto, tanto o RTC quanto o RTD percebem que a rede 170.10.0.0 possui uma preferência local mais alta quando as atualizações vêm do AS300 em vez do AS100. Todo o tráfego no AS256 que tenha aquela rede como destino transmite com o RTD como ponto d saída.

A utilização de mapas de rota fornece mais flexibilidade. No exemplo nesta seção, todas as atualizações recebidas pelo RTD estão marcadas com a preferência local 200 quando chegam no RTD. Atualizações que vêm do AS34 também estão marcadas com a preferência local 200. Esta marca pode ser desnecessária. Por esta razão, é possível utilizar mapas de rotas para especificar estas atualizações específicas que precisam ser marcadas com uma preferência local específica. Segue um exemplo:

RTD#
router bgp 256
neighbor 3.3.3.4 remote-as 300
neighbor 3.3.3.4 route-map setlocalin in
neighbor 128.213.11.1 remote-as 256
....
ip as-path access-list 7 permit ^300$
...

route-map setlocalin permit 10
match as-path 7
set local-preference 200

route-map setlocalin permit 20
set local-preference 150 

Com esta configuração, qualquer atualização que venha do AS300 possui uma preferência local de 200. Quaisquer outras atualizações, como as que vêm do AS34, possuem um valor de 150:

Atributo de métrica

bgp-toc20.gif

O atributo de métrica também é chamado de MULTI_EXIT_DISCRIMINATOR, MED (BGP4), ou INTER_AS (BGP3). O atributo é uma dica para vizinhos externos sobre a preferência de caminho em um AS. O atributo fornece uma maneira dinâmica de influenciar outro AS de modo a alcançar certa rota quando houver diversos pontos de entrada naquele AS. Um valor métrico menor é preferido.

Diferente de preferência local, a métrica é trocada entre ASs. Uma métrica é carregada em um AS, mas não sai do AS. Quando uma atualização entra no AS com certa métrica, tal métrica é utilizada para tomar decisões dentro do AS. Quando a mesma atualização passa para um terceiro AS, a métrica volta a 0. O diagrama nesta seção mostra o conjunto de métricas. O valor padrão da métrica é 0.

A não ser que um roteador receba outras direções, ele compara métricas de caminhos de vizinhos no mesmo AS. Para que o roteador compare métricas de vizinhos que vêm de Ass diferentes, é preciso emitir o comando de configuração especial bgp always-compare-med no roteador.

Observação: Há dois comandos de configuração de BGP que podem influenciar a seleção de caminho com base no discriminador de múltiplas saídas (MED). Os comandos são o bgp deterministic-med e o bgp always-compare-med. Uma emissão do comando bgp deterministic-med garante a comparação da variável MED em escolha de rotas quando peers diferentes anunciam no mesmo AS. Uma emissão do comando bgp always-compare-med garante a comparação do MED para caminhos de vizinhos em ASs diferentes. O comando bgp always-compare-med é útil quando fornecedores ou empreendimentos de serviço múltiplo concordam sobre uma política uniforme para a configuração de MED. Consulte Como o comando bgp deterministic-med defere do comando bgp always-compare-med para entender como esses comandos influenciam a seleção de caminhos do BGP.

No diagrama desta seção, o AS100 recebe informações sobre a rede 180.10.0.0 por três roteadores diferentes. RTC, RTD e RTB. RTC e RTD estão no AS300, e o RTB está no AS400.

Suponhamos que você tenha configurado a métrica que vai do RTC ao 120, a métrica que vai do RTD ao 200 e a métrica que vai do RTB ao 50. Por padrão, um roteador compara as métricas que vêm de vizinhos no mesmo AS. Portanto, o RTA pode comparar somente a métrica que vem do RTC à métrica que vem do RTD. O RTA escolhe o RTC como o melhor próximo nó, pois 120 é menos que 200. Ao receber uma atualização do RTB com étrica 50, o RTA não pode comparar a métrica a 120 porque o RTC e o RTB estão em ASs diferentes. O RTA deve escolher com base em alguns outros atributos.

Para forçar o RTA a comparar as métricas, você deve emitir o comando bgp always-compare-med no RTA. Estas configurações ilustram o processo:

RTA#
   router bgp 100
   neighbor 2.2.2.1 remote-as 300
   neighbor 3.3.3.3 remote-as 300
   neighbor 4.4.4.3 remote-as 400
   ....

RTC#
   router bgp 300
   neighbor 2.2.2.2 remote-as 100
   neighbor 2.2.2.2 route-map setmetricout out
   neighbor 1.1.1.2 remote-as 300

route-map setmetricout permit 10
   set metric 120

RTD#
   router bgp 300
   neighbor 3.3.3.2 remote-as 100
   neighbor 3.3.3.2 route-map setmetricout out
   neighbor 1.1.1.1 remote-as 300

route-map setmetricout permit 10
   set metric 200

RTB#
   router bgp 400
   neighbor 4.4.4.4 remote-as 100
   neighbor 4.4.4.4 route-map setmetricout out

route-map setmetricout permit 10
   set metric 50

Com estas configurações, o RTA escolhe o RTC como próximo nó, levando em consideração o fato de que todos os outros atributos são iguais. Para incluir o RTB na comparação de métricas , é preciso configurar o RTA da seguinte maneira:

RTA#
router bgp 100
neighbor 2.2.21 remote-as 300
neighbor 3.3.3.3 remote-as 300
neighbor 4.4.4.3 remote-as 400
bgp always-compare-med

Neste caso, o RTA escolhe o RTB como o melhor próximo nó para alcançar a rede 180.10.0.0.

Também é possível configurar métricas durante a redistribuição de rotas no BGP se você emitir o comando default-metric number .

Suponhamos que, no exemplo desta seção, o RTB injete uma rede por informações estáticas no AS100. Eis aqui a configuração:

RTB#
router bgp 400
redistribute static
default-metric 50

ip route 180.10.0.0 255.255.0.0 null 0

               !--- Isso faz com que o RTB envie 180.10.0.0 com uma métrica 50.
            
         

Atributo de comunidade

O atributo de comunidade é opcional e transitivo com um intervalo de 0 a 4,294,967,200. O atributo de comunidade é um meio de agrupar destinos em uma certa comunidade e aplicar decisões de roteamento de acordo com essas comunidades. As decisões de roteamento são aceitar, preferir e redistribuir, dentre outras.

É possível utilizar mapas de rotas para definir os atributos de comunidade. O comando set do mapa de rotas possui essa sintaxe:

            set community community-number [additive] [well-known-community] 
         

Algumas comunidades conhecidas predefinidas para serem utilizadas neste comando são:

  • no-export — Não anunciar para peers de eBGP. Mantenha esta rota dentro de um AS.

  • no-advertise — Não anunciar esta rota a nenhum peer, interno ou externo.

  • internet — Anunciar esta rota à comunidade da Internet. Qualquer roteador pertence a esta rota.

  • local-as — Utilizar cenários de confederação para impedir a transmissão de pacotes para fora do AS local.

Eis dois exemplos de mapas de rotas que definem a comunidade:

  • route-map communitymap
    match ip address 1
    set community no-advertise

    ou

  • route-map setcommunity
    match as-path 1
    set community 200 additive 

Se você não configurar a palavra-chave de acréscimo, 200 substituirá qualquer comunidade antiga já existente. Se você utilizar a palavra-chave de acréscimo, ocorrerá um acréscimo de 200 à comunidade. Mesmo se você definir o atributo de comunidade, este atributo não transmitirá aos vizinhos por padrão. Para enviar o atributo a um vizinho, você deve utilizar este comando:

            neighbor {ip-address | peer-group-name} send-community 
         

Segue um exemplo:

RTA#
router bgp 100
neighbor 3.3.3.3 remote-as 300
neighbor 3.3.3.3 send-community
neighbor 3.3.3.3 route-map setcommunity out

Nas versões 12.0 e posteriores do Cisco IOS Software, é possível configurar comunidades em três formatos diferentes: decimal, hexadecimal e AA:NN. Por padrão, o Cisco IOS Software utiliza o formato decimal mais antigo. Para cofigurar e exibir como AA:NN, emita o comando de configuração global ip bgp-community new-format. A primeira parte de AA:NN representa o número de AS e a segunda representa um número de 2 bytes.

Segue um exemplo:

Sem o comando ip bgp-community new-format em configuração global, uma emissão do comando show ip bgp 6.0.0.0 exibe o valor do atributo de comando em formato decimal. Neste exemplo, o valor do atributo de comunidade aparece como 6553620.

Router# show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/8, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  1
    10.10.10.1 from 10.10.10.1 (200.200.200.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Comunidade: 6553620
         

Agora, emita o comando ip bgp-community new-format globalmente neste roteador.

Router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# ip bgp-community new-format
Router(config)# exit
         

Com o comando de configuração global ip bgp-community new-format , o valor de comunidade sera exibido no formato AA:NN. O valor aparecerá como 100:20 na saída do comando show ip bgp 6.0.0.0 neste exemplo:

Router# show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/8, version 9
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  1
    10.10.10.1 from 10.10.10.1 (200.200.200.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Comunidade: 100:20
         

Estudos de caso do BGP 3

Filtragem de BGP

Um número de diferentes métodos de filtro permite que você controle o envio e recebimento de atualizações do BGP. É possível filtrar as atualizações de BGP com informações de rotas como base ou com informaões de caminho ou comunidades como base. Todos os métodos alcançam o mesmo resultado. A escolha de um ou outro método depende da configuração específica da rede.

Filtragem de rota

bgp-toc21.gif

Para restringir as informações de roteamento que o roteador aprende ou anuncia, é possível filtrar o BGP utilizando atualizações de rotas para formar um vizinho em particular. Você defini uma lista de acesso e a aplica às atualizações para ou de um vizinho. Emita este comando no modo de configuração do roteador:

            neighbor {ip-address | peer-group-name} distribute-list access-list-number {in | out}
         

Neste exemplo, o RTB origina a rede 160.10.0.0 e envia a atualização para o RTC. Se o RTC desejar parar a propagação de atualizações ao AS100, você deve definir uma lista de acesso para filtrar as atualizações e aplicar a lista de acesso durante a comunicação com RTA:

RTC#
router bgp 300
network 170.10.0.0
neighbor 3.3.3.3 remote-as 200
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 distribute-list 1 out

access-list 1 deny 160.10.0.0 0.0.255.255

access-list 1 permit 0.0.0.0 255.255.255.255

               !--- Filtrar todas as atualizações de roteamento sobre o 160.10.x.x.
            
         

A utilização de listas de acesso é complicada ao lidar com super-redes que podem causar alguns conflitos.

Suponhamos que, no exemplo desta seção, o RTB possua sub-redes diferentes de160.10.x.x. Seu objetivo é filtrar atualizações e anunciar somente 160.0.0.0/8.

Observação: A notação /8 que você está utilizando 8 bits de máscara de sub-rede, que começa na extrema esquerda do endereço de IP. Este endereço equivale a 1600.0.0.255.0.0.0.

O comando access-list 1 permit 160.0.0.0 0.255.255.255 permite 160.0.0.0/8, 160.0.0.0/9, e assim por diante. Para restringir a atualização para apenas 160.0.0.0/8, é preciso utilizar uma lista de acesso estendida neste formato:

            access-list 101 permit ip 160.0.0.0 0.255.255.255 255.0.0.0 0.0.0.0.
         

Esta lista permite somente 160.0.0.0/8.

Consulte Como bloquear uma ou mais redes de um peer de BGP para obter amostras de configuração sobre como filtrar redes de peers do BGP. O método utiliza o comando distribute-list com listas de controle de acesso (ACLs) estendidas e padrão, assim como filtro de listas de prefixo.

Filtragem de caminho

Outro tipo de filtragem é a filtragem de caminho.

bgp-toc22.gif

É possível especificar uma lista de acesso para atualizações entrando ou saindo com a utilização das informações de caminhos de AS do BGP. No diagrama desta seção, é possível bloquear atualizações sobre 160.10.0.0 para que elas não vão para o AS100. Para bloquear as atualizações, defina uma lista de acesso no RTC que impeça a transmissão para o AS100 de quaisquer atualizações originadas do AS200. Emita estes comandos:

            ip as-path access-list access-list-number {permit | deny} as-regular-expression
            
         
            neighbor {ip-address | peer-group-name} filter-list access-list-number {in | out}
         

Este exemplo impede o RTC de enviar atualizações sobre 160.10.0.0 para o RTA:

RTC#
router bgp 300
neighbor 3.3.3.3 remote-as 200
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 filter-list 1 out

               !--- O 1 é o número da lista de acesso abaixo.
            
ip as-path access-list 1 deny ^200$
ip as-path access-list 1 permit .*

O comando access-list 1 neste exemplo força a negação de quaisquer atualizações com informações de caminho que comecem com 200 e terminem com 200. O ^200$ no comando é uma "expressão regular", na qual ^ significa "iniciar com" e $ significa "finalizar com". Como o RTB envia atualizações sobre 160.10.0.0 com informações de caminho que comecem com 200 e terminem com 200, as atualizações correspondem à lista de acesso. A lista de acesso nega estas atualizações.

O .* é outra expressão regular, na qual o . significa "qualquer caractere" e o * significa "a repetição daquele caractere". Portanto, .* representa qualquer informação de caminho, que é necessária para permitir a transmissão de todas as outras atualizações.

O que acontece se, em vez de utilizar ^200$, você utilizar ^200? Com um AS400, como no diagrama desta seção, atualizações originadas do AS400 possuem informações de caminho do formulário (200, 400). Nesta informação de caminho, 200 é o primeiro e 400 é o último. Essas atualizações correspondem à lista de acesso. ^200 porque as informações de caminho começam com 200. A lista de acesso impede a transmissão destas atualizações para o RTA, que não é o requisito.

Para verificar se você implementou a expressão regular correta, emita o comando show ip bgp regexp regular-expression . Este comando exibe todos os caminhos que corresponderam à configuração da expressão regular.

Expressão regular do AS

Esta seção explica a critação de uma expressão regular.

Uma expressão regular é um padrão para corresponder contra uma série de entrada. Ao construir uma expressão regular, você especifica uma série à qual a entrada deve corresponder. No caso do BGP, você especifica uma série que consiste de informações de caminho às quais a entrada deve corresponder.

No exemplo da seção Filtragem de caminho, você especificou a série ^200$. Você queria informações de caminho que em dentro de atualizações para corresponder à série de modo a tomar uma decisão.

Uma expressão regular compreende:

  • Alcance

    Alcance é uma seqüência de caracteres entre colchetes à direita e à esquerda. Um exemplo é [abcd].

  • Átomo

    Um átomo é um único caractere. Estes é um exemplo:

    .
    • O . corresponde a um único caractere.

    ^
    • O ^ corresponde ao início da série de entrada.

    $
    • O $ corresponde ao fim da série de entrada.

    \
    • O \ corresponde ao caractere.

    -
    • O - corresponde a uma vírgula (,colchete esquerdo ({), right brace (}), o início de uma série de entrada, o fim de uma série de entrada, ou um espaço.

  • Parte

    Uma parte é um dos símbolos que seguem um átomo:

    *
    • O * corresponde a 0 ou mais seqüências do átomo.

    +
    • O + corresponde a 1 ou mais seqüências do átomo.

    ?
    • O ? corresponde ao átomo ou à série nula.

  • Filial

    Uma filial é 0 ou mais partes concatenadas.

Aqui estão alguns exemplos de expressões regulares:

a*
  • Esta expressão indica qualquer ocorrência da letra "a", que inclui nenhuma.

a+
  • Esta expressão indica que ao menos uma ocorrência da letra "a" deve estar presente.

ab?a
  • Esta expressão corresponde a "aa" ou "aba".

_100_
  • Esta expressão significa pelo AS100.

_100$
  • Esta expressão indica uma origem do AS100.

^100 .*
  • Esta expressão indica uma transmissão do AS100.

^$
  • Esta expressão indica uma origem deste AS.

Consulte Utilizando expressões regulares no BGP para exemplos de configurações de filtragem de expressões regulares.

Filtragem de comunidade do BGP

Este documento cobriu filtragem de rota e filtragem de caminho AS. Outro método é a filtragem de comunidade. A seção Atributo de comunidade discute comunidades e esta seção fornece alguns exemplos de como utilizar comunidades.

bgp-toc23.gif

Neste exemplo, você deseja que o RTB defina o atributo de comunidade para rotas do BGP que o RTB anuncia, de modo que o RTC não propague essas rotas para peers externos. Utilize o atributo de comunidade no-export.

RTB#
router bgp 200
network 160.10.0.0
neighbor 3.3.3.1 remote-as 300
neighbor 3.3.3.1 send-community
neighbor 3.3.3.1 route-map setcommunity out

route-map setcommunity
match ip address 1
set community no-export

access-list 1 permit 0.0.0.0 255.255.255.255 

Observação: Este exemplo utilizaa o comando route-map setcommunity para configurar a comunidade como no-export .

Observação: O comando neighbor send-community é necessário para enviar este atributo para o RTC.

Quando o RTC recebe as atualizações com o atributo NO_EXPORT, ele não propaga as atualizações para o RTA do peer externo.

Neste exemplo, o RTB configurou o atributo de comunidade como acréscimo de 100 200 . Esta ação adiciona o valor 100 200 para qualquer valor de comunidade existente antes da transmissão para o RTC.

RTB#
   router bgp 200
   network 160.10.0.0
   neighbor 3.3.3.1 remote-as 300
   neighbor 3.3.3.1 send-community
   neighbor 3.3.3.1 route-map setcommunity out

route-map setcommunity
match ip address 2
set community 100 200 additive

access-list 2 permit 0.0.0.0 255.255.255.255 

Uma lista de comunidades é um grupo de comunidades que você utiliza em uma cláusula corresponder de um mapa de rotas. A lista de comunidades permite que você filtre ou configure atributos com diferentes listas de números de comunidades como base.

            ip community-list community-list-number {permit | deny} community-number
            
         

Por exemplo, é possível dfinir este mapa de rotas como match-on-comunity .

route-map match-on-community
match community 10

               !--- O número da lista de comunidades é 10.
            
set weight 20
ip community-list 10 permit 200 300

               !--- O número da lista de comunidades é 200 300.
            
         

É possível utilizar a lista de comunidades para filtrar ou configurar alguns parâmetros, como ponderação e métrica, em certas atualizações tendo o valor de comunidade como base. No segundo exemplo desta seção, o RTB envia atualizaões ao RTC com uma comunidade de 100 200. Se o RTC desejar definir a ponderação tendo estes valore como base, você pode:

RTC#
router bgp 300
neighbor 3.3.3.3 remote-as 200
neighbor 3.3.3.3 route-map check-community in

route-map check-community permit 10
match community 1
set weight 20

route-map check-community permit 20
match community 2 exact
set weight 10

route-map check-community permit 30
match community 3

ip community-list 1 permit 100
ip community-list 2 permit 200
ip community-list 3 permit internet 

Neste exemplo, qualquer rota que possua 100 no atributo de comunidade corresponde à lista 1. A ponderação desta rota está configurada para 20. Qualquer rota que possua apenas 200 como comunidade corresponde à lista 2 e possui uma ponderação de 20. A palavra-chave exato determina que a comunidade consiste de apenas 200 e nada mais. A última lista de comunidades está aqui para garantir que outras atualizações não sejam descartadas. Lembre-se que qualquer coisa que não corresponda é descartada, por padrão. A palavra-chave internet indica todas as rotas porque todas elas são membros da comunidade da internet.

Consulte Utilizando valores de comunidade de BGP para controlar a política de roteamento em uma rede de provedor upstream para obter mais informações.

Vizinhos de BGP e mapas de rotas

bgp-toc24.gif

É possível utilizar o comando neighbor em conjunção com mapas de rotas para filtyrar ou configurar parâmetros em atualizações chegando ou saindo.

Mapas de rota associados com a instrução neighbor não possuem efeito em atualizações que estão chegando ao corresponde-las com os endereços de IP:

            neighbor ip-address route-map route-map-name
            
         

Suponhamos que, no diagrama desta seção, você deseje que o RTC aprenda do AS200 sobre redes locais ao AS200 e nada mais. Além disso, você deseja configurar a ponderação nas rotas aceitas para 20. Utilize uma combinação de listas de acesso neighbor e as-path:

RTC#
   router bgp 300
   network 170.10.0.0
   neighbor 3.3.3.3 remote-as 200
   neighbor 3.3.3.3 route-map stamp in

route-map stamp
match as-path 1
set weight 20

ip as-path access-list 1 permit ^200$ 

Quaisquer atualizações que originem do AS200 possuem informações de caminho que começam com 200 e terminam com 200. Essas atualizações são permitidas. Quaisquer outras atualizações são descartadas.

Suponhamos que você deseje:

  • Uma aceitação de atualizações que originam do AS200 e possuem ponderação 20

  • O descarte de atualizações que originam do AS400

  • Uma ponderação de 10 para outras atualizações

    RTC#
    router bgp 300
    network 170.10.0.0
    neighbor 3.3.3.3 remote-as 200
    neighbor 3.3.3.3 route-map stamp in
    
    route-map stamp permit 10
    match as-path 1
    set weight 20
    
    route-map stamp permit 20
    match as-path 2
    set weight 10
    
    ip as-path access-list 1 permit ^200$
    ip as-path access-list 2 permit ^200 600 .*

    Esta instrução define uma ponderação de 20 para atualizações locais do AS200. A instrução também configura uma ponderação de 10 para atualizações atrás do AS400 e descarta atualizações provenientes do AS400.

Utilização do Comando set as-path prepend

Em algumas situações, você deve manipular as informações de caminho para manipular o processo de decisão do BGP. O comandoque você utiliza com um mapa de roteamento é o:

            set as-path prepend as-path#
               as-path#
            
         

Suponhamos que, no diagrama da seção Vizinhos de BGP e mapas de rotas, o RTC anuncia sua própria rede 170.10.0.0 para dois ASs diferentes, o AS100 e o AS200. Quando as informações são propagadas para o AS600, os roteadores no AS600 possuem informações de alcançabilidade sobre 150.10.0.0 por duas rotas diferentes. A primeira rota é pelo AS100 com o caminho (100, 300) e a segunda é pelo AS400 com o caminho (400, 200, 300). Se todos os outros atributos forem os mesmos, o AS600 escolhe o caminho mais curto, o da rota pelo AS100.

O AS300 recebe todo o tráfego pelo AS100. Se desejar influenciar esta decisão do fim do AS300, você pode fazer o caminho pelo AS100 parecer maior do que o caminho que passa pelo AS400. Você poderá fazer isso se anexar números do AS às informações de caminho existentes que é anunciada ao AS100. Uma prática comum é repetir seu próprio número de AS da seguinte forma:

RTC#
router bgp 300
network 170.10.0.0
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 route-map SETPATH out

route-map SETPATH
set as-path prepend 300 300

Por causa desta configuração, o AS600 recebe atualizações sobre 170.10.0.0 pelo AS100 com informações de caminho do: (100, 300, 300, 300). Estas informações de caminho são maiores do que a (400, 200, 300) que o AS600 recebeu do AS400.

Grupos de peer do BGP

bgp-toc25.gif

Um grupo de peers de BGP é um grupo de vizinhos de BGP com algumas das mesmas políticas de atualização. Mapas de rotas, listas de distribuição e listas de filtros normalmente configuram políticas de atualização. Não é possível configurar as mesmas políticas para cada vizinho separad; mas você pode degfinir um nome de grupo de peer e atribuir essas políticas a preparar para o grupo.

Membros de seu próprio grupo de peers herdam todas as opções de configuração do grupo de peers. É possível configurar membros para cancelar estas opções se elas não afetarem atualizações externas. Só é possível cancelar opções configuradas como internas.

Para definir um grupo de peers, emita este comando:

            neighbor peer-group-name peer-group
         

Este exemplo aplica-se a grupos de peer de vizinhos internos e externos do BGP:

RTC#
   router bgp 300
   neighbor internalmap peer-group
   neighbor internalmap remote-as 300
   neighbor internalmap route-map SETMETRIC out
   neighbor internalmap filter-list 1 out
   neighbor internalmap filter-list 2 in
   neighbor 5.5.5.2 peer-group internalmap
   neighbor 5.6.6.2 peer-group internalmap
   neighbor 3.3.3.2 peer-group internalmap
   neighbor 3.3.3.2 filter-list 3 in

Esta configuração define um grupo de peers chamado internalmap. A configuração define algumas políticas para o grupo, como um mapa de rotas SETMETRIC para definir a métrica como 5 e duas diferentes listas de filtro, 1 e 2. A configuração aplica o grupo de peers a todos os vizinhos internos, o RTE, o RTF, e o RTG. Além disso, a configuração define uma lista de filtro separada 3 para RTE vizinho. A lista de filtros cancela a lista de filtros 2 dentro do grupo de peers.

Observação:  Só é possível cancelar opções que afetam atualizações internas.

Agora, observe como utilizar grupos de peers com vizinhos externos. Com o mesmo diagrama desta seção, vocÇe configura o RTC com um grupo de peers externalmap e aplica o grupo de peers aos vizinhos externos.

RTC#
   router bgp 300
   neighbor externalmap peer-group
   neighbor externalmap route-map SETMETRIC
   neighbor externalmap filter-list 1 out
   neighbor externalmap filter-list 2 in
   neighbor 2.2.2.2 remote-as 100
   neighbor 2.2.2.2 peer-group externalmap
   neighbor 4.4.4.2 remote-as 600
   neighbor 4.4.4.2 peer-group externalmap
   neighbor 1.1.1.2 remote-as 200
   neighbor 1.1.1.2 peer-group externalmap
   neighbor 1.1.1.2 filter-list 3 in

Observação: Nestas configurações, você define as instruções remote-as fora do grupo de peers porque deve definir ASs externos diferentes. Além disso, você pode cancelar as atualizações internas do vizinho 1.1.1.2 com a atribuição da lista de filtros 3.

Para obter mais informações sobre grupos de peers, consulte Grupos de peers do BGP.

Observação: Na versão 12.0(24)S do Cisco IOS Software, a Cisco apresentou o recurso Grupos de peers de atualização dinâmica do BGP. Esse recurso está disponível em versões posteriores do Cisco IOS Software também. O recurso introduz um novo algoritmo que calcula e otimiza dinamicamente grupos de atualizações de vizinhos que compartilham as memas políticas externas. Estes vizinhos podem compartilhar as mesmas mensagens de atualização. Em versões anteriores do Cisco IOS Software, o grupo de mensagens de atualização do BGP era à base de configurações de grupos de peers. Este método de atualizações de grupos é limitado a políticas externas e configurações de sessões específicas. O recurso Grupo de peers de atualização dinâmica do BGP réplicas de grupos de atualizações de configurações de grupos de peers. A separação melhora o tempo de convergência e a flexibilidade da configuração do vizinho. Consulte Grupos de peers de atualização dinâmica do BGP para obter mais detalhes.

Estudos de caso do BGP 4

Endereços agregados e de CIDR

bgp-toc26.gif

Um dos principais melhorias do BGP4 sobre o BGP3 é o roteamento entre domínios sem classe (CIDR). CIDR ou super-rede é um novo modo de ver endereços de IP. Como o CIDR, não há noção de classes, como classe A, B, ou C. Por exemplo, a rede 192.213.0.0 já foi uma rede ilegal de classe C. Agora, a rede é uma super-rede legal, 192.213.0.0/16. O "16" representa o número de bits na máscara da super-rede, quando você conta a partir da extrema esquerda do endereço de IP. Esta representação é semelhante a 192.213.0.0 255.255.0.0.

Você utiliza agregados para minimizar o tamanho de tabelas de roteamento. Agregação é o processo que combina as características de várias rotas diferentes de tal modo que é possível anunciar uma única rota. Neste exemplo, o RTB gera a rede 160.10.0.0. Você configura o RTC para propagar uma super-rede da rota 160.0.0.0 para o RTA:

RTB#
router bgp 200
neighbor 3.3.3.1 remote-as 300
network 160.10.0.0

#RTC
router bgp 300
neighbor 3.3.3.3 remote-as 200
neighbor 2.2.2.2 remote-as 100
network 170.10.0.0
aggregate-address 160.0.0.0 255.0.0.0 

O RTC propaga o endereço agregado 160.0.0.0 para o RTA.

Comandos agregados

Existe uma ampla faixa de comandos agregados. Você deve entender como cada um funciona para obter o comportamento de agregação desejado.

O primeiro comando é o do exemplo na seção Endereços agregados e de CIDR:

            aggregate-address address-mask
            
         

Este comando anuncia a rota de prefixo e todas as rotas mais específicas. O comando aggregate-address 160.0.0.0 propaga uma rede adicional 160.0.0.0, mas não impede a propagação de 160.10.0.0 para o RTA. O resultado é a propagação de ambas as redes 160.0.0.0 e 160.10.0.0 para o RTA, que é o anúncio da rota de prefixo e da mais específia.

Observação: Você não pode agregar um endereço se não possuir uma rota mais específica do endereço na tabela de roteamento do BGP.

Por exemplo, o RTB não pode gerar um agregado para 160.0.0.0 se não possuir uma entrada mais específica de 160.0.0.0 na tabela do BGP. A infjeção de uma rota mais específica à tabela do BGP é possível. A injeção da rota pode ocorrer por:

  • Atualizações de entrada de outros ASs

  • Redistribuição de um IGP ou estática no BGP

  • O comando network, por exemplo, network 160.10.0.0

Se desejar que o RTC propague somente a rede 160.0.0.0 e não a rota mais específica, emita este comando:

            aggregate-address address mask summary-only
         

Este comando anuncia somente o prefixo. O comando suprime todas as rotas mais específicas.

O comando aggregate 160.0.0.0 255.0.0.0 summary-only propaga a rede 160.0.0.0 e suprime a rota mais específica 160.10.0.0.

Observação: Se você agregar uma rede que injetou no BGP pelas instruções network, a entrada de rede sempre injetará atualizações no BGP. Esta injeção ocorre mesmo com a utilização do comando aggregate summary-only. O exemplo na seção Exemplo de CIDR 1 discute essa situação.

            aggregate-address address-mask as-set
         

Este comando anuncia a rota de prefixo e as rotas mais específicas. Mas o comando inclui informações de as-set nas informações de caminho das atualizações de roteamento.

            aggregate 129.0.0.0 255.0.0.0 as-set
         

A seção Exemplo de CIDR 2 (as-set) discute este comando.

Se deesejar suprimir rotas mais específicas ao fazer a agregação, defina um mapa de rotas e aplique-o aos agregados. A ação permite que você seja seletivo quanto a que rotas mais específicas suprimir.

            aggregate-address address-mask suppress-map map-name
            
         

Este comando anuncia a rota de prefixo e as rotas mais específicas. Mas o comando suprime anúncios com base em um mapa de rotas. Suponhamos que, com o diagrama na seção Endereços agregados e de CIDR, você deseje agregar 160.0.0.0, suprimir a rota mais específica 160.20.0.0 e permitir a propagação de 160.10.0.0. Utilize este mapa de rotas:

route-map CHECK permit 10
match ip address 1

access-list 1 permit 160.20.0.0 0.0.255.255
access-list 1 deny 0.0.0.0 255.255.255.255

Por definição do mapa de omissões, há uma supressão das atualizações de qualquer pacote que o limite de acesso permitir.

Então, aplique o mapa de rotas às instruções aggregate.

RTC#
router bgp 300
neighbor 3.3.3.3 remote-as 200
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 remote-as 100
network 170.10.0.0
aggregate-address 160.0.0.0 255.0.0.0 suppress-map CHECK 

Aqui está outra variação:

            aggregate-address address-mask attribute-map map-name
            
         

Este comando permite que você configure os atributos, como a métrica e o tempo de envio dos agregados. Para configurar a origem dos agregados para IGP, aplique este mapa de rotas ao comando aggregate attribute-map:

route-map SETMETRIC
set origin igp

aggregate-address 160.0.0.0 255.0.0.0 attribute-map SETORIGIN

Para obter mais informações, consulte Entendendo agregação de rotas no BGP.

Exemplo de CIDR 1

bgp-toc27.gif

Requisição: Permite que o RTB anuncie o prefixo 160.0.0.0 e suprima todas as rotas mais específicas. O problema com este requisito é que a rede 160.10.0.0 é local do AS200, o que significa que o AS200 é o originador de 160.10.0.0. Não é possível que o RTB gere um prefixo para 160.0.0.0 sem gerar uma entrada para 160.10.0.0, mesmo com a utilização do comando aggregate summary-only. O RTB gera ambas as redes, pois é o originiador de 160.10.0.0. Existem duas soluções para este problema.

A primeira solução é utilizar uma rota estática e redistribuir no BGP. O resultado é que o RTB anuncia o agregado com uma origem incompleta (?).

RTB#
router bgp 200
neighbor 3.3.3.1 remote-as 300
redistribute static

               !--- Isso gera uma atualização para 160.0.0.0
!--- com o caminho de origem como "incompleto".
            
ip route 160.0.0.0 255.0.0.0 null0

Na segunda solução, além da rota estática, você adiciona uma entrada ao comando network. Esta entrada possui o mesmo efeito, exceto que a entrada define a origem da atualização para o IGP.

RTB#
router bgp 200
network 160.0.0.0 mask 255.0.0.0

               !--- Esta entrada marca a atualização com origem IGP.
            
neighbor 3.3.3.1 remote-as 300
redistribute static
ip route 160.0.0.0 255.0.0.0 null0 

Exemplo de CIDR 2 (as-set)

A instrução as-set é utilizada em agregação para reduzir o tamanho da informação de caminho. Com as-set, o número de AS é listado apenas uma vez, independente de quantas vezes aparecer em caminhos diversos que foram agregados. Você utiliza o comando aggregate as-set em situações em que a agregação de informações causa perda de informações relacionada ao atributo de caminho. Neste exemplo, o RTC é atualizado sobre 160.20.0.0 do RTA e atualiza sobre 160.10.0.0 do RTB. Suponhamos que o RTC deseje agregar a rede 160.0.0.0/8 e enviá-la ao RTD. O RTD não conhece a origem daquela rota. Se você adicionar a instrução aggregate as-set, forçará o RTC a gerar informações de caminho no formato de um conjunto {}. Este conjunto inclui todas as informações de caminho, independente de que caminho veio primeiro.

bgp-toc28.gif

RTB#
router bgp 200
network 160.10.0.0
neighbor 3.3.3.1 remote-as 300

RTA#
router bgp 100
network 160.20.0.0
neighbor 2.2.2.1 remote-as 300

Caso 1:

O RTC não possui uma instrução as-set. O RTC envia uma atualização 160.0.0.0/8 ao RTD com informação de caminho (300), como se a rota tivesse originado no AS300.

RTC#
router bgp 300
neighbor 3.3.3.3 remote-as 200
neighbor 2.2.2.2 remote-as 100
neighbor 4.4.4.4 remote-as 400
aggregate 160.0.0.0 255.0.0.0 summary-only

               !--- Este comando faz o RTC enviar atualizações sobre 160.0.0.0/8 ao RTD
!--- sem indicar que 160.0.0.0 vem, na verdade, de dois ASs diferentes.
!--- Isso pode criar loops se o RTD possuir uma entrada no AS100 ou no AS200.
            
         

Caso 2:

RTC#
   router bgp 300
   neighbor 3.3.3.3 remote-as 200
   neighbor 2.2.2.2 remote-as 100
   neighbor 4.4.4.4 remote-as 400
   aggregate 160.0.0.0 255.0.0.0 summary-only
   aggregate 160.0.0.0 255.0.0.0 as-set

               !--- Este comando faz o RTC enviar atualizações sobre 160.0.0.0/8 ao RTD
!--- indicando que 160.0.0.0 pertence a um conjunto {100 200}.
            
         

Os próximos dois assuntos, Confederação de BGP e Refletores de rota, são para provedores de serviços da internet (ISPs) que desejam maior controle da explosão de peers iBGP dentro de seus ASs.

Confederação de BGP

A implementação da confederação de BGP reduz a malha do iBGP dentro de um AS. O truque é dividir um AS em vários ASs e atribuir o grupo todo a uma única confederação. Cada AS sozinho possui iBGP totalmente integrado e tem conexões a outros ASs dentro da confederação. Embora estes ASs possuam peers eBGP em ASs dentro da confederação, os ASs trocam roteamento como se tivessem usado o iBGP. Desta forma, a confederação preserva o próximo nó, a métrica e informações de preferência local. Para o mundo externo, a confederação parece pertencer a um único AS.

Para configurar uma confederação de BGP, emita esse comando:

            bgp confederation identifier autonomous-system
            
         

O identificador da confederação é o número de AS do grupo da confederação.

A emissão deste comando faz correspondência entre diversos ASs dentro da confederação:

            bgp confederation peers autonomous-system [autonomous-system] 
         

Abaixo encontra-se um exemplo de confederação:

bgp-toc29.gif

Suponhamos que você possui um AS500 que consiste de nove interlocutores de BGP. Também existem interlocutores que não são de BGP, mas você só está interessado em interlocutores de BGP que possuem conexões eBGP a outros ASs. Se você deseja fazer uma malha de iBGP completa no AS500, precisa de nove conexões de peer para cada roteador. Você precisa de oito peers de iBGP e um peer de eBGP para ASs externos.

Se utilizar a confederação, você pode dividir o AS500 em diversos ASs: AS50, AS60, e AS70. Você fornece ao AS um identificador de confederação 500. O mundo externo verá apenas um AS, o AS500. Para cada um, o AS50, o AS60 e o AS70, defina uma malha completa de peers de iBGP e uma lista de peers de confederação com o comando bgp confederation peers .

Aqui está um modelo de configuração dos roteadores RTC, RTD e RTA:

Observação: O RTA não tem conhecimento do AS50, do AS60, ou do AS70. O RTA tem conhecimento somente do AS500.

RTC#
router bgp 50
bgp confederation identifier 500
bgp confederation peers 60 70
neighbor 128.213.10.1 remote-as 50 (IBGP connection within AS50)
neighbor 128.213.20.1 remote-as 50 (IBGP connection within AS50)
neighbor 129.210.11.1 remote-as 60 (BGP connection with confederation peer 60)
neighbor 135.212.14.1 remote-as 70 (BGP connection with confederation peer 70)
neighbor 5.5.5.5 remote-as 100 (EBGP connection to external AS100)

RTD#
router bgp 60
bgp confederation identifier 500
bgp confederation peers 50 70
neighbor 129.210.30.2 remote-as 60 (IBGP connection within AS60)
neighbor 128.213.30.1 remote-as 50(BGP connection with confederation peer 50)
neighbor 135.212.14.1 remote-as 70 (BGP connection with confederation peer 70)
neighbor 6.6.6.6 remote-as 600 (EBGP connection to external AS600)

RTA#
   router bgp 100
   neighbor 5.5.5.4 remote-as 500 (EBGP connection to confederation 500)

Refletores de rota

Outra solução para a explosão de correspondência de iBGP em um AS são os Refletores de rota (RRs). Como a seção iBGP demonstra, um interlocutor de BGP não anuncia uma rota que aprendeu de outro interlocutor de iBGP a um terceiro interlocutor de iBGP. Você pode relaxar um pouco esta restrição e fornecer controle adicional, que permite que um roteador anuncie ou reflita rotas aprendidas por iBGP a outros interlocutores de iBGP. Esta reflexão de rota reduz o número de peers do iBGP dentro de um AS.

bgp-toc30.gif

Em casos normais, mantenha uma malha completa de iBGP entre o RTA, o RTB e o RTC no AS100. Se você utilizar o conceito RR, o RTC pode ser eleito como um RR. Desta forma, o RTC tem uma correspondência parcial de iBGP com o RTA e o RTB. Correspondência entre o RTA e o RTB não é necessária, pois o RTC é um RR para atualizações que vêm do RTA e do RTB.

            neighbor route-reflector-client
         

O roteador com este comando é o RR e os vizinhos para os quais o comando aponta são os clientes daquele RR. No exemplo, a configuração do RTC possui o comando neighbor route-reflector-client que aponta para os endereços de IP do RTA e do RTB. A combinação do RR e dos clientes é um "cluster". Neste exemplo, o RTA, o RTB e o RTC formam um cluster com um único RR no AS100.

Peers de iBGP do RR que não são clientes são "não clientes".

bgp-toc31.gif

Um AS pode ter mais de um RR. Nesta situação, um RR trata outros RRs como qualquer interlocutor de iBGP. Outros RRs podem pertencer ao mesmo cluster (grupo de clientes) ou a outros clusters. Em uma configuração simples, é possível dividir o AS em diversos clusters. Você configura cada RR com outros RRs como peers não clientes em uma topologia totalmente integrada. Clientes não devem corresponder-se com interlocutores de iBGP fora do cluster de cliente.

Considere este diagrama. O RTA, o RTB e o RTC formam um único cluster. O RTC é o RR. Para o RTC, RTA e RTB são clientes e qualquer outra coisa é um não cliente. Lembre-se que o comando neighbor route-reflector-client aponta para clientes de um RR. O mesmo RTD é o RR para clientes RTE e RTF. O RTG é um RR em um terceiro cluster.

Observação:  O RTD, o RTC e o RTG estão totalmente integrados, mas roteadores em um cluster não estão. Quando um RR recebe uma rota, esta lista mostra as rotas do RR. No entanto, esta atividade depende do tipo de peer:

  1. Rotas de um peer não cliente — Reflete para todos os clientes dentro de um cluster.

  2. Rotas de um peer cliente — Reflete para todos os peers não clientes além dos peers clientes.

  3. Rotas de um peer eBGP — Envia a atualização para todos os peers clientes e não clientes.

Aqui está a configuração de BGO relativa dos roteadores RTC, RTD e RTB:

RTC#

router bgp 100
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 route-reflector-client
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 route-reflector-client
neighbor 7.7.7.7 remote-as 100
neighbor 4.4.4.4 remote-as 100
neighbor 8.8.8.8 remote-as 200


RTB#

router bgp 100
neighbor 3.3.3.3 remote-as 100
neighbor 12.12.12.12 remote-as 300


RTD#

router bgp 100
neighbor 6.6.6.6 remote-as 100
neighbor 6.6.6.6 route-reflector-client
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 route-reflector-client
neighbor 7.7.7.7 remote-as 100
neighbor 3.3.3.3 remote-as 100

Pode haver um loop de informação de roteamento, pois há um reflexo das rotas aprendidas do iBGP. O esquema do RR possui alguns métodos para evitar este loop:

  • originator-id — Este é um atributo opcional e intransitivo de BGP com o tamanho de 4 bytes. Um RR cria este atributo. O atributo carrega a ID do roteador (RID) do originador da rota no AS local. Se, por causa de configurações ruins, as informações de roteamento retornarem ao originador, as informações são ignoradas.

  • cluster-list — A seção Diversos RRs em um cluster cobre a lista de clusters.

Diversos RRs em um cluster

bgp-toc32.gif

Normalmente, um cluster de clientes possui um único RR. Neste caso, a ID do roteador do RR identifica o cluster. Para aumentar a redundância e evitar pontos únicos de falhas, um cluster pode ter mais de um RR. É preciso configurar todos os RRs no mesmo cluster com uma ID de cluster de 4 bytes para que o RR possa reconhecer atualizações de RRs no mesmo cluster.

Uma lista de clusters é uma seqüência de IDs de cluster que a rota passou. Quando um RR reflete uma rota dos clientes de RR para não clientes fora do cluster, ele anexa a ID de cluster local à lista de clusters. Se esta atualização tiver uma lista de clusters vazia, o RR cria uma. Com este atributo, um RR pode identificar se as informações de roteamento sofreram loopback para o mesmo cluster por causa de configurações ruins. Se a ID de cluster local for encontrada na lista de clusters, o anúncio será igonorado.

No diagrama desta seção, o RTD, o RTE, o RTF e o RTH pertencem a um cluster. Tanto o RTD quanto o RTH são RRs do mesmo cluster.

Observação: Ocorre redundância porque o RTH possui correspondência totalmente integrada com todos os RRs. Se o RTD ficar inativo, o RTH toma seu lugar.

Aqui está a configuração do RTH, do RTD, do RTF e do RTC:

RTH#

router bgp 100
neighbor 4.4.4.4 remote-as 100
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 route-reflector-client
neighbor 6.6.6.6 remote-as 100
neighbor 6.6.6.6 route-reflector-client
neighbor 7.7.7.7 remote-as 100
neighbor 3.3.3.3 remote-as 100
neighbor 9.9.9.9 remote-as 300
bgp cluster-id 10


RTD#

router bgp 100
neighbor 10.10.10.10 remote-as 100
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 route-reflector-client
neighbor 6.6.6.6 remote-as 100
neighbor 6.6.6.6 route-reflector-client
neighbor 7.7.7.7 remote-as 100
neighbor 3.3.3.3 remote-as 100
neighbor 11.11.11.11 remote-as 400
bgp cluster-id 10


RTF#

router bgp 100
neighbor 10.10.10.10 remote-as 100
neighbor 4.4.4.4 remote-as 100
neighbor 13.13.13.13 remote-as 500


RTC#

router bgp 100
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 route-reflector-client
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 route-reflector-client
neighbor 4.4.4.4 remote-as 100
neighbor 7.7.7.7 remote-as 100
neighbor 10.10.10.10 remote-as 100
neighbor 8.8.8.8 remote-as 200

Observação: Você não precisa do comando bgp cluster-id para o RTC, pois só existe um RR naquele cluster.

Observação importante: Esta configuração não utiliza grupos de peer. Não utilize grupos de peer se os clientes dentro de um cluster não possuírem peers de iBGP diretos entre si e os clientes trocarem atualizações pelo RR. Se você configura grupos de peer, uma retirada potencial para a origem de uma rota no RR transmite para todos os clientes no cluster. Essa transmissão pode causar problemas.

O subcomando do roteador bgp client-to-client reflection está habilitado por padrão no RR. Se você desligar o reflexo cliente para cliente do BGP no RR e fazer correspondências de BGP redundantes entre os clientes, pode utilizar grupos de peer com segurança.

Interlocutores de BGP convencionais e RR

Um AS pode ter interlocutores de BGP que não entendem o conceito de RRs. Este documento chama estes roteadores de interlocutores de BGP convencionais. O esquema de RR permite que interlocutores de BGP convencionais coexistam. Estes roteadores podem ser membros de um grupo de clientes ou de não clientes. A existência destes roteadores permite migrações graduais e fáceis do modelo de iBGP atual para o modelo de RR. Você pode começar a criar clusters se configurar um único roteador como RR e tornar outros RRs e clientes de RR peers de iBGP normais. Depois, você pode criar mais clusters gradualmente.

bgp-toc33.gif

Neste diagrama, o RTD, o RTE e o RTF têm o conceito de reflexo de rotas. O RTC, o RTA e o RTB são roteadores "convencionais". Não é possível configurar estes roteadores como RRs. Você pode fazer uma malha de iBGP normal entre ester roteadores e o RTD. Mais tarde, quando estiver pronto para melhorar, você pode tornar o RTC um RR com os clientes RTA e RTB. Clientes não precisam entender o esquema de reflexo de rotas; somente os RRs precisam de atualização.

Aqui está a configuração do RTD e do RTC:

RTD#

router bgp 100
neighbor 6.6.6.6 remote-as 100
neighbor 6.6.6.6 route-reflector-client
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 route-reflector-client
neighbor 3.3.3.3 remote-as 100
neighbor 2.2.2.2 remote-as 100
neighbor 1.1.1.1 remote-as 100
neighbor 13.13.13.13 remote-as 300


RTC#

router bgp 100
neighbor 4.4.4.4 remote-as 100
neighbor 2.2.2.2 remote-as 100
neighbor 1.1.1.1 remote-as 100
neighbor 14.14.14.14 remote-as 400

Quando estiver pronto para melhorar o RTC e torná-lo um RR, remova a malha completa do uBGP e faça com que o RTA e o RTB tornem-se clientes do RTC.

Evitar loop de informações de roteamento

Por enquanto, este documento mencionou dois atrubutos que podem ser usados para evitar um loop de informações potencial: originator-id e cluster-list.

Outro modo de controlar loops é colocando mais restrições na cláusula de definição de mapas de rotas externas. A cláusula de definição para mapas de rotas externas não afeta rotas que refletem para peers de iBGP.

Você também pode colocar mais restrições em nexthop-self, que é uma opção de configuração por vizinho. Ao utilizar nexthop-self em RRs, a cláusula afeta somente o próximo nó de rotas aprendidas do eBGP, pois o próximo nó de rotas refletidas não deve ser alterado.

Retarndamento de sincronismo de rota

A versão 11.0 do Cisco IOS Software introduziu o retardamento de rota. Retardamento de rota é um mecanismo para minimizar a instabilidade causada por sincronismo de rota. Retardamento de rota também reduz a oscilação sobre a rede. Você define os critérios para identificar rotas com mal comportamento. Uma rota que sincroniza recebe uma pena de 1000 para cada sincronismo. Assim que a pena cumulativa chega a um "limite de supressão" predefinido, ocorre supressão do anúncio de rota. A pena decai exponencialmente baseada em um "período de meia-vida" pré-configurado. Uma vez que a pena diminui até um "limite de reutilização" predefinido, ocorre a insupressão do anúncio de rota.

O retardamento de rota não se aplica a rotas externas a um AS e aprendidas por iBGP. Dessa forma, o retardamento de rota evita uma pena maior para os peers de iBGP de rotas externas ao AS.

A pena decai a uma granularidade de 5 segundos. A insupressão das rotas ocorre a uma granularidade de 10 segundos. O roteador mantém as informações de retardo até que a pena torne-se menos que a metade do "limite de reutilização". Neste ponto, o roteador limpa as informações.

Inicialmente, o retardamento está desativado por padrão. Se houver necessidade, este recurso pode receber habilitação por padrão no futuro. Estes comandos controlam o retardamento de rota:

  • bgp dampening — Ativa o retardamento.

  • no bgp dampening — Desativa o retardamento.

  • bgp dampening half-life-time — Altera o período de meia-vida.

Um comando que define todos os parâmetros ao mesmo tempo é:

  • bgp dampening half-life-time reuse suppress maximum-suppress-time

Esta lista detalha a sintaxe:

  • half-life-time — O alcance é de 1–45 minutos e o padrão atual é de 15 minutos.

  • reuse-value — O alcance é de 1–20,000 e o padrão é de 750.

  • suppress-value — O alcance é de 1–20,000 e o padrão é de 2000.

  • max-suppress-time — Esta é a duração máxima da supressão de uma rota. O alcance é de 1–255 minutos e o padrão é de 4 vezes o período de meia-vida.

bgp-toc34.gif

RTB#
hostname RTB

interface Serial0
 ip address 203.250.15.2 255.255.255.252

interface Serial1
 ip address 192.208.10.6 255.255.255.252

router bgp 100
 bgp dampening
 network 203.250.15.0
 neighbor 192.208.10.5 remote-as 300


RTD#
hostname RTD

interface Loopback0
ip address 192.208.10.174 255.255.255.192

interface Serial0/0
 ip address 192.208.10.5 255.255.255.252

router bgp 300
 network 192.208.10.0
 neighbor 192.208.10.6 remote-as 100

A configuração de RTB é para retardamento de rede com parâmetros padrão. Supondo que o link do eBGP ao RTD seja estável, a tabela de BGP do RTB é semelhante a:

RTB# show ip bgp
BGP table version is 24, local router ID is 203.250.15.2 Status codes: s
suppressed, d damped, h history, * valid, > best, i - internal Origin
codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop          Metric LocPrf Weight Path
*> 192.208.10.0     192.208.10.5           0             0 300 i
*> 203.250.15.0     0.0.0.0                0         32768 i

Para simular um sincronismo de rota, emita o comando clear ip bgp 192.208.10.6 no RTD. A tabela de BGP do RTB é semelhante a:

RTB# show ip bgp
BGP table version is 24, local router ID is 203.250.15.2 Status codes: s
suppressed, d damped, h history, * valid, > best, i - internal Origin
codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop          Metric LocPrf Weight Path
 h 192.208.10.0     192.208.10.5           0             0 300 i
*> 203.250.15.0     0.0.0.0                0         32768 i

A entrada do BGP para 192.208.10.0 está em um estado histórico . Esta localização significa que você não tem um caminho melhor para a rota, mas ainda existe informação sobre a sincronia da rota.

RTB# show ip bgp 192.208.10.0
BGP routing table entry for 192.208.10.0 255.255.255.0, version 25
Paths: (1 available, no best path)
300 (history entry)
    192.208.10.5 from 192.208.10.5 (192.208.10.174)
Origin IGP, metric 0, external
Dampinfo: penalty 910, flapped 1 times in 0:02:03

A rota recebeu uma pena por sincronismo, mas a pena ainda está abaixo do "limite de supressão". O padrão é 2000. A supressão de rota ainda não ocorreu. Se ocorrer o sincronismo de rota mais algumas vezes, você verá:

RTB# show ip bgp
BGP table version is 32, local router ID is 203.250.15.2 Status codes:
s suppressed, d damped, h history, * valid, > best, i - internal Origin codes:
i - IGP, e - EGP, ? - incomplete

   Network          Next Hop          Metric LocPrf Weight Path
*d 192.208.10.0     192.208.10.5           0             0  300 i
*> 203.250.15.0     0.0.0.0               0       32768  i

RTB# show ip bgp 192.208.10.0
BGP routing table entry for 192.208.10.0 255.255.255.0, version 32
Paths: (1 available, no best path)
300, (suppressed due to dampening)
192.208.10.5 from 192.208.10.5 (192.208.10.174)
      Origin IGP, metric 0, valid, external
Dampinfo: penalty 2615, flapped 3 times in 0:05:18 , reuse in 0:27:00

A rota foi retardada ou suprimida. A rota é reutilizada quando a pena alcança "valor de reutilização". Neste caso, o valor de reutilização é o padrão, 750. As informações de retardamento são limpas quando a pena torna-se menor do que metade do limite de reutilização. Neste caso, a limpeza ocorre quando a pena torna-se 375 (750/2=375). Estes comandos exibem e limpam informações de estatística de sincronismo:

  • show ip bgp flap-statistics — Exibe estatísticas de sincronismo para todos os caminhos.

  • show ip bgp flap-statistics regexp regular-expression — Exibe estatísticas de sincronismo para todos os caminhos que correspondem a expressões regulares.

  • show ip bgp flap-statistics filter-list list — Exibe estatísticas de sincronismo para todos os caminhos que passem pelo filtro.

  • show ip bgp flap-statistics A.B.C.D m.m.m.m — Exibe estatísticas de sincronismo para uma única entrada.

  • show ip bgp flap-statistics A.B.C.D m.m.m.m — Exibe estatísticas de sincronismo para entradas mais específicas.

  • show ip bgp neighbor [dampened-routes] | [flap-statistics] — Exibe estatísticas de sincronismo para todos os caminhos de um vizinho.

  • clear ip bgp flap-statistics — Limpa estatísticas de sincronismo para todas as rotas.

  • clear ip bgp flap-statistics regexp regular-expression — Limpa estatísticas de sincronismo para todos os caminhos que correspondem a expressões regulares.

  • clear ip bgp flap-statistics filter-list list — Limpa estatísticas de sincronismo para todos os caminhos que passem pelo filtro.

  • clear ip bgp flap-statistics A.B.C.D m.m.m.m — Limpa estatísticas de sincronismo para uma única entrada.

  • clear ip bgp A.B.C.D flap-statistics — Limpa estatísticas de sincronismo para todos os caminhos de um vizinho.

Com o BGP seleciona um caminho

Agora que você está familiarizado com atributos e terminologia do BGP, consulte Algoritmo de seleção de melhor caminho do BGP.

Estudos de caso do BGP 5

Exemplo de projeto prático

Esta seção contém um exemplo de projeto que mostra as tabelas de configuração e de roteamento conforme as tabelas realmente aparecem em roteadores da Cisco.

bgp-toc35.gif

Esta seção mostra como construir esta configuração passo a passo e o que pode dar errado no caminho. Quando você possuir um AS que conecta-se a dois ISPs por eBGP, sempre execute o iBGP no seuu AS para ter maior controle sobre suas rotas. Neste exemplo, o iBGP executa dentro do AS100 entre o RTA e o RTB, e o OSPF executa como um IGP. Suponhamos que você se conecte a dois ISPs, o AS200 e o AS300. Esta é a primeira execução das configurações para todos os roteadores:

Observação: Essas não são as configurações finais.

RTA#
hostname RTA

ip subnet-zero

interface Loopback0
 ip address 203.250.13.41 255.255.255.0

interface Ethernet0
ip address 203.250.14.1 255.255.255.0

interface Serial0
 ip address 128.213.63.1 255.255.255.252

router ospf 10
 network 203.250.0.0 0.0.255.255 area 0

router bgp 100
 network 203.250.13.0
 network 203.250.14.0
 neighbor 128.213.63.2 remote-as 200
 neighbor 203.250.15.2 remote-as 100
 neighbor 203.250.15.2 update-source Loopback0

RTF#
hostname RTF

ip subnet-zero

interface Ethernet0
 ip address 203.250.14.2 255.255.255.0

interface Serial1
 ip address 203.250.15.1 255.255.255.252

router ospf 10
 network 203.250.0.0 0.0.255.255 area 0

RTB#
hostname RTB

ip subnet-zero

interface Serial0
 ip address 203.250.15.2 255.255.255.252

interface Serial1
 ip address 192.208.10.6 255.255.255.252

router ospf 10
 network 203.250.0.0 0.0.255.255 area 0

router bgp 100
network 203.250.15.0
 neighbor 192.208.10.5 remote-as 300
 neighbor 203.250.13.41 remote-as 100

RTC#
hostname RTC

ip subnet-zero

interface Loopback0
 ip address 128.213.63.130 255.255.255.192

interface Serial2/0
 ip address 128.213.63.5 255.255.255.252
!
interface Serial2/1
 ip address 128.213.63.2 255.255.255.252

router bgp 200
 network 128.213.0.0
 neighbor 128.213.63.1 remote-as 100
 neighbor 128.213.63.6 remote-as 400

RTD#
hostname RTD

ip subnet-zero

interface Loopback0
ip address 192.208.10.174 255.255.255.192

interface Serial0/0
 ip address 192.208.10.5 255.255.255.252
!
interface Serial0/1
 ip address 192.208.10.2 255.255.255.252

router bgp 300
 network 192.208.10.0
 neighbor 192.208.10.1 remote-as 500
 neighbor 192.208.10.6 remote-as 100

RTE#
hostname RTE

ip subnet-zero

interface Loopback0
ip address 200.200.10.1 255.255.255.0

interface Serial0
 ip address 195.211.10.2 255.255.255.252

interface Serial1
 ip address 128.213.63.6 255.255.255.252
 clockrate 1000000

router bgp 400
 network 200.200.10.0
 neighbor 128.213.63.5 remote-as 200
 neighbor 195.211.10.1 remote-as 500

RTG#
hostname RTG

ip subnet-zero

interface Loopback0
 ip address 195.211.10.174 255.255.255.192

interface Serial0
 ip address 192.208.10.1 255.255.255.252

interface Serial1
 ip address 195.211.10.1 255.255.255.252

router bgp 500
 network 195.211.10.0
 neighbor 192.208.10.2 remote-as 300
 neighbor 195.211.10.2 remote-as 400

Sempre utilize o comando network ou redistribua entradas estáticas no BGP para anunciar redes. Este método é melhor do que redistribuição de IGP no BGP. O exemplo utiliza o comando networkpara injetarredes no BGP.

Aqui, você inicia com a interface s1 no fechamento do RTB, como se o vínculo entre o RTB e o RTD não existisse. Esta é a tabela de BGP do RTB:

RTB# show ip bgp BGP
table version is 4, local router ID is 203.250.15.2 Status
codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
     Network          Next Hop          Metric LocPrf Weight Path
*i128.213.0.0      128.213.63.2           0    100      0 200 i
*i192.208.10.0     128.213.63.2                100      0 200 400 500
300 i
*i195.211.10.0     128.213.63.2                100      0 200 400 500 i
*i200.200.10.0     128.213.63.2                100      0 200 400 i
*>i203.250.13.0    203.250.13.41          0    100      0 i
*>i203.250.14.0    203.250.13.41          0    100      0 i
*>203.250.15.0     0.0.0.0                0         32768 i

Nesta tabela aparecem estas notas:

  • Um i no começo — Indica que a entrada foi aprendida por um peer do iBGP.

  • Um i no fim — Indica que a origem da informação de caminho é IGP.

  • Informação de caminho — Esta informação é intuitiva. Por exemplo, a rede 128.213.0.0 foi aprendida pelo caminho 200 com um próximo nó de 128.213.63.2.

    Observação: Qualquer entrada gerada localmente, como 203.250.15.0, tem um próximo nó 0.0.0.0.

  • Um > — Indica que o BGP escolheu a melhor rota. O BGP utiliza os passos de decisão que o documento Algoritmo de seleção de melhor caminho do BGP descreve. O BGP escolhe um melhor caminho para alcançar um destino, instala o caminho na tabela de IP Routing e anuncia o caminho para outros peers de BGP.

    Observação: Observe o atributo Próximo nó . O RTB conhece o 128.213.0.0 pelo próximo nó 128.213.63.2, que é o próximo nó do eBGP carregado no iBGP.

Observe a tabela de IP routing:

RTB# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate
default

Gateway of last resort is not set

     203.250.13.0 255.255.255.255 is subnetted, 1 subnets
O       203.250.13.41 [110/75] via 203.250.15.1, 02:50:45, Serial0
     203.250.15.0 255.255.255.252 is subnetted, 1 subnets
C       203.250.15.0 is directly connected, Serial0
O    203.250.14.0 [110/74] via 203.250.15.1, 02:50:46, Serial0

Aparentemente, nenhuma das entradas de BGP alcançou a tabela de roteamento. Existem dois problemas aqui.

O primeiro problema é que é impossível alcançar o próximo nó para estas entradas, 128.213.63.2. Não há como alcançar aquele próximo nó por este IGP, que é OSPF. O RTB não aprendeu sobre 128.213.63.0 pelo OSPF. É possível executar o OSPF na interface s0 do RTA e torná-lo passivo; dessa forma, o RTB sabe como alcançar o próximo nó 128.213.63.2. Esta configuração de RTA aparece aqui:

RTA#
hostname RTA

ip subnet-zero

interface Loopback0
 ip address 203.250.13.41 255.255.255.0

interface Ethernet0
ip address 203.250.14.1 255.255.255.0

interface Serial0
 ip address 128.213.63.1 255.255.255.252

router ospf 10
 passive-interface Serial0
 network 203.250.0.0 0.0.255.255 area 0
 network 128.213.0.0 0.0.255.255 area 0

router bgp 100
 network 203.250.0.0 mask 255.255.0.0
 neighbor 128.213.63.2 remote-as 200
 neighbor 203.250.15.2 remote-as 100
 neighbor 203.250.15.2 update-source Loopback0

Observação: Você pode emitir o comando bgp nexthopself entre o RTA e o RTB para alterar o próximo nó.

A nova tabela de BGP no RTB é semelhante a:

RTB# show ip bgp
BGP table version is 10, local router ID is 203.250.15.2
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop          Metric LocPrf Weight Path
*>i128.213.0.0      128.213.63.2           0    100      0 200 i
*>i192.208.10.0     128.213.63.2                100      0 200 400 500
300 i
*>i195.211.10.0     128.213.63.2                100      0 200 400 500 i
*>i200.200.10.0     128.213.63.2                100      0 200 400 i
*>i203.250.13.0     203.250.13.41          0    100      0 i
*>i203.250.14.0     203.250.13.41          0    100      0 i
*> 203.250.15.0     0.0.0.0                0         32768 i

Observação: Todas as entradas têm >, que significa que o BGP pode alcançar o próximo nó.

Observe a tabela de roteamento:

RTB# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * -
candidate default

Gateway of last resort is not set

     203.250.13.0 255.255.255.255 is subnetted, 1 subnets
O       203.250.13.41 [110/75] via 203.250.15.1, 00:04:46, Serial0
     203.250.15.0 255.255.255.252 is subnetted, 1 subnets
C       203.250.15.0 is directly connected, Serial0
O    203.250.14.0 [110/74] via 203.250.15.1, 00:04:46, Serial0
     128.213.0.0 255.255.255.252 is subnetted, 1 subnets
O       128.213.63.0 [110/138] via 203.250.15.1, 00:04:47, Serial0

O segundo problema é que você ainda não vê as entradas de BGP na tabela de roteamento. A única diferença é que 128.213.63.0 agora pode ser alcançado por OSPF. Este problema é uma questão de sincronização. O BGP não coloca estas entradas na tabelas de roteamento e não envia as entradas em atualizações de BGP por causa de uma falta de sincronização com o IGP.

Observação: O RTF não tem noção de redes 192.208.10.0 e 195.211.10.0 porque você ainda não redistribuiu BGP em OSPF.

Neste cenário, se você desativar a sincronização, as entradas aparecerão na tabela de roteamento. Mas a conectividade ainda estará quebrada.

Isso é o que acontecerá se você desativar a sincronização no RTB:

RTB# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * -
candidate default

Gateway of last resort is not set

B    200.200.10.0 [200/0] via 128.213.63.2, 00:01:07
B    195.211.10.0 [200/0] via 128.213.63.2, 00:01:07
B    192.208.10.0 [200/0] via 128.213.63.2, 00:01:07
     203.250.13.0 is variably subnetted, 2 subnets, 2 masks
O       203.250.13.41 255.255.255.255
           [110/75] via 203.250.15.1, 00:12:37, Serial0
B       203.250.13.0 255.255.255.0 [200/0] via 203.250.13.41, 00:01:08
     203.250.15.0 255.255.255.252 is subnetted, 1 subnets
C       203.250.15.0 is directly connected, Serial0
O    203.250.14.0 [110/74] via 203.250.15.1, 00:12:37, Serial0
     128.213.0.0 is variably subnetted, 2 subnets, 2 masks
B       128.213.0.0 255.255.0.0 [200/0] via 128.213.63.2, 00:01:08
O       128.213.63.0 255.255.255.252
           [110/138] via 203.250.15.1, 00:12:37, Serial0

A tabela de roteamento parece normal, mas não há como alcançar aquelas redes. O RTF no meio não sabe como alcançar as redes:

RTF# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * -
candidate default

Gateway of last resort is not set

     203.250.13.0 255.255.255.255 is subnetted, 1 subnets
O       203.250.13.41 [110/11] via 203.250.14.1, 00:14:15, Ethernet0
     203.250.15.0 255.255.255.252 is subnetted, 1 subnets
C       203.250.15.0 is directly connected, Serial1
C    203.250.14.0 is directly connected, Ethernet0
     128.213.0.0 255.255.255.252 is subnetted, 1 subnets
O       128.213.63.0 [110/74] via 203.250.14.1, 00:14:15, Ethernet0

Ao desativar a sincronização nesta situação, o problema ainda existe. Mas você precisará da sincronização mais tarde para outras questões. Redistribua o BGP em OSPF no RTA, com uma métrica de 2000:

RTA#
hostname RTA

ip subnet-zero

interface Loopback0
 ip address 203.250.13.41 255.255.255.0

interface Ethernet0
ip address 203.250.14.1 255.255.255.0

interface Serial0
 ip address 128.213.63.1 255.255.255.252

router ospf 10
 redistribute bgp 100 metric 2000 subnets
 passive-interface Serial0
 network 203.250.0.0 0.0.255.255 area 0
 network 128.213.0.0 0.0.255.255 area 0

router bgp 100
 network 203.250.0.0 mask 255.255.0.0
 neighbor 128.213.63.2 remote-as 200
 neighbor 203.250.15.2 remote-as 100
 neighbor 203.250.15.2 update-source Loopback0

A tabela de roteamento é semelhante a:

RTB# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * -
candidate default

Gateway of last resort is not set

O E2 200.200.10.0 [110/2000] via 203.250.15.1, 00:00:14, Serial0
O E2 195.211.10.0 [110/2000] via 203.250.15.1, 00:00:14, Serial0
O E2 192.208.10.0 [110/2000] via 203.250.15.1, 00:00:14, Serial0
     203.250.13.0 is variably subnetted, 2 subnets, 2 masks
O       203.250.13.41 255.255.255.255
           [110/75] via 203.250.15.1, 00:00:15, Serial0
O E2    203.250.13.0 255.255.255.0
           [110/2000] via 203.250.15.1, 00:00:15, Serial0
     203.250.15.0 255.255.255.252 is subnetted, 2 subnets
C       203.250.15.8 is directly connected, Loopback1
C       203.250.15.0 is directly connected, Serial0
O    203.250.14.0 [110/74] via 203.250.15.1, 00:00:15, Serial0
     128.213.0.0 is variably subnetted, 2 subnets, 2 masks
O E2    128.213.0.0 255.255.0.0 [110/2000] via 203.250.15.1,
00:00:15,Serial0
O       128.213.63.0 255.255.255.252
           [110/138] via 203.250.15.1, 00:00:16, Serial0

As entradas de BGP disapareceram porque o OSPF tem uma distância melhor que o iBGP. A distância do OSPF é 110, enquanto a do iBGP é 200.

Desative a sincronização no RTA para que ele possa anunciar 203.250.25.0. Esta ação é necessária, pois o RTA não faz sincronização com o OSPF por causa da diferença em máscaras. Mantenha a sincronização desativada no RTB para que ele possa anunciar 203.250.13.0. Esta ação é necessária no RTB pela mesma razão.

Agora, ative a interface s1 do RTB para ver como são as rotas. Além disso, habilite o OSPF em serial 1 do RTB para torná-lo passivo. Esta etapa permite que o RTA saiba sobre o próximo nó 192.208.10.5 pelo IGP. Se você não concluir esta etapa, ocorrerão loops de roteamento, pois, para alcançar o próximo nó 192.208.10.5, você precisa ir para o outro lado pelo eBGP. Estas são as novas configurações do RTA e do RTB:

RTA#
hostname RTA

ip subnet-zero

interface Loopback0
 ip address 203.250.13.41 255.255.255.0

interface Ethernet0
ip address 203.250.14.1 255.255.255.0

interface Serial0
 ip address 128.213.63.1 255.255.255.252

router ospf 10
 redistribute bgp 100 metric 2000 subnets
 passive-interface Serial0
 network 203.250.0.0 0.0.255.255 area 0
 network 128.213.0.0 0.0.255.255 area 0

router bgp 100
 no synchronization
 network 203.250.13.0
 network 203.250.14.0
 neighbor 128.213.63.2 remote-as 200
 neighbor 203.250.15.2 remote-as 100
 neighbor 203.250.15.2 update-source Loopback0

RTB#
hostname RTB

ip subnet-zero

interface Serial0
 ip address 203.250.15.2 255.255.255.252

interface Serial1
 ip address 192.208.10.6 255.255.255.252

router ospf 10
 redistribute bgp 100 metric 1000 subnets
 passive-interface Serial1
 network 203.250.0.0 0.0.255.255 area 0
 network 192.208.0.0 0.0.255.255 area 0

router bgp 100
 no synchronization
 network 203.250.15.0
 neighbor 192.208.10.5 remote-as 300
 neighbor 203.250.13.41 remote-as 100

As tabelas de BGP do RTB são semelhantes a:

RTA# show ip bgp
BGP table version is 117, local router ID is 203.250.13.41
Status codes: s suppressed, d damped, h history, * valid, > best,
i -internal Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop          Metric LocPrf Weight Path
*> 128.213.0.0      128.213.63.2           0             0 200 i
*>i192.208.10.0     192.208.10.5           0    100      0 300 i
*>i195.211.10.0     192.208.10.5                100      0 300 500 i
*                   128.213.63.2                         0 200 400 500 i
*> 200.200.10.0     128.213.63.2                         0 200 400 i
*> 203.250.13.0     0.0.0.0                0         32768 i
*> 203.250.14.0     0.0.0.0                0         32768 i
*>i203.250.15.0     203.250.15.2           0    100      0 i

RTB# show ip bgp
BGP table version is 12, local router ID is 203.250.15.10
Status codes: s suppressed, d damped, h history, * valid, > best,
i -internal Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop          Metric LocPrf Weight Path
*>i128.213.0.0      128.213.63.2           0    100      0 200 i
*                   192.208.10.5                         0 300 500 400
200 i
*> 192.208.10.0     192.208.10.5           0             0 300 i
*> 195.211.10.0     192.208.10.5                         0 300 500 i
*>i200.200.10.0     128.213.63.2                100      0 200 400 i
*                   192.208.10.5                         0 300 500 400 i
*>i203.250.13.0     203.250.13.41          0    100      0 i
*>i203.250.14.0     203.250.13.41          0    100      0 i
*> 203.250.15.0     0.0.0.0                0         32768 i

Há diversas formas de projetar sua rede para falar com dois ISPs diferentes, o AS200 e o AS300. Uma delas é ter um ISP primário e um ISP de backup. Você aprende rotas parciais de um dos ISPs e rotas padrão de ambos os ISPs. Neste exemplo, você recebe rotas parciais do AS200 e apenas rotas locais do AS300. Ambos o RTA e o RTB geram rotas parciais para o OSPF, com o RTB como preferência por causa da métrica menor. Desta forma, você pode balancear tráfigo externo entre os dois ISPs.

Assimetria potencial pode ocorrer se o tráfego que sai do RTA voltar pelo RTB. Esta situação pode ocorrer se você utilizar o mesmo conjunto de endereços de IP, a mesma rede principal, ao falar com dois ISPs. Por causa da agregação, todo o seu AS pode parecer uma entidade inteira para o mundo externo. Pontos de entrada para a sua rede podem ocorrer pelo RTA ou pelo RTB. Você pode descobrir que todo tráfego interno do seu AS chega por um único ponto, embora você tenha diversos pontos para a internet. No exemplo, você possui duas redes principais diferentes ao falar com os doisz ISPs.

Outra razão potencial para a assimetria é o diferente tamanho de caminho anunciado a chegar no seu AS. Talvez um provedor de serviços esteja mais perto de certo destino do que outro. No exemplo, tráfego do AS400 que tem sua rede como destino sempre vem pelo RTA por causa do caminho mais curto. Você pode tentar afetar esta decisão. Você pode utilizar o comando set as-path prepend para anexar números de caminho às suas atualizações e fazer a distância do caminho parecer mais comprida. Mas, com atributos como preferência local, métrica ou ponderância, o AS400 pode ter definido o ponto de saída como o AS200. Nesse caso, não há nada que você possa fazer.

Esta configuração é a configuração final para todos os roteadores:

RTA#
hostname RTA

ip subnet-zero

interface Loopback0
 ip address 203.250.13.41 255.255.255.0

interface Ethernet0
 ip address 203.250.14.1 255.255.255.0

interface Serial0
 ip address 128.213.63.1 255.255.255.252

router ospf 10
 redistribute bgp 100 metric 2000 subnets
 passive-interface Serial0
 network 203.250.0.0 0.0.255.255 area 0
 network 128.213.0.0 0.0.255.255 area 0
 default-information originate metric 2000

router bgp 100
 no synchronization
network 203.250.13.0
 network 203.250.14.0
 neighbor 128.213.63.2 remote-as 200
 neighbor 128.213.63.2 route-map setlocalpref in
 neighbor 203.250.15.2 remote-as 100
 neighbor 203.250.15.2 update-source Loopback0

ip classless
ip default-network 200.200.0.0

route-map setlocalpref permit 10
 set local-preference 200

No RTA, a preferência local para rotas que vêm do AS200 está configurada para 200. Além disso, a rede 200.200.0.0 é a escolha para padrão de candidato. O comando ip default-network permite escolher o padrão.

Também neste exemplo, a utilização do comando default-information originate com o OSPF injeta a rota padrão dentro do domínio de OSPF. Este exemplo também utiliza este comando com o Protocolo sistema intermediário a sistema intermediário (IS-IS Protocol) e com o BGP. Para o RIP, há uma redistribuição automática no RIP de 0.0.0.0, sem configuração adicional. Para o IGRP e o EIGRP, a injeção da informação padrão no domínio de IGP ocorre após redistribuição do BGP no IGRP e no EIGRP. Além disso, com o IGRP e o EIGRP, você pode redistribuir uma rota estática para 0.0.0.0 no domínio de IGP.

RTF#
hostname RTF

ip subnet-zero

interface Ethernet0
 ip address 203.250.14.2 255.255.255.0

interface Serial1
 ip address 203.250.15.1 255.255.255.252

router ospf 10
 network 203.250.0.0 0.0.255.255 area 0

ip classless

RTB#
hostname RTB

ip subnet-zero

interface Loopback1
 ip address 203.250.15.10 255.255.255.252

interface Serial0
 ip address 203.250.15.2 255.255.255.252
!
interface Serial1
 ip address 192.208.10.6 255.255.255.252

router ospf 10
 redistribute bgp 100 metric 1000 subnets
 passive-interface Serial1
 network 203.250.0.0 0.0.255.255 area 0
 network 192.208.10.6 0.0.0.0 area 0
 default-information originate metric 1000
!
router bgp 100
 no synchronization
 network 203.250.15.0
 neighbor 192.208.10.5 remote-as 300
 neighbor 192.208.10.5 route-map localonly in
 neighbor 203.250.13.41 remote-as 100
!
ip classless
ip default-network 192.208.10.0
ip as-path access-list 1 permit ^300$

route-map localonly permit 10
 match as-path 1
set local-preference 300

Para o RTB, a preferência local para atualizações que vem do AS300 está configurada para 300. Este valor é mais alto que o valor de preferência local de atualizações do iBGP que vêm do RTA. Deste modo, o AS100 escolhe o RTB para rotas locais do AS300. Quaisquer outras rotas no, se existirem outras rotas, transmitem internamente com uma preferência local de 100. Este valor é menos que a preferência local de 200, que vem do RTA. Portanto o RTA é a preferência.

Observação: Você anuncia apenas as rotas locais do AS300. Qualquer informação de caminho que não corresponder a ^300$ é descartada. Se desejar anunciar as rotas locais e as rotas vizinhas, que são clientes do ISP, utilize ^300_[0-9]*.

Aqui está a saída de expressões regulares que indica as rotas locais do AS300:

RTB# show ip bgp regexp ^300$
BGP table version is 14, local router ID is 203.250.15.10
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop          Metric LocPrf Weight Path
*> 192.208.10.0     192.208.10.5           0    300      0 300

RTC#
hostname RTC

ip subnet-zero

interface Loopback0
 ip address 128.213.63.130 255.255.255.192

interface Serial2/0
 ip address 128.213.63.5 255.255.255.252
!
interface Serial2/1
 ip address 128.213.63.2 255.255.255.252

router bgp 200
 network 128.213.0.0
 neighbor 128.213.63.1 remote-as 100
 neighbor 128.213.63.1 distribute-list 1 out
 neighbor 128.213.63.6 remote-as 400

ip classless
access-list 1 deny   195.211.0.0 0.0.255.255
access-list 1 permit any

No RTC, você agrega 128.213.0.0/16 e indica as rotas específicas para injeção no AS100. Se o ISP recusar-se a realizar esta tarefa, você deve filtrar a extremidade de entrada do AS100.

RTD#
hostname RTD

ip subnet-zero

interface Loopback0
 ip address 192.208.10.174 255.255.255.192
!
interface Serial0/0
 ip address 192.208.10.5 255.255.255.252
!
interface Serial0/1
 ip address 192.208.10.2 255.255.255.252

router bgp 300
 network 192.208.10.0
 neighbor 192.208.10.1 remote-as 500
 neighbor 192.208.10.6 remote-as 100

RTG#
hostname RTG

ip subnet-zero

interface Loopback0
 ip address 195.211.10.174 255.255.255.192

interface Serial0
 ip address 192.208.10.1 255.255.255.252

interface Serial1
 ip address 195.211.10.1 255.255.255.252

router bgp 500
 network 195.211.10.0
 aggregate-address 195.211.0.0 255.255.0.0 summary-only
 neighbor 192.208.10.2 remote-as 300
 neighbor 192.208.10.2 send-community
 neighbor 192.208.10.2 route-map setcommunity out
 neighbor 195.211.10.2 remote-as 400
!
ip classless
access-list 1 permit 195.211.0.0 0.0.255.255
access-list 2 permit any
route-map setcommunity permit 20
 match ip address 2
!
route-map setcommunity permit 10
 match ip address 1
 set community no-export

Uma demonstração da utilização de filtragem de comunidade está no RTG. Você adiciona uma comunidade no-export a atualizações de 195.211.0.0 para o RTD. Desta forma, o RTD não exportará a rota para o RTB. No entanto, neste caso, o RTB não aceitará estas rotas de qualquer forma.

RTE#
hostname RTE

ip subnet-zero

interface Loopback0
 ip address 200.200.10.1 255.255.255.0

interface Serial0
 ip address 195.211.10.2 255.255.255.252

interface Serial1
 ip address 128.213.63.6 255.255.255.252

router bgp 400
 network 200.200.10.0
 aggregate-address 200.200.0.0 255.255.0.0 summary-only
 neighbor 128.213.63.5 remote-as 200
 neighbor 195.211.10.1 remote-as 500

ip classless

O RTE agrega 200.200.0.0/16. Aqui estão as tabelas de BGP e de roteamento finais para o RTA, o RTF e o RTB:

RTA# show ip bgp
BGP table version is 21, local router ID is 203.250.13.41
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop          Metric LocPrf Weight Path
*> 128.213.0.0      128.213.63.2           0    200      0 200 i
*>i192.208.10.0     192.208.10.5           0    300      0 300 i
*> 200.200.0.0/16   128.213.63.2                200      0 200 400 i
*> 203.250.13.0     0.0.0.0                0         32768 i
*> 203.250.14.0     0.0.0.0                0         32768 i
*>i203.250.15.0     203.250.15.2           0    100      0 i

RTA# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * -
candidate default

Gateway of last resort is 128.213.63.2 to network 200.200.0.0

     192.208.10.0 is variably subnetted, 2 subnets, 2 masks
O E2    192.208.10.0 255.255.255.0
           [110/1000] via 203.250.14.2, 00:41:25, Ethernet0
O       192.208.10.4 255.255.255.252
           [110/138] via 203.250.14.2, 00:41:25, Ethernet0
C    203.250.13.0 is directly connected, Loopback0
     203.250.15.0 is variably subnetted, 3 subnets, 3 masks
O       203.250.15.10 255.255.255.255
           [110/75] via 203.250.14.2, 00:41:25, Ethernet0
O       203.250.15.0 255.255.255.252
           [110/74] via 203.250.14.2, 00:41:25, Ethernet0
B       203.250.15.0 255.255.255.0 [200/0] via 203.250.15.2, 00:41:25
C    203.250.14.0 is directly connected, Ethernet0
     128.213.0.0 is variably subnetted, 2 subnets, 2 masks
B       128.213.0.0 255.255.0.0 [20/0] via 128.213.63.2, 00:41:26
C       128.213.63.0 255.255.255.252 is directly connected, Serial0
O*E2 0.0.0.0/0 [110/1000] via 203.250.14.2, Ethernet0/0
B*   200.200.0.0 255.255.0.0 [20/0] via 128.213.63.2, 00:02:38

RTF# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * -
candidate default

Gateway of last resort is 203.250.15.2 to network 0.0.0.0

     192.208.10.0 is variably subnetted, 2 subnets, 2 masks
O E2    192.208.10.0 255.255.255.0
           [110/1000] via 203.250.15.2, 00:48:50, Serial1
O       192.208.10.4 255.255.255.252
           [110/128] via 203.250.15.2, 01:12:09, Serial1
     203.250.13.0 is variably subnetted, 2 subnets, 2 masks
O       203.250.13.41 255.255.255.255
           [110/11] via 203.250.14.1, 01:12:09, Ethernet0
O E2    203.250.13.0 255.255.255.0
           [110/2000] via 203.250.14.1, 01:12:09, Ethernet0
     203.250.15.0 is variably subnetted, 2 subnets, 2 masks
O       203.250.15.10 255.255.255.255
           [110/65] via 203.250.15.2, 01:12:09, Serial1
C       203.250.15.0 255.255.255.252 is directly connected, Serial1
C    203.250.14.0 is directly connected, Ethernet0
     128.213.0.0 is variably subnetted, 2 subnets, 2 masks
O E2    128.213.0.0 255.255.0.0
           [110/2000] via 203.250.14.1, 00:45:01, Ethernet0
O       128.213.63.0 255.255.255.252
           [110/74] via 203.250.14.1, 01:12:11, Ethernet0
O E2 200.200.0.0 255.255.0.0 [110/2000] via 203.250.14.1, 00:03:47,
Ethernet0
O*E2 0.0.0.0 0.0.0.0 [110/1000] via 203.250.15.2, 00:03:33, Serial1

Observação: A tabela de roteamento do RTF indica que o modo de alcançar redes locais ao AS300, como 192.208.10.0, é pelo RTB. O modo de alcançar outras redes conhecidas, como 200.200.0.0, é pelo RTA. O gateway de último recurso é configurado para RTB. Se algo acontecer com a conexão entre o RTB e o RTD, o padrão que o RTA anuncia entra em ação com uma métrica de 2000.

RTB# show ip bgp
BGP table version is 14, local router ID is 203.250.15.10
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop          Metric LocPrf Weight Path
*>i128.213.0.0      128.213.63.2           0    200      0 200 i
*> 192.208.10.0     192.208.10.5           0    300      0 300 i
*>i200.200.0.0/16   128.213.63.2                200      0 200 400 i
*>i203.250.13.0     203.250.13.41          0    100      0 i
*>i203.250.14.0     203.250.13.41          0    100      0 i
*> 203.250.15.0     0.0.0.0                0         32768 i

RTB# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * -
candidate default

Gateway of last resort is 192.208.10.5 to network 192.208.10.0

 *   192.208.10.0 is variably subnetted, 2 subnets, 2 masks
B*      192.208.10.0 255.255.255.0 [20/0] via 192.208.10.5, 00:50:46
C       192.208.10.4 255.255.255.252 is directly connected, Serial1
     203.250.13.0 is variably subnetted, 2 subnets, 2 masks
O       203.250.13.41 255.255.255.255
           [110/75] via 203.250.15.1, 01:20:33, Serial0
O E2    203.250.13.0 255.255.255.0
           [110/2000] via 203.250.15.1, 01:15:40, Serial0
     203.250.15.0 255.255.255.252 is subnetted, 2 subnets
C       203.250.15.8 is directly connected, Loopback1
C       203.250.15.0 is directly connected, Serial0
O    203.250.14.0 [110/74] via 203.250.15.1, 01:20:33, Serial0
     128.213.0.0 is variably subnetted, 2 subnets, 2 masks
O E2    128.213.0.0 255.255.0.0 [110/2000] via 203.250.15.1, 00:46:55, Serial0
O       128.213.63.0 255.255.255.252
           [110/138] via 203.250.15.1, 01:20:34, Serial0
O*E2 0.0.0.0/0 [110/2000] via 203.250.15.1, 00:08:33, Serial0
O E2 200.200.0.0 255.255.0.0 [110/2000] via 203.250.15.1, 00:05:42, Serial0

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 26634