The source code for this example is released with your software in the following locations:
- C source code:
- DDL source:
The Policy Manager sample application consists of two daemons on the Routing Engine (RE): the Policy Enforcement Daemon (PED) enforces policies on inet interfaces, and the Policy Server Daemon (PSD) provides a policy to each configured interface. Two additional daemons run on the MultiServices PIC: the Packet Filtering Daemon (PFD) processes data, and the Captive Portal Daemon (CPD), a simple HTTP server, functions as the control component with respect to the PFD.
- ODL source:
This sample application includes code for the following SDK functionality:
- Handling events, using the eventlib API in libisc2 (a library provided by the Internet Software Consortium). Events are used with sockets to provide asynchronous communication services.
- Using Kernel Communication (KCOM) in libjunos-sdk to listen for protocol family changes on interfaces
- Tracing and logging using the
- Using libjipc for inter-process communication to and from the PSD
In addition to enforcing policies, the Policy Enforcement Daemon (PED) also acts as the management component for the CPD, and PFD running on the MultiServices PIC.
The Policy Server Daemon (PSD) provides a policy to each configured interface. The policy consists of an input and output (inet) firewall filter name and a set of routes. You configure the interfaces before running the application; details appear in Configuring the Application.
- Writing control and data applications with the MP SDK, which use libconn and libmp-sdk for PIC-to-PIC and Routing Engine-to-PIC communications (for details about the control and data components of an MP SDK application, see Functionality in the Services SDK; for details about libconn, see libconn-section.)
The daemon listens for requests on the Routing Engine through the internal routing instance, IRI2 (it binds to 0.0.0.0) on port 7077 (chosen to avoid conflict with existing Juniper daemons). It accepts connection requests from PED-style clients; however, only one instance of the PED is intended. The daemon also processes the client's messages and replies to them.
The PFD is an MP SDK data application responsible for controlling which subscribers (end users) behind a PED-managed interface are allowed to have their packets routed. The case when the traffic is disallowed is handled by redirecting traffic to the captive portal (the CPD).
The application filters packets based on the source IP address and the destination port number. Specifically, it filters rom all source IP addresses coming in with a destination port of 80, the HTTP port.
The CPD is, in essence, just a very simple HTTP server. It is a control (or server-style) MP SDK application.
Unauthorized users have an opportunity to "authenticate." However, no real authentication is performed. A subscriber simply has the option of clicking a button on a web page to authorize traffic and another button to revoke the authorization.
The list of authorized users is updated based on these actions. This list is kept in memory and not preserved, although future versions could place it in persistent storage using GENCFG blobs (for more information about GENCFG, see Using the GENCFG/SSRB Library.)
The PED acts as the intermediary between the PFD and the CPD. When it discovers the connections for both the PFD and the CPD, it sends the CPD's internal server interface information to the PFD. The PFD can then connect directly to the CPD and receive CPD information through that channel.
The PED sends both the PFD and the CPD the configured PFD and CPD addresses. Whenever one of these configured addresses changes, the PED re-sends the addresses over the same channel to both the PFD and CPD.
The following figure shows how the 3 daemons communicate through the internal routing instance and API libraries:
The PED includes a SNMP sub-agency to support SNMP queries and traps. (The RE SDK SNMP library does not support the SNMP set operation.)
Communication Among Daemons
The PED SNMP MIB contains:
Total number of interfaces
Number of managed interfaces
Interface address family
Number of routes
Input filter name
Output filter name
PSD connection up time
PED-PSD connection up/down
Configuring the Application
© 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