fr:rapports:2023:11-25 []

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
# 2023/11/25 (Neutriton VRF + refonte réseau)

* [Réunion précédente](https://wiki.neutrinet.be/fr/rapports/2023/09-24)
* [Pad de la réunion](https://doc.neutrinet.be/hub-infra-2023-11-25)

Heure de début : 14h30

Présences : 

- HgO
- Célo
- Tharyrok

## Météo

*Moment informel durant lequel on exprime **en peu de mots** comment on se sent et si on a une attente forte pour la réunion.*
**Ce n'est pas un moment de discussion mais d'expression individuelle et ce n'est pas obligatoire :-)**

### Attente(s) forte(s)

*Si l'une ou l'autre personne exprime une attente forte, merci de vous en occuper en priorité ou de la noter dans le hub ou dans un point approprié.*

## Neutriton VRF

### Virtual routing and forwarding

Virtual routing and forwarding (VRF) est une technologie dans le domaine des réseaux informatiques qui permet à plusieurs instances d'une table de routage de coexister dans le même routeur en même temps. (Merci Wikipedia)

Il faut comprendre qu'au sein d'une même instance, on a plusieurs tables de routage qui ne se parlent pas entre elles. Et on doit déterminer à partir des vlan et des interfaces sur quelle table de routage cela arrive.

### GNS3

On va tester VRF avec [GNS3](https://www.gns3.com). Pour l'installer il y a deux partie, la gui et le serveur.

Comme dépendance nous allons donc avoir besoin de:

 - gns3-gui
 - gns3-serveur
 - wireshark
 - libvirt
 - dynamips
 - vpcs
 - ubridge

Activé la partie serveur : `sudo systemctl enable --now gns3-server@{USER}`

Activé la partie par default de libvirt : `sudo virsh net-start default`
Pour garder le reseau de libvirt apres le reboot : `sudo virsh net-autostart default`
Ce qui devrait créer l'interface `virbr0`

Ce rajouter les droit de wireshark : `sudo usermod -aG wireshark {USER}`

### Premiers pas avec GNS3

#### Importation du projet

File > Import portable project > gns3-neutriton-vrf-part1.gns3project

#### Espace de travail

Au centre, on voit notre espace de travail. 
Sur la barre du haut, il y a certains outils, comme le manage snapshot qui permet de créer un instantanné du projet, ou le "console to all devices" qui permet de lancer autant de terminaux qu'il y a de VM. On peut démarrer / éteindre, etc. les VMs. On a des éléments cosmétiques à la fin.

Sur la colonne de gauche, on encore d'autres outils. Le premier permet de voir des routeurs, mais là on n'a rien pour le moment. La plupart des routeurs étant propriétaires, il faut aller trouver les images sur le dark web.

Le deuxième permet d'avoir la liste des switches, qui sont des éléments simulés.

La troisième, c'est les "end devices". On a "cloud", qui est un bridge vers une de nos interfaces réseaux physiques. On a aussi NAT c'est un peu différent, car cela va utiliser directement l'interface de libvirt libvbr0. Cela permet d'être agnostique sur à peu prêt toutes les configs. Et enfin, VPCS est un petit ordinateur qui est simulé. On peut aussi importer des VMs, et c'est à cet endroit-là qu'elles apparaissent.

Le dernier bouton permet de lier les éléments. On peut cliquer par exemple sur le switch Routing, ce qui nous montre la liste des interfaces réseaux. En rouge c'est ce qui est libre, donc on en choisit une. Puis on clique sur Management, et pareil on prend une interface en rouge.

Pour supprimer un lien, on clique dessus quand il est surligné en rouge. C'est pas clair qu'il est sélectionné... Mais il l'est ! Et on appuie sur Delete.

Maintenant on va appuyer sur Start all Devices, et là tout devient vert, c'est Noël ! :christmas_tree: 

#### Configuration du terminal

On va double cliquer sur l'ordinateur Transit pour ouvrir un terminal. Il se peut que ça échoue car GNS3 utilise xterm par défaut. On configure le bon terminal Edit > Preferences > General > Console applications. Et là on clique sur Edit et normalement GNS3 nous propose une chiée de terminaux. Nous on va prendre KDE Konsole parce que TMTC.

Quand on passe la souris longtemps sur Transit, on voit les détails de chaque interface (eth0 connected to NAT par ex). 

### Sans VRF

A gauche des petites machines, on a les sous-réseaux utilisés dans GNS3. On peut les comparer au réseaux utilisés chez Neutrinet.

IP WAN (les IP annoncée sur les internets): 
fd5b:b35b:b602::/64
203.0.113.0/24

IP Routing (le reseau qui sert a faire des sessions bgp en interne)
fd02:467a:d300::/64
169.254.0.0/24

IP Management (le reseau qui sert de gestion)
fdf0:265c:b23c::/64
10.0.0.0/24

On a une config BGP très minimaliste.

Dans le terminal, avec `cat /etc/bird.conf` on voit qu'une default gateway est poussée à la VM edge avec bgp. Et avec `cat /etc/nftable.nft` elle fournit de l'accès internet à edge.

Si on ouvre la VM membre (cela pourrait être un VPS, une connexion internet, une brique), on ne voit qu'une seule interface réseau.

On peut faire un traceroute depuis la mv membre.
```
members:~# traceroute -I -n 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 46 byte packets
 1  203.0.113.129  0.962 ms  0.218 ms  0.228 ms (la gw de la machine members -> bras)
 2  203.0.113.1  0.509 ms  0.377 ms  0.364 ms (l'ip de la vm edge)
 3  198.51.100.1  0.717 ms  0.537 ms  0.507 ms (l'ip de la VM de transit)
 4  192.168.122.1  0.781 ms  0.638 ms  0.622 ms (l'ip de virbr0)
 5  *****
```
Entre 1, 2 et 3 on ne voit pas les IPs du réseau de routage. Quelle est donc cette magie ?

On va s'intéresser à la machine BRAS qui est le dernier équipemement entre le réseau DSL / coax, etc. du fournisseur et son propre réseau local. La différence avec un routeur classique ? C'est plus que ça, ça fait aussi de l2tp, pppoe, ... qui sont des protocole utiliser pour la collecte.

On peut ouvrir la VM BRAS (Broadband remote access server) et faire un ip a. L'IP qu'on voit dans le traceroute est celle de eth1

Si on fait `ip route show`
```
bras:~# ip r s
default via 168.254.0.1 dev eth0 proto bird src 203.0.113.5 metric 32 
10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.15 
168.254.0.0/24 dev eth0 proto kernel scope link src 168.254.0.5 
168.254.0.0/24 dev eth0 proto bird scope link src 203.0.113.5 metric 32 
203.0.113.5 dev lo proto bird scope link src 203.0.113.5 metric 32 
203.0.113.128/25 dev eth1 proto kernel scope link src 203.0.113.129 
203.0.113.128/25 dev eth1 proto bird scope link src 203.0.113.5 metric 32 
```
La partie intéressante est le `src 203.0.113.5`. 

C'est l'adresse qu'on a sur l'interface de loopback : 203.0.113.5/32

C'est ce qu'on fait sur les routeurs pour utiliser cette IP source pour tous les paquets qui sortent de la machine. Donc la default route apprise par edge via bgp va annoncer comme IP source 203.0.113.5 (qui est son IP sur le grand internet). Et l'IP 168.254.0.1 mène à edge.

En fait, entre edge et bras, on utilise l'adresse ip en 168.254.0.1 mais on ajoute dans les paquets l'info que l'adresse source est la 203.0.113.5.


la partie bgp responsable du sourcing est : 

```
protocol kernel kernel_v6 {
   scan time 60;

   ipv6 {
      import none;     # on n'importe aucune route qui vient du kernel
      export filter {  # on export des route de la mib vers le kernel
          krt_prefsrc = my_krt_prefsrc_v6; # on indique la source a utiliser
          accept;
      };
   };
}
```

protocol kernel indique qu'on va parler avec le kernel.

bird a une table reoutage interne qu'on appelle la "RIB". On se base toujours de ce point de vue pour tout ce qui est import / export, entrée / sortie.

Donc avec import none, cela signifie qu'aucune route n'est importée dans la RIB.

Export : on prend les routes de la rib, et on les exporte vers le protocole qui est en train d'être configuré, ici protocole kernel. Donc on vient ajouter des routes au kernel.

C'est pourquoi ici krt_prefsrc se configure en export. Cela dit d'ajouter ces infos quand on utilise le kernel.


NB : si on modifie la config de bird, on doit le relancer. Les machines sont les plus légères possibles, elles n'ont pas systemd, donc on doit faire ```/etc/init.d/bird restart```

Maintenant on va faire un traceroute vers l'IP de members depuis transit :
```
transit:~# traceroute -I -n 203.0.113.200
traceroute to 203.0.113.200 (203.0.113.200), 30 hops max, 46 byte packets
 1  198.51.100.2  0.488 ms  0.272 ms  0.215 ms   -> edge
 2  203.0.113.5  0.486 ms  0.344 ms  0.331 ms    -> bras
 3  203.0.113.200  0.618 ms  0.478 ms  0.462 ms  -> membres
```

Donc dans le sens de membre -> transit, l'IP qu'on a c'est celle de l'interface réseau sur laquelle le paquet est arrivée, donc la 203.0.113.129. CF ligne 108

Dans le sens transit -> membre, c'est l'IP qui est sur la lo (203.0.113.5), parce qu'elle vient du réseau de routage.

Sur la VM, on ping ensuite l'IP 10.0.0.15 :cry: cela répond ! Or, cette IP provient d'une VM dans le réseau de Management, mais ce réseau est réservé aux sysadmin de l'association :scream: Donc on n'a pas envie que des membres puissent y accéder...

En creusant un peu, on voit que c'est l'IP de BRAS. Il faudrait faire en sorte que BRAS ne permette pas d'accéder à cette route.

Pourquoi est-ce qu'on attend le sous réseau 10.0.0.0/24 ? La VM membres a une default GW vers bras, dans la table de routage de bras il y a le reseau 10.0.0.0/24, donc bras fait son travail de routage.

Bref, on peut dire que les bras nous en tombent...

On peut reproduire la même chose avec la vm transit. Si on rajoute une route vers le 10.0.0.0/24, on va avoir le même comportement : 

```
transit:~# ip route add 10.0.0.0/24 via 198.51.100.2 # l'ip de edge
transit:~# ping 10.0.0.11 # l'ip de edge dans le réseau management
PING 10.0.0.11 (10.0.0.11): 56 data bytes
64 bytes from 10.0.0.11: seq=0 ttl=64 time=0.593 ms
64 bytes from 10.0.0.11: seq=1 ttl=64 time=1.451 ms
```

C'est pas top en terme de sécurité…

On pourait mettre des regles de firewall, mais on aurait un indice sur les ip internet car elle ne repondra pas un unreachable mais juste aucune réponse. Avoir un unreachable c'est l'equivalent de /dev/null

C'est en raison de ce problème que Neutrirock Tharynet a commencé à s'intéresser aux VRF.

### Avec VRF

On va ouvrir la 2ème partie de l'atelier. On ouvre la VM edge, et on fait un ip a (ne pas confondre avec la bière).

On voit qu'on a une interface `vrf-mgmt` : 

```
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet 203.0.113.1/32 scope global lo
       valid_lft forever preferred_lft forever
    inet6 fd5b:b35b:b602::1/128 scope global 
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 0c:0c:65:b1:00:00 brd ff:ff:ff:ff:ff:ff
    inet 198.51.100.2/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fdca:d8ed:4e84::2/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::e0c:65ff:feb1:0/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 0c:0c:65:b1:00:01 brd ff:ff:ff:ff:ff:ff
    inet 168.254.0.1/24 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fd02:467a:d300::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::e0c:65ff:feb1:1/64 scope link 
       valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vrf-mgmt state UP group default qlen 1000
    link/ether 0c:0c:65:b1:00:02 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.11/24 scope global eth2
       valid_lft forever preferred_lft forever
    inet6 fdf0:265c:b23c::11/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::e0c:65ff:feb1:2/64 scope link 
       valid_lft forever preferred_lft forever
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 0c:0c:65:b1:00:03 brd ff:ff:ff:ff:ff:ff
    inet 203.0.113.17/28 scope global eth3
       valid_lft forever preferred_lft forever
    inet6 fd5b:b35b:b602:0:4::1/70 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::e0c:65ff:feb1:3/64 scope link 
       valid_lft forever preferred_lft forever
6: vrf-mgmt: <NOARP,MASTER,UP,LOWER_UP> mtu 65575 qdisc noqueue state UP group default qlen 1000
    link/ether 02:94:bb:f1:a4:b9 brd ff:ff:ff:ff:ff:ff
    inet 127.0.0.1/8 scope host vrf-mgmt
       valid_lft forever preferred_lft forever
    inet6 ::1/127 scope host 
       valid_lft forever preferred_lft forever
```

On voit sur la ligne de l'interface 4: eth2 `master vrf-mgmt` ce qui signifie que cette interface la est dans le vrf mgmt.

Si on essaie de pinguer la VM firewall sur 10.0.0.1, ça ne répond pas ! Ah ah ! :smiling_imp: 

Si on fait : 
```
edge:~# ip vrf exec vrf-mgmt ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: seq=0 ttl=64 time=1.470 ms
64 bytes from 10.0.0.1: seq=1 ttl=64 time=1.617 ms
^C
--- 10.0.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 1.470/1.543/1.617 ms
```

Pour executer une commande dans un vrf c'est : ip vrf exec {VRF_NAME} {COMMAND}

Si on va sur la VM members, pareil l'IP 10.0.0.15 (BRAS dans le réseau management) ne répond pas. Mais là on n'a pas accès à la VRF mgmt ! Elle se trouve sur la VM Bras. On est donc bien en sécurité :relieved:

Pour chaque VM dans le réseau management, la VRF est configurée.

Sur les configurations précises, on ne s'y attardera pas ici parce que c'est différent sur du Alpine et du Debian.

```
edge:~# ip route show table 40 # 40 car c'est la table 40 qui est le vrf mgmt
10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.11 
local 10.0.0.11 dev eth2 proto kernel scope host src 10.0.0.11 
broadcast 10.0.0.255 dev eth2 proto kernel scope link src 10.0.0.11 
127.0.0.0/8 dev vrf-mgmt proto kernel scope link src 127.0.0.1 
local 127.0.0.1 dev vrf-mgmt proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev vrf-mgmt proto kernel scope link src 127.0.0.1 
```

Si l'on fait un simple ip r s, on voit qu'on n'a plus du tout les IP de management :

```
edge:~# ip r s
default via 198.51.100.1 dev eth0 proto bird src 203.0.113.1 metric 32 
168.254.0.0/24 dev eth1 proto kernel scope link src 168.254.0.1 
168.254.0.0/24 dev eth1 proto bird scope link src 203.0.113.1 metric 32 
198.51.100.0/24 dev eth0 proto kernel scope link src 198.51.100.2 
198.51.100.0/24 dev eth0 proto bird scope link src 203.0.113.1 metric 32 
unreachable 203.0.113.0/24 proto bird src 203.0.113.1 metric 32 
203.0.113.1 dev lo proto bird scope link src 203.0.113.1 metric 32 
203.0.113.5 via 168.254.0.5 dev eth1 proto bird src 203.0.113.1 metric 32 
203.0.113.16/28 dev eth3 proto kernel scope link src 203.0.113.17 
203.0.113.16/28 dev eth3 proto bird scope link src 203.0.113.1 metric 32 
203.0.113.128/25 via 168.254.0.5 dev eth1 proto bird src 203.0.113.1 metric 32 
```

## Refonte réseau

Dans la 42ème refonte du réseau de Neutrinet, l'idée est de mettre le réseau de management par défaut, et de mettre le reste dans une VRF routing.

Donc ce qui était dans lo doit être porté par la VRF routing.

Dans `/etc/network/interfaces` on voit comment on définit la VRF routing.
```
auto routing
iface routing
	address 127.0.0.1/8
	address ::1/128
	address 80.67.181.0/32
	address 2001:913:1000:100::/128
	vrf-table 1011

auto ens3
iface ens3 inet static
	address 62.112.29.67/31
	address 2a00:1528:3201:5::22/126
	vrf routing
```
On choisit la VRF table entre 1000 et 65000, donc c'est arbitraire.


Du coup dans bird on doit aussi utiliser les vrf : 
```
root@edge-verixi-01:~# cat /etc/bird/conf.d/10_direct.conf 
protocol direct {
    ipv4;
    ipv6;
    vrf "routing";

    interface "-ens5", "*";
}
```

Si on regarde une session bgp on retrouve la spécification du vrf : 
```
root@edge-verixi-01:~# cat /etc/bird/peers/upstreams/private_6696_verixi.conf
protocol bgp private_verixi_v4 {
   neighbor 62.112.29.66 as 6696;
   local as my_asn;
   vrf "routing";
   description "[private] Verixi (6696)";

   default bgp_local_pref 100;

   ipv4 {
      import filter private_transit_verixi_import_v4;
      export filter private_transit_verixi_export_v4;

      next hop self;
   };
}
```

Donc on indique à Bird qu'il doit regarder dans la VRF routing pour rajouter les routes, sinon il ne verra même pas les IPs !

Si on regarde les port d'ecoute : 
```
root@edge-verixi-01:~# ss -lptn
State     Recv-Q    Send-Q         Local Address:Port       Peer Address:Port   Process                                                                         
LISTEN    0         128                  0.0.0.0:22              0.0.0.0:*       users:(("sshd",pid=320,fd=3))                                                  
LISTEN    0         8            0.0.0.0%routing:179             0.0.0.0:*       users:(("bird",pid=322,fd=10))                                                 
LISTEN    0         128                     [::]:22                 [::]:*       users:(("sshd",pid=320,fd=4))                                                  
LISTEN    0         8               [::]%routing:179                [::]:*       users:(("bird",pid=322,fd=8))   
```

On voit qu'il y a `%routing` sur le port d'écoute. Le `%` signifie que c'est lié à une interface en particulier, ici la VRF.


Pour voir les routes porté par le vrf : 

```
root@edge-verixi-01:~# ip r s table routing | head -n10
unreachable default proto bird src 80.67.181.0 metric 32 
1.0.64.0/18 via 62.112.29.66 dev ens3 proto bird src 80.67.181.0 metric 32 
1.0.128.0/19 via 62.112.29.66 dev ens3 proto bird src 80.67.181.0 metric 32 
1.0.128.0/18 via 62.112.29.66 dev ens3 proto bird src 80.67.181.0 metric 32 
1.0.128.0/17 via 62.112.29.66 dev ens3 proto bird src 80.67.181.0 metric 32 
1.0.160.0/19 via 62.112.29.66 dev ens3 proto bird src 80.67.181.0 metric 32 
1.0.192.0/19 via 62.112.29.66 dev ens3 proto bird src 80.67.181.0 metric 32 
1.0.192.0/18 via 62.112.29.66 dev ens3 proto bird src 80.67.181.0 metric 32 
1.0.224.0/19 via 62.112.29.66 dev ens3 proto bird src 80.67.181.0 metric 32 
1.1.64.0/19 via 62.112.29.66 dev ens3 proto bird src 80.67.181.0 metric 32 
```

Sur la VM bgp-verixi-01 il y a exabgp (un simulateur de sessions BGP) avec sa conf dans `/etc/exabgp/exabgp.conf`, dedans sont configurées les IP a annoncées a Neutrinet. Ces IP vienne de la RIB de edge-01.

En gros, on exporte la RIB sur edge-01 de Neutrinet en prod, et il y a une manière de convertir en fichier de conf exabgp. On a retiré des ranges d'IP dont le prefix est en supérieur a /20 pour éviter d'avoir une full view (tout internet), ce qui ne serait pas super intéressant et est consommateur de ram.

On fait cela parce qu'on n'a pas accès à les données bgp de la machine de Verixi. On doit donc les simuler.

Pourquoi refond-t-on encore le réseau ?

Ce que cette refonte des réseau a de particulier ?

Il y a une VM par lien réseau qu'on a (Transit Verixi + NL-IX, BNIX, BelgiumIX), alors qu'actuellement on a deux edges, où sont répartis nos liens de transit et peering.

Du coup, par machine, on n'aura les routes que des liens réseaux concernés. Alors que maintenant, dans les edge, les liens réseaux sont mélangés. Cela devrait permettre d'y voir plus clair.

Si on part de la VM edge-BelgiumIX, elle a par défaut le réseau de management. Dans le VRF de routing, il n'y a que les IP accessibles depuis BelgiumIX, pas tout internet. 

Le réseau de management est géré par les pfsense, pour aller sur internet.

Les pfsense sont reliés aux VM core. Chaque core a une full view et peut accéder à tout internet.

Les sessions BGP se font sur les core et les edge. Les edge pour la bordure du réseau, les core pour tout le réseau. Les core récupèrent les infos des différentes machines edge et recomposent façon puzzle pour avoir la full view.

Pour le dire autrement, chaque edge a une partie de l'information (un bout d'internet, si on considère que ce sont des liens de peering) et les cores ont l'information complète (full view).

Pour tout membre ou toute personne connectée dans la baie, on va faire un VLAN pour connecter la machine au core. On aura a chaque fois une IP VIP en fe80::1 pour le v6 et pour le v4 cela sera l'ip de l'inteface de routing.

Le truc, c'est qu'il va falloir mettre ça dans Ansible pour que cela aille se mettre sur chaque machine.

La question actuellement, et Tharynet Neutrirock n'est pas encore certain : 

Est-ce qu'on double les core ? Avec certaine core où seuls les humains configurent et d'autres où ce sont les machines qui configurent ? Mais cela implique plus de RAM car il faut dupliquer les full view.

Dans une logique d'économie d'IP, tous les edges auront la même IP exposée sur internet. Tant qu'on annonce notre range IP, on peut porter notre IP. De l'extérieur, si l'IP est annoncée par le edge BelgiumIX, cela arrivera sur le edge BelgiumIX. Si c'est le edge NLIX qui annonce le range, on arrivera sur le edge NLIX. 

Si cela arrive via BelgiumIX et que le chemin le plus court de retour est par NLIX, cela ne pose pas de souci. On reviendra par le chemin le plus court. On fait du routage assymétrique, mais c'est tout à fait possible. Verixi lui va annoncer un /24 de Neutrinet. On a un paquet qui arrive par un point d'entrée (par ex BelgiumIX, un des edge), c'est notre popote interne de voir par où il ressort (par ex. NL-IX).

Ce qui va simplifier la gestion au quotidien, c'est qu'on pourra faire nativement un jump sur le réseau management.

Pour le cas du VPN, actuellement on ne peut utiliser le cluster PostgreSQL qui se trouve dans Patata, car la VM VPN se trouve par défaut dans routing. La nouvelle utilisation des VRF fait qu'on devra lancer le VPN dans le VRF routing. Cela permet d'éviter que les tunnels VPN aient accès au réseau Patata, tout en accédant au cluster de base de données. Après est-ce qu'on veut faire ça ? ISPng est très legacy et n'est pas en HA, c'est pas très intéressant de l'avoir dans le cluster PostgreSQL. Mais cela nous donne des possibilités pour le futur.

Outre de nous donner plus de possibilités, cette refonte réseau nous permettra aussi d'améliorer certains points de notre infra : 

Actuellement, on a des soucis de routes. On passe par des endroits, on ne sait pas trop pourquoi. Les core vont éviter ça.

Ensuite, si un edge tombe, actuellement le temps de convergeance est très long... là ça va considérablement réduire.

Et si une VM core tombe, seule les gateway seront recalculées donc on gagne beaucoup de temps car tout ne sera pas recalculée.

Tout cela devrait être amélioré avec ce nouveau mode de fonctionnement.

## Prochaine réunion

Prochaine réunion : 02/12 à 11:00

Lieu : Chez Célo

Neutriton Alerting : 13/01/2024 à 14h au Caldarium

Garde-Pad : Célo

## Météo de fin

*Moment informel durant lequel on exprime **en peu de mots** comment, à titre personnel, la réunion a été vécue que ce soit positif ou négatif.*
*Si une ou plusieurs **tension est née** durant la réunion, il est peut-être nécessaire d'envisager l'une ou l'autre réunion pour y remédier.*

{{tag>infra neutriton}}