La Fibre
Datacenter et équipements réseaux => Équipements réseaux => 
WiFi => Discussion démarrée par: corrector le 28 juin 2012 à 15:10:59
-
Je voudrais pouvoir basculer de façon transparente de l'une connexion Ethernet Wifi à une connexion classique, sans interruption.
En fait il faudrait voir les deux cartes comme une seule.
Savez-vous comment faire?
-
Sous Linux, tu peux faire un agrégat actif-passif sur les deux interfaces :
http://techpatterns.com/forums/about1327.html (http://techpatterns.com/forums/about1327.html)
-
J'ai oublié de préciser que c'était avec la Freebox v5.
Est-ce que c'est possible d'apparaitre comme un seul périphérique Ethernet?
-
J'ai oublié de préciser que c'était avec la Freebox v5.
Et alors ?
-
Je voudrais pouvoir basculer de façon transparente de l'une connexion Ethernet Wifi à une connexion classique, sans interruption.
ratatouille:~# ping -c 30 -i 0.2 neufbox
PING neufbox (192.168.1.1) 56(84) bytes of data.
64 bytes from neufbox (192.168.1.1): icmp_req=1 ttl=64 time=0.373 ms
64 bytes from neufbox (192.168.1.1): icmp_req=2 ttl=64 time=0.335 ms
64 bytes from neufbox (192.168.1.1): icmp_req=3 ttl=64 time=0.374 ms
64 bytes from neufbox (192.168.1.1): icmp_req=4 ttl=64 time=0.642 ms
64 bytes from neufbox (192.168.1.1): icmp_req=5 ttl=64 time=0.369 ms
64 bytes from neufbox (192.168.1.1): icmp_req=6 ttl=64 time=0.442 ms
64 bytes from neufbox (192.168.1.1): icmp_req=7 ttl=64 time=0.353 ms
64 bytes from neufbox (192.168.1.1): icmp_req=8 ttl=64 time=0.344 ms
64 bytes from neufbox (192.168.1.1): icmp_req=9 ttl=64 time=0.344 ms
64 bytes from neufbox (192.168.1.1): icmp_req=12 ttl=64 time=0.989 ms
64 bytes from neufbox (192.168.1.1): icmp_req=13 ttl=64 time=0.988 ms
64 bytes from neufbox (192.168.1.1): icmp_req=14 ttl=64 time=1.04 ms
64 bytes from neufbox (192.168.1.1): icmp_req=15 ttl=64 time=0.958 ms
64 bytes from neufbox (192.168.1.1): icmp_req=16 ttl=64 time=1.02 ms
64 bytes from neufbox (192.168.1.1): icmp_req=17 ttl=64 time=1.19 ms
64 bytes from neufbox (192.168.1.1): icmp_req=18 ttl=64 time=1.09 ms
64 bytes from neufbox (192.168.1.1): icmp_req=19 ttl=64 time=1.03 ms
64 bytes from neufbox (192.168.1.1): icmp_req=20 ttl=64 time=0.911 ms
64 bytes from neufbox (192.168.1.1): icmp_req=21 ttl=64 time=1.00 ms
64 bytes from neufbox (192.168.1.1): icmp_req=22 ttl=64 time=2.55 ms
64 bytes from neufbox (192.168.1.1): icmp_req=23 ttl=64 time=1.82 ms
64 bytes from neufbox (192.168.1.1): icmp_req=24 ttl=64 time=0.955 ms
64 bytes from neufbox (192.168.1.1): icmp_req=25 ttl=64 time=1.68 ms
64 bytes from neufbox (192.168.1.1): icmp_req=26 ttl=64 time=0.938 ms
64 bytes from neufbox (192.168.1.1): icmp_req=27 ttl=64 time=0.974 ms
64 bytes from neufbox (192.168.1.1): icmp_req=28 ttl=64 time=0.369 ms
64 bytes from neufbox (192.168.1.1): icmp_req=29 ttl=64 time=0.335 ms
64 bytes from neufbox (192.168.1.1): icmp_req=30 ttl=64 time=0.326 ms
--- neufbox ping statistics ---
30 packets transmitted, 28 received, 6% packet loss, time 5834ms
rtt min/avg/max/mdev = 0.326/0.848/2.552/0.522 msDeux paquets perdus lors de la bascule RJ45 vers Wi-Fi, et aucun lors du retour en RJ45.
Moins de 500ms pour assurer le failover : c'est assez transparent pour toi ?
Est-ce que c'est possible d'apparaitre comme un seul périphérique Ethernet?
L'adresse MAC de l'interface réseau maîtresse* de l'agrégat est partagée par les autres interfaces, donc je serais tenté de penser que c'est bien le cas :
ratatouille:~# ifconfig | grep HWaddr
bond0 Link encap:Ethernet HWaddr 00:13:72:6a:97:c4
eth0 Link encap:Ethernet HWaddr 00:13:72:6a:97:c4
eth1 Link encap:Ethernet HWaddr 00:13:72:6a:97:c4* telle que définie dans la configuration ; l'agrégat utilisera cette adresse MAC même si l'interface physique correspondante est down.
-
Merci, c'est très intéressant!
-
Merci, je ne savais pas qu'on pouvait utiliser du bonding pour çà.
Pourquoi certaines interfaces Wi-fi sont vues en eth1 et d'autres en wlan0 ?
-
Merci, je ne savais pas qu'on pouvait utiliser du bonding pour çà.
Attention: certain switch ne vont pas apprécier ce style de manipulation.
Pourquoi certaines interfaces Wi-fi sont vues en eth1 et d'autres en wlan0 ?
Cela dépend du driver (ndiswrapper, wl).
Après, on peut renommer l'interface ....
-
Attention: certain switch ne vont pas apprécier ce style de manipulation.
D'après le Linux Ethernet Bonding Driver HOWTO (http://www.kernel.org/doc/Documentation/networking/bonding.txt), même les vieux switches acariâtres n'y verront que du feu :
The bond's MAC address is externally visible on only one port (network adapter) to avoid confusing the switch.
Quand j'ai testé une configuration identique sur mon NAS avec deux interfaces filaires, le vieux switch 10/100 sur lequel elles étaient toutes deux connectées l'a en tout cas très bien pris.
-
Si tu as un switch configuré en sticky (et max mac=1) sur les 2 ports, une violation va remonter (et suivant la politique: isolation dans la vlan poubelle, filtrage des paquets ayant la mac supplèmentaire, désactivation du port, ....) lors de la bascule d'un port à l'autre.
-
D'où le conseil :
The bond's MAC address is externally visible on only one port (network adapter) to avoid confusing the switch.
-
Ce qui ne marchera que si la deuxième carte n'a jamais envoyé de trame sur le port depuis le dernier reboot du switch.
-
Ce qui ne marchera que si la deuxième carte n'a jamais envoyé de trame sur le port depuis le dernier reboot du switch.
Donc ça marchera en gros dans tous les cas de figure, exception faite de celui où l'admin réseau aura cru nécessaire d'apprendre au switch à faire son travail correctement. ;D
-
Non, le sticky sert principalement à empêcher (par coupure après détection) la modification d'une infrastructure réseau.
Style: une salle où les machines sont en libre service et les cables réseau facilement accessibles.
-
est ce que quelqu'un pourrait expliquer un peu plus clairement le cas ou ça ne fonctionnerais pas?
j'ai fait un peu de théorie sur la sécu des réseaux en cours cette année mais on a pas trop approfondit et ça m'intéresse.
merci
ps je ne vois pas en quoi le sticky va remonter une violation ici... il n'est pas sensé enregistrer un nombre (que l'on définit) d'adresse (mac) et couper lorsque le nb est dépassé? si oui vus que c'est la même adresse mac ça ne pose pas de soucis? non?
-
Ben ça reste quand même un cas très particulier, bien tordu, en tout cas bien loin de la brave Freebox de corrector (et du matériel grand public, en général).
Et c'est tout de même par décision de l'administrateur réseau que ça merdoiera potentiellement (@butler_fr : l'adresse MAC ne montant que sur l'interface active de l'agrégat, si quelqu'un pique le port de l'interface en attente alors que celle-ci n'est jamais passée active depuis le dernier reboot du switch, il s'appropriera le jeton ; enfin, c'est ce que je crois comprendre.)
Surtout que l'intérêt d'appliquer ça à un équipement connecté en permanence (ce que suppose cette restriction, si je ne m'abuse), ben je vois pas bien : si j'avais deux interfaces filaires à brancher de façon permanente, je privilégierais un mode actif-actif (LACP).
Pas fait chez moi avec mon NAS parce que mon switch ne supporte pas LACP, mais sur un Cisco ...
Edit : c'est pas "collector", c'est "corrector".
-
Merci, je ne savais pas qu'on pouvait utiliser du bonding pour çà.
Pareil, je pensais que bonding = config symétrique de deux switchs face-à-face (du coup il fallait configurer la Freebox).
Pourquoi certaines interfaces Wi-fi sont vues en eth1 et d'autres en wlan0 ?
La racine du nom ("eth", "wlan") est proposé par le driver et le cœur de la couche réseau numérote automatiquement. Ce qui fait que le nom des périphériques peut varier selon l'ordre de création (souvent l'ordre de chargement des drivers). J'ai notamment vu un linux qui numérotait différemment après le démarrage ou la sortie de veille profonde.
Je pense qu'il faut absolument éviter la numérotation automatique, et toujours renommer les interfaces Ethernet sous linux dès qu'il y en a plus d'une.
-
ps je ne vois pas en quoi le sticky va remonter une violation ici... il n'est pas sensé enregistrer un nombre (que l'on définit) d'adresse (mac) et couper lorsque le nb est dépassé? si oui vus que c'est la même adresse mac ça ne pose pas de soucis? non?
La désactivation du port par le sticky produit une trap snmp.
Je pense qu'il faut absolument éviter la numérotation automatique, et toujours renommer les interfaces Ethernet sous linux dès qu'il y en a plus d'une.
La plupart des distributions linux utilise udev pour stabiliser le nom des interfaces (le fameux /etc/udev/rules.d/70-persistent-net.rules)
# USB device 0x0525:0xa4a2 (usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1f:11:00:12:34", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="dmz"
signifie toutes cartes réseau ethernet ayant la MAC 00:1f:11:00:12:34 sera renommé dmz.
-
Pareil, je pensais que bonding = config symétrique de deux switchs face-à-face (du coup il fallait configurer la Freebox).
C'est LACP (802.3ad) qui nécessite une configuration symétrique pour pouvoir fonctionner, et qui est cantonné - au moins sous Linux - à des interfaces possédant les mêmes propriétés (vitesse, duplex, ...).
Bien qu'étant également utilisé pour implèmenter LACP, le pilote bonding (littéralement : "collage") de Linux n'y est pas limité.
C'est en fait un truc assez générique à la base, chargé de réunir plusieurs interfaces réseau en un ensemble (donc de les agréger, stricto sensu).
La désactivation du port par le sticky produit une trap snmp.
La question n'était pas tant de savoir comment le blocage allait être signalé, que de comprendre pourquoi (dans quelles circonstances) il se produirait.
-
La question n'était pas tant de savoir comment le blocage allait être signalé, que de comprendre pourquoi (dans quelles circonstances) il se produirait.
Après activation du sticky sur un port, tu configure le nombre de MAC autorisé (généralement 1).
Le switch stocke et autorise ce nombre de MAC. Dés que tu dépasse, la politique configuré s'applique.
La documentation chez Cisco qui explique le mécanisme. (http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/25ew/configuration/guide/port_sec.html)
-
ok c'est ce que j'avais retenu de mes cours
mais du coup dans ce cas la ça ne devrait pas faire une violation si? (pas de changement de mac adresse).
-
C'est ce que j'ai essayé d'expliquer à thenico quelques messages plus haut.
Des images valant mieux qu'un discours, l'état de la MAC address table sur mon switch pour les deux ports sur lesquels mon NAS est connecté :
(https://lafibre.info/images/bistro/201206_switch_seb_port8.png)
(https://lafibre.info/images/bistro/201206_switch_seb_port9.png)
Il n'y a aucune adresse MAC qui remonte sur le port 9, celui de l'interface standby.
Par conséquent, à moins que quelqu'un ne vienne physiquement piquer ce port pour s'y brancher, ou que l'interface remue la queue au démarrage du serveur avant que l'agrégat soit monté, je ne vois pas vraiment de raison pour que le switch refuse de basculer l'adresse MAC de l'agrégat dessus.
-
que l'interface remue la queue au démarrage du serveur avant que l'agrégat soit monté, je ne vois pas vraiment de raison pour que le switch refuse de basculer l'adresse MAC de l'agrégat dessus.
Voila ce qui pourrait déclencher la violation.
Après, oui, le netadmin ne devrait pas mettre de port-security sur ces branchements.
Mais c'est déjà arrivé ce genre de surprise ...
-
La plupart des distributions linux utilise udev pour stabiliser le nom des interfaces (le fameux /etc/udev/rules.d/70-persistent-net.rules)
# USB device 0x0525:0xa4a2 (usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1f:11:00:12:34", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="dmz"
signifie toutes cartes réseau ethernet ayant la MAC 00:1f:11:00:12:34 sera renommé dmz.
Mouais, modifier un fichier dans /etc/? Bof.
Je préfère la méthode déglingos : les fichiers de config sont dans /usr/src/linux/.