Ruban Prasat Johnson is one of Inter.link’s Network Engineers and in this article he explains what he enjoys about his role, what he wished he knew earlier in his career, and how automation has helped networks.
As a Network Engineer, what does your typical day look like?
One thing I enjoy about network engineering is that there isn’t really a “typical” day. It usually sits somewhere between keeping the existing network healthy, solving problems, improving the infrastructure, and building automation to make tomorrow easier.
My day usually starts with checking the overall health of the network. I look at our monitoring and daily network status to identify things like link failures, routing issues, abnormal traffic patterns, or other infrastructure alerts.
From there, I usually go through customer and internal tickets. These can range from relatively simple connectivity or portal issues to more complex problems involving BGP traffic engineering, routing, DDoS mitigation, or network behaviour. If something isn’t immediately clear, I’ll bring it up during our daily sync with the team, investigate it further, and then get back to the customer.
A significant part of the job is also troubleshooting infrastructure issues. When an alert comes in, the goal isn’t just to clear the alert. I try to understand why it happened and whether it’s something that could happen again.
That naturally leads into one of the parts of the job I enjoy most: finding recurring problems and fixing them at the source.
Automation is a big part of that.
If I notice that engineers repeatedly have to perform the same manual checks, I ask myself:
“Why are we doing this manually?”
For example, I’ve worked on automating network checks such as finding ISIS path metrics between locations or calculating RTTs, turning something that previously required several manual steps into something much faster and more consistent.
I also handle escalations. For example, during a DDoS incident, troubleshooting might involve checking the customer’s traffic, identifying the attack pattern, verifying the mitigation template, understanding why the traffic wasn’t mitigated as expected, and then improving the configuration or proposing a better mitigation strategy.
Beyond day-to-day operations, there’s also a strong infrastructure-development aspect to the role.
That includes:
- Monitoring traffic growth and planning capacity upgrades
- Expanding bandwidth where required
- Working on new PoP deployments
- Planning and executing network maintenance
- Coordinating with providers when links fail
- Communicating planned maintenance to affected customers
- Contributing to new product discussions
- Improving existing processes and services
So for me, the role is really a combination of:
Operate → Troubleshoot → Improve → Automate → Scale.
And I think that’s what makes network engineering interesting.
What is your favourite part of being a Network Engineer?
For me, it’s troubleshooting complex problems and understanding what’s actually happening underneath the surface.
I enjoy starting with something that looks simple—“the customer can’t reach this destination” or “traffic isn’t taking the expected path”—and then working down through the layers.
You might start with:
Customer says:
“Traffic is slow.”
↓ Check traffic
↓ Check routing
↓ Check BGP
↓ Check ISIS
↓ Check path selection
↓ Check interface / transport
↓ Find the actual cause
The satisfying part is when all the pieces finally line up, and you understand why the network behaved the way it did.
I also really enjoy the engineering side of the role—once you’ve solved a problem, asking:
“How can we make sure nobody has to solve this manually again?”
That’s where troubleshooting turns into automation and engineering improvement.
What is something you know now that you wish you had known earlier in your career?
I wish I had understood earlier that knowing commands is not the same as understanding networking.
When you’re starting out, it’s easy to focus on things like:
show bgp
show isis
show interfaces
Configure…
But the real skill is understanding why the network is doing what it’s doing.
For example, instead of simply knowing that BGP selected a particular route, understand:
- Why was this route considered?
- Why did another route lose?
- What role did LOCAL_PREF play?
- Did MED matter?
- Was the route learned via eBGP or iBGP?
- Is route reflection involved?
- Is ORR involved?
- What does the IGP contribute to the decision?
- What happens when the topology changes?
The other thing I’ve learned is that network engineers should think beyond individual devices. A network isn’t Router A + Router B + Router C. It’s a system.
You need to understand how routing protocols, transport, automation, monitoring, capacity, customers and operational processes all interact. That mindset has probably been more valuable to me than memorising individual commands.
What kind of network challenges are becoming more common these days?
I think one of the biggest changes is that networks are becoming larger, more distributed and more software-driven.
We’re dealing with:
- More traffic
- More locations and PoPs
- Increasing bandwidth requirements
- More complex traffic engineering
- DDoS attacks becoming larger and more sophisticated
- Anycast and distributed services
- EVPN/MPLS-based architectures
- Increasing customer expectations for self-service
- And much greater pressure to automate operations
At the same time, the network can’t become more complicated operationally just because the infrastructure is becoming more complicated.
That’s where I think automation and good network design become essential.
The challenge isn’t just:
“Can we build this?”
It’s:
“Can we operate this reliably at scale?”
That’s a very different question.
What is something that automation has helped with when it comes to networks?
Automation has helped me most by removing repetitive operational work and making network checks more consistent.
A good example is network troubleshooting.
Imagine an engineer wants to compare the network path between two locations.
Without automation, you might need to:
Check router A
↓
Check ISIS database
↓
Check ISIS route
↓
Check metrics
↓
Check router B
↓
Calculate path
↓
Check RTT
↓
Compare results
If you do that frequently, it’s a perfect candidate for automation.
Input:
Berlin → Frankfurt
↓ Automation
↓ ISIS path
Metrics
Interfaces
RTT
Relevant routing information
↓ Result
The benefit isn’t only speed. It’s also consistency.
The automation performs the same checks every time, which reduces the chance of missing something during troubleshooting. And I think that’s one of the most important ways to approach network automation:
Don’t automate just because you can. Automate the repetitive work that gives engineers more time to solve the problems that actually require engineering judgment.
