Introdução
Este documento descreve como usar os Valores da Comunidade BGP para controlar a política de roteamento em redes de provedor upstream.
Pré-requisitos
Requisitos
Este documento requer uma compreensão do protocolo de roteamento BGP (Border Gateway Protocol) e sua operação.
Componentes Utilizados
Este documento não se restringe a versões de software e hardware específicas. No entanto, as informações neste documento são baseadas nesta versão de software:
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Informações de Apoio
Embora as próprias comunidades não alterem o processo de melhor caminho BGP, as comunidades podem ser usadas como flags para marcar um conjunto de rotas. Os roteadores do provedor de serviços upstream podem usar essas flags para aplicar políticas de roteamento específicas (por exemplo, a preferência local) dentro da rede.
Os provedores mapeiam entre os valores configuráveis da comunidade e os valores de preferência locais correspondentes dentro da rede do provedor. Você pode ter políticas específicas que exigem a modificação de LOCAL_PREF no conjunto de rede do provedor e os valores de comunidade correspondentes em suas atualizações de roteamento.
Uma comunidade é um grupo de prefixos que compartilham alguma propriedade comum e podem ser configurados com o atributo de comunidade BGP. O atributo de comunidade do BGP é um atributo transitivo opcional de comprimento variável. O atributo consiste em um conjunto de valores de quatro octetos que especificam uma comunidade. Os valores dos atributos de comunidade são codificados com um número de Sistema Autônomo (AS) nos dois primeiros octetos, com os outros dois octetos definidos pelo AS. Um prefixo que pode ter mais de um atributo de comunidade. Um alto-falante BGP que vê vários atributos de comunidade em um prefixo pode agir com base em um, alguns ou todos os atributos. Um roteador tem a opção de adicionar ou modificar um atributo de comunidade antes de passar o atributo para outros peers. Para saber mais sobre o atributo de comunidade, consulte Estudos de Caso do BGP.
O atributo de preferência local é uma indicação para o AS de qual caminho é preferido para alcançar uma determinada rede. Quando há vários caminhos para o mesmo destino, o caminho com a preferência mais alta é escolhido (o valor padrão do atributo de preferência local é 100). Para obter mais informações, consulte Estudos de caso.
Conventions
Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.
Configurar e controlar a política de roteamento
Observação: para encontrar informações adicionais sobre os comandos usados neste documento, use a Command Lookup Tool.
Para simplificar, supõe-se que o mapeamento do atributo de preferência local e do atributo de preferência local esteja estabelecido entre o provedor de serviços upstream (AS 100) e seu dispositivo (AS 30).
Preferência local |
Valores da Comunidade |
130 |
100:300 |
125 |
100:250 |
Se os prefixos forem anunciados com um atributo de comunidade igual a 100:300, o provedor de serviços de upstream definirá a preferência local dessas rotas como 130 e 125 se o atributo de comunidade for igual a 100:250.
Isso lhe dará controle sobre a política de roteamento na rede do provedor de serviços se você alterar os valores da comunidade dos prefixos anunciados para o provedor de serviços.
No diagrama de rede , o AS 30 deseja usar essa política de roteamento com os atributos de comunidade.
-
O tráfego de entrada do AS 100 destinado à rede 10.0.10.0/24 trafega pelo link R1-R3. Se o link R1-R3 falhar, todo o tráfego trafegará por R2-R3.
-
O tráfego de entrada do AS 100 destinado à rede 10.1.0.0/24 trafega pelo link R2-R3. Se o link R2-R3 falhar, todo o tráfego trafegará por R1-R3.
Para atingir essa política de roteamento, R3 anuncia seus prefixos desta maneira:
Para R1:
- 10.0.10.0/24 com atributo de comunidade de 100:300
- 10.1.0.0/24 com atributo de comunidade de 100:250
Para R2:
Quando os vizinhos BGP R1 e R2 receberem os prefixos de R3, R1 e R2 aplicam a política configurada com base no mapeamento entre a comunidade e os atributos de preferência local (mostrados na tabela anterior) e, assim, atingem a política de roteamento ditada por você (o AS 30). R1 instala os prefixos na tabela BGP.
O R2 instala o prefixo em sua tabela BGP:
Como uma preferência local mais alta tem prioridade nos critérios de seleção de caminho do BGP, o caminho com a preferência local de 130 (130 é maior do que 125) é selecionado como o melhor caminho no AS 100 e é instalado na tabela de roteamento de IP de R1 e R2. Para obter mais informações sobre critérios de seleção de caminho BGP, consulte Algoritmo de seleção de melhor caminho BGP.
Diagrama de Rede
Rede BGP
Configurações
Este documento utiliza as seguintes configurações:
R3
hostname R3
!
interface Loopback0
ip address 10.0.10.0 255.255.255.0
!
interface Ethernet0/0
ip address 10.1.0.0 255.255.255.1
!
interface Serial8/0
ip address 10.10.13.3 255.255.255.0
!--- Interface connected to R1
!
interface Serial9/0
ip address 10.10.23.3 255.255.255.0
!--- Interface connected to R2
!
router bgp 30
network 10.0.10.0 mask 255.255.255.0
network 10.1.0.0 mask 255.255.255.1
!--- Network commands announce prefix 10.0.10.0/24 and 10.1.0.0/24.
neighbor 10.10.13.1 remote-as 100
!--- Establishes peering with R1
neighbor 10.10.13.1 send-community
!--- Without this command, the community attributes are not sent to the neighbor
neighbor 10.10.13.1 route-map Peer-R1 out
!--- Configures outbound policy as defined by route-map "Peer-R1" when peering with R1
neighbor 10.10.23.2 remote-as 100
!--- Establishes peering with R2
neighbor 10.10.23.2 send-community
!--- Configures to send community attribute to R2
neighbor 10.10.23.2 route-map Peer-R2 out
!--- Configures outbound policy as defined by
!--- route-map "Peer-R2" when peering with R2.
no auto-summary
!
ip classless
ip bgp-community new-format
!--- Allows you to configure the BGP community
!--- attribute in AA:NN format.
!
access-list 101 permit ip host 10.0.10.0 host 255.255.255.0
access-list 102 permit ip host 10.1.0.0 host 255.255.255.1
!
!
route-map Peer-R1 permit 10
match ip address 101
set community 100:300
!--- Sets community 100:300 for routes matching access-list 101
!
route-map Peer-R1 permit 20
match ip address 102
set community 100:250
!--- Sets community 100:250 for routes matching access-list 102
!
route-map Peer-R2 permit 10
match ip address 101
set community 100:250
!--- Sets community 100:250 for routes matching access-list 101
!
route-map Peer-R2 permit 20
match ip address 102
set community 100:300
!--- Sets community 100:300 for routes matching access-list 102
!
end
R1
hostname R1
!
interface Loopback0
ip address 10.200.10.1 255.255.255.0
!
interface Serial8/0
ip address 10.10.13.1 255.255.255.1
!--- Connected to R3
!
interface Serial10/0
ip address 10.10.12.1 255.255.255.0
!--- Connected to R2
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 10.10.12.2 remote-as 100
!--- Establishes peering with R2
neighbor 10.10.12.2 next-hop-self
neighbor 10.10.13.3 remote-as 30
!--- Establishes peering with R3
neighbor 10.10.13.3 route-map Peer-R3 in
!--- Configures the inbound policy as defined by route-map "Peer-R3" when peering with R3.
no auto-summary
!
ip bgp-community new-format
!--- Allows you to configure the BGP community attribute in AA:NN format.
ip community-list 1 permit 100:300
ip community-list 2 permit 100:250
!--- Defines community list 1 and 2.
!
route-map Peer-R3 permit 10
match community 1
set local-preference 130
!--- Sets local preference 130 for all routes matching community list 1.
!
route-map Peer-R3 permit 20
match community 2
set local-preference 125
!--- Sets local preference 125 for all routes matching community list 2.
!
route-map Peer-R3 permit 30
!--- Without this permit 30 statement, updates that do not match the permit 10 or permit 20 statements are dropped.
!
end
R2
hostname R2
!
interface Loopback0
ip address 10.0.10.0 255.255.255.0
!
interface Serial9/0
ip address 10.10.23.2 255.255.255.1
!--- Connected to R3
!
interface Serial10/0
ip address 10.10.12.2 255.255.255.0
!--- Connected to R1
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 10.10.12.1 remote-as 100
!--- Establishes iBGP peering with R1
neighbor 10.10.12.1 next-hop-self
neighbor 10.10.23.3 remote-as 30
!--- Establishes peering with R3
neighbor 10.10.23.3 route-map Peer-R3 in
!--- Configures inbound policy as defined by route-map "Peer-R3" when peering with R3.
no auto-summary
!
ip bgp-community new-format
!--- Allows you to configure the BGP community attribute in AA:NN format.
!
ip community-list 1 permit 100:300
ip community-list 2 permit 100:250
!--- Defines community list 1 and 2.
!
route-map Peer-R3 permit 10
match community 1
set local-preference 130
!--- Sets local preference 130 for all routes matching community list 1.
!
route-map Peer-R3 permit 20
match community 2
set local-preference 125
!--- Sets local preference 125 for all routes matching community list 2.
!
route-map Peer-R3 permit 30
!--- Without this permit 30 statement, updates that do not match the permit 10 or permit 20 statements are dropped.
!
end
Verificação
R1 recebe os prefixos 10.0.10.0/24 e 10.1.0.0/24 com comunidades 100:300 e 100:250, como mostrado no próximo show ip bgp resultado de saída do comando.
Observação: depois que essas rotas são instaladas na tabela BGP com base na política configurada, os prefixos com a comunidade 100:300 recebem a preferência local 130 e os prefixos com a comunidade 100:250 recebem a preferência local 125.
R1#show ip bgp 10.0.10.0 BGP routing table entry for 10.0.10.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.10.12.2 30 10.10.13.3 from 10.10.13.3 (10.0.10.0) Origin IGP, metric 0, localpref 130, valid, external, best Community: 100:300 !--- Prefix 10.0.10.0/24 with community 100:300 received from 10.10.13.3 (R3) is assigned local preference 130.
R1#show ip bgp 10.1.0.0 BGP routing table entry for 10.1.0.0/24, version 4 Paths: (2 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.10.13.3 30 10.10.12.2 from 10.10.12.2 (10.1.0.0) Origin IGP, metric 0, localpref 130, valid, internal, best
!--- Received prefix 10.1.0.0/24 over iBGP from 10.10.12.2 (R2) with local preference 130
30 10.10.13.3 from 10.10.13.3 (198.51.100.1) Origin IGP, metric 0, localpref 125, valid, external Community: 100:250 !--- Prefix 10.1.0.0/24 with community 100:250 received from 10.10.13.3 (R3) is assigned local preference 125.
R1#show ip bgp BGP table version is 4, local router ID is 10.200.10.1 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 *> 10.0.10.0/24 10.10.13.3 0 130 0 30 i *>i 10.1.0.0/24 10.10.12.2 0 130 0 30 i * 10.10.13.3 0 125 0 30 i
O comando show ip bgp em R1 confirma que o melhor caminho selecionado em R1 está com a preferência local (LoclPrf) = 130. Da mesma forma, R2 recebe os prefixos 10.0.10.0/24 e 10.1.0.0/24 com as comunidades 100:250 e 100:300, como mostrado em negrito nesta saída de show ip bgp comando:
Observação: depois que essas rotas são instaladas na tabela BGP, com base na política configurada, os prefixos com a comunidade 100:300 recebem a preferência local 130 e os prefixos com a comunidade 100:250 recebem a preferência local 125.
R2#show ip bgp 10.0.10.0 BGP routing table entry for 10.0.10.0/24, version 2 Paths: (2 available, best #2, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.10.23.3 30 10.10.23.3 from 10.10.23.3 (10.0.10.0) Origin IGP, metric 0, localpref 125, valid, external Community: 100:250 !--- Prefix 10.0.10.0/24 with community 100:250 received from 10.10.23.3 (R3) is assigned local preference 125
30 10.10.12.1 from 10.10.12.1 (10.200.10.1) Origin IGP, metric 0, localpref 130, valid, internal, best !--- Received prefix 10.0.10.0/24 over iBGP from 10.10.12.1 (R1) with local preference 130
R2#show ip bgp 10.1.0.0 BGP routing table entry for 10.1.0.0/24, version 3 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.10.12.1 30 10.10.23.3 from 10.10.23.3 (10.1.0.0) Origin IGP, metric 0, localpref 130, valid, external, best Community: 100:300 !--- Prefix 10.1.0.0/24 with community 100:300 received from 10.10.23.3 (R3) is assigned local preference 130.
R2#show ip bgp BGP table version is 3, local router ID is 192.168.50.1 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 * 10.0.10.0/24 10.10.23.3 0 125 0 30 i *>i 10.10.12.1 0 130 0 30 i *> 10.1.0.0/24 10.10.23.3 0 130 0 30 i
Essa saída de show ip bgp comando em R2 confirma que o melhor caminho selecionado em R2 está com a preferência local (loclPrf) = 130. A rota IP para o prefixo 10.0.10.0/24 prefere que o link R1-R3 saia do AS 100 em direção ao AS 30. O show ip route comando em R1 e R2 confirma essa preferência.
R1#show ip route 10.0.10.0 Routing entry for 10.0.10.0/24 Known via "bgp 100", distance 20, metric 0 Tag 30, type external Last update from 10.10.13.3 3d21h ago Routing Descriptor Blocks: * 10.10.13.3, from 10.10.13.3, 3d21h ago Route metric is 0, traffic share count is 1 AS Hops 1 !--- On R1, the IP route to prefix 10.0.10.0/24 points to next hop 10.10.13.3 which is R3 serial 8/0 interface on the R1-R3 link.
R2#show ip route 10.1.0.0 Routing entry for 10.1.0.0/24 Known via "bgp 100", distance 200, metric 0 Tag 30, type internal Last update from 10.10.12.1 3d21h ago Routing Descriptor Blocks: * 10.10.12.1, from 10.10.12.1, 3d21h ago Route metric is 0, traffic share count is 1 AS Hops 1 !--- On R2, IP route to prefix 10.1.0.0/24 points to next hop R1 (10.10.12.1) on its iBGP link !--- Thus traffic to network 10.1.0.0/24 from R2 exits through R2-R1 and then R1-R3 link from AS 100 towards AS 30
A rota IP para o prefixo 10.1.0.0/24 prefere que o link R2-R3 saia do AS 100 em direção ao AS 30. O comando show ip route em R1 e R2 confirma essa preferência.
R2#show ip route 10.1.0.0 Routing entry for 10.1.0.0/24 Known via "bgp 100", distance 20, metric 0 Tag 30, type external Last update from 10.10.23.3 3d22h ago Routing Descriptor Blocks: * 10.10.23.3, from 10.10.23.3, 3d22h ago Route metric is 0, traffic share count is 1 AS Hops 1 !--- On R2, IP route to prefix 10.1.0.0/24 points to next hop 10.10.23.3 which is R3 serial 9/0 interface on R2-R3 link.
R1#show ip route 10.1.0.0 Routing entry for 10.1.0.0/24 Known via "bgp 100", distance 200, metric 0 Tag 30, type internal Last update from 10.10.12.2 3d22h ago Routing Descriptor Blocks: * 10.10.12.2, from 10.10.12.2, 3d22h ago Route metric is 0, traffic share count is 1 AS Hops 1 !--- On R1, IP route to prefix 10.1.0.0/24 points to next hop R2 (10.10.12.2) on its iBGP link. !--- Thus traffic to network 10.1.0.0/24 from R1 exits through R1-R2 and then R2-R3 link from AS 100 towards AS 30.
Se um link falhar, por exemplo, o link R1-R3, todo o tráfego deverá rastrear o link R2-R3. Você pode simular esse tráfego se desligar o link entre R1 e R3.
R1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R1(config)#interface serial8/0 R1(config-if)#shut R1(config-if)# 3d22h: %BGP-5-ADJCHANGE: neighbor 10.10.13.3 Down Interface flap 3d22h: %LINK-5-CHANGED: Interface Serial8/0, changed state to administratively down 3d22h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial8/0, changed state to down
Observe a tabela de IP Routing para os prefixos 10.0.10.0/24 e 10.1.0.0/24 no R1 e R2. Use o link R2-R3 para sair do AS 100.
R1#show ip route 10.0.10.0 Routing entry for 10.0.10.0/24 Known via "bgp 100", distance 200, metric 0 Tag 30, type internal Last update from 10.10.12.2 00:01:47 ago Routing Descriptor Blocks: * 10.10.12.2, from 10.10.12.2, 00:01:47 ago Route metric is 0, traffic share count is 1 AS Hops 1
R1#show ip route 10.1.0.0 Routing entry for 10.1.0.0/24 Known via "bgp 100", distance 200, metric 0 Tag 30, type internal Last update from 10.10.12.2 3d22h ago Routing Descriptor Blocks: * 10.10.12.2, from 10.10.12.2, 3d22h ago Route metric is 0, traffic share count is 1 AS Hops 1
Esta saída de show comando mostra que a rota para os prefixos 10.0.10.0/24 e 10.1.0.0/24 aponta para o próximo salto 10.10.12.2, (R2), que é esperado. Agora, observe a tabela de roteamento IP em R2 para verificar o próximo salto do prefixo 10.0.10.0/24 e 10.1.0.0/24. O próximo salto deve ser R3 para que a política configurada funcione com êxito.
R2#show ip route 10.0.10.0 Routing entry for 10.0.10.0/24 Known via "bgp 100", distance 20, metric 0 Tag 30, type external Last update from 10.10.23.3 00:04:10 ago Routing Descriptor Blocks: * 10.10.23.3, from 10.10.23.3, 00:04:10 ago Route metric is 0, traffic share count is 1 AS Hops 1
R2#show ip route 10.1.0.0 Routing entry for 10.1.0.0/24 Known via "bgp 100", distance 20, metric 0 Tag 30, type external Last update from 10.10.23.3 3d22h ago Routing Descriptor Blocks: * 10.10.23.3, from 10.10.23.3, 3d22h ago Route metric is 0, traffic share count is 1 AS Hops 1
O próximo salto 10.10.23.3 é a interface serial 9/0 de R3 no link R2-R3. Isso confirma que a política configurada funciona como esperado.
Informações Relacionadas