I Learned BGP on a Delhi Rooftop, Not in a Lab
How aligning WiMAX antennas at -82 dBm in 45°C heat taught me more about network fundamentals than any certification course ever did — and why infrastructure engineers are better prepared for AI than they think.
“Everyone learns BGP from a Cisco press book. I learned it from a directional antenna on a Delhi rooftop at 2 PM in June.”
I was 26 years old. Spectranet field engineer. The summer of 2009.
The job was simple: drive to the client site, climb to the rooftop, align the WiMAX antenna, bring up the link. Then drive to the next site.
Nobody told me it would be the best networking education of my life.
The Setup: Why I Took the Job
I had just come from HCL Infosystems, where I’d spent two years managing a hospital network in Gurgaon. Cisco ASA 5510, Active Directory, UTP cabling, EPABX telephony. I’d gotten good at LAN. I knew how a building network was supposed to work.
But WAN was a black box to me. The internet. The routing. The BGP. The actual infrastructure that connects buildings across a city, or a country.
At HCL, when the internet circuit went down, I called the ISP. I didn’t know what happened next. I just waited for it to come back.
That bothered me. I don’t like black boxes.
So when Spectranet offered me a field engineer role, I took it specifically for that reason. They were an ISP. They were the other side of the phone call.
The Mess: What Field Engineering Actually Means
The job description said “install and configure enterprise internet connectivity.”
What it didn’t say:
- The rooftop access will be via a rusted iron ladder bolted to the outside of a seven-story building
- The site survey will be wrong 40% of the time
- You will be on that rooftop at 2 PM on a June afternoon in Delhi, where the ambient temperature is 45°C and the rooftop surface is 60°C+
- The radio link will refuse to come up, and you will have no idea why
The first month, I failed to bring up three consecutive links. Just couldn’t get the signal lock.
My first wrong diagnosis: bad antennas. I reported it, got replacements shipped, went back. Same result.
My second wrong diagnosis: interference from adjacent frequencies. Changed the channel. Still nothing.
What I was missing was the basics. I was chasing symptoms.
The moment that changed it was a site in Nehru Place, August 2009.
I’d been on the roof for two hours. The far-end site was 3.8 km away, line-of-sight was theoretically clear. I was getting signal, but the throughput was terrible — 2 Mbps on a 10 Mbps link.
I called the NOC. The senior engineer asked: “What’s your SNR?”
I checked: 7 dB.
He said: “You need at least 12 dB for stable throughput. Your alignment is off. You’re probably hitting a Fresnel zone obstruction. Move the antenna elevation 3-5 degrees and check again.”
I had no idea what a Fresnel zone was. I moved the antenna. The SNR jumped to 14 dB. The throughput hit 9.4 Mbps.
I went home that night and read about Fresnel zones until midnight.
That’s how the pattern started.
The Solution: Field + GNS3 at Midnight
I built a routine. Every technical problem I encountered during the day, I would research and simulate at night.
The field gave me the problem. GNS3 gave me the explanation.
- Alignment and RF math → Understood Fresnel zones, link budget calculation, fade margin
- BGP edge configuration → Started with
show ip bgp summaryon the NOC equipment, then simulated multi-hop BGP sessions in GNS3 until I understood the full state machine - Juniper SRX configuration → Client firewalls. I’d never touched Juniper before. I configured my first production SRX by reading the Junos docs on my phone at the job site
By month six, I was doing things nobody asked me to do. When a link went down in the middle of the night, I’d look at the NOC logs before the senior engineers did. I started understanding what the BGP route withdrawals meant. I started seeing the network instead of just the cable.
# The first BGP debug output I actually understood — August 2009
# Neighbour had gone into Idle state. The question was: why?
show ip bgp neighbors 203.0.113.1
# BGP neighbor is 203.0.113.1, remote AS 9829, external link
# BGP state = Idle
# Last reset 00:04:23, due to Notification sent (Hold Time Expired)
# Hold timer expired because the ISP router wasn't receiving keepalives.
# Root cause: MTU mismatch on the WiMAX backhaul — BGP packets were
# being fragmented and dropped silently.
# Fix: set ip tcp adjust-mss 1452 on the CPE interface
That MTU debugging session took four hours and three NOC calls. I never forgot it. And years later, when I was debugging HCX migration traffic drops over IBM’s cloud interconnect, I remembered that rooftop immediately.
The underlying problem was identical. Only the abstraction layer had changed.
The Technical Foundation I Built
By 2011, when I left Spectranet for Net4 India, here’s what I actually knew — not from a course, from the field:
- RF link engineering: Fresnel zones, fade margin, link budget calculation, antenna polarization
- WiMAX: 3.5 GHz band configuration, OFDMA frame structure, CPE alignment to ±0.5° precision
- BGP fundamentals: iBGP vs eBGP, route advertisement, hold timers, AS path manipulation
- Juniper SRX: Zone-based firewalling, routing instances, J-Web and CLI
- Fiber: Splicing, OTDR testing, loss budgeting per splice point
- MAN topology: Ring protection switching, traffic engineering on metro Ethernet
- SNMP monitoring: Cacti polling, OID-level device health, threshold alerting
- MTU debugging: The packet fragmentation problem you don’t find in textbooks until you’ve been burned by it
None of this was on the CCNA exam. But all of it made me a significantly better network engineer than someone who had only labbed in a simulator.
The Verdict
Key Takeaway
Production infrastructure is the best classroom there is — but only if you combine it with deliberate study.
The field gave me problems I couldn’t solve. The midnight study sessions gave me frameworks to understand them. The combination made both stick permanently in a way that no exam-focused preparation ever did.
If you’re early in your infrastructure career:
- Get your hands dirty in production as fast as possible, even if it’s an OJT or a junior field role
- When something breaks and you don’t know why, that is a gift — treat it as a question you have to answer before sleep
- Lab the theory of what you see in production. GNS3, EVE-NG, whatever you have — simulate the exact scenario you just lived through
- The things you genuinely don’t understand at 2 PM on a rooftop are the things you’ll remember for 18 years
The CCNA certificate confirmed what I had already built on those rooftops. The rooftops didn’t care about the certificate.
And if you’re an infrastructure engineer looking at AI and feeling like you’ve missed the boat: you haven’t. Every BGP state machine you debugged, every MTU fragmentation drop you traced, every ZTP pipeline you built — that is the foundation of how reliable AI systems are designed. The vocabulary changed. The engineering didn’t.
Architecture and decisions: mine. Debugging sessions at odd hours: mine. AI assistance: structure, syntax, first draft. — Sachin
Sachin Kumar Sharma
Associate Director (Infrastructure & Cloud Architecture Strategy) | 20+ Yrs Exp
Architecting resilient multi-cloud enterprise landing zones, SDN overlay fabrics, DevSecFinOps automation pipelines, and autonomous Agentic AI platforms.
💡 Related Engineering Articles
We Built a Tier-3 Data Center From Scratch. Here Is What Nobody Tells You.
Two Tier-3 DCs. No prior template. A leaking PAC unit at 2am, a P2V migration that almost took out Oracle, and an MP-BGP dual-stack IPv6 deployment that lived in production for three years before anyone noticed it was running.
BGP as a FinOps Tool: Optimizing Cloud Data Egress Costs
How we turned BGP Local Preference and MED attributes into financial steering levers, cutting an enterprise cloud data egress bill by 70%.
Azure ExpressRoute & BGP: Multi-Region Hybrid Routing Architecture
How we fixed asymmetric routing drops across multi-region Azure ExpressRoute circuits using BGP Local Preference and AS-Path Prepending.
📬 Stay Updated on Tech Releases
Sign up to get notified when I publish new production war stories, agentic AI architecture blueprints, or open-source infrastructure tools.