[Résolu] nombre de carte réseau max sous linux

[Dark26]

J'ai un petit problème avec mon pseudo blade center maison.

la configuration : 1 switch 5 ports Gigabit. 1 lien vers le serveur n°1 avec 1 cable ( gigabit) et sur les 4 ports restant, 4 cartes réseaux en bond sur le serveur 2 , histoire d'avoir du pseudo 400 mbits

le truc c'est que je n'arrive pas a avoir plus de 3 cartes sur mon bond.

si j'essaie de les monter en dehors du bond, c'est pareil , ça ne veut pas.....

le pire c'est que les cartes réseaux sont toutes detectee au au boot et au démarrage du kernel ( verif avec dmesg)

mais on dirait qu'il n'arrive pas à compter au desss de 3

la cret n°1 est une nvidia nforce 2 integré a la carte lère , et les 4 autres sont des intel e100

j'ai testé avec un realteck, et c'est pareil.

vous avez une idée ???

[Dark26]

réponse

http://linux.derkeiler.com/Mailing-Lists/D...0/msg01283.html

70-persistent-net.rules

i

# This file was automatically generated by the /lib/udev/write_net_rules

# program run by the persistent-net-generator.rules rules file.

#

# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x10de:0x0066 (forcedeth)

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:00:00:00:01", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x1229 (e100)

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:a0:c9:e5:c7:83", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x10ec:0x8139 (8139too)

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:fc:9e:e8:c1", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x10de:0x0066 (forcedeth)

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:6c:aa:67:ac", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x10de:0x0066 (forcedeth)

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:6c:8d:35:6b", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x10de:0x0066 (forcedeth)

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:00:00:00:11", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x8086:0x1229 (e100)

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:a0:c9:d1:65:91", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

# PCI device 0x8086:0x1229 (e100)

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:a0:c9:d1:5f:1a", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x8086:0x1229 (e100)

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:a0:c9:cc:3e:cc", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

~

~

~

il appelle toutes les cartes par le même nom cet ane....

on supprime toutes les lignes foireuses et on reboot

sinon si ça interesse quelqu'un les résultats 4 cartes réseau 100

en mode serveur :

NFS-SERVER:~# iperf -s

------------------------------------------------------------

Server listening on TCP port 5001

TCP window size: 85.3 KByte (default)

------------------------------------------------------------

[ 4] local 10.10.10.7 port 5001 connected with 10.10.10.10 port 60607

[ ID] Interval Transfer Bandwidth

[ 4] 0.0-10.0 sec 343 MBytes 288 Mbits/sec

et en mode client

iperf -c 10.10.10.10

------------------------------------------------------------

Client connecting to 10.10.10.10, TCP port 5001

TCP window size: 16.0 KByte (default)

------------------------------------------------------------

[ 3] local 10.10.10.7 port 43115 connected with 10.10.10.10 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-10.0 sec 434 MBytes 364 Mbits/sec

c'est pas mal..... ( dit l'auvergnat qui devrait mieux acheter une réseau gigabit )

[lorinc]

udev, c'est quand même une sacrée usine à bug et à merdum infernum...

[keneda212]

interessant tous ca (connaissait pas cette commande)

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-10.0 sec 1.06 GBytes 912 Mbits/sec

avec 2x5m de cable categorie 5

sinon interessante aussi ton idée d'utiliser plusieurs cartes. Ca fonctionne bien ce systeme ?

[madko]

ça a l'air de hyper marcher (comme dirait E.Leclerc) vu les perf. T'as utilisé quel mode pour le bonding? le switch il doit gerer quelque chose ou c'est transparent? Parceque ça fait des lustres que j'y pense aussi à ça, mais bon jpense que mes dd vont pas suivre...

Sinon c'est quel distro qu'y a pas été foutu de voir plus de 3 cartes reseaux? parceque ya pas de limite...

[Dark26]

interessant tous ca (connaissait pas cette commande)

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-10.0 sec 1.06 GBytes 912 Mbits/sec

avec 2x5m de cable categorie 5

sinon interessante aussi ton idée d'utiliser plusieurs cartes. Ca fonctionne bien ce systeme ?

si tu as de la place sur ton switch

il y a 7 ou 8 mode possible pour le bond, est que cela marche mieux dans un sens que dans l'autre, car le pc lui même c'est par ou envoyer les paquets, par contre les autres pc ne voient qu'une adresse mac, et donc du coup c'est un peu plus le zouc.

je susi au boulot, et je n'ai plus pas l'adresse des différent mod, ce soir en rentrant....

le petit + c'est le failover, si une carte lache, ça fonctionne toujours ( enfin ça dépend du mode choisi ).

ça a l'air de hyper marcher (comme dirait E.Leclerc) vu les perf. T'as utilisé quel mode pour le bonding? le switch il doit gerer quelque chose ou c'est transparent? Parceque ça fait des lustres que j'y pense aussi à ça, mais bon jpense que mes dd vont pas suivre...

Sinon c'est quel distro qu'y a pas été foutu de voir plus de 3 cartes reseaux? parceque ya pas de limite...

je n'ai testé que le mod 1 (ou 0) je en sais plus, enfin celui qui ne fait pas que du secours...

mais le plus prometteur, c'est surement le 803.x ou un truc du genre, car il fait appel a une option du switch que mon dlink bas de gamme possède

mais bon hier pas eu le temps.

dans certains mods, il ne fait pas appel au switch

la distro c'est debian lenny, mais c'ets une histoire de udev qui nommé toutes mes cartes de la même façon....

c'est résolu.

[SnipX]

udev, c'est quand même une sacrée usine à bug et à merdum infernum...

Alors ça, je suis bien d'accord !!!!!!!! J'ai déjà eu plusieurs surprises avec udev !!

[Dark26]

http://www.cyberciti.biz/howto/question/st...river-howto.php

mode

Specifies one of the bonding policies. The default is

balance-rr (round robin). Possible values are:

balance-rr or 0

Round-robin policy: Transmit packets in sequential

order from the first available slave through the

last. This mode provides load balancing and fault

tolerance.

active-backup or 1

Active-backup policy: Only one slave in the bond is

active. A different slave becomes active if, and only

if, the active slave fails. The bond's MAC address is

externally visible on only one port (network adapter)

to avoid confusing the switch.

In bonding version 2.6.2 or later, when a failover

occurs in active-backup mode, bonding will issue one

or more gratuitous ARPs on the newly active slave.

One gratutious ARP is issued for the bonding master

interface and each VLAN interfaces configured above

it, provided that the interface has at least one IP

address configured. Gratuitous ARPs issued for VLAN

interfaces are tagged with the appropriate VLAN id.

This mode provides fault tolerance. The primary

option, documented below, affects the behavior of this

mode.

balance-xor or 2

XOR policy: Transmit based on the selected transmit

hash policy. The default policy is a simple [(source

MAC address XOR'd with destination MAC address) modulo

slave count]. Alternate transmit policies may be

selected via the xmit_hash_policy option, described

below.

This mode provides load balancing and fault tolerance.

broadcast or 3

Broadcast policy: transmits everything on all slave

interfaces. This mode provides fault tolerance.

802.3ad or 4

IEEE 802.3ad Dynamic link aggregation. Creates

aggregation groups that share the same speed and

duplex settings. Utilizes all slaves in the active

aggregator according to the 802.3ad specification.

Slave selection for outgoing traffic is done according

to the transmit hash policy, which may be changed from

the default simple XOR policy via the xmit_hash_policy

option, documented below. Note that not all transmit

policies may be 802.3ad compliant, particularly in

regards to the packet mis-ordering requirements of

section 43.2.4 of the 802.3ad standard. Differing

peer implementations will have varying tolerances for

noncompliance.

Prerequisites:

1. Ethtool support in the base drivers for retrieving

the speed and duplex of each slave.

2. A switch that supports IEEE 802.3ad Dynamic link

aggregation.

Most switches will require some type of configuration

to enable 802.3ad mode.

balance-tlb or 5

Adaptive transmit load balancing: channel bonding that

does not require any special switch support. The

outgoing traffic is distributed according to the

current load (computed relative to the speed) on each

slave. Incoming traffic is received by the current

slave. If the receiving slave fails, another slave

takes over the MAC address of the failed receiving

slave.

Prerequisite:

Ethtool support in the base drivers for retrieving the

speed of each slave.

balance-alb or 6

Adaptive load balancing: includes balance-tlb plus

receive load balancing (rlb) for IPV4 traffic, and

does not require any special switch support. The

receive load balancing is achieved by ARP negotiation.

The bonding driver intercepts the ARP Replies sent by

the local system on their way out and overwrites the

source hardware address with the unique hardware

address of one of the slaves in the bond such that

different peers use different hardware addresses for

the server.

Receive traffic from connections created by the server

is also balanced. When the local system sends an ARP

Request the bonding driver copies and saves the peer's

IP information from the ARP packet. When the ARP

Reply arrives from the peer, its hardware address is

retrieved and the bonding driver initiates an ARP

reply to this peer assigning it to one of the slaves

in the bond. A problematic outcome of using ARP

negotiation for balancing is that each time that an

ARP request is broadcast it uses the hardware address

of the bond. Hence, peers learn the hardware address

of the bond and the balancing of receive traffic

collapses to the current slave. This is handled by

sending updates (ARP Replies) to all the peers with

their individually assigned hardware address such that

the traffic is redistributed. Receive traffic is also

redistributed when a new slave is added to the bond

and when an inactive slave is re-activated. The

receive load is distributed sequentially (round robin)

among the group of highest speed slaves in the bond.

When a link is reconnected or a new slave joins the

bond the receive traffic is redistributed among all

active slaves in the bond by initiating ARP Replies

with the selected mac address to each of the

clients. The updelay parameter (detailed below) must

be set to a value equal or greater than the switch's

forwarding delay so that the ARP Replies sent to the

peers will not be blocked by the switch.

Prerequisites:

1. Ethtool support in the base drivers for retrieving

the speed of each slave.

2. Base driver support for setting the hardware

address of a device while it is open. This is

required so that there will always be one slave in the

team using the bond hardware address (the

curr_active_slave) while having a unique hardware

address for each slave in the bond. If the

curr_active_slave fails its hardware address is

swapped with the new curr_active_slave that was

chosen.

mon test a été effctue en mod 0

et je vais de ce pas tester avec le mod 4 : 802.3ad or 4

NFS-SERVER:~# iperf -s

------------------------------------------------------------

Server listening on TCP port 5001

TCP window size: 85.3 KByte (default)

------------------------------------------------------------

[ 4] local 10.10.10.7 port 5001 connected with 10.10.10.10 port 43335

[ ID] Interval Transfer Bandwidth

[ 4] 0.0-10.0 sec 342 MBytes 286 Mbits/sec

donc pas mieux dans ce sens

NFS-SERVER:~# iperf -c 10.10.10.10

------------------------------------------------------------

Client connecting to 10.10.10.10, TCP port 5001

TCP window size: 16.0 KByte (default)

------------------------------------------------------------

[ 3] local 10.10.10.7 port 45720 connected with 10.10.10.10 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-10.0 sec 444 MBytes 372 Mbits/sec

et la non plus----> donc je vais rester avec le mode 0 et ça ira très bien

edit en fait en mod 4 ça marche pas, ça ne va plus vite que du 100 :transpi/

[Dark26]

j'ai décider de vous faire marrer un peu , même si il n'y a rien de marrant

mon blade est en diskless pour la partie système, donc tout sur du NFS sur l'autre serveur .pas de disque systeme pas de swap....

configuration du bestiau : barton 2500 + avec 256 mo de ram et 3 disques durs, 2 x 500 Go et 1 x 750 Go le tout en sata

connexion avec aoe ( vblade ) disque dur chiffré + donc mon bond 0

en essayant de transférer des données sur le disque de 750 go par le réseau, ça bloque de partout ( des tiemout sur le nfs ) --> déja que j'avais du flasher le bios de la carte mère pour qu'il soit reconnu la il me fait des erreurs ata de partout.

Je crois que mon disque dur de 750 go rempli est en train de me claquer dans les pattes.

en testant le tranfert sur mes autres disques, la pas de problème .

ça démarre à environ 30 mo/s et puis ça sature à 9 / 10 mo/s apres 2 ou 3 secondes:keskidit:

tout simplement que le chiffrement + la partie gestion du vblade me bouffe 100% des ressources du coup je me suis fait chier pour rien, car même avec une seule carte réseau ça ferait exactement la même chose car le cpu n'arrive pas gérer le flo de données

ça serait tellement plus simple de mettre les disques dur dans des boitiers usb, qui soit dit en passant je possède déja

[madko]

t'as essayé sans le cryptage pour le fun? quoi que ça c'est normalement decrypté par ta blade nan? voir si c'est ça qu'est gourmand ou si c'est juste le aoe? Je sais qu'il existe des cartes réseaux acceleratrice pour le iSCSI peut etre que ça existe pour le AoE?? si ça coute pas un bras...

[Sandeman]

Le bonding marche généralement très bien sous Linux - on a bondé 2 CX4 (10 Gb/s) sur un serveur de sauvegarde, ça torche bien

2. A switch that supports IEEE 802.3ad Dynamic link

aggregation.

Most switches will require some type of configuration

to enable 802.3ad mode.

bien faire gaffe avec ça : des switchs Cisco le feront automatiquement, des switchs HP, non. Bilan, quand un collègue branche le serveur en bond sur les HP (comme il le faisait avec les Cisco)... juste une petite alerte spanning-tree. Et quand il a commencé à mettre du traffic (réplication DRBD) ... tout le backbone s'est effondré...