FCoE : retour d'expériences ; FCoE et Linux

FCoE : retour d'expériences ; FCoE et Linux - Débats - Linux et OS Alternatifs

Marsh Posté le 15-03-2011 à 17:01:19    

Hello,  
 
 
Auriez vous déjà mis en place du FCoE  ? Quel a été votre retour ?  
Egalement si vous avez des liens/infos sur FCoE  avec ou sans Linux je suis preneur ;)
 
 
Merci d'avance !


Message édité par gug42 le 15-03-2011 à 17:01:37
Reply

Marsh Posté le 15-03-2011 à 17:01:19   

Reply

Marsh Posté le 15-03-2011 à 17:08:36    

drapal (moins de 10min après), ça m'intéresse :D

Reply

Marsh Posté le 15-03-2011 à 17:26:40    

Je fais une maquette sur le sujet en Juin sur du HP Flexfabric et du Nexus 4000 dans des bladecenter H.
 
Sinon aujourd'hui y a des références en prod et UCS ça fonctionne pas trop mal.


---------------
"Parceque toi tu fracasses du migrant à la batte de baseball, c'est ça ?" - Backbone-
Reply

Marsh Posté le 16-03-2011 à 09:45:22    

Salut,
 
Ce choix de HP Flexfabric et Nexus était murement choisis ou un peu au pif ?  Que vas tu mettre dans les lames comme carte ?
Pour les BladeH j'avais vu les BNT10gbps et les cartes intel 88599 (qui permettent de faire du sriov au besoins).
 
Je me méfie des "success strory" sur les sites des constructeurs ...
 

Reply

Marsh Posté le 16-03-2011 à 10:12:09    

Y a un appel d'offres serveur à lancer d'où le maquettage. Une partie de nos serveurs sont HP c7000, on compte y mettre des lames G7 pour utiliser les CNA, mais le contrat groupe étant avec IBM, on va tester les nexus 4000 dans les bladecenter. Au réseau on ne prend que du cisco de toute manière.
 
Mon avis perso : cisco a un gros train d'avance sur le sujet vu que les nexus 5000 ça fait 3 ans que ça existe. Les modules Flexfabric chez HP sont tout frais et y a un cross connect entre les deux (ceux qui ne plait pas à mes collègues du SAN). Y a pas mal de monde qui regarde les nexus 4000 dans mon entourage, puis avec la seconde génération d'équipements FCoE (nexus 5500) je pense que ça commence maintenant à être plutôt fiable.
 
Je ferai un retour ici une fois que ça aura été testé.


Message édité par dreamer18 le 16-03-2011 à 10:15:17

---------------
"Parceque toi tu fracasses du migrant à la batte de baseball, c'est ça ?" - Backbone-
Reply

Marsh Posté le 17-03-2011 à 10:37:34    

Ok merci !

 

Effectivement ca parle pas mal des cisco 4000 dans les Chassis.
Pour ma part, pour l'ethernet/IP, j'ai des BNT VFA 10Gbps qui fonctionnent bien.
A priori ils peuvent également faire du FCOE, soit directement en sortie de chassis avec un bridge FCF, soit en les connectant à un cisco 5000 qui réaliserait le bridge.


Message édité par gug42 le 17-03-2011 à 10:38:08
Reply

Marsh Posté le 17-03-2011 à 11:23:29    

ok, ça fait du FIP snooping ?


---------------
"Parceque toi tu fracasses du migrant à la batte de baseball, c'est ça ?" - Backbone-
Reply

Marsh Posté le 17-03-2011 à 13:22:29    

Oui.

 

Si j'ai bien compris ca sert à mettre automatiquement en oeuvre des ACL et à les propager sur les équipements FCF Bridge ? mais des ACL sur quoi ?


Message édité par gug42 le 17-03-2011 à 13:23:40
Reply

Marsh Posté le 17-03-2011 à 13:27:24    

C'est pour la QoS FCoE et la classe no drop non ? Comme le bridge "apprend" à la volée les id des VLANs FCoE, je suppose qu'il protège automatiquement ces vlans et mets en place la QoS qui va bien.


---------------
"Parceque toi tu fracasses du migrant à la batte de baseball, c'est ça ?" - Backbone-
Reply

Marsh Posté le 17-03-2011 à 14:10:07    

Citation :


FCoE Initialization Protocol (FIP) snooping is an FCoE feature. In order to enforce point-to-point
links for FCoE traffic outside the regular Fibre Channel topology, Ethernet ports used in FCoE can
be automatically and dynamically configured with Access Control Lists (ACLs).
Using FIP snooping, the VFSM examines the FIP frames normally exchanged between the FCF and
ENodes to determine information about connected FCoE devices. This information is used to create
narrowly tailored ACLs that permit expected FCoE traffic to and from confirmed Fibre Channel
nodes, and deny all other undesirable FCoE or FIP traffic.


 
 

Citation :


When FIP Snooping is enabled on a port, the switch automatically installs the appropriate ACLs to
enforce the following rules for FCoE traffic:
Ensure that FIP frames from ENodes may only be addressed to FCFs.
Flag important FIP packets for switch processing.
Ensure no end device uses an FCF MAC address as its source.
Each FCoE port is assumed to be connected to an ENode and include ENode-specific ACLs
installed, until the port is either detected or configured to be connected to an FCF.
Ports that are configured to have FIP snooping disabled will not have any FIP or FCoE related
ACLs installed.
Prevent transmission of all FCoE frames from an ENode prior to its successful completion of
login (FLOGI) to the FCF.
After successful completion of FLOGI, ensure that the ENode uses only those FCoE source
addresses assigned to it by FCF.
After successful completion of FLOGI, ensure that all ENode FCoE source addresses originate
from or are destined to the appropriate ENode port.
After successful completion of each FLOGI, ensure that FCoE frames may only be addressed to
the FCFs that accept them.
Initially, a basic set of FCoE-related ACLs will be installed on all ports where FIP snooping is
enabled. As the switch encounters FIP frames and learns about FCFs and ENodes that are attached
or disconnect, ACLs are dynamically installed or expanded to provide appropriate security.
When an FCoE connection logs out, or times out (if ACL timeout is enabled), the related ACLs will
be automatically removed.
FCoE-related ACLs are independent of manually configured ACLs used for regular Ethernet
purposes (see “Access Control Lists” on page 93). FCoE ACLs generally have a higher prior
 

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed