Configuration et vérification de la fonction de publication conditionnelle BGP
Contenu
Introduction
La caractéristique conditionnelle d'annonce de Border Gateway Protocol (BGP) fournit le contrôle supplémentaire de l'annonce de route, selon l'existence d'autres préfixes dans la table BGP.
Conditions préalables
Conditions requises
Avant de tenter cette configuration, assurez-vous que vous êtes familiarisé avec :
Composants utilisés
La fonction de publication conditionnelle BGP décrite dans ce document a été introduite dans des versions de logiciel 11.1CC et 11.2 de Cisco IOS® et est disponible dans des versions ultérieures.
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
-
Version de logiciel 12.2(13)T13 de Cisco IOS®
-
Routeurs de la gamme Cisco 2500
Les informations contenues dans ce document ont été créées à partir des périphériques d'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 votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.
Théorie générale
Normalement, les routes sont propagées indépendamment de l'existence d'un chemin différent. La fonction de publication conditionnelle BGP emploie la non-exister-MAP et les mots clé d'annoncer-MAP de la commande de neighbor advertise-map afin de dépister des artères par le préfixe d'artère. Si un préfixe d'artère n'est pas présent dans la sortie de la commande de non-exister-MAP, alors l'artère spécifiée par la commande d'annoncer-MAP est annoncée. Cette caractéristique est utile pour les réseaux multihomed, dans lesquels quelques préfixes sont annoncés à un des fournisseurs seulement si les informations de l'autre fournisseur ne sont pas présentes (ceci indique une panne dans la session scrutante ou l'accessibilité partielle).
Les annonces conditionnelles BGP sont envoyées en plus des annonces normales qu'un routeur BGP envoie à ses pairs.
Conventions
Pour plus d'informations sur les conventions de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Configurez
Cette section vous fournit des informations pour configurer les fonctionnalités décrites dans ce document.
Note: Pour trouver les informations complémentaires sur les commandes utilisées dans ce document, utilisez l'utilitaire de recherche de commande IOS
Diagramme du réseau
Ce document utilise la configuration réseau indiquée dans le diagramme suivant.
Ici, l'interface de bouclage de R103 est utilisée pour annoncer 192.168.50.0/24 à R102. R102 a un réseau BGP, 128.16.16.0/24, qui est annoncé aux deux ses pairs de BGP externe (eBGP), R101 et R103, par défaut.
Avec la fonction de publication conditionnelle BGP, vous pouvez maintenant accomplir ces tâches sur R102 :
-
Si 192.168.50.0/24 existe dans la table BGP R102, alors n'annoncez pas le réseau 128.16.16.0/24 à R101.
-
Si 192.168.50.0/24 n'existe pas dans la table BGP R102, alors annoncez le réseau 128.16.16.0/24 à R101.
Avec le Cisco IOS® 12.2T ou les versions ultérieures, le mot clé d'exister-MAP peut être utilisé pour accomplir ces tâches aussi bien :
-
Si 192.168.50.0/24 existe dans la table BGP R102, alors annoncez le réseau 128.16.16.0/24 à R101.
-
Si 192.168.50.0/24 n'existe pas dans la table BGP R102, alors n'annoncez pas le réseau 128.16.16.0/24 à R101.
Configurez la caractéristique conditionnelle de publicité
Ce document utilise les configurations suivantes :
Note: L'exemple ici discute le mot clé de non-exister-MAP. L'utilisation du mot clé d'exister-MAP est semblable à ceci.
| R102 |
|---|
hostname R102 ! interface Loopback0 ip address 128.16.16.1 255.255.255.0 ! interface Serial8/0 ip address 10.10.10.2 255.255.255.0 ! interface Serial9/0 ip address 10.10.20.2 255.255.255.0 ! router bgp 2 bgp log-neighbor-changes network 128.16.16.0 mask 255.255.255.0 network 130.130.0.0 neighbor 10.10.10.1 remote-as 1 neighbor 10.10.10.1 advertise-map ADVERTISE non-exist-map NON-EXIST !--- Advertises the routes matched in the route-map ADVERTISE (128.16.16.0/24) !--- only if the routes matched in route-map NON-EXIST (192.168.50.0/24) !--- do not exist in the BGP table. neighbor 10.10.20.3 remote-as 3 ! ip route 130.130.0.0 255.255.0.0 Null0 ! access-list 60 permit 128.16.16.0 0.0.0.255 access-list 65 permit 192.168.50.0 0.0.0.255 ! route-map NON-EXIST permit 10 match ip address 65 ! route-map ADVERTISE permit 10 match ip address 60 ! |
| R103 |
|---|
hostname R103 ! interface Loopback0 ip address 192.168.50.1 255.255.255.0 ! interface Serial9/0 ip address 10.10.20.3 255.255.255.0 ! router bgp 3 bgp log-neighbor-changes network 192.168.50.0 neighbor 10.10.20.2 remote-as 2 ! |
| R101 |
|---|
hostname R101 ! interface Loopback0 ip address 200.200.200.1 255.255.255.0 ! interface Serial8/0 ip address 10.10.10.1 255.255.255.0 ! router bgp 1 bgp log-neighbor-changes network 200.200.200.0 neighbor 10.10.10.2 remote-as 2 ! |
Vérifier la configuration
Exemple 1
Cet exemple vérifie quel BGP ressemble à quand 192.168.50.0/24 est dans la table BGP R102 :
Premier contrôle pour voir si 192.168.50.0/24 existe dans la table BGP R102 :
R102# show ip bgp BGP table version is 6, local router ID is 128.16.16.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 *> 128.16.16.0/24 0.0.0.0 0 32768 i *> 130.130.0.0 0.0.0.0 0 32768 i *> 192.168.50.0 10.10.20.3 0 0 3 i *> 200.200.200.0 10.10.10.1 0 0 1 i
Puisque 192.168.50.0/24 est dans la table BGP R102, puis R102 ne doit pas annoncer 128.16.16/24 à R101.
R102# show ip bgp neighbors 10.10.10.1 advertised-routes
BGP table version is 6, local router ID is 128.16.16.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
*> 130.130.0.0 0.0.0.0 0 32768 i
*> 192.168.50.0 10.10.20.3 0 0 3 i
!--- Note 128.16.16.0/24 is not advertised to neighbor 10.10.10.1.
R102# show ip bgp 128.16.16.0
BGP routing table entry for 128.16.16.0/24, version 6
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
!--- This is not advertised to R101.
10.10.20.3
Local
0.0.0.0 from 0.0.0.0 (128.16.16.1)
Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
Vérifiez alors l'état de la publicité conditionnelle sur R102 :
R102# show ip bgp neighbors 10.10.10.1 BGP neighbor is 10.10.10.1, remote AS 1, external link BGP version 4, remote router ID 200.200.200.1 BGP state = Established, up for 02:27:07 Last read 00:00:07, hold time is 180, keepalive interval is 60 seconds !--- Output suppressed. For address family: IPv4 Unicast BGP table version 6, neighbor version 6 Index 1, Offset 0, Mask 0x2 Condition-map NON-EXIST, Advertise-map ADVERTISE, status: Withdraw 1 accepted prefixes consume 36 bytes Prefix advertised 3, suppressed 0, withdrawn 1 Number of NLRIs in the update sent: max 1, min 0 !--- Output suppressed.
La sortie prouve que la publicité conditionnelle « est retirée » et que les réseaux qui apparient le route-map « ANNONCENT » ne sont pas annoncés au pair 10.10.10.1.
Afin de confirmer les artères qui apparient le route-map « ANNONCEZ » ne sont pas annoncés à R101, vérifient la table BGP sur R101 :
R101# show ip bgp 128.16.16.0 % Network not in table
Exemple 2
Cet exemple affiche quel BGP ressemble à quand le réseau 192.168.50.0/24 n'existe pas dans la table BGP R102 :
D'abord, arrêtez l'interface 0 de bouclage sur R103 de sorte que R103 n'annonce plus 192.168.50.0/24 à R102.
R103(config)# interface loopback 0 R103(config-if)# shutdown R103(config-if)# 03:29:36: %LINK-5-CHANGED: Interface Loopback0, changed state to administratively down
Vérifiez alors que R102 n'apprend pas 192.168.50.0/24 et que le réseau n'est pas inclus dans la table BGP R102.
R102# show ip bgp BGP table version is 8, local router ID is 128.16.16.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 *> 128.16.16.0/24 0.0.0.0 0 32768 i *> 130.130.0.0 0.0.0.0 0 32768 i *> 200.200.200.0 10.10.10.1 0 0 1 i !--- Note 192.168.50.0/24 is not present.
Maintenant, voyez dans combien de temps il prend pour la publicité conditionnelle donnent un coup de pied :
R102# debug ip bgp updates *Mar 1 02:39:18.059: BGP(0): 10.10.20.3 rcv UPDATE about 192.168.50.0/24 -- withdrawn *Mar 1 02:39:18.059: BGP(0): no valid path for 192.168.50.0/24 *Mar 1 02:39:18.079: BGP(0): nettable_walker 192.168.50.0/24 no best path *Mar 1 02:39:18.219: BGP(0): 10.10.10.1 computing updates, afi 0, neighbor version 10, table version 11, starting at 0.0.0.0 *Mar 1 02:39:18.219: BGP(0): 10.10.10.1 send unreachable 192.168.50.0/24 *Mar 1 02:39:18.219: BGP(0): 10.10.10.1 send UPDATE 192.168.50.0/24 -- unreachable *Mar 1 02:39:18.219: BGP(0): 10.10.10.1 1 updates enqueued (average=27, maximum=27) *Mar 1 02:39:18.219: BGP(0): 10.10.10.1 update run completed, afi 0, ran for 0ms, neighbor version 10, start version 11, throttled to 11 *Mar 1 02:40:04.747: BPG(0): Condition NON-EXIST changes to Advertise *Mar 1 02:40:04.747: BGP(0): net 128.16.16.0/24 matches ADV MAP ADVERTISE: bump version to 12 *Mar 1 02:40:05.187: BGP(0): nettable_walker 128.16.16.0/24 route sourced locally *Mar 1 02:40:05.187: BGP(0): 10.10.10.1 computing updates, afi 0, neighbor version 11, table version 12, starting at 0.0.0.0 *Mar 1 02:40:05.187: BGP(0): 10.10.10.1 128.16.16.0/24 matches advertise map ADVERTISE, state: Advertise *Mar 1 02:40:05.187: BGP(0): 10.10.10.1 send UPDATE (format) 128.16.16.0/24, next 10.10.10.2, metric 0, path *Mar 1 02:40:05.187: BGP(0): 10.10.10.1 1 updates enqueued (average=52, maximum=52) *Mar 1 02:40:05.187: BGP(0): 10.10.10.1 update run completed, afi 0, ran for 0ms, neighbor version 11, start version 12, throttled to 12
Le processus conditionnel de publicité est déclenché par le processus de scanner BGP, qui exécute toutes les 60 secondes. Ceci signifie que l'heure maximum pour que la publicité conditionnelle la prenne effet est de 60 secondes. La publicité conditionnelle peut la prendre effet plus tôt, selon quand l'artère dépistée est retirée de la table BGP et quand le prochain exemple du scanner BGP se produit. Émettez ces commandes sur R102 afin de vérifier l'état conditionnel de publicité sur R102 pour 10.10.10.1 voisin :
R102# show ip bgp neighbors 10.10.10.1 BGP neighbor is 10.10.10.1, remote AS 1, external link BGP version 4, remote router ID 200.200.200.1 BGP state = Established, up for 02:45:27 Last read 00:00:27, hold time is 180, keepalive interval is 60 seconds !--- Output suppressed. For address family: IPv4 Unicast BGP table version 12, neighbor version 12 Index 1, Offset 0, Mask 0x2 Condition-map NON-EXIST, Advertise-map ADVERTISE, status: Advertise 1 accepted prefixes consume 36 bytes Prefix advertised 6, suppressed 0, withdrawn 4 Number of NLRIs in the update sent: max 1, min 0 !--- Output suppressed.
La table BGP R101 et la table de routage a 128.16.16.0/24, comme affiché ici :
Note: Dans cette sortie témoin, les annonces conditionnelles BGP (réseau 128.16.16.0/24) sont envoyées, en plus des annonces normales BGP (réseau 130.130.0.0/16) qu'un routeur BGP envoie à ses pairs.
R101# show ip bgp BGP table version is 18, 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 *> 128.16.16.0/24 10.10.10.2 0 0 2 i *> 130.130.0.0 10.10.10.2 0 0 2 i *> 200.200.200.0 0.0.0.0 0 32768 i
R101# show ip route bgp
128.16.0.0/24 is subnetted, 1 subnets
B 128.16.16.0 [20/0] via 10.10.10.2, 00:09:32
B 130.130.0.0/16 [20/0] via 10.10.10.2, 02:48:46
Exemple 3
Cet exemple comporte la réinstallation du réseau 192.168.50.0/24 dans R102 afin de voir de comment les modifications BGP « annoncent » « se retirent. »
Afin de réinstaller 192.168.50.0/24, n'émettez l'aucune commande shutdown d'apporter le bouclage 0 d'interface sur R103 à « VERS LE HAUT DE ».
R103(config)# interface loopback 0 R103(config-if)# no shutdown R103(config-if)# 03:49:06: %LINK-3-UPDOWN: Interface Loopback0, changed state to up 03:49:07: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up !--- R102 kicks in conditional advertisement the moment the !--- conditional network is received again. *Mar 1 02:51:42.227: BGP(0): 10.10.20.3 rcvd UPDATE w/ attr: nexthop 10.10.20.3, origin i, metric 0, path 3 *Mar 1 02:51:42.227: BGP(0): 10.10.20.3 rcvd 192.168.50.0/24 *Mar 1 02:51:42.247: BGP(0): Revise route installing 192.168.50.0/24 -> 10.10.20.3 to main IP table *Mar 1 02:51:42.379: BGP(0): 10.10.10.1 computing updates, afi 0, neighbor version 12, table version 13, starting at 0.0.0.0 *Mar 1 02:51:42.379: BGP(0): 10.10.10.1 send UPDATE (format) 192.168.50.0/24, next 10.10.10.2, metric 0, path 3 *Mar 1 02:51:42.379: BGP(0): 10.10.10.1 1 updates enqueued (average=47, maximum=47) *Mar 1 02:51:42.379: BGP(0): 10.10.10.1 update run completed, afi 0, ran for 0ms, neighbor version 12, start version 13, throttled to 13 *Mar 1 02:52:09.159: BPG(0): Condition NON-EXIST changes to Withdraw *Mar 1 02:52:09.159: BGP(0): net 128.16.16.0/24 matches ADV MAP ADVERTISE: bump version to 14 *Mar 1 02:52:09.499: BGP(0): nettable_walker 128.16.16.0/24 route sourced locally *Mar 1 02:52:11.559: BGP(0): 10.10.10.1 computing updates, afi 0, neighbor version 13, table version 14, starting at 0.0.0.0 *Mar 1 02:52:11.559: BGP(0): 10.10.10.1 128.16.16.0/24 matches advertise map ADVERTISE, state: Withdraw *Mar 1 02:52:11.559: BGP(0): 10.10.10.1 send unreachable 128.16.16.0/24 *Mar 1 02:52:11.559: BGP(0): 10.10.10.1 send UPDATE 128.16.16.0/24 -- unreachable *Mar 1 02:52:11.559: BGP(0): 10.10.10.1 1 updates enqueued (average=27, maximum=27) *Mar 1 02:52:11.559: BGP(0): 10.10.10.1 update run completed, afi 0, ran for 0ms, neighbor version 13, start version 14, throttled to 14
R102 n'annonce plus 128.16.16.0/24 à R101.
R102# show ip bgp neighbors 10.10.10.1 advertised-routes BGP table version is 14, local router ID is 128.16.16.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 *> 130.130.0.0 0.0.0.0 0 32768 i *> 192.168.50.0 10.10.20.3 0 0 3 i !--- Note 128.16.16.0/24 is not advertised. R102# show ip bgp neighbors 10.10.10.1 BGP neighbor is 10.10.10.1, remote AS 1, external link BGP version 4, remote router ID 200.200.200.1 BGP state = Established, up for 03:01:32 Last read 00:00:31, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: !--- Output supressed. For address family: IPv4 Unicast BGP table version 14, neighbor version 14 Index 1, Offset 0, Mask 0x2 Condition-map NON-EXIST, Advertise-map ADVERTISE, status: Withdraw 1 accepted prefixes consume 36 bytes Prefix advertised 7, suppressed 0, withdrawn 5 Number of NLRIs in the update sent: max 1, min 0 !--- Output supressed.
Note: Dans un scénario de monde réel, AS1 et AS3 sont connectés à l'Internet (BGP global). Par conséquent le réseau 192.168.50.0/24 pourrait être propagé par une maille globale BGP d'AS3 à la table BGP AS1 (R101). AS1, consécutivement, pourrait propager le préfixe 192.168.50.0 à R102 (selon l'accord de stratégie entre AS1 et AS2). Si R101 propage les artères AS3 apprises du maillage BGP global à R102, alors la publicité conditionnelle peut échouer si des contrôles supplémentaires ne sont pas placés dans la carte de non-exister.
Afin de comprendre mieux pourquoi la publicité conditionnelle échoue, considérez ce scénario. AS1 apprend 192.168.50.0/24 de la maille globale BGP et annonce 192.168.50.0/24 à AS2 (R102). R102 apprend également le préfixe 192.168.50.0/24 de son scruter direct à R103 (au-dessus du R102 à lien R103). Quand le lien direct entre R102 et R103 échoue, vous prévoyez que le préfixe 192.168.50.0/24 cesse d'exister dans la table BGP R102 et la publicité conditionnelle donne un coup de pied dedans et annonce le préfixe 128.16.16.0/24 à R101. Cependant, puisque le préfixe 192.168.50.0/24 continue à exister dans la table BGP R102 (apprise de R101), la publicité conditionnelle se casse parce que le préfixe dans la carte de non-exister existe toujours dans la table BGP R102. Pour s'assurer que le préfixe 192.168.50.0/24 est appris seulement de la liaison directe à AS3 (R102 à R103) pour que la publicité conditionnelle donne un coup de pied dedans, ajoutez une déclaration d'as_path de correspondance sous la carte de non-exister qui apparie l'AS_PATH du préfixe 192.168.50.0/24 instruit de la liaison directe (qui est dans ce cas EN TANT QUE 3). L'expression régulière pour ce cas est ^3. Pour plus d'informations sur des expressions régulières, référez-vous en utilisant des expressions régulières dans le BGP. Prenez garde que vous ne pouvez pas apparier juste le comme-chemin, et ne pas apparier le préfixe. Le match as-path peut seulement compléter les critères de correspondance pour le préfixe apparié. En d'autres termes, vous ne pouvez pas annoncer quelques préfixes à un voisin si aucun préfixe n'existe d'un certain COMME #.
La nouvelle configuration sur R102 est affichée ici. Les ajouts sont en gras.
| R101 |
|---|
hostname R102 ! interface Loopback0 ip address 128.16.16.1 255.255.255.0 ! interface Serial8/0 ip address 10.10.10.2 255.255.255.0 ! interface Serial9/0 ip address 10.10.20.2 255.255.255.0 ! router bgp 2 bgp log-neighbor-changes network 128.16.16.0 mask 255.255.255.0 network 130.130.0.0 neighbor 10.10.10.1 remote-as 1 neighbor 10.10.10.1 advertise-map ADVERTISE non-exist-map NON-EXIST neighbor 10.10.20.3 remote-as 3 ! ip route 130.130.0.0 255.255.0.0 Null0 ! ip as-path access-list 1 permit ^3 ! access-list 60 permit 128.16.16.0 0.0.0.255 access-list 65 permit 192.168.50.0 0.0.0.255 ! route-map NON-EXIST permit 10 match ip address 65 match as-path 1 ! route-map ADVERTISE permit 10 match ip address 60 ! |
Problèmes identifiés
Il y a quelques bogues connu qui associent au BGP et à la publicité conditionnelle. Le pour en savoir plus, se rapportent aux bogues CSCdp18563 (clients enregistrés seulement) et CSCdp20320 (clients enregistrés seulement) dans le Bug Toolkit.
Informations connexes
CommentairesLaissez-nous vous aider
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)