6. Exemple de nouvelles attributions d'adresses et de routage
- Exemple de nouvelles attributions d'adresses et de routage
6.1. Délégation d'adresses
Considérons le bloc de 524288 (2^19) adresses, commençant à 10.24.0.0 et se terminant à 10.31.255.255, alloué à un seul fournisseur de réseau, « PA ». Cela équivaut en taille à un bloc de 2048 numéros de réseau « classe C » hérités (ou /24). Une route classless vers ce bloc serait décrite comme 10.24.0.0 avec un masque de 255.248.0.0 et le préfixe 10.24.0.0/13.
Supposons que ce fournisseur de services connecte six sites dans l'ordre suivant (significatif car il démontre comment des « trous » temporaires peuvent se former dans l'espace d'adressage du fournisseur de services) :
o « C1 », nécessitant moins de 2048 adresses (/21 ou 8 x /24)
o « C2 », nécessitant moins de 4096 adresses (/20 ou 16 x /24)
o « C3 », nécessitant moins de 1024 adresses (/22 ou 4 x /24)
o « C4 », nécessitant moins de 1024 adresses (/22 ou 4 x /24)
o « C5 », nécessitant moins de 512 adresses (/23 ou 2 x /24)
o « C6 », nécessitant moins de 512 adresses (/23 ou 2 x /24)
Dans tous les cas, le nombre d'adresses IPv4 « requises » par chaque site est supposé permettre une croissance significative. Le fournisseur de services délègue son espace d'adressage comme suit :
o C1. attribuer 10.24.0 à 10.24.7. Ce bloc de réseaux est décrit par la route 10.24.0.0/21 (masque 255.255.248.0).
o C2. Attribuer 10.24.16 à 10.24.31. Ce bloc est décrit par la route 10.24.16.0/20 (masque 255.255.240.0).
o C3. Attribuer 10.24.8 à 10.24.11. Ce bloc est décrit par la route 10.24.8.0/22 (masque 255.255.252.0).
o C4. Attribuer 10.24.12 à 10.24.15. Ce bloc est décrit par la route 10.24.12.0/22 (masque 255.255.252.0).
o C5. Attribuer 10.24.32 et 10.24.33. Ce bloc est décrit par la route 10.24.32.0/23 (masque 255.255.254.0).
o C6. Attribuer 10.24.34 et 10.24.35. Ce bloc est décrit par la route 10.24.34.0/23 (masque 255.255.254.0).
Ces six sites doivent être représentés comme six préfixes de tailles variables au sein de l'IGP du fournisseur. Si, pour une raison quelconque, le fournisseur utilise un IGP obsolète qui ne prend pas en charge le routage classless ou les sous-réseaux à longueur variable, alors des routes explicites pour tous les /24 devront être transportées.
Pour rendre cet exemple plus réaliste, supposons que C4 et C5 sont multi-hébergés via un autre fournisseur de services, « PB ». Supposons en outre l'existence d'un site, « C7 », qui était à l'origine connecté à « RB » mais qui a déménagé vers « PA ». Pour cette raison, il possède un bloc de numéros de réseau qui sont attribués à partir du bloc de (prochain) 2048 x /24 de PB.
o C7. Attribuer 10.32.0 à 10.32.15. Ce bloc est décrit par la route 10.32.0.0/20 (masque 255.255.240.0).
Pour les sites multi-hébergés, supposons que C4 est annoncé comme primaire via « RA » et secondaire via « RB » ; et que C5 est primaire via « RB » et secondaire via « RA ». De plus, supposons que « RA » et « RB » sont tous deux connectés au même fournisseur de services de transit, « BB ».
Graphiquement, cette topologie ressemble à ceci :
10.24.0.0 -- 10.24.7.0__ __10.32.0.0 - 10.32.15.0
C1: 10.24.0.0/21 \ / C7: 10.32.0.0/20
\ /
+----+ +----+
10.24.16.0 - 10.24.31.0_ | | | |
C2: 10.24.16.0/20 \ | | 10.24.12.0 - 10.24.15.0_ | |
\| | / C4: 10.24.12.0/20 \ | |
| |/ \| |
10.24.8.0 - 10.24.11.0___/| PA |\ | PB |
C3: 10.24.8.0/22 | | _10.24.32.0 - 10.24.33.0__| |
| | C5: 10.24.32.0/23 | |
| | | |
10.24.34.0 - 10.24.35.0__/| | | |
C6: 10.24.34.0/23 | | | |
+----+ +----+
|| ||
routing advertisements: || ||
|| ||
10.24.12.0/22 (C4) || 10.24.12.0/22 (C4) ||
10.32.0.0/20 (C7) || 10.24.32.0/23 (C5) ||
10.24.0.0/13 (PA) || 10.32.0.0/13 (PB) ||
|| ||
VV VV
+---------- BACKBONE NETWORK BB ----------+
6.2. Annonces de routage
Pour suivre la règle n° 1, PA devra annoncer le bloc d'adresses qui lui a été donné et C7. Puisque C4 est multi-hébergé et primaire via PA, il doit également être annoncé. C5 est multi-hébergé et primaire via PB. En principe (et dans l'exemple ci-dessus), il n'a pas besoin d'être annoncé, puisque la correspondance la plus longue par PB sélectionnera automatiquement PB comme primaire et l'annonce de l'agrégat de PA sera utilisée comme secondaire. En pratique réelle, C5 sera normalement annoncé via les deux fournisseurs.
Les annonces de « PA » vers « BB » seront
10.24.12.0/22 primary (advertises C4)
10.32.0.0/20 primary (advertises C7)
10.24.0.0/13 primary (advertises remainder of PA)
Pour PB, les annonces doivent également inclure C4 et C5, ainsi que son bloc d'adresses.
Les annonces de « PB » vers « BB » seront
10.24.12.0/22 secondary (advertises C4)
10.24.32.0/23 primary (advertises C5)
10.32.0.0/13 primary (advertises remainder of RB)
Pour illustrer la question de diagnostic de problème mentionnée à la section 5.1, considérons ce qui se passe si PA perd sa connectivité vers C7 (le site qui est attribué à partir de l'espace de PB). Dans un protocole avec état, PA annoncera à BB que 10.32.0.0/20 est devenu inaccessible. Maintenant, lorsque BB purge cette information de sa table de routage, tout trafic futur envoyé à travers lui vers cette destination sera transféré vers PB (où il sera abandonné selon la règle n° 2) en vertu de la correspondance moins spécifique de PB, 10.32.0.0/13. Bien que cela ne cause pas de problème opérationnel (C7 est inaccessible dans tous les cas), cela crée tout de même un trafic supplémentaire à travers « BB » (et peut également prêter à confusion quelqu'un essayant de déboguer la panne avec « traceroute »). Un mécanisme pour mettre en cache un tel état inaccessible pourrait être appréciable, mais il dépasse le cadre du présent document.