Home Blog La configuration BGP a l’aide du GRE Tunnel

La configuration BGP a l’aide du GRE Tunnel

    Rate this post

    GRE Generic Routing EncapsulationDans cet article, nous allons expliquer comment le tunnel Generic Routing Encapsulation (GRE) peut être utilisé dans la situation où les routeurs parlant BGP (Border Gateway Protocol) sont connectés via des routeurs ne parlant pas BGP.

    Jetons un coup d’œil au scénario suivant:

    La société A exploite les routeurs Cisco CE1, Core1 et CE2 et utilise deux fournisseurs d’accès à Internet (FAI) – ISP1 et ISP2. Le numéro de système autonome (ASN) attribué à l’entreprise est 64500, le protocole BGP étant activé sur les routeurs CE1 et CE2. Le routeur CE1 est connecté au routeur PE_ISP1 (ASN 64501) et le routeur CE2 est connecté au routeur PE_ISP2 (ASN 64502). En plus du protocole de routage BGP, le protocole Open Shortest Path First (OSPF) est également activé sur tous les routeurs de l’entreprise.

    gre tunnels

    Image 1 – Topologie du réseau

    Maintenant, vérifions la configuration des deux routeurs FAI.

    1. La configuration des routeurs FAI

    Les deux routeurs ISP comprennent la configuration BGP de base qui est nécessaire afin d’établir une session eBGP avec CE1 et CE2 dans l’AS 64500. Les FAI et les routeurs des clients se connectent à l’aide de leurs adresses IP Loopback. Par conséquent, la commande update-source Loopback0 est utilisée dans la configuration BGP. En plus de cela, afin de lancer la session eBGP, on doit configurer une route statique sur les routeurs des fournisseurs et des clients vers leurs voisins eBGP.

    La commande disable-connected-check est requise à la fois sur les FAI ainsi que sur les routeurs clients. Cette commande désactive le processus de vérification de connexion pour les sessions eBGP qui sont accessibles par un seul saut mais qui sont configurées sur un interface Loopback.

    La commande redistribute connected – redistribue toutes les routes connectées via le protocole BGP.

    1.1. La configuration du routeur PE-ISP1

    router bgp 64501
    bgp router-id 1.1.1.4
    bgp log-neighbor-changes
    redistribute connected
    neighbor 1.1.1.1 remote-as 64500
    neighbor 1.1.1.1 disable-connected-check
    neighbor 1.1.1.1 update-source Loopback0ip route 1.1.1.1 255.255.255.255 2.2.2.1interface Loopback0
    ip address 1.1.1.4 255.255.255.255interface GigabitEthernet0/0
    description Link to CORE AS64500
    ip address 2.2.2.2 255.255.255.252

    interface GigabitEthernet0/1
    ip address 8.8.8.1 255.255.255.0

    1.2. La configuration du routeur PE-ISP2

    router bgp 64502
    bgp router-id 1.1.1.5
    bgp log-neighbor-changes
    redistribute connected
    neighbor 1.1.1.2 remote-as 64500
    neighbor 1.1.1.2 disable-connected-check
    neighbor 1.1.1.2 update-source Loopback0ip route 1.1.1.2 255.255.255.255 2.2.2.13interface Loopback0
    ip address 1.1.1.5 255.255.255.255interface GigabitEthernet0/0
    description Link to CE2 AS64500
    ip address 2.2.2.14 255.255.255.252

    interface GigabitEthernet0/1
    ip address 9.9.9.1 255.255.255.0

    2. La configuration des routeurs clients

    Les routeurs CE1 et CE2 du client sont des voisins BGP avec les routeurs des fournisseurs. De plus, les routeurs CE1 et CE2 sont configurés afin d’établir un voisinage iBGP entre eux. Afin de changer l’attribut du prochain saut de 1.1.1.4 à 1.1.1.1 pour l’annonce BGP envoyée de CE1 à CE2, on doit ajouter command neighbor 1.1.1.2 next-hop-self à la configuration BGP du routeur CE1. Sinon, le routeur CE2 n’ajoutera pas les routes avec le prochain saut 1.1.1.4 à sa table de routage car il n’a pas de route vers le réseau 1.1.1.4/32 dans sa table de routage. Une commande similaire doit être ajoutée dans la configuration BGP du CE2 pour configurer le routeur CE2 en tant que prochain saut (1.1.1.2) pour l’annonce reçue de l’ISP2 et envoyée vers CE1.

    Comme mentionné auparavant, le protocole OSPF est activé sur les routeurs CE1, Core et CE2. Pour empêcher l’envoi de messages OSPF Hello vers les routeurs ISP, on doit ajouter la commande passive-interface GigabitEthernet0/0 dans la configuration du protocole OSPF.

    2.1. La configuration du routeur CE1

    router bgp 64500
    bgp router-id 1.1.1.1
    bgp log-neighbor-changes
    redistribute connected
    neighbor 1.1.1.2 remote-as 64500
    neighbor 1.1.1.2 update-source Loopback0
    neighbor 1.1.1.2 next-hop-self
    neighbor 1.1.1.4 remote-as 64501
    neighbor 1.1.1.4 disable-connected-check
    neighbor 1.1.1.4 update-source Loopback0ip route 1.1.1.4 255.255.255.255 2.2.2.2interface Loopback0
    ip address 1.1.1.1 255.255.255.255interface GigabitEthernet0/0
    description Link to PE-ISP1 AS64501
    ip address 2.2.2.1 255.255.255.252

    interface GigabitEthernet1/0
    description Link to CORE
    ip address 2.2.2.6 255.255.255.252

    router ospf 1
    router-id 1.1.1.1
    passive-interface GigabitEthernet0/0
    network 1.1.1.1 0.0.0.0 area 0
    network 2.2.2.0 0.0.0.3 area 0
    network 2.2.2.4 0.0.0.3 area 0

    2.2. La configuration du routeur CE2

    router bgp 64500
    bgp router-id 1.1.1.2
    bgp log-neighbor-changes
    redistribute connected
    neighbor 1.1.1.1 remote-as 64500
    neighbor 1.1.1.1 update-source Loopback0
    neighbor 1.1.1.1 next-hop-self
    neighbor 1.1.1.5 remote-as 64502
    neighbor 1.1.1.5 disable-connected-check
    neighbor 1.1.1.5 update-source Loopback0ip route 1.1.1.5 255.255.255.255 2.2.2.14interface Loopback0
    ip address 1.1.1.2 255.255.255.255interface GigabitEthernet0/0
    description Link to PE-ISP2 AS64502
    ip address 2.2.2.13 255.255.255.252

    interface GigabitEthernet2/0
    description Link to CORE
    ip address 2.2.2.10 255.255.255.252

    router ospf 1
    router-id 1.1.1.2
    passive-interface GigabitEthernet0/0
    network 1.1.1.2 0.0.0.0 area 0
    network 2.2.2.8 0.0.0.3 area 0
    network 2.2.2.12 0.0.0.3 area 0

    2.3. Configuration du routeur principal (Core)

    interface Loopback0
    ip address 1.1.1.3 255.255.255.255interface GigabitEthernet0/1
    description Link to CE1
    ip address 2.2.2.5 255.255.255.252interface GigabitEthernet0/2
    description Link to CE2
    ip address 2.2.2.9 255.255.255.252router ospf 1
    router-id 1.1.1.3
    network 1.1.1.3 0.0.0.0 area 0
    network 2.2.2.4 0.0.0.3 area 0
    network 2.2.2.8 0.0.0.3 area 0
    3. La configuration du tunnel GRE

    Maintenant, nous allons analyser où se situe la configuration du tunnel GRE dans notre scénario. Vérifions d’abord une table de routage sur le routeur PE-ISP2.

    PE-ISP2# show ip route | begin Gateway
    Gateway of last resort is not set1.0.0.0/32 is subnetted, 4 subnets
    B1.1.1.1 [20/0] via 1.1.1.2, 00:02:56
    S1.1.1.2 [1/0] via 2.2.2.13
    B1.1.1.4 [20/0] via 1.1.1.2, 00:02:56
    C1.1.1.5 is directly connected, Loopback0
    2.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
    B2.2.2.0/30 [20/0] via 1.1.1.2, 00:02:56
    B2.2.2.4/30 [20/0] via 1.1.1.2, 00:02:56
    B2.2.2.8/30 [20/0] via 1.1.1.2, 00:02:56
    C2.2.2.12/30 is directly connected, GigabitEthernet0/0
    L2.2.2.14/32 is directly connected, GigabitEthernet0/0
    8.0.0.0/24 is subnetted, 1 subnets
    B8.8.8.0 [20/0] via 1.1.1.2, 00:02:56
    9.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
    C9.9.9.0/24 is directly connected, GigabitEthernet0/1
    L9.9.9.1/32 is directly connected, GigabitEthernet0/1

    Comme on peut le voir, le routeur PE-ISP2 a réussi à mettre tous les réseaux présents dans sa table de routage. Lorsqu’on active le débogage des paquets ICMP avec la commande debug ip icmp sur le routeur Core, on verra le message suivant.

    *Apr 25 15:25:30.501: ICMP: dst (8.8.8.1) host unreachable sent to 2.2.2.14

    Le message d’erreur révèle que le routeur Core ne sait pas où envoyer un paquet destiné à l’adresse IP 8.8.8.1. Ce problème a plusieurs solutions. Par exemple, on peut redistribuer les routes BGP dans le protocole OSPF sur les routeurs CE1 et CE2. Une autre solution est de configurer BGP sur le routeur Core et de l’appairer avec les routeurs CE1 et CE2. Lorsqu’on veut examiner l’utilisation du tunnel GRE dans notre scénario, on se concentre sur la deuxième option.

    Note: Il n’y a pas besoin d’écrire la commande tunnel mode gre ip dans la configuration du tunnel car il s’agit d’un mode par défaut pour l’interface tunnel.

     

    Le routeur CE1

    interface Tunnel0
    ip address 192.168.1.1 255.255.255.252
    tunnel source Loopback0
    tunnel destination 1.1.1.6
    tunnel mode gre ip

    Le routeur CE2

    interface Tunnel0
    ip address 192.168.1.2 255.255.255.252
    tunnel source Loopback0
    tunnel destination 1.1.1.1
    tunnel mode gre ip

    À ce stade, l’interface du tunnel est activée et nous devrions être en mesure d’effectuer un ping entre les adresses IP du tunnel. L’étape suivante est la reconfiguration de CE1 et CE2. Les routeurs seront configurés de définir une adresse IP particulière de tunnel en tant qu’attribut de saut suivant pour le NLRI (Network Layer Reachability Information) reçu dans les messages de mise à jour BGP. On va créer une route-map sur le routeur CE1 qui change l’adresse IP du prochain saut 1.1.1.1 en 192.168.1.1 pour les mises à jour envoyées vers le routeur CE2. Ensuite, on appliquera la route-map pour le voisin iBGP 1.1.1.2

    Le routeur CE1

    route-map nexthop_tun_out permit 10
    set ip next-hop 192.168.1.1router bgp 64500
    neighbor 1.1.1.2 route-map nexthop_tun_out out

    Un bref coup d’œil sur la table BGP pour la route 8.8.8.0 sur le routeur CE2 nous montre que l’interface de tunnel IP 192.168.1.1 est maintenant utilisée comme prochain saut pour la route 8.8.8.0/24.

    CE2# show ip bgp | include 8.8.8.0
    *>i 8.8.8.0/24 192.168.1.1 0 100 0 64501 ?

    Dans le sens inverse sur le routeur CE2, le processus est le même.

    Le routeur CE2

    route-map nexthop_tun_out permit 10
    set ip next-hop 192.168.1.2router bgp 64500
    neighbor 1.1.1.1 route-map nexthop_tun_out out

    Allons vérifier le saut suivant pour la route 9.9.9.0/24 sur le routeur CE1.

    CE1# show ip bgp | include 9.9.9.0
    *>i 9.9.9.0/24 192.168.1.2 0 100 0 64502 ?

    Maintenant, on pourra envoyer un ping de ISP2 à ISP1 et vice versa.

    PE-ISP2# ping 8.8.8.1
    Type escape sequence to abort.
    Send!!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms

    Et la sortie de la commande traceroute est la suivante:

    PE-ISP2# traceroute 8.8.8.1
    Type escape sequence to abort.
    Tracing the route to 8.8.8.1
    VRF info: (vrf in name/id, vrf out name/id)
    1 2.2.2.13 1 msec 1 msec 1 msec
    2 192.168.1.1 [AS 64500] 3 msec 2 msec 2 msec
    3 2.2.2.2 [AS 64500] 3 msec 3 msec *
    4. Les problèmes du tunnel GRE et du MTU

    La longueur maximale d’un paquet IP est de 65 535 octets. Il comprend 20 octets d’en-tête IP plus 65515 octets de charge utile. Cependant, la plus petite taille de paquet IP est normalement utilisée sur les liens en fonction du type de protocole layer 2. Cette longueur est définie par la valeur Maximum Transmission Unit (MTU). Ainsi, la valeur MTU indique la quantité de données que l’hôte d’envoi peut mettre dans un paquet.

    La valeur MTU pour un lien Ethernet est de 1500 octets, sans compter l’en-tête Ethernet et du postambule. Il comprend 20 octets pour l’en-tête TCP, 20 octets pour l’en-tête IP et 1460 octets pour la charge utile. Lorsque l’interface de tunnel est créée, la valeur MTU de l’interface de tunnel est automatiquement configuré avec un MTU de 1476 octets parce qu’on doit prendre en compte les 24 octets du tunnel GRE.

    Si le paquet avec une valeur MTU supérieure à 1476 octets est reçu, le routeur doit fragmenter ce paquet en petits morceaux. Ces fragments ont une valeur MTU de 1476 octets, avec laquelle ils sont envoyés dans le tunnel GRE. L’inconvénient de la fragmentation est évident : un routeur doit générer de nouveaux en-têtes et il utilise ses ressources (CPU et mémoire) ainsi que des exigences supplémentaires en matière de bande passante. De l’autre côté du tunnel GRE, le routeur réassemble les morceaux dans un paquet original de taille normale.

    La valeur MTU configurée sur la route du point A au point B peut être rapidement testée avec la commande ping associée à l’option « ne pas fragmenter » et en choisissant une certaine valeur MTU.

    PE-ISP1# ping 9.9.9.1 df-bit size 1477

    *Apr 25 21:38:39.926: ICMP: dst (2.2.2.2) frag. needed and DF set unreachable rcv from 2.2.2.1 mtu:1476.M

    Le message ICMP reçu sur le routeur PE-ISP1 indique qu’un routeur avec l’adresse IP 2.2.2.1 (CE1) a la valeur MTU réglée sur 1476 octets sur l’un de ses liens. Cependant, on interdit strictement la fragmentation, de sorte que la commande ping échoue.

    De cette façon, il apparaît une question : Pourquoi un routeur prend-il la peine de renvoyer un message ICMP à l’hôte d’envoi?

    Si l’indicateur DF (Don’t fragment) est réglé sur 1, le routeur n’est pas autorisé à fragmenter un paquet. Si le paquet contient plus que 1476 octets, le message ICMP de type 3 Destination unreachable et le code 4 Fragmentation needed sont envoyés à l’hôte expéditeur, contenant les informations sur la valeur MTU du prochain saut :1476 octets. L’hôte expéditeur prend en compte ces informations et règle la valeur MTU sur 1476 octets. Ce mécanisme, appelé Path MTU Discovery (PMTUD), est décrit dans le RFC 1191. PMTUD est supporté par les protocoles TCP et UDP et il est généralement activé sur les hôtes avec le bit DF réglé sur 1. Et c’est grâce au PMTUD que l’hôte expéditeur peut définir la valeur MTU correcte (c’est-à-dire la plus faible sur un lien) et que les paquets ne sont pas fragmentés.

    Le problème survient lorsque les messages ICMP sont bloqués quelque part sur la route par un ACL. Le routeur avec une valeur MTU configurée comme inférieure à celle du paquet IP envoyé renvoie le message ICMP Destination Unreachable, Fragmentation needed à l’hôte expéditeur.
    Cependant, l’hôte expéditeur ne peut pas le recevoir et ainsi prendre en compte la valeur MTU correcte. Il continue à utiliser le DF réglé sur 1 dans les en-têtes IP des paquets envoyés. En conséquence, le routeur avec la valeur MTU inférieure configurée sur le lien représente un goulot d’étranglement MTU sur la route. Et lorsqu’il n’est pas autorisé de fragmenter les paquets, la connexion échoue.

    5. Le routage récursif

    Le routage récursif est très certainement un problème indésirable pour un réseau. Il se produit lorsqu’un routeur essaie d’acheminer du trafic vers l’adresse de destination du tunnel à l’aide de l’interface du tunnel lui-même. Une fois que le routeur aperçoit un routage récursif, il désactive volontairement l’interface du tunnel pendant un certain laps de temps. Ensuite, l’interface du tunnel est rétabli par le routeur et le processus se répète. En conséquence, les routes OSPF et BGP de l’interface du tunnel oscillent.

    Afin de simuler un routage récursif, nous allons activer le protocole OSPF sur les interfaces tunnel des routeurs CE1 et CE2.

    router ospf 1
    network 192.168.1.0 0.0.0.3 area 0

    Ensuite, on vérifie les voisins OSPF.

    CE1# show ip ospf neighbor

    Neighbor ID     Pri   State           Dead Time   Address         Interface
    1.1.1.2           0   FULL/  –        00:00:34    192.168.1.2     Tunnel0
    1.1.1.3           1   FULL/DR         00:00:38    2.2.2.5         GigabitEthernet1/0

     

    CE2# show ip ospf neighbor

    Neighbor ID     Pri   State           Dead Time   Address         Interface
    1.1.1.1           0   FULL/  –        00:00:36    192.168.1.1     Tunnel0
    1.1.1.3           1   FULL/DR         00:00:32    2.2.2.9         GigabitEthernet2/0

    Il y a deux voisins OSPF présentés dans la sortie de la commande. La première adjacence OSPF est formée sur l’interface tunnel, tandis que la seconde l’est sur l’interface Gigabit Ethernet. Jusqu’ici, la table de routage du routeur CE1 ne contient aucune route récursive. Toutes les routes OSPF sont apprises via l’interface GigabitEthernet1/0.

    CE1# show ip route | begin Gateway
    Gateway of last resort is not set1.0.0.0/32 is subnetted, 5 subnets
    C1.1.1.1 is directly connected, Loopback0
    O1.1.1.2 [110/3] via 2.2.2.5, 02:38:43, GigabitEthernet1/0
    O1.1.1.3 [110/2] via 2.2.2.5, 04:21:21, GigabitEthernet1/0
    S1.1.1.4 [1/0] via 2.2.2.2
    B1.1.1.5 [200/0] via 192.168.1.2, 02:37:44
    2.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
    C2.2.2.0/30 is directly connected, GigabitEthernet0/0
    L2.2.2.1/32 is directly connected, GigabitEthernet0/0
    C2.2.2.4/30 is directly connected, GigabitEthernet1/0
    L2.2.2.6/32 is directly connected, GigabitEthernet1/0
    O2.2.2.8/30 [110/2] via 2.2.2.5, 04:21:21, GigabitEthernet1/0
    O2.2.2.12/30 [110/3] via 2.2.2.5, 02:38:43, GigabitEthernet1/0
    8.0.0.0/24 is subnetted, 1 subnets
    B8.8.8.0 [20/0] via 1.1.1.4, 04:21:36
    9.0.0.0/24 is subnetted, 1 subnets
    B9.9.9.0 [200/0] via 192.168.1.2, 02:37:44
    192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
    C192.168.1.0/30 is directly connected, Tunnel0
    L192.168.1.1/32 is directly connected, Tunnel0

    Maintenant, nous allons vérifier le coût OSPF pour le tunnel et les interfaces Ethernet Gigabit sur le routeur CE1.

    CE1# show ip ospf interface tunnel 0 | incl Cost
    Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 1000
    Topology-MTID Cost Disabled Shutdown Topology Name

     

    CE1# show ip ospf interface gi1/0 | incl Cost
    Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1
    Topology-MTID Cost Disabled Shutdown Topology Name

    Ainsi, le protocole OSPF préfère l’interface Gigabit Ethernet à l’interface tunnel puisque son coût est de 1 par rapport au coût de 1000 qui est appliqué pour l’interface tunnel. Pour simuler un routage récursif, on va modifier le coût de l’interface tunnel à 1 sur les deux routeurs CE.

    interface tunnel 0
    ip ospf cost 1

    Après un certain temps, on peut voir les logs suivants.

    *May  1 18:44:51.911: %ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of Tunnel0 – looped chain attempting to stack

    *May  1 18:44:59.095: %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing

    *May  1 18:44:59.095: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down

    A partir de là, l’interface tunnel et les tables de routage des routeurs CE1 et CE2 oscillent indéfiniment. Certaines routes de la table de routage de CE1 sont désormais disponibles via l’interface du tunnel.

    CE1# show ip route | begin Gateway
    Gateway of last resort is not set1.0.0.0/32 is subnetted, 5 subnets
    C1.1.1.1 is directly connected, Loopback0
    O1.1.1.2 [110/2] via 192.168.1.2, 00:00:08, Tunnel0
    O1.1.1.3 [110/2] via 2.2.2.5, 04:32:36, GigabitEthernet1/0
    S1.1.1.4 [1/0] via 2.2.2.2
    B1.1.1.5 [200/0] via 192.168.1.2, 02:48:59
    2.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
    C2.2.2.0/30 is directly connected, GigabitEthernet0/0
    L2.2.2.1/32 is directly connected, GigabitEthernet0/0
    C2.2.2.4/30 is directly connected, GigabitEthernet1/0
    L2.2.2.6/32 is directly connected, GigabitEthernet1/0
    O2.2.2.8/30 [110/2] via 192.168.1.2, 00:00:08, Tunnel0
    [110/2] via 2.2.2.5, 04:32:36, GigabitEthernet1/0
    O2.2.2.12/30 [110/2] via 192.168.1.2, 00:00:08, Tunnel0
    8.0.0.0/24 is subnetted, 1 subnets
    B8.8.8.0 [20/0] via 1.1.1.4, 04:32:51
    9.0.0.0/24 is subnetted, 1 subnets
    B9.9.9.0 [200/0] via 192.168.1.2, 02:48:59
    192.168.1.0/30 is subnetted, 1 subnets
    B192.168.1.0 [200/0] via 192.168.1.2, 00:00:03

    Alors, que s’est-il passé exactement ? Nous allons l’expliquer dans l’exemple suivant.

    Auparavant, nous avons activé le protocole OSPF sur l’interface de tunnel 192.168.1.1 du routeur CE1. Supposons que le CE1 envoie un message OSPF hello avec une adresse IP source 192.168.1.1 à l’adresse IP multicast OSPF 224.0.0.5. L’interface du tunnel ajoute l’en-tête GRE au paquet et l’en-tête IP extérieur avec l’adresse IP source 1.1.1.1 et l’adresse IP de destination 1.1.1.2. Ensuite, la route 1.1.1.2/32 est recherchée dans la table de routage de CE1. Cependant, la route a été apprise via l’interface tunnel. Pour cette raison, l’en-tête GRE et l’en-tête IP extérieur seraient à nouveau ajoutés au paquet GRE précédemment encapsulé. Et si le routeur CE1 n’avait pas désactivé l’interface tunnel au préalable, le processus se répéterait encore et encore.

    Afin d’éviter le routage récursif, on peut augmenter le coût ospf pour l’interface tunnel à 1000 en utilisant la commande no ip ospf cost 1 sur les routeurs CE1 et CE2. Cela empêcherait les routeurs d’utiliser les routes apprises via l’interface tunnel.


    Chez Noction, nous pouvons implémenter la configuration BGP à l’aide du tunnel GRE lors du déploiement de notre plate-forme de routage intelligent (IRP) dans les réseaux de certains clients. Dans des scénarios complexes spécifiques, le trafic du serveur IRP doit passer par plusieurs routeurs afin d’arriver au fournisseur. Et s’il n’est pas possible de configurer un Vlan de sondage séparé sur tous les routeurs, la solution optimale sera alors de configurer les tunnels GRE d’IRP vers les routeurs Edge.

    Accéder à la version anglaise de cet article – BGP over GRE Tunnel


    Boost BGP Preformance

    Automate BGP Routing optimization with Noction IRP

    bgp demo

    NO COMMENTS

    Leave a Reply