Phillips.tc --> EPhillips.us

Just a quick note to everyone, I retired the domain name phillips.tc, so blog.phillips.tc is no longer valid.  The new address is blog.ephillips.us.  I'm hoping Google updates its cache somewhat soon so folks can find the new URL!

Zone Based Firewall, PPTP pass-through

I am seeing many people migrating from Cisco CBAC to Zone Based Firewall (ZBF) on 800 - 3900 series ISR devices being used as Internet edge firewalls due to the greater flexibility, and better interoperability with policy routing.

The most common question I receive is from a tech that sets up Zone Based Firewall according to Cisco's guide and many examples on the Internet, then finds out clients on the inside are unable to use their PPTP Windows VPN to connect to a server outside the firewall.

I encourage anyone interested in a deep understanding of PPTP to read through RFC 2637, but I will give a quick summary of the pertinent aspects of PPTP here. It is important to understand that PPTP utilizes TCP port 1723 for connection establishment, authentication, and maintenance, it then uses GRE, IP protocol 47, to pass data. By default, ZBF's keyword "match protocol pptp" does not handle the GRE traffic, only the TCP 1723 traffic.

First, let's see how to migrate from CBAC to the most basic ZBF configuration

Exhibit 1: Most Basic ZBF Config

Everything except PPTP will work outbound with this config

Step 1: Define and populate our zones:

!Define two zones

zone security ZONE_INSIDE

zone security ZONE_OUTSIDE

interface fa0/1

!Assume FastEthernet0/1 is our inside interface

zone-member security ZONE_INSIDE

interface fa0/0

!Assume FastEthernet0/1 is our outside interface

zone-member security ZONE_OUTSIDE

!Remove any CBAC commands you had here

no ip inspect CBAC in

no ip inspect CBAC out

!Remove the inbound access-list from the outside interface. Unlike CBAC, we do not control inbound access via an access-list.

no ip access-group ACLin in

Step 2: Define the class maps that identify traffic that is permitted between zones:

class-map type inspect match-any CM_INTERNET_TRAFFIC

match protocol h323

match protocol pptp

match protocol ftp

match protocol tcp

match protocol udp

match protocol icmp

!Note - we add h323 and ftp here specifically to account for upper-layer inspection required for those protocols

Step 3: Configure a policy map which specifies the action for the class map:

policy-map type inspect PM_INSIDE_TO_OUTSIDE

class type inspect CM_INTERNET_TRAFFIC

inspect

Step 4: Configure the zone pair and apply your policy:

zone-pair security ZONEP_INSIDE_OUTSIDE source ZONE_INSIDE destination ZONE_OUTSIDE

service-policy type inspect PM_INSIDE_TO_OUTSIDE

Exhibit 2: I like PPTP, would like!

This config adds outbound PPTP. Note – GRE is not automatically opened by the “match protocol pptp” in the CM_INTERNET_TRAFFIC, so we need to make GRE passed both inside to outside and reverse without inspecting it.

Step 1, Define new class-map that matches all GRE, note that you need to use an ACL for this that is referenced in the class-map:

ip access-list extended GRE

remark Access List to allow PPTP GRE outbound

permit gre any any

class-map type inspect match-any CM_GRE_PROTOCOLS

match access-group name GRE

Step 2: Configure a policy map which specifies the action for the class map:

policy-map type inspect PM_INSIDE_TO_OUTSIDE

class type inspect CM_GRE_PROTOCOLS

pass

class type inspect CM_INTERNET_TRAFFIC

inspect

class class-default

drop

policy-map type inspect PM_OUTSIDE_TO_INSIDE

class type inspect CM_GRE_PROTOCOLS

pass

class class-default

drop

Step 3: Configure the zone pair and apply your policy:

zone-pair security ZONEP_INSIDE_OUTSIDE source ZONE_INSIDE destination ZONE_OUTSIDE

service-policy type inspect PM_INSIDE_TO_OUTSIDE

zone-pair security ZONEP_OUTSIDE_INSIDE source ZONE_OUTSIDE destination ZONE_INSIDE

service-policy type inspect PM_OUTSIDE_TO_INSIDE

Note: The above config is perfect for a SOHO user who is not hosting any internal servers. However, most sites will be hosting servers internally, so below is an example with the naming scheme of how I like to form my class maps, access-lists, and policy-maps. Note that I like to keep all "variable" names in upper case so they pop out to me in my config. (Credit to Internetwork Experts for that tip)

Exhibit 3: I host servers, so I need an inbound firewall

Step 1, Define an access-list with the internal IP of the server:

ip access-list extended HELPDESK

permit ip any host 10.5.0.3

Step 2, Define a "match-any" class-map with the protocols to be allowed:

class-map type inspect match-any CM_HELPDESK_PROTOCOLS

match protocol http

match protocol https

match protocol ssh

Step 3, Define a "match-all" class map to combine the two:

class-map type inspect match-all CM_HELPDESK

match access-group name HELPDESK

match class-map CM_HELPDESK_PROTOCOLS

Step 4, Add the class-map to the OUTSIDE_TO_INSIDE policy-map:

policy-map type inspect PM_OUTSIDE_TO_INSIDE

description Internet to LAN Servers

class type inspect CM_GRE_PROTOCOLS

pass

class type inspect CM_ICMP

inspect

class type inspect CM_HELPDESK

inspect

class class-default

drop

Step 5, Don't forget your nat statement:

ip nat inside source static 10.5.0.3 1.1.1.1

Notes:

1. I like to add an ICMP inspect class map so you can ping all servers without needing to explicitly adding ICMP to every server's class-map. You would not want this if permitting pinging is not preferred, or if you are worried about ICMP security risks.
2. If you need to add a non-standard port you have two options.
1. First, give it a name: ip port-map user-RDP port tcp 3389
2. Second, define an ACL with the ports, and add it to the "match-any" CM_SERVER_PROTOCOLS:

ip access-list extended LTIITEDGE_PROTOCOLS

permit tcp any host 10.50.1.10 eq 5061

permit tcp any host 10.50.1.10 eq 8057

permit tcp any host 10.50.1.10 eq 5062

permit tcp any host 10.50.1.10 eq 3478

permit tcp any host 10.50.1.10 range 49152 65535

DocCD items to reference:

Zone-Based Firewall Configuration Guide

MPLS + Troubleshooting added to CCIE R/S exam

Cisco today announced some exciting changes to the CCIE Routing and Switching written and lab exams.  Cisco will be adding MPLS and two hours of troublshooting to the CCIE R/S lab.  The lab will now be made up of the open-ended questions, two hours of troublshooting, and then the rest of the scenario-based questions.  I have pasted the new CCIE R/S version 4 lab blueprint below.  You can read more about this change on Cisco's site at https://cisco.hosted.jivesoftware.com/community/certifications/ccie_routing_switching/lab_exam?view=overview.

1.00	Implement Layer   2 Technologies	√
1.10	Implement Spanning Tree Protocol (STP)
	(a) 802.1d
	(b) 802.1w
	(c) 801.1s
	(d) Loop guard
	(e) Root guard
	(f) Bridge protocol data unit (BPDU) guard
	(g) Storm control
	(h) Unicast flooding
	(i) Port roles, failure propagation, and loop guard operation
1.20	Implement VLAN and VLAN Trunking Protocol (VTP)
1.30	Implement trunk and trunk protocols, EtherChannel, and load-balance
1.40	Implement Ethernet technologies
	(a) Speed and duplex
	(b) Ethernet, Fast Ethernet, and Gigabit Ethernet
	(c) PPP over Ethernet   (PPPoE)
1.50	Implement Switched Port Analyzer (SPAN), Remote Switched Port Analyzer (RSPAN), and flow control
1.60	Implement Frame Relay
	(a) Local Management   Interface (LMI)
	(b) Traffic shaping
	(c) Full mesh
	(d) Hub and spoke
	(e) Discard eligible   (DE)
1.70	Implement High-Level   Data Link Control (HDLC) and PPP
2.00	Implement IPv4
2.10	Implement IP version   4 (IPv4) addressing, subnetting, and variable-length subnet masking (VLSM)
2.20	Implement IPv4   tunneling and Generic Routing Encapsulation (GRE)
2.30	Implement IPv4 RIP version 2 (RIPv2)
2.40	Implement IPv4 Open Shortest Path First (OSPF)
	(a) Standard OSPF areas
	(b) Stub area
	(c) Totally stubby area
	(d)   Not-so-stubby-area (NSSA)
	(e) Totally NSSA
	(f) Link-state advertisement (LSA) types
	(g) Adjacency on a point-to-point and on a multi-access network
	(h) OSPF graceful restart
2.50	Implement IPv4 Enhanced Interior Gateway Routing Protocol (EIGRP)
	(a) Best path
	(b) Loop-free paths
	(c) EIGRP operations when alternate loop-free paths are available, and when they are not available
	(d) EIGRP queries
	(e) Manual summarization and autosummarization
	(f) EIGRP stubs
2.60	Implement IPv4 Border Gateway Protocol (BGP)
	(a) Next hop
	(b) Peering
	(c) Internal Border Gateway Protocol (IBGP) and External Border Gateway Protocol (EBGP)
2.70	Implement policy   routing
2.80	Implement Performance Routing (PfR) and Cisco Optimized Edge Routing (OER)
2.90	Implement filtering, route redistribution, summarization, synchronization, attributes, and other advanced features
3.00	Implement IPv6
3.10	Implement IP version 6 (IPv6) addressing and different addressing types
3.20	Implement IPv6  neighbor discovery
3.30	Implement basic IPv6 functionality protocols
3.40	Implement tunneling techniques
3.50	Implement OSPF version 3 (OSPFv3)
3.60	Implement EIGRP version 6 (EIGRPv6)
3.70	Implement filtering and route redistribution
4.00	Implement MPLS Layer 3 VPNs
4.10	Implement Multiprotocol Label Switching (MPLS)
4.20	Implement Layer 3 virtual private networks (VPNs) on provider edge (PE), provider (P), and customer edge (CE) routers
4.30	Implement virtual routing and forwarding (VRF) and Multi-VRF Customer Edge (VRF-Lite)
5.00	Implement IP Multicast
5.10	Implement Protocol   Independent Multicast (PIM) sparse mode
5.20	Implement Multicast   Source Discovery Protocol (MSDP)
5.30	Implement interdomain   multicast routing
5.40	Implement   PIM Auto-Rendezvous Point (Auto-RP), unicast rendezvous point (RP), and   bootstrap router (BSR)
5.50	Implement   multicast tools, features, and source-specific multicast
5.60	Implement IPv6 multicast, PIM, and related multicast protocols, such as Multicast   Listener Discovery (MLD)
6.00	Implement Network   Security
6.01	Implement access   lists
6.02	Implement Zone Based   Firewall
6.03	Implement Unicast   Reverse Path Forwarding (uRPF)
6.04	Implement IP Source   Guard
6.05	Implement   authentication, authorization, and accounting (AAA) (configuring the AAA   server is not required, only the client-side (IOS) is configured)
6.06	Implement Control   Plane Policing (CoPP)
6.07	Implement Cisco IOS   Firewall
6.08	Implement Cisco IOS   Intrusion Prevention System (IPS)
6.09	Implement Secure   Shell (SSH)
6.10	Implement 802.1x
6.11	Implement NAT
6.12	Implement routing   protocol authentication
6.13	Implement device   access control
6.14	Implement security   features
7.00	Implement Network   Services
7.10	Implement Hot Standby   Router Protocol (HSRP)
7.20	Implement Gateway   Load Balancing Protocol (GLBP)
7.30	Implement Virtual   Router Redundancy Protocol (VRRP)
7.40	Implement Network   Time Protocol (NTP)
7.50	Implement DHCP
7.60	Implement Web Cache   Communication Protocol (WCCP)
8.00	Implement Quality of   Service (QoS)
8.10	Implement Modular QoS CLI (MQC)
	(a) Network-Based   Application Recognition (NBAR)
	(b)   Class-based weighted fair queuing (CBWFQ),  modified deficit round robin (MDRR), and low latency queuing (LLQ)
	(c) Classification
	(d) Policing
	(e) Shaping
	(f) Marking
	(g) Weighted random   early detection (WRED) and random early detection (RED)
	(h) Compression
8.20	Implement Layer 2   QoS: weighted round robin (WRR), shaped round robin (SRR), and policies
8.30	Implement link   fragmentation and interleaving (LFI) for Frame Relay
8.40	Implement generic   traffic shaping
8.50	Implement Resource   Reservation Protocol (RSVP)
8.60	Implement Cisco   AutoQoS
9.00	Troubleshoot a Network
9.10	Troubleshoot complex Layer 2 network issues
9.20	Troubleshoot complex Layer 3 network issues
9.30	Troubleshoot a network in response to application problems
9.40	Troubleshoot network services
9.50	Troubleshoot network security
10.00	Optimize the Network
10.01	Implement syslog and   local logging
10.02	Implement IP Service   Level Agreement SLA
10.03	Implement NetFlow
10.04	Implement SPAN,   RSPAN, and router IP traffic export (RITE)
10.05	Implement Simple   Network Management Protocol (SNMP)
10.06	Implement Cisco IOS   Embedded Event Manager (EEM)
10.07	Implement Remote   Monitoring (RMON)
10.08	Implement FTP
10.09	Implement TFTP
10.10	Implement TFTP server   on router
10.11	Implement   Switch-module Configuration Protocol (SCP)
10.12	Implement HTTP and   HTTPS
10.13	Implement Telnet

CCIE ALU - Traffic Control

Foreward: An ALU is an Autonomous Learning Unit, you can read this post to learn more about them.

 

 

Question:

In addition to the 1.1.3.0/24 subnet on R3's FastEthernet0/0 interface, there is also a subnet 1.1.33.0/24, which contains several high bandwidth users.  These users have been receiving very large HTTP downloads across the Serial1/3 interface.  Limit HTTP responses destined to the 1.1.33.0/24 subnet to 512kbit/sec.  All configuration must be done on R3.

 

 

Highlight below for the solution:

 

Solution:

R3:

ip access-list extended HTTP_TO_1.1.33

 permit tcp any eq www 1.1.33.0 0.0.0.255

!

class-map match-all HTTP_TO_1.1.33

 match access-group name HTTP_TO_1.1.33

!

policy-map QOS1

 class HTTP_TO_1.1.33

    police 512000

 class class-default

!

interface Serial1/3

 service-policy input QOS1

 

 

Confirmation:

Rack1R3(config-if)#do sh policy-map int            

 Serial1/3

 

  Service-policy input: QOS1

 

    Class-map: HTTP_TO_1.1.33 (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: access-group name HTTP_TO_1.1.33

      police:

          cir 512000 bps, bc 16000 bytes

        conformed 0 packets, 0 bytes; actions:

          transmit

        exceeded 0 packets, 0 bytes; actions:

          drop

        conformed 0 bps, exceed 0 bps

 

    Class-map: class-default (match-any)

      11 packets, 1088 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: any

 

 

Explanation:

Since all configuration must be done on R3, we must use policing because only the very high-end Cisco  routers can perform shaping inbound.  We create a class that matches TCP traffic with a source port of 80 and any destination port, since the HTTP request is a very small packet going out Serial1/3, and the HTTP response is the very large packet coming in Serial1/3.

 

One important point to remember is this method of traffic control is ineffective for controlling UDP traffic streams since the traffic has already traversed the serial link between R2 and R3 by the time policing on R3 is enforced.  This method of policing on the "far end" is effective when controlling TCP traffic because the applications will set their sliding window to a size that will approximate 512kbit/sec.

 

If you are not 100% familiar with TCP, sliding windows, and all aspects of TCP retransmission, please read the following site for a great tutorial:  http://www.rhyshaden.com/tcp.htm

 

I highly encourage you to be extremely consistent in the way you name access-lists, class-maps, policy-maps, or other items you create in the IOS.  You are free to create any system you would like, but my general guidelines are to make your variables in all capital letters so they stand out in your show commands.  I also like to name items according to the section they were created for.  For example, if item 4.5 in the QOS section of a test requires me to create an access-list, I will name the access-list QOS4.5.  Or if I need to make a numbered ACL, I will number it 45 or 145 depending if I need a standard or extended access-list.

 

 

DocCD items to reference:

Configuration Guide (Class-Based Weighted Fair Queueing Configuration Task List)

class-map

policy-map

police

ip access-list  (Named Access-Lists)

service-policy in

CCIE ALU - FRTS and how to compute ts

Foreward: A CCIE ALU is an Autonomous Learning Unit, you can read this post to learn more about them.

 

 

 

Question:

Users have been reporting an increase in the number of dropped packets on the frame relay link between R1 and R2.  Your frame relay provider has sent you a notice that they are seeing significantly more traffic attempting to go through the frame relay link then permitted.  You have purchased 128kbit/sec of guaranteed bandwidth from the provider, but there is currently no restriction on the amount of traffic permitted out the frame relay link.  Limit the amount of traffic traversing the frame relay link to the permitted amount.  You will soon be allowing voice traffic across that link, so you must minimize delay and jitter.

 

 

 

Highlight below for the solution:

 

Solution:

map-class frame-relay FRTS

 frame-relay cir 128000

 frame-relay bc 1280

 frame-relay be 0

!

interface Serial0/0

 frame-relay traffic-shaping

 frame-relay class FRTS

 

Confirmation:

R2#show frame pvc 201

 

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

 

DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

 

  input pkts 5             output pkts 5            in bytes 520      

  out bytes 520            dropped pkts 0           in pkts dropped 0        

  out pkts dropped 0                out bytes dropped 0        

  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0        

  out BECN pkts 0          in DE pkts 0             out DE pkts 0        

  out bcast pkts 0         out bcast bytes 0        

  5 minute input rate 0 bits/sec, 0 packets/sec

  5 minute output rate 0 bits/sec, 0 packets/sec

  pvc create time 1w6d, last time pvc status changed 00:00:01

  cir 128000    bc 1280      be 0         byte limit 160    interval 10 

  mincir 64000     byte increment 160   Adaptive Shaping none

  pkts 0         bytes 0         pkts delayed 0         bytes delayed 0       

  shaping inactive   

  traffic shaping drops 0

  Queueing strategy: fifo

  Output queue 0/40, 0 drop, 0 dequeued

 

 

Explanation:

Frame relay traffic shaping is the method of controlling the rate at which packets are allowed to exit an interface.  Since frame relay is a multi-access medium, FRTS specifically allows us to specify separate queues for each DLCI, therefore if you need to allow a certain amount of bandwidth between one set of routers, and a separate amount of bandwidth between another set of routers, FRTS is a great option.

 

By default there is no limit to the amount of traffic exiting an interface, therefore in this case we will be attempting to send traffic up to the full interface speed out the frame relay interface.  Since our service provider is limiting us to 128kbit/sec, it is fruitless to send more than that.

 

The most important part of this question is to understand how CIR, Bc, Be, and Tc relate mathematically.    In this case, since we are asked to minimize delay and jitter we need to set our Tc as low as possible, which is 10ms.

 

You cannot set the Tc for FRTS explicitly, therefore we must calculate it.  To obtain the Tc we want, we need to first figure out how many segments should be sent in a single second.  To do this we take 1000 ms and divide it by the desired TC:

 

1000 / 10 = 100

 

Now we take our CIR and divide it by the number of segments we will send in a given second to figure out how many bits we should send each time segment, that number will be our Bc:

 

128000 / 100 = 1280

 

FRTS will now send 1280 bits every 10ms, resulting in 128,000 bits being sent per second.

 

It is interesting to note that a router cannot actually send data at less than the interface speed.  Therefore, if our frame relay connection above is a 1.536Mbit/sec T1, FRTS will send 1280 bits in  only 0.84ms, then sit idle for 9.16ms, then repeat that process 99 more times per second, resulting in the equivalent of 128Kbit/sec.

 

If you remember the above two step process, you will always be able to calculate the Bc needed to achieve a certain Tc.

1. Figure out how many segments should be sent in a single second    (1000ms / 10ms = 100 segments)
2. Divide our CIR by the number of segments to send in a single second to calculate Bc (128000bps / 100 segments = 1280 bits/segment)

 

 

DocCD items to reference:

Configuration Guide (Configuring Frame Relay Traffic Shaping)

map-class frame relay

frame relay traffic-shaping

frame relay class

show frame-relay pvc

CCIE ALU - CBWFQ and qos-group tagging to match traffic

Foreward: An ALU is an Autonomous Learning Unit to help with CCIE lab preparation , you can read this post to learn more about them.

 

 

Question:

 

All traffic coming in Serial0/1 of R2 needs to be guaranteed 512Kbit/sec of bandwidth when exiting the frame relay interface of R2.  All traffic entering FastEthernet0/0 of R2 should be dropped if it tries to exit the frame relay interface of R2, unless it is HTTPS traffic.  No change in configuration should be required if any IP addresses change in the future.  Also, no part of the packet header should be modified in any way by this configuration.

 

 

 

 

Highlight below for the solution:

 

Solution:

R2:

class-map match-all MATCH_HTTPS

 match protocol secure-http

class-map match-all MATCH_QOS1

 match qos-group 1

class-map match-all MATCH_QOS2

 match qos-group 2

!

policy-map IN_S0-1

 class class-default

  set qos-group 1

policy-map OUT_S0-0

 class MATCH_QOS1

  bandwidth 512

 class MATCH_QOS2

   drop

policy-map IN_FA0-0

 class MATCH_HTTPS

 class class-default

  set qos-group 2

!

interface FastEthernet0/0

 service-policy input IN_FA0-0

interface Serial0/1

 service-policy input IN_S0-1

interface Serial0/0

 service-policy output OUT_S0-0

 

 

Confirmation:

R2#show policy-map interface

 FastEthernet0/0

 

  Service-policy input: IN_FA0-0

 

    Class-map: MATCH_HTTPS (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps

      Match: protocol secure-http

 

    Class-map: class-default (match-any)

      45 packets, 670 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: any

      QoS Set

        qos-group 2

          Packets marked 45

 Serial0/0

 

  Service-policy output: OUT_S0-0

 

    Class-map: MATCH_QOS1 (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: qos-group 1

      Queueing

        Output Queue: Conversation 265

        Bandwidth 512 (kbps)Max Threshold 64 (packets)

        (pkts matched/bytes matched) 0/0

        (depth/total drops/no-buffer drops) 0/0/0

 

    Class-map: MATCH_QOS2 (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: qos-group 2

      drop

 

    Class-map: class-default (match-any)

      33 packets, 462 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: any

 Serial0/1

 

  Service-policy input: IN_S0-1

 

    Class-map: class-default (match-any)

      15 packets, 150 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: any

      QoS Set

        qos-group 1

          Packets marked 15

 

 

Explanation:

Qos-group is a flag that can be set and matched on packets, and is local to the router; that is, it is not an industry standard flag, or a flag that is part of the IP or Ethernet headers.  The qos-group is very useful because it allows you to apply QOS policy without modifying a packet.  For example, in the above question we could have set a DSCP or IP Precedence value, then matched based on that.  However, that would modify the packet and change those values; which might have been set by other devices in the network.

 

In this example we are setting QOS Group 1 on any packets entering the PPP serial link from R3 using the policy-map IN_S0-1.  We are also setting QOS Group 2 on any non-HTTPS packet entering FastEthernet0/0 using policy-map IN_FA0-0.  We are then reserving bandwidth for QOS Group 1, and dropping QOS Group 2 in policy-map OUT_S0-0.

 

An important point to remember is that policy-maps are "first hit exit" policies.  Meaning traffic is compared to each class within the policy-map, and as soon as it finds one that matches, the actions in that class are executed and the policy-map is exited.  In the example of IN_FA0-0 we can see that we are matching HTTPS traffic, and applying no action to it.  All other traffic hits the class class-default and has a QOS-GROUP 2 set on it.  An alternative to this configuration would be to set QOS-GROUP 2 on all traffic entering FastEthernet0/0, then in policy-map OUT_S0-0 you could match HTTPS and do nothing to it, thereby bypassing the drop associated with QOS GROUP 2.  Both options are valid and would be awarded full credit in the CCIE lab.

 

DocCD items to reference:

Configuration Guide (Class-Based Weighted Fair Queueing Configuration Task List)

class-map

policy-map

match protocol

drop (in a class-map)

set qos-group

service-policy in

service-policy out

show policy-map interface