Private corporate batches, live online cohorts and 1-on-1 mentoring in Cisco network design and NetDevOps — routing and switching design, IOS-XE and NX-OS, NETCONF/YANG, ACI, SD-WAN and pyATS — 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 Cisco environments across both halves of the job — design decisions with their consequences, then the automation that makes those decisions repeatable. On the design side that means convergence behaviour and loop-free topologies, route aggregation and link-state summarisation boundaries, fault isolation and fate sharing, tunnelling selection and QoS matched to application requirements. On the automation side it is configuration in Git rendered through Jinja2, deployed over NETCONF and RESTCONF against YANG models rather than screen-scraped CLI, and verified with pyATS and Genie parsers that assert BGP state and interface health instead of reading show output by eye. Controller-based fabrics are taught through their APIs, and every change is rehearsed in a Cisco Modeling Labs topology before it is promoted.
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 Cisco that means a trainer who has run it in production — Cisco network design and NetDevOps — routing and switching design, IOS-XE and NX-OS, NETCONF/YANG, ACI, SD-WAN and pyATS — 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 Cisco batchCisco builds the routing, switching, wireless, security and data-centre hardware that carries a very large share of enterprise traffic, along with the operating systems and controllers that run it. In practice an engineer meets it as a set of platforms and network operating systems: IOS-XE on Catalyst switches and ISR/ASR routers, NX-OS on Nexus data-centre switches, IOS-XR on service-provider platforms, and controller-based systems such as ACI with the APIC, Catalyst Center, SD-WAN with vManage, and cloud-managed Meraki.
Working in a Cisco estate splits into two disciplines that are usually taught apart and practised together. The first is design: choosing a Layer 2 and Layer 3 control plane that converges predictably, deciding where to aggregate routes and summarise link-state topology, isolating faults so a failure in one place does not become an outage everywhere, and selecting tunnelling, virtualisation and QoS mechanisms that match the application requirements rather than the datasheet.
The second is automation. Alongside the command-line interface, Cisco platforms expose model-driven interfaces — NETCONF, RESTCONF and gNMI, all driven by YANG data models — plus controller REST APIs on ACI, Catalyst Center, vManage and Meraki. That turns network configuration into something a program can produce, validate and version: configuration in Git, rendered from templates, tested before it reaches a device, deployed by a pipeline and verified afterwards. Cisco pyATS and the Genie libraries parse device state into structured objects so a pipeline can assert that BGP neighbours are up rather than eyeballing show output, and Cisco Modeling Labs provides the virtual topology to test against first.
Networks have become the last part of infrastructure still configured by hand, and the pressure to change that is now commercial rather than academic. Compute and cloud resources are provisioned from code in minutes; a firewall rule or VLAN change that takes three days of tickets is visibly the bottleneck, and every outage post-mortem that ends in "someone pasted the wrong config" makes the case again.
Cisco has responded by making every current platform programmable, and enterprises have responded by hiring for a hybrid profile. Job specifications increasingly ask for routing and switching design depth plus Python, Ansible, Git and CI — not a network engineer and separately an automation engineer, but one person who can do both and be trusted with the production fabric.
That combination is genuinely scarce. Many network engineers have never used version control; many automation engineers cannot read a BGP table, reason about microloops during convergence, or explain why a summarisation boundary was placed where it was. Automating a design nobody understands only produces failures faster. The engineers who can design the topology, express it as code, and prove a change in a virtual topology before shipping it are the ones organisations put in front of the core.
An accurate picture of the platforms before designing or automating anything. Which operating system runs on which hardware, which management interfaces each exposes, where controllers sit relative to devices, and the practical difference between device-by-device automation and intent expressed to a controller.
Topics: IOS-XE, NX-OS and IOS-XR: platforms and differences that matter · Catalyst, Nexus, ISR/ASR and Meraki hardware families · Management planes: CLI, SNMP, NETCONF, RESTCONF, gNMI, controller REST · Controller-based versus device-based operating models · Cisco Modeling Labs as the safe place to be wrong · Cisco DevNet resources, sandboxes and always-on labs · Building the toolchain: Python, Ansible, Git
How a switched domain behaves when something fails, and how to make that behaviour predictable. Fast convergence mechanisms, loop detection and mitigation, the alternatives to spanning tree for building loop-free topologies, and the fault isolation and segmentation decisions that decide how far a failure spreads.
Topics: Fast convergence techniques: down detection and interface dampening · Loop detection and mitigation protocols · Spanning tree types and tuning techniques · Loop-free topologies: REP, multipath, switch clustering, flex links · Transport mechanisms and their interaction with routing protocols over different link types · Fault isolation, fate sharing and redundancy in switched design · Virtualisation and segmentation at Layer 2 · vPC, port channels and first-hop redundancy behaviour
The design module that separates operators from architects. Route aggregation and where to place it, topology layering and link-state summarisation, the factors that actually govern convergence — recursion, microloops, timers, loop-free alternates — and how each routing protocol behaves in a design context rather than a configuration guide.
Topics: Route aggregation: purpose, location, technique and when to leak routes · Suboptimal routing as a consequence of aggregation choices · Network topology layering and the purpose of each layer · Topology abstraction and link-state summarisation: purpose and use · Metric-based traffic flow and modification, third-party next hop, protocol timers · Factors affecting convergence: recursion, microloops, transport, loop-free alternates · OSPF, EIGRP, IS-IS, BGP and RIP in relation to design: adjacency, loop-free paths, flooding domains and stubs · iBGP scalability, route reflectors and confederations · Routing policy, redistribution methods and mutual redistribution hazards · Analysing operational cost and complexity of a design
The addressing and forwarding subjects that underpin every design. Subnetting and the RIB-to-FIB relationship, NAT and policy-based routing as design tools with real costs, multicast from PIM through source-specific and anycast RP, and IPv6 concepts, security and transition mechanisms.
Topics: Subnetting, addressing plans and the RIB-FIB relationship · NAT and policy-based routing: legitimate uses and their costs · General multicast concepts and routing · PIM modes, source-specific multicast, MSDP and anycast RP · mVPN and multicast across a provider or overlay · General IPv6 concepts and addressing design · IPv6 security considerations · IPv6 transition techniques and dual-stack operation
Overlays as a design decision rather than a default. Layer 2 and Layer 3 tunnelling technologies and the five reasons anyone deploys one — security, network extension, resiliency, protocol integration, traffic optimisation — then technology and endpoint selection, and the effect an overlay has on the routing protocol underneath it.
Topics: Layer 2 and Layer 3 tunnelling technologies compared · Tunnelling for security, network extension and resiliency · Tunnelling for protocol integration and traffic optimisation · Tunnelling technology selection and endpoint placement · Tunnel parameter optimisation for end-user application behaviour · Effects of tunnelling on routing and the underlay · Routing protocol selection and tuning for tunnels · VXLAN EVPN fabric concepts and verification
Three subjects that decide whether a network is operable. QoS driven by application requirements rather than habit; network management requirements, reporting and the reference models organisations are audited against; and the protection of the infrastructure itself — administrative access, control plane and data plane.
Topics: QoS performance metrics and application requirements · Classification and marking, shaping, policing and queuing · DiffServ and IntServ strategies chosen from customer requirements · Network management and application reporting requirements · Technologies, tools and protocols used for network management · Reference models and processes: FCAPS, ITIL and TOGAF · Protecting network infrastructure: secure administrative access and control plane protection · Protecting network services: deep packet inspection and data plane protection · Identity management tools and technologies, including ISE and TrustSec · Considerations for 802.11 wireless, optical and SAN fabric deployment
The hands-on protocol work the design modules assume. Interfaces and VLANs, bringing up OSPF and BGP and breaking them deliberately, first-hop redundancy and vPC on Nexus, software upgrade and ISSU, and a structured troubleshooting method that goes from symptom to evidence to cause rather than to guesswork.
Topics: Interfaces, VLANs, trunking and spanning-tree verification · OSPF and BGP configuration, adjacency states and path selection · First-hop redundancy, port channels and vPC on Nexus · Access control and infrastructure ACL implementation · Software upgrade and ISSU on IOS-XE and NX-OS · Structured troubleshooting: symptom, evidence, hypothesis, proof · Reading platform state: hardware forwarding, TCAM and resource limits
The shift from text to data. YANG as the schema, NETCONF as the protocol with its datastores and locking semantics, RESTCONF as the HTTP mapping, and gNMI for streaming. How to find the right model, build a payload, and understand why a device rejects one.
Topics: YANG modelling: containers, lists, leaves, native vs OpenConfig models · Data models and structures: YANG, JSON and XML · Finding and reading models with pyang and YANG Suite · NETCONF: capabilities, datastores, candidate config, locking, commit · RESTCONF: URI construction, verbs, JSON and XML payloads · gRPC and gNMI: capabilities, get, set and subscribe · Error handling and rpc-error diagnosis · Choosing between native and OpenConfig models
Turning one-off scripts into automation a team can trust. Python libraries for network work, Ansible network collections and connection plugins, Jinja2 templating from a source-of-truth data model, idempotency on devices that were never designed for it, version control practice and secrets handling.
Topics: netmiko, ncclient, nornir and requests: when to use which · Ansible network collections: cisco.ios, cisco.nxos, ansible.netcommon · Connection plugins: network_cli, netconf, httpapi · Jinja2 templates and a source-of-truth data model in Git · Configuration management tools, agent and agentless, and version control with Git · Idempotency, check mode and config diff on network devices · Secrets and credential handling for network automation · Structuring a repository so a team can contribute safely
The discipline that makes network automation defensible. pyATS testbeds and AEtest structure, Genie parsers turning show output into objects, learning and diffing operational state before and after a change, and wiring the whole thing into a pipeline that gates on results.
Topics: pyATS testbed files, connections and device abstraction · Genie parsers, models and structured device state · Learn, snapshot and diff: proving a change did what it claimed · AEtest test scripts, sections and result reporting · Pre-change and post-change validation suites · Running tests against Cisco Modeling Labs topologies in CI · Pipeline design: lint, render, virtual test, approve, deploy, verify
Where the API is the network. The ACI object model and how the APIC REST interface mirrors it, Catalyst Center intent APIs and SD-Access, SD-WAN policy and templates through vManage, and Meraki's dashboard API — each taught as an automation surface, with the northbound and southbound API model made explicit.
Topics: ACI object model: tenants, VRFs, bridge domains, EPGs, contracts · APIC REST API, the object browser and moquery · ACI automation with Ansible and Terraform providers · Catalyst Center: intent APIs, templates, assurance data and SD-Access · SD-WAN architecture and vManage device and policy templates · Meraki dashboard API and configuration templates · Controller-based network design: policy-driven configuration, northbound and southbound APIs · When a controller helps and when it becomes the constraint
The surrounding platform an enterprise network now has to integrate with. UCS and Intersight for compute, multicloud connectivity and workload migration considerations, network functions virtualisation and SDN, model-driven telemetry replacing SNMP polling, and the IoT and edge patterns that push network design outward.
Topics: UCS architecture, service profiles and Intersight API-driven management · Nexus Dashboard and fabric-wide operations · Public, private, hybrid and multicloud design considerations, and XaaS models · Cloud performance, scalability, high availability, compliance and workload migration · Compute virtualisation: containers and virtual machines, virtual switches · NFVi, VNF and virtualisation functions; SDN and network programmability · Model-driven telemetry: sensor paths, subscriptions, dial-in vs dial-out, encodings · Telemetry pipelines into time-series storage, with syslog and NetFlow where they still fit · ThousandEyes for path visibility beyond your own estate · IoT architecture: network hierarchy, data acquisition and flow, standards and protocols · IoT security: segmentation, device profiling, secure remote access; edge and fog computing
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a multi-device Cisco Modeling Labs topology with routing and switching, reach every device from Python, and use it as the target for every later lab.
Build a routed topology, place summarisation boundaries two different ways, fail a link, and measure convergence and microloop duration for each design.
Provision interfaces, VRFs and BGP peers over NETCONF and RESTCONF using native and OpenConfig models, handling rpc-errors and rollback properly.
Hold site data in YAML, render device configuration through Jinja2, deploy with Ansible, and prove idempotency by running the play twice.
Snapshot device state with Genie, apply a change, diff the result, and fail the pipeline automatically when a BGP neighbour or interface does not come back.
Create tenants, bridge domains, EPGs and contracts against the APIC REST API, then reproduce the same result with Ansible and compare the workflows.
Take a real change request from Git branch through lint, template render, virtual-topology test and approval to deployment and post-change verification.
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
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
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.
| 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.