Comment Re:How many times .... (Score 2, Insightful) 33
Sure, the problem is probably not Machine X can't connect to Machine Y, and more likely to be VLAN 17 can't initiate a connection to VLAN 56 over port 8080, but maybe you're the only one at your company who needs to make that particular connection at that time.
And you call it in and the network engineer will ask some questions:
a1. Has this ever worked in the past? (they will always answer "yes")
a2. When was the last time you know it was working? (50% "yesterday" 50% "last week")
a3. Has anything changed on the boxes or were they moved? (100% no nothing same as always)
b1. Is this a new install? (95% of the time this will be the problem but they will only admit it 1% of the time)
But if your network has dozens of VLANs, multiple gateways and complex firewall rules, it very well could be a network issue that so far only you have experienced.
And the change control logs should IMMEDIATELY show you where the problem is, in that case.
In my example, if VLAN 17 and VLAN 56 are QA networks, there's a reasonable chance your network team won't give a shit and it'll take them a week to even take a look, so it's probably worthwhile as a sysadmin to make sure that A) Machine X is actually sending the data out the network interface and B) Machine Y isn't receiving the data and just discarding it.
That's the problem. Change control shows no changes on 17 or 56 in the last 6 months.
The alarm systems show no changes.
I can pull up the data on the ports X & Y are using in 30 seconds. No errors showing.
In another 30 seconds I can check all the stats for 17 & 56.
The network is SIMPLE! It really is. Troubleshooting a connection issue takes a few minutes at most.
In your example, the sysadmin will just say "the network is the problem" when the REAL PROBLEM is that the LATEST UPDATE of his app means it now listens on 443 instead of 8080.
And a quick Google search will bring up page after page of references to that just using the app name and the app version number.