Private corporate batches, live online cohorts and 1-on-1 mentoring in TCP/IP, subnetting, DNS, TLS and load balancing — the layer every outage eventually lands on — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches networking from the packet up rather than from the diagram down — subnetting and CIDR arithmetic done by hand, TCP handshakes and retransmissions read live in a capture, TLS chains validated with openssl, and DNS resolution traced with dig from root to authoritative. Sessions carry the fundamentals directly into the environments engineers actually operate: VPC design and route tables, security groups against network ACLs, load balancer health-check behaviour, and Kubernetes networking down to network namespaces, CNI datapaths, kube-proxy rules and NetworkPolicy enforcement — every concept demonstrated against running infrastructure with tcpdump, ss, ip and mtr rather than slides.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Networking that means a trainer who has run it in production — TCP/IP, subnetting, DNS, TLS and load balancing — the layer every outage eventually lands on — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Networking batchNetworking is the set of protocols, addressing rules and forwarding behaviour that move a byte from one process to another. For an infrastructure engineer it is not an academic topic: it is the layer where the ambiguous failures live. A pod that cannot reach a database, a TLS handshake that fails only from one region, a health check that flaps at exactly 60 seconds, a transfer that is fast on the LAN and unusable across a WAN — every one of those is a networking problem wearing an application costume.
The useful model is the four-layer TCP/IP stack rather than the seven-layer OSI diagram: link, internet, transport and application. Ethernet, ARP and switching move frames inside a broadcast domain. IP addressing, CIDR, subnetting and routing move packets between them. TCP supplies ordering, retransmission, flow control and congestion control — and imposes the handshake, the MSS, the receive window and the TIME_WAIT state that explain most confusing latency. UDP supplies none of that, which is exactly why DNS and QUIC use it. Above that sit DNS, TLS and HTTP, where certificate chains, SNI, ALPN and connection reuse decide whether a service is reachable.
Modern infrastructure adds two more layers on top of the same fundamentals. Cloud networking replaces cables with VPCs, subnets, route tables, security groups, NAT gateways, peering and private endpoints. Container networking replaces the physical host boundary with network namespaces, veth pairs, bridges, CNI plugins, iptables or eBPF datapaths, and Kubernetes Services, Ingress and NetworkPolicy. Neither abstraction removes the fundamentals; both make them harder to see, which is why engineers who can read a packet capture remain the ones who close the incident.
Cloud and Kubernetes did not remove the network — they moved it into software and hid it behind an API. The result is that far more engineers now configure routing, firewalls, load balancers and DNS than ever worked in a network team, and most of them learned it by copying a Terraform module. That gap shows up as the same recurring incidents: overlapping CIDRs discovered during a merger, security groups that allow far more than intended, MTU mismatches over a VPN tunnel, DNS TTLs that make a failover take an hour.
The hiring signal reflects it. Platform, SRE, cloud and security job specifications now assume subnetting, TLS, DNS and load-balancer behaviour as baseline knowledge rather than a specialism, and interviews probe it directly because it is the fastest way to separate someone who operates a system from someone who follows a runbook.
The knowledge also has an unusually long shelf life. Frameworks and orchestrators turn over every few years; the TCP handshake, CIDR arithmetic and certificate validation you learn now will still be correct in a decade.
Start where the packets do. The TCP/IP stack against the OSI diagram and why the four-layer model is the more useful mental tool. Ethernet framing, MAC addressing, ARP, switching and broadcast domains, VLANs, and the encapsulation walk-through that makes every later layer obvious.
Topics: OSI and TCP/IP models, and where each is actually useful · Ethernet frames, MAC addressing and the MAC table · ARP, gratuitous ARP and ARP cache problems · Switching, broadcast domains and collision domains · VLANs, trunking and 802.1Q tagging · Encapsulation and decapsulation end to end · MTU, jumbo frames and where fragmentation bites
The arithmetic that engineers are expected to do without a calculator. Binary addressing, prefix lengths, network and broadcast addresses, usable host ranges, VLSM and supernetting — then IPv6 addressing, which is different enough to deserve its own treatment.
Topics: IPv4 addressing, classes and why classful thinking still causes bugs · CIDR notation and prefix arithmetic in binary · Network address, broadcast address and usable host range · Subnetting and variable-length subnet masking · Private ranges, RFC 1918 and CIDR overlap in mergers and peering · IPv6 addressing, prefixes, SLAAC and dual-stack · Address plan design for a growing estate
How a packet chooses its next hop. Routing tables, longest-prefix match, default gateways, static and dynamic routing, and the NAT behaviour that makes cloud egress work — plus reading routes on a Linux host with ip route rather than trusting the diagram.
Topics: Routing tables and longest-prefix match · Default gateways and route metrics · Static routing and an introduction to OSPF and BGP · NAT, PAT, SNAT and DNAT · Asymmetric routing and why it breaks stateful firewalls · Policy routing and multiple routing tables on Linux · traceroute, mtr and interpreting hop-by-hop output
The layer that explains most latency complaints. The three-way handshake, sequence numbers, retransmission, flow control and congestion control, socket states, and the connection-lifecycle problems — TIME_WAIT exhaustion, half-open connections, keepalives — that surface as application bugs.
Topics: TCP three-way handshake, teardown and RST behaviour · Sequence numbers, ACKs, retransmission and duplicate ACKs · Flow control, receive window and window scaling · Congestion control, slow start and bandwidth-delay product · MSS, path MTU discovery and black-hole connections · Socket states, TIME_WAIT, CLOSE_WAIT and port exhaustion · UDP, and why DNS and QUIC prefer it · Reading transport behaviour with ss and tcpdump
The most common cause of an outage that is not the network. Resolution from root to authoritative, record types, delegation, caching and TTL behaviour, negative caching, and the operational patterns — split-horizon, low-TTL failover, service discovery — that infrastructure teams depend on.
Topics: Recursive vs authoritative resolution, walked with dig +trace · Record types: A, AAAA, CNAME, SRV, TXT, MX, NS, PTR, CAA · Delegation, glue records and zone files · TTL, caching layers and negative caching with SOA minimum · Split-horizon and private DNS zones in cloud environments · DNS-based failover and its real convergence time · Service discovery: Kubernetes CoreDNS and cloud private zones · DNS failure modes: stale caches, search domains, ndots
What actually happens in a handshake and why it fails. The chain of trust, SNI, ALPN, TLS 1.2 against 1.3, certificate validation rules, and the operational lifecycle — issuance, renewal, rotation, revocation — including mutual TLS between services.
Topics: TLS handshake in 1.2 and 1.3, and what changed · Certificate chains, intermediates and root stores · SNI, ALPN and virtual hosting over TLS · Hostname validation, SANs and wildcard limits · Certificate lifecycle: issuance, ACME, renewal and rotation · Revocation, OCSP stapling and its practical limits · Mutual TLS and client certificate authentication · Debugging with openssl s_client and curl -v
The application layer as infrastructure engineers meet it. HTTP/1.1 keep-alive against HTTP/2 multiplexing and HTTP/3 over QUIC, forward and reverse proxies, and load balancing at L4 and L7 — including the health-check, timeout and draining settings that cause most deployment-time errors.
Topics: HTTP/1.1 keep-alive, HTTP/2 multiplexing and HTTP/3 over QUIC · Forward proxies, reverse proxies and what each is for · L4 vs L7 load balancing and when each is correct · Load balancing algorithms and session affinity · Health checks: active, passive, thresholds and flapping · Idle timeouts, connection draining and graceful shutdown · X-Forwarded-For, PROXY protocol and preserving client IP · Keep-alive mismatches and the 502 they produce
The same fundamentals expressed as cloud APIs. VPC and VNet design, subnets and route tables, internet and NAT gateways, security groups against network ACLs, peering and transit connectivity, private endpoints, and hybrid links over VPN or dedicated interconnect.
Topics: VPC and VNet design: subnets, route tables, availability zones · Internet gateways, NAT gateways and egress cost · Security groups vs network ACLs: stateful vs stateless · VPC peering, transit gateway and hub-and-spoke topologies · Private endpoints and private service connectivity · Site-to-site VPN, IPsec and MTU on tunnels · Firewalls, nftables and host-level filtering · Flow logs, and using them to prove what was blocked
Where the abstraction is thickest and the fundamentals still decide the outcome. Network namespaces and veth pairs, the CNI contract, pod-to-pod and pod-to-service paths, kube-proxy against eBPF datapaths, Ingress, and NetworkPolicy. Closes with the structured diagnostic method the whole course has been building towards.
Topics: Network namespaces, veth pairs and bridges · The CNI contract and common plugins: Calico, Cilium, Flannel · Pod-to-pod, pod-to-service and pod-to-external paths · kube-proxy with iptables and IPVS, and eBPF alternatives · Services, Ingress controllers and external load balancers · CoreDNS resolution inside a cluster · NetworkPolicy: default deny, ingress and egress rules · A repeatable troubleshooting method: layer by layer with tcpdump, ss, ip, dig and curl
We rebuild the agenda around the tools you actually run.
Request a custom agendaDesign a complete IPv4 and IPv6 address plan across regions and environments by hand, then validate it against a set of existing CIDR blocks for overlap.
Capture live traffic with tcpdump, then explain a slow transfer, a connection reset and a failed handshake purely from sequence numbers, window sizes and flags.
Walk a name from the root servers to the authoritative answer with dig, then reproduce and fix a stale-cache failure and a search-domain resolution bug.
Diagnose an expired chain, a missing intermediate, a hostname mismatch and an SNI misconfiguration using openssl s_client and curl, then fix and verify each one.
Build public, private and data subnets with route tables, a NAT gateway, security groups and network ACLs, then use flow logs to prove exactly which rule blocks what.
Debug a DNS resolution failure, a NetworkPolicy that blocks legitimate traffic and an MTU mismatch across a tunnel, working from the datapath up rather than by trial and error.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.