Archive

Archive for the ‘cisco’ Category

Technical Book Annoyances

September 3, 2010 Leave a comment

It seems that if you read enough technical stuff, you are bound to find things you either disagree with, or know to be untrue. At least I think they are untrue until I validate my thoughts with the applicable standard or bounce my thoughts off of others within the IT community. I understand that it is VERY difficult to write books, white papers, articles, etc with a technical focus and have them turn out well. A lot of editing has to take place. The target audience has to be considered as well. In short, it is a lot different than writing a fiction novel or short story as when it comes to technical stuff, there’s a bunch of people out there second guessing every sentence you write and diagram you create. With fiction writing, the entire story is in someone’s head and accuracy is not a factor. Let me also state that I have tremendous respect for most technical authors.

However………

I have been doing a lot of reading on switching lately. I’m lazily making my way to the CCIE R/S lab attempt so I have been reading the 3560 command reference guide. It’s the Good Will Hunting approach. In addition to that, I decided to supplement my lunch today with some reading of End-to-End QoS Network Design. So, now that I am thinking about switching and QoS, I came home after work and started in on my so far unused copy of Cisco LAN Switching Configuration Handbook. There’s a QoS chapter. Hooray! The best of both worlds.

I get to the end of the third page in the chapter and run into a problem. That’s page 223 if you have the printed version handy. I came across this tidbit:

Classes 1 through 4 are termed the Assured Forwarding (AF) service levels. Higher class numbers indicate higher-priority traffic. Each class or AF service level has three drop precedence categories:

* Low (1)
* Medium (2)
* High (3)

Traffic in the AF classes can be dropped, with the most likelihood of dropping in the Low category and the least in the High category. In other words, service level AF class 4 with drop precedence 3 is delivered before AF class 4 with drop precedence 1, which is delivered before AF class 3 with drop precedence 3, and so on.

Did you spot any errors? At first, I thought I was reading it all wrong. Maybe I misinterpreted what the authors were saying. AF classes have different priority levels? Hmmmm. I thought they were the same. Then of course, there’s the issue of the book stating that the higher the drop precedence, the less likely it will get dropped. In other words, the book is saying that AF43 will get dropped less than AF41 along with a repeat of the logic stated earlier that AF41 comes before AF33 in terms of priority. At this point, I am really starting to get confused. That can’t be right. I’ve never heard anything like that before.

Maybe it was an error that was fixed in the errata that Cisco Press usually posts on their site. I checked, and there were no corrections issued for that particular book on the Cisco Press site. I also went over to Amazon and read through the reviews people had written. A lot of times, people will list errors in their book reviews, so it is a good source of information when determining whether or not to buy the book. There was nothing there that alluded to this potential error.

The next step was to check the RFC along with the End-to-End QoS book I am reading as well. RFC 2597 is entitled Assured Forwarding PHB Group. Or, AF per hop behavior group. Remember that in a DiffServ environment, QoS is done on a per class basis. There is no end to end guarantee for an individual flow so to speak. That’s what IntServ is for. One might even say that a per hop behavior is indicative of each hop being able to do whatever they want to traffic based on the class it is in. The router could care less about the entire flow. It looks at DSCP markings and makes a decision based on that. Maybe that’s being too generic, but that is the way that I understand DSCP, PHB, etc. The RFC said the following:

Section 1 Paragraph 3

Within each AF class IP packets are marked (again by the customer or
the provider DS domain) with one of three possible drop precedence
values. In case of congestion, the drop precedence of a packet
determines the relative importance of the packet within the AF class.
A congested DS node tries to protect packets with a lower drop
precedence value from being lost by preferably discarding packets
with a higher drop precedence value.

Section 2 Paragraphs 1 and 2

Assured Forwarding (AF) PHB group provides forwarding of IP packets
in N independent AF classes. Within each AF class, an IP packet is
assigned one of M different levels of drop precedence. An IP packet
that belongs to an AF class i and has drop precedence j is marked
with the AF codepoint AFij, where 1 <= i <= N and 1 <= j <= M.
Currently, four classes (N=4) with three levels of drop precedence in
each class (M=3) are defined for general use. More AF classes or
levels of drop precedence MAY be defined for local use.

A DS node SHOULD implement all four general use AF classes. Packets
in one AF class MUST be forwarded independently from packets in
another AF class, i.e., a DS node MUST NOT aggregate two or more AF
classes together.

Okay, so the RFC is fairly clear that the lower the drop precedence, the safer the traffic should be. Routers and switches should drop AFx3 before AFx2, and drop AFx2 before AFx1. Additionally, we learn that the 4 AF classes are general use. There is no hierarchy. AF4x is no different than AF2x. We may give AF4x more bandwidth in a given QoS policy during periods of congestion, but we can also do the same for AF3x, AF2x, or AF1x traffic if we want to.

Looking for the same type of information in the End-to-End QoS book yields the following taken from chapter 3, Classification and Marking Tools, in the “Marking Tools” section:

DSCP values can be expressed in numeric form or by special keyword names, called per-hop behaviors (PHB). Three defined classes of DSCP PHBs exist: Best-Effort (BE or DSCP 0), Assured Forwarding (AFxy), and Expedited Forwarding (EF). In addition to these three defined PHBs, Class-Selector (CSx) codepoints have been defined to be backward compatible with IP Precedence (in other words, CS1 through CS7 are identical to IP Precedence values 1 through 7). The RFCs describing these PHBs are 2547, 2597, and 3246.

RFC 2597 defines four Assured Forwarding classes, denoted by the letters AF followed by two digits. The first digit denotes the AF class and can range from 1 through 4. (Incidentally, these values correspond to the three most significant bits of the codepoint, or the IPP value that the codepoint falls under.) The second digit refers to the level of drop preference within each AF class and can range from 1 (lowest drop preference) to 3 (highest drop preference). For example, during periods of congestion (on an RFC 2597–compliant node), AF33 would be dropped more often (statistically) than AF32, which, in turn, would be dropped more often (statistically) than AF31. Figure 3-7 shows the Assured Forwarding PHB encoding scheme.

More validation that I was correct in my initial hunch. Even though I was fairly certain the LAN Switching Configuration Guide book was wrong, I wanted to double-check with perhaps one of the greatest tools available. Twitter. I got responses from 3 different people, which is saying something considering it was about 10PM CST. Thanks to Steve Shaw, Steve Rossen, and Andrew vonNagy for their assistance in validating my assumptions. Steve Shaw pointed me to the exact paragraph in RFC 2597 and Andrew mentioned 1 of the 3 new QoS videos that Kevin Wallace created and posted on YouTube which discuss the AF class and drop precedence. Check it out. It’s a fantastic video.

Now, you might be wondering why I am making such a big deal out of this. Is it really important? In this case, yes. Understanding the AF class and drop precedence is vital to one’s understanding of DSCP as a whole. If you get this wrong, it could bite you down the road when designing a QoS policy for a large network. It can bite you when troubleshooting a QoS problem. Some things have to be right every single time they are put in print. QoS is not some super-easy technology that can be mastered in a half-day. Auto-QoS is a great functionality on hardware. I used it this past weekend when configuring 3750 POE switches for use with Cisco phones. However, typing a command and understanding what the ramifications are of that command are 2 different things.

Thank goodness for multiple sources!

Advertisements
Categories: cisco, documentation, qos, routing, switching Tags:

Is It Possible To Stay Vendor Neutral?

August 4, 2010 5 comments

***Note: I am asking this question from a corporate IT perspective. I am not asking this from the standpoint of a vendor or reseller.

Most of what I do in the networking world revolves around one vendor’s equipment. Not all, but most. Can you guess the vendor? 😉

Do we buy most of our equipment from vendor XYZ for any of the following reasons?

1. We are comfortable with it.
2. Their products work.
3. The support is good. Documentation is abundant and detailed.
4. They have the most features.
5. Their cost is lower.
6. There is a large talent pool out there that knows their products.
7. They provide a complete end to end solution.
8. They are a financially stable company.
9. They get great reviews from all the trade magazines.
10. No other company has this particular technology/protocol/gadget.
11. They always buy us a great lunch and take us to sporting events for free. (Or some variation of this.)
12. We want one throat to choke if there are problems.

Perhaps some of these apply to you in terms of your relationship with vendor XYZ. I believe that some of those things are very valid reasons to buy from vendor XYZ. Some of them are not.

The problem, as I see it, is that SOMETIMES what we buy isn’t necessarily the BEST solution for the company. Notice that I said SOMETIMES. There are plenty of times in which we buy from vendor XYZ because it is the BEST solution for the company.

There’s a lot to be said for vendor comfort level. I, along with many others, know a decent amount about the Cisco switch and router product line. I know a LOT less about every other vendor’s switch and router product lines. Just for fun, over the past couple of weeks I have looked at other vendor’s switches and routers and tried to compare them to the Cisco line. It has been an interesting experiment to say the least. In the latest Packet Pushers podcast, Greg Ferro of etherealmind.com mentions something similar. Towards the end of the podcast he talks about how frustrating it is that other hardware vendors have the spec sheets for each model as a separate PDF. There’s no easy way to do a side by side comparison. See here for an example. I should point out that Juniper does have a “Compare Family Models” link on the main page of each product family but it is not a full blown separate page.

Let’s take switches for example. If I want to evaluate alternatives to the Cisco 3560 switch, how do I go about doing that? What vendors do I look at? There are easily a dozen vendors that I can look at. At what point do I draw a line in the sand and say that I am only going to look at 5 alternative vendors, or 3? Do I base the decision solely on features? Cost? Market share?

In regards to all of that, I would simply ask: “How much time do you have?”. My experience has been that doing something right takes time. If you don’t take the time to do it right, you’ll cut corners. One of the easiest corners to cut is in the vendor selection process. Just because a name is familiar doesn’t mean that it is going to be the best choice. It’s better to take the time and make the right choice than to buy what is familiar and wind up with bigger problems down the road.

Is it possible to stay vendor neutral? Yes, but it requires a lot of time and effort. Unfortunately, we don’t always have the time. I have pretty strong feelings toward certain product lines. Juniper’s SA line of SSL VPN appliances are nothing short of spectacular. HP’s Network Automation Software (CiscoWorks NCM) is an amazing product as well. There are several Cisco products that I could say the same thing about. Although I feel strongly about them, if someone were to show me a better product that was a better fit(cost,features,support), I would have no logical reason to oppose it. Business is business.

I have to be honest though. I have a certain inclination to lean towards Cisco many times during product selection. This is due to several factors that I listed at the beginning of this post. Two of the biggest reasons are the sheer amount of features their products contain as well as the generally large amount of documentation available for each product. Those two reasons don’t always hold true for all of their products, but more often than not, that is the case. Of course, for any substantial project(WAN optimization, wireless, IP telephony, firewall, network management), I would be foolish not to consider multiple vendors. For the smaller things, it just seems so easy to order a switch or two from Cisco. Is that me cutting corners? Well, as in anything, it depends. 😉

Categories: cisco, vendors Tags: ,