Multi-level virtual testing ground on a personal computer

Article:

Currently, virtualization technologies are an integral part of the IT world. In addition to the industrial application of virtual machine technology, which allows reducing the total cost of ownership of IT infrastructure, which everyone has been writing about for several years now, the technology is also widely used for studying or testing system, network and application software.

Most publications tend to focus on layer 1 virtualization. On one or more physical computers connected by real networks, based on some virtualization software, there are many virtual machines (VMs) connected by virtual networks (also emulated using virtualization software), which, if necessary, communicate with real networks through the network adapters of physical computers. In other words, most often we consider the level of real devices and one level of virtual objects (usually machines on the basis of which certain operating systems operate). True, to be more precise, in the examples discussed in the publications, objects of the second or deeper levels of virtualization are implicitly present, but the authors almost never focus their attention on this.

Let's consider the following network, which was invented solely for the sake of an example, and in itself does not carry any special practical value (everyone can choose any other example for themselves, including from real practice). There are two companies, each with a head office with a server in one geographic location, and a branch office with a workstation in another geographic location. Geographic points are separated by some MPLS-backbone based on Cisco routers. For each company separately, Layer 2 VPN is organized between the head office and the branch using Ethernet over MPLS (EoMPLS) technology to enable “transparent” interaction at the data link level (Ethernet) between the workstation and the server via MPLS-backbone.
The physical structure of the network in question is shown below.

Also shown below is the logical structure of interaction between workstations and servers of the network in question. In each company, the workstation and server can communicate transparently with each other, and are isolated from the other company's workstation and server.

The challenge is that this network needs to be modeled and tested, in particular the interaction of workstations with servers through the EoMPLS environment, and all this must be done with one single personal computer. This is a fairly familiar situation for most specialists in system and network technologies, who are faced with a similar task and who, as a rule, do not have extra computers at hand, much less Cisco routers.

Well, real computers are easily replaced by virtual machines created and launched using one or another software that implements virtual machine technology, for example, the same VMware Workstation 6.0 (in this article the author examines multi-level virtualization using the example of this particular software). The popular Dynamips simulator (as well as a convenient and visual graphical environment for it - GNS3) is well suited for modeling Cisco routers with EoMPLS support. However, a problem arises: you can separately simulate virtual machines with “real” full-featured MS Windows OS installed on them, and separately - Cisco routers with “real” full-featured Cisco IOS OS, but how to link the two simulation environments together over the network?

However, there is a way out of the situation. In VMware Workstation, you can bind VMnet virtual switches to the network adapters of a physical computer (using the Virtual Network Editor utility), and, accordingly, bind virtual network adapters of virtual machines to the corresponding VMnet virtual switches (when configuring a virtual machine). Below is an example of such a binding using the virtual switch VMnet0:

In turn, in the GNS3 environment based on Dynamips there is an object of the “Cloud” type, which can also be projected onto the network adapters of a physical computer. After this, the object can be connected to the network interfaces of other objects in the GNS3 environment, including the interfaces of Cisco routers. It should be especially noted that an object of the “Cloud” type is not, in essence, any full-fledged virtual device - it is just a virtual “junction point” (like a connector on a patch panel), which from a network point of view can be projected onto something, for example, to a computer's network adapter. Looking ahead, we also note that the “Computer” and “Server” objects used in the GNS3 environment are also objects of the “Cloud” type (simple “junction points” with corresponding icons for clarity), and not at all some kind of computer or server emulations using software, as is done, for example, in the Cisco Packet Tracer training simulator.

Below is an example of projecting a Cloud object C0 connected to the network interface of router R0 in a GNS3 environment onto the network adapter of a physical computer:

Inexperienced specialists may be confused by the long code (network transport identifier assigned by MS Windows OS for a network adapter) in the settings, and in order not to get confused in the names of the network connection, the names of the network adapter, the MAC address of the adapter and its identifier, you can use the built-in MS Windows the GETMAC utility, launched with the V key (Verbose - detailed information):

Thus, through such “two-way projection” at the OSI data link layer (essentially Layer 2 Bridging) onto the same network adapter of a physical computer, virtual routers in a GNS3 environment based on Dynamips can interact at the Ethernet level with virtual machines in a VMware Workstation environment (this has been tested experimentally many times). Unfortunately, it is not possible to directly link VMnet switches from a VMware environment with objects of the “Cloud” type (junction points) from GNS3 based on Dynamips over the network (at least, without using any special software).

Now a new problem arises: the number of network “points of contact” between the VMware environment and the Dynamips environment can be far from one, but several (in the example under consideration there are 4 of them - two workstations and two servers), while on a physical computer there can be be one or two or no network adapter at all. In addition, being tied to the network adapters of a physical computer is in any case not the most sensible idea from a security point of view. Finally, we are not particularly trying to place everything on the first level of virtualization; the goal of this article is multi-level virtualization.

In this situation, we will resort to the following simple trick: no one is stopping us from creating another auxiliary virtual machine with the required number of network adapters (as many “contact points” as needed), installing the OS on it, and most importantly, GNS3-based software Dynamips. Then, in GNS3, create, configure and launch the network required for modeling based on Cisco routers. Thus, Cisco routers “move” to the second level of virtualization (the auxiliary virtual machine itself is located on the first). Network "touchpoints" will be implemented through the corresponding "Cloud" objects (interface points) in GNS3 based on Dynamips, bound to the corresponding CISCONET virtual machine network adapters, which in turn are bound to the corresponding VMnet virtual switches, to which we can connect other virtual machines. In our example, we will use a CISCONET helper virtual machine with 4 network adapters (VMware Workstation 6.0 supports up to 10 network adapters per virtual machine) tied to the corresponding VMnet virtual switches.

Thus, we come to two levels of virtualization: VMware infrastructure inside a physical computer (1st level of virtualization), and Dynamips infrastructure inside an auxiliary virtual machine (2nd level of virtualization).

Finally, if we remember that EoMPLS is also a kind of virtualization using Cisco IOS, we will see that in the example under consideration there is also a 3rd level of virtualization. At the 3rd level of virtualization there is a virtual MPLS cloud and virtual circuits on top of this cloud, which are emulated by Cisco IOS on two Cisco routers.

As a result, we get the following multi-level virtualization scheme:

As can be seen from the diagram above, the experimenter’s computer is located at the level of real objects and, from a network point of view, is completely isolated from virtual machines and virtual routers, which is quite reasonable and correct. The first level of virtualization is provided by VMware Workstation software, at this level there are virtual workstations (WINPC1, WINPC2), virtual servers (WINSRV1, WINSRV2), and an auxiliary virtual machine CISCONET, as well as virtual switches VMnet3-VMnet6. The second level of virtualization is provided by the Dynamips-based GNS3 software running on the CISCONET virtual machine; at this level there are Cisco virtual routers (R1, R2), as well as virtual switches SW1-SW4 connected to the corresponding network interfaces of the routers (R1, R2). Network interaction between the first and second levels of virtualization is carried out through “two-way projection” at the OSI data link layer: virtual switches VMnet3-VMnet6 are bound to the corresponding network adapters LAN1-LAN4 of the auxiliary virtual machine CISCONET, and the corresponding ports of virtual switches SW1-SW4 through corresponding objects of the type “Cloud” (they are not shown in the diagram, since in essence they are simple “junction points” and nothing more), are also tied to the corresponding network adapters LAN1-LAN4 of the auxiliary virtual machine CISCONET. Finally, the third level of virtualization is provided by Cisco IOS OS tools running on virtual routers; at this level there is a virtual MPLS cloud and virtual chains (VC 111, VC 222) using EoMPLS technology. Using the Cisco OS itself, EoMPLS virtual chains are projected onto the corresponding interfaces of virtual routers (R1, R2) and thereby ensure network interaction between the second and third levels of virtualization.

Let us now move directly to the results of modeling this multi-level structure on a personal computer. This is what it looks like after creating, configuring and running virtual machines, including CISCONET, within which a network with Cisco routers has also been created, configured and launched:

The CISCONET virtual machine has four network adapters: LAN1, LAN2, LAN3 and LAN4, which are associated with the corresponding virtual switches VMnet3, VMnet4, VMnet5 and VMnet6. In turn, the virtual machine network adapter WINPC1 is bound to the virtual switch VMnet3, the network adapter WINPC2 is bound to VMnet4, the network adapter WINSRV1 is bound to VMnet5, and the network adapter WINSRV2 is bound to VMnet6. This is how one side of the “contact” points is implemented: the WINPC1, WINPC2, WINSRV1 and WINSRV2 virtual machines can interact with the CISCONET virtual machine through the corresponding network adapters of this machine. It is very important to note that any switching or routing between the network adapters of the CISCONET virtual machine using the MS Windows OS itself on this machine should, by definition, be prohibited. In turn, the CISCONET machine runs a Dynamips-based GNS environment running two Cisco virtual routers. The corresponding router interfaces are connected to the corresponding virtual switches SW1, SW2, SW3 and SW4 (not to be confused with the VMnet virtual switches), and the switches, in turn, are connected to the corresponding objects PC1, PC2, SRV1 and SRV2 (not to be confused with the virtual machines VMware with similar names). PC1, PC2, SRV1 and SRV2 are essentially objects of the “Cloud” type - simple “junction points” projected onto the corresponding network adapters LAN1, LAN2, LAN3 and LAN4 of the CISCONET virtual machine. Thus, the second side of the “contact points” is realized: the corresponding router interfaces can also interact with the CISCONET virtual machine through the corresponding network adapters of this machine.

The following partially shows how the necessary bindings are implemented between VMnet virtual switches and network adapters of the CISCONET virtual machine, as well as between objects PC1, PC2, SRV1 and SRV2 (junction points) and network adapters of the CISCONET virtual machine. The screenshot shows a window with the configuration file of the CISCONET virtual machine, which shows the MAC addresses of the network adapters and the binding to the VMnet virtual switches. Another window displays a table of network connections of the CISCONET virtual machine and the corresponding names of network adapters (assigned in MS Windows OS for this machine), MAC addresses of adapters and network transport identifiers. Finally, the third window displays the binding of the PC1 object of type “Cloud” (junction point) to the corresponding network transport identifier of the CISCONET virtual machine.

In order not to get confused in the network connections between different objects at different levels of virtualization, let’s summarize them in one visual table:

Net	VMware virtual machines	VMware Virtual Switch	CISCONET network connection	CISCONET network adapter MAC address	CISCONET Network Transport Identifier	Cloud object in GNS3	Virtual switch in GNS3	Cisco Virtual Router and Network Interface	EoMPLS virtual chain
	Virtualization layer 1					Level 2			Level 3
1	WINPC1 CISCONET	VMnet3	LAN1	00:0c:29:25:1f:ac	C0E98EFF-BFA7- 472F-A5C0-A22293E1EE26	PC1	SW1	R1:FA0/0	VC 111
2	WINPC2 CISCONET	VMnet4	LAN2	00:0c:29:25:1f:b6	390F3C01-A168- 40D8-A539- 1E417F3D6E1B	PC2	SW2	R1:FA0/1	VC 222
3	WINSRV1 CISCONET	VMnet5	LAN3	00:0c:29:25:1f:c0	6577836B-60A3- 4891-931C- 232ED8B2F8F2	SRV1	SW3	R2:FA0/0	VC 111
4	WINSRV2 CISCONET	VMnet6	LAN4	00:0c:29:25:1f:ca	7834C67F-12F2- 4559-BEF4- C170C3E0B7DC	SRV2	SW4	R2:FA0/1	VC 222

Now let's move on to the test results. The screenshot below shows that the respective workstations and servers “see” each other over the network (including through network services using broadcast requests) through the MPLS cloud, thanks to EoMPLS virtual circuits. Network professionals will also be interested in looking at the MPLS switching tables and the state of EoMPLS virtual circuits on Cisco routers. The second screenshot shows that the virtual chains (VC 111, VC 222) are functioning successfully and a certain number of bytes are transferred along them in both directions:

Thus, multi-level virtualization allows you to study and test various examples of network infrastructure, effectively using the computing resources of the personal computer at hand, which today often has a multi-core processor and high-capacity RAM on board. In addition, multi-level virtualization allows for more flexible distribution of computing resources and control over their use. So, for example, in the example discussed above, virtual routers operate within the computing resources of a secondary virtual machine, rather than a real computer, as would be the case with single-layer virtualization.

Please enable JavaScript to view the

The new Cisco Virtualization Experience Infrastructure (VXI) addresses the fragmented nature of existing solutions that make virtual desktop adoption difficult. In addition, the new infrastructure expands the virtualization capabilities of traditional desktop systems for multimedia and video processing.

Cisco VXI helps overcome the key barriers that prevent enterprises from taking advantage of the financial, data security, and flexible workstyle benefits of desktop virtualization, as well as the integration of multimedia and video collaboration features, without compromising the user experience. Additionally, Cisco VXI reduces the total cost of ownership of desktop virtualization solutions by radically increasing the number of virtual systems supported per server.

Analysts predict that desktop virtualization could reduce PC support costs by 51 percent (per user), while it accounts for 67 percent of PC IT budgets. Virtual desktops also help protect corporate intellectual property by placing information in the data center rather than on the user's physical device. At the same time, end users will be able to independently choose the device with which they will access their virtual computer. All of these benefits, coupled with increased productivity and business agility through multimedia and video applications, increase the value of network solutions for end users and businesses.

Cisco's recommended Cisco VXI-based architectures include Cisco Collaboration, Cisco Data Center Virtualization, and Cisco Borderless Networks, as well as the best desktop virtualization software and appliances.

The following Cisco technologies have been tested for compatibility with the Cisco VXI solution: Cisco Unified Communications applications optimized for virtual environments and endpoints, including the Cisco Cius tablet; Cisco Quad™ platform; solution for load balancing and optimization of Cisco ACE applications; Cisco software for accelerating global networks; Cisco ASA All-In-One Security Appliances; Cisco AnyConnect™ VPN Client; Cisco UCS™ Unified Computing Environment; Cisco Nexus® and Cisco Catalyst® family switches designed for data centers; multi-level switches for storage networks Cisco MDS; Cisco ISR routers.

The Cisco VXI solution includes Citrix XenDesktop® 5 and VMware View™ 4.5 desktop virtualization systems from industry leaders Citrix and VMware. The new infrastructure also supports management and security applications, storage systems from EMC and NetApp, and many Microsoft applications.

The Cisco VXI system supports a wide range of endpoints, including Cisco Unified IP phones, laptops, enterprise tablets including the Cisco Cius, and smartphones. Cisco, along with industry leader Wyse, has optimized a range of hardware and software technologies to improve the response time of applications running on the Cisco VXI environment and related architectures. Taking advantage of the openness of the Cisco ecosystem, DevonIT ​​and IGEL have also tested their devices for compatibility with the Cisco VXI solution.

Cisco VXI solution elements are designed and tested to work together in a variety of installation options to best meet customer requirements. In addition to flexible media support, the solution provides compatibility with a wide range of user devices and access methods, giving users the flexibility to choose based on business or application requirements.

Cisco Desktop Virtualization Appliances Optimized for Media Experience

Cisco announced two Cisco Virtualization Experience Client (VXC) devices that support desktop virtualization features in a “clientless” form in tandem with Cisco Unified Communications:

• The Cisco VXC 2100 is a compact device that is physically integrated with the Cisco Unified 8900 and 9900 series IP phones to optimize the user's workplace environment. It supports Power-over-Ethernet (PoE) and can work with one or two monitors. The device has four USB ports for connecting a mouse and keyboard, if necessary for working in a virtual environment.
• The Cisco VXC 2200 is a standalone, compact, clientless appliance with a streamlined design that gives users access to a virtual desktop and business applications running in a virtualized environment. Designed with the environment in mind, the Cisco VXC 2200 can be powered using either Power-over-Ethernet (PoE) or an optional power supply. This device also has four USB ports and two video ports, through which you can connect devices needed to work in a virtual environment.

To study Cisco courses, sometimes it is necessary to work with real images, since Packet Tracer does not always provide all the capabilities we need, its firmware is greatly reduced. Then GNS3, which I wrote about earlier, comes to our aid. There should be no problems installing and adding images, I think.

GNS3

Therefore, I will describe the typical configuration that we will recreate:

It's simple. On our real computer we run the GNS3 emulator. It runs a virtual Cisco 2961, which is connected to a VirtualBox virtual machine (for example, Windows XP). You can build configurations of any degree of complexity if resources allow, but we will focus on this one.

So what do we need? First of all, we create a new interface in the system to wrap it in GNS3.

To do this, we create a new loopback interface (Loopback), a Microsoft adapter, and map it to the cloud in GNS3.

I described how to install the new Loopback adapter in the video:

After creating the interface, we have a new network connection in the manager of the real machine:

I renamed it LOOPBACK so as not to be confused with anything else.

Now open GNS3:

Go to the settings and configure the VirtualBox machine:

The drop-down list contains all machines that are installed in the guest ViBox. We choose any one that interests us. In this case it is Windows XP.

Next, we drag the objects we need onto the GNS3 field. The cloud (this is an interface to a real machine), the VirtualBox virtual machine and the c2961 router, the image of which (you can take it from our file dump) has already been added to the hypervisor.

Let's go to the settings of our cloud C1. Here we need to specify that it is associated with the existing LOOPBACK interface.

Unfortunately, the interfaces have dissonant names, so you have to read carefully so as not to make a mistake. In the same way, by the way, you can connect the virtual Cisco in GNS3 to any other interface, be it Wireless or WAN. Select the one you need and click “Add”

We connect everything with connections and launch. The VirtualBox virtual machine starts immediately (Windows XP, we specified it). There I configure the network interface, for example, I give 192.168.200.2/24, and set the gateway to *.1, i.e. it will be on the router.

Then in the real machine I open the LOOPBACK properties and give it a different network address: 192.168.100.2/24, which does not overlap with the virtual machine. Well, the default gateway is itself *.1 of this subnet.

Here's the final picture:

Connect to router R1 and go to Console:

Here I have assigned the IP addresses corresponding to the default gateways of these machines (real and virtual)

Here's the configuration:

R1#conf t
R1(config)#int fa0/0
R1(config-if)#ip addr 192.168.100.1 255.255.255.0
R1(config-if)#no shut
R1(config-if)#exit
R1(config)#int fa0/1
R1(config-if)#ip addr 192.168.200.1 255.255.255.0
R1(config-if)#no shut
R1(config-if)#exit
R1(config)#

That is, on the side of the real machine we set the IP, which is the default gateway for the Loopback interface, and on the side of the virtual machine - IP, which is the default gateway for the virtual machine interface.

Now we can send a PING request from a virtual machine to a real one or vice versa:

Now we can install some WireShark or learn to route the network in another way by adding other virtual machines, addresses and LOOPBACK interfaces! Good luck!

As you know, sometimes articles from our good friends are published on the blog.

Today Evgeniy will tell us about Cisco router virtualization.

There is a classic network organization scheme: access level (SW1, SW2, SW3), distribution level (R1) and connection to the global network (R2). On router R2, statistics collection is organized and NAT is configured. A hardware firewall with traffic filtering and routing functions is installed between R2 and R3 (Scheme 1)

Not long ago, the task was set to migrate the entire network to an alternative gateway (R4). The new gateway has cluster functionality and is capable of horizontal scaling by increasing the number of cluster nodes. According to the commissioning plan, it was required that at a certain period of time there were two gateways on the network at the same time - the old one (R2) for all client networks, and the new one (R4) for the networks participating in testing the new gateway (Scheme 2).

Attempts to implement PBR (Policy-based routing) on ​​the internal router (R1) were unsuccessful - the traffic was looped. Management refused requests for additional equipment. Time passed, there was no router, the task was stalled...

And then I came across an article from the Internet that talked about isolating routing tables on Cisco routers.

I decided to get an additional router with an independent routing table based on the existing equipment. To solve the problem, a new project was drawn up (Scheme 3), implying the presence of an additional router with PBR capability.

Connection network between R1 and R5:

Network: 172.16.200.0 /30

Interface on R1: 172.16.200.2 /30

Interface on R5: 172.16.200.1 /30

VLANID: 100 – old router

VLANID: 101 – new router

Note: a virtual router created on the basis of R3 (Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9_NPE-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1)) is used as R5.

Router R3 is equipped with three Gigabit Ethernet ports, interface Gi0/0 is used for internal routing, Gi0/1 is used for connecting to a hardware firewall, and Gi0/2 is used for connecting to an external provider.

Let's move on to setting up the R5 router.

Let's go to configuration mode:
R3(config)#ip vrf zone1
This command creates an isolated routing table on the router. Name zone1 selected by the administrator independently. You can also assign an identifier and description. More details can be found in the documentation. Upon completion, return to configuration mode using the command exit.

Configuring network interfaces:
R3(config)#interface GigabitEthernet0/0.100

R3(config-subif)#encapsulation dot1Q 100
R3(config-subif)#ip address 172.16.100.2 255.255.255.252
R3(config-subif)#exit
R3(config)#interface GigabitEthernet0/0.101
R3(config-subif)#ip vrf forwarding zone1
R3(config-subif)#encapsulation dot1Q 101
R3(config-subif)#ip address 172.16.100.6 255.255.255.252
R3(config-subif)#exit
R3(config)#interface GigabitEthernet0/0.1000
R3(config-subif)#ip vrf forwarding zone1
R3(config-subif)#encapsulation dot1Q 1000
R3(config-subif)#ip address 172.16.200.1 255.255.255.252
R3(config-subif)#exit
Now you need to configure PBR. To do this, we will create an ACL, guided by the following rule: everyone who gets into the ACL is routed through the old gateway, and the rest are routed through the new one.
R3(config)#access-list 101 deny ip host 192.168.3.24 any
R3(config)#access-list 101 deny ip host 192.168.3.25 any
R3(config)#access-list 101 deny ip host 192.168.3.26 any
R3(config)#access-list 101 permit ip any any
Create a Route-Map:
R3(config)#route-map gw1 permit 50
R3(config-route-map)#match ip address 101
R3(config-route-map)#set ip vrf zone1 next-hop 172.16.100.1
R3(config-route-map)#exit
And apply it to the interface:
R3(config)#interface GigabitEthernet0/0.1000
R3(config-subif)#ip policy route-map gw1
R3(config-subif)#exit
Add a default route to the routing table zone1:
R3(config)#ip route vrf zone1 0.0.0.0 0.0.0.0 GigabitEthernet0/0.101 172.16.100.5
and check the routing table for zone1
R3#show ip route vrf zone1
Routing Table: zone1
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, + - replicated route

Gateway of last resort is 172.16.100.5 to network 0.0.0.0

S* 0.0.0.0/0 via 172.16.100.5, GigabitEthernet0/0.101
172.16.0.0/16 is variably subnetted, 6 subnets, 2 masks
C 172.16.100.0/30 is directly connected, GigabitEthernet0/0.100
L 172.16.100.2/32 is directly connected, GigabitEthernet0/0.100
C 172.16.100.4/30 is directly connected, GigabitEthernet0/0.101
L 172.16.100.6/32 is directly connected, GigabitEthernet0/0.101
C 172.16.200.0/30 is directly connected, GigabitEthernet0/0.1000
L 172.16.200.1/32 is directly connected, GigabitEthernet0/0.1000
The problem of dividing client network traffic into different gateways has been solved. Among the disadvantages of the adopted solution, I would like to note the increased load on the router hardware and weakened security, since the router connected to the global network has a direct connection to the local network, bypassing the hardware firewall.

We want to tell you about the operating system iOS, developed by the company Cisco. Cisco IOS or Internetwork Operating System(Internet Operating System) is the software used in most Cisco switches and routers (early versions of switches ran on CatOS). iOS includes routing, switching, internetworking and telecommunications functions integrated into a multitasking operating system.

Not all Cisco products use iOS. Exceptions include security products A.S.A., which use the Linux operating system and routers that run iOS-XR. Cisco IOS includes a number of different operating systems that run on a variety of network devices. There are many different variants of Cisco IOS: for switches, routers and other Cisco network devices, IOS versions for specific network devices, IOS feature sets that provide different packages of features and services.

The file itself iOS is several megabytes in size and is stored in a semi-permanent memory area called flash. Flash memory provides non-volatile storage. This means that memory contents are not lost when the device loses power. On many Cisco devices, IOS is copied from flash memory to RAM when the device is turned on, then IOS is started from RAM when the device is running. RAM has many functions, including storing data, which is used by the device to support network operations. Running iOS in RAM improves device performance, but RAM is considered volatile memory because data is lost during the power cycle. A power cycle is when a device is intentionally or accidentally turned off and then turned on again.

Device management with iOS occurs using the command line interface ( CLI), when connected using a console cable, by Telnet, SSH or using AUX port.

Version names Cisco IOS consist of three numbers and several symbols a.b(c.d)e, Where:

• a– major version number
• b– minor version number (minor changes)
• c– release serial number
• d– intermediate build number
• e(zero, one or two letters) – software release sequence identifier, such as none (which denotes the main line), T (Technology), E (Enterprise), S (Service provider), XA special functionality, XB as other special functionality etc.

Rebuild– often rebuilds are released to fix one specific problem or vulnerability for a given version of iOS. Rebuilds are done either to quickly fix an issue or to meet the needs of customers who do not want to upgrade to a later major version because they may be running critical infrastructure on their devices and therefore prefer to minimize changes and risk.

Interim release– intermediate releases, which are usually produced on a weekly basis and form a snapshot of current developments.

Maintenance release– tested versions, which include improvements and bug fixes. Cisco recommends that you upgrade to the Maintenance version whenever possible.

Stages of development:

• Early Deployment (ED)– earlier deployment, new functions and platforms are introduced.
• Limited Deployment (LD)– initial limited rollout, includes error corrections.
• General Deployment (GD)– general deployment of the OS, testing, refinement and preparation for release of the final version. Such releases are generally stable on all platforms
• Maintenance Deployment (MD)– These releases are used for additional support, bug fixes, and ongoing maintenance of the software.

Most Cisco devices that use iOS, also have one or more "feature sets" or "packages" - Feature Set. For example, Cisco IOS releases intended for use on Catalyst switches are available as "standard" versions (providing only basic IP routing), "advanced" versions that provide full IPv4 routing support, and "advanced IP services" versions that provide advanced features, as well as IPv6 support.

Each individual feature set corresponds to one category of services in addition to the basic set ( IP Base– Static Routes, OSPF, RIP, EIGRP. ISIS, BGP, IMGP, PBR, Multicast):

• IP data (Data– adds BFD, IP SLAs, IPX, L2TPv3, Mobile IP, MPLS, SCTP)
• Voice (Unified Communications– CUBE, SRST, Voice Gateway, CUCME, DSP, VXML)
• Security and VPN (Security- Firewall, SSL VPN, DMVPN, IPS, GET VPN, IPSec)

Was this article useful to you?

Please tell me why?

We are sorry that the article was not useful for you: (Please, if it is not difficult, indicate why? We will be very grateful for a detailed answer. Thank you for helping us become better!