| Oracle® Communications IP Service Activator Juniper M-series Device Support Guide Release 7.2 E47718-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications IP Service Activator Juniper M-series Device Support Guide Release 7.2 E47718-01 |
|
|
PDF · Mobi · ePub |
This chapter provides detailed information on the Quality of Service (QoS) and access control features configured by Oracle Communications IP Service Activator.
This section describes the key features of the Juniper QoS.
The Flexible PIC Concentrator (FPC) is a card that slots into the router. FPCs connect the Physical Interface Cards (PICs) to the rest of the router so that incoming packets are forwarded across the midplane to the appropriate destination port. Each FPC holds up to a maximum number of four PICs.
This structure is shown in Figure 7-1.
This hardware feature is reflected in the commands that are used to configure the device so that some commands are applied on a per-FPC basis.
For detailed information about the FPC consult the appropriate M-series Hardware guide.
Figure 7-2 illustrates the packet flow through the router.
On ingress, the inbound packet is classified and policers and firewall filters may be run to amend the forwarding class and the loss priority. Firewall filters may also direct the forwarding of the packet to an alternative routing instance or interface.
On egress, firewall filters and policers may again be run to modify the forwarding class and the loss priority. The outbound packet is queued according to the forwarding class and scheduling/dropping is applied.
For detailed information on Juniper QoS features, see the JUNOS Software Class of Service Configuration Guide and the JUNOS Software Network Interfaces Configuration Guide, available on the Juniper Networks Technical Documentation Web site:
A firewall filter classifies packets based on their content and may subsequently perform some action on the classified packets. Each filter comprises one or more filter terms. Each term consists of one or more conditions that define the filtering criteria and the action to take if a match occurs. The ordering of terms within the filter is significant. Packets are tested against each term until a match is found and the associated action is taken. If a packet does not match any of the filter conditions it is silently discarded. It is possible to define a large number of filters without affecting the speed of the interface.
Firewall filters can be applied to inbound or outbound traffic to restrict the packets passing in to or out of the device. Filters can be applied to one, more than one or all interfaces and the same filter can be applied to multiple interfaces.
Filtering is performed within the hardware by the Internet Processor II ASIC. This ASIC is standard on M5, M10, M20, M40 and M160 routers. It can be installed as an upgrade to early versions of M20 and M40 devices which do not have this ASIC.
Filter match conditions may be based on:
Numeric range: such as source or destination port number or IP precedence value
Addresses: source or destination IP address
Bit field values: matches can be made on IP options, TCP flags, and IP fragmentation fields
Firewall filters are used by IP Service Activator to implement access rules and rate limiting and to classify traffic for WRR.
The command to configure a firewall filter is made at the [edit firewall family inet] hierarchy level:
filter filter-name { term term-name { from { match-conditions; } then { action; } } }
where filter-name is the name of the filter, term-name is the name of the filter term, match-conditions is the condition that the incoming packets must match for the action to be applied, and action is the steps to take for packets that match the filter condition.
Firewall filters are applied to an interface by including the filter statement at the [edit interfaces interface-name unit logical-unit-number family inet] hierarchy level:
interfaces {
interface-name {
unit logical-unit-number {
family inet {
filter {
input filter-name;
output filter-name;
}
}
}
}
}
where interface-name is the name of the interface, logical-unit-number is the number of the logical interface, and filter-name is the name of the filter to be applied.
For more information see the JUNOS Software Class of Service Configuration Guide and the JUNOS Software Network Interfaces Configuration Guide, available on the Juniper Networks Technical Documentation Web site:
On Juniper devices, traffic is classified and enqueued on input to the device. For IP traffic, Juniper devices map incoming traffic to output transmission queues according to the value of the packet header's IP precedence bits or DiffServ codepoint setting. By default, packets are placed in queue 0 with the exception of routing protocol traffic which is placed in queue 3. In IP Service Activator, mapping of an IP precedence bit value to an output queue is indirectly configured when you apply a WRR PHB group.
In IP Service Activator, access rules are used to permit and deny access to identified traffic on a particular interface.
Access rules are implemented on Juniper devices by firewall filters. Each access rule translates directly to a filter that comprises a single filter term. If an access rule applies to both inbound and outbound traffic, two filters are generated. The generated filters are referenced in the configuration for the interfaces affected by the access rule. Access rules can be applied inbound and outbound.
For firewall filter syntax details, see "Firewall Filters".
The filter name is generated automatically and is in the following format:
InFilter|OutFilter--interface_name
where interface_name is the name of the interface.
The filter term name is generated automatically and is in the following format:
OrchFilterTerm--rule_id
where rule_id is the object ID of the rule allocated by IP Service Activator.
When access rules are implemented, as well as the specific permit or deny filters, additional filter terms are added to explicitly permit SNMP, Telnet and SSH traffic both inbound and outbound between the device and the device driver. These terms are always added at the start of the list, and minimize the chance of locking out network control traffic inadvertently.
Note:
Starting with version 4.0, IP Service Activator no longer configures an explicit accept term to allow any IP traffic not directly matched. The Juniper implicit discard action denies traffic that does not match any of the preceding terms.Be aware that, depending on your network architecture and use of management interfaces, you may need to appropriately add accept any access rules to avoid being locked out of your devices. One approach is to add an accept access rule to devices which is then inherited by the devices' interfaces used for management connectivity.
Access rules may be applied to traffic identified by any of the following methods:
Source and/or destination IP address
Source and/or destination port number
TCP control bits
IP protocol
IP precedence value/DiffServ codepoint
Note:
Rate limiting (see "Rate Limiting") and WRR classification (see "Weighted Round Robin Queuing Mechanism") are also implemented by firewall filters. If more than one feature is implemented on one interface, terms are automatically ordered so that they have the expected behavior. The order in which they are evaluated is WRR classification terms, followed by rate limiting terms followed by access rule terms.In addition, header logging is supported in access rules by the log command.
Header logging is enabled in the Access Rule property page of the Access Rule dialog box.
The configuration sent to the device if header logging is enabled is:
filter name { term term-name { from { other-ACL-options; } then { log; {accept|discard}; } } }
On Juniper devices, the tcp-established keyword is used only when established is the only option used.
If other control bits of the TCP header are selected in the access rule, the CLI line is:
tcp-flags other-TCP-control-bits & (ack|rst)
This is because tcp-established is an alias for tcp-flags ack|rst and tcp-flags commands cannot be repeated in the same filter term.
If TCP options are enabled, the configuration has the following format:
filter name { term term-name { from { other-ACL-options; [tcp-established;] | [tcp-flags boolean-combinations-of-urgent|ack|push|rst|syn|fin;] } then { [log;] {accept|discard}; } } }
This example shows an access rule that has been applied to an access interface with the following configuration:
Action: Permit
Direction: In
Traffic Type: aol-3-c
Source: Subnet 10.50.0.5
Destination: 10.50.0.6
The resulting configuration of the access router is as follows:
groups {
orchestream {
firewall {
family inet {
filter InFilter--fe-0-1-3-0 {
term OrchFilterTerm--3932 {
from {
protocol 6;
source-port 5193;
source-address 10.50.0.5/32;
destination-address 10.50.0.6/32;
}
then {
accept;
}
}
}
}
}
}
interfaces {
fe-0/1/3 {
unit 0 {
family inet {
filter {
input InFilter--fe-0-1-3-0;
}
}
}
}
}
}
}
Rate limiting enables you to limit the amount of traffic passing in to or out of an interface. It can be used to control access to the core network by constraining specific outbound traffic to a particular bandwidth. Rate limiting is implemented on Juniper routers by a specialized firewall filter.
Rate limiting allows a certain amount of busy traffic before it starts discarding packets. It applies the following rate limits to traffic that enters an interface:
Bandwidth: the number of permitted bits per second
Maximum burst size: the maximum burst size, defined in bytes, for traffic that exceeds the maximum bandwidth
Rate limiting is set up within PHB groups.
Rate limiting cannot be applied to MPLS traffic.
Rate limiting can only be applied to routers that have the Internet Processor II ASIC.
Rate limiting is implemented on Juniper devices by a specialized firewall filter. The filter features a policer that filters traffic based on bandwidth and burst size limits and specifies the action to take for traffic exceeding those conditions. Rate limiting is always applied to the outbound interface.
The Juniper command to define a policer is:
policer policer_name { if-exceeding { bandwidth-limit rate; burst-size-limit bytes; } then { discard; } }
where rate is the maximum burst rate in bits per second and bytes is the maximum number of bytes to be transmitted in bytes per second.
For information on general firewall filter syntax, see "Firewall Filters".
Traffic within a particular class of service is identified by IP precedence bit.
Values input to the client are as follows:
Average rate: the average transmission rate in Kbits per second for the class of service
Burst rate: the burst rate in Kbits per second for the class of service
Burst interval: the interval, in seconds, over which traffic in the selected class of service is allowed to maintain its maximum burst rate
The values required for the rate limiting policer statement are:
Bandwidth limit: the average number of bits permitted per second
Burst size limit: the total number of bytes per second in excess of the bandwidth limit allowed in a burst
JUNOS devices calculate burst based on the maximum number of bytes permitted in the burst, rather than the duration of the burst. The Juniper device driver calculates the required values from those input through the client as follows:
Bandwidth limit (in Kbits per second) = average rate
Burst size limit (in Kbytes per second) = (burst rate - average rate) * burst interval / 8
Note:
Burst rate and average rate must be set to different values.This example shows a PHB group that has been configured from the client with the details listed in Table 7-1.
Table 7-1 Example Configuration Details
| Class of Service | Average | Burst Rate | Interval |
|---|---|---|---|
|
Gold (5) |
4000 |
4500 |
10 |
|
Silver (3) |
3000 |
3500 |
10 |
|
Bronze (0) |
2000 |
2500 |
10 |
The resulting configuration is as follows:
groups {
orchestream {
firewall {
family inet {
filter OutFilter--fe-0-1-3-0 {
policer policer1 {
if-exceeding {
bandwidth-limit 2000000;
burst-size-limit 625;
}
then {
discard;
}
}
policer policer2 {
if-exceeding {
bandwidth-limit 3000000;
burst-size-limit 625;
}
then {
discard;
}
}
policer policer3 {
if-exceeding {
bandwidth-limit 4000000;
burst-size-limit 625;
}
then {
discard;
}
}
term OrchFilterTerm--policer1 {
from {
dscp af33;
}
then {
policer policer1;
accept;
}
}
term OrchFilterTerm--policer2 {
from {
precedence critical-ecp;
}
then {
policer policer2;
accept;
}
}
term OrchFilterTerm--policer3 {
from {
precedence internet-control;
}
then {
policer policer3;
accept;
}
}
}
}
intrfaces {
fe-0/1/3 {
unit 0 {
family inet {
filter {
output OutFilter--fe-0-1-3-0;
}
}
}
}
}
}
}
Weighted Round Robin (WRR) allows you to specify the percentage of bandwidth allocated to each queue. A greater number of packets is dequeued from a queue with a higher bandwidth percentage than one with a lower percentage whenever the queue is serviced.
Weights are assigned per queue for each interface within an FPC. Up to four transmission queues can be configured for each output link. The weight is defined as a percentage of the total link transmission bandwidth.
Only queues containing packets are serviced according to the configured weighting; empty queues are not serviced. This means that a congested queue can borrow buffer space and bandwidth from an under-utilized queue.
It is also possible to configure the memory allocation used by each queue on an interface.
WRR is implemented within IP Service Activator by PHB groups.
For information on traffic classification and allocation of output queues on Juniper devices see "Classification of Packets and Queue Selection".
Juniper implements WRR as follows:
Firewall filters are used to map the traffic to the appropriate forwarding classes
Scheduling policy maps are used to configure the forwarding classes that represent packet queues and associate them with physical interfaces.
WRR is always applied to outbound traffic.
An outbound firewall filter is used to apply the default mapping from IP precedence to forwarding class.
The format and syntax of the firewall filter command is as described in "Firewall Filters".
A scheduler configuration block is used to specify the bandwidth for a queue. The following Juniper command is configured by IP Service Activator at the [edit class-of-service] hierarchy level:
schedulers {
scheduler-name {
transmit-rate percent percentage;
}
}
where scheduler-name is the name allocated by IP Service Activator in the form Orch-Scheduler-interface_name and percentage is the calculated percentage of bandwidth to be allocated to the queue.
The following command is used to map a specified forwarding class to a scheduler configuration:
scheduler-maps {
map-name {
forwarding-class class-name scheduler scheduler-name;
}
}
where map-name is the name allocated by IP Service Activator in the form Orch-Scheduler-Map-interface_name, class-name is the name of the forwarding class (best-effort, expedited-forwarding, assured-forwarding, or network-control), and scheduler-name is the name of the associated scheduler.
The scheduler map is then associated with an output interface as follows:
interfaces {
interface-name {
scheduler-map map-name;
}
}
Traffic within a particular class of service is identified by the value of the IP precedence bits in the packet header or the experimental bits in the MPLS label.
WRR is implemented in IP Service Activator by means of a PHB group, as shown in Figure 7-5.
Figure 7-5 Implementing WRR with a PHB Group
For each class of service, a value can be specified in the weight field, which is converted to a percentage of the available bandwidth. The Packet limit value is not used and any value specified is ignored.
The device driver interprets each value as a ratio from which it calculates the bandwidth percentage. Each percentage value is rounded down to the nearest whole number. For example, if the weights allocated are 3, 6, 10, 1, the driver allocates the following bandwidth percentages: 15%, 30%, 50% and 5%. If the percentage values add up to less than 100% any excess bandwidth is distributed across all queues.
Note:
Oracle recommends that routing protocol traffic (IP Precedence 6 and 7 or DiffServ codepoints 48 and 56) is always allocated at least 5% of the available bandwidth.By default, IP traffic is placed in output transmission queue 0 and network control traffic in queue 3. Queue 0 is assigned 95% of the bandwidth, queue 3 is assigned 5%. If a WRR PHB group is not applied to an interface, this default configuration applies.To support the application of WRR PHBs, IP Service Activator includes a juniper.policy file that contains an example Juniper MPLS PHB Group-WRR. This PHB Group lets you define WRR schedulers for four classes of service:
Juniper-MPLS-best-effort (uses packet marking precedence [0, 1])
Juniper-MPLS-expedited-forwarding (uses packet marking precedence [2, 3])
Juniper-MPLS-assured-forwarding (uses packet marking precedence [4, 5])
Juniper-MPLS-network-control (uses packet marking precedence [6, 7])
The WRR schedulers are applied at the outbound (transmit) direction of the interface and assigned a percentage of interface bandwidth according to configured relative weights. The packet filters of the example Juniper MPLS PHB Group-WRR are implemented as firewall filters and use IP Precedence packet marking to assign packets to one of the 4 forwarding classes:
precedence [0, 1] (mapped to forwarding-class best-effort)
precedence [2, 3] (mapped to forwarding-class expedited-forwarding)
precedence [4, 5] (mapped to forwarding-class assured-forwarding)
precedence [6, 7] (mapped to forwarding-class network-control)
A limitation of the example Juniper MPLS PHB Group-WRR is that exactly four classes of service as defined in the juniper.policy file must be used and these CoSs cannot be modified. Also, the Default CoS visible in the client is ignored by the device driver and can be safely de-selected.
This example shows the example Juniper MPLS PHB Group-WRR configured from the client with the parameters listed in Table 7-2.
Table 7-2 Example Configuration Parameters
| Class of Service | Equivalent Packet Marking | Weight |
|---|---|---|
|
Juniper-MPLS-best-effort |
IP Precedence 0 and 1 |
25 |
|
Juniper-MPLS-expedited-forwarding |
IP Precedence 2 and 3 |
40 |
|
Juniper-MPLS-assured-forwarding |
IP Precedence 4 and 5 |
30 |
|
Juniper-MPLS-network-control |
IP Precedence 6 and 7 |
5 |
The resulting router configuration is:
orchestream {
interfaces {
ge-1/0/0 {
unit 1 {
family inet {
filter {
output OutFilter-ge-1-0-0-1;
}
}
}
class-of-service {
interfaces {
ge-1/0/0 {
scheduler-map Orch-Scheduler-Map-ge-1-0-0;
}
}
scheduler-maps {
Orch-Scheduler-Map-ge-1-0-0 {
forwarding-class best-effort scheduler Orch-Scheduler-ge-1-0-0-be;
forwarding-class expedited-forwarding scheduler Orch-Scheduler-ge-1-0-0-ef;
forwarding-class assured-forwarding scheduler Orch-Scheduler-ge-1-0-0-af;
forwarding-class network-control scheduler Orch-Scheduler-ge-1-0-0-nc;
}
}
schedulers {
Orch-Scheduler-ge-1-0-0-be {
transmit-rate percent 25;
}
Orch-Scheduler-ge-1-0-0-ef {
transmit-rate percent 40;
}
Orch-Scheduler-ge-1-0-0-af {
transmit-rate percent 30;
}
Orch-Scheduler-ge-1-0-0-nc {
transmit-rate percent 5;
}
}
}
firewall {
family inet {
filter OutFilter-ge-1-0-0-1 {
term OrchFilter-term-classifier-0 {
from {
precedence [ 0 1 ];
}
then {
forwarding-class best-effort;
next term;
}
}
term OrchFilter-term-classifier-1 {
from {
precedence [ 2 3 ];
}
then {
forwarding-class expedited-forwarding;
next term;
}
}
term OrchFilter-term-classifier-2 {
from {
precedence [ 4 5 ];
}
then {
forwarding-class assured-forwarding;
next term;
}
}
term OrchFilter-term-classifier-3 {
from {
precedence [ 6 7 ];
}
then forwarding-class network-control;
}
}
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|