> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/knowledge-base/fr/networking/routing-l2-networks.md).

# Routage des réseaux de couche 2 avec VergeOS

Cet article présente une méthode efficace de routage du trafic IP de couche 3 pour les réseaux physiques de couche 2 avec le puissant système réseau VergeOS. Il existe plusieurs façons d’y parvenir ; toutefois, l’objectif de cet article est de fournir des निर्देश claires et concises sur un scénario courant précis. Cet article devrait être particulièrement utile et intéressant pour les ingénieurs et les administrateurs de déploiements Edge dans lesquels des dispositifs physiques comme des téléphones, des caméras de vidéosurveillance ou des équipements réseau doivent communiquer avec des workloads dans VergeOS susceptibles de s’exécuter sur différents sous-réseaux IP. Avec cette méthode, un opérateur peut obtenir une communication locale directe entre ces dispositifs physiques hors de VergeOS et les réseaux internes gérés par VergeOS.

## Vue d’ensemble des étapes

1. Créer le réseau externe de couche 2
   * Il est important que ce réseau soit créé sans information IP. Si le bloc IP est déjà attribué à cette interface, il ne peut pas être ajouté à la route par défaut à l’étape suivante.
2. [Créer le bloc IP sur le réseau externe](/knowledge-base/fr/networking/network-blocks.md#creating-a-network-block) qui acheminera le trafic (probablement l’Externe par défaut)
   * En ajoutant le bloc IP ici, nous indiquons à VergeOS de s’attendre à ce trafic IP entrant via cette interface, et lors de l’étape suivante nous indiquerons à Verge networking où l’envoyer.
   * Attribuer le bloc IP au réseau externe de l’étape 1 (ou au tenant)
   * Lors de l’enregistrement, VergeOS créera automatiquement une ou plusieurs routes pour envoyer le trafic entrant dont les IP de destination correspondent à notre réseau de couche 2, auquel des VM peuvent également être attachées, ce qui permettra à tous les clients de communiquer entre les réseaux au sein de Verge (avec les règles de pare-feu appropriées) et avec les réseaux extérieurs à Verge via la route par défaut.
3. Retourner à l’Externe de couche 2 pour attribuer les IP et les autres options L3
   * Selon votre configuration amont, vous devrez peut-être définir des routes supplémentaires hors de Verge dans les routeurs amont pour acheminer le trafic destiné à ce sous-réseau (192.168.2.0/24 dans notre exemple) via l’IP externe de Verge.

{% hint style="info" %}
**Documents connexes utiles**

Introduction aux blocs réseau : [Vue d'ensemble des blocs réseau](/knowledge-base/fr/networking/network-blocks.md)\
Bases du routage : [Routage des réseaux internes](/knowledge-base/fr/networking/routing-between-internal-vergeio-networks.md)\
Règles réseau : [Guide produit VergeOS - Règles réseau](/run-the-platform/networking/network-rules.md)\
Dépannage réseau : [Guide produit VergeOS - Dépannage réseau](/run-the-platform/networking/net-troubleshooting.md)
{% endhint %}

## Scénario de démonstration

Dans le scénario d’exemple ci-dessous, nous allons acheminer l’espace d’adressage 192.168.2.0/24 via l’interface externe de VergeOS vers un réseau de couche 2 nommé « l2demo ». Dans ce scénario, toute VM attachée à l2demo avec une IP statique (dans le bon espace d’adressage) ou avec DHCP activé pourrait accéder à Internet, tout comme tout appareil physique situé en dehors de Verge, via l’interface L2. Le trafic entrant pourrait être autorisé et contrôlé au moyen de règles supplémentaires. Le trafic sortant pourrait également être restreint par d’autres règles, en faisant attention à l’ordre des règles.

### Détails du scénario de démonstration

* Bloc IP à router : 192.168.2.0/24
* IP externe de Verge : 10.1.1.2
* Réseau L2 externe de Verge : l2demo
* ID du réseau L2 : 1010
* Passerelle amont de Verge : 10.1.1.1
* Interface physique de Verge : phys1

### Créer le réseau L2

```
Dans le menu Réseaux :
```

1. Cliquez sur Nouveau externe
2. Nom : l2demo
3. Description : facultative
4. Type de couche 2 : vLan
5. ID de couche 2 : 1010
6. Type d’adresse IP : Aucun
7. Réseau d’interface : phys1
8. Cliquez sur Valider pour enregistrer.
9. Cliquez sur « Power On » sur la page du réseau après l’enregistrement.
   * Assurez-vous que le réseau démarre sans erreur dans la zone de journal

### Créer le bloc IP sur l’Externe et l’attribuer

1. Cliquez sur « Network Blocks » sur la page du réseau Externe
2. Cliquez sur « Nouveau »
3. Bloc réseau : 192.168.2.0/24
4. Type de propriétaire : Réseau
5. Propriétaire : l2demo
6. Cliquez sur Valider. Vous reviendrez à la page Blocs réseau, qui affichera désormais votre nouveau bloc et le propriétaire auquel il est attribué.

### Attribuer les informations IP au réseau L2

1. Retournez au réseau l2demo
2. Cliquez sur « Règles »

* Confirmez que les règles de pare-feu sont en attente d’application. Vérifiez qu’il existe maintenant une route sortante ; il s’agit de la nouvelle règle. Nous l’appliquerons plus tard.
* Cliquez sur Annuler pour revenir à la page du réseau

3. Cliquez sur Modifier pour attribuer les informations IP au réseau.
4. Type d’adresse IP : Statique
5. Adresse IP : 192.168.2.1
6. Adresse réseau 192.168.2.0/24
7. DNS : Simple
8. Serveur DNS : 10.1.1.1
9. DHCP : activé
10. DHCP dynamique : activé
11. Adresse de début DHCP : 192.168.2.200
12. Adresse de fin DHCP : 192.168.2.254
13. Cliquez sur Valider pour enregistrer

À ce stade, vous avez créé tout ce qu’il faut, mais l’application est toujours en attente ainsi qu’un redémarrage du réseau pour ajouter la couche 2 à l2demo.

* Retournez à votre tableau de bord Réseaux et cliquez sur Tous les réseaux
* Notez que les réseaux Externe et l2demo sont marqués « nécessite l’application du pare-feu » et que l2demo est marqué « nécessite un redémarrage »
* Redémarrez le réseau l2demo en le sélectionnant puis en cliquant sur « Redémarrer ».
  * Acceptez l’option d’appliquer les règles de pare-feu au redémarrage et cliquez sur « oui » pour confirmer.
* Appliquez les règles de pare-feu sur l’Externe en le sélectionnant puis en cliquant sur « Appliquer les règles ».
  * Cliquez sur « oui » pour confirmer
* EN DEHORS DE VERGE (dans le routeur amont) : configurez une route sur 10.1.1.1 pour envoyer 192.168.2.0/24 via 10.1.1.2 et définissez toute autre politique requise pour le trafic sur ce périphérique.

## Variante pour tenant

Lors de l’application du processus ci-dessus à un tenant, il existe généralement deux implémentations courantes.

* Idéalement, une VM de tenant qui doit accéder à un réseau physique de couche 2 le ferait via des routes, en créant les routes et règles appropriées pour autoriser le trafic d’un réseau interne de tenant vers un réseau de couche 2 ; par ex., notre précédent réseau « l2demo » via la passerelle 192.168.2.1.
* Si un accès natif à la couche 2 est requis dans les réseaux de tenant, voir [Fournir un accès couche 2 à un tenant](/knowledge-base/fr/tenants/provide-layer2-to-tenant.md) pour créer un port de commutateur virtuel reliant le réseau du tenant à l’interface externe de couche 2 en dehors du tenant.

{% hint style="warning" %}
Si les appareils ne peuvent pas accéder à Internet, vérifiez de nouveau :

* La route amont vers 192.168.2.0/24 est définie<br>
* Les règles de pare-feu sont appliquées dans le bon ordre<br>
* L’IP/le sous-réseau de la VM ou du périphérique correspond au bloc attribué<br>
  {% endhint %}

***


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.verge.io/knowledge-base/fr/networking/routing-l2-networks.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.