Posted: April 1st, 2010 | Author: charlie | Filed under: IT Management | Tags: linux, ROI, web hosting | 1 Comment »
Whether you are a small business, fortune 500, or in-between, Web hosting providers may have something to offer. Web hosting is extremely competitive, and not many companies survive. Once the need for Web hosting services is established, you need to do some research to determine whether a specific hosting company is a good fit.
Small businesses will depend more heavily on their hosting provider, as their entire Web infrastructure may reside at a hosting company. As businesses get larger, and acquire their own IT staff, they tend to start running their own Web servers. At some point, maybe due to cost-cutting measures, companies may revisit the hosting option. If it’s really only $5 per month, then why not?
Hosting companies also offer virtual machines that your IT staff can run. These are a great alternative to hosting DR servers in remote data centers. VM plans are more expensive than a regular shared Web hosting plan, but not much more. With both options we need to pay close attention to the hosting company’s track record and value-add services.
What to Expect
There are literally hundreds of popular hosting companies out there. Each has their own tools for managing your domains, and each offers their own unique set of value-add services.
At a minimum, there are a few things you should demand from any Web host. Due to the brutally competitive nature of the business and interchangeability of these services, you should never be shy about demanding a new feature or picking up and moving to a new provider. A few of the basic things you should expect are:
- A Web interface to manage your domains, billing, and user accounts
- Shell, SFTP, and various other methods of remote access
- Unlimited MySQL databses, and an easy way to create and manage them
- Easy, automated installation mechanisms for common open source Web applications
- Unlimited e-mail boxes and a few options for Web-based access
- Log analysis and detailed reporting
- And lately: unlimited disk space and bandwidth
Five or ten years ago you would not find most of these features with the most popular hosting companies. These days, however, they all offer most of these items and a lot more.
Companies that offer VM hosting, or Virtual Private Servers (VPS) as some call it, will provide a basic set of tools to manage your virtual machine. You can generally select from a few operating systems and reload it at any time. Afterwards, however, you’re on your own. You get the root password and are free to install whatever you need.
Is it Worth It?
Psychologically, most people have a problem purchasing something that appears too cheap. When looking at Web hosting services, the list of options leaves most people drooling. Then they see the price: sometimes less than $5 per month, for unlimited disk space, bandwidth, accounts, and with a free domain registration. How can they do that?
The servers must be horribly overloaded as these companies cram more and more customers onto them. At $60 per year per customer, the hosting company can’t exactly afford to buy top of the line servers, right?
The truth is, hosting is brutally competitive. Most companies fail. The ones that survive have a high level of automation to allow them to manage their servers with very little manhours. Even at today’s sub-$5 pricing for a monthly plan, that equates to one $3000 server per 50 customers, at their yearly rate. A properly configured Apache Web server environment should be able to handle 300 Web sites on today’s hardware without a problem.
Of course, someone could write a PHP script that goes wild and consumes way too many resources, slowing down the entire server. The hosting companies monitor the servers, and this type of thing is usually dealt with quickly. However, it is worthwhile to ask your chosen hosting company whether or not they allow adult content. Adult sites are generally very high-traffic, and if you’re site is sharing the same Web server, it may suffer performance issues.
The Case for Secondary Hosting
Enterprises should not rule out hosting providers. You don’t need to outsource your entire Web team, but part of a good disaster recovery strategy will certainly include multiple off-site resources. Instead of paying co-location fees and trodding your own servers to a datacenter across the country, why not get a few virtual machines in multiple locations?
If your physical server dies, you may be sending FTE to the remote site to replace the hardware. In a hosted VM environment, you never have to worry about taking employees away from their daily work and paying travel expenses. Just click a button in the hosting provider’s Web interface to create a new VM if something goes awry.
You can host your own Web servers, secondary DNS, or just about any other service your company relies upon. If you’re worried about reliability, you can always select two or three VM providers in separate parts of the country (or world). To equal the cost of one server in a co-location environment, you’d have probably 10-20 virtual machines spread throughout the world.
Next Steps
If you’re interested in hosting Web sites with a Web hosting provider or VMs, the next step is to do some research. Read reviews of various hosting companies, and pay attention to issues people cite. There will always be a certain amount of people unhappy with a service, but pay careful attention to what they are saying went wrong. Likewise, pay attention to the few positive reviews you might find. Most happy customers remain silent, so when you find a positive review it holds more weight than a rant.
“Cheap web hosting” is a great Google search. You will find a few unbiased sites that list providers, the services they offer, reviews, and pricing. We don’t want to make any recommendations, but just remember: more expensive is not always better in a fiercely competitive market such as Web hosting.
1 Comment » Related posts:
- Managing Virtual Machine and Cloud Sprawl
- How Much Server do you Need?
- Zenoss: We Can Ditch Nagios Now
- Understanding Linux Virtual Memory
- The Perils of Sudo With User Passwords
Posted: March 17th, 2010 | Author: charlie | Filed under: Networking 101 | Tags: ccna, cisco, networks | No Comments »
What’s more important than IP and routing? Well, Layer 2 is much more important when it’s broken. Many people don’t have the Spanning Tree Protocol (STP) knowledge necessary to implement a Layer 2 network that’s resilient. A switch going down shouldn’t prevent anyone from having connectivity, excluding the hosts that are directly attached to it. Before we can dive into Spanning Tree, you must understand the innerworkings of layer 2.
Layer 2, the Data Link layer, is where Ethernet lives. We’ll be talking about bridges, switching, and VLANs with the goal of discovering how they interact in this part of Networking 101. You don’t really need to study the internals of Ethernet to make a production network operate, so if you’re inclined, do that on your own time.
Ethernet switches, as they’re called now, began life as a “bridge.” Traditional bridges would read all Ethernet frames, and then forward them out every port, except the one it came in on. They had the ability to allow redundancy via STP, and they also began learning which MAC addresses were on which port. At this point, a bridge then became a learning device, which means they would store a table of all MAC addresses seen on a port. When a frame needed to be sent, the bridge could look up the destination MAC address in the bridge table, and know which port is should be sent out. The ability to send data to only the correct host was a huge advancement in switching; collisions were much less likely. If the destination MAC address wasn’t found in the bridge table, the switch would simply flood it out all ports. That’s the only way to find where a host actually lives for the first time, so as you can see, flooding is an important concept in switching. It turns out to be quite necessary in routing too.
Important terminology in this layer includes:
Unicast segmentation : Bridges can limit which hosts hear unicast frames (frames sent to only one MAC address). Hubs would simply forward everything to everyone, so this alone is a huge bandwidth-saver.
Collision Domain : The segment over which collisions can occur. Collisions don’t happen any more, since switches use cut-through forwarding and NICs are full-duplex. If you see collisions on a port, that means someone negotiated half-duplex accidentally, or something else is very wrong.
Broadcast Domain : The segment over which broadcast frames are sent and can be heard.
A few years later, the old store-and-forward method of bridge operation was modified. New switches started only looking at the destination MAC address of the frame, and then sending it instantly. Dubbed cut-through forwarding, presumably because frames cut through the switch much quicker and with less processing. This implies a few important things: a switch can’t check the CRC to see if the packet was damaged, and that implies collisions needed to be made impossible.
Now, to address broadcast segmentation, VLANs were introduced. If you can’t send a broadcast frame to another machine, they’re not on your local network, and you will instead send the entire packet to a router for forwarding. That’s what a Virtual LAN (VLAN) does, in essence–it makes more networks. On a switch, you can configure VLANs, and then assign a port to a VLAN. If host A is in VLAN 1, it can’t talk to anyone in VLAN 2, just as if they lived on totally disconnected devices. Well, almost; if the bridge table is flooded and the switch is having trouble keeping up, all data will be flooded out every port. This has to happen in order for communication to continue in these situations. This needs to be pointed out because many people believe VLANs are a security mechanism. They are not even close. Anyone with half a clue about networks (or with the right cracking tool in their arsenal) can quickly overcome the VLAN broadcast segmentation. In fact, a switch will basically turn into a hub when it floods frames, spewing everyone’s data to everyone else.
If you can’t ARP for a machine, you have to use a router, as we already know. But does that mean you have to physically connect wires from a router into each VLAN? Not anymore, we have layer 3 switches now! Imagine for an instance, if you will, a switch that contains 48 ports. It also has VLAN 1 and VLAN 2, and ports 1-24 are in VLAN 1, while ports 25-48 are part of VLAN 2. To route between the two VLANs, you have basically three options. First, you can connect a port in each VLAN to a router, and assign the hosts the correct default route. In the new-fangled world of today, you can also simply bring up two virtual interfaces in each VLAN. In Cisco land, the router interfaces would be called vlan1 and vlan2. They get IP addresses, and the hosts use the router interface as their router.
The third way brings us to the final topic of the layer 2 overview. If you have multiple switches that need to contain the same VLANs, you can connect them together so that VLAN 1 on switch A is the same as VLAN 1 on switch B. This is accomplished with 802.1q, which will tag the packets as they leave the first switch with a VLAN identifier. Cisco calls these links “trunk ports,” and you can have as many VLANs on them as the switch allows (currently 4096 on most hardware). So, the third and final way to route between VLANs is to connect a trunk to a router, and bring up the appropriate interfaces for each VLAN. The hosts on VLAN 1, on both switch A and B will have access to the router interface (which happens to be on another device) since they are all “trunked” together and share a broadcast domain.
We’ve saved you from the standard “this is layer 2, memorize the Ethernet header” teaching method. To become truly guru you must know it, but to be a useful operator, (something the cert classes don’t teach you) simply understand how it all works. Join us next time for an exploration of most interesting protocol in the world, Spanning Tree.
No Comments yet... be the first » Related posts:
- Networking 101: Understanding Layers
- Networking 101: Subnetting – Slice Up 32-bits
- Networking 101: More Subnets, and IPv6
- Networking 101: IP addresses
- Are Cisco Flex Links the End of STP?
Posted: March 15th, 2010 | Author: charlie | Filed under: SAN 101 | Tags: education, SAN, storage, storage networking | No Comments »
As we dive deeper into SAN technology, it’s Fibre Channel’s turn to be examined. FC is the underpinning of all SAN technologies these days, as it won the protocol war roughly 25 years ago.
FC wouldn’t be much use without something on top of it, namely SCSI. FC is the low-level transport that ships data, but hosts are normally talking SCSI as far as they’re concerned. The hubs, switches, and HBAs in a SAN all speak FC, while the applications that use SAN storage continue to use familiar protocols, like SCSI.
The idea behind FC was to create a high throughput, low latency, reliable and scalable protocol. Ethernet wouldn’t quite cut it for highly-available storage needs. FC can currently operate of speeds up to 10Gb/s (10GFC) for uplinks, and 4Gb for standard host connections. FC also provides small connectors. As silly as it sounds, SCSI cables become unruly after time, and small strands of fibre are certainly easier to manage. The equipment required to connect to a FC SAN (multiple HBAs for each host, fibre, and switches) is extremely expensive, and was the main reason SAN technologies took so long to become widely adopted.
Topologies
In reality, two different protocols, or topologies, make up the FC protocol. FC supports all topologies, but the behavior of the protocol changes depending on the topology. The following three types of topologies are supported:
- PTP (point to point): normally used for DAS configurations.
- FC-AL (FC Arbitrated Loop): Fabric Loop ports, or FL ports on a switch, and NL_Ports (node loop) on an HBA, support loop operations.
- FC-SW (FC Switched): the mode when operating on a switched SAN.
FC-AL operation is quite scary, but sometimes a device doesn’t support FC-SW operations, and there’s no choice. A hub has no choice but to operate in FC-AL mode, and therefore attached hosts must as well. When a device joins an FC-AL, or when there’s any type of error or reset, the loop must reinitialize. All communication is temporarily halted during this process, so it can cause problems for some applications. FC-AL is limited to 127 nodes due to the addressing mechanism, in theory, but in reality closer to 20. FC-AL is mostly relegated to niche uses now, including but not limited to internal disk array communications and internal storage for high-end servers.
FC switches can be connected any way you please, since the FC protocol avoids the possibility of a loop by nature. Ethernet isn’t so lucky. The addressing scheme used does impose a limit of 239 switches though. FC switches use FSPF, a link-state protocol like OSPF in the IP world, to ensure loop-free and efficient connectivity.
FC networks are generally designed in one of two ways: either one big star, or one big star with edge switches hanging off it. These are commonly known as “core-only” and “core-edge” configurations. Normally a SAN will contain two of these networks, and each host’s HBA or storage device’s controller will attach to each. Keeping these networks separate isn’t as necessary as it is with FC-AL topologies, but even with FC-SW setups it still provides complete isolation and assurance that a problem in one fabric won’t impact the other. An FSPF recalculation, for example, could cause a brief interruption in service.
Ports
As previously mentioned, there are different port types in a SAN, and it can get confusing. Let’s try to clear up some of that terminology:
- N_Port: Node Port; the node connection point; end points for FC traffic
- F_Port: Fabric Port; a switch-connected port, that is a “middle point” connection for two N_Ports
- NL_Port: Node Loop Port; connects to others via their NL_Ports, or to a switched fabric via a single FL_Port; or NL_port to F_Port to F_Port to N_Port (through a switch)
- FL_Port: Fabric Loop Port; a shared point of entry into a fabric for AL devices; example NL_Port to FL_Port to F_Port to N_Port
- E_Port: Expansion Port; used to connect multiple switches together via ISL (inter-switch links)
- G_Port: Generic Port; can switch between F_Port and E_Port operation depending on how it’s connected
- TE_Port: Trunked Expansion Port; link aggregation of multiple E_Ports for higher throughput
You’ll generally only see F_Ports and FL_Ports when looking at a single SAN switch, and knowing the difference helps. FL means that you’re talking FC-AL, and there’s a device attached that is either a hub, something that can’t do anything but FC-AL, or something strange. Ports will automatically configure themselves as an FL_Port if the attached device is Loop-only, otherwise it will be an F_Port. It’s also worth noting that some brands of FC switches don’t allow you to have an E_Port unless you pay a higher licensing fee. It’s something to think about if you ever plan to connect multiple switches together.
FC Layers
FC has its own layers, so in fact, calling it “like Ethernet” isn’t quite accurate, even if it helps for understanding. They are:
- FC-0: The interface to the physical media; cables, etc
- FC-1: Transmission protocol or data-link layer, encodes and decodes signals
- FC-2: Network Layer; the core of FC
- FC-3: Common services, like hunt groups
- FC-4: Everything! Protocol mapping for SCSI, iSCSI, FCP, IP, and others
The bulk of FC is really in FC-2. FC-PH refers to FC-0 through FC-2, which are strangely dubbed the physical layers.
FC also supports its own naming and addressing mechanism, which sheds light on the previously mentioned limitations in FC-AL and FC-SW topologies. Next time, we’ll discuss the header format for FC-2 as well as FC address assignment and name resolution.
In a Nutshell:
- FC is the transport mechanism, and SCSI or even IP rid atop FC
- FC-AL is a loop, where all connected devices see each other, and a re-initialization takes out the entire SAN
- Port types reveal what is actually happening, and knowing what they stand for can aid in topology visualization when looking at a switch’s configuration
No Comments yet... be the first » Related posts:
- SAN 101: Intro to SANs and Storage
- Networking 101: Understanding Layers
- Understanding Linux Virtual Memory
- Networking 101: Layer 2, Link and Spanning Tree
- Are Cisco Flex Links the End of STP?
Posted: March 15th, 2010 | Author: charlie | Filed under: Linux / Unix, Security | Tags: linux, Security | 2 Comments »
A wise man once said, “everyone is root if you allow them to login as a user,” in retort to a question about the security of a multi-user Linux system. There is plenty of truth in that, but just accepting eminent compromise isn’t always acceptable. Let’s take a look at how you can limit your exposure while letting unknown and untrusted users login with a shell.
There are basically two groups of people who’d want to restrict login users heavily. First, the collaborators, possibly two separate organizations that have been forced to work together. Second, people who wish to allow some shady characters access to a shell, but believe they may attempt to compromise security. If at all possible, the best policy is to simply not give access out, and if you do, make sure patches are applied daily.
To say that you simply shouldn’t give out shells to untrustworthy users may work in a few instances. Say, for example, there is a need for remote users at another site to login and run the same series of commands every day. Say, for the sake of argument, their task can be easily scripted. If this is their only purpose on the server, a shell certainly isn’t necessary. OpenSSH allows a set of restrictions to be applied to an SSH key.
At the end of an SSH key entry, you can tack on these options:
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command=”~/bin/script.sh”
This effectively restricts any SSH connections using this key to only being allowed to run the mentioned script. This can even be a setuid script that restarts a web server, for example. It’s quite safe, because OpenSSH will reject any variation of the command= text. Users possessing this key will only be able to execute the command that is explicitly allowed.
Aside from that, and possibly some fancy web-based tools or cron jobs, there aren’t may options left. At times users just need to be able to login and work.
It should go without saying that you need to stay up-to-date on patches. We won’t focus too much on that, aside from saying: automate! Securing a machine is an entirely different topic all together, but here are a few points to consider.
Enabling SELinux (Security-Enhanced Linux) is your first line of defense against unknown attacks. SELinux can prevent buffer overflows, as opposed to simply taking the “updates” path, which requires that a publicly known hole be fixed before some tries to exploit it. SELinux provides a significantly improved access system to limit programs from accessing things they don’t require to be operational. That, combined with overflow prevention makes it quite difficult to compromise a Linux system.
Further, on the issue of securing a multi-user machine, there is a much-debated precept: that users shouldn’t be able to see what processes are running, unless they own them. This restriction is simple to enable in Linux and the BSD’s, but does it really buy you anything? The answer is “maybe,” and at the same time, “not really.” To satisfy the maybe camp, consider a process’s arguments. When you run a command with a given set of arguments, the command as well as the arguments will show up in a ‘ps’ listing. If you have provided a password on the command-line for some reason, it will be visible to anyone running a ‘ps’ while your process is still running. Many people think that allowing users to see running daemon processes on a server will allow them to know what to try attacking. This information is trivial to obtain via other means anyway, so “not really.”
Every time this discussion starts, someone quickly suggests a chroot jail. The chroot command stands for “change root,” which does just that. If you run the command: ‘chroot /home/charlie /bin/bash’ then chroot will look for the shell in /home/charlie/bin/bash, and then proceed to lock you into that directory. The new root of the file system, for the lifetime of the bash shell, is /home/charlie. You now have zero access to any other part of the actual file system. Any available command, and its required libraries, needs to be copied into the chroot jail. Providing a usable environment is a ton of work. It’s actually easier to give each user their own Linux Xen or Solaris Zone instance. Really.
Finally we come to the restricted shells. The most popular, rbash, is a restricted bash shell. Setting a user’s shell to rbash will provide absolutely zero security. In theory, rbash will prevent users from running anything by specifying a full path, including ‘./’ (the current directory). This implies that it’s difficult for users to run commands, including scripts they write or downloaded exploits. Since $PATH is controlled globally, users can only run things in those locations. Unfortunately, /bin/ is going to need to be in their path, so all a user needs to do is run a new shell, and rbash is no longer in the picture: ‘exec bash’
One method of alleviating this is to give users only one item in their path, a directory the administrator created. Within the directory, simply place symlinks to all the authorized commands. This is nearly as cumbersome as setting up chroot, but much more tolerable.
Security isn’t convenient, and if it is, you’re doing something wrong.
There are certainly ways to prevent users from running downloaded programs, but in the end, the multi-user security of a system will depend on security of every piece of software installed. Preventing the exploits from being successful, a la SELinux, adds the most viable method of protection. Coupled with a frequently updated system, additional restrictions such as rbash aren’t generally necessary.
2 Comments » Related posts:
- The Perils of Sudo With User Passwords
- Built-in Security with Cisco IPS
- Understanding Linux Virtual Memory
- Back to Basics: Unix File Permissions
- LDAP: Understand the Protocol and Work With Entries
Posted: March 8th, 2010 | Author: charlie | Filed under: Networking | Tags: cisco, networks, performance, VoIP | No Comments »
WANs often need Quality of Service (QoS) configured to ensure that certain traffic is classified as “more important” than other traffic. Until now, it took a serious Cisco guru to configure a network properly for VoIP if the network was at all bandwidth constrained. AutoQoS, a new IOS feature for Cisco routers, makes deploying VoIP easy, even on busy WAN links. In this article we’ll cover the basics, what AutoQoS does, and some of its limitations.
The first whack at AutoQoS was Cisco recognizing the need to simplify VoIP traffic prioritization. VoIP is especially sensitive to any latency, jitter, or loss, and users will notice problems. To ensure the best possible VoIP call, the network must ensure that lower priority 
traffic does not interfere with time-sensitive VoIP. AutoQoS can be enabled on both WAN links and Ethernet switches to automatically provide a nice best-practices based template for VoIP prioritization.
How it Works
QoS allows a router to classify which types of traffic are most important, and ensure that that traffic passed as quickly as possible. If necessary, other traffic will be queued until the higher priority traffic has had a chance to pass. Before a router can know when to queue versus when to attempt to pass all traffic, it must be configured with bandwidth settings for each link.
Configuring QoS on a Cisco router normally involves a complex series of interactions, which require understanding not only the protocols, but a router’s strange way of associating policies. The basic steps are:
- Use an ACL to define which traffic gets matched
- A class-map classifies matched traffic into classes
- A policy-map assigns priorities to the classes
- The policy-map is applied to the interface, which enables the processing of all packets through the ACL, class-map, and policy-map
Each of these “maps” are quite complicated and prone to error. Most sites are going to be duplicating effort because of common problems, like VoIP, needing QoS help.
Why AutoQoS
QoS configuration is not simple. It requires understanding the protocols your network interfaces are using, as well as the type of data you’re passing. To configure QoS for VoIP, for example, you must understand how VoIP works. In short, it requires a guru. If you’re like me, you literally giggled out loud the first time you encountered the word, “AutoQoS.”
AutoQoS enables any network administrator to just “turn on” a solid solution for ensuring VoIP is happy. VoIP is the pain point for most organizations, so that’s what Cisco focused on first, and that’s what we’re focusing on here. Given the limited scope of AutoQoS, it’s believable that it works well enough. In reality, QoS configurations generally classify many types of traffic, and then place a priority on each one.
The main benefit of AutoQoS is that administrator training is much quicker. It also means that VoIP deployments often go much smoother, and upgrading WAN links isn’t usually required. Finally, AutoQoS creates templates that can be modified as needed and copied elsewhere for deployment.
Limitations
Before talking about how to enable AutoQoS, which is literally three commands, let’s talk about where this works best, and what’s required to use AutoQoS.
First and foremost, you can only configure AutoQoS on a few types of router interfaces. These interfaces include:
- PPP or HDLC serial interfaces
- ATM PVCs
- Frame Relay (point-to-point links only)
Cisco catalyst switches also support an AutoQoS command to prioritize Cisco VoIP phones, but you cannot prioritize (using AutoQoS) generic VoIP protocols.
Next, there are some limitations with ATM sub-interfaces. If you have a low-speed ATM link (less than 768Kbps), then AutoQoS will only work on point-to-point sub-interfaces. Higher speed ATM PVCs are fully supported though. For standard serial links, AutoQoS is not supported at all on sub-interfaces. A quick litmus test to see if AutoQoS will work on your desired interfaces or not is to verify that the service-policy configuration is supported. If not, you’ll probably have to reconfigure some links.
AutoQoS will not work if an existing QoS configuration exists on an interface. Likewise, when you disable the AutoQoS configuration, any changes you may have made to the template after the initial configuration will be lost.
Bandwidth statements are used by AutoQoS to determine what settings it should use, so remember that after updating bandwidth statements in the future, you have to re-run the AutoQoS commands.
Making it Work
In the most standard situation, where VoIP isn’t performing as it was promised, the network admin can quickly save the day by running the following on the WAN interface:
interface Serial0
bandwidth 256
autoqos voip
If it’s the local network that needs tuning, the following can be run on Catalyst switches (if running Enhanced Images):
auto qos voip cisco-phone
auto qos voip trust
It really couldn’t be easier than that. For the WAN example, we told the router that interface Serial0 has 256 Kbps, and to enable VoIP QoS. The switch example is similar, for Cisco phones.
The neat part about this is that AutoQoS is actually doing more than just generating a configuration for you and forgetting about it. If you run the command show autoqos interface s0, you will see much more than just your standard old interface configuration. It will show that a Virtual Template “interface” has been created, and that a class is applied to the interface. The same output will also show you the configuration of the template and class-map, with an asterisk next to each entry that was generated by AutoQoS. It’s actually keeping track of what was done automatically so that you can learn what AutoQoS is doing. As mentioned previously, however, don’t forget that removing the AutoQoS configuration will destroy all QoS settings on an interface, not just the ones that AutoQoS configured.
Finally, remember to enable QoS on both sides of a WAN link to truly prioritize VoIP packets. Don’t forget to read through the Cisco documentation before deploying it, even though AutoQoS is simple, in comparison. It is simple, but the more prepared you are the easier it is to deploy.
Cisco will hopefully continue this trend of providing Auto features for complicated, but common tasks. AutoQoS for VoIP sure does enable a much larger audience to correctly deploy VoIP over a wide variety of networks.
No Comments yet... be the first » Related posts:
- Are Cisco Flex Links the End of STP?
- Built-in Security with Cisco IPS
- Manage Devices and Configurations with Cisco SDM
- What the Heck is a TCAM?
- Networking 101: Layer 2, Link and Spanning Tree
