Quality of Service Within the WIN-T Inc 1a Network

By: CW3 Troy Ward Troy.J.Ward2.mil@mail.mil

1

Quality of Service (QOS) within any communications network is an important part of ensuring that it provides users a stable backbone and reliable services. In a Local Area Network (LAN) environment where we are able to connect everything using 1Gbps links QOS is rarely required, but with our tactical network we are often constrained with relatively low speed Wide Area Network (WAN) links that create bottlenecks within the network. It is at these bottlenecks that QOS provides us with the ability to prioritize traffic.

About This Paper This article has two main purposes; First to give you a brief introduction about QOS and how it is applied in the baseline WIN-T Inc 1 configs, and secondly to recommend modifications to the baseline configs to increase efficiency (in my personal opinion). It is important to realize that everything I write here is based on my own personal experiences and opinions both as a BCT Net Tech, Observer Coach/Trainer (OC/T) at the National Training Center, lots of reading and me just being a nerd.

It is important to remember that while a screwed up QOS policy won’t completely bring down your network, it can come pretty damn close in some extreme situations so changes to it should be done in a controlled fashion. Always make sure you have a backup copy of your current working configs before you roll out a change so you have something to fall back on if need be. Finally when you are developing your QOS strategy it is important to include your BCT S6, Server Tech, and FA 53 among other people in the discussion so that we can make sure we are placing the correct systems in the correct Access Control Lists (ACL).

Misconceptions about QOS There are a few important misconceptions that I think are important to address with QOS. First, while QOS is always (or at least should be) running in the background of our network, it only begins to actively prioritize traffic when the interface the QoS policy is applied to becomes congested. That means that if bandwidth is available, data will be placed on the link as soon as it arrives at the port. Once the interface becomes congested, QOS will kick in and begin to queue the traffic based on its priority.

Next, QOS is not the end-all be-all solution to bandwidth management. QOS is just one of many tools available to a Net Tech to ensure that their network operates smoothly. QOS will never replace a solid Digital Rules of Engagement which states what can and can’t go on the network. Certain simple steps such as limiting the size of email attachments, minimizing and compressing photos, using SharePoint/shared drives instead of email to distribute files and other similar ideas can greatly reduce the time that QOS will actually be active.

Finally (and perhaps most importantly) a Net Tech must realize that their normal WIN-T configs that they receive only provide the framework for QOS and don’t actually allow it to work. The standard WIN-T baseline configs provide the policies, but lack the completed ACL’s in order to

2

identify what traffic is what. These ACLs must be completed with input from the unit’s server tech, automations officer, S6, and Commander’s priorities.

Baseline QOS WIN-T Inc 1 implements QOS using three separate steps. The first step is the identification of “interesting” traffic based on a policy-map. Policy-maps can identify traffic based on a number of factors but under WIN-T ACLs are the primary source of identification. Identification occurs at three important places within the JNN/CPN. On the SIPR Tier 2 Router (ST2R) on interfaces g0/0.322 (management), g0/0.324 (data), and g0/0.358 (voice), on the NIPR Tier 2 Route r (NT2R) on the same interfaces as the ST2R, and one last time on the AES router on interface fa0/0 (the Linkway port) just prior to being sent to the Linkway modem.

Once traffic has been identified using a policy-map, it is often “marked” using a policy-map. Marking a packet changes the Differentiated Services Code Point (DSCP) byte within the IP header to identify it as a particular priority of traffic. By changing the DSCP byte, packet identification is much faster given the fact that the router already examines the IP header as a normal part of routing. Within the JNN/CPN, marking takes place at the same time as when the traffic is initially identified.

The final step in the QOS process is queuing. While identification and marking are always occurring on the router, queuing is only active when a link becomes congested. By congested, I mean that packets are arriving at an output interface faster than the shaping policy (if applied to the interface) or bandwidth on the wire for that interface is available. Once this happens, the link is “congested” and the router will begin to actively prioritize network traffic and utilize its buffers in an effort to prevent data from being dropped.

Queuing occurs at each WAN interface (serial ports on the NIPR tier 2 router and on the Ethernet interface connecting to the Linkway modem on the STT). When queuing occurs, the router allocates bandwidth to each class (voice, streaming, low-latency, high-throughput, etc.) of traffic based on defined percentages of total bandwidth for the link. The total bandwidth for a link is determined based on the line speed (i.e. a 2 Mbps serial connection) or by the shaping policy (i.e. 5 Mbps placed on the Ethernet interface to the Linkway modem) applied to the interface. Traffic within each class is further prioritized based on its precedence (flash, immediate, routine, etc.). The ultimate goal of queuing is for traffic to be transmitted in a timely manner with minimal impact to mission essential data.

Traffic Classes On both the ST2R and NT2R there are eight predefined classes of traffic: Network Control, Short Message, Video, Streaming, Low-Latency Data, High-Throughput Data, Management, and All Traffic.

3

Network Control: The NetworkControl class map is defined by access list NetworkControl. The NetworkControl class map is used to identify telnet and secure shell (SSH) traffic used for configuring and managing routers and other network devices. In the baseline configs, access list NetworkControl matches against any traffic with a source or destination port of 22 or 23 (telnet or SSH) regardless of its IP address.

Short Message: The ShortMessage class map is defined by access list ShortMessage. This class map is used to identify such things as chat room and instant messaging software such as Jabber and mIRC. The baseline configs are designed to identify traffic based on IP address (one for each server) however it is much more efficient to identify traffic based on port number (Jabber uses source/destination port TCP 5222 for all communications).

Video: The Video class is defined by five class maps and their respective access lists: Video-FO (Flash Overide), Video-F (Flash), Video-I (Immediate), Video-P (Priority), and Video-R (Routine). The video class is used primarily to identify VTC traffic. Systems are identified by IP address using standard Multilevel Precedence Preemption (MLPP).

Streaming: The Streaming class is defined by five class maps and their respective access lists: Streaming-FO, Streaming-F, Streaming-I, Streaming-P, and Streaming-R. The streaming class is used primarily to identify streaming video (UAV feeds, VBrick, etc.) and streaming audio (Ventrilo). While identifying UAV and VBrick feeds will depend on your exact setup, I recommend you configure Ventrilo as Streaming-F by identifying packets with a source or destination port of TCP/UDP 3784.

Low-Latency Data: The Low-Latency Data class is defined by six class maps and their respective access lists: LLData-FO, Critical-Servers, CPOFData, LLData-I, LLData-P, and LLData-R. The Low-Latency data class is for data (non-voice) which should ideally have minimal delay because the user will be interacting with it in real-time. This includes such things as CPOF, DNS, and web traffic among many others. One important thing to note is that on the ST2R the class map CPOFData is used instead of LLData-I and on both the ST2R and NT2R the class map Critical-Servers is the same as what would normally be considered LLData-F. See the attached example config for specific recommendations on how to classify various systems.

High-Throughput Data: The High-Throughput Data class is defined by five class maps and their respective access lists: HHData-FO, HHData-F, HHData-I, HHData-P, and HHData-R. The High-Throughput Data class is for data (non-voice) which moves relatively large amounts of data that can suffer from some minor delay without affecting the user. This includes such things as exchange, share drives, and other similar services. See the attached example config for specific recommendations on how to classify various systems.

Management: Aside from the Network Control class, the Management class is the only class which is already predefined and doesn’t need to be modified to work. The Management class is

4

defined in the Management access list. It is designed to mark the following types of traffic: FTP, TACACS, SNMP, TFTP, syslog, and SNMP traps.

Identification On the ST2R identification takes place using three separate service-polices:

Data‐Remark 

Voice‐Remark 

Management‐Remark.  

The Data-Remark service-policy is applied to all incoming traffic from VLAN 324 (server and user traffic) and is used to identify the various classes of data traffic produced on those VLANs. The Voice-Remark service-policy is applied to all incoming traffic from VLAN 358 (voice) and is used to identify streaming and VTC traffic (voice signaling and voice traffic are all premarked with the appropriate DSCP by the call manager when the packets are generated). The Management-Remark service-policy is applied to the incoming traffic from VLAN 322 (management traffic) and VLAN 333 (information assurance) and is used to identify the management traffic that is produced on those VLANs.

On the NT2R identification takes place in two distinct areas. It first takes place on each of the VLANs noted above to identify the various types of NIPR traffic produced. As on SIPR, all of this traffic is identified through the use of user-defined ACLs. The second area where identification takes place on the NT2R is on the outbound serial interfaces (HCLOS and FDMA) through the use of the NIPRSerial service-policy. The NIPRSerial service policy is used to queue traffic (discussed below) but it must first identify the various types of traffic. In this particular case the traffic is identified not by an ACL but the value set in its DSCP byte in the IP header. This allows for faster identification.

On the AES router identification takes place just prior to data being sent to the Linkway through service-policy Aggregate. This service-policy is applied to the outbound direction of the Ethernet interface that connects to the Linkway modem. It is important to realize that in addition to identifying traffic, this policy-map also artificially shapes the speed of the interface from its normal line speed (normally 100 Mbps) to a significantly lower speed (generally 4 or 5 Mbps). This is done to prevent the Linkway from being flooded with traffic that it won’t be able to transmit and to ensure that QOS kicks in when needed.

Marking When marking occurs, the DSCP byte (see Figure 1) in the packets IP header is modified to a predefined value. As noted above, packets are marked with different values (Differentiated Services Code Points) so that the queuing mechanisms can provide appropriate precedence and priority to traffic. For the most part in WIN-T, packets must first be identified and marked with

5

the appropriate DSCP based on ACLs. By modifying the IP header, the packet’s class and priority is automatically determined when the header is examined as a part of routing.

Figure 1 DSCP Byte

User generated packets are marked as they first enter the NT2R and ST2Rs from VLANs 322, 324, 333, and 358. As packets enter the router, they are first identified through the use of ACLs and then the DSCP byte is modified to its appropriate value to aid in identification later down the road.

Queuing Queuing occurs on each of the WAN interfaces (serial ports and TDMA) on the JNN and CPN. Queuing is the act of temporarily delaying some traffic so that higher priority traffic can be transmitted first. While this delay may ultimately result in some data being dropped, the idea is that this will minimally affect mission essential traffic. It is important to remember that unlike the identification and marking steps which are continually in operation, queuing only occurs when the link becomes congested.

When queuing occurs within the JNN or CPN, two things are actually occurring simultaneously. First, bandwidth is being allocated statically by class type based on a percentage of the bandwidth available on that particular link. Second, within the bandwidth that is reserved for a particular class of data, packets are delayed or even dropped based on their priority within that particular class.

Packet Drop Dropping some packets is a natural part of QOS. When queuing beings, the router will purposely begin to drop a small number of packets as they arrive at the interface queue. Using a process called Weighted Random Early Detection (WRED) the router will randomly select to drop a small number of packets based on its class. This is done in an effort to use TCP’s built in congestion avoidance process to have the sending host slow down. WRED will continue to occur while the interface is congested in an effort to keep its buffers from filling completely.

6

Eventually if the flow of traffic does not decrease, the buffers for one or more traffic queue for an interface will fill completely to the point that it is not able to accept any more traffic. When this occurs a situation known as tail drop occurs where all packets for that class of traffic are dropped regardless of precedence. This will occur until some packets in that buffer are transmitted and there is room to accept more. Tail drop is the uncontrolled dropping of packets and a sign that the link is nearly or completely saturated.

Implementing the Baseline When a unit receives the baseline configurations, 90% of the required work has already been completed for the Net Tech. When delivered, all required traffic classes have been defined, policy-maps required to mark that traffic have been defined, and the service-policies needed to queue that traffic are in place. The only thing that is missing to get basic QOS working is for the Net Tech to identify what traffic belongs in each class of traffic.

Under WIN-T, this initial traffic identification takes place through the use of extended ACLs. While the use of ACLs allow traffic to be identified by both IP address and port number I recommend the use of ports to allow specific traffic to be identified with the minimal set of rules required. See Table 1 for a list of recommended traffic classification.

Sh

ort

M

essa

ge

JABBER Ventrillo Chat Transverse

Vid

eo

Flash Override Flash Immediate Priority Routine BVTC

Str

eam

ing

Flash Override Flash Ventrillo Immediate Soft CAU Priority

Routine UAV

Lo

w L

aten

cy

Dat

a

Flash Override DNS Flash (Critical Servers) Domain Controller Immediate CPOF Adobe Connect CRAM Priority TIGR TAIS AFATDS AMDWS

Routine Portal Page Web BCS3

Hig

h

Th

rou

gh

pu

t D

ata

Flash Override Flash PASS/DDS Immediate Priority Exchange File Server

Routine DCGS-A CIDNE Table 1 Recommended QOS Prioritization

7

Detailed examples of the above classifications can be found in the attached configuration.

Once interesting traffic has been identified, there are a few other steps that must be taken to ensure that the baseline QOS operates correctly. First on the NT2R it is important to ensure that all serial interfaces that are used (FDMA and HCLOS) have the appropriate bandwidth statement set based on the actual link speed. Also on the NT2R, it is important to ensure that the ACL “C2-Traffic” contains the CT interface IP address of your TACLANE.

Like the NT2R, it is important to ensure that the “C2-Traffic” ACL on the AES router contains the TACLANE’s CT IP address in order to differentiate between SIPR and NIPR traffic.

TACLANE Configuration The TACLANE is responsible for the encryption of all SIPR information before it travels across the NIPR backbone. Under the default configuration the DSCP value of each packet is encrypted along with the payload of the packet itself. The TACLANE firefly key configuration has an option which allows for the DSCP byte of each packet to be left unencrypted (See the WIN-T TACLANE configuration guide for details). This is vital to ensuring that the QOS for SIPR traffic operates as intended. Failure to configure this option correctly will result in all SIPR traffic being handled as “best effort”.

Figure 2 TACLANE Accepted DSCP Values

8

Troubleshooting QOS QOS can be difficult to confirm and troubleshoot. It is often only when something is wrong that we realize that it is not working correctly. While the only true way to ensure that the correct packet is getting the correct marking is to use Wire Shark or other similar packet capture program, the router does provide us with several commands that will help us out.

Show IP access-list Access lists (ACL) are used extensively in the JNN/CPN configs for both security as well as implementing QOS. They can also be used to verify the correct tagging of traffic as it passes through various stages of the network. Aside from using IP address and port numbers to identify traffic, an extended ACL can also look at a packets DSCP marking for identification. In Figure 3 we see ACL “Test_DSCP” has been applied to the tunnel interface. Further review of the ACL itself (Figure 4) shows that it is used to identify traffic with a DSCP value of 21 and that it has matched traffic against it.

Figure 3 Test ACL Applied to Tunnel Interface

Figure 4 Results from "Show ip access-lists TEST_DSCP"

The ACL can be configured to look for one or more classes of traffic and will increment its counter each time it finds a corresponding packet. It is important to realize that this can’t guarantee the correct packet is actually getting the marking, but can at least show that traffic with that marking has been generated and is passing through a particular interface. It is important to use this only for testing purposes and not leave it on all the time. Depending on the exact location of where you apply this ACL, it may inspect a large number of packets and can ultimately adversely affect the performance of your router.

Show Policy-map Interface The command show policy-map interface is a critical command to know in order to determine the current status of an interface from a QOS perspective. Figure 5 shows the output when the show policy-map interface command is given on an uncongested interface. As you can see the “Targeted Rate” for the traffic shaping is 6144000 (this is standard on a JNN TDMA interface). Below that you see that it has received 94026 packets for a total of 101,961,726 bytes. Most importantly we see that we have not delayed any packets. Finally you can see that shaping is not

9

currently active (by default this information is for the last five minutes but that interval can be changed with the load-interval command).

Figure 5 Show Policy-map Interface on Uncongested Interface

As you can see in Figure 6 the amount of bandwidth has increased significantly. Shaping is now active and packets are being delayed. The interface is now congested.

Figure 6 Show Policy-map Interface on a Congested Interface

Figure 7 is a continuation of the output started in Figure 6. As you scroll through the output you see the detailed statics for each class of traffic that makes up the Policy-map “Aggregate”. As you can see the class “C2Data” received a total of 67,113 packets. This number is made up from the total of each class of traffic within the class “C2Data” (33,422 packets from LowLatencyData and 33,691 packets from HighThroughputData).

10

Figure 7 Show Policy-map Interface on a Congested Interface Cont.

Figure 8 is another continuation of the output from Figure 6. Here we see detailed information about what traffic is and is not being dropped for each class of traffic. This is the information for the traffic within C2Data. On the row labeled af11 (this equates to DSCP 10 or “HTData-R”) has transmitted 1,447,893 packets. We also see that it has 37,446 packets that were dropped due to “Random Drop”. As the queue begins to fill up and the interface becomes congested, the router will randomly drop packets periodically based on their marking in an attempt to get the transmitting device to slow down its transmit rate (more information can be found by Googling “TCP Window Rate”). Finally we see that 5,190,942 packets have been dropped due to “Tail Drop”. Each class of traffic gets its own individual buffer. As each buffer fills up, it eventually runs out of room. When this occurs, any packets that reach the buffer while it is full is automatically dropped (tail drop) indiscriminately.

In Figure 8 we also see more information under class default. This is made up of a variety of classes that don’t fit within the predefined AF or CS classes but rest assured those packets have been properly marked and handled.

11

Example Configuration This is an example access list configuration based on my recommended traffic configuration. This should be modified to meet your network’s needs.

! ! ip access-list extended ShortMessage-FO remark This access list allows certain hosts to have FO ShortMessage precedence remark permit Jabber by port permit tcp any any eq 5222 permit tcp any eq 5222 any ! ip access-list extended Video-FO remark This access list allows certain hosts to have FO VTC precedence ! ip access-list extended Video-F remark This access list allows certain hosts to have F VTC precedence ! ip access-list extended Video-I remark This access list allows hosts to have I VTC precedence ! ip access-list extended Video-P remark This access list allows certain hosts to have P VTC precedence

Figure 8 Show Policy-Map Interface on a Congested Interface Cont.

12

! ip access-list extended Video-R remark This access list allows certain hosts to have R VTC precedence ! ip access-list extended Streaming-FO remark This access list allows certain hosts to have FO Streaming precedence ! ip access-list extended Streaming-F remark This access list allows certain hosts to have F Streaming precedence remark Ventrillo permit tcp any any eq 3784 permit tcp any eq 3784 any permit udp any any eq 3784 permit udp any eq 3784 any ! ip access-list extended Streaming-I remark This access list allows hosts to have I Streaming precedence ! ip access-list extended Streaming-P remark This access list allows certain hosts to have P Streaming precedence ! ip access-list extended Streaming-R remark This access list allows certain hosts to have R Streaming precedence ! ip access-list extended LLData-FO remark This access list allows certain hosts to have FO Low Latency Data precedence ! ip access-list extended Critical-Servers remark This access list allows certain hosts to have F Low Latency Data precedence remark DNS replys permit udp any any eq 53 permit udp any eq 53 any permit tcp any any eq 53 permit tcp any eq 53 any remark Domain Controllers (Repeat for additional domain controllers) !permit ip any host <Domain Controller> !permit ip host <Domain Controller> any ! ip access-list extended CPOFData remark This access list allows CPOF hosts to have I Low Latency Data precedence remark CPOF Mid Tiers (Repeat for additional mid tiers/repositories permit ip any host <Mid Tier> permit ip host <Mid Tier> any remark Adobe Connect permit tcp any any eq 5060 !

13

ip access-list extended LLData-P remark This access list allows certain hosts to have P Low Latency Data precedence remark Web traffic permit tcp any any eq 80 permit tcp any eq 80 any permit tcp any any eq 443 permit tcp any eq 443 any remark TIGR (Repeat for additinal TIGR servers) permit ip any host <TIGR Server> permit ip host <TIGR Server> any ! ip access-list extended LLData-R remark This access list allows certain hosts to have P Low Latency Data precedence ! ip access-list extended HTData-FO remark This access list allows certain hosts to have FO High Throughput Data precedence ! ip access-list extended HTData-F remark This access list allows certain hosts to have F High Throughput Data precedence ! ip access-list extended HTData-I remark This access list allows hosts to have I High Throughput Data precedence remark Exchange permit tcp any any eq 135 permit tcp any eq 135 any remark File Share (Repeat for additional file shares) permit ip any host <File Share> permit ip host <File Share> any ! ip access-list extended HTData-P remark This access list allows certain hosts to have P High Throughput Data precedence ! ip access-list extended HTData-R remark This access list allows certain hosts to have R High Throughput Data precedence ! ip access-list extended Management permit udp any any eq snmp snmptrap syslog tftp permit udp any eq snmp snmptrap syslog tftp any permit tcp any any eq ftp tacacs 443 permit tcp any eq ftp tacacs 443 any

QOS Packet Example This section examines just one scenario starting from a packet being generated all the way until it is transmitted out the TDMA interface for the JNN. In this scenario, it is assumed that the packet is originating from a CPOF machine destined for it’s midtier server and is configured as above.

14

It is significantly helpful to use the attached QOS diagram to follow step by step as it moves through the system. Also below you will see a number of screen shots from packet captures taken with Wireshark.

1. A data packet is generated from a host. In this example the host is a CPOF computer (IP Address 148.37.10.2) sending a packet to the BCT mid-tier (IP Address 148.37.209.162). When the packet is generated, it has a default DSCP value of 000000. Under normal routing, the packet enters the JNN on VLAN 59 on the ST2S. From there it moves to the ST2R using VLAN 224/324 (See Figure 9) 

Figure 9 Original Unmodified Packet

2. When the packet inters the router on interface G0/0.324 it encounters the command service-policy input Data-Remark.

3. The router goes through policy-map “Data-Remark” line by line attempting to find a condition that matches. It begins at the top of the policy-map and works its way down. In this example, it first tries to match the packet as “ShortMessage-FO-Mark” and works down until it reaches “LLData-I-Remark”.

4. When the router reaches “class LLData-I-Remark” in policy-map “Data-Remark”, examines class map “LLData-I-Mark”. Within LLData-I-Mark it references “match access-group name CPOFData”.

5. When we examine access list “CPOFData”, we see that the ACL matches against any packet with a source or destination address of 148.37.209.162 (the BCT CPOF mid-tier). In our example, the packet has a destination IP address of 148.37.209.162 and matches on the ACL resulting in the packet being identified as class LLData-I-Mark (See Figure 10).

Figure 10 Data Packet Matches to Access list CPOFData

6. As a result of the packet being identified as class “LLData-I-Mark”, the router changes the DSCP byte in the packet’s header to 010101 (DSCP 21) (See Figure 11).

15

Figure 11 DSCP Byte Changed to DSCP 21

7. The packet continues into the ST2R and under normal WIN-T configurations goes into the SIPR Tunnel. Here the packet is encapsulated with a GRE header. The original header including source and destination IP addresses is encapsulated with the tunnel header. The packets source address becomes the routers G0/0.175 IP Address (TACLANE PT GW) and the destination becomes the remote routers G0/0.175 IP Address. The DSCP byte of the original packet header is brought out to the new header so the value does not change (see Figure 12).

 

Figure 12 Packet Following Encapsulation in SIPR Tunnel

8. The packet goes out the ST2R G0/0.175 interface and into the PT interface of the TACLANE. If the TACLANE is configured correctly (see baseline TACLANE configuration guide), the DSCP value of the packet is not encrypted. When the packet comes out the CT side of the TACLANE, it once again gets a new header (source IP address becomes the TACLANE CT and the destination becomes the remote TACLANE CT) but once again the DSCP byte has not changed (see Figure 13).

16

Figure 13 Packet Following Encryption from the TACLANE

9. Under normal WIN-T routing, the packet enters the NT2R on G0/0.175 where the router must decide how the packet will be routed out to the world: FDMA or TDMA. For the example we will assume that it is going to go TDMA. If the packet were to go FDMA, the service-policy on the serial interfaces is similar (but with some differences) to the policy that is applied on the AES router described below.

10. The packet moves to the AES router on the STT through interface FA0/1/0 and ultimately reaches VLAN3. On both of these steps, no QOS is applied and the packet remains unchanged.

11. Once in the AES router, OSPF pushes the packet out the tunnel interface. The packet changes its source and destination addresses to that of the routers Linkway IP addresses. Even though the router will automatically mark the encrypted GRE packet produced by the tunnel with the same DSCP value as it had, it only does this after the packet is in the outbound que for interface fa0/0 (the source interface for the tunnel). What this means is that when the router is processing the packet to actually put it on the physical interface, there is no DSCP value and thus no QOS occurring before it is sent out. To solve this on the tunnel interface we find the command “qos pre-classify”. This command tells the router to temporarily save a copy of the original packet and to inspect that DSCP value and use it for the encrypted packet when it is moved to fa0/0

17

12. Once the encrypted packet is actually on fa0/0 and reading to the Linkway it encounters the command “service-policy output Linkway”.

13. “Policy-map Linkway” does two important things. First it shapes the traffic going out the interface from 100 mbps to 6144 kbps (JNN) or 4096 kbps (CPN). This is to prevent the outbound traffic from flooding the Linkway and allows for queuing and prioritization to occur. The second important step that occurs here is that the policy-map also references a second policy-map “Aggregate”.

14. Policy-map “Aggregate” is responsible for the actual prioritization of traffic that occurs within the router. Like policy-map “Data-Remark” in step 4, Aggregate looks at each packet and tries to classify it as a particular class of traffic based on the classes referenced in the policy-map. Once again it tests against each class map referenced starting at the beginning of “Aggregate” (C2VOIP) and moves down the list until it gets to class “C2Data”.

15. When we examine class map “C2Data” we first see the command “class map match-all C2Data”. The “match-all” part of this command indicates that all conditions within that class map must be met in order for it to be considered part of the class. In this case those conditions are that the packet is 1. part of class “data” and 2. that it matches access list “C2-Traffic”.

16. When we examine class map “data” we see that it includes the command “match-any” indicating that if any condition within the class is true that the packet is part of the class. The two conditions referenced are 1. that the packet is part of class “LowLatencyData” or 2. that the packet is part of class “HighThroughputData”.

17. When we examine class map “LowLatencyData” we see once again “match-any”. There are a number of conditions that the router can possibly match but the all require an examination of the DSCP value of the packet. The command “qos-preclassify” in step 11 ensures that we are looking at the DSCP value of the original packet and not the encrypted packet which currently has no value. If you recall, the original packet prior to entering the AES tunnel had a DSCP value of 21 which does match against one of the conditions in class map “LowLatencyData”. At this point, the first of two conditions required for the packet to be considered “C2Data” is true.

18. The second condition that must be tested as true in order for the packet to be considered “C2Data” is that it must match against access list “C2-Traffic”. When we examine that ACL we see that it will match against any packet with the TACLANE CT IP address. If you remember, after the now encrypted packet left the TACLANE, it now had a source IP address of the TACLANE CT. Because of this, the second condition has been met and the packet is now considered to be a member of the class “C2Data”.

19. Now that the packet is “C2Data”, it will be prioritized in accordance with that class. The command “bandwidth percent 24” ensure that when the interface is congested, that “C2Data” will get at least 24% of the bandwidth on the interface (this % is based on the shaped traffic rate referenced in step 13). The second command “random-detect dscp-

18

based” indicates that if that 24% is used up and there is still additional traffic that needs to go out, it is qued (and eventually dropped if required) based first on its class (first three bits of the DSCP value) and then on its drop-probability (last three bits of the DSCP value).

Works Cited Andy. (2008, Nov 29). QoS Pre-classify in GRE over IPsec VPNs. Retrieved from Cisconinja’s Blog: http://cisconinja.wordpress.com/2008/11/29/qos-pre-classify-in-gre-over-ipsec-vpns/

Baily, M. (2012, Feb 28). QOS at JRTC.

Understanding Packet Counters in show policy-map interface Output. (2008, Feb 15). Retrieved from Cisco: http://www.cisco.com/en/US/tech/tk543/tk760/technologies_tech_note09186a0080108e2d.shtml

Westbrook, C. (2012, April 22). QOS Checklist.