Estudos de caso do BGP

Transcrição

1 Estudos de caso do BGP Í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 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

2 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 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. 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: RTA# router bgp autonomous-system

3 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 AS 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:

4 RTA# neighbor remote-as 200 RTB# router bgp 200 neighbor remote-as 100 neighbor remote-as 200 router bgp 200 neighbor 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 , remote AS 200, external link BGP version 4, remote router ID 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:

5 neighbor ip-address update-source interface Este exemplo ilustra a utilidade deste comando : RTA# neighbor remote-as 100 neighbor update-source loopback 1 RTB# neighbor 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, 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 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 Observação: O RTA utilizou o endereço de IP da interface física do RTB, , 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: RTA# neighbor remote-as 300 neighbor ebgp-multihop RTB# router bgp 300 neighbor 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 é 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)

6 RTA# int loopback 0 ip address neighbor remote-as 200 neighbor ebgp-multihop neighbor update-source loopback 0 network ip route ip route RTB# int loopback 0 ip address router bgp 200 neighbor remote-as 100 neighbor update-source loopback 0 neighbor ebgp-multihop network ip route ip route 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ó : um caminho através do e o outro através do 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 , a métrica para esta atualização está configurada para 5. Estes comandos ilustram o exemplo: match ip address 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

7 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:

8 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 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 network network passive-interface Serial0 redistribute bgp 100 route-map SETMETRIC neighbor remote-as 300 network route-map SETMETRIC permit 10 match ip-address 1 set metric 2 route-map SETMETRIC permit 20 set metric 5 access-list 1 permit Neste exemplo, se uma rota corresponde ao endereço de IP , 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 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: router bgp 300 network neighbor remote-as 100 neighbor route-map STOPUPDATES out route-map STOPUPDATES permit 10 match ip address 1 access-list 1 deny access-list 1 permit 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

9 Redistribuição Redistribuição e rotas estáticas 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 mask ip route null 0 Este exemplo indica que o roteador A gera uma entrada de rede para /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 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 e o RTC anuncia Observe a configuração do RTC: Se emitir o comando network você possui: router eigrp 10 network redistribute bgp 200 default-metric router bgp 200 neighbor remote-as 300 network mask !--- Isso limita as redes que o seu AS origina para

10 Se, em vez disso, utilizar a redistribuição, você possui: router eigrp 10 network redistribute bgp 200 default-metric router bgp 200 neighbor remote-as 300 redistribute eigrp 10!--- O EIGRP injeta novamente no BGP. Essa redistribuição provoca a origem de pelo seu AS. Você não é a origem de ; AS100 é a origem. Portanto você deve utilizar filtros para impedir a origem de sair daquela rede pelo seu AS. A configuração correta é: router eigrp 10 network redistribute bgp 200 default-metric router bgp 200 neighbor remote-as 300 neighbor distribute-list 1 out redistribute eigrp 10 access-list 1 permit 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: router eigrp 10 network redistribute bgp 200 default-metric router bgp 200 neighbor remote-as 300 redistribute static... ip route null0... A interface null0 significa ignorar o pacote. Portanto, se você receber o pacote e houver uma correspondência mais específica do que , 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:

11 RTA# neighbor remote-as 300 network RTB# router bgp 200 neighbor remote-as 300 network router bgp 300 neighbor remote-as 100 neighbor remote-as 200 network Observação: Você não precisa da rede ou 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 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 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. RTA# neighbor remote-as 100 neighbor remote-as 300 network

12 RTB# neighbor remote-as 100 neighbor remote-as 400 network router bgp 400 neighbor remote-as 100 network 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 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 no AS200. Quando a rota percorre o AS300, o RTC anexa seu prórprio número de AS à rede. Portanto, quando 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 é (300, 200). O mesmo processo aplica-se a e O RTB precisa pegar o caminho (300, 100); o RTB percorre o AS300 e depois o AS100 para alcançar O RTC precisa percorrer (200) para alcançar e o caminho (100) para alcançar Atributo de origem

13 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. RTA# neighbor remote-as 100 neighbor remote-as 300 network redistribute static ip route null0 RTB# neighbor remote-as 100 network RTE# router bgp 300 neighbor remote-as 100 network O RTA alcança 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 por i. Este "i" significa que a entrada é no mesmo AS e a origem é IGP. O RTE alcança por 100 i. O "100 i" significa que o próximo de AS é 100 e a origem é IGP. O RTE também alcança 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 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.

14 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 para o RTA com um próximo nó de O RTA anuncia para o RTC com um próximo nó de 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 para seu peer do ibgp, RTB, com um próximo nó de Portanto, de acordo com o RTB, o próximo nó a alcançar é e não Certifique-se de que o RTB pode alcançar pelo IGP. Caso contrário, o RTB descarta pacotes com o destino de , 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 do RTA. Você deve tornar o igrp passivo no link ao RTC para que o BGP seja apenas trocado. RTA# neighbor remote-as 300 neighbor remote-as 100 network RTB# neighbor remote-as 100 router bgp 300 neighbor remote-as 100 network Observação: O RTC anuncia para o RTA com um próximo nó equivalente a Observação: O RTA anuncia para o RTB com um próximo nó equivalente a 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) 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 pelo Quando o RTC envia uma atualização de BGP para o RTA relacionado a , o RTC utiliza como próximo nó o O RTC não utiliza seu próprio endereço de IP, 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 é mais sensato do que o nó extra pelo RTC. Observação: O RTC anuncia para o RTA com um próximo nó 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)

15 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 para o RTA com um próximo de 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: router bgp 300 neighbor remote-as 100 neighbor next-hop-self O RTC anuncia com um próximo nó equivalente a Backdoor de BGP 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

16 90 para EIGRP 110 para OSPF O RTA recebe atualizações sobre 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 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 neighbor remote-as 300 network backdoor A rede é tratada como uma entrada local, mas não é anunciada como uma entrada de rede normal. O RTA aprende 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

17 Antes de discutir a sincronização, observe este cenário. O RTC no AS300 envia atualizações sobre RTA e RTB executam ibgp, portanto o RTB recebe a atualização e é capaz de alcançar pelo próximo nó, 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 no IGP. Nesse ponto, o RTE não faz idéia de que sequer existe. Se o RTB começar a anunciar para o AS400 que pode alcançar , tráfego que vem do RTD para o RTB com destino 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 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 Certifique-se de que outros roteadores podem alcançar 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: no synchronization Observação: Certifique-se de emitir o comando clear ip bgp address para reiniciar a seção. RTB#

18 network neighbor remote-as 400 neighbor remote-as 100 no synchronization!--- O RTB coloca 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 RTD# router bgp 400 neighbor remote-as 100 network RTA# network neighbor remote-as 100 Atributo de ponderação 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 do AS4. O RTA propaga a atualização para o RTC. O RTB também aprendeu sobre a rede do AS4. O RTB propaga a atualização para o RTC. O RTC agora possui duas maneiras de alcançar 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 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-listnumber weight weight Utilize mapas de rotas. router bgp 300 neighbor remote-as 100 neighbor weight 200 neighbor remote-as 200 neighbor weight 100!--- A rota para o do RTA tem ponderação 200.!--- A rota para o do RTB tem ponderação 100.

19 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. router bgp 300 neighbor remote-as 100 neighbor filter-list 5 weight 200 neighbor remote-as 200 neighbor filter-list 6 weight 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. router bgp 300 neighbor remote-as 100 neighbor route-map setweightin in neighbor remote-as 200 neighbor 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 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:

20 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 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: router bgp 256 neighbor remote-as 100 neighbor remote-as 256 bgp default local-preference 150 RTD# router bgp 256 neighbor remote-as 300 neighbor 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 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 remote-as 300 neighbor route-map setlocalin in neighbor remote-as 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 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.

21 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 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# neighbor remote-as 300 neighbor remote-as 300 neighbor remote-as router bgp 300 neighbor remote-as 100 neighbor route-map setmetricout out neighbor remote-as 300 route-map setmetricout permit 10 set metric 120 RTD# router bgp 300 neighbor remote-as 100 neighbor route-map setmetricout out neighbor remote-as 300 route-map setmetricout permit 10 set metric 200 RTB# router bgp 400 neighbor remote-as 100 neighbor 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# neighbor remote-as 300 neighbor remote-as 300 neighbor 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 Também é possível configurar métricas durante a redistribuição de rotas no BGP se você emitir o comando default-metric number.

22 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 null 0!--- Isso faz com que o RTB envie 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# neighbor remote-as 300 neighbor send-community neighbor 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

23 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 exibe o valor do atributo de comando em formato decimal. Neste exemplo, o valor do atributo de comunidade aparece como Router# show ip bgp BGP routing table entry for /8, version 7 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer from ( ) Origin IGP, metric 0, localpref 100, valid, external, best Comunidade: 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 neste exemplo: Router# show ip bgp BGP routing table entry for /8, version 9 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer from ( ) 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 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:

24 neighbor {ip-address peer-group-name} distribute-list access-list-number {in out} Neste exemplo, o RTB origina a rede 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: router bgp 300 network neighbor remote-as 200 neighbor remote-as 100 neighbor distribute-list 1 out access-list 1 deny access-list 1 permit !--- Filtrar todas as atualizações de roteamento sobre o 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 de x.x. Seu objetivo é filtrar atualizações e anunciar somente /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 O comando access-list 1 permit permite /8, /9, e assim por diante. Para restringir a atualização para apenas /8, é preciso utilizar uma lista de acesso estendida neste formato: access-list 101 permit ip Esta lista permite somente /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. É 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 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

25 neighbor {ip-address peer-group-name} filter-list access-list-number {in out} Este exemplo impede o RTC de enviar atualizações sobre para o RTA: router bgp 300 neighbor remote-as 200 neighbor remote-as 100 neighbor 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 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. $

26 O $ corresponde ao fim da série de entrada. \ O \ corresponde ao caractere. - Parte 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. 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.? Filial O? corresponde ao átomo ou à série nula. 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$

27 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. 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 neighbor remote-as 300 neighbor send-community neighbor route-map setcommunity out route-map setcommunity match ip address 1 set community no-export access-list 1 permit 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 Esta ação adiciona o valor para qualquer valor de comunidade existente antes da transmissão para o RTC. RTB# router bgp 200 network neighbor remote-as 300 neighbor send-community neighbor route-map setcommunity out

28 route-map setcommunity match ip address 2 set community additive access-list 2 permit 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 !--- O número da lista de comunidades é É 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 Se o RTC desejar definir a ponderação tendo estes valore como base, você pode: router bgp 300 neighbor remote-as 200 neighbor 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

29 É 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: router bgp 300 network neighbor remote-as 200 neighbor 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 router bgp 300 network neighbor remote-as 200 neighbor 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 ^ *

30 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 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 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: router bgp 300 network neighbor remote-as 100 neighbor route-map SETPATH out route-map SETPATH set as-path prepend Por causa desta configuração, o AS600 recebe atualizações sobre 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 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

31 Este exemplo aplica-se a grupos de peer de vizinhos internos e externos do BGP: 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 peer-group internalmap neighbor peer-group internalmap neighbor peer-group internalmap neighbor 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. 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 remote-as 100 neighbor peer-group externalmap neighbor remote-as 600 neighbor peer-group externalmap neighbor remote-as 200 neighbor peer-group externalmap neighbor 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 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

32 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 já foi uma rede ilegal de classe C. Agora, a rede é uma super-rede legal, /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 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 Você configura o RTC para propagar uma super-rede da rota para o RTA: RTB# router bgp 200 neighbor remote-as 300 network #RTC router bgp 300 neighbor remote-as 200 neighbor remote-as 100 network aggregate-address O RTC propaga o endereço agregado 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 propaga uma rede adicional , mas não impede a propagação de para o RTA. O resultado é a propagação de ambas as redes e 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 se não possuir uma entrada mais específica de 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 Se desejar que o RTC propague somente a rede 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 summary-only propaga a rede e suprime a rota mais específica 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

33 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 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 , suprimir a rota mais específica e permitir a propagação de Utilize este mapa de rotas: route-map CHECK permit 10 match ip address 1 access-list 1 permit access-list 1 deny 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. router bgp 300 neighbor remote-as 200 neighbor remote-as 100 neighbor remote-as 100 network aggregate-address 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 attribute-map SETORIGIN Para obter mais informações, consulte Entendendo agregação de rotas no BGP. Exemplo de CIDR 1

34 Requisição: Permite que o RTB anuncie o prefixo e suprima todas as rotas mais específicas. O problema com este requisito é que a rede é local do AS200, o que significa que o AS200 é o originador de Não é possível que o RTB gere um prefixo para sem gerar uma entrada para , mesmo com a utilização do comando aggregate summary-only. O RTB gera ambas as redes, pois é o originiador de 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 remote-as 300 redistribute static!--- Isso gera uma atualização para !--- com o caminho de origem como "incompleto". ip route 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 mask !--- Esta entrada marca a atualização com origem IGP. neighbor remote-as 300 redistribute static ip route 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 do RTA e atualiza sobre do RTB. Suponhamos que o RTC deseje agregar a rede /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.

35 RTB# router bgp 200 network neighbor remote-as 300 RTA# network neighbor remote-as 300 Caso 1: O RTC não possui uma instrução as-set. O RTC envia uma atualização /8 ao RTD com informação de caminho (300), como se a rota tivesse originado no AS300. router bgp 300 neighbor remote-as 200 neighbor remote-as 100 neighbor remote-as 400 aggregate summary-only!--- Este comando faz o RTC enviar atualizações sobre /8 ao RTD!--- sem indicar que vem, na verdade, de dois ASs diferentes.!--- Isso pode criar loops se o RTD possuir uma entrada no AS100 ou no AS200. Caso 2: router bgp 300 neighbor remote-as 200 neighbor remote-as 100 neighbor remote-as 400 aggregate summary-only aggregate as-set!--- Este comando faz o RTC enviar atualizações sobre /8 ao RTD!--- indicando que pertence a um conjunto { }. 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:

36 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. router bgp 50 bgp confederation identifier 500 bgp confederation peers neighbor remote-as 50 (IBGP connection within AS50) neighbor remote-as 50 (IBGP connection within AS50) neighbor remote-as 60 (BGP connection with confederation peer 60) neighbor remote-as 70 (BGP connection with confederation peer 70) neighbor remote-as 100 (EBGP connection to external AS100) RTD# router bgp 60 bgp confederation identifier 500 bgp confederation peers neighbor remote-as 60 (IBGP connection within AS60) neighbor remote-as 50(BGP connection with confederation peer 50) neighbor remote-as 70 (BGP connection with confederation peer 70) neighbor remote-as 600 (EBGP connection to external AS600) RTA# neighbor 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.

37 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". 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: Rotas de um peer não cliente Reflete para todos os clientes dentro de um cluster. Rotas de um peer cliente Reflete para todos os peers não clientes além dos peers clientes. 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:

38 neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor remote-as 100 neighbor remote-as 200 RTB# neighbor remote-as 100 neighbor remote-as 300 RTD# neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor 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 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.

39 Aqui está a configuração do RTH, do RTD, do RTF e do RTC: RTH# neighbor remote-as 100 neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor remote-as 100 neighbor remote-as 300 bgp cluster-id 10 RTD# neighbor remote-as 100 neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor remote-as 100 neighbor remote-as 400 bgp cluster-id 10 RTF# neighbor remote-as 100 neighbor remote-as 100 neighbor remote-as 500 neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor remote-as 100 neighbor remote-as 100 neighbor 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.

40 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# neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor remote-as 100 neighbor remote-as 100 neighbor remote-as 300 neighbor remote-as 100 neighbor remote-as 100 neighbor remote-as 100 neighbor 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.

41 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 max-suppress-time Esta é a duração máxima da supressão de uma rota. O alcance é de minutos e o padrão é de 4 vezes o período de meia-vida. RTB# hostname RTB interface Serial0 ip address interface Serial1 ip address bgp dampening network neighbor remote-as 300 RTD# hostname RTD interface Loopback0 ip address interface Serial0/0 ip address router bgp 300 network neighbor 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 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

42 *> i *> i Para simular um sincronismo de rota, emita o comando clear ip bgp no RTD. A tabela de BGP do RTB é semelhante a: RTB# show ip bgp BGP table version is 24, local router ID is 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 i *> i A entrada do BGP para 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 BGP routing table entry for , version 25 Paths: (1 available, no best path) 300 (history entry) from ( ) 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 é 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 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 i *> i RTB# show ip bgp BGP routing table entry for , version 32 Paths: (1 available, no best path) 300, (suppressed due to dampening) from ( ) 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.

43 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. 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 conectase 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 interface Ethernet0 ip address interface Serial0 ip address router ospf 10 network area 0 network

44 network neighbor remote-as 200 neighbor remote-as 100 neighbor update-source Loopback0 RTF# hostname RTF ip subnet-zero interface Ethernet0 ip address interface Serial1 ip address router ospf 10 network area 0 RTB# hostname RTB ip subnet-zero interface Serial0 ip address interface Serial1 ip address router ospf 10 network area 0 network neighbor remote-as 300 neighbor remote-as 100 hostname RTC ip subnet-zero interface Loopback0 ip address interface Serial2/0 ip address ! interface Serial2/1 ip address router bgp 200 network neighbor remote-as 100 neighbor remote-as 400 RTD# hostname RTD ip subnet-zero interface Loopback0 ip address interface Serial0/0 ip address ! interface Serial0/1 ip address router bgp 300 network neighbor remote-as 500 neighbor remote-as 100 RTE# hostname RTE ip subnet-zero interface Loopback0 ip address

45 interface Serial0 ip address interface Serial1 ip address clockrate router bgp 400 network neighbor remote-as 200 neighbor remote-as 500 RTG# hostname RTG ip subnet-zero interface Loopback0 ip address interface Serial0 ip address interface Serial1 ip address router bgp 500 network neighbor remote-as 300 neighbor 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 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 *i i *i i *i i *i i *>i i *>i i *> 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 foi aprendida pelo caminho 200 com um próximo nó de Observação: Qualquer entrada gerada localmente, como , tem um próximo nó 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 pelo próximo nó , 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

46 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 C O is subnetted, 1 subnets [110/75] via , 02:50:45, Serial is subnetted, 1 subnets is directly connected, Serial [110/74] via , 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, Não há como alcançar aquele próximo nó por este IGP, que é OSPF. O RTB não aprendeu sobre 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ó Esta configuração de RTA aparece aqui: RTA# hostname RTA ip subnet-zero interface Loopback0 ip address interface Ethernet0 ip address interface Serial0 ip address router ospf 10 passive-interface Serial0 network area 0 network area 0 network mask neighbor remote-as 200 neighbor remote-as 100 neighbor 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 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 *>i i *>i i *>i i *>i i *>i i *>i i *> 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

47 O C O O is subnetted, 1 subnets [110/75] via , 00:04:46, Serial is subnetted, 1 subnets is directly connected, Serial [110/74] via , 00:04:46, Serial is subnetted, 1 subnets [110/138] via , 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 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 e 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/0] via , 00:01:07 B [200/0] via , 00:01:07 B [200/0] via , 00:01: is variably subnetted, 2 subnets, 2 masks O [110/75] via , 00:12:37, Serial0 B [200/0] via , 00:01: is subnetted, 1 subnets C is directly connected, Serial0 O [110/74] via , 00:12:37, Serial is variably subnetted, 2 subnets, 2 masks B [200/0] via , 00:01:08 O [110/138] via , 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 O C C O is subnetted, 1 subnets [110/11] via , 00:14:15, Ethernet is subnetted, 1 subnets is directly connected, Serial is directly connected, Ethernet is subnetted, 1 subnets [110/74] via , 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 interface Ethernet0 ip address

48 interface Serial0 ip address router ospf 10 redistribute bgp 100 metric 2000 subnets passive-interface Serial0 network area 0 network area 0 network mask neighbor remote-as 200 neighbor remote-as 100 neighbor 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 E [110/2000] via , 00:00:14, Serial0 O E [110/2000] via , 00:00:14, Serial0 O E [110/2000] via , 00:00:14, Serial is variably subnetted, 2 subnets, 2 masks O [110/75] via , 00:00:15, Serial0 O E [110/2000] via , 00:00:15, Serial is subnetted, 2 subnets C is directly connected, Loopback1 C is directly connected, Serial0 O [110/74] via , 00:00:15, Serial is variably subnetted, 2 subnets, 2 masks O E [110/2000] via , 00:00:15,Serial0 O [110/138] via , 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 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 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ó pelo IGP. Se você não concluir esta etapa, ocorrerão loops de roteamento, pois, para alcançar o próximo nó , 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 interface Ethernet0 ip address interface Serial0 ip address router ospf 10 redistribute bgp 100 metric 2000 subnets passive-interface Serial0 network area 0 network area 0

49 no synchronization network network neighbor remote-as 200 neighbor remote-as 100 neighbor update-source Loopback0 RTB# hostname RTB ip subnet-zero interface Serial0 ip address interface Serial1 ip address router ospf 10 redistribute bgp 100 metric 1000 subnets passive-interface Serial1 network area 0 network area 0 no synchronization network neighbor remote-as 300 neighbor 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 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 *> i *>i i *>i i * i *> i *> i *> i *>i i RTB# show ip bgp BGP table version is 12, local router ID is 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 *>i i * i *> i *> i *>i i * i *>i i *>i i *> 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

50 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 interface Ethernet0 ip address interface Serial0 ip address router ospf 10 redistribute bgp 100 metric 2000 subnets passive-interface Serial0 network area 0 network area 0 default-information originate metric 2000 no synchronization network network neighbor remote-as 200 neighbor route-map setlocalpref in neighbor remote-as 100 neighbor update-source Loopback0 ip classless ip default-network 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 é 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 , 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 no domínio de IGP. RTF# hostname RTF ip subnet-zero interface Ethernet0 ip address interface Serial1 ip address router ospf 10 network area 0 ip classless RTB# hostname RTB ip subnet-zero interface Loopback1 ip address interface Serial0 ip address !

51 interface Serial1 ip address router ospf 10 redistribute bgp 100 metric 1000 subnets passive-interface Serial1 network area 0 network area 0 default-information originate metric 1000! no synchronization network neighbor remote-as 300 neighbor route-map localonly in neighbor remote-as 100! ip classless ip default-network 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 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 *> hostname RTC ip subnet-zero interface Loopback0 ip address interface Serial2/0 ip address ! interface Serial2/1 ip address router bgp 200 network neighbor remote-as 100 neighbor distribute-list 1 out neighbor remote-as 400 ip classless access-list 1 deny access-list 1 permit any No RTC, você agrega /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

52 ip address ! interface Serial0/0 ip address ! interface Serial0/1 ip address router bgp 300 network neighbor remote-as 500 neighbor remote-as 100 RTG# hostname RTG ip subnet-zero interface Loopback0 ip address interface Serial0 ip address interface Serial1 ip address router bgp 500 network aggregate-address summary-only neighbor remote-as 300 neighbor send-community neighbor route-map setcommunity out neighbor remote-as 400! ip classless access-list 1 permit 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 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 interface Serial0 ip address interface Serial1 ip address router bgp 400 network aggregate-address summary-only neighbor remote-as 200 neighbor remote-as 500 ip classless O RTE agrega /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 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP,? - incomplete

53 Network Next Hop Metric LocPrf Weight Path *> i *>i i *> / i *> i *> i *>i 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 to network is variably subnetted, 2 subnets, 2 masks O E [110/1000] via , 00:41:25, Ethernet0 O [110/138] via , 00:41:25, Ethernet0 C is directly connected, Loopback is variably subnetted, 3 subnets, 3 masks O [110/75] via , 00:41:25, Ethernet0 O [110/74] via , 00:41:25, Ethernet0 B [200/0] via , 00:41:25 C is directly connected, Ethernet is variably subnetted, 2 subnets, 2 masks B [20/0] via , 00:41:26 C is directly connected, Serial0 O*E /0 [110/1000] via , Ethernet0/0 B* [20/0] via , 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 to network is variably subnetted, 2 subnets, 2 masks O E [110/1000] via , 00:48:50, Serial1 O [110/128] via , 01:12:09, Serial is variably subnetted, 2 subnets, 2 masks O [110/11] via , 01:12:09, Ethernet0 O E [110/2000] via , 01:12:09, Ethernet is variably subnetted, 2 subnets, 2 masks O [110/65] via , 01:12:09, Serial1 C is directly connected, Serial1 C is directly connected, Ethernet is variably subnetted, 2 subnets, 2 masks O E [110/2000] via , 00:45:01, Ethernet0 O [110/74] via , 01:12:11, Ethernet0 O E [110/2000] via , 00:03:47, Ethernet0 O*E [110/1000] via , 00:03:33, Serial1 Observação: A tabela de roteamento do RTF indica que o modo de alcançar redes locais ao AS300, como , é pelo RTB. O modo de alcançar outras redes conhecidas, como , é 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 RTB# show ip bgp BGP table version is 14, local router ID is 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

54 *>i i *> i *>i / i *>i i *>i i *> 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 to network * is variably subnetted, 2 subnets, 2 masks B* [20/0] via , 00:50:46 C is directly connected, Serial is variably subnetted, 2 subnets, 2 masks O [110/75] via , 01:20:33, Serial0 O E [110/2000] via , 01:15:40, Serial is subnetted, 2 subnets C is directly connected, Loopback1 C is directly connected, Serial0 O [110/74] via , 01:20:33, Serial is variably subnetted, 2 subnets, 2 masks O E [110/2000] via , 00:46:55, Serial0 O [110/138] via , 01:20:34, Serial0 O*E /0 [110/2000] via , 00:08:33, Serial0 O E [110/2000] via , 00:05:42, Serial0 Informações Relacionadas BGP: Perguntas Mais Freqüentes Configurações de modelo do BGP através de um Firewall PIX Como Utilizar o HSRP para Fornecer Redundância em uma Rede BGP Multihomed Configurando a redundância de modo de roteador único e BGP em uma MSFC do Cat6000 Alcançar roteamento ideal e reduzir consumo de memória do BGP Solução de Problemas do BGP Solução de problemas de alta CPU causados pelo scanner do BGP ou pelo processo de roteador de BGP Compartilhamento de Carga com BGP em Ambientes Simples e Multihomed: Configurações Amostrais Página de Suporte do BGP Suporte Técnico e Documentação - Cisco Systems Cisco Systems Inc. Todos os direitos reservados. Data da Geração do PDF: 3 Abril