CCIE or Null!

My journey to CCIE!

Archive for November 2011

A quick look at the MQC and CBWFQ

leave a comment »

As I jumped into my QoS studies my first though was going to be “I’m in way over my here head this is not going to be fun”, after all QoS is a very daunting subject. However as I trek my way through the QoS Exam Guide I am finding QoS easier to swallow. A very large topic in the QoS exam guide is the MQC – Modular QoS CLI (Yes, an acronym within an acronym) this MQC is the way to configure QoS and boy is it simple to get the hang of. In fact the configuration of a Zone Based Firewall was actually based off the MQC design. That was a big relief to me, I’ve spent plenty of time around firewalls and to find out that the QoS MQC is really the heart of the zone based firewall configuration I was relieved, and even more relieved when I saw the configuration and understood it fairly quickly.

Let’s take a quick run through the configuration of Class Based Weighted Fair Queuing (CBWFQ) using the MQC.

Step 1: The Class-Map

The first step is to create the class map, the class map is used to classify the data. The data can be matched by an ACL, specific protocol information, DSCP, or IP Precedence values

Below is a list of other match statements, as you can see the list is quite extensive. You can match on everything from a specific interface to a frame-relay DLCI. Also notice the not statement, which allows you to exclude variables from the class map a nifty trick that can come in handy from time to time.

Step 2: The Policy-Map

Now, the policy map is where you add the class maps (remember the class map is case sensitive) and have the router do something you want with traffic matched for a particular class map, whether it be re-classify the packet with a different QoS marking, reserve a specific amount of bandwidth for this traffic, or something else entirely (policy maps are quite powerful. I highly recommend you lab with them to see all the cool things you can do with them). Do keep in mind, until the policy map is assigned to a service policy on an interface the router will not actually do anything. We have one more step.

Here we have a list of actions that can applied to the packets matched to the class map we can do everything from compress the header, set QoS values, drop the packets, police or shape the traffic, and much more.

Step 3: The Service-Policy

The service policy is where we apply our policy map to an interface in the input or output direction (Remember like ACLs, the inbound direction means packets coming into an interface and outbound refers to packets leaving the interface)

Now the service policy is actually pretty smart it will not allow you to assign the service policy to an interface in which some of the features are unsupported, it also will not allow you to oversubscribe the interface bandwidth

So, there is a typical QoS configuration using Cisco’s MQC setup, this QoS method is also the configuration for CBWFQ, so hey I technically showed you 2 things with one blog post! Now the biggest different between the configuration of CBWFQ and the Zone Based Firewall is the service policy is applied to an interface and not a zone pair.

Now one final look at all the configurations:

Notice there is a class-default in there, the class-default is the where every packet gets matched that does not match any other class map in the policy map, so you can easily effect all the traffic without matching every protocol or subnet, again something that can come in handy from time to time.

Written by Stephen J. Occhiogrosso

November 28, 2011 at 8:00 AM

BGP+MPLS passed onto QoS!

leave a comment »

Well I was finally able to sneak out of the office to go take the BGP+MPLS 642-691 exam earlier this week, something I have been trying to do for almost 2 weeks now. I really didn’t think finding the time to schedule the test was going to be the toughest part. The test took me an hour, and I passed so all my studying and work has paid off.

I was honestly a bit disappointed with the test, it seemed a bit more one-sided to me and the simulations were less than challenging in my opinion. I’ve done much more complicated labs in GNS3 and at work that matter. So as I was going the exam I felt more and more confident and really over-prepared. I do suppose it’s better than the alternative and failing the exam so I won’t dwell on this any further I passed and I am one step closer (well two technically) to getting my CCIP certification.

I’ll be jumping into QoS in hopes of taking this test by end of the year, and starting 2012 with my CCIP Certification!

Written by Stephen J. Occhiogrosso

November 20, 2011 at 12:35 PM

Posted in Certification

Tagged with , , , ,

Packet flow through a Cisco ASA.

with 16 comments

As I was reading my Cisco Firewalls book I found this picture (very early on to) concerning how a Cisco ASA handles traffic passing through the device and the logic behind it. it’s a chart worth paying attention to in my opinion. I mean we are going to be practical here, you are not going to run off and debug ip packet for every ASA issue you run into but knowing and understanding the flow chart below will surely give you an edge when troubleshooting ASA connectivity issues.

Now looking this at first glance might be slightly intimidating but in the end this is nothing more than a flow chart. Now, as you follow this flow chart much of the actions will seem like common sense:

  • If the ASA does not have a route to the destination the traffic gets dropped. (Of course)
  • If the traffic is denied by an ACL it gets dropped. (As we would expect)
  • If an Inspect rule is configured to drop the it get dropped. (Once again, as we would expect)

What I think makes this flow chart most valuable is the fact you see in which order these rules are applied looking at the flow chart we see the following order:

  1. ACL’s will be checked first.
  2. NAT rules will checked second.
  3. Inspect policies will applied next.
  4. Then after all that the packet enters IPS-AIM Module for inspection, after that it leaves through the egress interface.

Written by Stephen J. Occhiogrosso

November 15, 2011 at 7:25 AM