3.2

Q&A with lab 3.2

Based on your knowledge of SDM, why do you think that the router needs to have these non-SDM specific commands entered in?

Since SDM offers smart wizards and advanced configuration support for LAN and WAN interfaces, Network Address Translation (NAT), stateful and application firewall policy, IPS, IPSec VPN, QoS, and NAC policy features, it is important to first create an environment for SDM to being to operate

What are the advantages and disadvantages of installing SDM on both the router and PC?
With SDM on both router and PCs, you can access the graphical user interface and maintain configs from any method

SDM Dashboard:

2.1

This picture is the final result of the lab.

5.1

Notable questions and answers:

How many traffic classes has AutoQoS derived from the observed patterns?
transactional
bulk
routing
best effort

Is this how you would also classify traffic generated by the Pagent router if you were to implement the suggested QoS policy on the command line? Explain.
Yes, according to the suggested QoS policy

What does the DSCP marking AF11 indicate?
AF11 indicates traffic such telnet, ssh, and xwindows traffic: protocols for remote administration

What does the differentiated services code point (DSCP) marking AF21 indicate?
This DSCP marking is used for media and marks values for voice and/or video traffic in network queuing

Are these markings locally significant to the router or globally significant over the entire routed path?
The settings are globally significant

How much bandwidth do you expect to be allocated to the transactional and bulk traffic classes respectively?
transactional – 10597kbs
bulk – 10636 kbs

Which queuing tool does the policy generated on router R1 represent?
fair-queue

Why is the auto discovery step separate from the actual implementation of AutoQoS?
The discovery phase allows the application to observe traffic on and interface. By observing traffic over a significant period of time, one insures all types of traffic has been accounted for. Then by issuing AutoQos, policies will be generated.

3.1

This lab was really straight forward with no hesitations. Throughout the lab we created the following two files according to the lab notes and netlab respectively:

basic-tgn.cfg
advanced-tgn.cfg

According to netlab documentation, netlab takes care of all switch commands.

In order to create traffic statistics we followed appendix C for netlab configuration and were able to generate all statistics

4.1

A couple points of interest:

The lab notes insructed us to load the basic-tgn.cfg file (and we were cool with that). We did notice however that they gave us the wrong command(we were not cool with this part). The correct command that we used and found to right is:
TrafGen# tgn load-config flash:basic-tgn.cfg

Remember to stop the traffic generator when doing step 2 of the lab notes. It was asked to be started previously, but never mentioned to be stopped. Traffic generator must be stopped to continue with the remainder of the commands.

4.2

Note: this lab was a collaborative effort and is referenced similarly at Jeff’s blog

The “precedence internet” portion of the R1(config)# access-list 101 permit ip any any precedence internet> command sets the priority to for the access list to Match packets with internetwork control precedence

The debug custom-queue> command on router 1 promted the “q” to change “4” to “1”, and “1” to “2”when router 2 initiated a telent sessions.
Note the appropriate output for the steps in pages 12 – 14

Compare your output to this. If it doesnt match, you;ve probably configured something incorrect.

4.4

Note: This lab was a collaborative effort with Jeff Baier

It is important to not load the TGN traffic generator configuration as previously done in labs 4.1 and 4.2

Output for NQR configuration:
fastethernet0/0
add tcp
send 1000
rate 60
length random 200 to 1000
l2-dest 0014.a969.1070
l3-src 172.16.10.4
l3-dest 172.16.20.4
l4-dest 23
fastethernet0/1 capture
add clone-of 1
l4-dest 21
add clone-of 1
l4-dest 119
add clone-of 1
l4-dest 22
add clone-of 1

When we first tried the lab, we had 9 traffic streams, compared to 5 in the lab manual. The rest of the lab would then not work. After checking we realized we had pasted in the NQR configuration incorrectly. We scrubbed the pod and started over, this time with the correct NQR config and now it is working right, and there are only 5 traffic streams.

After running the start send command, time will pass, and then the router will inform you when all packets have been sent. The “Time will pass” meant only about 15 seconds for us.

FIFO is on by default when no other queueing types are enabled.

TrafGen(NQR:OFF,Fa0/0:5/5)#sh pkt-seq-drop-stats

Summary of packet sequence/drop stats of traffic streams
ts# template interface sent recvd dropped out-of-seq max-seq
1 TCP Fa0/0 1000 85 915 37 27
2 TCP Fa0/0 1000 144 856 33 50
3 TCP Fa0/0 1000 142 858 29 47
4 TCP Fa0/0 1000 149 851 26 59
5 TCP Fa0/0 1000 64 936 29 27

TrafGen(NQR:OFF,Fa0/0:5/5)#sh delay

Summary of delay-stats of traffic streams
ts# template interface min-delay max-delay avg-delay stdev-delay
1 TCP Fa0/0 0.057936 0.803841 0.390446 0.125760
2 TCP Fa0/0 0.008399 0.420713 0.323438 0.089587
3 TCP Fa0/0 0.019842 0.449999 0.329806 0.107765
4 TCP Fa0/0 0.030354 0.437458 0.310051 0.103980
5 TCP Fa0/0 0.037837 0.772656 0.406740 0.144821

TrafGen(NQR:OFF,Fa0/0:5/5)#sh jitter

Summary of jitter-stats of traffic streams
ts# template interface min-jitter max-jitter avg-jitter stdev-jitter
1 TCP Fa0/0 0.000169 0.399956 0.080740 0.101643
2 TCP Fa0/0 0.007366 0.182717 0.083387 0.035971
3 TCP Fa0/0 0.010463 0.242322 0.094656 0.054160
4 TCP Fa0/0 0.000168 0.181835 0.098233 0.036947
5 TCP Fa0/0 0.001478 0.352950 0.107737 0.103940

After WFQ On both serial interfaces:

TrafGen(NQR:OFF,Fa0/0:5/5)#sh pkt-seq-drop-stats

Summary of packet sequence/drop stats of traffic streams
ts# template interface sent recvd dropped out-of-seq max-seq
1 TCP Fa0/0 1000 62 938 28 29
2 TCP Fa0/0 1000 157 843 36 50
3 TCP Fa0/0 1000 165 835 33 82
4 TCP Fa0/0 1000 165 835 30 52
5 TCP Fa0/0 1000 102 898 50 30

TrafGen(NQR:OFF,Fa0/0:5/5)#sh delay

Summary of delay-stats of traffic streams
ts# template interface min-delay max-delay avg-delay stdev-delay
1 TCP Fa0/0 0.012909 0.802448 0.411571 0.167596
2 TCP Fa0/0 0.025648 0.452551 0.330156 0.115428
3 TCP Fa0/0 0.022489 0.449449 0.302500 0.113113
4 TCP Fa0/0 0.017471 0.451252 0.337060 0.101554
5 TCP Fa0/0 0.008788 0.803437 0.425355 0.134657

TrafGen(NQR:OFF,Fa0/0:5/5)#sh jitter

Summary of jitter-stats of traffic streams
ts# template interface min-jitter max-jitter avg-jitter stdev-jitter
1 TCP Fa0/0 0.000712 0.393095 0.118065 0.126037
2 TCP Fa0/0 0.000562 0.247177 0.100784 0.058709
3 TCP Fa0/0 0.008739 0.187170 0.103791 0.046940
4 TCP Fa0/0 0.000087 0.221418 0.089329 0.050680
5 TCP Fa0/0 0.000159 0.385631 0.083481 0.110551

To setup Custom Queueing

Cisco instructions to setup custom queueing or look at appendix in lab for an example of how to setup custom queueing.

TrafGen(NQR:WAIT,Fa0/0:5/5)#sh pkt-seq-drop-stats

WARNING: Traffic generation Currently on.
The packets in transit are counted as dropped

Summary of packet sequence/drop stats of traffic streams
ts# template interface sent recvd dropped out-of-seq max-seq
1 TCP Fa0/0 1000 354 646 262 17
2 TCP Fa0/0 1000 723 277 202 64
3 TCP Fa0/0 1000 729 271 187 65
4 TCP Fa0/0 1000 725 275 188 80
5 TCP Fa0/0 1000 364 636 261 16

TrafGen(NQR:WAIT,Fa0/0:5/5)#
TrafGen(NQR:OFF,Fa0/0:5/5)#sh delay-stats

Summary of delay-stats of traffic streams
ts# template interface min-delay max-delay avg-delay stdev-delay
1 TCP Fa0/0 0.003821 0.563391 0.474184 0.078021
2 TCP Fa0/0 0.008626 0.562538 0.451431 0.076181
3 TCP Fa0/0 0.009091 0.601371 0.442814 0.088573
4 TCP Fa0/0 0.004680 0.616352 0.442122 0.099195
5 TCP Fa0/0 0.009104 0.598018 0.476281 0.077497

TrafGen(NQR:OFF,Fa0/0:5/5)#sh jitter-stats

Summary of jitter-stats of traffic streams
ts# template interface min-jitter max-jitter avg-jitter stdev-jitter
1 TCP Fa0/0 0.000782 0.252218 0.060681 0.051143
2 TCP Fa0/0 0.000033 0.284539 0.058684 0.049382
3 TCP Fa0/0 0.000116 0.331612 0.060187 0.065775
4 TCP Fa0/0 0.000124 0.301200 0.081352 0.057493
5 TCP Fa0/0 0.000660 0.261888 0.060208 0.050835

Try making one of the queues have a size of 10000. How does this affect all of
the traffic flows?
It allows steams 1 and 5 to almost not drop any, while the other streams got worse and dropped a lot more.

After applying priority queueing

TrafGen(NQR:OFF,Fa0/0:5/5)#sh pkt-seq-drop-stats

Summary of packet sequence/drop stats of traffic streams
ts# template interface sent recvd dropped out-of-seq max-seq
1 TCP Fa0/0 1000 1000 0 0 1000
2 TCP Fa0/0 1000 850 150 109 164
3 TCP Fa0/0 1000 81 919 0 81
4 TCP Fa0/0 1000 61 939 0 61
5 TCP Fa0/0 1000 1000 0 0 1000

TrafGen(NQR:OFF,Fa0/0:5/5)#sh delay-stats

Summary of delay-stats of traffic streams
ts# template interface min-delay max-delay avg-delay stdev-delay
1 TCP Fa0/0 0.007056 0.030114 0.017861 0.004088
2 TCP Fa0/0 0.009582 1.004727 0.714964 0.200605
3 TCP Fa0/0 0.014017 0.014017 0.014017 N/A
4 TCP Fa0/0 0.009314 0.009314 0.009314 N/A
5 TCP Fa0/0 0.007834 0.032614 0.019193 0.004371

TrafGen(NQR:OFF,Fa0/0:5/5)#sh jitter-stats

Summary of jitter-stats of traffic streams
ts# template interface min-jitter max-jitter avg-jitter stdev-jitter
1 TCP Fa0/0 0.000012 0.012252 0.003326 0.002402
2 TCP Fa0/0 0.000062 0.432661 0.173587 0.101557
3 TCP Fa0/0 N/A N/A N/A N/A
4 TCP Fa0/0 N/A N/A N/A N/A
5 TCP Fa0/0 0.000019 0.013464 0.003540 0.002599

How does the packet loss with PQ compare to that of previous queuing
strategies?
The normal and low priorities had lots of packets dropped, while the higher priority streams almost got all their traffic through.

What would happen if you put all the streams in the high priority queue?
It would have the same results as FIFO queueing, because they would all be competing again.

Note of interest:

*Mar 13 20:49:49.187: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.10.1 (FastEthernet0/0) is down: holding time expired
*Mar 13 20:49:52.071: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.10.1 (FastEthernet0/0) is up: new adjacency

Since we are filling the queues with generated traffic, routing updates from EIGRP are not getting through. We keep seeing the above 2 messages because the hold down timers expire, and then later the routing updates get through and EIGRP sees the interface as a new adjacency.

ip route 172.16.20.0 255.255.255.0 Serial0/0/0

4.6

We could not initially get on Router 4 due to not having the correct login password. It is important our students to remain consist when using passwords on shared equipment. We had to scrub the device and start over after trying multiple password attempts.

When issuing the match protocol OSPF command it will momentarily hang due to existing OSPF traffic already on the network

Why would a network administrator decide to use IP Precedence over DSCP, or vice-versa?
An administrator would use IP Precendence if they have a situation that calls for a fine-grained, flow-based mechanism, differentiated service. They would then in turn use DSCP if they have a situation that calls for a coarse-grained, class-based mechanism for traffic management.

What happens to the DSCP markings on IP packets traversing the serial link from R4 to R3 if no other traffic classes are referenced within the policy map?
Since they are not referenced the DSCP is set to default, and they will follow the default values.

How could you create compressible TCP packets given the current topology?
We could tcp port 23 to telnet from router to touter. After trying to telnet, R4 is CHUNKing – literally (we taxed the router’s RAM out).

4.5

After EIGRP is configured, the lab notes ask us to use the command:nterface fastethernet 0/1 however, netlab is setup with a different topology and the appropriate show command would be show interface fastethernet 0/1

According to best QoS practices, where should packets be marked?
On data link layer they will marked at: CoS (Inter-Switch Link [ISL], 802.1p), Multiprotocol Label Switching (MPLS) experimental (EXP) bits, Frame Relay. On the network layer they will be marked at: DSCP, and IP precedence.

What is a trust boundary in terms of classification and marking?
A trust boundary needs to be closest the edge of the network as possible. With respect to marking is the point in the network at which markings like CoS or DSCP begin to be accepted.

When creating these traffic classes, should you use the match-any or the match-all keyword?
The match-any command should be used.

Notice the following output from the show class-map command

and the output from the show policy-map command:

If a BGP packet with an IP precedence marking of 3 enters the Fast Ethernet 0/0 interface on R1 and is destined for R2, into which traffic class will the packet be classified?
It will be put in the class-default clas-map

What IP precedence will the packet be assigned at the egress port?
It will get a precedence of 0

What traffic types would usually belong in a priority queue in a production environment?
The types of traffic needed to be in a priority queue would be telephony traffic and any other mission critical, time sensitive, guaranteed delivery traffic.

4.3

Step 1: Configure Addressing

Configure all of the physical interfaces shown in the diagram. Set the clock rate on the serial link to 64000 and use the no shutdown command to enable all of the interface addresses in the topology diagram.

R1(config)# interface serial0/0/0

R1(config-if)# ip address 172.16.12.1 255.255.255.0

R1(config-if)# clock rate 64000

R1(config-if)# no shutdown

R2(config)# interface serial0/0/0

R2(config-if)# ip address 172.16.12.2 255.255.255.0

R2(config-if)# no shutdown

Step 2: Enable Telnet Access on R2

Enable telnet access on R2 by setting a VTY line password to “cisco”.

R2(config-if)# line vty 0 4

R2(config-line)# password cisco

Step 3: Enable TCP Header Compression

TCP header compression is used to compress TCP headers in a network to save bandwidth on a link. However, TCP header compression comes at a cost in terms of processor time.

TCP header compression must be configured on both ends of the network to compress and decompress packets. RTP header compression is configured similarly, although it is not shown in this lab.

Issue the ip tcp header-compression command in interface configuration mode to enable TCP header compression. A class-based form of the command is used in the modular QoS CLI (MQC), but that information will be covered in later labs. Configure this command on the Serial 0/0/0 interfaces on both R1 and R2.

R1(config)# interface serial0/0/0

R1(config-if)# ip tcp header-compression

R2(config)# interface serial0/0/0

R2(config-if)# ip tcp header-compression

Describe a traffic profile in which TCP header compression can be very useful.

Header compression is vital when traffic transverses a slow link and low total delay is valuable. As long as the router has a processor capable of handling the compression on both ends, TCP header-compression will better utilize the bandwidth on the line.

Step 4: Verify TCP Header Compression

Issue the show ip tcp header-compression command to view statistics for compressed TCP headers.

Generate some TCP traffic by connecting from R1 to R2 via Telnet.

R1# telnet 172.16.12.2

Trying 172.16.12.2 … Open

User Access Verification

Password: cisco

R2> exit

[Connection to 172.16.12.2 closed by foreign host]

R1#

Verify that the TCP traffic was compressed.

Given the numbers in the output of the commands shown above, identify how the efficiency improvement factor is computed:

By the numbers listed above, we can see that R1 had a 3.81 efficiency improvement. R2 had a 3.02 efficiency improvement. Overall both were close to a 90% hit ratio as far as sent and received packets that were compressed. With a basis of 1.0 efficiency improvement, 1244 bytes saved/442 bytes sent + 1.0 gives us the R1 3.81 efficiency improvement. For R2, 1109 bytes saved/ 547 bytes sent + 1.0 gives us the efficiency improvement factor.