Suivant les utilisations, l'un est souvent plus rapide que l'autre mais l'autre n'est parfois pas dispo dans l'OS cilent ou serveur et ahhhhhhhhhhhhhhh
Bwef ... pour commencer un lien sympa de comparaison des fonctionnalités : http://www.helios.de/news/Newsletter/AF ... le-fr.html
LES gros PORTS
CIFS
-> NetBios-ssn 139
-> UDP 137, 138
-> TCP 445
AFP
-> TCP 548
NFS
-> TCP/UDP 111 (RPC 4.0 portmapper)
-> 892
-> TCP/UDP 2049 (NFSD)
-> TCP 1110 (Cluster Primaire)
-> UDP 1110 (Cluster Secondaire)
-> TCP/UDP 4045 NFS lock manager
... en construction
[TU] Protocoles CIFS / SMB / NFS / AFP - TCP / UDP ...
[TU] Protocoles CIFS / SMB / NFS / AFP - TCP / UDP ...
Hummmm.
De mon coté, pour que l'un de mes serveur Linux (sur une DMZ) puisse se connecter en NFS à ma baie NetApp, j'ai du ouvrir que 3 ports sur mon Firewall :
- 111
- 2049
- 4046
Si cela peut aider
De mon coté, pour que l'un de mes serveur Linux (sur une DMZ) puisse se connecter en NFS à ma baie NetApp, j'ai du ouvrir que 3 ports sur mon Firewall :
- 111
- 2049
- 4046
Si cela peut aider

- augur1
- Messages : 13167
- Inscription : ven. 12 janv. 2018 17:44
- Localisation : où tout est neuf et tout est sauvage
- Contact :
[TU] Protocoles CIFS / SMB / NFS / AFP - TCP / UDP ...
moui ... mais en quel protocole ?!Hummmm.
De mon coté, pour que l'un de mes serveur Linux (sur une DMZ) puisse se connecter en NFS à ma baie NetApp, j'ai du ouvrir que 3 ports sur mon Firewall :
- 111
- 2049
- 4046
Si cela peut aider
[TU] Protocoles CIFS / SMB / NFS / AFP - TCP / UDP ...
Dans un soucis de facilité, j'ai ouvert UDP & TCP.
Il est vrai que j'aurais du me pencher plus la dessus, mais toujours un manque de temps et de nombreuses missions.
Il est vrai que j'aurais du me pencher plus la dessus, mais toujours un manque de temps et de nombreuses missions.
[TU] Protocoles CIFS / SMB / NFS / AFP - TCP / UDP ...
dans le port tout est bon ...
- augur1
- Messages : 13167
- Inscription : ven. 12 janv. 2018 17:44
- Localisation : où tout est neuf et tout est sauvage
- Contact :
[TU] Protocoles CIFS / SMB / NFS / AFP - TCP / UDP ...
Je reprends un truc que je viens de creuser : VLan / IGMP
... de : https://lafibre.info/switch/gestion-des ... #msg139216
'IGMP proxy' sert surtout dans les routeurs quand on a du NAT notamment. Le routeur fait 'proxy' pour les clients NATés vis a vis de l'amont.
Dans les switch c'est plus rare , ca sert quand on a des VLANs différents non routés entre eux par exemple. Dans ce cas le switch va servir de proxy entre les clients sur un VLAN et l'amont qui est sur un autre VLAN.
Ca permet aussi de soulager l'amont quand on a beaucoup de clients car le proxy 'factorise' les requêtes d'abonnement/désabonnement et donc 100 clients derrière un proxy sont vu comme un seul par l'amont.
Avec le multicast les choses peuvent vite devenir compliquées et on s'embrouille facilement. Comme toujours en réseau il faut raisonner par couches et par 'tiers' (access , distribution, core):
IGMP est un protocol au dessus d'IP. Il ne sert qu'entre des clients et un routeur multicast donc en général sur le LAN uniquement. Au delà, en amont, vers les sources multicast (vidéos ou autres) , c'est d'autres protocoles qui sont utilisés comme par exemple PIM.
IP Multicast est de niveau 3 et pour fonctionner sur des switch Ethernet il existe un mapping vers des adresse Ethernet multicast (MAC multicast) de la couche 2 facon ARP comme avec les adresses IP unicast vers les adresses MAC classiques.
Par défaut tout switch va diffuser les adresses MAC multicast sur tout ses ports.
En utilisant IGMP Snooping un switch 'écoute' la couche 3 (IP donc) pour capter les messages IGMP et en fonction d'eux changer la façon dont il diffuse les adresses MAC multicast. IGMP Snooping est donc un mécanisme interne au switch qui ne concerne que le switch et sa facon dont il gere le mapping 3->2 pour le multicast d'IP.
Ce dessin de Wikipedia resume assez bien les 'tiers' et les couches:
[center]
[/center]
... de : https://lafibre.info/switch/gestion-des ... #msg139216
'IGMP proxy' sert surtout dans les routeurs quand on a du NAT notamment. Le routeur fait 'proxy' pour les clients NATés vis a vis de l'amont.
Dans les switch c'est plus rare , ca sert quand on a des VLANs différents non routés entre eux par exemple. Dans ce cas le switch va servir de proxy entre les clients sur un VLAN et l'amont qui est sur un autre VLAN.
Ca permet aussi de soulager l'amont quand on a beaucoup de clients car le proxy 'factorise' les requêtes d'abonnement/désabonnement et donc 100 clients derrière un proxy sont vu comme un seul par l'amont.
Avec le multicast les choses peuvent vite devenir compliquées et on s'embrouille facilement. Comme toujours en réseau il faut raisonner par couches et par 'tiers' (access , distribution, core):
IGMP est un protocol au dessus d'IP. Il ne sert qu'entre des clients et un routeur multicast donc en général sur le LAN uniquement. Au delà, en amont, vers les sources multicast (vidéos ou autres) , c'est d'autres protocoles qui sont utilisés comme par exemple PIM.
IP Multicast est de niveau 3 et pour fonctionner sur des switch Ethernet il existe un mapping vers des adresse Ethernet multicast (MAC multicast) de la couche 2 facon ARP comme avec les adresses IP unicast vers les adresses MAC classiques.
Par défaut tout switch va diffuser les adresses MAC multicast sur tout ses ports.
En utilisant IGMP Snooping un switch 'écoute' la couche 3 (IP donc) pour capter les messages IGMP et en fonction d'eux changer la façon dont il diffuse les adresses MAC multicast. IGMP Snooping est donc un mécanisme interne au switch qui ne concerne que le switch et sa facon dont il gere le mapping 3->2 pour le multicast d'IP.
Ce dessin de Wikipedia resume assez bien les 'tiers' et les couches:
[center]

- augur1
- Messages : 13167
- Inscription : ven. 12 janv. 2018 17:44
- Localisation : où tout est neuf et tout est sauvage
- Contact :
[TU] Protocoles CIFS / SMB / NFS / AFP - TCP / UDP ...
Par contre, avec switch Cisco /!\
Multicast Does Not Work in the same VLAN in Catalyst Switches
Only layer 2 communication is required, but if nodes are on different switches connected by an inter-switch link it may not work as expected, this is due to IGMP features which are enabled by default on some switches.
As a two switch configuration supported by a First Hop Resiliency Protocol (FHRP) such as HRSP, GLBP or VRRP, this could become a common challenge.
Note: for ICS 1.4 and 1.5 (H1/2013) the default multicast address is 239.192.1.1
corosync_mcast_addr=${corosync_mcast_addr:-"239.192.1.1”
For Cisco Catalyst the quick fix is:
[cpp]SWITCH# (config)#int vlan 30
SWITCH# (config-if)# ip pim sparse-dense-mode[/cpp]
This must be applied in the appropriate VLAN, it does not have to be applied to all VLANs.
The above example assume that VLAN 30 is the location for the Interplay Common Services “cluster” of nodes
The URL below contains more detailed explanation
http://www.cisco.com/en/US/products/hw/ ... a9df.shtml
Multicast Does Not Work in the same VLAN in Catalyst Switches
Only layer 2 communication is required, but if nodes are on different switches connected by an inter-switch link it may not work as expected, this is due to IGMP features which are enabled by default on some switches.
As a two switch configuration supported by a First Hop Resiliency Protocol (FHRP) such as HRSP, GLBP or VRRP, this could become a common challenge.
Note: for ICS 1.4 and 1.5 (H1/2013) the default multicast address is 239.192.1.1
corosync_mcast_addr=${corosync_mcast_addr:-"239.192.1.1”
For Cisco Catalyst the quick fix is:
[cpp]SWITCH# (config)#int vlan 30
SWITCH# (config-if)# ip pim sparse-dense-mode[/cpp]
This must be applied in the appropriate VLAN, it does not have to be applied to all VLANs.
The above example assume that VLAN 30 is the location for the Interplay Common Services “cluster” of nodes
The URL below contains more detailed explanation
http://www.cisco.com/en/US/products/hw/ ... a9df.shtml