The Grey Area of Customer Problems in ISP networks
When you run a network, you’ll hit this situation sooner or later. A customer buys a service, but the issue they are dealing with is not related to your network. It is theirs. Sometimes the cause is clear. It could be a bad route filter, a broken firewall rule, an odd NAT setup, or a design that worked months ago (or on another provider) but now creates problems. Packets reach your edge without issues. The control plane looks good. Everything works on your end, but the customer still cannot get things working. This is where things get tricky.
When It Is Clearly Not Your Problem
From a support standpoint, the answer seems simple. If the service works at the handoff point, it is not your problem. Many providers make this boundary clear.
You prove the circuit works.
You show that BGP sessions are established.
You verify traffic passes across the handoff.
Case closed.
In theory, this approach saves engineering time and keeps your team focused. Network teams already have plenty to do without fixing someone else’s firewall or routing issues. But in reality, things are rarely that simple. Customers often do not see the boundary the same way you do. They bought connectivity from you, so when something breaks, you are the one they call. And sometimes, they have a point.
The Operational Reality
Recently, I worked through a situation like this. A customer purchased IP transit through a client of mine. The contract’s dollar value was modest, but the network design behind it was a little out of the ordinary. The customer had spent months building a custom solution with their transport provider. By the time the service was live, they depended on it. Changing the setup was not something they could easily reverse. When the service went live they started having customers call and complain about slow Internet or non-working Internet.
What do you do in this situation? It worked on their old provider. Now they are blaming you. At that point, you have two choices.
Option 1: Draw the Boundary
You tell the customer the service is working as promised. You show proof and close the ticket. This saves your team’s time and keeps you from doing free consulting. But there are downsides.
Customers remember who helped them when they were in a bind. They also remember who told them to solve it themselves. Even if you are right, the relationship can suffer. You also need to show the customer that the problem is on their side. This can be challenging if the customer is not local.
Option 2: Work the Problem Together
The other choice is to step into the grey area and help look into the problem, even if it is not strictly your responsibility. This might include:
- Reviewing routing policies
- Looking at traceroutes and traffic paths
- Walking through BGP behavior
- Helping them reason through their design
As I said before, the customer was willing to pay for the extra help. That makes a big difference. Now you are not giving away free support—you are offering engineering services. The conversation shifts from “this is not our problem” to “we can help you fix it.”
What You Are Really Deciding
The real decision is not technical. It is strategic. You are balancing three things:
- Engineering time
- Customer relationship
- Long-term revenue potential
A small contract now might grow over time. Many networks expand slowly, and vendors who help during tough times often stay on. But you cannot let every support request turn into endless consulting. That leads to burnout and chaos. The key is knowing which cases are worth the extra effort.
A Simple Rule
I follow a simple rule. If the customer is reasonable, works with you, and is willing to pay for your time, it is usually best to help. Not because you must, but because good technical relationships grow stronger over time. If the customer wants endless help and ignores your advice, the answer is clear. Sometimes, the best response is still: the service is working as designed.
The Reality of Network Engineering
Network diagrams show clear boundaries, but real operations rarely do. Packets move across different domains, but problems do not stop at the edge router. Engineers often find themselves dealing with issues that cross company lines. That is just part of the job.
The real skill is knowing when you are fixing a problem together and when you are quietly becoming someone else’s network team.
What about the customer I mentioned before? It ended up being a tunnel they had for management participating in OSPF. It was not a problem with the other provider because the two segments of their network did not talk to each other. Once they started talking to each other it formed loops and caused traffic to go over the tunnel instead of the transport connection.
j2networks family of siteshttps://j2sw.com
https://startawisp.info
https://indycolo.net
#packetsdownrange #routethelight