SDX 6.4.x Solutions Guide > Providing Premium Services in a PCMM Environment > Using the SAE in a PCMM Environment

Using the SAE in a PCMM Environment

The SAE uses the Common Open Policy Service (COPS) protocol as specified in the PacketCable Multimedia Specification PKT-SP-MM-I03-051221 to manage PCMM-compliant CMTS devices in a cable network environment. The SAE connects to the CMTS device by using a COPS over Transmission Control Protocol (TCP) connection. In cable environments, the SAE manages the connection to the CMTS device.

The CMTS device does not provide address requests or notify the SAE of new subscribers, subscriber IP addresses, or any other attributes. IP address detection and all other subscriber attributes are collected outside of the COPS connection to the CMTS device. The SAE uses COPS only to push policies to the CMTS device and to learn about the CMTS status and usage data.

Because the CMTS device does not have the concept of interfaces, the SDX software uses pseudointerfaces to model CMTS subscriber connections similar to subscriber connections for JUNOS routing platforms and JUNOSe routers.

This section describes how the SAE is used in cable networks and how to configure the SAE for this environment. It includes the following sections:

• Logging In Subscribers and Creating Sessions
• SAE Communities
• Storing Session Data
• Configuring the SAE for a Cable Network Environment
• Adding Objects for CMTS Devices to the Directory
• Using the NIC Resolver
• Monitoring the SAE in a Cable Environment

Logging In Subscribers and Creating Sessions

You can use two mechanisms to obtain subscriber address requests and other information and to set up a pseudointerface on the CMTS device. (You must choose one mechanism; you cannot mix them.):

1. Assigned IP subscriber. The SAE learns about a subscriber through subscriber-initiated activities, such as activating a service through the portal or through the Advanced Services Gateway (ASG).

With this method, you use the assigned IP subscriber login type along with the network interface collector (NIC) to map IP addresses to the SAE.

2. Event notification from an IP address manager. The SAE learns about subscribers through notifications from an external IP address manager, such as a DHCP server or a RADIUS server.

With this method, you use the event notification application programming interface (API). The API provides an interface to the IP address manager, and lets the IP address manager notify the SAE of events such as IP address assignments.

Assigned IP Subscribers

With the assigned IP subscriber method of logging in subscribers and creating sessions, the SDX software uses IP address pools along with NIC resolvers to provide mapping of IP addresses to SAEs. You configure the static address pools or dynamically discovered address pools in the virtual router configuration for a CMTS device. These pools are published in the NIC. The NIC maps subscriber IP addresses in requests received through the portal or Advanced Services Gateway to the SAE that currently manages that CMTS device.

Login Interactions with Assigned IP Subscribers

This section describes login interactions for assigned IP subscribers. In the example shown in Figure 13, the subscriber activates a service through a portal. You could also have the subscriber activate a service through the Advanced Services Gateway.

Figure 13: Login Interactions with Assigned IP Subscribers

The sequence of events for logging in and creating sessions for assigned IP subscribers is:

1. The subscriber logs in to the portal.
2. The portal sends the subscriber's IP address to the NIC.
3. Based on the IP address, the NIC looks up the subscriber's SAE, CMTS device, and interface name, and returns this information to the portal.
4. The portal sends a getSubscriber message to the SAE. The message includes the subscriber's IP address, CMTS device, and interface name.
5. The SAE creates an assigned IP subscriber and performs a subscriber login. Specifically, it:

1. Runs the interface classification script and creates a pseudointerface for the PCMM device driver.

• If it finds a default policy, it pushes the policy to the CMTS device.
• If it does not find a default policy, it continues with the next steps.

1. Runs the subscriber classification script with the IP address of the subscriber. (Use the ASSIGNEDIP login type in subscriber classification scripts.)
2. Loads the subscriber profile.
3. Runs the subscriber authorization plug-ins.
4. Runs the subscriber tracking plug-ins.
5. Creates a subscriber session and stores the session data in the session store file.

6. The SAE pushes service policies for the subscriber session to the CMTS device.

Because the SAE is not notified when the subscriber logs out, the assigned IP idle timer begins when no service is active. The SAE removes the interface subscriber session when the timeout period ends.

Event Notification from an IP Address Manager

With the event notification method of logging in subscribers and creating subscriber sessions, the subscriber logs in to the CMTS device and obtains an IP address through an address server, usually a DHCP server. The SAE receives notifications about the subscriber, such as the subscriber's IP address, from an event notification application that is installed on the DHCP server.

To use this method of logging in subscribers, you can use the event notification API to create the application that notifies the SAE when events occur between the DHCP server and the CMTS device. You can also use Monitoring Agent, an application that was created with the event notification API, and that monitors DHCP or RADIUS messages for DHCP or RADIUS servers. See SDX Application Library Guide, Chapter 21, Integrating IP Address Managers with the SAE.

Login with Event Notification

This section describes login interactions using event notifications.

Figure 14: Login Interactions with Event Notification Application

The sequence of events for logging in subscribers and creating sessions is:

1. The DHCP client in the subscriber's computer sends a DHCP discover request to the DHCP server.
2. The DHCP server sends a DHCP offer to the subscriber's DHCP client.
3. The DHCP client sends a DHCP request to the DHCP server.
4. The DHCP server acknowledges the request by sending a DHCP Ack message to the DHCP client.
5. The event notification application that is running on the DHCP server intercepts the DHCP Ack message.
6. The event notification application sends an ipUp message to the SAE that notifies the SAE that an IP address is up.
7. The SAE performs a subscriber login. Specifically, it:

1. Runs the interface classification script and creates a pseudointerface for the PCMM device driver.

• If it finds a default policy, it pushes the policy to the CMTS device.
• If it does not find a default policy, it continues with the next steps.

1. Runs the subscriber classification script.
2. Loads the subscriber profile.
3. Runs the subscriber authorization plug-ins.
4. Runs the subscriber tracking plug-ins.
5. Creates a subscriber session and stores the session in the session store file.

8. The SAE provisions policies for the subscriber session on the CMTS device.

The ipUp event should be sent with a timeout set to the DHCP lease time. The DHCP server sends an ipUp event for each Ack sent to the client. The SAE restarts the timeout each time it receives an ipUp event.

If the client explicitly releases the DHCP address (that is, it sends a DHCP release event), the DHCP server sends an ipDown event. If the client does not renew the address, the lease expires on the DHCP server and the timeout expires on the SAE.

SAE Communities

For SAE redundancy in a cable network, you can have a community of two or more SAEs. SAEs in a community are given the role of either active SAE or passive SAE. The active SAE manages the connection to the CMTS device and keeps session data up to date within the community. Figure 15 shows a typical SAE community.

Figure 15: SAE Community

When an SAE opens a connection to the CMTS device, it negotiates with other SAEs to determine which SAE controls the CMTS device. The SAE community manager and members of the community select the active SAE.

A passive SAE needs to take over as active SAE in any of the following cases:

• The active SAE shuts down or the connection between the CMTS device and the active SAE goes down. In this case, the active SAE notifies the passive SAEs, and one of the passive SAEs takes over as active SAE.
• A passive SAE does not receive a keepalive message from the active SAE within the keepalive interval. In this case, the passive SAE attempts to become the active SAE.

Configuration Tasks for SAE Communities

You can configure the following for SAE communities:

• Define the members of an SAE community by adding the IP addresses of SAEs in the community to the virtual router object of the CMTS device in the directory. See Adding Objects for CMTS Devices to the Directory.
• Define parameters for the SAE community manager in SDX Configuration Editor. See Configuring the SAE Community Manager.
• If there is a firewall in the network, configure the firewall to allow SAE messages through.

Storing Session Data

To aid in recovering from an SAE failover, the SAE stores subscriber and service session data. When the SAE manages a CMTS device, session data is stored locally in the SAE host's file system. The SDX component that controls the storage of session data on the SAE is called the session store. The session store queues data and then writes the data to session store files on the SAE host's disk. Once the data is written to disk, it can survive a server reboot.

For more information, see Storing Subscriber and Service Session Data in SDX Network Guide: SAE, Juniper Networks Routers, and NIC, Chapter 2, Configuring the SAE.

PCMM Record-Keeping Server Plug-In

To allow the SAE's embedded policy server to communicate with a record-keeping server (RKS) in a PCMM environment, you need to use the PCMM record-keeping server plug-in. This plug-in is similar to the RADIUS accounting plug-ins, but it works with any RKS that is compliant with the PCMM specification. The RKS plug-in supports additional attributes: Application-Manager-ID, Request-Type, and Update-Reason. The plug-in sends all requests to the RKS as Acct-Status-Type=Interim-Update.

Configuring the SAE for a Cable Network Environment

The tasks to configure the SAE for a cable network environment are:

1. Configuring a PCMM Device Driver.
2. Configuring CMTS-Specific RKS Plug-Ins.
3. Configuring the Session Store Feature. See SDX Network Guide: SAE, Juniper Networks Routers, and NIC, Chapter 2, Configuring the SAE.
4. Configuring the SAE Community Manager.
5. Configuring SAE Properties for the Event Notification API (if you are using an external address manager).
6. Configuring PCMM Record-Keeping Server Plug-Ins (if you are using the SAE's embedded policy server).

In addition to configuring the SAE, you need to:

1. Configure the CMTS device in the directory (if you are using the SAE's embedded policy server). See Adding Objects for CMTS Devices to the Directory.
2. Configure the NIC (if you are using assigned IP subscribers). See Using the NIC Resolver.
3. Enable the COPS interface on the CMTS device. See the documentation for your CMTS device for information about how to do this.

Configuring a PCMM Device Driver

The SAE connects to the PCMM device by using a COPS over TCP connection. The PCMM device driver controls this connection. You create a PCMM device driver for each CMTS device that the SAE manages. You can specify properties for the PCMM device driver in the Router tab of SDX Configuration Editor.

Keepalive Interval [s]

• Interval between keepalive messages sent from the COPS client (the PCMM device) to the COPS server (the SAE). The COPS client monitors the COPS connection by sending keepalive messages at random intervals between one-fourth and three-fourths of the specified interval. If the client or the server does not receive the expected keepalive answer within the specified timeout, the client closes the connection.
• Value—Number of seconds in the range 0-2147483647. A value of 0 means that the timeout is disabled.
• Default—45
• Property name—Router.pcmm.keepalive

TCP Connection Timeout [s]

• Timeout for opening a TCP connection to the PCMM device.
• Value—Number of seconds in the range 0-2147483647
• Default—5
• Property name—Router.pcmm.open_connection_timeout

Application Manager ID

• When this SAE is configured as the application manager, the identifier of the application manager. The application manager includes this identifier in all messages that it sends to the policy server. The policy server passes this ID to the CMTS device in Gate Control messages. The CMTS device returns the ID associated with the gate to the policy server. The policy server uses this information to associate gate messages with a particular application manager.
• Value—4-byte unsigned integer; must be unique in a service provider network
• Default—0

Message Timeout [ms]

• Amount of time that the COPS server (the SAE) waits for a response to COPS requests from the COPS client (the PCMM device). Under a high load the PCMM device may not be able to respond fast enough to COPS requests. Change this value only if a high number of COPS timeout events appear in the error log.
• Value—Number of milliseconds in the range 0-2147483647
• Default—120000
• Property name—Router.pcmm.message_timeout

COPS Message Maximum Length [bytes]

• Maximum length of a COPS message.
• Value—Number of bytes in the range 4 bytes to 2 GB
• Guidelines—We recommend that you use the default setting.
• Default—204800
• Property name—Router.pcmm.message_max_length

COPS Message Read Buffer Size [bytes]

• Buffer size for receiving COPS messages from the COPS client.
• Value—Number of bytes in the range 4 bytes to 2 GB
• Guidelines—We recommend that you use the default setting unless you are instructed to change it by Juniper Networks engineers.
• Default—30000
• Property name—Router.pcmm.message_read_buffer_size

COPS Message Write Buffer Size [bytes]

• Buffer size for sending COPS messages to the COPS client.
• Value—Number of bytes in the range 4 bytes to 2 GB
• Guidelines—We recommend that you use the default setting unless you are instructed to change it by Juniper Networks engineers.
• Default—30000
• Property name—Router.pcmm.message_write_buffer_size

SAE Community Manager

• Name of the community manager that manages PCMM driver communities. Active SAEs are selected from this community. You define community managers in the Ext. Interfaces tab of SDX Configuration Editor. See Configuring the SAE Community Manager.
• Value—Community name
• Default—PCMMCommunityManager
• Property name—Router.pcmm.community.name

Element ID

• Enables or disables and sets the unique identifier that the SAE uses to identify itself when it originates RKS events.
• Value—8-byte unsigned integer in the range 0-99999; must be unique within a PCMM network
• Default—0
• Property name—Router.pcmm.emid

Default RKS Plug-In

• Enables or disables and sets the RKS plug-in to which the SAE sends event messages.
• Value—Name of an RKS plug-in; see Configuring PCMM Record-Keeping Server Plug-Ins
• Default—Disabled
• Property name—Router.pcmm.rks.plugin

Configuring CMTS-Specific RKS Plug-Ins

You can configure an RKS plug-in for specific CMTS devices. When there are events for the CMTS device, the SAE sends the events to the specified plug-in.

To assign a CMTS-specific RKS plug-in:

1. In the CMTS Specific RKS Plug-ins area of a PCMM device driver configuration, select CMTS Specific RKS Plug-in, and click Create a New Instance of.

The Create New Instance dialog box appears.

2. Assign the name of the CMTS device as the instance name, and click OK.

The new plug-in instance appears.

3. Fill in the RKS Plug-in field.

RKS Plug-in

• Name of the plug-in to which the SAE sends events for this CMTS device.
• Value—Name of an RKS plug-in. See Configuring PCMM Record-Keeping Server Plug-Ins.
• Default—No value
• Property name—Router.pcmm.<CMTS name>.rks.plugin

Configuring the SAE Community Manager

You can configure the properties for an SAE community manager in the Ext. Interface tab of SDX Configuration Editor.

Keepalive Interval [s]

• Interval between keepalive messages sent from the active SAE to the passive members of the community.
• Value—Number of seconds in the range 0-2147483647
• Default—30
• Property name—SAEFeature.PCMMCommunityManager.heartbeat

Number of Threads

• Number of threads that are allocated to manage the community.
• Value—Integer in the range 0-2147483647
• Guidelines—You generally do not need to change this property.
• Default—5
• Property name—SAEFeature.PCMMCommunityManager.num_threads

Acquire Timeout

• Amount of time an SAE waits for a remote member of the community when it is acquiring a distributed lock. To avoid race conditions when the SAE community is determining which SAE is the active SAE, the community manager has a distributed lock. When an SAE attempts to become the active SAE, it needs to acquire the distributed lock.
• Value—Number of seconds in the range 0-2147483647
• Guidelines—You generally do not need to change this property.
• Default—15
• Property name—SAEFeature.PCMMCommunityManager.acquire_timeout

Blackout Time

• Amount of time that an active SAE must wait after it shuts down before it can try to become the active SAE of the community again.
• Value—Number of seconds in the range 0-2147483647
• Default—30
• Property name—SAEFeature.PCMMCommunityManager.blackout_time

Configuring SAE Properties for the Event Notification API

You can configure the SAE properties for the event notification API in the Ext. Interface tab of SDX Configuration Editor.

Retry Time

• Amount of time between attempts to send events that could not be delivered.
• Value—Number of seconds in the range 0-2147483647
• Default—300
• Property name—SAEFeature.event.retry_time

Retry Limit

• Number of times an event fails to be delivered before the event is discarded.
• Value—Integer in the range 0-2147483647
• Default—5
• Property name—SAEFeature.event.retry_limit

Number of Threads

• Number of threads allocated to process events.
• Value—Integer in the range 0-2147483647
• Default—5
• Property name—SAEFeature.event.num_threads

Configuring PCMM Record-Keeping Server Plug-Ins

You configure PCMM RKS plug-ins in the Plug-Ins tab of SDX Configuration Editor. To set up PCMM record-keeping server plug-ins:

1. In the navigation pane, select the SAE object for which you want to configure plug-ins.
2. Select the Plug-Ins tab.

The Plug-Ins pane appears.

3. In the Plug-In Pool area of the Plug-Ins pane, select PCMM Record Keeping Server Plugin from the drop-down list, and click Create a New Instance of.

The instance appears in the Plug-In Pool area.

4. Fill in the plug-in instance fields as described below.
5. In the Peer Group area, create at least one peer to use as the default peer. See Configuring RKS Peers.
6. In the PCMM Device Driver configuration, add the RKS plug-in as the default RKS plug-in or as a CMTS-specific plug-in. See Configuring a PCMM Device Driver.

Load Balancing Mode

• Selects the mode for load-balancing RKSs.
• Value—Failover, round-robin

• Failover—SAE sends requests to the RKS configured as the default peer. If the default peer fails, the SAE uses the next server configured in the peer group. The SAE cycles through the configured servers as needed.
• Round-robin—SAE alternates requests between all RKSs configured in the peer group.

• Default—Failover
• Property name—loadBalancingMode

Failover failback timer

• Controls if and when the SAE attempts to fail back to the default peer.
• Value—Integer

• n—Number of seconds after a failover that the SAE attempts to fail back; range is 1-2147483647
• 0—SAE always attempts to fail back
• -1—SAE never attempts to fail back

• Default—-1
• Property name—failbackTimer

Retry interval [ms]

• Time the SAE waits for a response from an RKS before it resends the packet. The SAE keeps sending packets until either the RKS acknowledges the packet or the maximum timeout is reached.
• Value—Number of milliseconds in the range 0-2147483647
• Default—3000
• Property name—local.retryInterval

Max Queue Length

• Maximum number of unacknowledged messages that the plug-in receives from the RKS before it discards new messages.
• Value—Integer in the range 0-2147483647
• Default—10000
• Property name—local.maxWaitingQueueLength

Bind Address

• Source IP address that the plug-in uses to communicate with the RKS.
• Value—IP address; if you do not specify an address, the global default address is used. The SAE automatically sets the global default address when you run the etc/config command during initial configuration of the SAE. The property for the global address is the AccountingMgr.local.address property in the /opt/UMC/sae/etc/default.properties file.
• Default—No value
• Property name—local.address

UDP Port

• Source UDP port or a pool of ports that the plug-in uses to communicate with the RKS.
• Value—You can enter a single port number, a pool of port numbers, or a list of port numbers and port ranges. If you do not specify a UDP port, the global default port is used (see Configuring UDP Ports for RADIUS Plug-Ins in SDX Subscribers and Subscriptions Guide, Chapter 5, Configuring Authorization and Accounting Plug-Ins).

• Port number in the range 1-65535
• A range of ports in the format port-port; for example, 7000-7003
• A comma-separated list of port numbers and port ranges

• Default—No value
• Example—7000-7003, 7006, 7007-7009
• Property name—local.port

FEID MSO Data

• MSO-defined data in the financial entity ID (FEID) attribute, which is included in event messages.
• Value—First eight bytes of the FEID attribute
• Default—Zero filled
• Property name—feid.msoData

FEID MSO Domain Name

• MSO domain name in the FEID attribute that uniquely identifies the MSO for billing and settlement purposes.
• Value—Domain name up to 239 bytes; begins at the ninth byte of the FEID attribute
• Default—No value
• Property name—feid.msoDomainName

Trusted Element

• When the SAE is running as a policy server—which means that the SAE sends event messages directly to the RKS—specifies whether or not the SAE is a trusted network element.
• Value

• True—The SAE is a trusted element.
• False—The SAE is not a trusted element.

• Default—True
• Property name—trusted

Default peer

• Name of the primary RKS to which the SAE sends accounting packets.
• Value—Name of the RKS as defined in the RKS peer configuration
• Default—No value
• Property name—defaultPeer

Configuring RKS Peers

An RKS peer is an instance of an RKS. A PCMM environment has a primary RKS and optionally a secondary RKS. The primary RKS is mandatory, and you assign the RKS as primary by configuring it as the default peer in the RKS plug-in. The secondary RKS is optional, and it is an RKS peer that is not configured as the default peer. If you define multiple nondefault peers, one of them is randomly chosen to be the secondary RKS.

RKS peers are configured in the peer group for each PCMM RKS plug-in instance. To create an RKS peer:

1. In the Peer Group area of a PCMM RKS plug-in instance, select RKS Peer and click Create a New Instance of.

The Create New Instance dialog box appears.

2. Assign a name to the instance, and click OK.

The new peer appears in the Peer Group area.

3. Fill in the fields as described below.

RKS Server Address

• IP address of the RKS server to which the SAE sends accounting data.
• Value—IP address
• Default—No value
• Property name—peer.<peer name>.remote.address

RKS Server Port

• Port used for sending accounting packets.
• Value—Valid UDP port
• Default—1813
• Property name—peer.<peer name>.remote.port

Adding Objects for CMTS Devices to the Directory

To manage CMTS devices, the SAE creates and manages pseudointerfaces that it associates with a virtual router object in the directory. Each CMTS device in the SDX network must appear in the directory as a router object, and it must be associated with a virtual router object called default. The router and virtual router are not actually configured on the CMTS device; the router and virtual router in the directory provide a way for the SAE to manage the CMTS device by using the SAE's embedded policy server.

To add a CMTS device to the directory with SDX Admin:

1. In the navigation pane, highlight o=Network, and right-click.
2. Select New > EdgeDevice.

The New EdgeDevice dialog box appears.

3. In the New EdgeDevice dialog box, enter the name of the CMTS device, and click OK.

The name of the new device appears in the navigation pane, and information about the device appears in the EdgeDevice pane.

4. Set the parameters in the Main tab of the EdgeDevice pane.
5. Click Save in the EdgeDevice pane.
6. Create a virtual router for the CMTS device. See Creating a Virtual Router for the CMTS Device

Description

• Information about this device; keywords that the SDX Admin find utility uses.
• Value—Text string
• Default—No value

Management Address

• IP address of the CMTS device. The SAE uses this address to establish a COPS connection with the CMTS device.
• Value—IP address
• Default—No value

Router Driver Type

• Type of device that this directory object will be used to manage.
• Value

• JUNOSe—JUNOSe router
• JUNOS—JUNOS routing platform
• PCMM—PCMM-compliant CMTS device

If you do not fill in this field, the device driver ignores this router driver.

• Default—No value

QoS Profiles

• For JUNOSe routers only, QoS profiles that are configured on the router.
• Value—List of QoS profiles on separate lines
• Example—atm-default
• Default—No value

Creating a Virtual Router for the CMTS Device

You need to add a virtual router object called default to the CMTS device. To add a virtual router with SDX Admin:

1. In the navigation pane, right-click on the CMTS device.
2. Select New > VirtualRouter.

The New EdgeDevice dialog box appears.

3. In the New VirtualRouter dialog box, enter the name default, and click OK.

The default virtual router appears in the navigation pane, and information about the virtual router appears in the VirtualRouter pane.

4. Configure virtual router parameters in the Main Tab. See Configuration Parameters for Virtual Routers.
5. Select the SAE Connection tab of the VirtualRouter pane, and add SAEs that are connected to the CMTS device. This list becomes the community of SAEs.

To add an SAE:

1. Type the IP address of the SAE in the field below the Connected SAE box.
2. Click Add.

6. Click Save in the VirtualRouter pane.

Configuration Parameters for Virtual Routers

Use the fields in this section to define virtual router objects. If you are using assigned IP subscribers along with the NIC, you need to configure either a local or static address pool so that the NIC can resolve the IP-to-SAE mapping.

SNMP Read Community

• SNMP community name associated with SNMP read-only operations for this VR.
• Value—Text string
• Example—admin

SNMP Write Community

• SNMP community name associated with SNMP write operations for this VR.
• Value—Text string
• Example—public

Scope

• Service scopes assigned to this VR—See Configuring Service Scopes in SDX Services and Policies Guide, Chapter 1, Managing Services.
• Value—Text string
• Example—POP-Westford

Local Address Pools

• List of IP address pools that the VR currently manages and stores. You must configure either a local address pool or a static address pool so that the NIC can resolve the IP-to-SAE mapping.
• Value—List of IP address pools. You can specify an unlimited number of IP address pools. You can specify either the first and last addresses in a range, or you can specify a subnet address, a subnet mask, and a list of addresses to exclude from the subnet.

The IP pool syntax has the following format:

([<ipAddressStart> <ipAddressEnd>] |
{<ipBaseAddress>/(<mask> | <digitNumber>)(,<ipAddressExclude>)*})

where:

• <ipAddressStart>—First IP address (version 4 or 6) in a range
• <ipAddressEnd>—Last IP address (version 4 or 6) in a range
• <ipBaseAddress>—Network base address
• <mask>—Subnet mask
• <digitNumber>—Integer specifying the length of the subnet mask
• <ipAddressExclude>—List of IP addresses to be excluded from the subnet
• |—Choice of expression; choose either the expression to the left or the expression to the right of this symbol
• *—Zero or more instances of the preceding group

You can use spaces in the syntax only to separate the first and last explicit IP addresses in a range.

• Default—No value
• Example—([10.10.10.5 10.10.10.250] {10.20.20.0/24})

Static Address Pools

• List of IP address pools that the VR manages but does not store. You can configure these address pools only in the SDX software. You must configure either a local address pool or a static address pool so that the NIC can resolve the IP-to-SAE mapping.
• Value—See the field Local Address Pools.
• Default—No value
• Example—([10.10.10.5 10.10.10.250] {10.20.20.0/24})

Managing SAE IOR

• Common Object Request Broker Architecture (CORBA) reference for the SAE managing this VR.
• Value—One of the following items:

• The actual CORBA reference for the SAE
• The absolute path to the interoperable object reference (IOR) file
• A corbaloc URL in the form corbaloc::<host>:8801/SAE

• <host> is the name or IP address of the SAE host

• Guidelines—The PoolPublisher and IorPublisher router initialization scripts provide this information when the router connects to the SAE. For information about configuring router initialization scripts, see SDX Network Guide: SAE, Juniper Networks Routers, and NIC, Chapter 3, Using JUNOSe Routers in the SDX Network or SDX Network Guide: SAE, Juniper Networks Routers, and NIC, Chapter 4, Using JUNOS Routing Platforms in the SDX Network. If you do not select one of these router initialization scripts, enter a value in this field.
• Default—No value
• Example—One of the following items:

• Absolute path— /opt/UMC/sae/var/run/sae.ior
• corbaloc URL—boston:8801/sae
• Actual IOR— IOR:000000000000002438444C3A736D67742E6A756E697...

Tracking Plug-in

• Plug-in instances that track interfaces that the SAE manages on this VR. The SAE calls these plug-ins after an interface comes up, when new policies are installed on the interface, and when the interface goes down.
• Value—Comma-separated list of plug-in instances
• Guidelines—Enter plug-in instances and NIC SAE plug-in agents that are specific to this VR. For information about configuring tracking plug-ins, see SDX Subscribers and Subscriptions Guide, Chapter 5, Configuring Authorization and Accounting Plug-Ins.
• Default—No value
• Example—nicsae, flexRadius

Configuring SAE Communities

You define SAE communities by entering the SAEs in a community in the connected SAE field of the virtual router object.

When you modify a community, wait for passive session stores on the new community members to be updated before you shut down the current active SAE. Otherwise, if you add a new member to a community, and then a failover from the current active SAE to the new member is triggered immediately, the new member's session store may not have received all data from the active SAE's session store.

To define a community, select the SAE Connection tab of the VirtualRouter pane, and add the addresses of SAEs that can manage this CMTS device.

To add an SAE:

1. Type the IP address of the SAE in the field below the Connected SAE box.
2. Click Add.

To modify an SAE address:

1. Double-click the IP address of the SAE in the Connected SAE box.
2. Modify the IP address in the field below the Connected SAE box.
3. Click Modify.

To delete an SAE address:

1. Double-click the IP address of the SAE in the Connected SAE box.
2. Remove the IP address from the field below the Connected SAE box.
3. Click Delete.

Connected SAE

• SAEs that are connected to the CMTS device.
• Value—IP addresses
• Default—No value

Using the NIC Resolver

If you are using the assigned IP subscriber method of logging in subscribers, and you are using the NIC to determine the subscriber's SAE, you need to configure a resolver on the NIC. The OnePopDynamicIp sample configuration data supports this scenario. The OnePopDynamicIp configuration supports one point of presence (POP) and provides no redundancy. The realm for this configuration accommodates the situation in which IP pools are configured locally on each virtual router object.

You can access the OnePopDynamicIp configuration in either SDX Admin or SDX Configuration Editor. Figure 16 shows the sample configuration in SDX Configuration Editor.

Figure 16: OnePopDynamicIP Sample Configuration in SDX Configuration Editor

For more information about the resolution process for OnePopDynamicIp, see SDX Network Guide: SAE, Juniper Networks Routers, and NIC, Chapter 5, Locating Subscriber Information.

Monitoring the SAE in a Cable Environment

You can use SAE Web Admin to monitor the state of PCMM device drivers and pseudointerfaces installed on the SAE, or to monitor session, service, and policy information for PCMM envirnoments just as you would monitor them for routers.

For example, to view information about PCMM device drivers running on the SAE:

1. In the navigation pane, expand State, and click Routers.

The Routers State page appears.

2. To view a specific driver, enter part or all of the name of the driver in the VR name contains field, and click Search.

or

To view all drivers, click List All.

3. Click a driver under Search Results to get more information about the specified driver.

To view information about the pseudointerfaces running on the PCMM device driver:

1. In the navigation pane, expand State, and click Interfaces.

The Router Interface State page appears.

2. To view a specific router interface, enter part or all of the name of the following, and then click Search:

• VR name
• Interface name

3. Click an interface name to get more information about the specified interface.

See SDX Monitoring and Troubleshooting Guide, Chapter 6, Monitoring and Managing SAE Data for more information.