System Configuration for the Dynamic Policy Manager Application

The applications's extensions to the JUNOS configuration hierarchy are organized into a new dpm hierarchy under the sync object as follows:.

 1 dpm {
 2     policer <pname> {
 3         if-exceeding {
 4             bandwidth-limit <x>;
 5             bandwidth-percent <x>;
 6             burst-size-limit <x>;
 7         }
 8         then {
 9             discard;
10             forward-class <x>;
11             loss-priority <x>;
12         }
13     }
14     ...
15     interface-defaults {
16         ifl-pattern {
17             input-policer <pname>;
18             output-policer <pname>;
19         }
20         ...
21     }
22     subscriber-database {
23         class <cname> {
24             policer <pname>;
25             subscriber <sname> {
26                 password <pw>;
27             }
28             ...
29         }
30         ...
31     }
32     use-classic-filters;  ## hidden
33 }

The policer object that is configured on Line 2 is similar to what one would be able to define under the JUNOS firewall's policer object. The configuration allowed here in the system is a subset of what the JUNOS policer allows. All the objects and attributes defined in this object define characteristics similar to those of the JUNOS policer; thus, we do not repeat their explanation here.

Line 14 indicates (using three periods) that there can be multiple objects like this. It is possible to define a list of policers as long as they have different

identifying attributes as shown on line 2.

Line 15 defines the interface-defaults object, which contains the configuration for the default policies applied to interfaces.

Line 16 defines the ifl-pattern object. Using the pattern given in the object's name, the application can match against all IFL interface names. It can then apply input and output filters for the matching IFL interfaces, with a corresponding policer action of either the input-policier or output-policer attributes from lines 17 or 18.

Line 20 again indicates that there may be multiple unique ifl-pattern objects.

Line 22 defines the subscriber-database object. This object contains the configuration for the dynamic policies applied to or removed from interfaces for subscribers as they log in or out using the system's web-interface portal.

Inside the subscriber-database object, you define multiple classes to group and categorize subscribers. Each class is defined by a class object as shown on line 23, and has a unique name. Each class also has a policer attribute, as shown on line 24. The policer is applied to or removed from the subscriber's traffic dynamically as the subscriber logs in or out. This is done through the creation of another term that matches the subscriber's traffic with this policer as the term's action. ( For more information on this process, see Applying Dynamic Policers.)

Each class defines multiple subscribers by specifying the usernames and passwords in a list, as shown on lines 25 and 26. A subscriber with a unique identifier should only be defined in one class.

Line 32 defines a use-classic-filters attribute. If this (normally hidden) toggle attribute is present in the configuration, the system uses classic implicit filters instead of the default fast-update implicit filters to manage the policies. This does not change the functionality of the system, but it changes how the behavior is achieved. It is included here to demonstrate the use of both kinds of filters.

Currently, the system always uses classic filters regardless of this setting, because fast-update filters are only supported for JUNOS internal use. Should this change, the fast-update filters would be the natural (and hence the default) choice because the terms are evaluated based on priority instead of sequentially; this facilitates the implementation by allowing two levels of policy priorities (for subscribers and for interface defaults). It should also provide enhanced performance.

Sample Configuration

This sample scenario classifies subscribers into two categories. The subscriber gets the bandwidth for their class when they sign in.

Without logging in, all subscribers are presumed to connect through an interface matching one of the patterns in the interface-defaults section; they will have the default dead-slow policer applied to their traffic.

This sample also shows the configuration for enabling system tracing, which is normally only done for debugging purposes and is shown here because it is a new addition to the configuration possibilities.

chassis {
    fpc 1 {
        pic 2 {
            adaptive-services {
                service-package {
                    extension-provider {
                        control-cores 4;
                        object-cache-size 128;
                        forwarding-database-size 127;
                        package sync-dpm-ctrl;
                    }
                }
            }
        }
    }
}
interfaces {
    ms-1/2/0 {
        unit 0 {
            family inet {
                address 30.30.20.20/32;
            }
        }
    }
}
sync {
    dpm {
        policer dead-slow {
            if-exceeding {
                bandwidth-limit 64000;
                burst-size-limit 2000;
            }
            then discard;
        }
        policer medium-speed {
            if-exceeding {
                bandwidth-limit 1000000;
                burst-size-limit 50000;
            }
            then loss-priority high;
        }
        policer high-speed {
            if-exceeding {
                bandwidth-limit 6000000;
                burst-size-limit 100000;
            }
            then loss-priority high;
        }
        interface-defaults {
            fe-1/2* {
                input-policer dead-slow;
                output-policer dead-slow;
            }
            fe-0/1/0* {
                input-policer dead-slow;
                output-policer dead-slow;
            }
            fe-0/1/1.0 {
                input-policer dead-slow;
                output-policer dead-slow;
            }
        }
        subscriber-database {
            class silver {
                policer medium-speed;
                subscriber barb {
                    password abc123;
                }
                subscriber steve {
                    password mnlop;
                }
            }
            class gold {
                policer high-speed;
                subscriber sara {
                    password 543210;
                }
                subscriber mike {
                    password xyzabc;
                }
            }

        }
    }
    traceoptions {                 ## only used for debugging purposes
            file dpm.trace;
            flag all;
            syslog;
        }
    }
}

Initializing the Dynamic Firewall Filter Functionality


2007-2009 Juniper Networks, Inc. All rights reserved. The information contained herein is confidential information of Juniper Networks, Inc., and may not be used, disclosed, distributed, modified, or copied without the prior written consent of Juniper Networks, Inc. in an express license. This information is subject to change by Juniper Networks, Inc. Juniper Networks, the Juniper Networks logo, and JUNOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Generated on Sun May 30 20:26:47 2010 for Juniper Networks Partner Solution Development Platform JUNOS SDK 10.2R1 by Doxygen 1.4.5