 |
 |
Dear All At 11:00 today in the GridPP community there is an EVO meeting to discuss the LHCb issues (http://indico.cern.ch/conferenceDisplay.py?confId=95694 password is dteam ). It is a follow up meeting to one held two weeks ago (http://indico.cern.ch/conferenceDisplay.py?confId=93191 ) in which Brunel, Sheffield and Glasgow plus people from LHCb were involved. Since the impact is now seen to be wider, other sites are welcome to join the discussion, especially those where NAT is in use. Jeremy On 20 May 2010, at 09:43, Douglas McNab wrote: > Gridftp transfer issues > Brunel - NAT > QMUL - NAT > Sheffield - NAT > Liverpool - NAT > Bristol > Glasgow - NAT > Lancaster > > No problems: > Manchester - External IP > Oxford - External IP > Imperial - External IP > RAL - External IP > > I think we have a winner. Unfortunately, fixing this is not > straightforward. > > Cluster Monkey has a good description of gridftp issues with NAT's > on page two they state ... > > Most NAT devices are capable of translating the port numbers as > well. Currently, however, GT does not have this capability, and > therefore the port number on the internal machine on which a > particular service is listening must be the same as on the external > interface of the firewall. Thus, in the case of multiple machines > behind a single NAT device, each machine must have a unique port > range defined, and those ports must be forwarded to the appropriate > machine by the firewall. (GLOBUS_HOSTNAME will be the same for all > the machines, however.) > > This seems to be backed up by the NAT instructions from http://dev.globus.org/wiki/FirewallHowTo > Network Address Translation (NAT) > > Clients behind NATs will be restricted as described in #Allowed > Incoming Ports unless the firewall and site hosts are configured to > allow incoming connections. > > This configuration involves: > > • Select a separate portion of the ephemeral port range for each > host at the site on which clients will be running (e.g. 45000-45099 > for host A, 45100-45199 for host B, etc.). > • Configure the NAT to direct incoming connections in the port > range for each host back to the appropriate host (e.g., configure > 45000-45099 on the NAT to forward to 45000-45099 on host A). > • Configure the Globus Toolkit clients on each site host to use the > selected port range for the host using the techniques described in > Section . > • Configure Globus Toolkit clients to advertise the firewall as the > hostname to use for callbacks from the server host. This is done > using the GLOBUS_HOSTNAME environment variable. The client must also > have the GLOBUS_HOSTNAME environment variable set to the hostname of > the external side of the NAT firewall. This will cause the client > software to advertise the firewall's hostname as the hostname to be > used for callbacks causing connections from the server intended for > it to go to the firewall (which redirects them to the client). > Dug > > ---------- Forwarded message ---------- > From: Douglas McNab <[log in to unmask]> > Date: 19 May 2010 16:53 > Subject: NAT's > To: Testbed Support for GridPP member institutes <[log in to unmask] > > > > > Hi, > > I would like to find out which sites have NAT'd worker nodes and > which sites have their worker nodes with external IP's. > > in particular these sites: > > Brunel - NAT > QMUL > Sheffield - NAT > Liverpool > Bristol > Glasgow - NAT > Lancaster > Manchester > Oxford - External IP > > If you your site is listed above, please let me know so that I can > compile a list. > This relates to the ongoing upload issue LHCb is having from various > UK sites. > All the documentation and my investigations point towards GLOBUS and > NAT not really working well together. > This is pretty much a known fact. > > Regards, > > Dug > -- > ScotGrid, Room 481, Kelvin Building, University of Glasgow > tel: +44(0)141 330 6439 > > > > -- > ScotGrid, Room 481, Kelvin Building, University of Glasgow > tel: +44(0)141 330 6439