Tag Archives: IOS

iOS 7 and Labels

Posted on by
1

wwdc-13-apple-reveals-ios-7

Apple is prepping the release of iOS 7 to their users sometime in the next couple of months. The developers are already testing it out to find bugs and polish their apps in anticipation of the user base adopting Jonathan Ive‘s vision for a mobile operating system. In many ways, it’s still the same core software we’ve been using for many years now with a few radical changes to the look and feel. The icons and lack of skeumorphism are getting the most press. But I found something that I think has the ability to be even bigger than that.

The user interface (UI) elements in the previous iOS builds all look very similar. This is no doubt due to the influence of Scott Forestall, the now departed manager of iOS. The dearth of glossy buttons and switches looked gorgeous back in 2007 when the iPhone was first released. But all UI evolves over time. Some evolve faster than others. Apple hit a roadblock because of those very same buttons. They were all baked into the core UI. Changing them was like trying to correct a misspelled word in a stone carving.  It takes months of planning to make even the smallest of changes.  And those changes have to be looked at on a massive scale to avoid causing issues in the rest of the OS.

iOS 7 is different to me.  Look at this pic of an incoming call and compare it with the same screen in iOS 6:

iOS 7

iOS 7

iOS 6

iOS 6

The iOS 6 picture has buttons.  The iOS 7 picture is different.  Instead of have chiseled buttons, it looks like the Answer and Decline buttons have been stuck to the screen with labels.  That’s not the only place in the UI that has a label-like appearance.  Sending a new  iMessage or text to someone in the Messages app looks like applying a stamp to a piece of paper.  Taking all that into consideration, I think I finally understand what Ive is trying to do with this UI shift in iOS 7

Labels are easy to reapply.  You just peel them off and stick them back on.  Unlike the chiseled-in-stone button UI, a label can quickly and easily be reconfigured or replaced if it starts to look dated.  Apple made mention of this in Ive’s iOS 7 video where he talked about creating “hierarchical layers (to) establish order“.  Ive commented that this approach gives depth to the OS.  I think he’s holding back on us.

Jonathan Ive created UI layers in the OS so he can change them out more quickly.  Think about it.  If you only have to change a label in an app or change the way they are presented on screen, it allows you to make more rapid changes to the way the OS looks.  If the layers are consistent and draw from the same pool of resources, it allows you to skin the OS however you want with minimal effort.  Ive wasn’t just trying to scrub away the accumulation of Scott Forrestal’s ideas about the UI.  He wanted to change them and make the UI so flexible that the look can be updated in the blink of an eye.  That gives him the ability to change elements at will without the need to overhaul the system.  That kind of rapid configurability gives Apple the chance to keep things looking fresh and accommodate changing tastes.

Tom’s Take

I can almost hear people now saying that making future iOS releases able to be skinned is just another rip off of Android’s feature set.  In some ways, you are very right.  However, consider that Android was always designed with modularity in mind from the beginning.  Google wanted to give manufacturers and carriers the ability to install their own UI.  Think about how newsworthy the announcement of a TouchWiz-free Galaxy S4 was.  Apple has always considered the UI inviolate in all their products.  You don’t have much freedom to change things in iOS or in OS X.  Jonathan Ive is trying to set things up so that changes can be made more frequently in iOS.  Modders will likely find ways to insert their own UI elements and take these ideas in an ever more radical direction.  And all because Apple wanted to be able to peel off their UI pieces as easily as a label.

IOS X-Treme!

Posted on by
8

IOSXtreme

As a nerd, I’m a huge fan of science fiction. One of my favorite shows was Stargate SG-1. Inside the show, there was a joke involving an in-universe TV program called “Wormhole X-Treme” that a writer unintentionally created based on knowledge of the fictional Stargate program. Essentially, it’s a story that’s almost the same as the one we’re watching, with just enough differences to be a totally unique experience. In many ways, that’s how I feel about the new versions of Cisco’s Internetwork Operating System (IOS) that have been coming out in recent months. They may look very similar to IOS. They may behave similarly to IOS. But to mistake them for IOS isn’t right. In this post, I’m going to talk about the three most popular IOS-like variants – IOS XE, IOS XR, and NX-OS.

IOS XE

IOS XE is the most IOS-like of all the new IOS builds that have been released. That’s because the entire point of the IOS XE project was to rebuild IOS to future proof the technology. Right now, the IOS that runs on routers (which will henceforth be called IOS Classic) is a monolithic kernel that runs all of the necessary modules in the same memory space. This means that if something happens to the routing engine or the LED indicator, it can cause the whole IOS kernel to crash if it runs out of memory. That may have been okay years ago but today’s mission critical networks can’t afford to have a rogue process bringing down an entire chassis switch. Cisco’s software engineers set out on a mission to rebuild the IOS CLI on a more robust platform.

IOS XE runs as a system daemon on a “modern Linux platform.” Which one is anyone’s guess. Cisco also abstracted the system functions out of the main kernel and into separate processes. That means that if one of them goes belly up it won’t take the core kernel with it. One of the other benefits of running the kernel as a system daemon is that you can now balance the workload of the processes across multiple processor cores. This was one of the more exciting things to me when I saw IOS XE for the first time. Thanks to the many folks that pointed out to me that the ASR 1000 was the first device to run IOS XE. The Catalyst 4500 (the first switch to get IOS XE) is using a multi core processor to do very interesting things, like the ability to run inline Wireshark on a processor core while still letting IOS have all the processor power it needs. Here’s a video describing that:

Because you can abstract the whole operation of the IOS feature set, you can begin to do things like offer a true virtual router like the CSR 1000. As many people have recently discovered, the CSR 1000 is built on IOS XE and can be booted and operated in a virtualized environment (like VMware Fusion or ESXi). The RAM requirements are fairly high for a desktop virtualization platform (CSR requires 4GB of RAM to run), but the promise is there for those that don’t want to keep using GNS3/Dynamips or Cisco’s IOU to emulate IOS-like features. IOS XE is the future of IOS development. It won’t be long until the next generation of supervisor engines and devices will be using it exclusively instead of relying on IOS Classic.

IOS XR

In keeping with the sci-fi theme of this post, IOS XR is what the Mirror Universe version of IOS would look like. Much like IOS XE, IOS XR does away with the monolithic kernel and shared memory space of IOS Classic. XR uses an OS from QNX to serve as the base for the IOS functions. XR also segments the ancillary process in IOS into separate memory spaces to prevent system crashes from an errant bug. XR is aimed at the larger service provider platforms like the ASR 9000 and CRS series of routers. You can see that in the way that XR can allow multiple routing protocol processes to be executed at the same time in different memory spaces. That’s a big key to the service provider.

What makes IOS XR so different from IOS Classic? That lies in the configuration method. While the CLI may resemble the IOS that you’re used to, the change methodology is totally foreign to Cisco people. Instead of making live config changes on a live system, the running configuration is forked into a separate memory space. Once you have created all the changes that you need to make, you have to perform a sanity check on the config before it can be moved into live production. That keeps you from screwing something up accidentally. Once you have performed a sanity check, you have to explicitly apply the configuration via a commit command. In the event that the config you applied to the router does indeed contain errors that weren’t caught by the sanity checker (like the wrong IP), you can issue a command to revert to a previous working config in a process known as rollback. All of the previous configuration sets are retained in NVRAM and remain available for reversion.

If you’re keeping track at home, this sounds an awful lot like Junos. Hence my Mirror Universe analogy. IOS XR is aimed at service providers, which is a market dominated by Juniper. SPs have gotten very used to the sanity checking and rollback capabilities provided by Junos. Cisco decided to offer those features in an SP-specific IOS package. There are many that want to see IOS XR ported from the ASR/CSR lines down into more common SP platforms. Only time will tell if that will happen. Jeff Fry has an excellent series of posts on IOS XR that I highly recommend if you want to learn more about the specifics of configuration on that platform.

NX-OS

NX-OS is the odd man out from the IOS family. It originally started life as Cisco’s SAN-OS, which was responsible for running the MDS line of fibre channel switches. Once Cisco started developing the Nexus switching platform, they decided to use SAN-OS as the basis for the operating system, as it already contained much of the code that would be needed to allow networking and storage protocols to interoperate on the device, a necessity for a converged data center switch. Eventually, the new OS became known as NX-OS.

NX-OS looks similar to the IOS Classic interface that most engineers have become accustomed to. However, the underlying OS is very different from what you’re used to. First off, not every feature of classic IOS is available on demand. Yes, a lot of the more esoteric feature sets (like the DHCP server) are just plain unavailable. But even the feature sets that are listed as available in the OS may not be in the actual running code. You need to active each of these via use of the feature keyword when you want to enable them. This “opt in” methodology ensures that the running code only contains essential modules as well as the features you want. That should make the security people happy from an exploit perspective, as it lowers the available attack surface of your OS.

Another unique feature of NX-OS is the interface naming convention. In IOS Classic, each interface is named via the speed. You can have Ethernet, FastEthernet, GigabitEthernet, TenGigabit, and even FortyGigabit interfaces. In NX-OS, you have one – Ethernet. NX-OS treats all interfaces as Ethernet regardless of the underlying speed. That’s great for a modular switch because it allows you to keep the same configuration no matter which line cards are running in the device. It also allows you to easily port the configuration to a newer device, say from Nexus 5500 to Nexus 6000, without needed to do a find/replace operation on the config and risk changing a line you weren’t supposed to. Besides, most of the time the engineer doesn’t care about whether an interface is gigabit or ten gigabit. They just want to program the second port on the third line card.

Tom’s Take

No software program can survive without updates. Especially if it is an operating system. The hardware designed to run version 1.0 is never the same as the hardware that version 5.0 or even 10.0 utilizes. Everything evolves to become more efficient and useful. Think of it like seasons of sci-fi shows. Every season tells a story. There may be some similarities, but people overall want the consistency of the characters they’ve come to love coupled with new stories and opportunities to increase character development. Network operating systems like IOS are no different. Engineers want the IOS-like interface but they also want separated control planes, robust sanity checking, and modularized feature insertion. Much like the writers of sci-fi, Cisco will continue to provide new features and functionality while still retaining the things to which we’ve grown accustomed. However, if Cisco ever comes up with a hare-brained idea like the Ori, I can promise there’s no way I’ll ever run IOS-Origin.

My Thoughts on IOU-For-Learning

Posted on by
Reply

This week, Learning@Cisco announced a new program designed to help those people out there that want a virtualized router platform upon which to study for the CCNA and CCNP.  While the idea behind an emulated IOS platform is one that has been desired for a long time, what Cisco released today isn’t quite what we’ve been clamoring for.  The new programs use the now-famous IOS on Unix (IOU) setup that has been used internally at Cisco for a while now and was made famous by Jeremy Gaddis in this post.  This is also the same platform that is used in the troubleshooting section of the CCIE Routing & Switching Lab.

The new program is completely hosted by Cisco.  All of your access to the IOU environment is done via web and SSH.  You, as the end user, have no access to the files that comprise IOU.  Since the emulator is presented as a component of a learning package, there is no opportunity to modify the topologies presented.  They are canned and align with the courseware you purchase.  This is great for people that are just starting out in the networking world that have no access to the proper gear to learn how to enable telnet sessions and address an interface.  By limiting the access you have to a topology, you get rid of some of the confusion that surrounds tools such as GNS3, namely the dearth of options that tend to confuse the first-time users.

I have a couple of problems with what Cisco’s released so far:

1.  IOU isn’t a true layer 2 emulator.  The software that comprises IOU is great at simulating IOS running on a router.  That’s because it’s essentially an IOS image that has been modified to run on a different “hardware” platform.  So long as all you are worried about is working with routers, IOU is a great resource.  However, if you really want to dive into the second layer of the OSI model, you’re going to come up short rather quickly.  Basic layer 2 configuration is fine for a CCENT/CCNA type of student, but by the time you reach the CCNP level of switching, you’re going to find the interface of IOU wholly unsuitable.  Since IOU emulates a router, it has to emulate switching as it would be on a router with an ESM switch module.  That means that anything that relies on an ASIC to function, such as QoS, is right out the window.  Which means that some of the more esoteric and hard-to-learn parts of using IOS on a switch remain off-limits.  I’ve been able to use 16-port switching modules in GNS3 to emulate switches for some of my studies, but I quickly reached the limits of this configuration with things like advanced spanning tree configuration or specialized tasks like Storm Control.  I think that Cisco needs to put a little more effort into providing an emulated environment for switching.  Finding a way to emulate the ASICs of the QoS functions would make those learning VoIP QoS on 3560/3750 switches much happier.

2.  There’s still no proof-of-concept for engineers.  As luck would have it, I have a small lab at $employer to test some of the things customers ask me about.  It’s been cobbled together with bits and pieces of cast off equipment over the years.  Where I run into trouble are those cases where the customer has a setup that I can’t quite reconstruct with the equipment I have.  What would be nice is a kind of emulation environment that allows me to reconstruct this setup quickly.  This is the perfect scenario for something like IOU.  Being able to quickly reconstruct a customer’s environment or duplicate your own environment for things like change control and internal testing would be a dynamite idea.  By utilizing a Cisco UCS cluster with the right topology files, I could have my WAN configuration duplicated and run several sample configs for maintenance window changes quickly with the capability to roll them back if something horrible breaks.  That’s where the true power of having an emulator lies for the advanced engineer.

3.  Strict control of IOU cuts out the “gray market”.  It’s no big shock that Cisco has taken the stance with the 360 Program that you’re either with us or you’re the “gray market”.  Vendors like Internetwork Expert (INE) and IPExpert have their own courseware and rack space designed to aid their students.  These racks use real routers and switches to allow students the ability to do practical studying.  However, these kinds of study aids are prohibitively expensive for a training provider to get into.  Now, imagine if you could fire up and virtual rack of routers and switches for your students at the touch of a button.  The barrier to entry becomes much lower to those companies wishing to get involved in the training market.  The possibility then exists that you could have some bad apples in the bunch that might dilute the training offered to students and put a black mark against your name.  By holding all the cards in the IOU discussion, Cisco ensures that the technology never leaves their house, so any training partners wishing to leverage the power behind the emulated IOS platform must abide by Cisco’s rules if they want to keep playing.  Cisco can then force training partners to use 360 materials or the equivalent for CCNP/CCNA/CCENT training.  That forces the non-Cisco approved partners out of the space sooner rather than later.

Tom’s Take

Cisco’s getting to the educational platform party ahead of some of the other network vendors, like HP and Juniper, but they’re doing it with baby steps.  High level engineers have been hoping for a truly unlimited emulator for testing things for quite a while now.  I think they’re still going to be waiting for a while to come.  This new learning program is leveraging IOU to replace aging programs like the Boson Network Simulator or the NetSim products.  By tailoring it toward the entry-to-mid learner, it allows them to work out the kinks in the presentation while still keeping control over the platform for the time being.  I’ve heard that they will expand this idea to encompass security offerings and one day the CCIE as well.  I think that the IOU Learning Platform will be integrated into the 360 program and will only be offered as a part of the materials that you receive from your subscription to it.  I seriously doubt that even a CCIE-level student will have unfettered access to IOU in their own lab, since the possibility of a non-crippled version of IOU being readily available creates too many complications for Cisco support.  It’s already fairly easy to get a copy of IOU if you know where to look.  Imagine what would happen if a copy from a CCIE candidate got out into the wild without fixed configurations or limitations that you face in the hosted CCNA version?  I applaud Cisco for the steps they’ve taken in the right direction for allowing students access to emulated educational software.  Now it’s time to observe what happens and meet the needs of those of us on the other end of the scale.

If you think that Cisco needs to offer a full IOS platform for educational purposes, please head over to Greg Ferro’s site and put your digital signature on the educational IOS petition.  The more signatures that are gathered, the more pressure that can be brought to bear on Cisco to show them the will of the engineer.