IP : Protocole BGP (Border Gateway Protocol)

Utilisation des valeurs BGP Community pour contrôler la stratégie de routage dans le réseau fournisseur ascendant

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document explique comment l'attribut community de Protocole BGP (Border Gateway Protocol) peut être utilisé afin de contrôler le ½ du ¿  de policyï de routage dans son réseau du fournisseur de service ascendant.

Conditions préalables

Conditions requises

Ce document requiert la compréhension du protocole de routage BGP et de son fonctionnement. Pour plus d'informations, consultez les Études de cas BGP.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques. Cependant, les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

  • Version de logiciel 12.2(27) de ½ du ¿  de Cisco IOSïÂ

  • Routeurs de la gamme Cisco 2500

Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.

Théorie générale

Tandis que les communautés elles-mêmes ne modifient pas le processus de prise de décision BGP , les communautés peuvent être utilisées en tant qu'indicateurs afin de marquer un ensemble de routes. Le fournisseur de services de ½ du ¿  d'Upstreamï que les Routeurs peuvent alors employer ces indicateurs pour appliquer le routage spécifique maintient l'ordre (par exemple, préférence locale) le ½ du ¿  ï dans leur réseau.

Les fournisseurs établissent un mappage entre les valeurs de la communauté configurables par le client et les valeurs correspondantes de préférence locale dans le réseau fournisseur. L'idée est que les clients avec des stratégies qui requièrent la modification de LOCAL_PREF dans le réseau fournisseur définissent les valeurs correspondantes de la communauté dans leurs mises à jour de routage.

Une communauté est un groupe de préfixes qui partagent une certaine propriété commune et peuvent être configurés avec l'attribut de la communauté BGP. L' attribut de la communauté BGP est un attribut transitif facultatif de longueur variable. L'attribut se compose d'un ensemble de quatre valeurs d'octet qui spécifient une communauté. Les valeurs d'attribut de la communauté sont encodées avec un numéro de Système autonome (AS) dans les deux premiers octets, avec les deux octets restants définis par l'AS. Un préfixe peut avoir plus d'un attribut de la communauté. Un speaker BGP qui voit des attributs de la communauté multiples dans un préfixe peut agir sur la base d'un seul, de plusieurs ou de tous les attributs. Un routeur peut ajouter ou modifier un attribut de la communauté avant de transmettre l'attribut à d'autres homologues. Pour en savoir plus sur l'attribut de la communauté, consultez les Études de cas BGP.

L'attribut de préférence local indique au AS le chemin de routage préféré afin d'atteindre un certain réseau. Quand il y a des plusieurs chemins à la même destination, le ½ du ¿  ï le chemin avec la préférence plus élevée est préféré (la valeur par défaut de l'attribut local preference est 100). Pour plus d'informations, consultez la section Attribut de préférence local.

Conventions

Pour plus d'informations sur les conventions de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Configurez

Contrôle de la stratégie de routage

Cette section vous fournit des informations pour configurer les fonctionnalités décrites dans ce document.

Remarque: Pour obtenir des informations supplémentaires sur les commandes utilisées dans ce document, utilisez l'Outil de recherche de commande (clients enregistrés seulement).

Pour simplifier, on part du principe que ce mappage de l'attribut de la communauté et de l'attribut de préférence local est établi entre le fournisseur de service en amont (AS 100) et le client (AS 30).

Préférence locale Valeurs de la communauté
130 100:300
125 100:250

Si le client annonce les préfixes avec un attribut de la communauté égal à 100:300, le fournisseur de service en amont définit la préférence locale de ces routes à 130 et à 125 si l'attribut de la communauté est égal à 100:250.

Cela vous permet de contrôler la stratégie de routage dans le réseau du fournisseur de service si vous modifiez les valeurs de la communauté des préfixes annoncés au fournisseur de service.

Dans le diagramme de réseau, le client AS 30 souhaite réaliser cette stratégie de routage avec les attributs de la communauté.

  • Le trafic entrant de AS 100 destiné au réseau 6.6.6.0/24 arrive à travers la liaison R1-R3. Au cas où la liaison R1-R3 échoue, tout le trafic arrive à travers R2-R3.

  • Le trafic entrant de AS 100 destiné au réseau 7.7.7.0/24 arrive à travers la liaison R2-R3. Au cas où la liaison R2-R3 échoue, tout le trafic arrive à travers R1-R3.

Afin de réaliser cette stratégie de routage, R3 annonce ses préfixes comme suit :

À R1 :

  • 6.6.6.0/24 avec un attribut de la communauté 100:300

  • 7.7.7.0/24 avec un attribut de la communauté 100:250

À R2 :

  • 6.6.6.0/24 avec un attribut de la communauté 100:250

  • 7.7.7.0/24 avec un attribut de la communauté 100:300

Une fois que les voisins BGP R1 et R2 reçoivent les préfixes de R3, R1 et R2 appliquent la stratégie de routage préconfigurée basée sur le mappage entre la communauté et les attributs de préférence locaux (montrés dans cette table), et réalisent ainsi la stratégie de routage dictée par le client (AS 30). R1 installe les préfixes dans la table BGP.

  • 6.6.6.0/24 avec une préférence locale de 130

  • 7.7.7.0/24 avec une préférence locale de 125

R2 installe le préfixe dans sa table BGP :

  • 6.6.6.0/24 avec une préférence locale de 125

  • 7.7.7.0/24 avec une préférence locale de 130

Puisqu'une préférence locale plus élevée est préférée dans les critères de sélection de chemin BGP, le chemin avec une préférence locale de 130 (130 est plus grand que 125) est sélectionné comme meilleur chemin de routage dans AS 100, et est installé dans la table de routage IP de R1 et R2. Pour plus d'informations sur les critères de sélection de chemin par BGP, reportez-vous à l'Algorithme de sélection du meilleur chemin BGP.

Diagramme du réseau

Ce document utilise la configuration réseau indiquée dans le diagramme suivant :

http://www.cisco.com/c/dam/en/us/support/docs/ip/border-gateway-protocol-bgp/28784-bgp-community.gif

Configurations

Ce document utilise les configurations suivantes :

R3
Current configuration : 2037 bytes
!
version 12.2
!
hostname R3
!
interface Loopback0
�ip address 6.6.6.1 255.255.255.0
!
interface Ethernet0/0
�ip address 7.7.7.1 255.255.255.0
!
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 6.6.6.0 mask 255.255.255.0
�network 7.7.7.0 mask 255.255.255.0

!--- Network commands announce prefix 6.6.6.0/24


!--- and 7.7.7.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 6.6.6.0 host 255.255.255.0
access-list 102 permit ip host 7.7.7.0 host 255.255.255.0
!
!
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
Version 12.2
!
hostname R1
!
interface Loopback0
�ip address 200.200.200.1 255.255.255.0
!���������
interface Serial8/0
�ip address 10.10.13.1 255.255.255.0

!--- 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
Version 12.2
!
hostname R2
!
interface Loopback0
ip address 192.168.50.1 255.255.255.0
!
interface Serial9/0
ip address 10.10.23.2 255.255.255.0

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

Vérifiez

R1 reçoit les préfixes 6.6.6.0/24 et 7.7.7.0/24 avec les communautés 100:300 et 100:250, comme indiqué en gras dans la sortie show ip bgp de cette section.

Remarque: Une fois que ces routes sont installées dans la table BGP basée sur la stratégie configurée, la préférence locale 130 est attribuée aux préfixes avec la communauté 100:300 et la préférence locale 125 est attribuée aux préfixes avec la communauté 100:250.

R1# show ip bgp 6.6.6.0 
BGP routing table entry for 6.6.6.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 (6.6.6.1)
����� Origin IGP, metric 0, localpref 130, valid, external, best
����� Community: 100:300

!--- Prefix 6.6.6.0/24 with community 100:300 received from


!--- 10.10.13.3 (R3) is assigned local preference 130.

R1# show ip bgp 7.7.7.0 
BGP routing table entry for 7.7.7.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 (192.168.50.1)
����� Origin IGP, metric 0, localpref 130, valid, internal, best

!--- Received prefix 7.7.7.0/24 over iBGP from 10.10.12.2


!--- (R2) with local preference 130.

� 30
��� 10.10.13.3 from 10.10.13.3 (6.6.6.1)
����� Origin IGP, metric 0, localpref 125, valid, external
����� Community: 100:250

!--- Prefix 7.7.7.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 200.200.200.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
*> 6.6.6.0/24������ 10.10.13.3�������������� 0��� 130����� 0 30 i
*>i7.7.7.0/24������ 10.10.12.2�������������� 0��� 130����� 0 30 i
*������������������ 10.10.13.3�������������� 0��� 125����� 0 30 i

La commande show ip bgp sur R1 confirme que le meilleur chemin sélectionné sur R1 contient la préférence locale (LoclPrf) = 130.

De même, R2 reçoit les préfixes 6.6.6.0/24 et 7.7.7.0/24 avec les communautés 100:250 et 100:300, comme indiqué en gras dans la sortie de la commande show ip bgp de cette section.

Remarque: Une fois que ces routes sont installées dans la table BGP basée sur la stratégie configurée, la préférence locale 130 est attribuée aux préfixes avec la communauté 100:300 et la préférence locale 125 est attribuée aux préfixes avec la communauté 100:250.

R2# show ip bgp 6.6.6.0
BGP routing table entry for 6.6.6.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 (6.6.6.1)
����� Origin IGP, metric 0, localpref 125, valid, external
����� Community: 100:250

!--- Prefix 6.6.6.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 (200.200.200.1)
����� Origin IGP, metric 0, localpref 130, valid, internal, best

!--- Received prefix 6.6.6.0/24 over iBGP from 10.10.12.1


!--- (R1) with local preference 130.

R2# show ip bgp 7.7.7.0
BGP routing table entry for 7.7.7.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 (6.6.6.1)
����� Origin IGP, metric 0, localpref 130, valid, external, best
����� Community: 100:300

!--- Prefix 7.7.7.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
*� 6.6.6.0/24������ 10.10.23.3�������������� 0��� 125����� 0 30 i
*>i���������������� 10.10.12.1�������������� 0��� 130����� 0 30 i
*> 7.7.7.0/24������ 10.10.23.3�������������� 0��� 130����� 0 30 i

Cette sortie de commande show ip bgp sur R2 confirme que le meilleur chemin sélectionné sur R2 a la préférence locale (LoclPrf) = 130.

L'artère IP au ½ 6.6.6.0/24 du ¿  de prefixï préfère le lien R1-R3 quittant hors de l'AS 100 vers EN TANT QUE 30. La commande show ip route sur R1 et R2 confirme cela.

R1# show ip route 6.6.6.0
Routing entry for 6.6.6.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 6.6.6.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 6.6.6.0
Routing entry for 6.6.6.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 6.6.6.0/24 points


!--- to next hop R1 (10.10.12.1) on its iBGP link.


!--- Thus traffic to network 6.6.6.0/24 from R2


!--- exits through R2-R1 and then�R1-R3 link from


!--- AS 100 towards AS 30.

L'artère IP au ½ 7.7.7.0/24 du ¿  de prefixï préfère le lien R2-R3 quittant hors de l'AS 100 vers EN TANT QUE 30. La commande show ip route sur R1 et R2 confirme cela.

R2# show ip route 7.7.7.0�
Routing entry for 7.7.7.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 7.7.7.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 7.7.7.0
Routing entry for 7.7.7.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 7.7.7.0/24 points


!--- to next hop R2 (10.10.12.2) on its iBGP link.


!--- Thus traffic to network 7.7.7.0/24�from�R1


!--- exits through R1-R2 and then�R2-R3 link


!--- from AS 100 towards AS 30.

En cas de défaillance d'une liaison, par exemple de la liaison R1-R3, tout le trafic doit suivre la liaison R2-R3. Vous pouvez simuler cela si vous coupez la liaison entre R1-R3.

R1# conf t
Enter configuration commands, one per line.�End with CNTL/Z.
R1(config)#int s8/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

Notez la table de routage IP pour les préfixes 6.6.6.0/24 et 7.7.7.0/24 sur R1 et R2. Utilisez la liaison R2-R3 afin de quitter l'AS 100.

R1# show ip route 6.6.6.0
Routing entry for 6.6.6.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 7.7.7.0
Routing entry for 7.7.7.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

Cette sortie show command output montre que la route aux préfixes 6.6.6.0/24 et 7.7.7.0/24 pointe vers le prochain saut 10.10.12.2, (R2), comme attendu. Observez maintenant la table de routage IP sur R2 pour contrôler le prochain saut des préfixes 6.6.6.0/24 et 7.7.7.0/24. Le prochain saut doit être R3 pour que la stratégie configurée fonctionne.

R2# show ip route 6.6.6.0
Routing entry for 6.6.6.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 7.7.7.0
Routing entry for 7.7.7.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

Le prochain saut 10.10.23.3 est R3 interface de l'interface série 9/0 sur R2-R3 le ½ du ¿  du lien. ï que ceci confirme la stratégie configurée fonctionne comme prévu.


Informations connexes


Document ID: 28784