Ce post a pour but de présenter les grandes bases du protocole BGP tout en l'appliquant sur un lab GNS3.

Nous étudierons la mise en place des sessions BGP entre différents réseaux (AS), nous verrons comment ont lieu les annonces de routes et comment on peut les influencer que ce soit pour les échanges au sein du même réseau (iBGP) ou de différents réseaux/AS (eBGP).

La suite logique de cette présentation est "Concepts et maquette du protocole MPLS".

Prérequis de la maquette

GNS3 :

  • c7200-adventerprisek9-mz.124-24.T8.image

Branchement de 12 routeurs c7200 sur un switch

Interconnection des routeurs sur GNS3

Interconnection niveau 3 entre les routeurs

Interconection niveau 3 des routeurs

Pour le réseau d’interco entre deux routeurs on prend le plus petit chiffre d’abord :

Exemple entre R1 et R3 :

  • vlan 13
  • ip sur R1 : 13.13.13.1/24
  • ip sur R3 : 13.13.13.3/24

Mise en place des adjacences BGP dans l’AS123 (iBGP)

On souhaite monter les adjacences sur les loopbacks des routeurs pour ne pas être dépendant de l’état des interco physiques. (Utile dans les cas ou il y’a de nombreux routeurs dans un AS pour assurer la redondance des sessions BGP, on dispose de plusieurs chemins pour joindre les loopbacks).

Pour annoncer les loopbacks au sein de l’AS 123 on utilise un IGP, ici OSPF :

exemple sur R3 :

R3# interface Loopback0
 ip address 3.3.3.3 255.255.255.255
 ip ospf 1 area 0

interface FastEthernet0/0.13
 encapsulation dot1Q 13
 ip address 13.13.13.3 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
!
interface FastEthernet0/0.23
 encapsulation dot1Q 23
 ip address 23.23.23.3 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0

Même chose sur R1,R2 on peut ensuite joindre les loopbacks depuis les routeurs du même AS.

Pour monter les adjencences entre les loopbacks :

exemple sur R3 :

R3# router bgp 123
  no synchronization
  bgp log-neighbor-changes
  neighbor 1.1.1.1 remote-as 123
  neighbor 1.1.1.1 update-source Loopback0
  neighbor 2.2.2.2 remote-as 123
  neighbor 2.2.2.2 update-source Loopback0
  no auto-summary
Attention ! L’attribut update-source est nécessaire sinon les updates auront lieux à partir des interfaces physiques et non des loopbacks

Même configuration sur R1 & R2.

Mise en place des adjacences BGP entre les différents AS (eBGP)

Même principe pour mettre en place les sessions BGP entre les différents AS sauf que l’on utilise les IP des interfaces physiques.

exemple sur R5 vers R7 et R2 :

R5# router bgp 5
 no synchronization
 bgp log-neighbor-changes
 neighbor 25.25.25.2 remote-as 123
 neighbor 57.57.57.7 remote-as 7
 no auto-summary

On fait la même chose pour l’ensemble des autres routeurs.

Toutes les sessions BGP sont maintenant montées et « established »

Annonce des routes

Sur chaque routeur on crée une loopback1 avec une ip/32 que l’on souhaite router entre les différents AS.

exemple sur R7 :

R7# interface Loopback1
 ip address 77.77.77.77 255.255.255.255
!

On annonce ce réseau dans la configuration BGP :

R7# router bgp 7
 network 77.77.77.77 mask 255.255.255.255

Tous les réseaux sont maintenant annoncés.

Résolution des problèmes

next-hop-self

Au sein de l’AS123 il manque l’option next-hop-self. En effet par défaut les sessions iBGP conservent les next-hop apprises en eBGP.

De ce fait, R3 ne connaît pas la route de R4 car le next-hop est l’ip "physique" de l'interco R1<->R4, or R3 ne connaît pas cette IP.

Pour modifier cela, et pour forcer R1 à annoncer la route de de R4 (44.44.44.44) avec son ip en tant que next-hop et non l’ip de R4, on ajoute cette attribut :

R1# router bgp 123
 no synchronization
 bgp log-neighbor-changes
 neighbor 3.3.3.3 remote-as 123
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 3.3.3.3 next-hop-self

Même chose sur R2, R6 et 58.

Une route apprise par iBGP n’est pas renvoyée par iBGP.

De ce fait, R3 ne renvoie pas le préfixe de R5 à R1 car il l’a apprise en iBGP. Deux solutions sont alors possibles :

  • Full-mesh, on fait une adjacence entre tous les routeurs du même AS.
  • Route-reflector, le trafic sera renvoyé d’un client iBGP vers un client iBGP du route-reflector.

Dans notre cas R3 sera route-reflector :

R3# router bgp 123
 no synchronization
 bgp log-neighbor-changes
 network 33.33.33.33 mask 255.255.255.255
 neighbor 1.1.1.1 remote-as 123
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 1.1.1.1 route-reflector-client
 neighbor 2.2.2.2 remote-as 123
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 route-reflector-client

Script pour tester le ping des loopbacks :

en tclsh :

R1# tclsh
foreach i {
44.44.44.44
55.55.55.55
33.33.33.33
66.66.66.66
77.77.77.77
88.88.88.88
99.99.99.99
} { ping $i source loopback1 }

Modification des attributs BGP

Il est possible de jouer et d'influencer la priorisation des routes apprises et annoncées par les routeurs, Cisco les traites selon un certain ordre, nous verrons ici les principales méthodes pour influencer cet apprentissage :

  • weight
  • local-pref
  • as-path
  • community

weight

Cet attribut est configuré localement sur un routeur et n'est pas propagé, il s'agit d'une valeur propre à Cisco.

Nous avons modifié le weight du neighbor BGP entre R3 ↔ R2 pour prioriser les routes de R9 (et du coup toutes les routes apprises par R2).

Sur R3 :

R3# router bgp 123
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 route-reflector-client
 neighbor 2.2.2.2 weight 500

On clear les adjacences

R3# clear ip bgp * soft

Cet attribut modifie le poids de toutes les routes annoncées par le neighbor.

Pour modifier seulement quelques routes on utilise une route-map.

  • Création sur R2 d’une prefix-list lo99 avec le préfix de R9
  • On match cette prefix-list sur la route-map FROM_R5 et on applique l’attribut  weight
  • On assigne cette route-map au neighbor

exemple sur R2 :

R2# 
ip prefix-list lo99 seq 5 permit 99.99.99.99/32
!
route-map FROM_R5 permit 10
 match ip address prefix-list lo99
 set weight 1000
!
route-map FROM_R5 permit 20
!
router bgp 123
 neighbor 25.25.25.5 remote-as 5
 neighbor 25.25.25.5 route-map FROM_R5 in

local-preference

On souhaite prioriser pour tout l’AS123 les routes reçues de l’AS10 concernant R8, en augmentant la local-preference

Ainsi on force l’AS123 à sortir par l’AS10 pour joindre R8. Pour cela :

Sur R2 :

R2# 
ip prefix-list lo88 seq 5 permit 88.88.88.88/32
!
route-map FROM_R10 permit 10
 match ip address prefix-list lo88
 set local-preference 120
!
route-map FROM_R10 permit 20
!
router bgp 123
 neighbor 10.10.10.10 remote-as 10
 neighbor 10.10.10.10 ttl-security hops 2
 neighbor 10.10.10.10 update-source Loopback0
 neighbor 10.10.10.10 route-map FROM_R10 in

Les flux à destination de 88.88.88.88 sortent maintenant par l’AS10 pour tout l’AS123.

AS-PATH

L’attribut « AS-PATH » est transmis aux AS voisins BGP qui doivent le prendre en charge.

As prepending :

Avec l’AS prepending on peut influencer l’entrée des flux de son AS.

« The AS path is a well-known mandatory attribute, which means that it’s present for all prefixes exchanged between BGP neighbors. When a BGP router sends out an update to a neighbor in a different autonomous system (i.e., an external or eBGP neighbor), it adds its own AS number to the front (left side) of the AS path »

Sur R2 on va annoncer à R5 et R10 que pour joindre R3 il y’a 3 sauts au lieu de 1 actuellement, ainsi on obligera le routage des flux entrants par R4.

« On va prépendre dans l’AS-path 2 nouveaux sauts ».

Sur R2 :

R2# 
 neighbor 10.10.10.10 remote-as 10
 neighbor 10.10.10.10 ttl-security hops 2
 neighbor 10.10.10.10 update-source Loopback0
 neighbor 10.10.10.10 route-map FROM_R10 in
 neighbor 10.10.10.10 route-map R5_OUT out
 neighbor 25.25.25.5 remote-as 5
 neighbor 25.25.25.5 route-map FROM_R5 in
 neighbor 25.25.25.5 route-map R5_OUT out
!
ip prefix-list lo33 seq 5 permit 33.33.33.33/32
!
route-map R5_OUT permit 10
 match ip address prefix-list lo33
 set as-path prepend 123 123
!
route-map R5_OUT permit 20

Depuis R5 on regarde la route de 33.33.33.33 :

La best-route est maintenant celle qui passe par R4.

Community

Les attributs sont des attributs optionnal transitive, c’est à dire qu’un attribut appliqué sur un AS peut être envoyé vers un autre AS.
Un provider peut utiliser les communities avec un autre provider pour que son préfixe soit traité de manière spécifique.

Par défaut il existe un certain nombre communities déjà existantes sur les équipements des différents constructeurs et définis par des RFC.

Exemple, la community no-export permet d’annoncer son préfixe seulement aux voisins directs.

La community local-AS n’avertira les préfixes qu’aux voisins du même AS.

On souhaite appliquer une community pour que R9 annonce sa loopback sur l’AS68 mais que l’AS68 ne puisse pas le ré-annoncer aux autres voisins, il s’agit de la community no-export.

Sur R9 :

interface Loopback10
 ip address 10.99.99.99 255.255.255.255
!
router bgp 9
 network 10.99.99.99 mask 255.255.255.255
 neighbor 89.89.89.8 remote-as 68
 neighbor 89.89.89.8 send-community
 neighbor 89.89.89.8 route-map TO_R8 out
!
route-map TO_R8 permit 10
 match ip address prefix-list lo1099
 set community no-export

Sur R8 on apprend la route de 10.99.99.99, cependant il ne renvoie pas ce préfixe aux autres voisins e-BGP (R7), en activant l’option send-community sur les autres voisins du même AS68 ils apprendront aussi la route.

Pour vérifier depuis R8 :

Dernier cas :

On souhaite faire une community sur R9 et R8 pour que le réseau annoncé par R9 soit "prépender" de 3 AS-paths pour R7.

Résultat attendu depuis R7 :

Pour cela on crée une custom community sur R9 et R8, puis on match la community et on prépend.

Sur R9 :

interface Loopback99
 ip address 10.9.9.9 255.255.255.255
!
ip prefix-list lo99 seq 5 permit 10.9.9.9/32
!
route-map TO_R8 permit 15
 match ip address prefix-list lo99
 set community 9:100

Sur R8 :

ip community-list standard PREPEND3HOP permit 9:100
!
route-map TO_R7 permit 10
 match community PREPEND3HOP
 set as-path prepend 68 68 68

On vérifie avec show ip bgp 10.9.9.9 que la community est transitée.