[Contents]
[Prev]
[Next]
[Index]
[Report an Error]
Configuring the SRC Client
The JUNOSe software has an embedded client that
interacts with the Juniper Networks SRC software, enabling the SRC
software to manage the router’s policy and QoS configuration.
The connection between the router and the SRC software
uses the Common Open Policy Service (COPS) protocol and is fully compliant
with the COPS usage for policy provisioning (COPS-PR) specification.
The router’s SRC client functions as the COPS client, or policy
enforcement point (PEP). The SRC software functions as the COPS server,
or policy decision point (PDP).
Table 10 provides common
terms used in the COPS environment.
Table 10: SRC Client
and COPS Terminology
|
Term
|
Description
|
|
COPS
|
Common Open Policy Service; query-and-response protocol used
to exchange policy information between a policy server and its clients.
|
|
COPS-PR
|
COPS usage for policy provisioning; the PEP requests policy
provisioning when the operational state of interface and DHCP addresses
changes.
|
|
PDP
|
Policy decision point; the COPS server. which makes policy decisions
for itself and for clients that request decisions. The SRC software
is the PDP.
|
|
PEP
|
Policy enforcement point; the COPS client, which enforces policy
decisions. The JUNOSe COPS interface is a PEP.
|
|
PIB
|
Policy Information Base; a collection of sets of attributes
that represent configuration information for a device.
|
|
SRC
|
Session and Resource Control (SRC) software, formerly the Service
Deployment System (SDX) software; functions as a COPS PDP.
|
The JUNOSe software COPS-PR implementation uses
the outsourcing model that is described in RFC 3084. In this model,
the PEP delegates responsibility to the PDP to make provisioning decisions
on the PEP’s behalf.
 |
Note:
When you upgrade from an earlier JUNOSe release, the software
removes the instance of SSCC that was configured with XDR.
If you are going to perform a unified ISSU from a JUNOSe release
numbered lower than Release 10.0.0 and you have an XDR configuration,
unified ISSU is not supported while an XDR configuration is presented.
|
The provisioning is event-driven and is based on
policy requests rather than on an action taken by an administrator—the
provisioning is initiated when the PDP receives external requests
and PEP events. Provisioning can be performed in bulk (for example,
an entire QoS configuration) or in smaller segments (for example,
updating a marking filter). The following list shows the interaction
between the PEP and the PDP during the COPS-PR operation.
- Initial connection
- PEP starts the COPS-PR connection with the PDP.
- PDP requests synchronization.
- PEP sends all currently provisioned policies to PDP.
- Change of interface state
- PEP requests provisioning of an interface from the PDP.
- PDP determines policies and sends provisioning data to
the PEP.
- PEP provisions the policies.
- PDP requests policy provisioning
- PDP determines new policies and sends provisioning data
to the PEP.
- PEP provisions the policies.
The information exchange between the PDP and PEP
consists of data that is modeled in Policy Information Bases (PIBs)
and is encoded using the standard ASN.1 basic encoding rules (BERs).
The COPS-PR support in JUNOSe software uses a proprietary PIB. The
proprietary PIB consists of a series of tables that is supported in
previous JUNOSe software releases, including the proprietary accounting
and address assignment mechanisms.
The proprietary PIB provides the Policy Manager
and QoS Manager functionality shown in the following lists.
- Policy Manager
- Committed access rate
- Packet filtering
- Policy routing
- QoS classification and marking
- Rate limiting
- Traffic class
- QoS Manager
- Queues
- Schedulers
- Traffic classes
You can configure SRC clients on a per-virtual-router
basis. To configure the SRC client:
- Enable the SRC client. With the CLI sscc
enable command you can specify BER-encoded information
exchange for COPS-PR.
- host1(config)#sscc enable cops-pr
- Specify the IP addresses of up to three service activation
engines (SAEs) (primary, secondary, and tertiary). You can optionally
specify the port on which the SAEs listen for activity.
- host1(config)#sscc primary address
- host1(config)#sscc secondary address 192.168.12.1
port 3288
- (Optional) Enable policy and QoS configuration support
for IPv6 interfaces.
- host1(config)#sscc protocol ipv6
- (Optional) Specify on which router the TCP/COPS connection
is to be established.
- host1(config)#sscc transportRouter chicago
- (Optional) Specify a fixed source address for the TCP/COPS
connection created for an SRC client session.
- host1(config)#sscc sourceAddress 10.9.123.8
- (Optional) Specify a fixed source interface for the TCP/COPS
connection.
- host1(config)#sscc sourceInterface atm 3/0
- (Optional) Specify the delay period during which the SRC
client waits for a response from the SAE.
- host1(config)#sscc retryTimer 120
sscc address
- Use to configure the SRC client with the IP addresses
of the SAEs and the ports on which the SAEs listen for activity.
- You can specify primary, secondary, and tertiary SAEs,
and the port numbers on which each listens for activity. By default,
the SAE listens on port 3288.
- Example
- host1(config)#sscc primary address 192.168.128.10
port 3288
- Use the no version to remove
a specific SAE (primary, secondary, or tertiary) from the list of
SAEs.
- See sscc address
sscc enable
- Use to enable the SRC client’s COPS support in the
router.
- Use with the cops-pr keyword
to enable COPS-PR support.
- Example
- host1(config)#sscc enable cops-pr
- Use the no version to disable
the feature.
- See sscc enable
sscc protocol ipv6
- Use to configure IPv6 support on the SRC client. IPv6
support enables policy and QoS configuration on IPv6 interfaces. The
IPv6 support is in addition to the default IPv4 support.
- Example
- host1(config)#sscc protocol ipv6
- Use the no version to disable
IPv6 support on the SRC client.
- See sscc protocol ipv6
sscc retryTimer
- Use to specify the delay period (in the range 5–300
seconds) during which the SRC client waits for a response from the
SAE.
- If only a primary SAE is configured, the client resends
the request to the primary SAE.
- The client attempts to connect to a tertiary SAE only
if both the primary and secondary SAEs are unavailable. For example,
if the client is connected to the secondary SAE when the delay period
expires, the client first tries to connect to the primary SAE before
trying the tertiary SAE. The client waits for the length of the delay
period before each attempt.
- Example
- host1(config)#sscc retryTimer 90
- Use the no version to restore
the default value, 90 seconds.
- See sscc retryTimer
sscc sourceAddress
- Use to specify a fixed source address for the TCP/COPS
connection created for an SRC client session. This is the local address.
- If you do not specify a source address, the TCP/COPS connection
is not bound to a specific source (that is, local) address.
- Example
- host1(config)#sscc sourceAddress 10.9.123.8
- Use the no version to remove
the specified address.
- See sscc sourceAddress
sscc sourceInterface
- Use to specify a fixed source interface for the TCP/COPS
connection created for an SRC client session. This is a local interface.
- You may need to set a source interface in cases where
a firewall, access control list, or policy configuration exists; and
it is important to know what the interface is, or you need to set
the interface independently from other protocols that have conflicting
requirements.
- If you do not specify a source interface, the TCP/COPS
connection is not bound to a specific source (that is, local) interface.
- Example
- host1(config)#sscc sourceInterface atm 3/0
- Use the no version to remove
the source interface.
- See sscc sourceInterface
sscc transportRouter
- Use to specify on which router the TCP/COPS connection
is to be established.
- The router can be the same as or different from the router
the SRC client session is created in and associated with.
- If you do not specify the transport router for an SRC
client session, the transport router defaults to the router associated
with the session.
- Example
- host1(config)#sscc transportRouter chicago
- Use the no version
to remove the specified SRC client transport router.
- See sscc transportRouter
[Contents]
[Prev]
[Next]
[Index]
[Report an Error]