Aruba WLANs 101 and design fundamentals Integration Partners' Wireless Lead Architect, Tim Cappalli gives a Presentation at Aruba Networks EMEA conference.
Digital native
From Wikipedia, the free encyclopedia
“The term digital native can be used to describe people born after 1980, when social digital technologies, such as Usenet and bulletin board systems, came online. Digital natives are characterized as having access to networked digital technologies and the skills to use those technologies. Major parts of their lives and daily activities are mediated by digital technologies: social interaction, friendships, civic activities, hobbies. And they’ve never known any other way of life”
By way of the above definition I am a digital non-native, I might be considered an adopted child of the natives. Although I was hacking code and designing digital systems prior to the 1980s, I do not have the mindset that differentiates the digital natives from the non-natives. My experts on the topic of digital natives are a pair of true digital natives, my daughters, they are 18 and 20 and to them I am a total digital Luddite. I asked them about their views on the use of digital technology and their expectations of the networks that supported these technologies. I suspect their answers are typical of digital natives the world over. These views and expectations are changing all aspects of networks to include: storage, security, connectivity, services, pricing and advertising.
Some of the digital native’s views and expectation:
• No concept of “where” the content resides (on-net, off-net, local, cached, it does not matter)
• No concept of busy hour or congestion periods so that the term 24/7 is meaningless as there is no other option and down-time is incomprehensible as the only time that you cannot access content is when your battery is dead.
• Power is free and available
• Mobility trumps size and comfort
• Cellular service is a staple part of the household budget (not a business expense)
• No off button, apps that always run
• Social networking is a given (others care what they are doing)
• Social sites are safe (Whether or not, they are a tremendous source for identity theft or a sociopaths playground)
• Applications are secure (their information will not be lost or stolen)
• Where an application runs is of no concern (locally or not) only connectivity options
• Touch, links, resizing, tabs, multitasking (on the machine) are all natural operations
•Given these expectations for service, how does your network design meet these new user’s requirements?
• Was your network designed around traffic engineering standards of the 1990s?
• Does your network have single points of failure? Transport, management, billing?
• What is your upgrade plan, are you watching the bandwidth growth, or just the bandwidth?
• Do you have a means to notify users of security breaches or do you just watch them happen?
• Can your systems withstand another Hurricane Sandy and survive?
• Are you transporting all your traffic all the time? Is caching viable?
If you cannot answer these questions, then it is time to take a close look at your network. If you answered these questions and most are to the negative, it is time to rethink the implementation of your network.
If you are wondering who these natives are, you are not one of them, but look around, they are pasted to their smart phones, taking selfies, and poking fun at you. If your network or systems fail, they won’t care, there are other providers or app that will work just fine for them. What’s your #?
From my point of view I see is the loss of net neutrality as a boon for the technology of the Internet as a whole. If service providers can charge more for ‘premium’ content it stands to reason that the provider has to offer a ‘premium’ class of service for that content. This concept is totally lacking across the Internet. Today there is no class of service or quality of service distinction provided by ISPs. Verizon might have a scheme that is used in its network (most likely not to classify user Internet traffic), as does AT&T and all the others. The point is that none of them have a single agreed upon scheme.
Definitions abound in the RFCs as to what the classifications should be and what quality guarantees should be applied, but no one has ever implemented these across the broad Internet. They have been successfully implemented in Enterprise networks for years, voice, video and data routinely are passed between locations on the same pipes and routers. Each traffic type offered its own distinction and quality treatment.
With the opening of the Internet to multiple tiers of traffic costs, a global means of traffic classification and quality is possible. Peering between carriers could have CoS/QoS agreements that effect routing and service provider choices (the coin of the realm, as to say). This treatment would foster more service providers to meet the agreements or run the risk of losing customer traffic.
Once a global system is in place a totally new set of services and capabilities could be offered over the Internet that would foster competition and development…
While there are purported to be many winners and losers in the Net Neutrality wars, the battle is far from over. One winner I could see is the Internet itself and the quality guarantees that could be offered.
Mine tend to be outdoors, skiing and sailing are my principals, but I tend to buck the trend. It seems that a large number of people find their hobbies on-line, gaming being one of the principals. A recent survey shows that the U.S. supports about 145 Million gamers and that they spend on the average of about 215 million game hours per day. It is no wonder that the game hosting companies are doing so well. Another survey showed that on-line gamers are split between games that play for points and those that play for money.
I worked with a gaming company a while ago and found it interesting that the biggest concerns for this company were bandwidth and denial of service attacks. The bandwidth concerns I understood, the more bandwidth the more feature rich and life like the game can be. The second concern was a surprise. Apparently when a gamer is disenchanted with a game, in addition to going to another game, he or she finds is necessary to disrupt the game so that other gamers and the gaming company cannot continue that game. Seems childish, but then again I have seen folks drive pickup trucks over ski trails quite possibly for the same reason. In any case, back to this game company and their concerns.
The bandwidth concern was not really a concern at all, bandwidth and high bandwidth devices are easy to come by today and this company had 20Gbps at its disposal in no time at all (and when I left them were using 8 Gbps of that bandwidth on average). The solution to the second concern needed a little more research and had a couple of possible solutions.
Looking at the denial of service mitigation solutions there are three main types – in-line, bypass and cloud based. All three types of systems use basically the same technique to mitigate the attacks. Traffic is monitored and when an attack profile is seen that traffic is scrubbed. Each of the mitigation techniques has its pros and cons.
The in-line systems are typically the least costly per bit protected, they save the attacked server, but do not stop the incoming traffic from clogging the Internet access link. These systems have a fixed throughput and require a load balancer or forklift for scaling to greater throughputs. They monitor and scrub the traffic as it passes through the system. For a couple of vendors, the DDoS protection is added to other functions (i.e. firewalls or load balancers). These devices tend to be easier to setup and troubleshoot as all traffic follows the same path through the system.
The bypass systems are another on-premises solution that is composed of two components, one is the monitor system and the other the scrubber. When traffic matches an attack profile it is detoured to the scrubber for processing. The non-attack traffic proceeds on the direct path. Routing protocols are typically used to create the bypass. These solutions block the unwanted traffic protecting the attacked server, but again do not unclog the Internet access link from the DDoS traffic. The principal advantage is that the scrubber device does not have to be line rate, because it only received traffic that matches attack profiles. The monitoring device can be a purpose built device or an existing firewall or router with flow monitoring capabilities. The separation in function allows this solution to scale without a major change to the hardware. The bypass systems tend to be more complicated to setup and troubleshoot due to the routing involved.
The cloud based systems are the third type of solution available today. These systems operate by routing traffic to a scrubber in the cloud. The solutions vary by how that is accomplished. Some DDoS providers act as the customer’s ISP, advertising the customer’s routes to the Internet and see all the traffic from the Internet. When traffic matches the attack profiles, it is dropped. Traffic that does not match the profile is handed to the customer without delay. One cloud based vendor uses a hybrid approach, monitoring the traffic on the customer’s premises and then diverting the traffic to a cloud based scrubber when attacks are detected. In all these solutions the customer, their ISPs and the DDoS provider have to agree on routing arrangements. These systems are typically pay as you grow arrangements and are a totally managed system as far as setup and troubleshooting is concerned.
With all these solutions the gaming company actually went for the cheapest solution. They decided that they could sacrifice the attacked server. When an attack occurred, they advertised the attacked prefix to their ISPs with the black-hole attribute. This stopped the attack traffic. Considering that they had a virtual environment for the games themselves, they spun up another copy of the game on another server and continued on.
Looking at the level of attacks that are plaguing the Internet today it seems that some folks are making a hobby out of these attacks. Rather than the game servers, attacks are being aimed at the login servers, blocking all users from attaching to the game sites. These companies have been forced off-line and need to install some form of attack prevention systems. It seems that the growth of on-line gaming will help foster a new round of DDoS attack solutions.
It will be interesting to see if those that make a living from attack mitigation can get ahead of the attacker hobbyist.
I know it is a worn out marketing line, but the recent advances in technology have sparked an interest in this technophile. Wearable technology made techie headlines with the announcement of an electronic fabric. Today we have glasses and watches that are connected, and I am sure that I can find a ring that can be a phone or whatever, but a tee shirt that is electronically connected… the possibilities are endless.
I am not talking about the sport apparel that is wired to accept an i-whatever for my listening pleasure, although I did see a dude pushing a hoodie strings into his ear and wondered what new fad this was until I saw the headset wire in the cord. Who needs Q-Tips sticking out of your ears to make a statement?
Although another avenue to explore, this is not about the health monitoring devices either. Those strapped on things that tell me how many steps I have taken today or how often my heart rate has exceeded (or not in my case) the limit for a workout. My heart rate monitor died of boredom, I think the batteries gave up the ghost trying to find my pulse.
What I am taking about is a connected fabric, a wearable technology that is Internet aware, connected as an entity and usable by those that wish to exploit its capabilities. What I am thinking is combining digital signs, on-demand advertising, and tee shirts. Get my message out to the masses, instantly on the street, in their faces, and personal (it does not get any more personal than the guy standing in front of you).
For those of you that are not following along here at the speed of nerd, let me connect the dots. I have a fabric that can be fashioned with various electronic gadgets (integrated not attached). I order my fabric with a 4G receiver connected to a LED type sign (to be positioned on the back of the tee-shirt, hoodie or jacket). I can determine the position and the movement of the walking sign as well as the intended target of the ad. At this point I can send an appropriate advertisement to the sign as the target audience is within range of the person wearing the ad-apparel…
What is not to love, a new source of revenue for wearing over prices apparel, a new outlet for advertising, a variation on the worn-out tee-shirt slogans (sorry about the “What’s in you..”). It could be a new economy, sandwich boards for the 21st century. What could go wrong?
I am not alone in this endeavor, I saw a video clip of a fashion show where one of the dresses was streaming tweets from the fashion designer. Talk about live advertising and attention getting digital signs. Again what could go wrong with this new medium?
Anytime that I get carried away down these technological rabbit holes my practical side catches up with me, how could I protect this system from hackers? It would be a relatively open system using the public airways for transmission and existing protocols. A hacker’s dream, turning advertisements for a restaurant into a public statement of how good they are at breaking and altering, embarrassing a designer during a debut.
So how do I protect this system, encrypt the signal, set up firewall rules for receiving commands and scanning the display information, authenticating the users. All normal security measures making the system more robust, but also more complicated. When designed from the ground up with these security measures in place, it would not add to the overall scope of the project, but adding these things as an afterthought would be a major setback. It is better to be proactive where security is concerned rather than see the effects of a security breach walking the sidewalks “Don’t Eat At Joe’s he….”
I recently co-authored a whitepaper discussing the layered network security approach typically implemented with PCI Compliance. This got me thinking about layered security in general.
Data center security, network security, application security, physical security, and national security… One thing these entirely different security architectures have in common is the layered approach to securing critical assets.
Each approach has a first line of defense, an in-depth inspection of incoming traffic, the “trusted” core, and the transit traffic from one side to another. The perimeter will usually catch most “bad guys” and the core will typically be the most expensive to secure. Each architecture can be layered, secured, and segmented time after time after time.
Implementations, upgrades and maintenances typically occur one layer at a time. Each layer is abstracted and separately maintained and/or operated separately from the rest. Attackers are not just lock pickers or breaking through one line of defense. In many cases, they're trying to get through layer after layer of security. The ultimate goal is the “crown jewels”.
Implementing network security devices is typically done in much the same manner as security layers. Let’s say you've purchased a shiny new next-generation firewall. It comes with several cool new features you want to use, but aren't currently implementing. A typical layered installation would go something like the following:
Install the stateful firewall.
Include NAT.
2. Turn on IPSec VPN services
3. Turn on Application Layer Gateway features
4.Turn on packet inspection and intrusion detection
Use the “recommended” signatures
5. Turn on threat management
Turn on and use the “recommended” virus signatures
Turn on and use the “recommended” spam signatures
Turn on and use the “recommended” malware signatures
6. Turn on “application aware” features
Coordinate application rule-sets with existing stateful rule-sets
Typical installations usually include a “burn in” period for each feature. The burn in period usually includes log and flow gathering, rule-base altering/tweaking, and preparing for the next layer of security features.
And once the desired services are implemented, it seems like one of two inevitable things always happen: It’s time to optimize the configuration or it’s time to upgrade the implementation.
As a sales engineer for Integration Partners I have the opportunity to spend long periods of time behind the wheel of my car. I am in tune with the rhythms of my car, the sound of its engine, the vibration of the tires on the road surface and any number of other observations that my senses can pick up. I do not rely on the alarms to tell me when something should be looked into, I am typically aware of these things well in advance of the warnings generated by the manufacturer. The more information I can receive from the car the happier I am. Hopefully with this information I can stay one step ahead of having to call a tow truck from the side of the road. My dream car would contain an instrument cluster that would house gauges for every operational part of the drive train.
I realize that not all drivers operate the same and that I might be an exception to the rule (I have been told this for many other aspects of my life). Some drivers go on the theory that no news is good news. All they want to know is how fast they are driving and when to fill up the tank. Their idea of a gauge cluster includes a speed odometer and a fuel gauge. They feel that since they are not auto mechanics, the added information does nothing for them. The car should continue to work as designed.
This difference in the driving philosophy is analogous to the operation of a communications network. Some network administrators are maniacs about the status of their networks. Each link, server, and device is under constant observation. When any datum is out of the norm they are investigating the cause of the abnormality and the effect on the other aspects of the network prior to any alarms going off. At the other end of the spectrum are the administrators that are only watching the speed odometer and the gas gauge, do they have enough capacity and are things moving fast enough. In many cases these administrators do not even have gauges, they go on the “No News” theory of networking (e.g. If users are not complaining then things must be ok).
From a networking (and driving) perspective these two philosophies can be described as proactive and reactive monitoring. The two camps have avid supporters that argue their case with religious-like fervor. The arguments typically fall into three areas, business, change and design.
Business Case – The proactive vs. reactive argument is most often cast in a business case. The cost of proactive management is a major investment, whether it is performed as an internal discipline or outsourced. The companies have to balance the cost of proactive network management against other business costs. The question often comes down to “Can the added costs associated with proactive network management be offset by an associated increase in network uptime?” If the answer to this question is no, then a reactive management philosophy will probably be adopted.
Change Management – For proactive network management to reduce network outages, the administrators must change the network as conditions dictate, changing load or adjusting the design to avoid degraded devices. For networks that have stringent change management regulations, proactive network management is not feasible. The change management process precludes the non-emergency
changing of the network. In these cases the reactive management scheme is all that is needed, no need to worry about the network status unless the administrator is like me.
Network Design – I guess that if my car was designed to the same survivability standards as my networks, I would be less interested in the hour to hour operation of the engine and drive train. Since my car has any number of single points of failure, I believe that constant monitoring is required. The same can be said for communications networks, as the networks become more survivable the need for constant attention diminishes. Only those components that are a single point of failure need the full attention, reactive management can be used for all the other components. Network automation is another design capability that has an effect on management. As networks become more aware of their own status, the applications that are running on them, the performance of those applications, and through automation have the ability to dynamically adjust and compensate (like traction control in my car can when it detects road slippage); the role of the network manager becomes one of a spectator to the network rather than a player.
The choice of reactive or proactive network management is dependent on many factors and is debatable, what is not debatable is the need for management of communications networks. Like driving a car without any indicators, running a network without any management capabilities is asking for trouble. Companies cannot afford the loss of their communications and the only way to know of a problem is through management functions. Whether a manager has their eyes glued to the gauges or merely waiting for an alarm the management function decreases the time to return the network to proper operation and lowers to cost of an outage.
An interesting sign to be found on the highways of Vermont, I looked for it in Connecticut and Massachusetts, but they do not seem to care, left, right center, drive where ever you please. But in Vermont it seems that the department of transportation wants to preserve the road surface of the left lane, only use it when you are passing another vehicle.
I guess the proper way to view the sign is to stay in the right lane, allowing the impatient drivers to pass on the left.
Another way to look at it is that the right lane is for the cautious and those that are following the status quo and the left lane is for passing those folks.
This is the approach that I have taken when looking at the recent advances in Ethernet switching. There are companies that are cautiously advancing in the right lane and those that are out in the passing lane covering new ground and pressing new capabilities. This post takes a look at a few of the switch options and aligns then in my opinion of a proper lane.
10 Gbps performance capabilities – The introduction of a new generation of 10Gbps chips from Broadcom(1) has been used by Juniper, Arista, Cisco, Brocade and Extreme in their top of rack switches. These high density 10Gbps devices offer from 40 to 70 odd ports in extremely low power 1 RU devices. RIGHT LANE!
SDN Controller Integration – Every vendors today has an SDN play and a solution for “white switch” arguments. As this segment of the technology matures we will see separation between the vendors, but today. RIGHT LANE!
Cisco released the Nexus 1000V switch which is a VEB(2) (virtual embedded bridge). This software switch loads on a Hypervisor and provides standards based switching between virtual machines and also to the outside world. This bridge offers full VLAN support. PASSING LANE!
Arista Networks announced a new data center term, a combination of leaf and spine, the “spline”. The only member of the spline family is the 7250 QX-64(3), a box 2 rack units high that can support 64 40-Gb/s ports or 256 10-Gb/s ports. This device opens a new record for density. PASSING LANE!
Juniper Networks unveiled QFX5100 series of switches(4) this fall with the QFX5100-48S, a10GbE switch offering 48 dual-mode, small form-factor pluggable transceiver (SFP/SFP+) ports and six quad small form-factor pluggable plus (QSFP+) 40GbE ports. This switch does not break any density records or speed for that matter, what puts this device and Juniper in the passing lane is the way the operating system is supported. JUNOS is run as a virtual machine on a CentOS kernel. The concept is to get the in service upgrade capabilities of a dual controller device in a single controller switch. Upgrades and downgrades should be hitless in this environment. The other options and capabilities for this device are unknown at this time, because it has not been done before. PASSING LANE!
Facebook rarely if ever is associated with Ethernet hardware, but they are changing that perception with the Open Compute Project(5). This project is creating a specification for an open source hardware switching platform
and an open source operating system for the platform. They expect to see hardware that will meet the specifications in the near future. The implications are incredible, imagine an environment where a customer can create a Ethernet switch in the same way they can create a computer today. Choose the platform, the ports, the hardware accelerators, and choose the operating system that they are most comfortable with. Facebook is in the PASSING LANE.
Just as on the highway cars are constantly changing lanes, so are the Ethernet switch vendors and their products.
(1) Broadcom’s 10G chip set - http://www.broadcom.com/products/Ethernet-Controllers-and-Adapters/Enterprise-Server-Controllers/BCM578x0-Family
(2) Cisco’s VEB - http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/whitepaper_c11-620065_ps10277_Products_White_Paper.html
Chief Executive Officer Jeff Bezos unveiled the plan on CBS’s “60 Minutes” news program in the U.S., showing interviewer Charlie Rose the flying machines that can serve as delivery vehicles. Bezos said the gadgets, called octocopters, can carry as much as 5 pounds within a 10-mile radius of an Amazon fulfillment center. Amazon may start using the drones, which can make a delivery within 30 minutes, within five years pending Federal Aviation Administration approval, Bezos said
Interesting concept, but what if you use it for data backup. Back in the 90s Marshal T. Rose wrote a number of technology books, in one of these he calculated the throughput of a station wagon hurling down the highway at 65 miles per hour and compared that to the current transport technologies. Twenty year later it looks like we have another transport system that could rival the throughput of that Caprice Classic.
The news story claimed a five pound payload, a 30 minute delivery over a 10 mile radius. So a typical metropolitan area, the Caprice will not make it in that time, let alone get it loaded and gassed up for the trip.
Using existing storage technology (USB flash Drives) I calculated the throughput of the Amazon octocopters at:
A 128GB flash drives weighs in at 8 grams
5 lbs = 2268 grams = 238 flash drives = 30.4 TB of storage = 243.7Tb of data
30 minutes to load and transport the package = 1800 seconds of transmission
243.7Tb over 1800 seconds ~ 135Gbps of wireless transport
This is of course an absurd calculation as it does not take into account any number of factors. But the point is that physical back up has been the primary choice for many companies for many years. I had the privilege of working for one of the package delivery services that had data centers geographically separated. They used airplanes to perform the nightly backups (calculate the throughput of a 747).
Enterprises are constantly looking for the next best thing for inter data center connectivity. For real time synchronization between applications the current technologies are all that need to be used. But that is not where the throughput problems arise. The remote storage and retrieval is what stresses the current technologies. The wide deployment of 100Gbps transport will relieve these stresses, but the facts remain that storage requirements continue to grow and retention of this information is of critical importance to enterprises.
Maybe it is time to take a step back to the old technologies and see what the bandwidth and security of a Capris Classic, an octocopter, or a 747 really is for your enterprise. The speed and peace of mind might surprise you.
For the holidays I tried a new twist on the festive fowl. I found a receipt for apple maple roasted turkey (http://allrecipes.com/recipe/maple-roast-turkey/). It was a hit. Maple syrup is a staple around our household, it sweetens everything possible in the kitchen (from apples to zucchini).
I liken it to the way that Ethernet has transformed networking, a standardized normalized platform that supports all other communications. Today we can have Ethernet transport from the desktop to desktop regardless of how far those desktops are separated (room, building, campus, metro, nationally or internationally.) The same frame is used to transport those upper layers from edge to edge.
Like my turkey recipe, I take notice when a new Ethernet based technology is introduced. The week prior to our holiday Avaya presented a relatively new Ethernet based transport technology to the engineering team based on Shortest Path Bridging (802.1aq). The technology is explained quite well in a virtualization white paper from Avaya (http://www.avaya.com/usa/resource/assets/whitepapers/dn4469%20-%20network%20virtual%20using%20spb%20white%20paper.pdf) so there is no need to repeat the techno-babble here. The technology is intended to replace Ethernet transport over MPLS in the wide area and the use of spanning tree in the local areas. The technological equivalent of replacing sugar with maple syrup on our breakfast table.
Over the past decade I have taught about, designed and installed local area, metro area and wide area Ethernet deployments. None have been straight forward, none plug and play. As the size of the deployment has grown, so has the complexity of the technology. Adding multicast only made the deployment more difficult, another set of addressing, protocols and designs.
So when I read, no I have not had the opportunity to deploy it yet, about shortest path bridging I was intrigued about this system. Loop free local topologies, resilient, and multiservice with as the name implies shortest path transit.
But I have seen this all before. In the early 90s a new exciting all-in-one technology was going to revolutionize communications from the desktop to the wide area. It contained the control, data and management planes in one unified architecture. You more experienced engineers might recognize this diagram:
Yes, Asynchronous Transfer Mode (ATM) offered the same feature set that I am seeing for SPB. But ATM lacked industry support and provided a small blip on the technology landscape for all its hype. Mostly because ATM needed chip sets that were ultra-expensive and specialized hardware. SPB on the other hand is Ethernet with a reuse of the technologies that have been time proven and readily available as far as hardware and chip sets are concerned.
More recently shortest path bridging has been compared to TRILL ("Transparent Interconnection of Lots of Links") an IETF standard that provides for a loop free interconnection of RBridges (Routing Bridges) using ISIS (also found in SPB). This technology allows a campus (up to 64k RBridges) to appear as a single LAN. Among other features this technology supports IP address movement across the
campus. While TRILL and SPB share common attributes, the introduction of SPB to the wide area and service providers portends a wider scope than TRILL.
My guess is that Shortest Path Bridging will deliver on the promises of simplification and services, but that the penetration will initially be for greenfield campuses. This seems the sweet spot for a technology that promises support for multiple services, reductions in provisioning, and virtualization. We will all see where this technology goes, but it is interesting to see new efforts in signaling and services offered on a known platform.
Just to be fair, I live in northern Vermont where we cook our own maple products (syrup, sugar and butter).
In my capacity as solution architect for New England I have the opportunity to travel the roads from my home in Vermont. Last week while traveling to a customer visit the DOT informational signs, had the following message in four foot high letters:
Hands on Wheel
Mind on Road
Considering that the commute is about four hours, this sign gave me food for thought. If drivers heeded this sign there would be fewer crashes on the roads, leading to fewer backups, leading to fewer distracted drivers, leading to fewer crashes, etc. etc. etc.
In the past decades technology has created many solutions for the Hands on Wheel portion of this equation, there are hands free phones, head up displays, voice command controls for entertainment and environment. There are programs that convert text to voice and voice to text. There are even glasses that can be worn that have a fully interactive display in them. There are so many gadgets that there really is no reason to have your hands off the wheel while operating your automobile.
The issue is that none of these gadgets address the greater concern of Mind on Road it seems that in our need to stay connected 24 x 7 keeping our mind on the road of a secondary concern to technologists.
While a blog post on highway safety would be self-conversant, that is not what initially came to mind when I saw the road sign. What I saw was an underlying message to many network administrators today.
We network engineers and administrators are bombarded with technological gadgets that collect, prioritize and display information on the state of the transport, security and information in our networks. We can have all that information presented to us on a single pane of glass, e-mailed to us as we eat dinner or call us in the middle of the night. We have analytics that will identify the root cause of the problem, the most probable cause of the next problem and what we will have for lunch next Monday.
We have no lack of gadgets to allow us to keep our Hands on Wheel of our networks. In my role as an architect I can find any number of vendors that will support this effort, all with valid claims to time savings and concentrated focus to the “wheels” of your networks.
Like in my car I see few gadgets that allow the network administrators to handle the other part of the message Mind on Road. Few network administrators work where their only concern is the connectivity of their network. For administrators that are in the retail or the wholesale sector PCI compliance is far more important to the overall profitability of the company than the interconnectivity of the offices. If the company does not pass a PCI audit then problems with the WAN are of little concern. If a health care provider cannot show compliance with HIPAA, response times from the servers are of little importance. If financial institutions do not pay attention to the myriad of regulations that are imposed on them, then the status of remote users is of little concern.
Our focus should be; what is the Road that our businesses follow that lead to profitability and growth. What are the elements that need to be monitored and guarded that allow our enterprises to stay in business. These elements are the Mind on Road message. All the other stimulus are secondary, all are distractions from what your primary focus should be.
Like with automobiles, the gadgets available to the network administrator today do not solve the Mind on Road problem only the Hands on Wheel issues. The solution to the Road issue is twofold. The first is the definition of the networking issues that are paramount to the success and profitability of your company. The other is a solution of secondary issues that take your attention away from the issues identified as paramount.
The handling of the paramount issues, once identified, should be the principal focus of the administrative team. They should be given tools to quickly identify and troubleshoot these issue when they occur and have the forensic information needed to comply with the regulatory concerns. These tools are vertically specific and are typically focused on compliance.
The secondary issues, while distracting administrators from the Road, have to be resolved to allow the smooth operation of the network. These issues cannot be ignored or turned-off (as in the case of me as a driver), they must be dealt with in a timely manner. This is the time for managed services. The outsourcing of those secondary issues so that you can focus on the paramount issues. Sort of like me using administrative assistants when I am driving, I focus on the road, while they focus on the other issues that might turn up. The managed service can be as simple as another set of eyes on glass, or as complete as problem resolution. The choice comes down to how many free cycles an administrator can spare for these secondary issues.
Like the number of accidents on the highway, if administrators could reduce the amount of time that they are not focused on their Road, the number of incidents that are enterprise effecting would drop considerably. Outsourcing the management of the non-paramount portions of the network would be one way to allow administrators to both keep their hands on the wheel of their network and their minds on the road to success for their enterprise.
Approximately fifteen years ago the demise of the IPv4 address pool and the popular use of IPv6 has been two years away. In 2000 we were going to run out of IPv4 address by 2002, in 2003 it was 2005 etc. etc. etc.
Well we have finally made it those two years, IPv4 is still not exhausted, but it is quite winded and some say on its last gasp. But we are seeing the use and deployment of IPv6.
The topic today is a case of the “forgot to ask the right questions” when deploying a new core for a data center. The engineer asked about price, ports, throughput and power, but forgot about IPv6 capacity. The core, while sized correctly for IPv4 traffic could not handle the table sizes for IPv6 neighbors (analogous to the IPv4 ARP table).
The existing design is as shown below, showing a collapsed core surrounded by edge switches. All routing is performed in the core and all the edges pass layer 2 traffic (VLANs in this case).
The intermediate distribution frames (IDFs or closet switches) are connected via 1Gbps links to the core, while the data center top rack (ToR) switches are connect with 10Gbps links. The core is composed of a quad of 10Gbps switches configured into a virtual chassis. Outside access is provided by a 10Gbps connected firewall (not shown).
The problem is that when IPv6 is added to the network (happening as you read this post) the core can not handle the number of IPv6 addresses that are expected when things come up to full speed. What to do? The core is new, so a fork lift overhaul would be career affecting, retiring while a nice option, is not in the cards….. so, a fix has to be determined.
Option 1 Divide and Conquer
My initial impression is that the problem is the virtual chassis. If the four members of the core were acting as individuals, the table sizes would be four times as large. Each of the core routers would handle a fourth of the addresses. Weighing the advantages and disadvantages of this option are:
Pluses – No CAPEX needed – always a good thing
Pluses – Retains the core, not collapsed, but centralized
Pluses – No single point of failure
Disses – Limited scalability – The 4x scaling is still too small for growth
Disses – Active/Standby – reduces the bandwidth by half
The disses outweigh the pluses in this option, the scaling and the bandwidth are what makes the initial design a winner, taking these two elements away solves the immediate problem, but provides not path forward.
Option 2 Distribute the Load
Another option that was proposed by a colleague was to distribute the load to a further reach. This option is really just an exaggeration of the first option. Instead of distributing the neighbors between the four core routers, why not distribute the routing functions to the edge? In this option the two tier architecture is morphed into a single routing environment where the core acts as a central meeting point rather than a functional core. All devices are OSPF attached routers routing both IPv4 and IPv6 traffic. The scaling issue of the neighbor table disappears and all devices are the same (functionally). The pros and cons of this approach are:
Pro – scalability – Not likely that any single edge device will reach the table limit for IPv6 neighbors. If they do they cn be changed out for a bigger box containing the expense.
Pro – Reliability and bandwidth utilization are maintained via equal cost multi-path routing and OPSF.
Con – Increased cost – the edge devices need routing functions, which is an additional license per device (ouch!)
Con – Increased complexity – The initial design contains all layer 3 functions to a single device, now routing is pushed to all devices in the network, while not a major issue, still increases the complexity of the overall network.
Con – Increased management – Today there is a single default gateway for all each VLAN in the network. Distributing the routing functions requires a rewrite of the DHCP profiles for all devices increasing the management functions today and ongoing.
Once again the cons outweigh the pros for this option. This option not only costs more money, but also adds to the overall complexity of the network there by increasing the OPEX as well.
Pro – Reliability and bandwidth utilization are maintained via equal cost multi-path routing and OPSF.
Con – Increased cost – the edge devices need routing functions, which is an additional license per device (ouch!)
Con – Increased complexity – The initial design contains all layer 3 functions to a single device, now routing is pushed to all devices in the network, while not a major issue, still increases the complexity of the overall network.
Con – Increased management – Today there is a single default gateway for all each VLAN in the network. Distributing the routing functions requires a rewrite of the DHCP profiles for all devices increasing the management functions today and ongoing.
Once again the cons outweigh the pros for this option. This option not only costs more money, but also adds to the overall complexity of the network there by increasing the OPEX as well.
Option 3 – Bit the Bullet
In the third option the overall design stays the same for IPv4, but changes slightly for IPv6. Instead of the core IPv4 traffic and perform layer 2 switching for IPv6 traffic. An additional router will be added into the mix for the IPv6 routing functions. This arrangement is show in the following diagram, the IPv6 router will be a one-armed bandit attached to the core VC.
This option again has its ups and downs for this deployment. They are:
Up – scaling – the new router can handle any size IPv6 deployment as well as offering advanced IPv4 routing features that might not be available in the core.
Up – Reliability – the use of LAGs and redundant components does not reduce the overall MTBF of the design.
Up – Reduced Complexity – the existing design retains its existing functions
Up – Minimal added management - The addition of the IPv6 router complies with the existing design philosophy of collapsing functions, in this case the IPv6 functions are all in one router.
Con – Added CAPEX – We added another device to the design to meet the IPv6 requirement
Yes, as you may think I am stacking the odds in favor of this option. While not the cheapest solution, it is the only one that will allow the migration to IPv6 to be as pain less as possible while still supporting the IPv4 traffic that is the bread and butter of this network.
Thought Process
IPv6 has been a long time arriving, it has and it is here to stay, this fact has caught many network engineers unaware, while I have not delved into the actual implementation of IPv6 for this network, the first step is being able to support this new protocol on the devices in the network. Once that is accomplished then the real work of migrating to IPv6 can begin and that is a topic for a future post.
The cloud has had many definitions. In the early 90s when most enterprises maintained private line networks, moving to a frame relay or ATM service from the carriers was referred to as transferring their data over the cloud. In those days I was teaching service provider sales teams and I would insist on a definition of what was in the cloud. How many times did I hear that it did not matter, that it was in the cloud and that as long as what went in came out again, all was good in the cloud.
The cloud has grown since those early days, today the decision to use a cloud service makes economic and technological sense. Why build it local when an enterprise can save money, reduce headaches and offer a better product from the cloud.
Amazon, one of the leaders in cloud services, has a total cost of ownership (TCO) calculator (http://aws.amazon.com/tco-calculator/) that allows the definition of the current or proposed data center and provides a TCO for that data center compared to the cost of offering the same services from the Amazon cloud service. For the trials that I ran, the savings were all over 70% of the cost of hosting the services locally.
I recently visited one of my customers and they are very cloud centric. They are fast growing, distributed geographically and data center intense. All very good reasons to rely on cloud services. We were discussing the management of their communications infrastructure and I suggested a management server that would provide the view and capabilities that were being requested. The first response I received from this definition was if it would run on Amazon’s cloud service, if not what was the size of the server.
This request gave me pause, and so I asked why the size request. The engineer stated that the CTO had an 8lb. rule for any device, if it was heavier than 8 pounds, then it had to go in the cloud. Apparently devices under 8 pounds could be hosted in the enterprises data center.
An interesting decision point, 8 pounds;
17 inch laptop > 8 pounds
1RU device (really does not matter what function) > 8 pounds
UPS >>> 8 pounds
Router > 8 pounds
Basically any device that would normally be found in a data center all are over-weight and should be positioned as a service in the cloud. This limited the data center to the essential elements that were needed to provide connectivity to the cloud for the enterprise.
I started thinking about the 8 pound rule, and like any rule, I schemed about what I could get away with and still stay within the rules. I modified the rule a little, instead of judging each device separately, I use the 8 pound rule as a total system weight, 8 pounds, 128 ounces, what could I build as far as a data center was concerned.
What I came up with is interesting.
Using standard components I arrived at a small data center, 1.2 TB or storage, data base server, AAA server, web server, and application server. A 1Gbps infrastructure with security and Internet connectivity.
The weight-in was
I have a little over 2 pounds left over for growth, adding more storage or compute power. An interesting study, but really not the point I was aiming for when I started this post. Techies, so squirrel prone that any reason to get off topic can be interesting, back to where I was.
Conclusion:
The problem with my data center in a shoe box is the reliability, survivability, and availability of the system, one pulled plug and my entire system is off-line.
When it comes right down to the choice of creating your own or using a cloud, the decision has not changed from when I was teaching about frame relay. The question is “what is the prime business that an enterprise is in”? Is it a data center business, a data transmission business, or is it more likely an enterprise that develops and sells products over the Internet. An enterprise should put its resources where they will generate revenue, not in support of systems that are overhead.
The economic realities of cloud services are here today, the technical realities in the terms of security, reliability, regulatory conformance and survivability are being addressed. Fewer and fewer enterprises are able to justify a data center. If you have not so already, it might be time to create your enterprises’ 8lb. Rule.
discoholicmusic
2087
jbbartram-illu
gummygunk
prguitarman