Network/Juniper/Survival guide : Différence entre versions

De MonPtitSite
Sauter à la navigation Sauter à la recherche
(Page créée avec « {{MediaWiki}} <br> {{FOND_BLEU|Juniper- '''Petit guide de survie''' pour un newbie ...}} = Sites Références = * [https://www.juniper.net/documentation/us/en/software/j… »)
 
Ligne 54 : Ligne 54 :
  
 
Junos supports regex during configuration.
 
Junos supports regex during configuration.
−
 
−
 
−
<syntaxhighlight lang="bash">
 
−
[user@demo project2]$ tree -F group_vars
 
−
group_vars/
 
−
├── db_servers/
 
−
│ ├── 3.yml
 
−
│ ├── a.yml
 
−
│ └── myvars.yml
 
−
├── lb_servers/
 
−
│ ├── 2.yml
 
−
│ ├── b.yml
 
−
│ └── something.yml
 
−
└── web_servers/
 
−
└── nothing.yml
 
−
</syntaxhighlight>
 
−
 
  
 
=Command Summary=
 
=Command Summary=
Ligne 88 : Ligne 71 :
 
|{{CODE|show interfaces [extensive]}}
 
|{{CODE|show interfaces [extensive]}}
 
|operational
 
|operational
−
| Get interface statistics
+
|Get interface statistics
 +
|-
 +
|{{CODE|set interfaces INTERFACE …}}
 +
|configuration
 +
|Configures an interface
 
|-
 
|-
−
|{{CODE|ansible_port}}
+
|{{CODE|set interfaces INTERFACE description}}
−
|Port utilisé par Ansible pour se connecter à l'hôte géré. Pour le plug-in de connexion par SSH (par défaut), la valeur par défaut est '''22'''.
+
|configuration
 +
|Adds a description to an interface
 
|-
 
|-
−
|{{CODE|ansible_user}}
+
|{{CODE|set interfaces INTERFACE unit NUMBER family inet address …}}
−
|Utilisateur dont se sert Ansible pour se connecter à l'hôte géré. Le comportement par défaut d'Ansible est de se connecter à l'hôte géré à l'aide du même nom d'utilisateur que celui qui exécute le playbook Ansible sur le noeud de contrôle.
+
|configuration
 +
|Configures an IPv4 address
 
|-
 
|-
−
|{{CODE|ansible_become_user}}
+
|{{CODE|set interfaces INTERFACE disable}}
−
|Une fois qu'Ansible s'est connecté à l'hôte géré, il bascule vers cet utilisateur en utilisant absible_become_method (qui est {{CODE|sudo}} par défaut). Il se peut que vous deviez vous procurer des informations d'identification d'authentification de quelque façon que ce soit.
+
|configuration
 +
|Disables an interface
 
|-
 
|-
−
|{{CODE|ansible_python_interpreter}}
+
|{{CODE|set vlans NAME vlan-id ID}}
−
|Chemin d'accès à l'exécutable Python qu'Ansible doit utiliser sur l'hôte géré. Sur Ansible 2.8 et versions ultérieures, cette valeur par défaut est {{CODE|auto}}, qui sélectionne automatiquement un interpréteur Python sur l'hôte exécutant le playbook en fonction du système d'exploitation qu'il exécute. Ainsi, il n'est plus autant nécessaire d'utiliser ce paramètre que dans les versions antérieures d'Ansible.
+
|configuration
−
|}
+
|Defines a VLAN
−
 
+
|-
−
 
+
|{{CODE|show vlans}}
−
=== Variables utilisées lors d'exécution de playbooks ===
+
|operational
−
 
+
|Shows a list of configured VLANs
−
Lorsqu'un play est en cours d'exécution, un certain nombre de variables et de faits peuvent être utilisés pour identifier le nom de l'hôte géré actuel qui exécute une tâche :
+
|-
−
 
+
|{{CODE|set interfaces INTERFACE unit 0 family ethernet-switching interface-mode <access/trunk>}}
−
{| class="wikitable"
+
|configuration
−
!colspan="2"|Variables Ansible spécifiques à l'exécution
+
|Sets a layer-2 port type (trunk port or access port)
 +
|-
 +
|{{CODE|set interfaces INTERFACE unit 0 family ethernet-switching vlan members VLAN}}
 +
|configuration
 +
|Adds VLANs to the port
 +
|-
 +
|{{CODE|set interfaces INTERFACE vlan-tagging}}
 +
|configuration
 +
|Enables VLAN tagging, which enables the use of units as subinterfaces
 +
|-
 +
|{{CODE|set poe interface all}}
 +
|configuration
 +
|Enables PoE on all interfaces
 
|-
 
|-
−
! class="wikitable" | Variable
+
|{{CODE|set protocols lldp-med interface all}}
−
! Description
+
|configuration
 +
|Enables LLDP-MED on all interfaces
 
|-
 
|-
−
|{{CODE|inventory_hostname}}
+
|{{CODE|rename}}
−
|Nom de l'hôte géré en cours de traitement, extrait de l'inventaire.
+
|configuration
 +
|Renames some configuration
 
|-
 
|-
−
|{{CODE|ansible_host}}
+
|{{CODE|deactivate}}
−
|Adresse IP ou nom d'hôte réel qui a été utilisé pour se connecter à l'hôte géré, comme indiqué
+
|configuration
−
précédemment.
+
|Deactivates any part of the config
 
|-
 
|-
−
|{{CODE|ansible_facts ['nom d'hôte']}}
+
|{{CODE|copy}}
−
|Nom court (non qualifié) de l'hôte collecté comme un fait de l'hôte géré.
+
|configuration
 +
|Copy some configuration from one place to another
 
|-
 
|-
−
|{{CODE|ansible_facts ['fqdn']}}
+
|{{CODE|replace}}
−
|Nom de domaine complet de l'hôte collecté comme un fait de l'hôte géré.
+
|configuration
 +
|Replace some configuration
 
|-
 
|-
−
|{{CODE|ansible_play_hosts}}
+
|{{CODE|annotate}}
−
|liste de tous les hôtes qui n'ont pas encore échoué au cours du play actuel (et qui, par conséquent, sera utilisée
+
|configuration
−
pour les tâches restantes du play).|}
+
|Adds annotations into the config, like comments in code
 +
 
 
|}
 
|}
−
 
−
== Penser ré-utilisabilité ! ==
 
−
 
−
Les rôles permettent de créer des playbooks simples et de réutiliser du code commun à plusieurs projets.  Un '''role''' doit porter sur un objectif ou une fonction spécifique.
 
−
Idéalement, il est préférable de créer des rôles génériques configurables par le biais de variables. Ces variables sont le plus souvent définies par défaut dans le fichier YAML <code>roles/[nom_role]/default/main.yml</code>
 
−
De cette façon, un rôle disposant de son propre paramétrage et ensemble de tâches peut facillement être intégré dans un autre playbook.
 
−
 
−
Si un playbook doit modifier le contenu d'une variable définie par un rôle, il suffit :
 
−
* soit inclure un fichier de définition de variables au niveau du playbook (cf <code>[https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#defining-variables-in-files var_files]</code>)
 
−
* soit définir une zone tasks <code>vars:</code> qui remplace le contenu de cette variable. (cf [https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable Ordre de précédence des variables dans un playbook ansible])
 
−
 
−
Exemple
 
−
 
−
 
−
<syntaxhighlight lang="yaml">
 
−
- hosts: webservers
 
−
  vars:
 
−
    apache2_config: true
 
−
    apache2_default_port: 8000
 
−
  roles:
 
−
    ansible-apache2
 
−
 
−
</syntaxhighlight>
 
−
 
−
Ce playbook utilise le rôle <code>ansible-apache2</code> en modifiant 2 variables utilisées par ce rôle : <code>apache2_config</code> & <code>apache2_default_port</code>.
 
−
 
−
A l'éxécution de ce playbook, le service apache2 sera installé sur les serveurs <code>webservers</code> pour écouter sur le port 8000/tcp.
 
−
 
−
== Exécution centralisée des playbooks ==
 
−
 
−
Pour contrôler l'accès aux systèmes et auditer l'activité d'Ansible, il est nécessaire d'envisagez l'utilsiation d'un serveur de contrôle dédié à partir duquel tous les playbooks Ansible sont exécutés.
 
−
Les administrateurs système doivent toujours disposer de leurs propres comptes sur le système, ainsi que des informations d'identification permettant de se connecter aux hôtes gérés et d'augmenter les privilèges, si nécessaire.
 
−
Lorsqu'un administrateur système cesse de travailler sur le projet, sa clé SSH peut être supprimée du fichier <code>authorized_keys</code> de l'hôte géré et ses privilèges de commande <code>sudo</code> peuvent être révoqués, sans répercussion sur les autres administrateurs.
 
−
 
−
Ce serveur central peut avantageusement héberger les services <code>[https://www.ansible.com/products/awx-project/faq awx]</code> ou la version supportée par Red Hat <code>[https://www.ansible.com/products/tower Ansible Tower]</code>
 
−
 
−
= Tester régulièrement =
 
−
 
−
Il est bien évident qu'il faut tester les playbooks aussi bien au cours de la phase de développement que pendant l'exécution des playbooks eux-même.  En effet, Ansible offre cette possibilité de s'auto-valider en définissant des tâches spécifiques permettant de vérifier une étape précédente d'un playbook.
 
−
 
−
== Test des résultats des tâches ==
 
−
Si on a besoin de confirmer la réussite d'une tâche, vérifiez le résultat de la tâche au lieu de faire confiance au code de retour du module.
 
−
Il existe plusieurs moyens de valider une tâche, en fonction du module concerné.
 
−
 
−
 
−
Exemple :
 
−
 
−
<syntaxhighlight lang="yaml">
 
−
- Start web server
 
−
  service:
 
−
    name: httpd
 
−
    status: started
 
−
- name: Check web site from web server
 
−
  uri:
 
−
    url: http://{{ ansible_fqdn }}
 
−
    return_content: yes
 
−
  register: example_webpage
 
−
  failed_when: example_webpage.status != 200
 
−
</syntaxhighlight>
 
−
 
−
 
−
== Utilisation de block/rescue pour effectuer une récupération ou une restauration  ==
 
−
 
−
La directive <code>block</code> est utile pour regrouper des tâches ; lorsqu'elle est associée à la directive
 
−
<code>rescue</code>, elle est utile lorsqu'il s'agit d'effectuer une récupération après des erreurs ou des pannes.
 
−
 
−
Exemple :
 
−
 
−
 
−
<syntaxhighlight lang="yaml">
 
−
- block:
 
−
  - name: Check web site from web server
 
−
    uri:
 
−
      url: http://{{ ansible_fqdn }}
 
−
      return_content: yes
 
−
    register: example_webpage
 
−
    failed_when: example_webpage.status != 200
 
−
  rescue:
 
−
    - name: Restart web server
 
−
      service:
 
−
        name: httpd
 
−
        status: restarted
 
−
</syntaxhighlight>
 
−
 
  
  
 +
= Additional References =
  
−
== Outils de test ==
+
Explanation of “ifd” and “ifl” indexes  https://kb.juniper.net/InfoCenter/index?page=content&id=KB2820
  
−
* <code>ansible-playbook --syntax-check</code> : pour vérifier la syntaxe d'un playbook (sans l'exécuter)
+
Router Interfaces Overview  https://www.juniper.net/documentation/en_US/junos/topics/concept/interfaces-interface-naming-overview.html
−
* <code>ansible-playbook --check</code> : Exécute un playbook en mode "vérification"
 
−
{{NOTE
 
−
|contenu=
 
−
Cette vérification ne garantit pas une précision parfaite, étant donné que le playbook peut avoir besoin d'exécuter réellement certaines tâches avant que les tâches ultérieures du playbook ne fonctionnent correctement. Certaines tâches peuvent être marquées avec la directive check_mode: no. Ces tâches s'exécutent même en mode vérification.
 
−
}}
 
  
 +
Performing Loopback Testing https://www.juniper.net/documentation/en_US/junos/topics/topic-map/ethernet-fast-and-gigabit-loopback-testing.html
  
−
{{NOTE
+
Configuring Default, Primary, and Preferred Addresses and Interfaces https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/interfaces-configuring-default-primary-and-preferred-addresses-and-interfaces.html
−
|contenu=
 
−
Il existe d'autres outils. Par exemple :
 
−
L'outil <code>ansible-lint</code> analyse un playbook et recherche les problèmes éventuels. Tous les problèmes signalés n'interrompront pas forcément le fonctionnement du playbook, mais les problèmes signalés peuvent indiquer la présence d'une erreur.
 
−
L'outil <code>yamllint</code> analyse un fichier YAML et tente d'identifier les problèmes liés à la syntaxe YAML. Cet outil n'a pas une connaissance directe d'Ansible, mais il peut intercepter des problèmes potentiels de syntaxe YAML.
 
−
}}
 

Version du 24 novembre 2022 à 18:17

Accueil SysAdmin Hobbies                  


Juniper- Petit guide de survie pour un newbie ...


Sites Références

Notes

There are several acronyms for interface types and components: 

  * IFD – Interface Physical Device
  * IFL – Interface Logical Device
  * IFF – Address Family
  * IFA – Address Entry

Common interface names are: 

   * ge – Gigabit ethernet
   * xe – 10G ethernet
   * et – 100G ethernet
   * ae – aggregated ethernet (LAG/etherchannel)
   * vlan or irb – Logical interface based on VLAN


SFP’s can be of different speeds (eg, one may be 1G, and another may be 10G). So be aware that the interface names may change based on the SFP used.

The interface naming convention is type-x/y/z 

   Type is ge, xe, etc
   x – FPC (aka linecard)
   y – module or slot
   z – port number

There are several names for management interfaces. Each platform may use different names. These include fxp0, em0, me0, and vme0. Some of these are physical, and others are virtual.

Some interfaces, such as pimd, pime, dsc, ipip, and gre, are special interfaces that are used for special purposes.

An unnumbered interface does not have an IP address. This helps conserve IP addresses.

All interfaces are configured with a unit. This contains logical interface information, like addressing. Sometimes this is used to create sub-interfaces. Physical properties (duplex, link speed, etc) are not configured in the unit.

Each unit may have one or more family. This is where the address is applied. For example, the inet family is for IPv4 addressing.

Addresses can be primary, preferred, or secondary. Primary addresses are used for locally sourced (broadcast or multicast) traffic, destined to a remote subnet. Preferred addresses are for locally sourced traffic to the local subnet.

Configuring voice ports means three main steps: 

  * Configuring a voice VLAN
  * Configuring PoE
  * Configuring LLDP-MED

Junos supports regex during configuration.

Command Summary

Juniper OS Command summary
Command Mode Description
show interfaces terse operational Get a simplified view of all interfaces on the system
show interfaces [extensive] operational Get interface statistics
set interfaces INTERFACE … configuration Configures an interface
set interfaces INTERFACE description configuration Adds a description to an interface
set interfaces INTERFACE unit NUMBER family inet address … configuration Configures an IPv4 address
set interfaces INTERFACE disable configuration Disables an interface
set vlans NAME vlan-id ID configuration Defines a VLAN
show vlans operational Shows a list of configured VLANs
set interfaces INTERFACE unit 0 family ethernet-switching interface-mode <access/trunk> configuration Sets a layer-2 port type (trunk port or access port)
set interfaces INTERFACE unit 0 family ethernet-switching vlan members VLAN configuration Adds VLANs to the port
set interfaces INTERFACE vlan-tagging configuration Enables VLAN tagging, which enables the use of units as subinterfaces
set poe interface all configuration Enables PoE on all interfaces
set protocols lldp-med interface all configuration Enables LLDP-MED on all interfaces
rename configuration Renames some configuration
deactivate configuration Deactivates any part of the config
copy configuration Copy some configuration from one place to another
replace configuration Replace some configuration
annotate configuration Adds annotations into the config, like comments in code


Additional References

Explanation of “ifd” and “ifl” indexes https://kb.juniper.net/InfoCenter/index?page=content&id=KB2820

Router Interfaces Overview https://www.juniper.net/documentation/en_US/junos/topics/concept/interfaces-interface-naming-overview.html

Performing Loopback Testing https://www.juniper.net/documentation/en_US/junos/topics/topic-map/ethernet-fast-and-gigabit-loopback-testing.html

Configuring Default, Primary, and Preferred Addresses and Interfaces https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/interfaces-configuring-default-primary-and-preferred-addresses-and-interfaces.html

Récupérée de « http://mediawiki.monptisite.fr/index.php?title=Network/Juniper/Survival_guide&oldid=474 »