Lotus Notes client didn’t work at the Frensham Pond Hotel, when I stayed there.

Long story short

• Ports 80/443 worked, so I was able to “surf” the web.
• Port 1352 blocked

How did I know?

• I used nPing.exe, and this is what a failure looks like
  
• A successful nPing looks like this:
  
  (and your Lotus Notes client should work)

The fix?

• None, unfortunately.  The Hotel’s ISP blocked everything except ports 80 & 443.

nPing is part of the NotesConnect toolset and can be found via this weblink:
Testing TCP/IP connections with NotesCONNECT

Such as WAN link utilisation.

Users were complaining that network performance was slow across the 80M WAN link.  How did they know?  Citrix users mostly …

So I ask our telecommunications provider, “is our link congested?”

‘No, 60% utilisation.  Here’s a graph of the network performance:”

Can you see what’s wrong?  Well there’s a couple of things, it’s a sample image for example.  But if you knew we were running Netware 3 & 4, you’d expect to see IPX/SPX traffic.  Which were the protocol layers our users were mostly using.

“Where is it?”, I ask.

‘Oh, we don’t measure IPX/SPX traffic, it’s only IP.’

My estimate, based on running a network sniffer, was that IPX/SPX was using 30% of the WAN link.

My recommendations were:

• remove IPX/SPX
  (difficult, talking Netware 3 & 4 here)
• upgrading the WAN link.

“Reports that say that something hasn’t happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don’t know we don’t know.”  – Donald Rumsfeld

I’ve run into latency issues over the last 20 years, and in short, they’ve been

• X-Modem
• IBM SNA
• Citrix
• Windows Vista

X-modem

… was created in August 1977 to allow file transfers between Bulletin Board Systems.  Developed by Ward Christensen.  A simple protocol by design, which was it’s beauty and it’s downfall.  Didn’t work so well over satellite links with a latency of 300ms.  Relaxed X-modem was the workaround.

IBM SNA

… has a heartbeat of 2 seconds.  Miss the heartbeat and the link dies.  Which is what was happening in the remote community of Gove, in the Northern Territory.  Because of WAN congestion, and a tropospheric WAN link, mainframe terminals in Gove would drop out.  Reconfiguring the Gove Cisco switch to provide a local SNA heartbeat solved the problem.

Citrix

… curse of an idea I tell you.  In August 2003, Citrix sessions were dropping out at a remote site.  Citrix is very intolerant of WAN congestion (20ms).  So are the users who lose their Citrix sessions.  Given that a picture tells a thousand words, here’s what the network capture told us:

The RED lines indicate traffic inbound to the client site.
The BLUE lines are outbound traffic.
Both measured at the Cisco switch, so it didn’t tell us what the local LAN was doing.

The inbound red traffic indicated that our desktop management toolset was heavily utilising the line, after hours in particular (desktop patching).  The outbound blue traffic didn’t tell us much from the graph.  Further investigation, with a network sniffer, showed that 70 Citrix clients were communicating with a (remote) Citrix Server farm.  Now each Citrix client uses about 20k/s bandwidth, so 70 clients across a 128k WAN link just didn’t fit.  The answer was for the customer to increase the size of the WAN link, which they did.

Vista

I had drafted why the Vista file copy routine was broken, due I think, to latency issues, but Mark Russinovich explains it so much better, here.