Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Assembler tout cela

Les cas d’utilisation suivants sont des exemples de différentes conceptions réseau qui utilisent différentes méthodes et techniques des fonctionnalités d’Apstra Freeform abordées. Ces exemples vous aident à mieux comprendre comment les fonctionnalités d’Apstra et de Freeform peuvent être utilisées pour traiter divers cas d’utilisation de mise en réseau.

Étude de cas n°1 - Petite version de London Tube - Topologie CloudLabs

Ce cas d’utilisation utilise une petite version du système souterrain de Londres comme carte pour concevoir une topologie de réseau à partir de commutateurs arbitraires. Le concept ici est de créer une conception de réseau très simple à l’aide de modèles Jinja et d’un ensemble de propriétés. Ce cas d’utilisation montre comment créer une conception réseau complète à l’aide de modèles Jinja et de jeux de propriétés non compliqués.

Ce cas d’utilisation est disponible en laboratoire pratique à l’aide de Juniper Apstra Cloudlabs. Il existe également un référentiel GitHub qui inclut les fichiers Jinja et les ensembles de propriétés JSON auxquels vous pouvez faire référence, contribuer ou même fourche.

  1. Topologie de l’environnement.

    La conception dans le plan

    Toutes les liaisons système affichant les balises et les adresses IP attribuées par l’intermédiaire de l’éditeur/API de topologie.

  2. État final des configurations rendues. Pour l’équipement Bond-Street, voici un exemple de configuration de rendu.

    interfaces Bloquer les options de stratégie Protocoles de blocage Bloc
     interfaces { 
        replace: xe-0/0/0 { 
          unit 0 { 
    interfaces { 
        replace: xe-0/0/0 { 
          unit 0 { 
            description "facing_oxford-circus:xe-0/0/1"; 
            family inet { 
              address 192.168.0.2/31; 
            } 
          } 
        } 
        replace: xe-0/0/1 { 
          unit 0 { 
            description "facing_green-park:xe-0/0/1"; 
            family inet { 
              address 192.168.0.8/31; 
            } 
          } 
        } 
        replace: lo0 { 
          unit 0 { 
              family inet { 
                  address 10.0.0.2/32; 
              } 
    protocols { 
      lldp { 
          port-id-subtype interface-name; 
          port-description-type interface-description; 
          neighbour-port-info-display port-id; 
          interface all; 
      } 
      replace: rstp { 
        bridge-priority 0; 
        bpdu-block-on-edge; 
      } 
      bgp { 
        group external-peers { 
          type external; 
          export send-direct; 
          neighbor 192.168.0.3 { 
            peer-as 22; 
            export add-med-110; 
          } 
          neighbor 192.168.0.9 { 
            peer-as 86; 
            export add-med-177; 
          } 
        } 
      } 
    } 
    routing-options { 
      autonomous-system  47; 
    } 
    protocols {
      lldp {
         port-id-subtype
    interface-name;
         port-description-type
    interface-description;
         neighbour-port-info-display port-id;
     interface all; } replace: rstp {
     bridge-priority 0;
     bpdu-block-on-edge; }
     bgp {
     group external-peers {
     type external;
     export send-direct;
     neighbor 192.168.0.3 {
     peer-as 22; export add-med-110;
     } neighbor 192.168.0.9 { peer-as 86; export add-med-177;
     } } } } 
    routing-options {
      autonomous-system 47;
    }
  3. Afficher les modèles de configuration

    Config Template System.jinja Description
    system { 
        host-name {{hostname}}; 
    } 
    Il s’agit du modèle de configuration principal.jinja. Ce modèle est le modèle system.jinja qui utilise la variable intégrée « hostname » du contexte de l’équipement pour définir le nom de l’hôte système sur ce.
    Interfaces de modèle de configuration.jinja Description
    {% set this_router=hostname %} 
    interfaces { 
    {% for interface_name, iface in interfaces.iteritems() %} 
        replace: {{ interface_name }} { 
          unit 0 { 
            description "{{iface['description']}}"; 
            family inet { 
              address {{iface['ipv4_address']}}/{{iface['ipv4_prefixlen']}}; 
            } 
          } 
        } 
    {% endfor %} 
        replace: lo0 {
          unit 0 { 
              family inet { 
                  address {{ property_sets.data[this_router]['loopback'] }}/32; 
              } 
          } 
       } 
    } 

    Définir la variable this_router=nom de l’hôte

    Pour une boucle qui traverse les interfaces et insère la syntaxe d’aubaine d’interface appropriée pour junos, y compris la description de l’interface et de l’adresse inet de la famille et de la longueur de préfixe à partir du contexte de l’équipement. Vous pouvez remplir ces valeurs via les liens de l’éditeur de topologie.

    Cela insère les données property_set de l’adresse de bouclage de ce routeur dans la stanza de bouclage.

    Config Template Protocols.jinja Description
    {% set this_router=hostname %} 
    policy-options { 
      policy-statement send-direct { 
          term 1 { 
              from protocol direct; 
              then accept; 
          } 
      } 
    {% for interface_name, iface in interfaces.iteritems() %} 
    {% set link_med = iface.link_tags[0] %} 
    {# 
      this may create multiple identical policy-statements, but JunOS is smart enough 
      to squash them. 
    #} 
      policy-statement add-med-{{ link_med }} { 
              from { 
                route-filter 0.0.0.0/0 longer; 
              } 
              then { 
                metric add {{ link_med }}; 
              } 
              then  { 
                accept 
              } 
      } 
    {% endfor %} 
    } 
     
    protocols { 
      lldp { 
          port-id-subtype interface-name; 
          port-description-type interface-description; 
          neighbour-port-info-display port-id; 
          interface all; 
      } 
      replace: rstp { 
        bridge-priority 0; 
        bpdu-block-on-edge; 
      } 
     
      bgp { 
        group external-peers { 
          type external; 
          export send-direct; 
          {% for interface_name, iface in interfaces.iteritems() %} 
          neighbor {{ iface.neighbor_interface.ipv4_address }} { 
            {% set peer_hostname=iface.neighbor_interface.system_hostname %} 
            peer-as {{ property_sets.data[peer_hostname]['asn'] }}; 
            export add-med-{{ iface.link_tags[0] }}; 
          } 
          {% endfor %} 
        } 
      } 
    } 
     
    routing-options { 
      autonomous-system  {{ property_sets.data[this_router]['asn'] }}; 
    } 

    Définissez la variable this_router = nom d’hôte à partir du contexte de l’équipement.

    Définissez une aubaine d’options de stratégie pour envoyer tous les itinéraires directement joints.

    Marcher dans l’arborescence de l’interface.

    Définissez la variable link_med sur la balise définie sur l’interface via la topologie.

    Définir les paramètres LLDP

    Définir les paramètres RSTP

    Créer l’aubaine bgp

    Groupes de pairs externes

    Type d’externe (ebgp)

    Politique d’exportation d’send-direct

    Marchez dans l’arborescence de l’interface et insérez des voisins pour n’importe quel voisin ayant une adresse ipv4. Définissez la variable peer_hostname sur le nom d’hôte des interfaces de voisinage.

    Prenez le peer comme du property_sets données « asn »

    La stanza peer-as est définie avec une politique d’exportation d’add-med-tags

    Définissez la gamme d’options de routage avec le système autonome de la propriété définit commen valeur.

  4. Ensemble de propriétés

    Description de l’ensemble de propriétés « données »
    { 
        "bond-street": { 
          "asn": 47, 
          "loopback": "10.0.0.2" 
        }, 
        "green-park": { 
          "asn": 86, 
          "loopback": "10.0.0.4" 
        }, 
        "tottenham-court-road": { 
          "asn": 48, 
          "loopback": "10.0.0.3" 
        }, 
        "leicester-square": { 
          "asn": 137, 
          "loopback": "10.0.0.5" 
        }, 
        "piccadilly-circus": { 
          "asn": 23, 
          "loopback": "10.0.0.1" 
        }, 
        "oxford-circus": { 
          "asn": 22, 
          "loopback": "10.0.0.0" 
        } 
      } 

    L’ensemble de propriétés est simple représenté sous la forme d’une liste de dictionnaires qui incluent les éléments suivants :

    • Le nom du système ou de la station est la clé, et à l’intérieur de cette clé se trouvent deux paramètres

    • Asn qui est le numéro de système autonome pour l’appairage BGP

    • Bouclage (loopback) qui est l’adresse de bouclage du système/de la station avec laquelle il doit être appairé.

Cas d’utilisation n°2 : balises et ensembles de propriétés pour la configuration du jour 2

La petite topologie ci-dessous a été construite dans l’éditeur de topologie Freeform. Il dispose de trois commutateurs et de deux systèmes externes nommés ESXi-1 et ESXi-2. Les liaisons faisant face aux deux hôtes sont marquées respectivement par esxBlueTrunk et esxRedTrunk. L’objectif de ce cas d’utilisation est de montrer comment une seule façon d’utiliser la fonctionnalité Freeform pour construire de manière dynamique le tronc du commutateur face aux hôtes ESXi, déterminées par les entrées du jeu de propriétés et les balises attribuées dans la topologie.

Le rôle de la balise dans cette instance est d’indiquer où le tronc doit être configuré/créé.

Le rôle de l’ensemble de propriétés dans cette instance est de conserver les données pertinentes requises pour configurer les membres du tronc, les VLAN et les IRB.

Cet exemple décrit la puissance d’utiliser un modèle de configuration (Jinja2), des balises et des ensembles de propriétés soigneusement conçus pour créer une configuration, sans avoir à repenser le modèle de configuration. Lorsque de nouvelles balises sont attribuées à la topologie ou que de nouveaux VN sont affectés au jeu de propriétés, la configuration associée sera construite de manière dynamique pour ces troncs.

Configuration de l’état final

Pour l’interface balisées avec esxBlueTrunk, la configuration Junos finale comprend les éléments suivants :

Bloc d’interface Bloc IRB Bloc VLAN
interfaces { 
  ae2 { 
  description esxBlueTrunk 
    unit 0 {             
      family ethernet-switching { 
          interface-mode trunk 
          vlan { 
            members [ 
                    vn99 
                    vn100 
                    vn101 
            ] 
         } 
      }           
    } 
  } 
irb { 
    unit 99 { 
        family inet { 
            mtu 9000; 
            address 1.1.99.1/24; 
        } 
    } 
    unit 100 { 
        family inet { 
            mtu 9000; 
            address 1.1.100.1/24; 
        } 
    } 
    unit 101 { 
        family inet { 
            mtu 9000; 
            address 1.1.101.1/24; 
        } 
    } 
  } 
} 
vlans { 
  vn99 { 
    vlan-id 99; 
    description vMotionVN-99; 
    l3-interface irb.99; 
  } 
  vn100 { 
    vlan-id 100; 
    description storageVN-100; 
    l3-interface irb.100; 
  } 
  vn101 { 
    vlan-id 101; 
    description mgmtVN-101; 
    l3-interface irb.101; 
  } 
} 

Ensemble de propriétés esxTrunk

L’ensemble de propriétés inclut les détails nécessaires à la création de la configuration Trunk de Junos

Description de l’ensemble de propriétés esxTrunk

L’ensemble de propriétés esxTrunk (à gauche) a été construit comme dictionnaire des dictionnaires pour une bonne raison: pour permettre la recherche récursive. Le dictionnaire esxBlueTrunk a été étendu pour afficher les valeurs 99, 100, 101 qui dans cette instance sont utilisées à la fois comme ID VLAN et comme clé du dictionnaire ci-dessous. Les dictionnaires ci-dessous fournissent la clé : paires de valeur pour le sous-réseau, la passerelle et la description. Dans cet exemple, le sous-réseau n’est pas requis et existe uniquement pour référence.

Les données étant organisées de cette façon, le modèle de configuration a été conçu pour récurrence à travers deux structures de données afin de rechercher les balises correspondantes :

  1. Ensemble de propriétés esxTrunk

  2. Topologie de l’éditeur de topologie

Lorsque la balise des deux jeux de données correspond, le modèle de configuration produit la configuration souhaitée. En associant le jeu de propriétés à gauche à la sortie de configuration Junos ci-dessus, vous voyez que :

  • Les valeurs esx[Rouge | | bleu Pink]Trunk, sont utilisés comme balises pour correspondre, lorsque nous passons à travers les deux ensembles de données.

  • Les valeurs 99, 100, 101 sont utilisées comme ID VLAN

  • La passerelle est utilisée comme adresse IRB

  • La description est utilisée pour remplacer la description de l’interface originale (selon les besoins)

L’esx(Red/Pink)Trunk, contient des informations similaires à celles de l’esxBlueTrunk

Pour permettre une marche récursive efficace des propriétés Définies à gauche et des balises attribuées aux liaisons de la topologie, les balises ont été volontairement affectées aux mêmes valeurs

  • esxRedTrunk

  • esxBlueTrunk

  • esxPinkTrunk

Machine d’état de modèle de configuration de base Jinja2

Le flux Config Template esxTrunks.jinja est décrit ci-dessous.

Modèle de configuration de base Jinja2

Description
du modèle de configuration
{% set Rendered_VNs = {} %} 
{% for ps_tag in property_sets.esxTrunk %} 
 
 
 
  {% for interface_name, iface in interfaces.iteritems() %}  
    {% if ((iface.link_tags) and (ps_tag in iface.link_tags)) %} 
   
 
interfaces { 
  {{interface_name}} { 
  description {{ ps_tag }} 
     
 
  unit 0 {             
      family ethernet-switching { 
          interface-mode trunk 
          vlan { 
            members [ 
                {% for vlan_id in property_sets.esxTrunk[ps_tag] %} 
                {% set _ = Rendered_VNs.update({vlan_id: ps_tag}) %} 
                    vn{{ vlan_id }} 
                {% endfor %} 
            ] 
         } 
      }           
    } 
  } 
  {% endif %} 
  {% endfor %}   
  {% endfor %} 
   
irb { 
{% for vn in Rendered_VNs %} 
{% set tag = Rendered_VNs[vn] %} 
    unit {{ vn }} { 
        family inet { 
            mtu 9000; 
            address {{ property_sets.esxTrunk[tag][vn]['gateway'] }}; 
        } 
    } 
    {% endfor %} 
  } 
} 
vlans { 
{% for vn in Rendered_VNs|unique %} 
{% set tag = Rendered_VNs[vn] %} 
  vn{{ vn }} { 
    vlan-id {{ vn }}; 
    description {{ property_sets.esxTrunk[tag][vn]['description'] }}-{{ vn }}; 
    l3-interface irb.{{ vn }}; 
  } 
  {% endfor %} 
} 

Un dictionnaire global permettant de stocker des VN à rendre

Commencez par traverser l’ensemble de propriétés esxTrunk ci-dessus. La première valeur récupérée et stockée dans la variable ps_tag (balise Property Set) est l’une des chaînes suivantes :

  • esxRedTrunk

  • esxBlueTrunk

  • esxPinkTrunk

Traverser ou « itérer » à travers les interfaces de la topologie

Si une interface link_tag existe et que le ps_tag figure dans la liste des balises de liaison d’interface, la condition est remplie lorsque la configuration du tronc est rendue.

Lancez la sortie du bloc d’interfaces . Sortie du interface_name où ps_tag égale la balise de liaison de l’interface . Attribuez éventuellement une description, bien que Freeform ait déjà attribué cette description à partir de la topologie

Définir le numéro d’unité et la configuration associée pour décrire le tronc

Définir le membre d’agrégation

Traverser le jeu de propriétés esxTrunk à l’aide du ps_tag pour récupérer les ID VLAN

Saisissez chaque ID VLAN dans le dictionnaire déclaré à la ligne 1pour une utilisation ultérieure

Sortie de l’ID VLAN vn détaillé dans l’ensemble de propriétés esxTrunk

Mettre fin à la boucle lorsqu’il n’y a plus d’entrées dans l’ensemble de propriétés esxTrunk

Mettre fin à l’énoncé if ci-dessus

Terminer la déclaration ci-dessus

Terminer la déclaration ci-dessus

Lancer la sortie du bloc irb

Parcourir le dictionnaire Rendered_VNs

Pour plus de lisibilité, définissez la balise variable sur la balise stockée dans le dictionnaire

Définissez le numéro de l’unité à l’aide du vlan_id

Définir l’adresse de passerelle stockée dans l’esxTrunk PropertySet à l’aide de la balise, de vn et de la clé « passerelle » pour accéder à la chaîne stockée

Terminer la déclaration ci-dessus

Starer sortant le bloc vlans

Selon le bloc irb ci-dessus, traverser le dictionnaire Rendered_VNs,

Pour plus de lisibilité, définissez la balise variable sur la balise stockée dans le dictionnaire

Définir le numéro de vn

Définir l’ID vlan_id

Définissez la description selon les besoins

Définir le numéro irb de couche 3

Terminer la déclaration ci-dessus

Le modèle de configuration basé sur Jinja2 visible ci-dessous utilise à la fois la balise attribuée et l’ensemble de propriétés pour construire la configuration requise.

Cas d’utilisation n°3 - Exemple avancé utilisant CRB - Topologie CloudLabs

Ce dernier cas d’utilisation est un exemple complet de CRB rédigé par Apstra Engineering. Cet exemple repose entièrement sur des modèles Jinja statiques et toutes les données sont définies dans des ensembles de propriétés pour le réseau/les équipements. Cela permet aux utilisateurs de cet exemple CRB de faire fonctionner / étendre / modifier le réseau simplement en modifiant des ensembles de propriétés et en vous permettant de ne pas toucher aux modèles Jinja sous-jacents. L’objectif de ce cas d’utilisation est de vous donner un exemple de l’art du possible et de démontrer la flexibilité et la puissance de la fonctionnalité Freeform. Tous les modèles de configuration, ensembles de propriétés, modèles et fonctions jinja ont intégré la documentation pour vous aider à comprendre l’utilisation et la fonction.

Ce cas d’utilisation est disponible sous la forme d’un sandbox pratique entièrement déployé à l’aide de Juniper Apstra Cloudlabs. Il existe également un référentiel GitHub qui inclut tous les mêmes fichiers. vous pouvez l’utiliser comme exemples d’exécution de certaines fonctions pour créer vos propres modèles de configuration avancés dans votre cas d’utilisation https://www.juniper.net/us/en/forms/apstra-free-trial.html