Showing posts with label qos. Show all posts
Showing posts with label qos. Show all posts

Monday, February 2, 2009

3560 QoS: Per-port per-vlan policing

I know the name is scary, but I do dig Catalyst QoS. This is the second of back-to-back posts on the subject. This is one is a little more complex than classification and decided on a Visio for it:


Per-van policing in the 3560s is different from the 3550s because there is no "match VLAN" clause available. Instead you create hierarchical policies and attach them to the SVI.

Here is the scenario:

VLAN100 will be policed to 64k (192.168.100.0/24)
VLAN200 Will be policed to 128k (192.168.200.0/24)

Because of bursts, I was not able to get these exact rates, but you will see how these policies are applied and the effect they have on traffic flow. Plus you can always play with the burst sizes on your own :)

Here is the tracker I created on R2:

access-list 1 permit 192.168.100.1
access-list 1 permit 192.168.100.3
access-list 2 permit 192.168.200.5
!
class-map match-any VLAN100
match access-group 1
class-map match-any VLAN200
match access-group 2
!
policy-map TRACKER
class VLAN100
class VLAN200
!
interface Ethernet0/0
no ip address
load-interval 30
full-duplex
!
interface Ethernet0/0.100
encapsulation dot1Q 100
ip address 192.168.100.2 255.255.255.0
service-policy input TRACKER
!
interface Ethernet0/0.200
encapsulation dot1Q 200
ip address 192.168.200.2 255.255.255.0
service-policy input TRACKER

All configuration is being done on SW2. There really is not an order of operations to follow, but basically you just need to make sure class-maps and policy-maps are created before you apply them. The logical flow is what you want to get used to. Otherwise you will be jumping into and out of classes and policies, reconfiguring them like I did :)

At our child (aka "second") level we have a class-map that matches the interface and we have our policer. The interface matching here is whats is referred into in the first clause of "per-port per-vlan" policing.

class-map match-all TRUNK
match input-interface FastEthernet0/13
!
policy-map VLAN100-POLICER
class TRUNK
police 64000 12000 exceed-action drop
policy-map VLAN200-POLICER
class TRUNK
police 128000 24000 exceed-action drop

As far as I know, this "bottom" or "second" level class-map can only match input-interface. And this second level policy must be a policer.

Now, at the parent level we create a new class to match IP traffic and then apply our child polices below that. This top-level class must match an ACL (match protocol ip gave me errors when applying the policy).

access-list 100 permit ip any any
!
class-map match-all IP
match access-group 100
!
policy-map VLAN100-PARENT
class IP
set ip precedence 1
service-policy VLAN100-POLICER
policy-map VLAN200-PARENT
class IP
set ip precedence 2
service-policy VLAN200-POLICER

Notice that I have the "set ip precedence" clause in our parent policies. These first level policies are required to have an action. You will get an error message stating this if you try to apply it to the SVI without an action:

SW2(config)#int vlan 100
SW2(config-if)#service-policy input VLAN100-PARENT
%QoS: No action is configured in the policymap VLAN100-PARENT classmap IP, or it is being modified.


So make sure you have set or trust clause in there. Now we can apply them to the SVIs:

mls qos
!
interface FastEthernet0/13

mls qos vlan-based
!
interface Vlan100
no ip address
service-policy input VLAN100-PARENT
!
interface Vlan200
no ip address
service-policy input VLAN200-PARENT

From R1, R3 and R5 I will send a bunch of pings to R2:

R1#ping 192.168.100.2 re 1000000
R3#ping 192.168.100.2 re 1000000
R5#ping 192.168.200.2 re 1000000

Let's look at R2 after a few minutes.

R2#sho policy-map interface e0/0.100 | section VLAN100
Class-map: VLAN100 (match-any)
107819 packets, 12722642 bytes
30 second offered rate 50000 bps
Match: access-group 1
107819 packets, 12722642 bytes
30 second rate 50000 bps

R2#sho policy-map interface e0/0.200 | section VLAN200
Class-map: VLAN200 (match-any)
156873 packets, 18511014 bytes
30 second offered rate 107000 bps
Match: access-group 2
156873 packets, 18511014 bytes
30 second rate 107000 bps

We don't see the limits of 64k and 128k being reached, but the drops on the senders indicate that policing is working. And we can also tell VLAN 200 is getting roughly twice the bandwidth that VLAN 100 is getting. We could get closer to the limit by adjusting the burst sizes appropriately.

Key things to remember:
  • Child classes use match input-interface
  • Child policies use police
  • Parent classes match ACL (I think you can also match dscp, maybe others)
  • Parent policies must have an action (e.g. set or trust)
  • Apply parent policies to SVI
I strongly recommend getting your hands dirty with these configurations if you want to master them. I read a lot about switch qos, but it wasn't until I started playing around with scenarios like this that I got a better understanding of how to do it and what is required. If we truly understand what each QoS method does, then we should have no trouble deciphering what we are asked to do on the lab :)

3560 QoS: VLAN-Based Classification

This is a topic I learned about while reading blogs over at IE. Here is the original:

Comparing Traffic Policing Features in the 3550 and 3560 switches

I have the following topology:

R1----|
R3---SW1---SW2---R2
R5----|

R1,R3 are in vlan 100, 192.168.100.0/24
R5 is in vlan 200, 192.168.200.0/24

R2 is on a trunked port with the following configuration:

interface Ethernet0/0.100
encapsulation dot1Q 100
ip address 192.168.100.2 255.255.255.0
ip accounting precedence input
no snmp trap link-status
!
interface Ethernet0/0.200
encapsulation dot1Q 200
ip address 192.168.200.2 255.255.255.0
ip accounting precedence input
no snmp trap link-status

On SW2 we will enable vlan-based qos and then mark traffic based on ACLs. First we make the ACLs:

ip access-list extended ICMP
permit icmp any any
ip access-list extended TCP
permit tcp any any

Next we make our class-maps and policy-maps:

class-map match-all ICMP
match access-group name ICMP
class-map match-all TCP
match access-group name TCP

policy-map VLAN
class TCP
set ip precedence 5
class ICMP
set ip precedence 3

Next enable mls qos, vlan-based qos and apply the policy to an SVI. Note that the SVI does not need an IP address:

mls qos

int f0/13
interface FastEthernet0/13
switchport trunk encapsulation dot1q
switchport trunk native vlan 50
switchport mode trunk
mls qos vlan-based

int vlan 100
service-policy input VLAN
int vlan 200
service-policy input VLAN

Now run some tests. Here I Ping and Telnet from R5, telnet from R1 and then ping from R3:

R5#ping 192.168.200.2 rep 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 192.168.200.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/3/4 ms
R5#

R5#telnet 192.168.200.2
Trying 192.168.200.2 ... Open

R2>exit

[Connection to 192.168.200.2 closed by foreign host]
R5#

R1#telnet 192.168.100.2
Trying 192.168.100.2 ... Open

R2>exit

[Connection to 192.168.100.2 closed by foreign host]
R1#

R3#ping 192.168.100.2 re 50

Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 1/3/4 ms
R3#

Verify on R2:

R2#sho int precedence
Ethernet0/0.100
Input
Precedence 3: 50 packets, 5900 bytes
Precedence 5: 46 packets, 2953 bytes
Ethernet0/0.200
Input
Precedence 3: 100 packets, 11800 bytes
Precedence 5: 15 packets, 969 bytes
R2#

Saturday, November 22, 2008

Traffic Shaping - "Peak" sets target rate higher than "Average"

Here is my topology:

R1----R3----[LAN with R4 and R5]

R4 and R5 are sending traffic to R1's loopback 1.1.1.1
R3 has the following configuration:

! ACLs to match R4 and R5:
!
access-list 4 permit 172.12.34.4
access-list 5 permit 172.12.34.5
!
! Classes that match R4 and R5:
!
class-map match-all R4
match access-group 4
class-map match-all R5
match access-group 5
!
! Policy that uses "peak" for R5, "average" for R4
!
policy-map SHAPER
class R5
bandwidth 100
shape peak 128000
class R4
bandwidth 100
shape average 128000
!
! Policy applied outbound toward R1
!
interface FastEthernet0/0
ip address 172.12.123.3 255.255.255.0
load-interval 30
speed 100
full-duplex
service-policy output SHAPER


This has been running for about 10-15 minutes. R4 seems to be shaped as normal around 128k. R5 though is hitting 180k.

R3#show policy-map interface
FastEthernet0/0

Service-policy output: SHAPER

Class-map: R5 (match-all)
14826 packets, 20963964 bytes
30 second offered rate 181000 bps, drop rate 0 bps
Match: access-group 5
Queueing
Output Queue: Conversation 265
Bandwidth 100 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 833/1177862
(depth/total drops/no-buffer drops) 0/0/0
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
256000/128000 1984 7936 7936 62 1984

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 14826 20963964 831 1175034 no

Class-map: R4 (match-all)
10214 packets, 14442596 bytes
30 second offered rate 124000 bps, drop rate 0 bps
Match: access-group 4
Queueing
Output Queue: Conversation 266
Bandwidth 100 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 5221/7382494
(depth/total drops/no-buffer drops) 0/0/0
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
128000/128000 1984 7936 7936 62 992

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 1 10213 14441182 5221 7382494 yes

Class-map: class-default (match-any)
226 packets, 22043 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any



But if you look in the output above you can see that the Target/Average rate for R5 is set to 256000/128000. Nowhere did I specify 256000. By using shape peak 128000, this was configured for me. What's more is that my traffic rate never reaches 256000. This is because there is congestion on the interface and R4 is also sending traffic. If I stop R4 from sending this is what I will have:

R3#show policy-map interface
FastEthernet0/0

Service-policy output: SHAPER

Class-map: R5 (match-all)
23779 packets, 33623506 bytes
30 second offered rate 241000 bps, drop rate 0 bps
Match: access-group 5
Queueing
Output Queue: Conversation 265
Bandwidth 100 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 2859/4042626
(depth/total drops/no-buffer drops) 0/0/0
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
256000/128000 1984 7936 7936 62 1984

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 23779 33623506 2853 4034142 yes

Class-map: R4 (match-all)
12499 packets, 17673586 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: access-group 4
Queueing
Output Queue: Conversation 266
Bandwidth 100 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 6393/9039702
(depth/total drops/no-buffer drops) 0/0/0
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
128000/128000 1984 7936 7936 62 992

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 12499 17673586 6392 9038288 no

Class-map: class-default (match-any)
328 packets, 32056 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any


I never quite reach 256000, but I am getting close and hover around 241000 to 246000 consistently.

Still researching why the target rate is 256000...if anyone knows, please leave comment!

* * * * * U P D A T E ! ! ! * * * * *

This is a flash update, I think I have a better understanding of this now. For some reason I was thinking the values after "peak" was different than the value after "average". They are both CIR! This will always be the "average rate". You target rate will be set using default values if you do not specify a Be. And it appears Be = Bc by default.

R3(config-pmap-c)#shape ?
average configure token bucket: CIR (bps) [Bc (bits) [Be (bits)]], send out Bc only per interval
peak configure token bucket: CIR (bps) [Bc (bits) [Be (bits)]], send out Bc+Be per interval


So if you want a peak rate of 512000, there are multiple things you can configure since you are sending Bc+Be every interval. In fact you can:

1) set peak to 512000, Bc to 5120, Be of 0
2) set peak to 384000, Bc to 3840, Be to 1280
3) set peak to 256000, Bc to 2560, Be to 2560

All of these (and many more combinations) set target rate to 512000.

Friday, September 26, 2008

3560 QoS - DSCP mutation

I am completely absorbing myself in 3560 qos. I love it. I love reading about it and labbing it. So browsing through the DocCD today, I decided to lab dscp-dscp mutation. It's fairly simple, but along the way I also learned how to monitor and a way to mark traffic.

Here is the topology (it's a mutated iewb topology)

R4====SW2====SW1====SW3---[int vlan 201,202]

R4 is trunk link carrying vlan 201,202:

interface Ethernet0/0.201
encapsulation dot1Q 201
ip address 155.1.201.4 255.255.255.0
!
interface Ethernet0/0.202
encapsulation dot1Q 202
ip address 155.1.202.4 255.255.2550


SW3 has two SVIs:

interface Vlan201
ip address 155.1.201.9 255.255.255.0

interface Vlan202
ip address 155.1.202.9 255.255.255.0


Other links are all dot1q trunks passing vlan 201 and 202.

1. SET UP SW2 TO CLASSIFY AND MARK

mls qos

access-list 1 permit 155.1.201.0 0.0.0.255
access-list 2 permit 155.1.202.0 0.0.0.255

class-map match-all VLAN202
match access-group 2
class-map match-all VLAN201
match access-group 1

policy-map MARK
class VLAN201
set precedence 1
class VLAN202
set precedence 2

interface FastEthernet0/4
service-policy input MARK


2. ON SW3 TRUST AND MONITOR QOS

mls qos

int f0/13
mls qos trust dscp
mls qos monitor dscp 0 8 16 24 32

SW3# show mls qos int f0/13 st
FastEthernet0/13
Ingress
dscp: incoming no_change classified policed dropped (in pkts)
0 : 19 19 200 0 0
8 : 200 100 0 0 0
16: 200 100 0 0 0
24: 0 0 0 0 0
32: 0 0 0 0 0
Others: 0 0 0 0 0
Egress
dscp: incoming no_change classified policed dropped (in pkts)
0 : 200 n/a n/a 0 0
8 : 100 n/a n/a 0 0
16: 100 n/a n/a 0 0
24: 0 n/a n/a 0 0
32: 0 n/a n/a 0 0
Others: 283 n/a n/a 0 0

You can see that we already have traffic coming in as DSCP 8 and 16. We will be mutating these on SW1.

3. CONFIGURE DSCP-to-DSCP MUTATION ON SW1

mls qos
mls qos map dscp-mutation MAP1 8 to 24
mls qos map dscp-mutation MAP1 16 to 32
int f0/13
mls qos trust dscp
mls qos dscp-mutation MAP1


4. PING FROM R4 to SVI on SW3

R4#ping 155.1.202.9 re 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 155.1.202.9, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/4 ms
R4#ping 155.1.201.9 re 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 155.1.201.9, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/8 ms
R4#


5. VERIFY MUTATION ON SW3

SW3# show mls qos int f0/13 st
FastEthernet0/13
Ingress
dscp: incoming no_change classified policed dropped (in pkts)
0 : 194 194 200 0 0
8 : 600 500 0 0 0
16: 700 600 0 0 0
24: 100 100 0 0 0
32: 100 100 0 0 0
Others: 0 0 0 0 0
Egress
dscp: incoming no_change classified policed dropped (in pkts)
0 : 200 n/a n/a 0 0
8 : 500 n/a n/a 0 0
16: 600 n/a n/a 0 0
24: 100 n/a n/a 0 0
32: 100 n/a n/a 0 0
Others: 2674 n/a n/a 0 0


Notice that we now have 100 packets each marked DSCP 24 and 32.

Sunday, September 21, 2008

RSVP - Allowed reservable bandwidth

I don't see RSVP on the R&S blueprint but there is "signaling" so maybe I will see it. Anyways I had the following task today in IPexpert's volume 1 section 18:

- Link between R2-R5 is a T1
- Allow dynamic reservations done by applications using this link
- Allow oversubscription by 200% of the link speed.
- If RTP, make sure header is only 1-2 bytes

The last part is easy, it's juts RTP header compression. However the first 3 parts caused some trouble. Here's why:

R2(config)#int s0/2/0
R2(config-if)#ip rsvp bandwidth 3088

RSVP bandwidth (which is the bandwidth for the IP
headers and data inside them, but not the required
link layer headers) exceeds 75% of interface bandwidth.
It may be that you need to enter the 'bandwidth'
command to correct the system's understanding of the
available bandwidth. If that's not the case, then:
Due to bit-stuffing, layer 2 headers and layer 1
framing, and the need for routing and keep-alive
traffic, not to mention the RSVP messages themselves,
this is just plain too high. Configure your interface
realistically for the bandwidth available.


Easy right? Just set the max-reserved-bandwidth to 100% and set the bandwidth to 3088.

R2(config)#int s0/2/0
R2(config-if)#band 3088
R2(config-if)#max-reserved-bandwidth 100
R2(config-if)#ip rsvp bandwidth 3088

RSVP bandwidth (which is the bandwidth for the IP
headers and data inside them, but not the required
link layer headers) exceeds 75% of interface bandwidth.
It may be that you need to enter the 'bandwidth'
command to correct the system's understanding of the
available bandwidth. If that's not the case, then:
Due to bit-stuffing, layer 2 headers and layer 1
framing, and the need for routing and keep-alive
traffic, not to mention the RSVP messages themselves,
this is just plain too high. Configure your interface
realistically for the bandwidth available.


Not so fast! It turns out max-reserved-bandwidth doesn't apply to RSVP. So we have to set the bandwidth a little higher...how much higher?

3088/0.75 = 4118

R2(config-if)#band 4118
R2(config-if)#ip rsvp bandwidth 3088

Friday, September 5, 2008

Class-Based TCP header compression, traveling the DocCD

I was playing around with header compression today and noticed an issue (no longer an issue, I found my problem, see comments section) with class-based header compression. First, here is my topology:

R2-----ethernet-----[R3]-----serial-----[R4]

On R3 I have the following:

class-map match-all TELNET
match protocol telnet
!
policy-map OUT2R4
class TELNET
compress header ip
!
interface Serial1/1
ip address 172.12.34.3 255.255.255.0
service-policy output OUT2R4

When I telnet to R4 from R2 nothing happens, it opens up but I get no password prompt:

R2#telnet 4.4.4.4
Trying 4.4.4.4 ... Open




When I disable compression it works fine. So on R4 I tried to enable compression:

R4(config)#class-map TELNET
R4(config-cmap)#match protocol telnet
R4(config-cmap)#exit
R4(config)#policy-map INBOUND
R4(config-pmap)#class TELNET
R4(config-pmap-c)#compression header ip
R4(config)#int s1/1
R4(config-if)#service-policy input INBOUND
Header compression: Can be enabled as an output feature only
R4(config-if)#^Z

So I tried this instead:

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

But still it didn't work. So I headed to the DocCD:

First stop was 12.4 Quality of Service Configuration Guide. From there I went to Part 6: Link Efficiency Mechanisms. Next I clicked the "Header Compression" link then to "Configuring Class-Based RTP and TCP Header Compression." I already had what I thought was the correct CBWFQ configuration but nevertheless, I started here.

After shortly browsing this topic I found "Configuring TCP Header Compression" link. Here is where I found the treasure in the configuration example:

"ip tcp header-compression [passive | iphc-format | ietf-format]"

But my R4 doesn't have the iphc-format option listed:

R4(config-if)#ip tcp header-compression ?
passive Compress only for destinations which send compressed headers


But it took as a hidden option:

R4(config-if)#ip tcp header-compression iphc-format

And it worked!

R2#telnet 4.4.4.4
Trying 4.4.4.4 ... Open


User Access Verification

Password:
R4>

Not sure if all the links above will be available in the real lab, but it still was a good exercise in getting through the documentation. I started off with QoS, made my to Class-based compression and then ultimately found the command I was looking for - one that wasn't even in my context help!

Sunday, June 1, 2008

Priority-queuing in Action

Too see how priotiy-queuing impacts traffic flows, I set up a small lab. R2, R3 and R4 connect to the same LAN as R5. R5 connects to R6. Each router has a loopback x.x.x.x where x is the router number.

R2
\
R3-------f0/0 R5 s1/1 ----R6
/
R4

On R5 we make 3 ACLs:

R5(config)#access-list 102 permit icmp host 2.2.2.2 host 6.6.6.6
R5(config)#access-list 103 permit icmp host 3.3.3.3 host 6.6.6.6
R5(config)#access-list 104 permit icmp host 4.4.4.4 host 6.6.6.6

Now we assign each ACL to a priority-list

R5(config)#priority-list 1 protocol ip high list 102
R5(config)#priority-list 1 protocol ip medium list 103
R5(config)#priority-list 1 protocol ip normal list 104

Assign the priority-list to the interface with the priority-group command:

R5(config)#int s1/1
R5(config-if)#priority-group 1

Now let's verify the priority queuing is working.

Below we get a baseline and see that R3 normally gets an average round trip time of 34-38 ms for 200 pings. When R2 starts sending traffic, we can see the R3 round trip average (and max time) increase about 50%.

R3 pings, R2 is silent:

R3#ping 6.6.6.6 source 3.3.3.3 repeat 200

Type escape sequence to abort.
Sending 200, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
Success rate is 100 percent (200/200), round-trip min/avg/max = 4/34/188 ms

R3#ping 6.6.6.6 source 3.3.3.3 repeat 200

Type escape sequence to abort.
Sending 200, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
Success rate is 100 percent (200/200), round-trip min/avg/max = 4/38/104 ms

R3 and R2 both send pings (I started sending 250 1200-byte packets from R2 first, then quickly hopped over to R3 and started the ping)

R3#ping 6.6.6.6 source 3.3.3.3 repeat 200

Type escape sequence to abort.
Sending 200, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
Success rate is 100 percent (200/200), round-trip min/avg/max = 4/57/220 ms

R3#ping 6.6.6.6 source 3.3.3.3 repeat 200

Type escape sequence to abort.
Sending 200, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
Success rate is 100 percent (200/200), round-trip min/avg/max = 8/66/368 ms

Notice how much higher the avg and max times are for R3 when R2 is pinging R6. We can see directly how priority-queuing impacts traffic flows.