November 22, 2012 at 03:18What it looks like from the inside and what are the advantages of modular OS of network devices, for example, XOS from Extreme Networks
- Tutorial
In recent years, manufacturers of active network equipment have been promoting their products that run on modular operating systems, while the CLI is slightly different, if any.
The main differences, as a rule, are hidden from administrators and users for quite logical reasons (protection of technologies, copyrights, as well as possible irreversible consequences that may be caused by inquisitive minds). About how such logical structures are implemented almost a little lower.
Typically, modular OSs run on top of:
• MontaVista Linux (Cisco NX-OS, Extreme XOS)
• FreeBSD (JunOS)
• OpenBSD (Dell-Force10 OS)
• and others ...
But working directly with the file system itself is locked and requires additional privileges.
This mode of operation in Extreme XOS is called "debug-mode".
To enter “debug-mode”, you must manually drive the command completely, since the hint does not work in this case. After that, the console will prompt you to enter the password, which you need to receive from TAC engineers (if the service case requires it and there is a valid service contract). The password will be valid for 59 minutes, and is generated based on the “challenge” generated by the system.
After entering the “debug-mode”, the user can get a hint using <TAB> a couple of additional hidden branches of the settings commands.
And if the branch for the most part is available for viewing in the normal mode of operation,
here is the branch (I immediately remember the cartoon for some reason :) is completely hidden and is intended for debugging by XOS developers.
It is also worth noting that if you know the hidden commands of the branch, then having registered them completely in the CLI you can apply them, but this will not work with the teams.
But the most important thing is that it is exclusively from this mode that you can get into the shell.
The set of commands of the built-in BusyBox is shown in the picture.
And the root directory structure is quite familiar to all Linux systems.
Everything is mounted on a pre-installed CF switch.
When installing XOS from BootRom, you can see how these eight logical partitions are formatted. The ninth position is an external USB flash drive connected to the port on the front panel.
Below is the answer to the question - "What is the difference when installing the OS in the" primary "and" secondary "sections?", And also why one XOS file is suitable for installation on all switches of the same line regardless
of model and functionality.
Prior to the release of the Summit X460 family of switches, Broadcom CPUs with MIPS 64 architecture were installed on the switches, now they are more productive processors from RMI with a similar architecture. That is why two kernels are included in the operating system file, each of which is compiled for its own processor. As the kernel, version 2.6.98.6 is selected.
Alphadiags files help diagnose the hardware, from ports to internal buses to LEDs. Diagnostics can be simple and advanced and can be run from the CLI using the <run diagnostic {normal | extended}> (the launch causes a loss of traffic on the ports !!!).
It is possible that the name alphadiags is somehow related to the fact that all Extreme Networks equipment is assembled on the conveyors of Alpha plants.
The processor that is installed in the Summit X460-24t switch
Below, in fact, those processes and kernel modules due to which the operating system is called modular.
Each process has its own memory area, which allows for the failure of one process and the rest to work, as well as to manually restart some
modules that are not critical for the entire system.
The authorship of some kernel modules. Since Extreme Networks uses Broadcom ASICs in its equipment, they require kernel modules from the source to work with them.
Each switch has an identifier of its platform, which is stored in EEPROM, so after installation, a check is made for compliance with the platform and the license level. Information about what functionality you need to run is contained in the corresponding files. The convenience of this approach is that after entering the license key, a command is simply issued to launch the corresponding modules, without the need to completely reinstall the OS image.
The last file is a script that loads the default configuration.
Using the built-in vi editor, you can see the structure of such files. Everything is quite simple there: a description of the process / module, a start path, the ability to manually restart, the ability to self-repair a process after a failure, as well as some other parameters.
Conclusion:
1. Modular operating systems are more intelligent than their predecessors - monolithic operating systems, with all the ensuing marketing consequences. However, their installation requires appropriate hardware support, which in turn increases the final cost of the products. This is especially noticeable on access switches, which in this case cannot compete in price with analogues on monolithic OSs, and some manufacturers do not even make offers in this segment.
2. Difficulty if you want to install the system image on a virtual machine: firstly, installation scripts built into the OS are not available to the user, and secondly, not all manufacturers use x86-based processors in their solutions. And therefore, this issue with emulators is solved only by manufacturers who make the necessary corrections and compile the source for x86.
In general, the situation is somewhat (in the personal opinion of the author) reminiscent of the mobile phone market, where with the advent of modular OSs such as IOS and Android, there was a de facto abandonment of old platforms
that now occupy a niche in the lower price segment. The market for network devices will certainly not be so dynamic, but the trends and benefits from such a transition are obvious.
So let's follow the announcements from Extreme Networks, Cisco Systems, Juniper Networks and other market leaders who are actively developing and using the functionality we have reviewed.
Extreme Networks Authorized Training Courses
MUK-Service - all types of IT repair: warranty, non-warranty repair, sale of spare parts, contract service
The main differences, as a rule, are hidden from administrators and users for quite logical reasons (protection of technologies, copyrights, as well as possible irreversible consequences that may be caused by inquisitive minds). About how such logical structures are implemented almost a little lower.
Typically, modular OSs run on top of:
• MontaVista Linux (Cisco NX-OS, Extreme XOS)
• FreeBSD (JunOS)
• OpenBSD (Dell-Force10 OS)
• and others ...
But working directly with the file system itself is locked and requires additional privileges.
This mode of operation in Extreme XOS is called "debug-mode".
To enter “debug-mode”, you must manually drive the command completely, since the hint does not work in this case. After that, the console will prompt you to enter the password, which you need to receive from TAC engineers (if the service case requires it and there is a valid service contract). The password will be valid for 59 minutes, and is generated based on the “challenge” generated by the system.
After entering the “debug-mode”, the user can get a hint using <TAB> a couple of additional hidden branches of the settings commands.
And if the branch for the most part is available for viewing in the normal mode of operation,
here is the branch (I immediately remember the cartoon for some reason :) is completely hidden and is intended for debugging by XOS developers.
It is also worth noting that if you know the hidden commands of the branch, then having registered them completely in the CLI you can apply them, but this will not work with the teams.
But the most important thing is that it is exclusively from this mode that you can get into the shell.
The set of commands of the built-in BusyBox is shown in the picture.
And the root directory structure is quite familiar to all Linux systems.
Everything is mounted on a pre-installed CF switch.
When installing XOS from BootRom, you can see how these eight logical partitions are formatted. The ninth position is an external USB flash drive connected to the port on the front panel.
Below is the answer to the question - "What is the difference when installing the OS in the" primary "and" secondary "sections?", And also why one XOS file is suitable for installation on all switches of the same line regardless
of model and functionality.
Prior to the release of the Summit X460 family of switches, Broadcom CPUs with MIPS 64 architecture were installed on the switches, now they are more productive processors from RMI with a similar architecture. That is why two kernels are included in the operating system file, each of which is compiled for its own processor. As the kernel, version 2.6.98.6 is selected.
Alphadiags files help diagnose the hardware, from ports to internal buses to LEDs. Diagnostics can be simple and advanced and can be run from the CLI using the <run diagnostic {normal | extended}> (the launch causes a loss of traffic on the ports !!!).
It is possible that the name alphadiags is somehow related to the fact that all Extreme Networks equipment is assembled on the conveyors of Alpha plants.
The processor that is installed in the Summit X460-24t switch
Below, in fact, those processes and kernel modules due to which the operating system is called modular.
Each process has its own memory area, which allows for the failure of one process and the rest to work, as well as to manually restart some
modules that are not critical for the entire system.
The authorship of some kernel modules. Since Extreme Networks uses Broadcom ASICs in its equipment, they require kernel modules from the source to work with them.
Each switch has an identifier of its platform, which is stored in EEPROM, so after installation, a check is made for compliance with the platform and the license level. Information about what functionality you need to run is contained in the corresponding files. The convenience of this approach is that after entering the license key, a command is simply issued to launch the corresponding modules, without the need to completely reinstall the OS image.
The last file is a script that loads the default configuration.
Using the built-in vi editor, you can see the structure of such files. Everything is quite simple there: a description of the process / module, a start path, the ability to manually restart, the ability to self-repair a process after a failure, as well as some other parameters.
Conclusion:
1. Modular operating systems are more intelligent than their predecessors - monolithic operating systems, with all the ensuing marketing consequences. However, their installation requires appropriate hardware support, which in turn increases the final cost of the products. This is especially noticeable on access switches, which in this case cannot compete in price with analogues on monolithic OSs, and some manufacturers do not even make offers in this segment.
2. Difficulty if you want to install the system image on a virtual machine: firstly, installation scripts built into the OS are not available to the user, and secondly, not all manufacturers use x86-based processors in their solutions. And therefore, this issue with emulators is solved only by manufacturers who make the necessary corrections and compile the source for x86.
In general, the situation is somewhat (in the personal opinion of the author) reminiscent of the mobile phone market, where with the advent of modular OSs such as IOS and Android, there was a de facto abandonment of old platforms
that now occupy a niche in the lower price segment. The market for network devices will certainly not be so dynamic, but the trends and benefits from such a transition are obvious.
So let's follow the announcements from Extreme Networks, Cisco Systems, Juniper Networks and other market leaders who are actively developing and using the functionality we have reviewed.
Extreme Networks Authorized Training Courses
MUK-Service - all types of IT repair: warranty, non-warranty repair, sale of spare parts, contract service