Configuration de Direct Link on Classic

Lorsque votre connectivité IBM Cloud® Direct Link on Classic a été établie, vous pouvez suivre la procédure indiquée dans ce document pour configurer votre réseau afin qu'il interagisse avec IBM Cloud.

En général, pour que votre connexion Direct Link on Classic fonctionne, vous devez effectuer quelques étapes de configuration réseau de base, puis configurer le protocole BGP (Border Gateway Protocol). Lors du processus de configuration, un ingénieur IBM vous aide à activer votre réseau pour l'utilisation de la fonction Virtual Routing and Forwarding (VRF), qui est requise.

Configuration du réseau de base

Définissez votre réseau distant à l'aide de l'espace d'adresse privé RFC1918 standard.
- Pour les nouveaux environnements, espace 10.0.0.0/8.
- Pour les environnements existants qui utilisent 10.0.0.0/8, nous vous recommandons d'obtenir une évaluation plus détaillée pour garantir qu'il n'y a pas de conflit avec le réseau de services IBM Cloud ou les réseaux déjà affectés à votre compte.
Notre personnel chez IBM Cloud affecte /31 ou /30 pour chaque connexion et configure une adresse IP d'interface sur l'infrastructure du routeur d'interconnexion (XCR) IBM Cloud.
Configurez l'interface de votre routeur CER (Customer Edge Router) à l'aide de l'adresse IP fournie : utilisez l'adresse IP XCR IBM Cloud comme tronçon suivant pour tout trafic destiné à IBM Cloud.
Pour le trafic de retour, IBM Cloud utilise l'adresse IP CER affectée comme tronçon suivant pour tout trafic destiné au réseau distant, comme annoncé via BGP.

Configuration de BGP

Pour échanger des informations de route avec votre environnement, IBM Cloud nécessite la configuration de BGP. Les options disponibles sont les suivantes :

ASN : IBM Cloud affecte un numéro ASN privé pour chaque utilisateur. Sinon vous pouvez utiliser votre propre ASN public. Votre préférence vous est demandée au moment où vous passez la commande. Votre numéro ASN privé vous est fourni lors du processus d'implémentation.
VRF : Avec VRF, IBM Cloud annonce les sous-réseaux privés spécifiques affectés à votre compte client. Vous devez déclarer les réseaux distants que vous souhaitez accessibles depuis le réseau privé IBM Cloud. Il vous incombe en tant que client de gérer les annonces en provenance et à destination du réseau IBM Cloud. (Vous trouverez plus de détails sur VRF à la section suivante).

Les réseaux suivants sont exclus et ne peuvent pas être acceptés : 10.0.0.0/14, 10.198.0.0/15, 10.200.0.0/14, 169.254.0.0/16, 224.0.0.0/4.
ECMP : Pour les clients qui optent pour intégrer la redondance à un emplacement pris en charge, IBM Cloud prend en charge l'implémentation de la fonction ECMP (Equal-Cost MultiPath) pour fournir l'équilibrage de charge et la redondance sur les deux liaisons. Cette configuration ECMP doit être demandée au moment de la commande.

Spécifications de protocole BGP pour IBM Cloud Direct Link

Les spécifications de protocole BGP sont les suivantes :

Comme indiqué dans la section précédente, le protocole BGP est obligatoire pour gérer votre routage via Direct Link. Un compte qui commande Direct Link est migré vers l'environnement VRF.

Mises en garde relatives aux VLAN et VRF :

Le spanning VLAN entre les comptes n'est pas admis dans l'environnement VRF.
Le service VPN IPsec est limité.

VRF n'empêche pas l'accès VPN SSL, mais le comportement change. Sans VRF, une connexion VPN suffit pour voir tous les serveurs sur votre compte. Avec VRF, vous ne pouvez accéder qu'aux ressources présentes sur le marché associé à votre réseau privé virtuel (VPN). Par conséquent, si vous vous connectez au VPN DAL, vous ne pouvez vous connecter qu'aux serveurs DAL.

Le numéro de système autonome (ASN) d'IBM Cloud est 13884, pour les services publics et privés.

L'ASN par défaut d'un client lors d'une commande est 64999, mais elle peut être modifiée à la demande du client.
En option, un ASN privé de 4 octets " 4201000000- " 4294967294 peut être pris en charge.
ASN exclus : " 0, " 13884, " 36351, " 64512, " 64513, " 65100, " 65201-65234,65402-65433, " 65500 et ASN de 4 octets : " 4201065000-4201065999
Si vous utilisez Direct Link Connect avec un service à 3 couches, par exemple, IP VPN, IBM Cloud établit un protocole BGP avec l'ASN du fournisseur Direct Link Connect.

Recommandations, valeurs par défaut et limites :

La tunnellisation (c'est-à-dire GRE) est prise en charge et recommandée si le chevauchement d'adresses IP devient un problème.
Les valeurs par défaut du temporisateur BGP sont Keepalive:30, Holdtime:90
L'authentification n'est pas activée par défaut.
BGP BFD n'est pas activé par défaut.
La limite de réception maximale (de la part des clients ou des fournisseurs) est 200 par VRF.

Limitations strictes pour les affectations d'adresse IP

Si vous utilisez le réseau 10.x.x.x, vous ne pouvez toujours pas créer de chevauchement avec vos hôtes dans IBM Cloud ni avec le réseau des services IBM Cloud, qui occupe 10.0.0.0/14, 10.198.0.0/15 et 10.200.0.0/14.
Les plages suivantes ne sont pas admises dans le système fédéral, par conséquent, elles sont rejetées par les serveurs IBM : 169.254.0.0/16, 224.0.0.0/4.

Redondance et diversité

IBM Cloud Direct Link offre la diversité et les clients sont responsables d'implémenter la redondance à travers leurs schémas BGP.

Si vous sélectionnez ECMP pour la redondance, les deux sessions BGP doivent exister sur le même routeur XCR. C'est pourquoi vous renoncez à la diversité du routeur et êtes exposé à des risques en cas de défaillance du routeur. Vous gagnez la redondance de la couche 3 mais vous perdez la diversité du routeur.

Comprendre les décisions de transfert BGP

IBM Cloud Le routage et le transfert BGP varient selon la mise en œuvre du fournisseur sur le site. Ceci est essentiel pour comprendre comment vous configurez votre équipement sur place pour fonctionner avec Direct Link. Un manque de compréhension et de planification peut entraîner des comportements indésirables tels que des chemins d'acheminement asymétriques ou des choix d'acheminement incorrects. Le tableau suivant est classé du plus important au moins important. Ceci s'applique aux chemins simples. L'utilisation de plusieurs chemins d'accès modifie ce comportement. Pour toute dérogation à ces règles générales, suivez le guide de configuration de votre routeur.

Figure 1.BGP
Prise en compte du BGP	Signification	Valeur préférentielle
Prochain saut Reachable	BGP ne sélectionnera pas une route avec laquelle il ne peut pas communiquer.	N/A
Poids (Cisco uniquement)	Métrique spécifique à Cisco pour la préférence d'un chemin.	Valeur supérieure préférée
Local_Pref	Métrique indépendante du fournisseur pour la préférence d'un chemin.	Valeur supérieure préférée
Routes injectées localement	Si votre routeur est à l'origine des routes, préférez-le à iBGP/eBGP.	N/A
Longueur du chemin AS_Path	Nombre d'AS qu'une route doit traverser.	Valeur inférieure préférée
Origine	Quel protocole est à l'origine de la route.	BGP interne préféré à BGP externe
MOY	Multi Exit Discriminator, qui peut préférer un chemin de sortie entre les AS.	La valeur la plus basse est privilégiée
Type de voisin	Quelle est la relation protocolaire entre deux AS ?	Préférer le BGP interne au BGP externe
Métrique IGP	Quelle était la métrique IGP de la route ?	La valeur la plus basse est privilégiée
Âge de l'itinéraire	Quel est l'âge des routes ?	Préférer l'itinéraire le plus ancien

En savoir plus sur VRF

Tous les comptes qui utilisent une solution IBM Cloud Direct Link doivent migrer vers une instance VRF. Pour plus d'informations, voir Foire aux questions sur la migration de compte VRF.

En utilisant VRF, les clients annoncent les routes disponibles vers leurs réseaux distants auto-définis. Cette configuration ne vous autorise pas à utiliser des adresses IP auto-définies sur le réseau IBM Cloud.

La migration vers un VRF nécessite une courte fenêtre d'interruption (jusqu'à 30 minutes pour les grands comptes avec plusieurs VLANs/localisations), pendant laquelle les VLANs du réseau dorsal perdent leur connectivité mutuelle pendant qu'ils sont déplacés vers le VRF.

VRF élimine l'option "Spanning VLAN" de votre compte, y compris les fonctions éventuelles de spanning VLAN de compte à compte, car tous les réseaux VLAN sont en mesure de communiquer sauf si un dispositif de passerelle est mis en place pour gérer le trafic. VRF limite également la possibilité d'utiliser les services VPN IBM Cloud, car ce n'est pas compatible avec les services VPN SSL et IPsec de IBM Cloud.

En guise d'alternative, vous pouvez utiliser l'offre IBM Cloud Direct Link même pour gérer vos serveurs ou pour exécuter votre propre solution VPN (par exemple Vyatta) pouvant être configurée avec différents types de VPN. Après avoir effectué la migration sur VRF, le réseau VPN SSL fonctionne en principe lorsqu'une connexion VPN est réalisée avec le même emplacement de centre de données dans lequel s'exécute une machine virtuelle (VM) de calcul, mais il n'autorise pas l'accès mondial.

Utilisation de BYOIP et NAT avec Direct Link

IBM Cloud Direct Link n'offre pas BYOIP sur le réseau privé. Par conséquent, le trafic avec une adresse IP de destination qui n'a pas été affectée par IBM Cloud n'est pas traité. Les clients peuvent toutefois encapsuler le trafic entre le réseau distant et leur réseau IBM Cloud qui utilise GRE, IPsec ou VLAN.

En règle générale, l'environnement BYOIP est implémenté dans le cadre d'une passerelle de réseau (Vyatta) ou d'un déploiement VMWare NSX. Cette configuration permet aux clients d'utiliser tout espace IP souhaitable côté IBM Cloud et d'effectuer un routage inverse via le tunnel vers le réseau distant. Cette configuration doit être gérée et prise en charge par le client, indépendamment de IBM Cloud. De plus, cette configuration peut interrompre la connectivité au réseau de services IBM Cloud si le client affecte un bloc 10.x.x.x utilisé par IBM Cloud pour les services.

Avec cette solution, il faut également que chaque hôte nécessitant une connectivité au réseau de services IBM Cloud et au réseau distant ait deux adresses IP affectées : une devant être affectée à partir du bloc IBM 10.x.x.x et l'autre à partir du bloc du réseau distant. Les routes statiques doivent être configurées sur l'hôte pour garantir que le trafic soit routé. Vous ne pouvez pas affecter d'espace IP directement sur les hôtes IBM Cloud (BYOIP) et le rendre acheminable sur le réseau IBM Cloud intrinsèquement. La seule manière d'implémenter cette possibilité est soulignée précédemment, mais elle n'est pas prise en charge par IBM Cloud.

Sinon, les clients affectent souvent un bloc de réseau distant à utiliser dans une table NAT configurée sur leur routeur périphérique distant. Cette configuration permet aux clients de limiter les modifications requises sur les deux réseaux, tout en continuant à acheminer le trafic dans un espace d'adresse réseau compatible avec les deux réseaux.