Linux Hammer tools

[root@foo313 ~]# cat


if [ $1 ]; then

for i in `seq 0 $((NUM_PROC-1))`; do
        awk 'BEGIN {for(i=0;i<10000;i++)for(j=0;j<10000;j++);}' &

echo "PIDS: `pidof awk`"
[root@foo313 ~]#

[root@foo313 ~]# ./ 10
PIDS: 11429 11428 11427 11426 11425 11424 11423 11422 11421 11420
[root@foo313 ~]# ps -ef | grep awk
root     11420     1 31 09:22 pts/1    00:00:01 awk BEGIN {for(i=0;i<10000;i++)for(j=0;j<10000;j++);}
root     11421     1 45 09:22 pts/1    00:00:02 awk BEGIN {for(i=0;i<10000;i++)for(j=0;j<10000;j++);}
root     11422     1 32 09:22 pts/1    00:00:01 awk BEGIN {for(i=0;i<10000;i++)for(j=0;j<10000;j++);}
root     11423     1 29 09:22 pts/1    00:00:01 awk BEGIN {for(i=0;i<10000;i++)for(j=0;j<10000;j++);}
root     11424     1 48 09:22 pts/1    00:00:02 awk BEGIN {for(i=0;i<10000;i++)for(j=0;j<10000;j++);}
root     11425     1 45 09:22 pts/1    00:00:02 awk BEGIN {for(i=0;i<10000;i++)for(j=0;j<10000;j++);}
root     11426     1 27 09:22 pts/1    00:00:01 awk BEGIN {for(i=0;i<10000;i++)for(j=0;j<10000;j++);}
root     11427     1 46 09:22 pts/1    00:00:02 awk BEGIN {for(i=0;i<10000;i++)for(j=0;j<10000;j++);}
root     11428     1 28 09:22 pts/1    00:00:01 awk BEGIN {for(i=0;i<10000;i++)for(j=0;j<10000;j++);}
root     11429     1 34 09:22 pts/1    00:00:01 awk BEGIN {for(i=0;i<10000;i++)for(j=0;j<10000;j++);}
root     11450 11351  0 09:22 pts/1    00:00:00 grep awk

Linux KVM on CentOS 7 minimal

Linux KVM on CentOS 7



Install KVM on CentOS 7 from minimal install

$ sudo yum -y install qemu-kvm libvirt virt-install bridge-utils virt-install
$ sudo systemctl start libvirtd 
$ sudo systemctl enable libvirtd

Create Network Interfaces

Create Bridge Interface

$ sudo bash -c 'cat > /etc/sysconfig/network-scripts/ifcfg-kvm01 << EOF

Add physical interface to bridge

$ sudo bash -c 'cat > /etc/sysconfig/network-scripts/ifcfg-enp0s8 << EOF

Create New Virtual Guest

$ sudo virt-install \
   --name=DEV_test03__5950 \
   --controller type=scsi,model=virtio-scsi \
   --disk path=/var/lib/libvirt/images/DEV_test03__5950.dsk,size=8,sparse=true,cache=none,bus=scsi \
   --graphics vnc,listen=,port=5950 \
   --network bridge=kvm01 \
   --vcpus=2 --ram=1024 \
   --cdrom=/var/storage/os/CentOS-7.0-1406-x86_64-DVD.iso \
   --os-type=linux \

Create Partition table for guests

File System LV Name size (MB)
/ lv_root 512
/home lv_home 128
/opt lv_opt 128
/usr lv_usr 3072
/tmp lv_tmp 128
/var lv_var 512
/usr/local lv_local 128
swap lv_swap 1024
boot phys 512

Are white box switches less secure?

Are white box switches less secure than proprietary alternative switches like Juniper or Cisco?

Gregory Pickett, Founder of Hellfire Security, did a presentation about white box security during the last Black Hat conference, triggering a multitude of news articles which we will analyse in this post. Without dwelling on the all too common distraction caused by the author mixing ideas – the title of the presentation is about SDN and the presentation is all about white box networking security – the security issues raised are real.

Those security issues are either network operating system (NOS) specific (which I will not comment on since none of them are related to PicOS), or Pre-Boot related (Bootkit). I will focus on the key issues relating to security of NOS boot loaders, specific to Open Networking / White Box Networking.

Rootkit and Bootkit

The typical goal of a malicious user is to install a rootkit on the device under attack. A rootkit is a collection of software designed to enable unauthorized access while masking its existence. Because NOS’s protection mechanisms are becoming more elaborate, a new type of attack has emerged. This kind of attack bypasses all NOS security, by booting malicious software before the NOS loads. Rootkits using such pre-boot attacks are called Bootkits, and represent one of the most advanced technologies available to cybercriminals today.

Bootkit attacks were first demonstrated a few years ago at Black Hat on typical servers or on Windows machines. That type of attack is now becoming common, with steady growth in the number of Bootkits available, such as XPAJ or TLD4. To date, most attacks have targeted servers and desktops, however they can be easily applied to network devices like routers, switches or firewalls, enabling full access to most data transmitted by the network.

To avoid the attacks, a chain of trust is required and must be in place from the moment the equipment is taken out of the box until the NOS is loaded. Every step in this process must be secure. This is a process that ensures the device boots an immaculate image that has not been tampered with or modified. There are two ways to create a trusted boot system: Secured Boot and Measured Boot.

Building a Trusted Boot System with Secured Boot

With Secured Boot, the boot sequence is stopped if a valid threat is detected, rendering the device unusable. Secured Boot requires the use of UEFI (a BIOS replacement) and a signed NOS. The UEFI boot will verify the NOS signature prior to loading any NOS. This means that the UEFI is pre-loaded with a set of public keys.

There are drawbacks however. For example, how much of the NOS needs to be signed? This is the subject of much debate. Another issue is the reliability of the NOS signature. Can it be trusted? Security agencies have been known to tamper with well-known network devices in the past, so it is difficult to believe they would not have access to encryption keys.

Building a Trusted Boot System with Measured Boot

With Measured Boot, the device continues to boot even if the system has been compromised, but the entire boot process is recorded in logs that are placed in a new hardware chip called a TPM (Trusted Platform Module). A remote server would regularly query the TPM chip for the values, then compare them with known good values. If there was a mismatch, the server could then be programmed to perform a number of actions. The most significant drawback of this solution is the need for hardware modification.

Are pre-boot attacks unique to the white box market?

No. Pre-boot attacks are in not limited to white box switches. They can affect all vendors and to date we are not yet aware of any network vendors utilizing a trusted boot system at this time.

It is easier to install Bootkit with ONIE, because loading software is its purpose. But any ZTP (Zero Touch Provisioning) system can be used for this function as well and most network vendors support some flavor of ZTP.

Secure Boot as the long-term solution and workaround

A trusted boot system is the long term solution, but it requires hardware support, NOS support and boot loader support (ONIE). Pica8 is actively working to convince hardware ODM vendors to use UEFI Boot and to install TPM chips on their white box switches. Pica8 is also part of the OCP community, which is adding UEFI support for ONIE in its next release.

Until trusted boot systems are available, the best solution is to protect the management network used to download the NOS on your switches. Physical protection is required in this case as a rogue DHCP server can easily download malicious software.

Once the NOS has been installed, ONIE and ZTP should be disabled which is the default behavior for ONIE once a NOS installation has occurred.

open switching terminology

The networking industry is making a decisive move toward open switches. Much of the media’s attention is on mega-scale operators’ do-it-yourself switches, such as Facebook’s Wedge and 6-Pack or Google’s much more secretive in-house switches. A few weeks ago I sat in on a presentation by analyst Alan Weckel of Dell’Oro Group at the Ethernet Technology Summit, and he made the interesting observation that if Google were counted as a switch vendor (with itself as its only customer), it would be the world’s second largest – surpassed only by Cisco.

ted talk
Four mindblowing Ted Talks for techies
TED talks make that possible to do in a single sitting. Here are four talks that in just over an hour
At least as important as what the tech giants are doing – and eventually, more important – is that normal-sized network operators are beginning to pay attention to open switching, and you’re going to see some enormous shakeups in the Ethernet market in the next few years.

Open switching has spawned a small lexicon that can be confusing to newcomers, leaving them wondering what the difference is, say, between bare metal switches and white box switches, and whether the differences really matter or are just a marketing overlay. In this blog I want to take a crack at differentiating the terms you hear most often around open Ethernet switching.

I don’t claim any of this as authoritative. It’s just my attempt to wave away some of the fog.
Open Switches

Let’s start with defining open switches themselves, although I doubt that anyone who is interested enough to read this article doesn’t already have a reasonable understanding of what open switching is.

Open switches are switches in which the hardware and software are separate entities that can be changed independently of each other. So the same hardware can support multiple operating systems, or the same operating system can be run on multiple hardware configurations. This is in contrast to closed switches, in which the hardware and software are always purchased together. So for example if you buy a Juniper EX or MX you also buy JUNOS. If you buy a Cisco Catalyst switch you buy IOS.

So open switches are about choice. Interestingly, though, that doesn’t necessarily mean your choice. It could mean a vendor has the choice of rebranding an open switch, adding their own software, and selling it all as a package.

That’s where the lexicon comes in.

Bare Metal Switches

These are open switches as you usually think of them. You buy the hardware, no brains included, all ready to be loaded with the operating system of your choice. This is how we’ve been building servers – and sometimes PCs and laptops – for years. You choose the applications you need to run, then you choose the operating system that best supports the applications or best fits your operational environment, and then you choose the hardware on which to run it all.


Buyer’s Guide to Mobile Application Platforms
Network Management Megatrends 2016: Hybrid Cloud, Network Analytics and the Internet of Things
Search Resources
Bare metal manufacturers are primarily Taiwanese, and include such companies as Accton, Quanta QCT, Alpha Networks, and Delta Computer. These same companies are original design manufacturers (ODMs) for many of the mainstream switch vendors; in fact, some of the bare metal switches available to you are the same switches you buy from the mainstream vendors, but without the label and without the operating system, and at a fraction of the cost.

The bare metal switch comes with a boot loader called the Open Network Install Environment (ONIE), which allows you to load an operating system onto the switch. A sort of PXE for switches.

There’s a multitude of operating systems you can load, such as Broadcom’s FastPath, Big Switch Networks’ Switch Light, Cumulus Networks’ Cumulus Linux, and Pica8’s PicOS. Juniper Networks is making a move into the open switch community with its OCX1100, and it will be interesting to see if eventually you can buy a license for JUNOS to run on your choice of bare metal switch.

What the available operating systems have in common is that they are commercial software. You won’t find much in the way of practical freeware. There’s the Open Compute Project’s Open Network Linux (ONL), but right now ONL is an open-source development platform on which to build practical operating systems, rather than a fully cooked OS. It’s a great foundation if you are a commercial developer or if you want to tinker with coding your own OS in a lab, but it’s not something you can deploy in your production network by itself.

White Box Switches

This is where things start to get confusing. “White box” is often used interchangeably with “bare metal” or “brite box,” so context is important. I’m giving you a definition here that sits somewhere between bare metal and brite box, and you’re more than welcome to disagree. It’s the closest I can get without blurring the lines.

NASA competition could net you $1.5M for next great airship
160324 lynch
US accuses 7 Iranians of hacking US banks, New York dam
cbf 008
Energy Star 3.0 server spec to look at coprocessors for more accurate…
A white box switch differs from a bare metal switch in that it comes with an operating system installed. It’s still an open switch because the OS and the hardware are not integrated as they are in a “black box” switch. Basically you’re buying a package: a bare metal switch and an operating system.

If you buy a switch from Accton’s subsidiary Edge-Core Networks, for example, you might get a choice of bare metal, white box with DCSS SwitchOS installed, or white box with Cumulus Linux installed. Juniper’s OCX1100 is a white box solution, because it is a commodity switch packaged with JUNOS. Pica8 offers a white box solution in which you can get their PicOS packaged with a switch. Big Switch Networks is also a white box provider; you buy their SDN software and bare metal switches as a package. Alternatively, you can get a Big Switch package with switches from a brand-name provider such as Dell, which makes them a brite box provider.

Wait… A what?

Brite Box Switches

Brite box stands for BRanded whITE box, just in case you weren’t confused enough. You’ll see it spelled brite box, brite-box, or britebox. Greg Ferro suggests calling them whitebrand boxes, saying britebox “…sounds like dishwashing liquid or something you buy from the local two dollar store.”

Whatever form tickles your fancy, there actually is a difference from white box and bare metal. Sort of.

A brite box switch is made by an ODM, and is often the same switch offered by the ODMs as bare metal, but it sports a front bezel with a brand name like Dell or HP. And so there you have it. Branded white box.

Merchant Silicon
A cornerstone of open switches, whether bare metal, white box, or brite box, is that they are built around merchant or “off the shelf” silicon from companies such as Broadcom, Mellanox Technologies, Intel/Fulcrum, and Centec Networks. This is in contrast to the custom ASICs most of the legacy vendors use in their high-end switches and routers. While custom silicon allows for tight integration with a proprietary operating system and a broad feature set, the production cycle from design to foundry is long and enormously expensive. Merchant silicon vendors, on the other hand, introduce new generations of chips every 18 to 24 months.

This doesn’t mean that merchant silicon is to be found only in open switches. While the big vendors like Cisco and Juniper still tout the better points of custom ASICs, they too are introducing switches built on merchant silicon, such as Cisco’s Nexus 3000 and 9000, and Juniper’s aforementioned OCX1000. Arista switches have always used off-the-shelf chips.

The object lesson for vendors that tie their software too closely to their hardware is Sun Microsystems. While Sun clung to custom microprocessors, vendors like Dell and HP with open x86-based servers swooped in and took over the server market. Between November 2007 and November 2008, Sun lost 80% of its value. Open switches can do the same thing to established switch vendors if they cling too closely to past practices.

Does It Matter?

Bare metal switches only matter to commercial software providers. Unless you’re Facebook or Google, you’re not likely to put something in your network with minimal support channels. White or brite box solutions, in which you’re buying a hardware and software package backed up by trustworthy engineering support, are the only real open switching choices for normal-sized network operators.

That said, what really matters is the movement to open switching. Think about how you build servers right now, and consider the advantages of building your switches the same way.