Computer Technology Support

QoS is a big topic on your BCMSN and CCNP exams, and for good reason. As more and more traffic flows through today’s networks, accurately applying QoS to both your routers and switches becomes more important.

Note the phrase “accurately applying”. You must have a plan in place before you start configuring QoS on your switches, and to create such a plan you should use Cisco’s Three-layer Hierarchical Model.

This model breaks switches down into three main groups - Access, Distribution, and Core. You’re familiar with these groups from your CCNA studies, and now you’ve got to apply this knowledge.

The QoS workload should be borne by the Access and Distribution layers, because the Core layer switches need to be left alone as much as possible to their primary purpose - switching!

Traffic should generally be classified and marked at the Access layer. This allows traffic to be assigned the desired QoS values and carry that value throughout the network.

If you choose to change CoS-DSCP mappings, this will generally be done at the Distribution layer. Since distribution layer switches will be receiving frames and packets with QoS values from the access layer switches, the appropriate “trust” and “no trust” statements should be configured on the appropriate distribution layer switches.

Any traffic received by core switches should already be classified and marked as needed. The key with core switches is to use a simple queuing setup to keep the switching process fast. Fast, fast, fast!

Real-world note - Low Latency Queuing (LLQ) is an excellent choice for core switches. The name says it all - low latency! The configuration of LLQ is not a BCMSN topic, but a quick search on the term low latency queuing will quickly bring up several Cisco LLQ configuration documents.

Knowing the three layers of Cisco’s networking model and the basic QoS operation and commands is vital to passing the CCNP exams, but even more importantly, you’ve got to apply this knowledge carefully and accurately to make QoS work for you in today’s production networks.

Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage, home of over 100 free certification exam tutorials, including

Multicasting is a vital topic on your BCMSN, CCNP, and CCIE exams, and it can also be very confusing when you first start studying it. Multicasting uses concepts that are unlike anything you’ve run into in your routing protocol studies, and that can throw you at first. I speak from experience that multicasting is like any other Cisco technology - learn the basics, master the fundamentals, and then build your skills on that foundation.

One such fundamental is the RPF Check, or Reverse Path Forwarding Check.

A fundamental difference between unicasting and multicasting is that a unicast is routed by sending it toward the destination, while a multicast is routed by sending it away from its source.

“toward the destination” and “away from its source” sound like the same thing, but they’re not. A unicast is going to follow a single path from source to destination. The only factor the routers care about is the destination IP address - the source IP address isn’t a factor.

With multicast routing, the destination is a multicast IP group address. It’s the multicast router’s job to decide which paths will lead back to the source (upstream) and which paths are downstream from the source. Reverse Path Forwarding refers to the router’s behavior of sending multicast packets away from the source rather than toward a specific destination.

The RPF Check is run against any incoming multicast packet. The multicast router examines the interface that the packet arrived on. If the packet comes in on an upstream interface - that is, an interface found on the reverse path that leads back to the source - the packet passes the check and will be forwarded. If the packet comes in on any other interface, the packet is dropped.

The RPF Check serves to verify the integrity of your multicasting network, and also serves as a reminder that the basic operation of multicasting is a lot different than unicasting!

Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage, home of over 100 free certification exam tutorials, including

CCNA exam success depends largely on noticing the details, and this is especially true of configurations involving directly connected serial interfaces. And of course, it’s not enough to notice these details - you’ve got to know what to do about them!

A Cisco router is a DTE by default, but directly connecting two DTEs with a DCE/DTE cable is not enough. In the following example, R1 and R3 are directly connected at their Serial1 interfaces. The line goes up briefly after being opened, but the line protocol goes down after about 30 seconds.

R3(config-if)#int s1

R3(config-if)#ip address 172.12.13.3 255.255.255.0

R3(config-if)#no shutdown

2d18h: %LINK-3-UPDOWN: Interface Serial1, changed state to up

2d18h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up

R3(config-if)#

2d18h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down

The problem is that one of the routers needs to act as the DCE in order for the line protocol to come up and stay up. If this were your CCNA / CCNP home lab, you could just go over and look at the DTE/DCE cable to see which router had the DCE end of the cable attached. In this example, though, we don’t have physical access to the routers. How can we tell which router has the DCE end of the cable attached?

R3#show controller serial 1

HD unit 1, idb = 0×1C44E8, driver structure at 0×1CBAC8

buffer size 1524 HD unit 1, V.35 DCE cable

The show controller command gives us this information. (There’s a lot more output that this with this command, but it’s unimportant for our purposes.) The router with the DCE end of the cable needs to supply a clock rate to the DTE, and we’ll do just that with the interface-level clockrate command.

R3#conf t

Enter configuration commands, one per line. End with CNTL/Z.

R3(config)#int serial1

R3(config-if)#clockrate 56000

2d18h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up

In just a few seconds, the line protocol goes up and stays up.

When troubleshooting a connection, always run show interface first. If you see the combination shown below, the connection is physically fine but logically down. That’s generally the result of a needed keepalive not being present. With Frame Relay, it’s probably an LMI issue, but with directly connected serial interfaces the issue is most likely the DCE end of the connection not supplying clockrate.

R3#show interface serial 1

Serial1 is up, line protocol is down

Troubleshooting is a big part of the job, and it’s a big part of the Cisco CCNA and CCNP programs as well. Know your show and debug commands and you’re on your way to passing the CCNA!

Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage, home of over 100 free certification exam tutorials, including