Tunnel GRE interop ALU

J'ai essayé de comprendre comment configurer un tunnel GRE entre un ALU 7750SR et un fournisseur tiers. Je pense que cela rechigne à VC-ID dans le SDP, mais j'espère que quelqu'un a de l'expérience pour obtenir un tunnel GRE dans un environnement multi-fournisseurs avec ALU.

Voici la syntaxe demandée:

sdp 9999 create
far-end 1.1.1.1 
path-mtu 1500 
keep-alive 
exit

ies 9998 customer 1 create 
 interface "PACKET_DESIGN" create 
 address 10.128.105.6/30 
 spoke-sdp 9999:1 create 
 no shutdown 
 exit 
no shutdown

gre alcatel-lucent-7750 Boue
la source

Pourriez-vous fournir un peu plus d'informations? Qu'avez-vous essayé, pourquoi pensez-vous que le VC-ID pourrait être la cause, quel fournisseur tiers, ...

Gerben

Quelle est la configuration du réseau? Est-ce que cela passe un pare-feu ou est-il configuré sur le pare-feu? Dans le cas d'un pare-feu, avez-vous autorisé le trafic des ports GRE et TCP? Veuillez fournir un schéma de réseau comme celui-ci: LAN1 => Firewall1 == GRE Tunnel == Firewall2 <= LAN2

Bulki

Pouvez-vous publier un exemple de configuration pour donner du contexte?

jwbensley

@javano J'ai ajouté la syntaxe au message principal.

Boue

@Bulki Aucun pare-feu n'est impliqué. J'essaye d'obtenir ceci pour tunneler une contiguïté ISIS L1 à un serveur Route Explorer / Packet Design mais à toutes fins utiles, vous pouvez imaginer que j'essaye de faire un tunnel vers un routeur Cisco (car je peux obtenir un tunnel GRE pour travailler de Cisco à Packet Design sans syntaxe spéciale du côté de Cisco). Le schéma de réseau est aussi simple qu'il y paraît: LAN1 - Tunnel GRE - LAN2. Noyau MPLS standard, aucun TE n'a lieu car le SDP est défini comme GRE.

Boue

Réponses:

Le support AFAIK GRE est limité aux services VPN ou en tant que pseudowire d'accès. Au moins, selon ALU, il n'y a aucun moyen d'utiliser GRE comme tunnel logique du côté «réseau». Cela nécessiterait une lame de service. Cependant, je n'ai pas testé cela, mais cela semble être l'histoire officielle.

aakso
la source

En jouant, j'ai certainement pu faire fonctionner les tunnels GRE du côté réseau ALU à ALU, et avoir des contiguïtés ISIS à travers le tunnel. C'est quand c'est ALU à autre chose que ça ne marche pas. Je suis certain que le problème est que l'étiquette SVC-ID arrive sur le périphérique non ALU (et que le périphérique non ALU n'en renvoie pas à ALU) mais je ne peux pas penser à un moyen de le résoudre. Il semble stupéfiant qu'il n'y ait pas de moyen facile de transformer un tunnel GRE standard RFC en ALU à un autre fournisseur.

Boue

Votre configuration implique la signalisation tldp car elle est activée par défaut. Il peut être désactivé avec "signalisation désactivée". J'ai testé cette configuration - mais il semble toujours que l'utilisation de "speak-sdp" dans le contexte IES / VPRN appelle l'étiquette de service à utiliser dans le plan de données. Je dois cependant vérifier cela avec des captures de paquets. La "vraie" interface de tunnel afaik nécessite une lame MS-ISA. Ensuite, vous pouvez créer des saps de tunnel logiques qui ont la destination GRE.

aakso

J'ai déjà essayé ça. Permettez-moi de vous montrer ce que vous avez fait.

J'ai d'abord créé les SDP en tant que GRE.

far-end 10.1.0.6
signaling off
keep-alive
 shutdown
exit
no shutdown

Créez ensuite votre service IES. Maintenant, lorsque vous créez le Spd-Spd et que la signalisation est désactivée (puisque vous utilisez GRE), vous devez alors établir manuellement les étiquettes vc d'entrée et de sortie.

ies 100 customer 1 create
 interface "to_SARA_2" create
  address 192.168.0.1/30
  spoke-sdp 12:100 create
   ingress
    vc-label 2048
   exit
   egress
    vc-label 2048
   exit
  exit
 exit
 no shutdown
exit

Cette dernière chose fait l'affaire et vous pouvez ensuite transférer du trafic en utilisant GRE au lieu de MPLS ...

lucas
la source

Souvent, vous devez définir le MTU à 1440 ou moins de la mémoire pour permettre à l'en-tête GRE d'accéder à l'autre site> très utile et facile à comprendre (pas un livre blanc de 100 pages non plus)

Calcul de la surcharge du mode tunnel IPSec GRE Point à point IPSEC GRE

Je dirais que vous vous référez à cet article pour obtenir plus d'informations: j'en ai configuré un l'autre avec 2 ciscos - supprimez simplement les éléments IPSec de votre configuration, mais comme je l'ai dit> abaissez le MTU des deux côtés pour qu'il corresponde (et vous devriez vraiment mettre en œuvre IPSEC)

alex_da_gr8
la source

L'interface MTU de bout en bout est normalisée à 9212 (ce nombre inclut les frais généraux L2). Utiliser la commande "path-mtu" était plus une "grêle marie" pendant que j'essayais de faire fonctionner cela. Pour les coups de pied, j'ai modifié l'instruction path-mtu à 1400, 1300, 1200 et 1100 et elle est restée opérationnelle. Votre lien ne résout pas la différence de livraison entre ALU et Cisco, et la configuration d'un tunnel GRE entre deux Cisco n'est pas le problème. IPSEC n'est pas non plus nécessaire car ce tunnel ne quitte pas notre propre AS.

Mud