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

Network Engineering

583 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
[email protected]
5
Reacting to "It's the network" allegation (infosec.pub)
submitted 9 months ago by [email protected] to c/[email protected]
2 comments fedilink hide all child comments
 

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?

top 2 comments
sorted by: hot top controversial new old
[โ€“] slazer2au 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.

[โ€“] [email protected] 2 points 9 months ago

A little late, but here is what I usually do when a ticket like that comes in:

  1. Check monitoring. It's quick and easy to check so I'll look before even asking any clarifying questions. If there is a real network problem at a site, 95% of the time its going to show up on our monitoring dashboard. Everything from ISP outages to device failures show up here.
  2. Ask for more details about what they are trying to do. What is the goal? What are you doing? What is happening? What should be happening? When was the last time it worked?
  3. Based on those details, I can usually put together a good guess as to what might be going on, so i'll test that theory out and see if i'm right.