Showing posts with label ccna. Show all posts
Showing posts with label ccna. Show all posts

Friday, 15 November 2019

Cisco SNMP Configuration | What is Simple Network Management Protocol

Cisco SNMP Configuration | What is Simple Network Management Protocol

This chapter explain the operation of SNMP. It also describes how to configure SNMP on Cisco Router to collect messages on a small to medium-sized network management device.

What is Simple Network Management Protocol (SNMP)

SNMP (Simple Network Management Protocol) was developed to allow administrators to manage nodes, such as servers, workstations, routers, switches and security devices, in an IP network. It allows network administrators to manage network performance , detect and resolve network problems, and plan for network growth.
SNMP is an application layer protocol that provides a message format for communication between administrators and agents. The SNMP system consists of three elements:

  • SNMP Manager
  • SNMP agents (managed node)
  • Administration Information Base (MIB)

To configure SNMP on a network device, it is first necessary to define the relationship between the administrator and the agent.
The SNMP Manager is part of a network management system (NMS) and runs SNMP management software.

The SNMP administrator can collect information from an SNMP agent using a “get” action and can change the setting with “set”. In addition, SNMP agents can forward information directly to an NMS through traps.
The SNMP agent and the MIB reside on the network device clients. The network devices that must be managed have an SMNP agent software module. MIBs store data about the device's operation and are designed to be available to authenticated remote users. The SNMP agent is responsible for providing access to the local MIB that reflects the resources and activity of the objects.
SNMP uses UDP port number 162 to retrieve and send administration information.

SNMP OPERATION

SNMP agents that reside on managed devices collect and store information about the devices and their operation. The agent stores this information locally in the MIB. The SNMP administrator then uses the SNMP agent to access the information within the MIB.
There are two main SNMP administrator requests: get and set.

  • NMS uses a get request to request data from the device.
  • NMS uses an established request to change the configuration variables on the agent's device. A set request can also initiate actions within a device. For example, a set request can cause a router to restart, send or receive a configuration file.

The SNMP administrator uses the actions of the get and set requests to perform the operations described in the table:
SNMP Operations Table.
OperationDescription
get-requestRetrieve a value of a specific variable.
get-next-requestRetrieves a value of a variable within a table; The SNMP administrator does not need to know the exact name of the variable. A sequential search is performed to find the necessary variable within a table.
get-bulk-requestIt retrieves large blocks of data, such as several rows in a table, that would otherwise require the transmission of many small blocks of data. (Only works with SNMPv2 or newer).
get-responseIt responds to a get-request, get-next-request and set-request operation sent by NMS.
set-requestStores a value in a specific variable.
The SNMP agent responds to SNMP administrator requests as follows:

  • Obtain an MIB variable : The SNMP agent performs this function in response to an NMS get request PDU. The agent retrieves the value of the requested MIB variable and responds to NMS with that value.
  • Set a MIB variable : The SNMP agent performs this function in response to an NMS set request PDU. The SNMP agent changes the value of the MIB variable to the value specified by NMS. The SNMP agent response to a set request includes the new configuration on the device.

SNMP AGENT TRAPS

NMS periodically polls SNMP agents that reside on managed devices to request data from devices through the get request. With this process, a network management application can collect information to control traffic loads and verify the configurations of managed devices.
The information can be displayed through the NMS GUI. You can calculate the averages, the minimums or the maximums, graph the data or set thresholds to activate a notification process when the thresholds are exceeded.
For example, NMS can control the CPU usage of a Cisco router. The SNMP administrator periodically tests the value and presents this information in a graph so that the network administrator uses it to create a baseline.
SNMP periodic polling has disadvantages:

  • There is a delay between the moment at which an event occurs and the moment when NMS warns of it (by polling).
  • There is a level of balance between the frequency of the poll and the use of bandwidth.

To mitigate these disadvantages, SNMP agents may generate and send traps to inform NMS about certain events immediately.

USE OF AN SNMP TRAP

Traps are unsolicited messages that alert the SNMP administrator about a condition or event on the network. Some examples of trap conditions include, but are not limited to, incorrect user authentication, reboots, link status (active or inactive), MAC address tracking, closing a TCP connection, loss of connection to a Neighbor or other important events.
Trap notifications reduce network and agent resources by eliminating the need for some of the SNMP polling requests.

In Image, the use of an SNMP trap to alert the network administrator that the G0 / 0 interface failed is shown. The NMS software can send a text message to the network administrator, display a pop-up window in the NMS software or display the router icon in red in the NMS GUI.

SNMP VERSIONS

There are several versions of SNMP, including the following:

  • SNMPv1 : The simple network management protocol, a complete Internet standard, is defined in RFC 1157.
  • SNMPv2c : defined in RFCs 1901 to 1908; uses the administrative framework based on community chains.
  • SNMPv3 : interoperable protocol based on standards originally defined in RFCs 2273 to 2275; Provides secure access through authentication and encryption of packets across the network.

All versions use SNMP managers, SNMP agents and MIB. Cisco IOS software supports the three versions mentioned above.
Unlike SNMPv1, SNMPv2c includes a mass recovery mechanism and more detailed error message reports for management stations.
The most up-to-date description of SNMPv3 is found in RFCs 3410 to 3415. It adds methods to ensure the secure transmission of important data between managed devices.
SNMPv3 provides both models and security levels. A security model is an authentication strategy configured for a user and the group within which the user resides. A security level is the level of security allowed within a security model.
The combination of security level and security model determines what security mechanism is used when handling an SNMP package. The available security models are SNMPv1, SNMPv2c and SNMPv3.
A network administrator must configure the SNMP agent to use the version of SNMP that the management station supports.

COMMUNITY CHAINS

For SNMP to work, NMS must have access to the MIB. To ensure that access requests are valid, there must be some form of authentication.
SNMPv1 and SNMPv2c use community strings that control access to the MIB. Community strings are passwords for unencrypted text. SNMP community strings authenticate access to MIB objects.
There are two types of community chains:

  • Read only (ro) : provides access to MIB variables, but does not allow changes to these variables, just read them. Because security is minimal in version 2c, many organizations use SNMPv2c in read-only mode.
  • Read and write (rw) : provides read and write access to all objects in the MIB.

To view or set MIB variables, the user must specify the corresponding community string for read or write access.

STEPS TO CONFIGURE SNMP

A network administrator can configure SNMPv2 to obtain network information from network devices:

  1. Step 1 . (Required) Configure the community string and access level (read or read and write only) using the snmp-server community string ro | rw .
  2. Step 2 . (Optional) Register the device location using the snmp-server location text command .
  3. Step 3 . (Optional) Register the system contact using the snmp-server contact text command .
  4. Step 4 . (Optional) Restrict SNMP access to NMS hosts (SNMP administrators) that authorizes an ACL: Define the ACL and then name the ACL with the snmp-server community string access-list-number-or-name command . This command can be used to specify the community string and to restrict SNMP access through ACLs. Steps 1 and 4 can be combined in one step, if desired.
  5. Step 5 . (Optional) Specify the recipient of SNMP trap operations with the snmp-server host id-host [ version { 1 | 2c | 3 [ auth | noauth | priv ]}] community-string . By default, no trap manager is defined.
  6. Step 6 . (Optional) Enable traps on an SNMP agent with the snmp-server enable traps notification-types command . If no type of trap notification is specified in this command, then all types of trap are sent. Repeated use of this command is necessary if a certain subset of trap types is desired.

All basic steps to configure SNMP are performed in global configuration mode:

R1 (config) # snmp-server community batonaug ro SNMP_ACL 
R1 (config) # snmp-server location NOC_SNMP_MANAGER 
R1 (config) # snmp-server contact Wayne World 
R1 (config) # snmp-server host 192.168.1.3 version 2c batonaug 
R1 ( config) # snmp-server enable traps 
R1 (config) # ip access-list standard SNMP_ACL 
R1 (config-std-nacl) # permit 192.168.1.3

VERIFICATION OF SNMP CONFIGURATION

There are several software solutions to see the SNMP result. For our purposes, the Kiwi syslog server shows the SNMP messages associated with SNMP traps.
PC1 and R1 are configured to demonstrate the result in an SNMP manager in relation to SNMP traps. IP address 192.168.1.3/24 was assigned to PC1. The Kiwi syslog server is installed on PC1.
After R1 is configured, every time an event occurs that qualifies as a trap, SNMP traps are sent to the SNMP administrator. For example, if an interface is activated, a trap is sent to the server. Configuration changes on the router also activate the sending of SNMP traps to the SNMP administrator.
Can you see a list of more than 60 types of trap notification with the snmp-server enable traps command ? . In the configuration of R1, no type of trap notification is specified in the snmp-server enable traps notification-types command , so all traps are sent.

SNMP Manager

In Image 12, a check box was activated in the Setup menu to indicate that the network administrator wants the SNMP manager software to listen to detect SNMP traps on UDP port 162.

SNMP VERIFICATION COMMANDS

To verify the SNMP configuration, use any variant of the show snmp command in privileged EXEC mode. The most useful command is simply the show snmp command, as it shows the information that is usually of interest when examining the SNMP configuration.
Unless an SNMPv3 configuration is involved, most other command options only show selected parts of the show snmp command result .
The result of the show snmp command does not show information related to the SNMP community string or, if applicable, to the associated ACL. Figure 5 shows the information of the SNMP community string and the ACL using the show snmp community command .

RECOMMENDED SECURITY PRACTICES

While SNMP is very useful for monitoring and troubleshooting, it can also create security vulnerabilities. For this reason, before implementing SNMP, consider security best practices.

SNMPv1 and SNMPv2c rely on SNMP community strings in unencrypted text to authenticate access to MIB objects. These community chains, like all passwords, must be chosen carefully to ensure that they are not too easy to crack.
In addition, community chains should be changed at regular intervals and in accordance with network security policies. For example, chains must be changed when a network administrator changes roles or leaves the company. If SNMP is used only to monitor devices, use read-only communities.
Make sure SNMP messages do not spread beyond management consoles. ACLs must be used to prevent SNMP messages from being sent beyond the required devices.
SNMPv3 is recommended because it provides authentication and security encryption. There are other global configuration mode commands that a network administrator can implement to take advantage of authentication and encryption in SNMPv3:

  • The snmp-server group groupname { v1 | v2c | v3 { auth | noauth | priv }} creates a new SNMP group on the device.
  • The snmp-server user username groupname v3 [ encrypted ] [ auth { md5 | sha } auth-password ] [ priv { des | 3des | aes { 128 | 192 | 256 }} priv-password ] is used to add a new user to the SNMP group specified in the snmp-server group ngroupname command .


Thursday, 14 November 2019

Cisco SYSLOG Configuration Complete Tutorial

Cisco SYSLOG Configuration Complete Tutorial

This tutorial is a complete guide on Cisco SYSLOG Configuration, what is syslog and how syslog works . In addition, how to configure syslog to collect messages on a small to medium-sized network management device.
Monitoring a functioning network can provide information to a network administrator to proactively manage the network and report network usage statistics to others. Link activity, error rates and link status are some of the factors that help a network administrator determine the status and use of a network. Collecting and reviewing this information over time allows a network administrator to view and project the growth, and can help detect and replace a defective part before it fails completely.
This chapter covers three protocols that a network administrator can use to control the network. Syslog, SNMP and NetFlow are popular protocols with different strengths and weaknesses. Together they provide a good set of tools to understand what happens in a network.
The NTP protocol is used to synchronize the time across the devices, which is especially important when trying to compare the log files of different devices.

What is SYSLOG ?

When certain events occur on a network, network devices have trusted mechanisms to notify detailed system messages to the administrator. These messages may be important or not.
Network administrators have a variety of options for storing, interpreting and displaying these messages, as well as for receiving those messages that could have the greatest impact on the network infrastructure.
The most common method of accessing system messages provided by network devices is to use a protocol called " syslog ".

Syslog uses UDP port 514 to send event notification messages over IP networks to event message collectors.
The term "syslog" is used to describe a standard. It is also used to describe the protocol developed for that standard. The syslog protocol was developed for UNIX systems in the 1980s, but IETF first registered it as RFC 3164 in 2001 .
Many network devices support syslog, including routers, switches, application servers, firewalls and other network devices. The syslog protocol allows network devices to send system messages to syslog servers across the network. It is possible to set up a special out-of-band network (OOB) for this purpose.
There are several different software packages of syslog servers for Windows and UNIX. Many of them are freeware.
The syslog logging service provides three main functions:

  • The ability to collect registration information for problem control and resolution
  • Ability to select the type of registration information that is captured
  • The ability to specify the destinations of captured syslog messages

How SYSLOG Works

On Cisco network devices, the syslog protocol begins by sending system messages and the debug command result to an internal local device registration process. The way in which the registration process manages these messages and results is based on the device settings.
For example, syslog messages can be sent over the network to an external syslog server. These messages can be retrieved without having to access the device itself. The results and log messages stored on the external server can be included in several reports for easy reading.
On the other hand, syslog messages can be sent to an internal buffer. Messages sent to the internal buffer can only be viewed through the device CLI.

Finally, the network administrator can specify that only certain types of system messages be sent to several destinations. For example, you can configure the device to forward all system messages to an external syslog server. However, debug level messages are forwarded to the internal buffer, and only the administrator can access them from the CLI.
As shown in the illustration, common destinations for syslog messages include the following:

  • Logging buffer (RAM inside a router or switch)
  • Console line
  • Terminal line
  • Syslog server

It is possible to control system messages remotely by viewing the logs on a syslog server or accessing the device through Telnet, SSH or through the console port.

 FORMAT OF SYSLOG MESSAGES

Cisco devices generate syslog messages as a result of network events. Each syslog message contains a severity level and an installation .

SYSLOG SEVERITY LEVEL

The lower the level numbers, the more fundamental the syslog alarms. The severity level of the messages can be set to control where each type of message is displayed (that is, on the console or other destinations). In Image 3, the complete list of syslog levels is shown.

Each level of syslog has its own meaning:

  • Warning level, emergency level : these are error messages about software or hardware that is malfunctioning; These types of messages mean that the functionality of the device is affected. The severity of the problem determines the actual level of syslog that is applied.
  • Debug level: This level indicates that the messages are results that are generated from the issuance of several debug commands .
  • Notification level: the notification level only provides information, the functionality of the device is not affected. Interface messages active or inactive, or system restart are displayed at the notification level.

INSTALLATION INFORMATION

In addition to specifying severity, syslog messages also contain information about the installation. Syslog installations are service identifiers that identify and categorize system status data to report error and event messages.
The available registry installation options are specific to the network device. For example, Cisco 2960 series switches and Cisco 1941 routers support 24 installation options that are categorized into 12 types of installation.
Some common syslog message installations that are reported on Cisco IOS routers include the following:


By default, the format of syslog messages in Cisco IOS software is as follows:
seq no: timestamp:% facility-severity-MNEMONIC: description
For example, the example result of a Cisco switch for an EtherChannel link that changes to the active state is as follows:
00:00:46:% LINK-3-UPDOWN: Interface 
Port-channel1, changed state to up
Here the installation is LINK, and the severity level is 3, with the UPDOWN MNEMOTECHNICAL.
The most common messages are the active link and the inactive link, and the messages that a device produces when it exits configuration mode. If the ACL log is configured, the device generates syslog messages when the packets match a parameter condition.

SERVICE TIME STAMP

Log messages can be marked with the time, and the source address of syslog messages can be set. This improves debugging and administration in real time.
When the global service timestamps log uptime configuration mode command is entered , the amount of time that has elapsed since the last time the switch was started in the logged events is displayed. A more useful version of this command applies the datetime keyword instead of the uptime keyword ; This causes each registered event to show the date and time associated with the event.
When the datetime keyword is used , the clock must be set on the network device. This can be achieved in two ways:

  • Manual configuration using the clock set command
  • Automatic configuration using the NTP protocol

To allow an NTP time server to synchronize the software clock, use the global configuration mode command:
ntp server  ip-address
In the illustration, an example configuration is shown. R1 is configured as an NTP client, while router R2 functions as an authoritative NTP server. A network device can be configured as an NTP server, so that the other devices synchronize outside their time, or as an NTP client.

R2 (config) # ntp master 1
R1 (config) # ntp server 10.1.1.1
For the rest of the chapter, it is assumed that the clock was set and the service timestamps log datetime command was configured on all devices.

SYSLOG SERVER

To view syslog messages, a syslog server must be installed on a network workstation. There are several versions of freeware and shareware of syslog, as well as business versions to buy.
The syslog server provides a relatively user-friendly interface to see the result of syslog. The server analyzes the result and places the messages in predefined columns to interpret them easily.

Network administrators can easily navigate through a large amount of data that is collected on a syslog server. An advantage of viewing syslog messages on a syslog server is the ability to perform granular searches through the data. In addition, a network administrator can quickly remove syslog messages that are not important from the database.

DEFAULT REGISTRATION

By default, Cisco routers and switches send log messages to the console for all severity levels. In some versions of IOS, the device also buffers log messages by default. To enable these two settings, use the global logging console and logging buffered configuration commands , respectively.
The show logging command shows the default configuration of the registration service on a Cisco router, as shown in the illustration. In the first lines of the result, information about the registration process is provided, and at the end of the result the registration messages are indicated.

  • In the highlighted first line, it is indicated that this router is registered in the console and debug messages are included. This actually means that all debug level messages, as well as any lower level messages (such as notification level messages), are logged in the console. The result also indicates that 32 of these messages were recorded.
  • In the second highlighted line, it is indicated that this router is registered in an internal buffer. Since registration on an internal buffer was enabled on this router, the show logging command also indicates the messages in that buffer.

ROUTER AND SWITCH COMMANDS FOR SYSLOG CLIENTS

There are three steps to configure the router to send system messages to a syslog server where they can be stored, filtered and analyzed:

  • Step 1 . Configure the name of the destination host or the IP address of the syslog server in global configuration mode:

R1 (config) # logging 192.168.1.3

  • Step 2 . Control the messages that are sent to the syslog server with the global configuration mode logging trap level command . For example, to limit messages to levels 4 and below (0 to 4), use one of two equivalent commands:

R1 (config) # logging trap 4
R1 (config) # logging trap warning

  • Step 3 . Optionally, configure the source interface with the global configuration mode command:

logging source-interface  interface-type interface number
This specifies that syslog packets include the IPv4 or IPv6 address of a specific interface, regardless of the interface the packet uses to exit the router. For example, to set the source interface to g0 / 0, use the following command:

R1 (config) # logging source-interface g0 / 0

SYSLOG CONFIGURATION EXAMPLE

In Image 8, R1 was configured to send log messages of levels 4 and below to the syslog server at 192.168.1.3. The source interface was established in the G0 / 0 interface. A loopback interface is created, deactivated and reactivated. The result of the console reflects these actions.

The only messages that appear on the syslog server are those with a severity level of 4 or less (more serious). Messages with a severity level of 5 or more (less severe) appear in the result of the router console, but do not appear in the result of the syslog server, because the logging trap command limits the syslog messages that are sent to the syslog server according to severity level.

VERIFICATION OF SYSLOG

You can use the show logging command to view any message that is logged. When the registration buffer is large, it is convenient to use the vertical bar option (|) with the show logging command. The vertical bar option allows the administrator to specifically indicate which messages should be displayed.
For example, by issuing the show logging | include changed state to up , it is ensured that only interface notifications showing " changed state to up " are displayed .
In Image , it is also shown that by issuing the show logging | begin June 12 22:35 shows the contents of the registration buffer that occurred on June 12 or after this date.

What is NAT and how does it work ?

What is NAT and how does it work ?

This section explains What is NAT(Network Address Translation) and how does it work, as well as its characteristics. All public IPv4 addresses used on the Internet must be registered in a regional Internet registry (RIR). Organizations can lease public addresses from an SP, but only the registered owner of a public Internet address can assign that address to a network device.
However, with a theoretical maximum of 4300 million addresses, the IPv4 address space is very limited. When Bob Kahn and Vint Cerf first developed the TCP / IP protocol suite that included IPv4 in 1981, they never imagined what the Internet could become.
With the proliferation of personal computing devices and the arrival of the World Wide Web, it soon became clear that the 4300 million IPv4 addresses would not be enough. The long-term solution was the IPv6 protocol, but more immediate solutions were needed. In the short term, the IETF implemented several solutions, including translation of network addresses (NAT) and private IPv4 addresses defined in RFC 1918 .

PRIVATE IPV4 ADDRESS SPACE

There are not enough public IPv4 addresses to assign a unique address to each device connected to the Internet. Networks are usually implemented through the use of private IPv4 addresses, as defined in RFC 1918. The following table shows the range of addresses included in RFC 1918.
Table of private IPv4 addresses.
ClassInternal Address Range RFC 1918CIDR prefix
TO10.0.0.0 to 10.255.255.25510.0.0.0/8
B172.16.0.0 to 172.31.255.255172.16.0.0/12
C192.168.0.0 to 192.168.255.255192.168.0.0/16
These private addresses are used within an organization or a site to allow devices to communicate locally. However, since these addresses do not identify individual companies or organizations, private IPv4 addresses cannot be routed over the Internet .
To allow a device with a private IPv4 address to access resources and devices outside the local network, the private address must first be translated into a public address .
NAT provides the translation of private addresses to public addresses. This allows a device with a private IPv4 address to access resources outside its private network, such as those found on the Internet.
A single public IPv4 address can be shared among hundreds or even thousands of devices, each configured with an exclusive private IPv4 address.

WHAT IS NAT?

NAT (Network Address Translation) has many uses, but the main one is to keep public IPv4 addresses . This is achieved by allowing networks to use private IPv4 addresses internally and by providing translation to a public address only when necessary.
NAT has the additional benefit of providing some degree of privacy and additional security to a network, since it hides the internal IPv4 addresses of external networks.
Routers with NAT enabled can be configured with one or more valid public IPv4 addresses. These public addresses are known as " NAT set ".
When an internal device sends out-of-network traffic, the router with NAT enabled translates the device's internal IPv4 address to a public address in the NAT set. For external devices, all incoming and outgoing network traffic appears to have a public IPv4 address from the set of addresses provided.

In general, NAT routers work at the border of an internal route network. An internal route network is one that has a single connection to its neighboring network, an entrance to the network and an exit from it. In the example in Image 2, R2 is a border router. Viewed from the ISP, R2 forms a network of internal routes.
When a device within the internal route network wishes to communicate with a device outside its network, the packet is forwarded to the border router. The border router performs the NAT process, that is, it translates the internal private address of the device to a public, external and routable address.

NAT TERMINOLOGY

According to NAT terminology, the internal network is the set of networks subject to translation. The external network refers to all other networks.
When using NAT, IPv4 addresses are designated differently, depending on whether they are on the private network or on the public network (Internet), and whether the traffic is inbound or outbound.
NAT includes four types of addresses:

  • Internal Local Address
  • Global Global Address
  • External local address
  • Global external address

When determining what type of address is used, it is important to remember that NAT terminology is always applied from the perspective of the device with the translated address:

  • Inside Local address : the address of the device that is translated through NAT.
  • Inside Global address : the address of the destination device.

NAT uses the concepts of local or global in relation to addresses:

  • Outside Local address : any address that appears in the internal portion of the network.
  • outside Global address : any address that appears in the outer portion of the network.


In the illustration, PC1 has the internal local address 192.168.10.10. From the perspective of PC1, the web server has the external address 209.165.201.1. When packets from PC1 are sent to the global web server address, the internal local address of PC1 is translated to 209.165.200.226 (internal global address). In general, the external device address is not translated (usually public IPv4 address).

  1. PC1 has different local and global addresses, while the web server has the same public IPv4 address in both cases. From the perspective of the web server, the traffic originating in PC1 seems to come from 209.165.200.226 (internal global address).
  2. The NAT (R2) router is the demarcation point between internal and external networks; and, local and global addresses.

INTERNAL, EXTERNAL, GLOBAL AND LOCAL TERMS

The terms "internal" and "external" are combined with the terms "global" and "local" to refer to specific addresses. In the illustration, router R2 was configured to provide NAT. This has a set of public addresses to assign to internal hosts.


  • Inside local address : the source address seen from inside the network. In the illustration, IPv4 address 192.168.10.10 was assigned to PC1. This is the internal local address of PC1.
  • Inside Global address: the source address seen from the external network. In the illustration, when traffic from PC1 is sent to the web server on 209.165.201.1, R2 translates the internal local address to an internal global address. In this case, R2 changes the source IPv4 address from 192.168.10.10 to 209.165.200.226. According to NAT terminology, the internal local address 192.168.10.10 is translated to the internal global address 209.165.200.226.
  • Outside Global address: the destination address seen from the external network. It is a globally routable IPv4 address and assigned to a host on the Internet. For example, the web server can be reached at IPv4 address 209.165.201.1. In general, global and local external addresses are the same.
  • Outside local address : the address of the destination seen from the internal network. In this example, PC1 sends traffic to the web server at IPv4 address 209.165.201.1. While it is rare, this address may be different from the globally routable address of the destination.
The illustration shows how traffic that is sent from an internal computer is directed to an external web server through the router with NAT enabled. It also shows how return traffic is directed and translated initially.

HOW DOES NAT WORK?

In this example, PC1 with private address 192.168.10.10 wishes to communicate with an external web server with public address 209.165.201.1.


  • PC1 sends a packet addressed to the web server. R1 forwards the packet to R2.
  • When the packet arrives at R2, the router with NAT enabled for the network, R2 reads the source IPv4 address of the packet to determine if it meets the criteria specified for translation.
  • In this case, the source IPv4 address meets the criteria and translates from 192.168.10.10 (internal local address) to 209.165.200.226 (internal global address). R2 adds this local to global address assignment to the NAT table.
  • R2 sends the packet with the translated source address to the destination.
  • The web server responds with a packet addressed to the internal global address of PC1 (209.165.200.226).
  • The R2 receives the packet with the destination address 209.165.200.226. Review the NAT table and find an entry for this assignment. R2 uses this information and translates the internal global address (209.165.200.226) to the internal local address (192.168.10.10), and the packet is forwarded to PC1.

Sunday, 10 November 2019

Backup Cisco IOS image to TFTP Server | Copy Image in Flask

Backup Cisco IOS image to TFTP Server | Copy Image in Flask

In this post we will explain how to Backup Cisco IOS image to TFTP Server or how to copy IOS Image in Router Flash. Using TFTP server you can take backup Cisco configurations and save Cisco Image as well.

TFTP SERVERS AS BACKUP LOCATION

As a network grows, the Cisco IOS software configuration images and files can be stored on a central TFTP server. This helps control the amount of IOS images and revisions to those IOS images, as well as the configuration files that must be maintained.
Production internetworks usually cover large areas and contain several routers. For any network, it is advisable to have a backup copy of the Cisco IOS software image in case the system image on the router is damaged or accidentally deleted.
Widely distributed routers need a source or backup location for Cisco IOS software images. The use of a network TFTP server allows uploads and downloads of the image and configuration through the network. The network TFTP server can be another router, a workstation or a host system.

Creating Cisco IOS Image Backup

To maintain network operations with minimal downtime, it is necessary to implement procedures to back up Cisco IOS images.

In following figure, the network administrator wishes to back up the current image file on the router ( c1900-universalk9-mz.SPA.152-4.M3.bin ) on the TFTP server at 172.16. 1,100. You can learn the Cisco IOS name convention here.
To back up the Cisco IOS image on a TFTP server, follow these three steps:

  • Step 1 . Make sure there is access to the network TFTP server. Ping the TFTP server to test connectivity.

R1 # ping 172.16.1.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.100, timeout is 2 
seconds:
!!!!!
Success rate is 100 percent (5/5),
round-trip min / avg / max = 56/56/56 ms

  • Step 2 . Verify that the TFTP server has enough disk space to support the Cisco IOS software image. Use the show flash0: command on the router to determine the size of the Cisco IOS image file. The sample file is 68831808 bytes in length.

R1 # show flash0:
- # - --length-- ----- date / time ------ path
8 68831808 Apr 2 2017 21:29:58 +00: 00 
            c1900-universalk9-mz.SPA.152-4.M3.bin

  • Step 3 . Copy the image to the TFTP server using the copy source-url destination-url command.
R1 # copy flash0: tftp: 
Source filename []? c1900-universalk9-mz.SPA.152-4.M3.bin
Address or name of remote host []? 172.16.1.100
Destination filename [c1900-universalk9-mz.SPA.152-4.M3.bin]?
Writing c1900-universalk9-mz.SPA.152-4.M3.bin ...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
68831808 bytes copied in 363,468 secs (269058 bytes / sec)
After issuing the command using the specified source and destination URLs, the user is requested to enter the name of the source file, the IP address of the remote host and the name of the destination file. Then the transfer starts.

Copying a Cisco IOS Image to TFTP Server

In this example, IPv6 is used for transfer, to show that TFTP can also be used over IPv6 networks.
Image illustrates how to copy an image of Cisco IOS software from a TFTP server. A new image file ( c1900-universalk9-mz.SPA.152-4.M3.bin ) will be copied from the TFTP server in 2001: DB8: CAFE: 100 :: 99 to the router.

Follow these steps to update the software on the Cisco router:

  • Step 1 . Select a Cisco IOS image file that meets the requirements in terms of platform, features and software. Download the file from cisco.com and transfer it to the TFTP server.
  • Step 2 . Verify connectivity to the TFTP server. Ping the TFTP server from the router.

R1 # ping 2001: DB8: COFFEE: 100 :: 99
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001: DB8: CAFE: 100 :: 99,
timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5),
round-trip min / avg / max = 56/56/56 ms


  • Step 3 . Make sure there is enough space in the flash memory on the router that is updated. You can check the amount of available flash memory using the show flash0: command .

R1 # show flash0:
- # - --length-- ----- date / time ------ path
182394880 bytes available (74092544 bytes used)
R1 #

  • Step 4 . Copy the IOS image file from the TFTP server to the router with the copy command .

After issuing this command with the specified destination and source URLs, the user will be asked to enter the IP address of the remote host, the name of the source file and the name of the destination file. File transfer will start.

BOOT SYSTEM COMMAND

To update the copied IOS image once that image is saved in the router's flash memory, configure the latter to load to a new image during boot using the boot system command.
Save the configuration . Reload the router to boot with the new image. Once you start the router, use the show version command to verify that the new image was loaded.
During boot, the bootstrap code analyzes the boot configuration file in the NVRAM to detect boot system commands that specify the name and location of the Cisco IOS software image to load. Several boot system commands can be entered sequentially to provide a boot plan that has fault tolerance.

  • As shown below, the boot system command is a global configuration command that allows the user to specify the source for the Cisco IOS software image to load.

R1 # configure terminal
R1 (config) # boot system 
 flash0: //c1900-universalk9-mz.SPA.152-4.M3.bin
R1 (config) # exit
R1 # copy running-config startup-config
R1 # reload
Among the available syntax options are the following:

  • Specify the flash device as the source of the Cisco IOS image:

Router (config) # boot system flash0: //c1900-universalk9-mz.SPA.152-4.M3.bin
Specify the TFTP server as the source of the Cisco IOS image, with ROMmon as backup.
Router (config) # boot system tftp: //c1900-universalk9-mz.SPA.152-4.M3.bin
If there are no boot system commands in the configuration, by default, the router loads and runs the first valid Cisco IOS image in flash memory.
Finally, as shown in Image, the show version command can be used to verify the software image file.

Cisco IOS Naming Convention T 12.0 to M 15.0

Cisco IOS Naming Convention T 12.0 to M 15.0

This chapter will give you a brief introduction about Cisco IOS Naming Convention. Cisco IOS (initial Internetwork Operating System) is software that is used in most Cisco routers and switches. IOS is a package of routing, switching, security and other internetworking technologies integrated in a single multitasking operating system. The Cisco IOS portfolio supports a wide range of technologies and features. Clients choose an IOS based on a group of protocols and features supported by a particular image. Understanding the Cisco IOS feature set portfolio is useful in selecting the right IOS to meet the needs of an organization. Cisco made significant changes to the IOS software packages and licenses by making the transition from IOS 12.4 to 15.0 .

Cisco IOS Software Release Families and Trains

Cisco IOS software evolved from a single platform operating system for routing to a sophisticated operating system that supports a broad array of features and technologies, such as VoIP, NetFlow and IPsec . To better meet the requirements of the different market segments, the software is organized into families of software versions and software streams. A family of software versions consists of several versions of the IOS software that have the following characteristics:

  • They share a code base.
  • They apply to related hardware platforms.
  • They overlap in compatibility coverage (when the life of an OS ends, another OS is introduced and supported).

Examples of Cisco IOS software versions, within a family of software versions, are 12.3, 12.4, 15.0 and 15.1 .
Along with each version of the software, there are new versions of the software created to implement bug fixes and new features. In IOS, these versions are called " trains ."
A Cisco IOS train is used to release versions with a common code base to a specific set of platforms and features. A train can contain several versions , and each version is a snapshot of the train code base at the time of launch. Because different families of software versions can be applied to various platforms or market segments, several trains can be in effect at any time.

Cisco IOS 12.4 Mainline and T Trains

The illustration shows the migration of software version 12.3 to 12.4. Within a family of software versions, there may be one or two closely related active trains.

The relationships between the version of the mainline train 12.4 and the 12.4T train of the Cisco IOS software are shown.
For example, the Cisco 12.4 IOS software family has two trains, 12.4T trains and 12.4 mainline trains.

Cisco IOS 12.4 TRAINS 

The Cisco 12.4 IOS software train is considered the mainline train. The mainline train receives mostly software corrections (errors) in order to improve its quality. The mainline train versions are also called " Maintenance Implementation (MD) versions ."
A mainline train is always associated with a technology train (T train). A T train, such as 12.4T, receives the same software bug fixes as the mainline train. The T train also receives new hardware and software compatibility features. The versions on the 12.4T train of Cisco IOS software are considered Early Deployment (ED) versions .
There may be other trains, depending on the family of the software version. For example, another available train is the service provider (train S) . An S train contains specific features designed to meet the requirements of service providers. All secondary trains on the mainline train (T, S, etc.) usually have an uppercase letter that designates the type of train.
Main Line Train = 12.4
T train: 12.4T 
(12.4 + new hardware and software compatibility features)
Until the family of version 12.4 of Cisco IOS software inclusive, the mainline trains and the T trains were separated.
In other words, from the mainline train, a T train branched out and became an independent code base that received new features and hardware compatibility. Over time, a new mainline train evolved from an established T train, and the cycle began again.
The use of several trains was modified with version 15 of the Cisco IOS software.

Cisco IOS 12.4 Mainline and T Numbering

The Cisco IOS version numbering convention is used to identify the version of the IOS software, including bug fixes and new software features. In the illustration, an example of the numbering scheme for the main line trains and for the T trains is shown:


  • The software version numbering scheme for a mainline train consists of a train number, a maintenance identifier and a collection identifier.

For example, version 12.4 (21a) of Cisco IOS software is a mainline train. The version for a train T consists of a train number, a maintenance identifier, a train identifier and a collection identifier. For example, version 12.4 (20) T1 of Cisco IOS software belongs to train 12.4T of Cisco IOS software.

  • Each maintenance identifier of the Cisco IOS 12.4 main line of software, such as 12.4 (7), includes additional maintenance and software fixes. This change is indicated by the number in parentheses.

Each maintenance release of Cisco 12.4T IOS software, such as 12.4 (20) T, includes these same software fixes, along with additional software features and hardware compatibility.

  • Cisco uses collections of an individual version to integrate corrections of important problems. A collection typically includes corrections for a limited number of software defects, known as warnings. It is indicated with a lowercase letter inside the parenthesis of the mainline trains or with a final number on other trains.

For example, version 12.4 (21) of Cisco IOS software received some warning fixes, and the resulting collection was named 12.4 (21a). Similarly, 12.4 (15) T8 is the eighth collection of 12.4 (15) T

SINGLE VERSION NUMBERS

A unique set of individual version numbers is used for all trains 12.4 of the Cisco IOS software. Maintenance version 12.4 and version 12.4T use a pool of individual version numbers that are shared throughout the family of version 12.4 of that software. Version 12.4 (6) T of the Cisco IOS software was followed by version 12.4 (7) T and version 12.4 (8) T. This allows the administrator to track changes made to the code.

CISCO IOS SYSTEM IMAGE PACKAGES 12.4

Prior to version 15.0 of Cisco IOS software, that software had eight packages for Cisco routers, as shown in the illustration.
The package scheme was introduced with the mainline train 12.3 of the Cisco IOS software, and was subsequently used on other trains. Image packages consist of eight IOS images, three of which are considered higher packages.
The five non-superior packages are as follows:

  1. IP Base : is the basic image of Cisco IOS software.
  2. Voice over IP : converging voice and data, VoIP, VoFR and IP telephony.
  3. Advanced Security : VPN and security features, including Cisco IOS firewall, IDS / IPS, IPsec, 3DES and VPN.
  4. Service provider services (SP) : Add SSH / SSL, ATM, VoATM and MPLS to Voice over IP.
  5. Base for companies : protocols for companies (Appletalk, IPX and IBM Support).

Three other superior packages offer additional combinations of IOS software features that address more complex network requirements.
All features are merged into the Advanced Enterprise Services package. This package integrates support for all routing protocols with Voice, Security and VPN capabilities:

  • Advanced Enterprise Services : complete feature set of Cisco IOS software
  • Enterprise Services : base for business and service provider services
  • Advanced IP Services : advanced security, service provider services and IPv6 support

CISCO 15.0 IOS M AND T TRAINS

After Cisco IOS version 12.4 (24) T, the next version of Cisco IOS software was 15.0.
IOS 15.0 provides several improvements to the operating system, for example:

  • New hardware and feature compatibility
  • Greater consistency of features with other major versions of IOS
  • Version of new features and more predictable collection programs
  • Compatibility policies for proactive individual versions
  • Simplified Version Numbering
  • Clearer migration and software implementation guidelines

As shown in the illustration, Cisco IOS 15.0 uses a different version model of traditional 12.4 independent T and mainline trains.

Instead of being divided into independent trains, the T 15 and mainline trains of the Cisco 15 IOS software will have extended maintenance version (EM version) and standard maintenance version (T version) . With the new IOS version model, the mainline versions of the Cisco 15 IOS are called " M trains ."
Starting with 15.0, new versions in the form of a T train are available approximately two to three times per year. EM versions are available approximately every 16 to 20 months . The T versions allow you to receive the Cisco feature more quickly, before the next EM version is available.
An EM version incorporates the feature and hardware compatibility of all previous T versions. This makes the latest versions of EM contain the total functionality of the train at the time of launch.

CISCO IOS TRAIN NUMBERING 15

The version numbering convention for IOS 15 allows you to identify the specific IOS version, including bug fixes and new software features, similar to families of previous IOS versions. The illustration shows examples of this convention for the EM version and the T version.

EXTENDED MAINTENANCE VERSION

The EM version is ideal for long-term maintenance , and allows customers to meet the requirements, implement the version and maintain it for an extended period. The mainline train incorporates features provided in previous versions and further improvements to incremental features and hardware compatibility.
The first maintenance collection (for bug fixes only, without new features or new hardware compatibility) of version 15.0 (1) M bears the number 15.0 (1) M1. Subsequent maintenance versions are defined by an increase in the maintenance collection number (e.g., M2, M3, etc.).

STANDARD MAINTENANCE VERSION

The T version is used for short deployment versions ideal for the latest features and hardware compatibility before the next version of EM is available. Version T provides regular error correction maintenance collections and critical error support for errors affecting the network, such as Product Security Incident Reporting Equipment (PSIRT) problems.
The first version of new features 15 T planned carries the version number 15.1 (1) T. The first maintenance collection (for bug fixes only, without new features or new hardware compatibility) of version 15.1 (1) T will bear the number 15.1 (1) T1. Later versions are defined by an increase in the maintenance collection number (e.g., T2, T3, etc.).

 IOS 15 SYSTEM IMAGE PACKAGES

The Cisco second generation integrated service router series (ISR G2) 1900, 2900 and 3900 support services on demand through the use of software licenses.
The Services on demand process allows customers to achieve operational savings through ease of ordering and software management. When an order for a new Cisco G2 ISR platform is placed, the router ships with a unique and universal image of Cisco IOS software, and a license is used to enable specific feature set packages, as shown in Image:

There are two types of universal images supported in ISR G2:

  • Universal images with the designation “universalk9” in the name of the image : this universal image offers all the features of Cisco IOS software, including secure content cryptography features, such as IPsec VPN, SSL VPN and secure unified communications.
  • Universal images with the designation “universalk9_npe” in the name of the image : secure compliance with the encryption capabilities provided by Cisco Software Activation meets the requirements for exporting encryption capabilities.

Some countries have import requirements that require that the platform does not support any secure cryptography functionality, such as content cryptography.
With the ISR G2 devices, the selection of the IOS image was facilitated, because all the features within the universal image are included. The features are activated by licenses (product activation key - PAK). Each device ships with universal image.
Figure shows the suggested migration for the next generation ISRs from IOS 12 (IOS reform packages) to IOS 15 (simplified packages).

IOS IMAGE FILE NAMES

The Cisco IOS image file is based on a special naming convention. The name of the Cisco IOS image file contains several parts, each with a specific meaning. It is important to understand this naming convention when updating and selecting a Cisco IOS software.
As shown in Image 8, the show flash command shows files stored in flash memory, including system image files.

IMAGE NAME FOR IOS 12.4

In Image, an example of an image name of the IOS 12.4 software is shown.


  • Image name (c2800nm) : Identifies the platform on which the image is executed. In this example, the platform is a Cisco 2800 router with a network module.
  • advipservicesk9 : Specify the feature set. In this example, advipservicesk9 refers to the Advanced IP Services feature set, which includes the service provider and advanced security packages along with IPv6.
  • mz : indicates where the image is executed and if the file is compressed. In this example, "mz" indicates that the file runs from RAM and is compressed.
  • 124-6.T : indicates the format of the file name for image 12.4 (6) T. This is the train number, the maintenance version number and the train identifier.
  • bin : the file extension. This extension indicates that this is an executable binary file.

IMAGE NAME FOR IOS 15

In following Image, the different parts of an IOS 15 system image file in an ISR G2 device are illustrated:


  • Image name (c1900) : Identifies the platform on which the image is executed. In this example, the platform is a Cisco 1900 router.
  • universalk9 : specifies the designation of the image. The two designations for an ISR G2 are universalk9 and universalk9_npe. Universalk9_npe does not contain secure encryption and is intended for countries with encryption restrictions. Features are controlled by licenses and can be divided into four technology packages: IP Base, Security, Unified Communications and Data.
  • mz : indicates where the image is executed and if the file is compressed. In this example, "mz" indicates that the file runs from RAM and is compressed.
  • SPA : indicates that the file is digitally signed by Cisco.
  • 152-4.M3 : Specifies the format of the file name for image 15.2 (4) M3. This is the IOS version, which includes the numbers of the main version, the secondary version, the maintenance version and the maintenance collection. The M indicates that it is an extended maintenance version.
  • bin : the file extension. This extension indicates that this is an executable binary file.

MEMORY LOCATION AND COMPRESSION FORMAT

The most common designation for memory location and compression format is mz . The first letter indicates the location where the image is executed on the router. The locations may include the following:

  • f : flash
  • m : RAM
  • r : ROM
  • l : relocatable

The compression format can be z for zip or x for mzip. File compression is a method that Cisco uses to compress some images executed from RAM that is effective in reducing image size. It decompresses itself, so that when the image is loaded into RAM to run, the first action is decompression.

MEMORY REQUIREMENTS

On most Cisco routers, even on integrated service routers, the IOS is stored in CompactFlash memory as a compressed image and loaded into the DRAM during startup.
The Cisco IOS software version 15.0 images available for Cisco 1900 and 2900 ISRs require 256 MB of flash memory and 512 MB of RAM. The ISR 3900 requires 256 MB of flash memory and 1 GB of RAM. This does not include additional management tools, such as Cisco Configuration Professional (Cisco CP). For complete details, see the product data sheet for the specific router.