this post was submitted on 24 Jan 2024
5 points (85.7% liked)

Network Engineering

570 readers
1 users here now

All things enterprise network engineering, design, and architecture.

Rules

  1. No low effort posts
  2. No home networking topics
  3. No memes

founded 1 year ago
MODERATORS
 

So, every network engineer knows it: everyone else will blame the network and you have to prove them wrong.

There are multiple reason:

  • lack of knowledge
  • ignorance
  • passing on responsibility
  • laziness
  • ... There are more.

I am interested in how you react to 'The network is causing the problems' requests.

  • do you request certain information?
  • need an explanation?
  • what are you first steps?
  • do you have a runbook or some policy in place?

Without getting into too much detail, I request some or all of the following information before I start looking:

  • what are they trying to do? What is the desired outcome?
  • what is the error message? *(pref a screenshot!) *+ timestamp (for logs)
  • has it ever worked before?
  • since when isn't it working?
  • can you resolve domains?
  • Source Host > Destination Host:Port
  • Results of Ping + Powershell Test-NetConnection on Windows and Netcat on Linux (to test general connection, assuming TCP connection)

What I ask for and in what order depends on the person I am talking to. By the way, monitoring is my friend. If it says everything is fine, it usually is.

Side note Describing the actual proof that it is not the network depends heavily on the infrastructure and the problem, so this may be a discussion for another thread.


What are your first steps?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 3 points 9 months ago

I ask pretty much the same things, but if they are a repeat offender I will start refusing to accept the ticket and justify that with listing the previous tickets where that user complained about the network and it ended up being a fault on not on the network.