3550 support both inbound and outbound policy. 3560 only support inbound policy.
1. 3550 per-port per-vlan policy
class-map match-any dscp-class
match ip dscp af31
!
class-map match-all vlan-class
match vlan 5 10-30 40
match class-map dscp-class
!
policy-map vlan-dscp
class-map vlan-class
set dscp CS3
police 128000 8000 exceed-action drop
!
inter fa 1/13
service-policy input vlan-dscp
2. 3560 SVI by using hierarchical policy maps
!
! Any non-IP traffic
!
mac access-list extended MAC_ANY
permit any any 0x0 0xFFFF
!
! Any IP traffic
!
ip access-list extended IP_ANY
permit ip any any
!
! Class for any non-IP traffic
!
class-map MAC_ANY
match access-group name MAC_ANY
!
! Class for any IP traffic
!
class-map IP_ANY
match access-group name IP_ANY
!
! Class to match the port connected to R1
!
class-map PORT_R1
match input-interface FastEthernet 0/1
!
! Class to match the port connected to R3
!
class-map PORT_R3
match input-interface FastEthernet 0/3
!
! Inteface-level policy-maps, limit rate per-port (R1 & R3)
!
policy-map PORT_R1
class PORT_R1
police 64000 8000
!
policy-map PORT_R3
class PORT_R3
police 512000 64000
!
! VLAN policy-map; two levels
!
policy-map VLAN_POLICY
class IP_ANY
set dscp 24
service-policy PORT_R1
class MAC_ANY
set dscp ef
service-policy PORT_R3
!
! Attach a switch-wide VLAN policy
!
interface VLAN 1
service-policy input VLAN_POLICY
!
! Enabe VLAN based-QoS on some ports
!
interface range FastEthernet 0/1, FastEthernet 0/3
mls qos vlan-based
Showing posts with label QoS. Show all posts
Showing posts with label QoS. Show all posts
Monday, September 21, 2009
Wednesday, September 02, 2009
Frame relay QoS
MQC_Based Frame relay traffice shaping:
Sample: Shape PVC DLCI 112 to 384Kpbs and enable FRF.12 fragmentation for all PVCs
class-map VOICE
match ip dscp ef
!
class-map DATA
match ip dscp cs1
!
! Match the specific DLCI
!
class-map DLCI_112
match fr-dlci 112
!
! "Child" policy-map, used to implement CBWFQ
!
policy-map CBWFQ
class VOICE
priority 64
class DATA
bandwidth 128
class class-default
fair-queue
!
! "Parent" policy map, used for PVC shaping
! With multiple classes, we can match different DLCIs
! all at the same physical interface (where they belongs)
!
policy-map INTERFACE_POLICY
class DLCI_112
shape average 384000
shape adaptive 192000
service-policy CBWFQ
!
! Apply the parent policy map at physical interface level
! Also, configure FRF.12 "global" settings here
!
interface Serial 0/0/0
service-policy output INTERFACE_POLICY
frame-relay fragment 640 end-to-end
==========================================================
Legacy Frame Relay traffic shaping:
In summary:
- Legacy command frame-relay traffic-shaping is incompatible with MQC-based FRTS (you can’t mix them)
- Fancy queueing could not be used as a PVC-queueing strategy: CBWFQ is the only option available
- Per-VC CBWFQ is configured via hierarchical policy-maps configuration: Parent policy sets shaping values, while child policy implements CBWFQ
- You may apply policy-map per-interface (subinterface) or per-VC, using match fr-dlci under class-map submode
- You can’t apply FRF.12 fragmentation with MQC commands – it should be applied at physical interface level. By doing so, FRF.12 is effectively enabled for all PVCs
- Physical interface queue could be set to any of WFQ/CQ/PQ or CBWFQ (not restricted to FIFO as with FRTS legacy) – though this is rarely needed
Sample: Shape PVC DLCI 112 to 384Kpbs and enable FRF.12 fragmentation for all PVCs
class-map VOICE
match ip dscp ef
!
class-map DATA
match ip dscp cs1
!
! Match the specific DLCI
!
class-map DLCI_112
match fr-dlci 112
!
! "Child" policy-map, used to implement CBWFQ
!
policy-map CBWFQ
class VOICE
priority 64
class DATA
bandwidth 128
class class-default
fair-queue
!
! "Parent" policy map, used for PVC shaping
! With multiple classes, we can match different DLCIs
! all at the same physical interface (where they belongs)
!
policy-map INTERFACE_POLICY
class DLCI_112
shape average 384000
shape adaptive 192000
service-policy CBWFQ
!
! Apply the parent policy map at physical interface level
! Also, configure FRF.12 "global" settings here
!
interface Serial 0/0/0
service-policy output INTERFACE_POLICY
frame-relay fragment 640 end-to-end
==========================================================
Legacy Frame Relay traffic shaping:
- Enabled with frame-relay traffic-shaping command at physical interface level
- Incompatible with GTS or MQC commands at subinterfaces or physical interface levels
- With FRTS you can enforce bitrate per-VC (VC-granular, unlike GTS), by applying a map-class to PVC
- When no map-class is explicitly applied to PVC, it’s CIR and Tc are set to 56K/125ms by default
- Shaping parameters are configured under map-class frame-relay configuration submode
- Allows to configure fancy-queueing (WFQ/PQ/CQ) or simple FIFO per-VC
- No option to configure fancy-queueing at interface level: interface queue is forced to FIFO (if no FRF.12 is configured)
- Allows for adaptive shaping (throttling down to minCIR) on BECN reception (just as GTS) and option to reflect incoming FECNs as BECNs
- Option to enable adaptive shaping which responds to interface congestion (non-empty interface queue)
Tuesday, September 01, 2009
Frame Relay Compression
Stacker vs Predictor
1. Stacker is more CPU intensive.
2. Predictor is more Memory intensive.
Frame relay compression schemes:
1. Data payload compression.
1.1 Cisco proprietary packet-by-packet payload compression. It uses Stacker compression
For a multiple interface use:
frame-relay map ip 10.1.1.1 100 payload-compress packet-by-packet
For P2P interface:
frame-relay payload-compress packet-by-packet.
1.2 FRF.9 uses Stacker. It has better compression ratio than packet by packet.
You should use IETF encapsulation for the pvc that uses FRF.9. Actually when you enable the rfr9 stac keyword, IETF encapsulation is automatically enabled.
For a multiple interface use:
frame-relay map ip 10.1.1.1 100 payload-compress FRF9 stac
For P2P interface:
frame-relay payload-compress FRF9 stac.
2. Packet header compression
2.1 TCP/IP. See RFC 1144
It is important to note that TCP/IP header compression is hop-by-hop compression scheme. The TCP/IP header must be replaced at each node. So it adds latency and CPU load.
And TCP/IP compression requires Cisco proprietary encapsulation.
For physical interface:
frame-relay ip tcp head-compression [passive]
For DLCI
frame-relay map ip 10.1.1.1 100 tcp header-compression [active|passive]
You can also disable it by:
frame-relay map ip 10.1.1.1 100 nocompress
2.2 RTP. See RFC 1889
It is also hop-by-hop compression. And only support Cisco encapsulation
frame-relay ip rtp header-compression [passive]
frame-relay map ip 10.1.1.1 100 rtp header-compression.
frame-relay map ip 10.1.1.1 100 compress (Enabel both tcp and rtp compression).
1. Stacker is more CPU intensive.
2. Predictor is more Memory intensive.
Frame relay compression schemes:
1. Data payload compression.
1.1 Cisco proprietary packet-by-packet payload compression. It uses Stacker compression
For a multiple interface use:
frame-relay map ip 10.1.1.1 100 payload-compress packet-by-packet
For P2P interface:
frame-relay payload-compress packet-by-packet.
1.2 FRF.9 uses Stacker. It has better compression ratio than packet by packet.
You should use IETF encapsulation for the pvc that uses FRF.9. Actually when you enable the rfr9 stac keyword, IETF encapsulation is automatically enabled.
For a multiple interface use:
frame-relay map ip 10.1.1.1 100 payload-compress FRF9 stac
For P2P interface:
frame-relay payload-compress FRF9 stac.
2. Packet header compression
2.1 TCP/IP. See RFC 1144
It is important to note that TCP/IP header compression is hop-by-hop compression scheme. The TCP/IP header must be replaced at each node. So it adds latency and CPU load.
And TCP/IP compression requires Cisco proprietary encapsulation.
For physical interface:
frame-relay ip tcp head-compression [passive]
For DLCI
frame-relay map ip 10.1.1.1 100 tcp header-compression [active|passive]
You can also disable it by:
frame-relay map ip 10.1.1.1 100 nocompress
2.2 RTP. See RFC 1889
It is also hop-by-hop compression. And only support Cisco encapsulation
frame-relay ip rtp header-compression [passive]
frame-relay map ip 10.1.1.1 100 rtp header-compression.
frame-relay map ip 10.1.1.1 100 compress (Enabel both tcp and rtp compression).
Thursday, December 04, 2008
RSVP
RSVP is one way. Typically RSVP is initialize by sender.
Typically, an RSVP-capable application running on an end system host on one side of a router network sends either unicast or multicast RSVP PATH (Set Up) messages to the destination end system or host on the other side of the router network with which it wishes to communicate. The initiating application is referred to as the sender; the target or destination application is called the receiver. In this example, the sender runs on the host upstream from Router A and the receiver runs on the host downstream from Router C. The router network delivers the RSVP PATH messages from the sender to the receiver. The receiver replies with RSVP RESV messages in an attempt to reserve across the network the requested resources that are required between itself and the sender. The RSVP RESV messages specify the parameters for the requisite QoS that the router network connecting the systems should attempt to offer.
In the example, the RSVP PATH messages flow in one direction: downstream from the sender, which in this example is Router A. (If the host were to initiate the RSVP PATH message, the message would flow from the host to Router A.) Router A sends the message downstream to Router B, and Router B sends it downstream to Router C. (If the downstream host were the actual receiver, Router C would send the RSVP PATH message downstream to the receiver host.) Each router in the router network must process the RSVP PATH message and route it to the next downstream hop.
The RSVP RESV messages flow in one direction: upstream from the receiver (in this example, Router C), upstream from Router C to Router B, and upstream from Router B to Router A. If the downstream host were the receiver, the message would originate with the host, which would send it to Router C. If the upstream host were the sender, the final destination of the RSVP RESV message would be the upstream host. At each hop, the router receiving the RSVP RESV message must determine whether it can honor the reservation request.
The ip rsvp bandwidth command both enables RSVP on an interface and specifies the amount of bandwidth on the interface that can be reserved (and the amount of bandwidth that can be allocated to a single flow). To ensure QoS for the RSVP reservation, WFQ is configured on the interfaces enabled for the reservation.
If the router network is capable of offering the specified (QoS) level of service, then an end-to-end reserved path is established. If not, the reservation attempt is rejected and a RESV ERROR message is sent to the receiver. The ability of each router in the network to honor the requested level of service is verified, link by link, as the RSVP RESV messages are sent across the router network to the sender. However, the data itself for which the bandwidth is reserved travels one way only: from the sender to receiver across an established PATH. Therefore, the QoS is effective in only one direction. This is the common case for one-to-many multicast data flows.
Weighted Fair Queuing (WFQ) needs to be enabled for RSVP. Although
WFQ is normally enabled by default on the Serial interfaces (2.048 Mbps and
below), once Frame Relay Traffic Shaping is enabled, WFQ is disabled.
1. Frame Relay
You need to enable the following step
1.1 Enable WFQ
If you do not use frame-relay traffic-shaping, make sure the interface is enabld for WFQ(Default). If you do use traffic-shaping, you need to enable WFQ in the map-class.
It is better to enable traffic shaping because that will be enfore queueing on the Per-VC.
1.2 Configure bandwidth under the both interface and sub-interface.
ip rsvp bandwidth 128(interface-max) 64 (per flow max)
it is important to note that when using subinterfaces that the ip rsvp bandwidth command will need to be applied to the physical along with the subinterface. If more than one subinterface is using RSVP, the physical interface’s ip rsvp bandwidth command will be the sum of all the subinterface’s ip rsvp bandwidth commands.
Example:
interface Serial3/0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay traffic-shaping
ip rsvp bandwidth 500 64 //Interface-max 500=350+150, single flow max = max {subinterfaces}
!
interface Serial3/0.1 point-to-point
ip address 10.1.1.1 255.255.0.0
frame-relay interface-dlci 101
class fr-voip
ip rsvp bandwidth 350 64
!
interface Serial3/0.2 point-to-point
ip address 10.3.1.1 255.255.0.0
frame-relay interface-dlci 201
class fast-vcs
ip rsvp bandwidth 150 32
!
map-class frame-relay fr-voip
frame-relay cir 800000
frame-relay bc 8000
frame-relay mincir 128000
frame-relay fragment 280 //option
no frame-relay adaptive-shaping
frame-relay fair-queue //Enable WFQ
!
map-class frame-relay fast-vcs
frame-relay cir 200000
frame-relay bc 2000
frame-relay mincir 60000
frame-relay fragment 280
no frame-relay adaptive-shaping
frame-relay fair-queue //Enable WFQ
Rack1R5#show frame-relay pvc 101
PVC Statistics for interface Serial1/0 (Frame Relay DTE)
DLCI = 504, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0.1
Typically, an RSVP-capable application running on an end system host on one side of a router network sends either unicast or multicast RSVP PATH (Set Up) messages to the destination end system or host on the other side of the router network with which it wishes to communicate. The initiating application is referred to as the sender; the target or destination application is called the receiver. In this example, the sender runs on the host upstream from Router A and the receiver runs on the host downstream from Router C. The router network delivers the RSVP PATH messages from the sender to the receiver. The receiver replies with RSVP RESV messages in an attempt to reserve across the network the requested resources that are required between itself and the sender. The RSVP RESV messages specify the parameters for the requisite QoS that the router network connecting the systems should attempt to offer.
In the example, the RSVP PATH messages flow in one direction: downstream from the sender, which in this example is Router A. (If the host were to initiate the RSVP PATH message, the message would flow from the host to Router A.) Router A sends the message downstream to Router B, and Router B sends it downstream to Router C. (If the downstream host were the actual receiver, Router C would send the RSVP PATH message downstream to the receiver host.) Each router in the router network must process the RSVP PATH message and route it to the next downstream hop.
The RSVP RESV messages flow in one direction: upstream from the receiver (in this example, Router C), upstream from Router C to Router B, and upstream from Router B to Router A. If the downstream host were the receiver, the message would originate with the host, which would send it to Router C. If the upstream host were the sender, the final destination of the RSVP RESV message would be the upstream host. At each hop, the router receiving the RSVP RESV message must determine whether it can honor the reservation request.
The ip rsvp bandwidth command both enables RSVP on an interface and specifies the amount of bandwidth on the interface that can be reserved (and the amount of bandwidth that can be allocated to a single flow). To ensure QoS for the RSVP reservation, WFQ is configured on the interfaces enabled for the reservation.
If the router network is capable of offering the specified (QoS) level of service, then an end-to-end reserved path is established. If not, the reservation attempt is rejected and a RESV ERROR message is sent to the receiver. The ability of each router in the network to honor the requested level of service is verified, link by link, as the RSVP RESV messages are sent across the router network to the sender. However, the data itself for which the bandwidth is reserved travels one way only: from the sender to receiver across an established PATH. Therefore, the QoS is effective in only one direction. This is the common case for one-to-many multicast data flows.
Weighted Fair Queuing (WFQ) needs to be enabled for RSVP. Although
WFQ is normally enabled by default on the Serial interfaces (2.048 Mbps and
below), once Frame Relay Traffic Shaping is enabled, WFQ is disabled.
1. Frame Relay
You need to enable the following step
1.1 Enable WFQ
If you do not use frame-relay traffic-shaping, make sure the interface is enabld for WFQ(Default). If you do use traffic-shaping, you need to enable WFQ in the map-class.
It is better to enable traffic shaping because that will be enfore queueing on the Per-VC.
1.2 Configure bandwidth under the both interface and sub-interface.
ip rsvp bandwidth 128(interface-max) 64 (per flow max)
it is important to note that when using subinterfaces that the ip rsvp bandwidth command will need to be applied to the physical along with the subinterface. If more than one subinterface is using RSVP, the physical interface’s ip rsvp bandwidth command will be the sum of all the subinterface’s ip rsvp bandwidth commands.
Example:
interface Serial3/0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay traffic-shaping
ip rsvp bandwidth 500 64 //Interface-max 500=350+150, single flow max = max {subinterfaces}
!
interface Serial3/0.1 point-to-point
ip address 10.1.1.1 255.255.0.0
frame-relay interface-dlci 101
class fr-voip
ip rsvp bandwidth 350 64
!
interface Serial3/0.2 point-to-point
ip address 10.3.1.1 255.255.0.0
frame-relay interface-dlci 201
class fast-vcs
ip rsvp bandwidth 150 32
!
map-class frame-relay fr-voip
frame-relay cir 800000
frame-relay bc 8000
frame-relay mincir 128000
frame-relay fragment 280 //option
no frame-relay adaptive-shaping
frame-relay fair-queue //Enable WFQ
!
map-class frame-relay fast-vcs
frame-relay cir 200000
frame-relay bc 2000
frame-relay mincir 60000
frame-relay fragment 280
no frame-relay adaptive-shaping
frame-relay fair-queue //Enable WFQ
Rack1R5#show frame-relay pvc 101
PVC Statistics for interface Serial1/0 (Frame Relay DTE)
DLCI = 504, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0.1
Friday, November 28, 2008
RTP classification
Quote from Cisco.
Why nBAR RTP Payload Classification
While placing voice and video on a network, adequate bandwidth must exist to meet the service needs of these applications. Classification and Marking of the traffic should be performed as close to the edge of the network as possible. The marked DSCP values can then classify, condition, and define the per-hop behavior of each traffic class of traffic within the Diffserv domain.
Cisco IOS Software currently offers many methods for the classification of voice and video traffic. The advantages and disadvantages of each feature are listed below.
1. Match ip rtp
This command matches IP RTP packets that fall within the specified UDP port range. The "match ip rtp" feature matches UDP packets destined to all even port numbers within the specified range. Its limitation is that it will match any UDP packet using an even port number that falls within the range configured. There is a risk that another application could use UDP ports that fall in the same range, as specified by the "match ip rtp" match criteria. This application traffic will now be queued in the Low Latency queue with the delay sensitive voice traffic, and might hamper the quality of voice calls. It is therefore very useful to have a classification engine that can classify applications above the port number criteria.
Notes: To match udp range from 16374 - 16574, use command "match ip rtp 16374 200"
2. Ip dscp and ip precedence
Various applications and end devices (ie: IP Phones and Polycom Video units) can set their DSCP values. The router can now use this specific DSCP, or Precedence, value as classification criteria for voice and video streams. However, a danger does always exist, because another end user or application could, deliberately or accidentally, mark their packets with the same DSCP or Precedence value.
3. Access lists
Access lists can classify RTP packets, based on source or destination IP addresses, and UDP port number range but do not provide a granular way to classify RTP streams. Again, there is a risk of another application inadvertently matching the access-list criteria for identification of voice and video traffic, resulting in potential theft of service for these service classes. Also, access-lists do not provide classification statistics that are available with nBAR. nBAR thus provides more granular and application-specific matching criteria than access lists.
Notes: To match udp range from 16374 - 16574, use command "ip access-list 110 permit udp any any range 16374 16574".
4. nBAR RTP Payload Classification
This feature expands the RTP traffic-matching capabilities of an nBAR-enabled router by looking deeper into the RTP header to check for RTP specific parameters instead of relying on even UDP port numbers alone
This feature also addresses the challenge of distinguishing RTP packets from different applications based on their payload types or CODECS. The space for payload types is limited, so only very common encodings are assigned static types. These are typically audio and video encodings that have been "blessed" by international standardization bodies, such as the G. series of ITU-T audio encodings (see Table 1). Dynamic payload types map an RTP payload type to an audio and video encoding for the duration of a session. Different members of a session could use different mappings if needed. As shown in the above table, Dynamic payload types use the PT range 96-127.
There are multiple encodings defined by the A/V profile that use dynamic payload types, including GSM-HR, RED, VDVI, L8, MP2P and BMPEG Codecs. nBAR RTP Payload type classification provides a powerful means of classifying the applications based on their static or dynamic payload type.
Why nBAR RTP Payload Classification
While placing voice and video on a network, adequate bandwidth must exist to meet the service needs of these applications. Classification and Marking of the traffic should be performed as close to the edge of the network as possible. The marked DSCP values can then classify, condition, and define the per-hop behavior of each traffic class of traffic within the Diffserv domain.
Cisco IOS Software currently offers many methods for the classification of voice and video traffic. The advantages and disadvantages of each feature are listed below.
1. Match ip rtp
This command matches IP RTP packets that fall within the specified UDP port range. The "match ip rtp" feature matches UDP packets destined to all even port numbers within the specified range. Its limitation is that it will match any UDP packet using an even port number that falls within the range configured. There is a risk that another application could use UDP ports that fall in the same range, as specified by the "match ip rtp" match criteria. This application traffic will now be queued in the Low Latency queue with the delay sensitive voice traffic, and might hamper the quality of voice calls. It is therefore very useful to have a classification engine that can classify applications above the port number criteria.
Notes: To match udp range from 16374 - 16574, use command "match ip rtp 16374 200"
2. Ip dscp and ip precedence
Various applications and end devices (ie: IP Phones and Polycom Video units) can set their DSCP values. The router can now use this specific DSCP, or Precedence, value as classification criteria for voice and video streams. However, a danger does always exist, because another end user or application could, deliberately or accidentally, mark their packets with the same DSCP or Precedence value.
3. Access lists
Access lists can classify RTP packets, based on source or destination IP addresses, and UDP port number range but do not provide a granular way to classify RTP streams. Again, there is a risk of another application inadvertently matching the access-list criteria for identification of voice and video traffic, resulting in potential theft of service for these service classes. Also, access-lists do not provide classification statistics that are available with nBAR. nBAR thus provides more granular and application-specific matching criteria than access lists.
Notes: To match udp range from 16374 - 16574, use command "ip access-list 110 permit udp any any range 16374 16574".
4. nBAR RTP Payload Classification
This feature expands the RTP traffic-matching capabilities of an nBAR-enabled router by looking deeper into the RTP header to check for RTP specific parameters instead of relying on even UDP port numbers alone
This feature also addresses the challenge of distinguishing RTP packets from different applications based on their payload types or CODECS. The space for payload types is limited, so only very common encodings are assigned static types. These are typically audio and video encodings that have been "blessed" by international standardization bodies, such as the G. series of ITU-T audio encodings (see Table 1). Dynamic payload types map an RTP payload type to an audio and video encoding for the duration of a session. Different members of a session could use different mappings if needed. As shown in the above table, Dynamic payload types use the PT range 96-127.
There are multiple encodings defined by the A/V profile that use dynamic payload types, including GSM-HR, RED, VDVI, L8, MP2P and BMPEG Codecs. nBAR RTP Payload type classification provides a powerful means of classifying the applications based on their static or dynamic payload type.
Subscribe to:
Posts (Atom)