Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit comment utiliser les valeurs de communauté BGP pour contrôler la stratégie de routage dans les réseaux de fournisseurs en amont.
Ce document requiert la compréhension du protocole de routage BGP et de son fonctionnement.
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 :
Logiciel Cisco IOS® version 12.2(27)
Routeurs de la gamme Cisco 2500
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Bien que les communautés elles-mêmes ne modifient pas le processus BGP Best Path, les communautés peuvent être utilisées comme indicateurs afin de marquer un ensemble de routes. Les routeurs du fournisseur de services en amont peuvent ensuite utiliser ces indicateurs pour appliquer des stratégies de routage spécifiques (par exemple, la préférence locale) au sein de leur réseau.
Les fournisseurs mappent vos valeurs de communauté configurables et les valeurs de préférence locales correspondantes dans le réseau du fournisseur. Vous pouvez avoir des stratégies spécifiques qui nécessitent la modification de LOCAL_PREF dans le réseau du fournisseur et définir les valeurs de communauté correspondantes 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 communauté sont codées avec un numéro de système autonome (AS) dans les deux premiers octets, les deux autres étant définis par le système autonome. Un préfixe peut avoir plus d'un attribut de la communauté. Un haut-parleur BGP qui voit plusieurs attributs de communauté dans un préfixe peut agir en fonction d'un, d'une partie ou de la totalité des 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 locale indique au système autonome quel chemin est préféré pour atteindre un réseau donné. Lorsqu'il existe plusieurs chemins vers la même destination, le chemin avec la préférence la plus élevée est choisi (la valeur par défaut de l'attribut de préférence locale est 100). Pour plus d'informations, reportez-vous à Études de cas .
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Note: Pour obtenir des informations supplémentaires sur les commandes utilisées dans ce document, utilisez l'outil de recherche de commandes.
Pour simplifier, le mappage d'attribut de communauté et d'attribut de préférence locale est supposé être établi entre le fournisseur de services en amont (AS 100) et votre périphérique (AS 30).
Préférence locale |
Valeurs de la communauté |
130 |
100:300 |
125 |
100:250 |
Si les préfixes sont annoncés avec un attribut de communauté égal à 100:300, alors le fournisseur de services en amont définit la préférence locale de ces routes sur 130 et 125 si l'attribut de communauté est égal à 100:250.
Cela vous permet de contrôler la stratégie de routage au sein du réseau du fournisseur de services si vous modifiez les valeurs de communauté des préfixes annoncés au fournisseur de services.
Dans le schéma de réseau , l'AS 30 souhaite utiliser cette stratégie de routage avec les attributs de communauté.
Le trafic entrant en provenance d'AS 100 destiné au réseau 10.0.10.0/24 traverse la liaison R1-R3. Si la liaison R1-R3 échoue, tout le trafic passe par R2-R3.
Le trafic entrant en provenance d'AS 100 destiné au réseau 10.1.0.0/24 transite par la liaison R2-R3. Si la liaison R2-R3 échoue, tout le trafic passe par R1-R3.
Pour atteindre cette stratégie de routage, R3 annonce ses préfixes comme suit :
À R1 :
À R2 :
10.0.10.0/24 avec un attribut de la communauté 100:250
10.1.0.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 configurée en fonction du mappage entre les attributs de préférence locale et de communauté (indiqué dans la table précédente), et réalisent ainsi la stratégie de routage que vous avez dictée (AS 30). R1 installe les préfixes dans la table BGP.
10.0.10.0/24 avec une préférence locale de 130
10.1.0.0/24 avec une préférence locale de 125
R2 installe le préfixe dans sa table BGP :
10.0.10.0/24 avec une préférence locale de 125
10.1.0.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.
Mise en réseau BGP
Ce document utilise les configurations suivantes :
R3
R1
R2
Current configuration : 2037 bytes
!
version 12.2
!
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
Version 12.2
!
hostname R1
!
interface Loopback0
ip address 200.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
Version 12.2
!
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
R1 reçoit les préfixes 10.0.10.0/24 et 10.1.0.0/24 avec les communautés 100:300 et 100:250, comme indiqué dans le prochain résultat de la commande show ip bgp.
Note: 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 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
.0!--- Received prefix 10.1.0.0/24 over iBGP from 10.10.12.2
!--- (R2) with local preference 130.
!--- (R2) with local preference 130.
30
10.10.13.3 from 10.10.13.3 (198.50.100.0)
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 200.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
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 10.0.10.0/24 et 10.1.0.0/24 avec les communautés 100:250 et 100:300, comme indiqué en gras dans le résultat de la commande show ip bgp :
Note: 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 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 (200.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.0.10.0
BGP routing table entry for 10.0.10.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.0.10.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
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. La route IP vers le préfixe 10.0.10.0/24 préfère que la liaison R1-R3 sorte de l'AS 100 vers l'AS 30. La commande show ip route sur R1 et R2 confirme cette préférence.
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.
La route IP vers le préfixe 10.1.0.0/24 préfère la liaison R2-R3 pour sortir de l'AS 100 vers l'AS 30. La commande show ip route sur R1 et R2 confirme cette préférence.
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.
Si une liaison échoue, par exemple la liaison R1-R3, tout le trafic doit suivre la liaison R2-R3. Vous pouvez simuler ce trafic si vous arrêtez 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 10.0.10.0/24 et 10.1.0.0/24 sur R1 et R2. Utilisez la liaison R2-R3 afin de quitter l'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
Cette sortie show command output montre que la route aux préfixes 10.0.10.0/24 et 10.1.0.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 10.0.10.0/24 et 10.1.0.0/24. Le prochain saut doit être R3 pour que la stratégie configurée fonctionne.
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
Le prochain saut 10.10.23.3 est l'interface R3 Serial 9/0 sur la liaison R2-R3. Ceci confirme que la stratégie configurée fonctionne comme prévu.
Révision | Date de publication | Commentaires |
---|---|---|
4.0 |
11-Jul-2022 |
Recertification pour Cisco.com. Amélioré 7/5/2022 et 7/6/2022 et republié. Réparé et republié le 11/07/2022. |
3.0 |
06-Jul-2022 |
Recertification pour Cisco.com. Amélioré 7/5/2022 et 7/6/2022 et republié. |
2.0 |
22-Jun-2022 |
Recertification pour Cisco.com. |
1.0 |
12-Nov-2002 |
Première publication |