The internal components of a cisco router and switch

Bootstrap Stored in the microcode of the ROM, the bootstrap is used to bring a router up during initialization. It boots the router up and then loads the IOS.

POST (power-on self-test) Also stored in the microcode of the ROM, the POST is used to check the basic functionality of the router hardware and determines which interfaces are present.

ROM monitor Again, stored in the microcode of the ROM, the ROM monitor is used for manufacturing, testing, and troubleshooting,as well as running a mini-IOS when the IOS in flash fails to load.

Mini-IOS Called the RXBOOT or bootloader by Cisco, the mini-IOS is a small IOS in ROM that can be used to bring up an interface and load a Cisco IOS into flash memory. The mini-IOS can also perform a few other maintenance operations.

RAM (random access memory) Used to hold packet buffers, ARP cache, routing tables, and also the software and data structures that allow the router to function. Running-config is stored in RAM, and most routers expand the IOS from flash into RAM upon boot.

ROM (read-only memory) Used to start and maintain the router. Holds the POST and the bootstrap program as well as the mini-IOS.

Flash memory Stores the Cisco IOS by default. Flash memory is not erased when the router is reloaded. It is EEPROM (electronically erasable programmable read-only memory)created by Intel.

NVRAM (nonvolatile RAM) Used to hold the router and switch configuration. NVRAM is not erased when the router or switch is reloaded. Does not store an IOS. The configuration register is stored in NVRAM.

Configuration register Used to control how the router boots up. This value can be found as the last line of the show version command output and by default is set to 0x2102, which tells the router to load the IOS from flash memory as well as to load the configuration from NVRAM.

The router and switch boot sequence

When a Cisco device boots up, it performs a series of steps, called the boot sequence, to test the hardware and load the necessary software. The boot sequence comprises the following steps:

1. The IOS device performs a POST, which tests the hardware to verify that all components of the device are present and operational. The post takes stock of the different interfaces on the switch or router, and it’s stored in and runs from read-only memory (ROM).

2. The bootstrap in ROM then locates and loads the Cisco IOS software by executing programs responsible for finding where each IOS program is located. Once they are found, it then loads the proper files. By default, the IOS software is loaded from flash memory in all Cisco devices. The default order of an IOS loading from a Cisco device begins with flash, then TFTP server, and finally, ROM.

3. The IOS software then looks for a valid configuration file stored in NVRAM. This file is called startup-config and will be present only if an administrator has copied the running-config file into NVRAM.

4. If a startup-config file is found in NVRAM, the router or switch will copy it, place it in RAM, and name the file the running-config. The device will use this file to run, and the router/switch should now be operational. If no startup-config file is found in NVRAM, the router/switch reacts by broadcasting out any interface that detects carrier detect (CD) to locate a TFTP host in its search for a configuration. When that fails, which it typically does, the device will begin the setup mode configuration process. Most people don’t even realize the device has attempted this process!

The default order of an IOS loading from a Cisco device begins with flash, then TFTP server, and finally, ROM.

Booting System

Booting from Flash memory

Booting from tftp server

Configuration Register

Managing the Configuration Register

All Cisco routers have a 16-bit software register that’s written into NVRAM. By default, the configuration register is set to load the Cisco IOS from flash memory and to look for and load the startup-config file from NVRAM. In the following sections, I am going to discuss the configuration register settings and how to use these settings to provide password recovery on your routers.

Understanding the Configuration Register Bits

The 16 bits (2 bytes) of the configuration register are read from 15 to 0, from left to right. The default configuration setting on Cisco routers is 0x2102. This means that bits 13, 8, and 1 are on. Notice that each set of 4 bits (called a nibble) is read in binary with a value of 8, 4, 2, 1.

The boot field, which consists of bits 0–3 in the configuration register (the last 4 bits), controls the router boot sequence and locates the Cisco IOS.

Checking the Current Configuration Register Value

You can see the current value of the configuration register by using the show version command (sh version or show ver for short), as demonstrated here:

The last information given from this command is the value of the configuration register. In this example, the value is 0x2102—the default setting. The configuration register setting of 0x2102 tells the router to look in NVRAM for the boot sequence.

Register Values and rules

Recovering Passwords

If you’re locked out of a router because you forgot the password, you can change the configuration register to help you get back on your feet. As I said earlier, bit 6 in the configuration register is used to tell the router whether to use the contents of NVRAM to load a router configuration. The default configuration register value is 0x2102, meaning that bit 6 is off. With the default setting, the router will look for and load a router configuration stored in NVRAM (startup-config). To recover a password, you need to turn on bit 6. Doing this will tell the router to ignore the NVRAM contents. The configuration register value to turn on bit 6 is 0x2142. Here are the main steps to password recovery:

I’m going to cover these steps in more detail in the following sections. I’ll also show you the commands to restore access to ISR series routers. You can enter ROM monitor mode by pressing Ctrl+Break or Ctrl+Shift+6, then b, during router bootup. But if the IOS is corrupt or missing, if there’s no network connectivity available to find a TFTP host, or if the mini-IOS from ROM doesn’t load (meaning the default router fallback failed), the router

IP Service Level Agreements (SLAs)

Using IP SLA for Troubleshooting

I want to mention one more thing that can help you troubleshoot your IP network, and this is using IP service-level agreements (SLAs), which will allow us to use IP SLA ICMP echo to test far-end devices instead of pinging manually.

R1 should have an ICMP Echo test configured to the remote server address, and the test should run every 10 seconds and be scheduled to run forever.

Switched Port Analyzer (SPAN)

Using SPAN for Troubleshooting

A traffic sniffer can be a valuable tool for monitoring and troubleshooting your network. However, since the inception of switches into our networks more than 20 years ago, troubleshooting has become more difficult because we can’t just plug an analyzer into a switch port and be able to read all the network traffic. Before we had switches, we used hubs, and when a hub received a digital signal on one port, the hub sent that digital signal out on all ports except the port it was received on. This allows a traffic sniffer that is connected to a hub port to receive all traffic in the network.

Modern local networks are essentially switched networks. After a switch boots, it starts to build up a layer 2 forwarding table based on the source MAC addresses of the different packets that the switch receives. After the switch builds this forwarding table, it forwards traffic that is destined for a MAC address directly to the exit port. By default, this prevents a traffic sniffer that is connected to another port from receiving the unicast traffic. The SPAN feature was therefore introduced on switches to help solve this problem

The SPAN feature allows you to analyze network traffic passing through the port and send a copy of the traffic to another port on the switch that has been connected to a network analyzer or other monitoring device. SPAN copies the traffic that the device receives and/or sends on source ports to a destination port for analysis.

For example, if you would like to analyze the traffic flowing from PC1 to PC2, shown in Figure 20.2, you need to specify a source port where you want to capture the data. You can either configure the interface Fa0/1 to capture the ingress traffic or configure the interface Fa0/3 to capture the egress traffic—your choice! Next, specify the destination port interface where the sniffer is connected and will capture the data, in this example Fa0/2. The traffic flowing from PC1 to PC2 will then be copied to that interface, and you will be able to analyze it with a traffic sniffer.

Cloud Computing

Service Models

Cloud providers can offer you different available resources based on your needs and budget. Figure shows the three service models available depending on the type of service you choose to get from a cloud.

Software Defined Networking (SDN)

Si vous avez travaillé sur des installations Wi-Fi d'entreprise au cours de la dernière décennie, vous auriez conçu votre réseau physique, puis configuré un type de contrôleur réseau gérant tous les points d'accès sans fil du réseau. On peut faire de même pour les routeurs et les switchs, et c'est précisément cette gestion centralisée des trames et des paquets réseau que SDN (Software Defined Networking) nous fournit.

SDN (Software Defined Networking) supprime l'intelligence des périphériques réseau en ayant un contrôleur central qui gère le réseau au lieu d'avoir un système d'exploitation complet (Cisco IOS) sur chaque périphérique. À son tour, le contrôleur gère le réseau en automatisant la configuration et les corrections sur tous les périphériques. Ainsi, à la place des périphériques réseau disposant chacun de plans de contrôle individuels, nous disposons désormais d'un plan de contrôle centralisé qui consolide toutes les opérations réseau dans le contrôleur SDN.

APIs permet aux applications de contrôler et de configurer le réseau sans intervention humaine. Les API sont un autre type d'interface de configuration, tout comme les interfaces CLI, SNMP ou GUI, qui facilitent les opérations entre machines.

APPLICATION PROGRAMMING INTERFACES (APIs)

Southbound APIs

Northbound APIs