Vous êtes sur la page 1sur 12

Rappel des différents niveaux

ENSERG - ENSIMAG Localement : découverte des routeurs


3ème année « Télécom » ARR par RDP en IPv4, RS/RA en IPv6

Technologies de routage avancé


Au sein d’un domaine d’administration :
des protocoles intérieurs IGP

Deux classes d’algorithmes :


À vecteurs de distance : RIP(v2), (E)IGRP
Pierre.Laforgue@imag.fr
À état des liens : OSPF, IS-IS

1 2

Objectifs distincts
Au sein d’un réseau de transit
(éventuellement) : MPLS
Protocoles intérieurs :
Optimiser
Entre domaines d’administration : Fiabiliser
un seul protocole extérieur, BGP4
Classe : à vecteurs de chemins
Protocole extérieur :
Usage entre opérateurs :
Maintenir la connectivité
full routing ~120 000 routes
Appliquer une « policy » (contrats, AUP, COU)
sinon, acceptation d’une route par défaut
Sécuriser

3 4

Granularité Notion de système autonome (AS)


Ensemble de routeurs et de réseaux administrés par une
même organisation (responsabilité unique) ou publiés par
Protocole intérieur : un réseau IP une même organisation (e.g. un opérateur)
(un préfixe « X/n »)
Routeurs internes Routeur de bord
Protocole extérieur : une liste de réseaux
IP (préfixes « X/n ») :
appartenant à un « système autonome »
et
relevant d’une même « policy »
SYSTÈME AUTONOME

ex. : un AS par campus, réseau « régional », ISP, transporteur, …


5
ou un AS pour un IAP incluant tous ses clients 6

1
Les numéros d’AS Différence avec les aires d’OSPF :
Aire = ensemble de réseaux IP, les routeurs de bord étant à
cheval sur plusieurs aires
Ressource bientôt (2005 ?) rare : 2**16 AS = ensemble de routeurs, un routeur appartenant à un AS

Routeur de bord d’AS


Actuellement ~ 11 000 AS publics visibles
Routeurs internes
dans les échanges BGP AS x

AS officiels (publics) : [ 1 – 64511 ]


Plage d’AS « privés » (non annoncés par
les opérateurs) : [ 64512 – 65535 ]
AIRE 1 OSPF AIRE 2 OSPF

Routeur de bord d’aire


7 8

Objectifs du protocole BGP Objectifs de BGP (suite)


Interconnexion d’organismes Indépendance vis-à-vis des IGP internes aux AS
Mais au sein de chaque AS : appui sur IGP &
indépendants voire concurrents
import / export routes entre IGP et BGP.
opérateurs
grandes entreprises, campus, …
relations de gré à gré entre 2 AS « Scalability » : capacité d’adaptation à
y compris dans des points d’échange multi-AS : différentes échelles ( routage Internet)
NAP, MAE, CIX, GIX, …
Network Access Point, Metropolitan Area Ethernets, Commercial/Global Internet eXchange
Minimisation du trafic de service
Application de politiques de routage
indépendantes (mais compatibles ☺) Stabilité du routage
Respect des contrats passés entre organismes
Sûreté de fonctionnement
9 10

2 principes généraux Stub AS


Stub AS = un seul point de connexion
Mode connecté BGP non nécessaire / alternatives :
routage statique ou un IGP sommaire
versus datagrammes (ex. RIP) ou gestion propre
de sessions (OSPF) sur IP
Ou BGP ( contrôle) donc AS mais privé
BGP ne transmet que les modifications
Sessions TCP entre les routeurs de bord d’AS, en interne
au sein de l’AS comme entre 2 AS

Point à point entre routeurs de bord d’AS :


symétrie entre pairs

11 12

2
stub AS
avec numéro d’AS privé
« Multi-homed » sans transit

BGP recommandé

ISP BG
P
AS 454

Lien physique CLIENT


Session BGP AS 64512

Utilisation possible d’un AS privé (64512 à 65535) l’opérateur


requalifiera les routes du client sous son propre AS, public.
13 14

Client « multi-homed » sur une sortie Deux points de sortie


2 sorties, vers 1 ou vers 2 autre(s) AS
Opérateur 1
deux motivations possibles :
R2
optimisation géographique et/ou redondance
P AS 286
BG
CLIENT R1
AS 100
BG AS 300
AS 14298 P
E-BGP
Opérateur 2
R1 a deux voisins « pairs BGP » : R2 et R3
Exemple de stratégie du client : R3 I-BGP
annonce globale de toutes ses routes aux deux, E-BGP
AS 454 BGP Externe
annonce de routes plus précises à chacun
équilibrage + redondance BGP Interne
Autre exemple sécurisation (redondance uniquement) AS 200
Autre exemple respect de 2 AUP différentes (partition)

15 16

N points de sortie Échange des routes au sein de l’AS


Au sein d’un AS relié à plusieurs routeurs
d’un ou plusieurs autres AS :

AS 100 Les routeurs de bord de l’AS s’échangent leurs


E-BGP E-BGP
informations de routage en I-BGP
AS 300
AS 400
Ces connexions I-BGP doivent former un
E-BGP E-BGP
maillage complet « full mesh »entre tous les
routeurs de bord de l’AS
AS 200
I-BGP

BGP Externe
BGP Interne
17 18

3
Échange des routes au sein de l’AS Les composants d’un routeur BGP
La description statique de la « politique » :
Le maillage I-BGP est un maillage de
ce qu’on accepte d’annoncer à chacun
connexions logiques (sessions TCP) et non
ce qu’on accepte comme annonces des autres
pas physiques : les routeurs de bord sont
les critères et traitements d’attributs
rarement reliés directement dans un AS
Les IGP internes à l’AS (exemple : OSPF)
maintiennent une connectivité entre tous Les tables dynamiques contenant les
les routeurs de bord via d’autres routeurs informations de routage :
internes un routeur BGP utilise 1 des 3 En entrée : la table Adj-RIB-in
protocoles IGP, I-BGP et E-BGP avec En sortie : la table Adj-RIB-out
chaque partenaire selon le rôle de celui-ci. En interne : la table Loc-RIB
19 20

Le processus BGP
Les 4 messages BGP
au sein d’un routeur

Réception d’annonces Envoi d’annonces


Le processus BGP d’un routeur interagit
avec ceux d’autres routeurs par 4 types de
Politique de Politique de
messages :
filtrage en entrée filtrage en sortie OPEN
KEEPALIVE
NOTIFICATION
Adj-RIB-in Loc-RIB Loc-RIB-out
UPDATE
Processus BGP
Taille : de 19 à 4096 octets
Sécurisation optionnelle par MD5
Configuration Table de propre BGP ou au niveau TCP :
locale routeur (+IGP) routage 16 octets fonction(TCPseg, secret partagé)
21 22

Le message OPEN Le message KEEPALIVE


1er message de la session TCP Confirme un OPEN
Indique au partenaire :
son propre identifiant de routeur BGP
(exemple : adresse IP d’une interface loopback, comme Réarme le chien de garde de la session
en OSPF)
des paramètres optionnels
Propose une durée de maintien session Si temps de maintien non nul, réémission
Valeurs suggérées : 3 à 90 secondes
toutes les N secondes – recommandation :
choix de la plus faible N = 1/3 du hold time (ex. N=30 s pour hold=90s)
0 = maintien sans limite de durée
Met le processus en attente d’un KEEPALIVE Message de taille minimale, 19 octets

23 24

4
Le message NOTIFICATION Le message UPDATE

Ferme la session BGP et la session TCP But : retrait ou ajout d’annonces


Fournit un code et un sous-code d’erreur
Annule les routes apprises par BGP 1. liste des préfixes à retirer : réseaux que
[ opt. configurer le maintien des routes] l’AS ne peut plus atteindre
Émission sur tout incident : 2. liste d’attributs communs à TOUS les
Aucun KEEPALIVE reçu pendant <hold time> préfixes IP du champ NLRI : origine,
Réception d’un message incorrect chemin d’AS, métriques et préférences, …
Erreur automate, etc. 3. « NLRI » = liste des préfixes annoncés
(ajout à ceux annoncés précédemment)

25 26

Le message UPDATE Le message UPDATE

Un attribut = type + valeur + 4 flags : Envoyé uniquement si changement


Optionnel / « Bien-connu »
* Un attribut « bien-connu » peut être : Deux effets :
de présence obligatoire (ex. AS-path),
ou facultative (ex. Local-Pref). Modification des tables RIB du processus
* Un attribut optionnel peut être :
Transitif / Intransitif Envoi d’Updates aux autres voisins
Partiel / Complet
Sur 1 octet / sur 2
27 28

L’automate BGP Attributs des routes d’un UPDATE

(simplifié) Universels (« bien-connus ») obligatoires :


ORIGIN, AS_PATH, NEXT_HOP
Ouverture Envoi
LIBRE
Session TCP
CONNECTÉ
OPEN
OPEN ENVOYÉ Universels non obligatoires :
NOT E
LOCAL_PREF, ATOMIC_AGGREGATE
IFY IV
AL
EP Optionnels et ré-annonçables :
KE
MULTI_EXIT_DISC (MED), AGGREGATOR
SESSION ETABLIE
UPDATE KEEPALIVE
Optionnels et non transitifs
WEIGHT (spécifique Cisco), …

29 30

5
L’attribut obligatoire ORIGIN L’attribut obligatoire AS-PATH
Source de l’info. sur la route, 3 cas :
Liste ordonnée des AS via lesquels a transité
IGP route intérieure à l’AS d’origine l’annonce de préfixes NLRI, en fait :
Ne signifie pas « apprise par IGP » mais « spécifiée par combinaison d’ensembles et de séquences d’AS
une directive network et route connue, vérifiée par IGP)
AS1 annonce 193.212.0.0/24 - - 1
AS2 annonce 193.212.1.0/24 - - 2
EGP : route apprise via un EGP (BGP4)
AS3 annonce 193.212.0.0/23 - - 3 (1 2)
INCOMPLETE : autre origine AS4 annonce 193.212.0.0/23 - - 4 3 (1 2)
origine inconnue, déclaration statique ou redistribution Ensemble si agrégation de morceaux d’origines différentes
d’un IGP Les agrégations se font le plus souvent à chemins d’AS
identiques Séquence d’AS en général
Préférence : IGP > EGP > INCOMPLETE

31 32

L’attribut obligatoire NEXT_HOP exemple de tables Adj-RIB-in


Adresse IP du prochain routeur à utiliser : 193.250.5.0/24
en général l’adresse IP de l’annonceur.

AS 1276 reçoit
Entre deux AS, le trafic utile peut aussi ne pas transiter et sto
par les routeurs de bord ou ne pas utiliser les adresses 195.4.0.1 cke :
IP de leurs interfaces sur la liaison inter-AS
3 exemples de cas : NLRI ORIGIN NEXT_HOP AS_PATH
Réseau de transit inter-AS non annoncé au sein de l’AS 195.120.3.0/24 I 195.4.0.2 875
Routeur de transit ne supportant pas BGP
Raccourci (plusieurs routeurs sur un même Ethernet)
195.4.0.2
reçoit et sto
I-BGP conserve en Next-Hop l’adresse du routeur AS 875 cke :
extérieur qui a annoncé une route
d’où l’intérêt de forcer le Next-Hop à une adresse interne à 195.120.3.0/24
NLRI ORIGIN NEXT_HOP AS_PATH
l’AS si le lien DMZ n’est pas annoncé par l’IGP par exemple 193.250.5.0/24 I 195.4.0.1 1276

33 34

configuration sur Cisco tables Adj-RIB-in

193.250.5.0/24 193.8.0.0/22
193.250.5.0/24
195.5.0.1 195.5.0.2
AS 1276 AS 510
AS 1276 .2
.6.0
195.4.0.1 195.4.0.1 195
router bgp 1276
neighbor 195.4.0.2 remote-as 875
network 193.250.5.0 255.255.255.0
NLRI ORIGIN NEXT_HOP AS_PATH
195.4.0.2 193.120.3.0/24 I 195.4.0.2 875
.6 .0.1 193.8.0.0/22 I 195.5.0.2 510
AS 875 195
195.4.0.2 193.8.0.0/22 I 195.4.0.2 875, 510
193.120.3.0/24 I 195.5.0.2 510, 875
router bgp 875 AS 875
193.120.3.0/24
neighbor 195.4.0.1 remote-as 1276
network 193.120.3.0 255.255.255.0 NLRI ORIGIN NEXT_HOP AS_PATH
193.120.3.0/24 193.250.5.0/24 I 195.4.0.1 1276
193.8.0.0/22 I 195.4.0.1 1276, 510
193.8.0.0/22 I 195.6.0.2 510
193.250.5.0/24 I 195.6.0.2 510, 1276
35 36

6
configuration sur Cisco L’attribut LOCAL-PREF
193.250.5.0/24 193.8.0.0/22

195.5.0.1 195.5.0.2 « Bien-connu » facultatif


AS 1276 AS 510
.2
195.4.0.1 6.0
1 95. Transmet au sein d’un AS, donc en I-BGP, qu’on
préfère tel ou tel AS-PATH lorsqu’une même liste
de préfixes est annoncée par 2 AS voisins.
.6.0
.1 Exemple : préférer une liaison plus rapide, un contrat plus
195 router bgp 1276
intéressant, l’autre voie servant de secours.
195.4.0.2 neighbor 195.4.0.2 remote-as 875
AS 875 neighbor 195.5.0.2 remote-as 510
network 193.250.5.0 255.255.255.0
Jamais annoncé en E-BGP
router bgp 875
193.120.3.0/24 neighbor 195.4.0.1 remote-as 1276
neighbor 195.6.0.2 remote-as 510
network 193.120.3.0 255.255.255.0
37 38

L’attribut WEIGHT L’attribut Multi-Exit-Discriminator

Optionnel intransitif Optionnel intransitif


sorte de « métrique externe »
Même objectif que LOCAL-PREF mais pour (rôle inverse de LOCAL-PREF)
un choix local au routeur BGP : permet à l’AS voisin de discriminer mes
pondère la priorité des routes en interne points d’entrée selon préfixes annoncés ;
n’est pas réexporté par lui.
Jamais annoncé Exemple : optimisation géographique

39 40

MED (suite) Les 2 attributs d’agrégation

2 AS reliés par plus d’un lien ATOMIC_AGREGATE « bien-connu » facultatif


Interdit de désagréger.
Permet d’informer que tel lien est Le préfixe peut recouvrir des préfixes soumis à
d’autres politiques : autres AS-PATH ou attributs
préférable pour telle liste de préfixes
internes ou externes à l’AS annonceur
AGGREGATOR Optionnel transitif – précise :
l’AS où une agrégation a été effectuée
En général, un opérateur ne l’accepte que
l’adresse IP du routeur qui l’a effectuée
d’un client (sinon, possibilité de forçage du
transit longue distance via le concurrent, sans
contrepartie financière …)
41 42

7
Les « communautés » Portée respective des attributs
Attribut optionnel transitif
Ensemble de destinations ayant en
AS 3 AS 2
commun une propriété « logique » ORIGIN
AS_PATH++
(pas de limites physiques, d’AS, …) NEXT_HOP2
ORIGIN
AS_PATH+
no-export pas d’annonce hors confédération NEXT_HOP1
MULTI_EXT_DISC
(confédération = ensemble de « sous-AS »)
no-advertise pas d’annonce aux pairs
numéro d’AS + valeur : sémantique privée ORIGIN
AS_PATH
NEXT_HOP
ORIGIN
Une route peut avoir plusieurs attributs community. LOCAL_PREF
AS_PATH
MULTI_EXT_DISC
Un routeur peut ajouter ou modifier ces attributs. WEIGHT NEXT_HOP
AS 1 LOCAL_PREF

43 44

Choix d’une route Annonce BGP des routes internes à l’AS


But : installer la « meilleure » route dans RIB-Loc
Critères par priorité décroissante : À partir de déclarations statiques
Next-Hop accessible Pas d’instabilité ☺ mais trous noirs possibles
WEIGHT max. redistribute [static|connected]
LOCAL_PREF max. ORIGIN: Incomplete
Route générée par le routeur lui-même
AS_PATH le plus court [ajout possible de répétitions]
Semi-dynamiquement : préférable
ORIGIN IGP > EGP > Incomplete network <préfixe> ORIGIN: IGP
MULTI_EXT_DISC min
EBGP > Confederation external > IBGP
Dynamiquement
Next-Hop via le plus proche voisin IGP Suit au mieux l’état du réseau mais nécessite un
Route annoncée par le routeur BGP d’ID min. filtrage redistribute <IGP> <paramètres>
ID = adresse IP de loopback ou max adresses interfaces Filtrage automatique des routes OSPF « extern »

45 46

La politique de routage Filtrage de préfixes


AS100 ne veut pas servir d’AS de transit pour le réseau
194.10.3.0/24 de l’AS300 il ne le réannonce pas
Ses objectifs :
194.10.1.0/24 194.10.3.0/24
Sélection parmi les routes reçues
Sélection parmi les routes annonçables AS 100 AS 300
194.9.2.1 194.9.2.3
Positionnement d’attributs de routes 194.9.1.1

Ses moyens d’action : router bgp 100


filtrage de préfixes network 194.10.1.0 255.255.255.0
neighbor 194.9.1.2 remote-as 200
filtrage d’AS_PATH (sur expressions régulières) 194.9.1.2 neighbor 194.9.2.3 remote-as 300

manipulation d’attributs
AS 200 neighbor 194.9.1.2 distribute-list 1 out
access-list 1 deny 194.10.3.0 0.0.0.255
agrégation de préfixes 194.10.2.0/24
access-list 1 permit 0.0.0.0 255.255.255.255

47 48

8
Filtrage de chemins d’AS Filtrage par route map
Filtrage des AS_PATH annoncés : AS100 ne veut servir d’AS AS100 ne veut pas servir d’AS de transit à AS300
de transit pour aucun des réseaux internes d’AS300

194.10.1.0/24 194.10.3.0/24 194.10.1.0/24 194.10.3.0/24

AS 100 AS 300 AS 100 194.9.2.1 AS 300


194.9.2.1 194.9.2.3
194.9.2.3
194.9.1.1 194.9.1.1

router bgp 100


router bgp 100
network 194.10.1.0 255.255.255.0
network 194.10.1.0 255.255.255.0
neighbor 194.9.1.2 remote-as 200
neighbor 194.9.1.2 remote-as 200
neighbor 194.9.2.3 remote-as 300
neighbor 194.9.2.3 remote-as 300 194.9.1.2
194.9.1.2 neighbor 194.9.1.2 route-map X out
neighbor 194.9.1.2 filter-list 1 out
AS 200 ou
AS 200 ip as-path access-list 1 deny ^300$
neighbor 194.9.1.2 filter-list 1 out
ip as-path access-list 1 permit .*
ip as-path access-list 1 permit ^$
194.10.2.0/24 194.10.2.0/24

49 50

Manipulation Choix d’architecture


des longueurs de chemins, des métriques, …

neighbor 192.68.5.2 route-map SetLocal in Différentes techniques permettent


route-map SetMetric permit 10
match ip address 1 d’optimiser l’architecture BGP
route-map SetLocal permit 10
set local-preference 300 set metric 200

route-map SetMetric permit 20 dans le cas de grands AS


set metric 300
et/ou de grands points d’échange
neighbor 172.16.20.2.2 route-map access-list 1 permit 194.10.3.0 0.0.0.255
AddASnum out

route-map AddASnum permit 10


set as-path prepend x x

51 52

Optimisation interne AS : Optimisation interne AS :


le réflecteur de routes la « confédération »
« Full mesh » ex. 100 sessions I-BGP / routeur Partition d’un AS en sous-AS
Dans un cluster de clients (inclus dans un AS),
1 session entre chaque client et le réflecteur qui : Au sein d’un sous-AS « full mesh » I-BGP
sélectionne les chemins ; propage une :
route reçue d’un non-client vers clients
route d’un client vers non clients et clients (sauf lui) Entre sous-AS, E-BGP mais règles I-BGP :
route d’un pair EBGP vers non clients et clients
route IBGP sans changer les attributs
Next-Hop, MED, Local-Pref préservés
ex. next-hop réémis tel quel (sinon, risque de boucle)
Dépendance critique
Solution : plusieurs réflecteurs par cluster Architecture conseillée : tous les sous-AS
interagissent via un sous-AS épine dorsale
53 54

9
« Damping » des routes à éclipses
Optimisation externe :
le « serveur de routes »
succession d’UPDATE et de WITHDRAWN
Cas des grands points d’échange : propagés partout impacte les routeurs
Par exemple, 100 fournisseurs d’accès Solution : à chaque oscillation, pénalité de
et 50 000 routes annoncées croissance « exponentielle »
d’où jusqu'à 10 000 sessions TCP Durée de ½ vie (configurable) atteinte
(moins si la matrice des accords est creuse)
pénalité divisée par 2

Solution : le serveur de routes pénalité > couperet route supprimée


une session par fournisseur d’accès
pénalité < réhabilitation rétablissement
55 56

Pénalisation des routes vacillantes État des lieux et perspectives

Données actuelles et extrapolations …


Pénalité

couperet

réhabilitation

Temps

CONSEIL :
Pour éviter qu’un routeur (n’importe où !) ne vous pénalise, agrégez !
57 58

Problématique Explosion du nombre de routes

Évolution de la taille de la table de routage des


routeurs dépourvus de route défaut :
Consommation n°AS
Instabilités de 1988 à avril 1994 : croissance exponentielle
Temps de convergence ⇑ en 1994 et 1995 : déploiement de CIDR
Longueur moyenne des préfixes ⇑
Densité du graphe inter-AS ⇑ 1995-1998 : croissance linéaire 10 000/an
Granularité des politiques, finesse du La stabilité des routes ⇑ grâce à :
l’absorption dans les agrégats des instabilités
contrôle de l’ingénierie du trafic ⇑ périphériques de préfixes longs,
l’arrivée du mécanisme de pénalisation.
59 60

10
Efficacité du CIDR Consommation de numéros d’AS

1999-2000 : retour d’une croissance non + 51 % par an depuis 4 ans


linéaire : 42 % par an
2001 : paysage contrasté : 11 000 AS dans les chemins annoncés
⇑ là où il y avait moins de préfixes longs,
sauts ⇓ à l’introduction de grosses agrégations
Passage à 32 bits avant 2005 ?
On n’assainit pas vraiment le marécage initial.
CIDR modèle hiérarchique pas vraiment modification du protocole triviale
adapté à un marché concurrentiel avec des transition non triviale
recherches d’optimum individuel

61 62

Consommation d’adresses IP Granularité des annonces

10**9 adresses annoncées aujourd’hui Longueur moyenne du préfixe annoncé :


= 26 % de l’espace IPv4 unicast 18 fin 2000 ; 18,6 maintenant
Sur 108 000 entrées, 59 000 sont des /24
Croissance annuelle des annonces : (mi 2001)

routes + 42 %, adressage +7 % Filtrage des préfixes > taille N ???


Pourquoi cet écart ? Temps de convergence : 2 mn …
effet des NAT 55 % des routes forment des « trous »
tendance à raffiner les stratégies dans des agrégats, majoritairement avec des
chemins d’AS différents

63 64

Bibliographie Quelques sites web


www.rsng.net : Route server project
Le routage dans l’Internet, C. Huitema, www.caida.org : outils et données de métrologie réseau
Eyrolles, 1994 www.merit.edu/~ipma/tools/lookingglass.html : répertoire
Interconnections with bridges and routers, de « looking glass » permettant d’interroger des routeurs de
R, Perlman, Addison-Wesley, 1996 points d’échange sur les routes qu’ils ont en table
Internet Routing Architectures, B.Halabi, www.ep.net : Liste des points d’échange
Cisco Press, 1997 www.ra.net : Router arbitrer project
BGP4 Inter-Domain Routing in the Internet, www.cisco.com/univercd/cc/td/doc/cisintwk/ics/icsbgp4.h
J. W. Stewart III, Addison-Wesley, 1998 tm : Manuel de configuration BGP4 des routeurs Cisco.

65 66

11
RFC
RFC1771 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T. Li. March 1995(DS)
RFC1772 Application of the Border Gateway Protocol in the Internet. Y.
Rekhter, P. Gross. March 1995. (DS)
RFC1773 Experience with the BGP-4 protocol. P. Traina. March 1995.(INFO)
RFC1774 BGP-4 Protocol Analysis. P. Traina, Editor. March 1995. (INFO)
RFC1966 BGP Route Reflection An alternative to full mesh IBGP. T. Bates & R.
Chandrasekeran. June 1996. (EXP)
RFC1997 BGP Communities Attribute. R.Chandra, P.Traina & T.Li. August 1996(PS)
RFC1998 An Application of the BGP Community Attribute in Multi-home Routing.
E. Chen & T. Bates. August 1996. (INFO)
RFC2042 Registering New BGP Attribute Types. B. Manning. January 1997. (INFO)
RFC2283 Multiprotocol Extensions for BGP-4. T. Bates, R. Chandra, D. Katz, Y.
Rekhter. February 1998. (PS)
RFC2385 Protection of BGP Sessions via the TCP MD5 Signature Option. A.
Heffernan. August 1998. (PS)
RFC2439 BGP Route Flap Damping. C. Villamizar, R. Chandra, R. Govindan.
November 1998. (PS)
RFC2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing.
P. Marques, F. Dupont. March 1999. (PS)
RFC 2796 BGP Route Reflection - An Alternative to Full Mesh IBGP. T. Bates, R.
Chandra, E. Chen. April 2000. (PS)
RFC3065 Autonomous System Confederations for BGP. P. Traina, D. McPherson, J.
Scudder. February 2001. (PS)

67

12