Course sections

1
Lecture 1: Identify, implement and troubleshoot IPv4 addressing and subnetting
2
Lecture 2: Identify, implement and troubleshoot IPv6 addressing and subnetting
3
Lecture 1: Troubleshoot reverse path forwarding
4
Lecture 2: Implement and troubleshoot IPv4 protocol independent multicast
5
Lecture 3: Implement and troubleshoot multicast source discovery protocol
6
Lecture 4: Describe IPv6 multicast
7
Lecture 1: Implement and troubleshoot static routing
8
Lecture 2: Implement and troubleshoot default routing
9
Lecture 3: Compare routing protocol types
10
Lecture 4: Implement, optimize and troubleshoot administrative distance
11
Lecture 5: Implement and troubleshoot passive interface
12
Lecture 6: Implement and troubleshoot VRF lite
13
Lecture 7: Implement, optimize and troubleshoot filtering with any routing protocol
14
Lecture 8: Implement, optimize and troubleshoot redistribution between any routing protocol
15
Lecture 9: Implement, optimize and troubleshoot manual and auto summarization with any routing protocol
16
Lecture 10: Implement, optimize and troubleshoot policy-based routing
17
Lecture 11: Identify and troubleshoot sub-optimal routing
18
Lecture 12: Implement and troubleshoot bidirectional forwarding detection
19
Lecture 13: Implement and troubleshoot loop prevention mechanisms
20
Lecture 14: Implement and troubleshoot routing protocol authentication
21
Lecture 1: Implement and troubleshoot RIPv2
22
Lecture 2: Describe RIPv6 [RIPng]
23
Lecture 1: Describe packet types
24
Lecture 2: Implement and troubleshoot neighbor relationship
25
Lecture 3: Implement and troubleshoot loop free path selection
26
Lecture 4: Implement and troubleshoot operations
27
Lecture 5: Implement and troubleshoot EIGRP stub
28
Lecture 6: Implement and troubleshoot load-balancing
29
Lecture 7: Implement EIGRP [multi-address] named mode
30
Lecture 8: Implement, troubleshoot and optimize EIGRP convergence and scalability
31
Lecture 1: Describe OSPF packet types
32
Lecture 2: Describe neighbor relationship
33
Lecture 3: Implement and troubleshoot OSPFv3 address-family support
34
Lecture 4: Implement and troubleshoot network types, area types and router types
35
Lecture 5: Implement and troubleshoot path preference
36
Lecture 6: Implement and troubleshoot operations
37
Lecture 1: Describe, implement and troubleshoot peer relationships
38
Lecture 7: Implement, troubleshoot and optimize OSPF convergence and scalability
39
Lecture 2: Implement and troubleshoot IBGP and EBGP
40
Lecture 3: Explain attributes and best-path selection
41
Lecture 4: Implement, optimize and troubleshoot routing policies
42
Lecture 5: Implement and troubleshoot scalability
43
Lecture 6: Implement and troubleshoot multiprotocol BGP
44
Lecture 7: Implement and troubleshoot AS path manipulations
45
Lecture 8: Implement and troubleshoot other BGP features
46
Lecture 9: Describe BGP fast convergence features
47
Lecture 1: Describe basic IS-IS network
48
Lecture 3: Describe network types, levels and router types
49
Lecture 4: Describe IS-IS operations
50
Lecture 5: Describe optimization features
51
Key Takeaways: Layer 3 Technologies
52
Quiz: Layer 3 Technologies

Network Principles, Lecture 1

Lecture 1: Describe basic software architecture differences between IOS and IOS XE

Describe basic software architecture differences between IOS and IOS XE

Cisco classic IOS has always had a monolithic software architecture, which means that it is both downloaded and run as a single binary image where all processes share the same memory address space. Monolithic and non-modular architecture leads to no memory protection between processes, as a result software defects in classic IOS code can potentially corrupt data used by other processes. It also has a run to completion scheduler, which means that the kernel does not preempt a running process — the process must make a kernel call before other processes can be scheduled and get a chance to run.

In all variations of classic Cisco IOS, packet routing and forwarding (switching) are distinct functions. Routing and other protocols run as IOS processes and contribute to the formation of Routing Information Base (RIB). This is processed to generate the final IP forwarding table (FIB, Forwarding Information Base), which is used by the forwarding function of the router. On router platforms with software-based forwarding (e.g., Cisco 7200 or Cisco ISR G2) most traffic handling is done at interrupt level using Cisco Express Forwarding (CEF). This helps avoid process context switching that would need to be done otherwise to forward packets. Routing functions such as OSPF or BGP run at the process level. In routers with hardware-based forwarding, such as the Cisco ASR1000 (which runs IOS XE), ASR9000 or CRS-1 or NCS series (which run IOS XR), IOS computes the FIB in software running on route processor (RP) hardware (typically x86 CPUs) and loads it into the forwarding hardware (such as an ASIC or a network processor), which performs the actual packet forwarding function.

The IOS XE is a POSIX based environment along with various open source software for the common drivers, tools and utilities needed to manage the system. In addition to the standard set of off-the-shelf drivers, IOS XE also includes a set of Cisco specific drivers and associated chassis/platform management modules.

On top of the base operating system (Linux) and drivers, IOS XE provides a comprehensive set of infrastructure modules which define how software is installed, how processes are started and sequenced, how high-availability (HA) and software upgrades are performed. The core application that runs on top of this new infrastructure is the IOS feature set in the form of IOS daemon (IOSd). By running Cisco IOS, products reap the benefits of an extensive feature set for routing and switching platforms that has been built into IOS over last two decades.

Finally, the evolved IOS architecture is specifically designed to accommodate other applications outside of IOS blob or IOSd. These applications can be upgraded or restarted independently of IOSd. If an application does require services from IOS, it can integrate with IOS through a set of client libraries called service points. These service points generically extend IOS information and services to outside applications such that these services are not replicated or managed separately. IOS XE is not a new network “OS” per se, it is rather an incarnation of classic IOS (“IOS”) where role of classic IOS is reduced to an application running on top of a Linux kernel. This approach also allows building routing/switching platforms that use a variety of data plane hardware (ASICs or network processors such as Cisco’s QFP or CPP) by way of the abstraction provided between control and data planes.

Each Cisco IOS XE Software subpackage provides specific functions for the Cisco ASR 1000 Series router.

Table 1-1, shows functions of Cisco IOS XE Software Subpackages

Package Function
RPBase Provides the operating system software for the route processor
RPControl Controls the control plane processes that interface between Cisco IOS Software and the rest of the platform
RPAccess Provides software required for router access

●      The non-K9 version of this subpackage is included only in consolidated packages that do not have cryptographic support.

●      The K9 version of this sub-package includes restricted components (Secure Sockets Layer [SSL] and Secure Shell [SSH]); consolidated packages with this subpackage are subject to export controls.

RPIOS Provides the Cisco IOS Software kernel, which is where Cisco IOS Software features are stored and run;

each consolidated package has a different RPIOS subpackage

ESPBase Provides the ESP operating system and control processes and the ESP software
SIPSPA Provides the shared port adaptor (SPA) driver and associated field-programmable device (FPD) images
SIPBase Controls the Session Initiation Protocol (SIP) carrier card operating system and control processes

 

Control plane and Forwarding plane

IOS XE allows development of data plane ASICs outside the IOS instance and have them program to a set of standard APIs which in turn enforces Control Plane and Data Plane processing separation. It achieves Control Plane / Data Plane separation through the introduction of the Forwarding and Feature Manager (FFM) and its standard interface to the Forwarding Engine Driver (FED). FFM provides a set of APIs to control plane processes. FFM programs the data plane via the FED and maintains forwarding state for the entire system. The FED is the instantiation of the hardware driver for the data plane.

Table 1-2, compares classic IOS (“IOS) and IOS XE architectures

Software Architecture Classic IOS (“IOS”) IOS XE
Monolithic Yes No
Control and Data Plane separation (Software) No Yes
Control and Data Plane separation (Hardware) Platforms that run classic IOS do not have clear separation of control and data plane in hardware Platforms that run IOS XE do have clear separation of control and data plane hardware
Feature parity All IOS versions contain a singular set of IOS features (E.g. all platforms in T train contain same features such as Cisco ISR G2 and 7200) All IOS XE versions contain software that is specific to one or a set of platforms

E.g., IOS XE running on Cisco ASR 900 contains different feature set than one running on Cisco ASR1000

Example Platforms All software based platform

Cisco ISRs (3900, 2900, 1900, 8XX), 7200 (end of life)

Cisco ISR 4K

Cisco ASR1000 series (1006, 1004, 1002, 1001)

Impact to troubleshooting and performances

Significant differences in software architecture lead to significant differences in how you troubleshoot the platforms that run classic IOS versus IOS XE. We can break down those differences in few larger areas.

Table 1-3, shows comparison of troubleshooting differences between classic IOS (“IOS) and IOS XE

Troubleshooting Area Classic IOS (“IOS”) IOS XE
Methodology All software based platforms use single set of troubleshooting approach Different set of show/debug platform CLIs for control and data planes
Command Line Interface (CLI) – show and debug commands All software based platforms use single set of CLIs Show/Debug CLIs can be specific to a given platform (e.g. ASR1000 versus ISR 4451)
Files and locations All software based platforms use single set of rules (E.g., crash dump go to internal bootflash by default)

Classic IOS image naming conventions

It can be specific to a given platform (e.g. ASR1000 versus ISR 4451)

ASR1000 dumps SPA driver cashdump on harddisk: by default

Newer software packages naming conventions

Level of difficulty Straightforward, upside of software-based platforms Complex, downside or cost of modularity i.e. clear separation of control and data plane software and hardware leads to more involved troubleshooting