The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter describes learning of interface topology and association of the remote cable MSO links solution.
To control and report traffic in the context of a remote interface, you must map the topology in terms of the available CMTS interfaces and their associated bandwidth. This map must include keys that the Cisco SCE uses to associate subscriber traffic with specific interfaces.
The Cisco SCE learns the interface topology by retrieving the CMTS configuration by using the Simple Network Management Protocol (SNMP) and converting the configuration to a virtual links map. Virtual links are provisioned to the relevant Cisco SCEs.
VLM queries the CMTS device and learns the upstream and downstream channels, their names, and their rates. VLM supports multiple primary channels for each wideband group. For primary channels within a wideband group, VLM queries the CMTS for resource allocation that is reserved for legacy modems.
For downstream channels, VLM obtains the mapping information of the channels to wideband groups. For the wideband channels, VLM extracts the:
The parameters for the primary and secondary channels include:
Table 3-1 lists the parameters and their values for primary and secondary channels and the dynamic AGCs.
Interface association awareness is achieved through DHCP integration. The CMTS IP (specifically, the Relay-Agent IP, or giaddr) is part of the DHCP dialog and upstream and downstream interface IDs are included in the Relay-Agen t option (for example, option 82 [encoded in sub option 1, the circuit ID]). This information allows the Cisco SCE to uniquely identify upstream and downstream interfaces to which a subscriber is mapped, even in cases in which more than one CMTS is connected to an Cisco SCE.
The Cisco Service Control Subscriber Manager learns the interfaces automatically from the CMTSs and provisions the vlinks to the Cisco SCE on the following events:
During these events, the Cisco Service Control Subscriber Manager creates new Vlinks learnt from the CMTSs, updates the existing Vlinks if the SM observed any changes, and removes the unwanted Vlinks to make sure that the SM has synchronized completely with the CMTS interfaces to reserve the unused Vlinks for the new interfaces. During this process, the Cisco Subscriber Manager removes all Vlinks created directly in an Cisco SCE using CLI or any other source without the knowledge of the Cisco Service Control Subscriber Manager.
Note If multiple CMTS devices connected to an Cisco SCE have the same SNMP SysName, the VLM fails to identify the duplication and this results in unpredictable behavior.
The Cisco SCE DHCP sniffer LEG extracts the CMTS IP and reports it to the Subscriber Manager, which performs the appropriate virtual-link association, allowing the Cisco SCE to manage the traffic correctly.
Wideband channels are associated with three AGCs in a two-level hierarchy and the cable modems are mapped to their respective AGCs. For information on the AGC mapping, see the “Bandwidth Control Enhancements” section and the “Mapping of Cable Modems Through DHCP Sniffing” section.
When the VLM queries the CMTS device, it reads all the IP addresses from the CMTS device IP table and creates the mapping table that is used to map IP addresses to the CMTS device to which they are related. Many of the IP addresses that are read from the CMTS device are not used by subscribers, which can cause the mapping table to become too large and unmanageable. To prevent this, the VLM dynamically selects and releases the giaddr values from the IP table. VLM ignores IP addresses that starts with 127 because these IP addresses are considered as the loop back IP addresses.
When a subscriber logs in, the CMTS device appends the giaddr to the DHCP transaction. For a giaddr that is new to the DHCP LEG (or an existing giaddr that was not used during previous logins):
– If a device exists with the same host-name, it indicates that a new IP was added to the device:
– If the device host-name is invalid, it indicates one of these causes:
– If the device host name is valid, the name is new to the VLM, and the dynamic device feature is enabled:
From Service Control Application for Broadband Release 3.6.5, for a static device configuration, you can disable learning new giaddr during login. After you disable learning new giaddr, if the Subscriber Manager identifies that the relay agent does not belong to any known CMTS, the SM continues to log in instead of doing a query. During periodic queries, the Cisco Subscriber Manager continues to learn new giaddrs. To disable learning new giaddr during login, set enable_dynamic_giaddrs_learning to false.
– If the policy mappings are found, a subscriber is created by using the policy mappings.
– During a login operation, if the policy mappings are not found:
Note When the VLM queries a device, all login operations of the affected device are stored in a queue. After completing the query operations, the login process resumes and there is no loss of login operations. Each subscriber is logged in with their respective mappings.
– VLM removes the giaddr from its list of giaddr values.
– IP value is no longer a giaddr in the CMTS device (when performing p3vlink --show-device -d < device >, the giaddr attribute does not contain the removed IP).
– LEG removes the entries from the mapping table that are related to the giaddr.
– For each subscriber, the VLM checks if the subscriber giaddr custom property is the same as the removed giaddr and if so, changes the property to be the IP address of the CMTS device.
This example shows the current details of a subscriber:
– DHCP transactions of the affected CMTS device are placed on hold. The VLM buffer can store 100,000 DHCP events per CMTS.
– LEG queues up the subscriber login request.
– On completion of device query operation, the VLM notifies the LEG.
– LEG removes the stored messages in the queue and restarts the login operation.
– DHCP transactions of any newly detected CMTS device are stored in the queue until VLM queries the new CMTS information.
In releases earlier than Cisco Service Control Subscriber Manager Release 3.8.5, VLM learns integrated or modular interfaces if the interfaces are associated with wideband interfaces.
From Cisco Service Control Subscriber Manager Release 3.8.5, VLM learns integrated cable interfaces or modular cable interfaces if they are directly associated to a MAC domain even if they are not associated under wideband interfaces.
From Cisco Service Control Subscriber Manager Release 3.8.5, the Cisco Service Control Subscriber Manager has an option to retrieve the cable modem MAC address from the CMReg MIBs received from the CMTS. The retrieved list of cable modem MACs is added to the Subscriber Manager Database as Subscriber ID, with the device IP address as giaddr.
To enable this option, use the CLU p3vlink --import-subs-into-db command. For details about the CLU, see the “Monitoring Using the p3vlink Utility” section.
If the VLM detects that a new CMTS is added as part of the device-add operation, the Cisco Service Control Subscriber Manager can trigger an import of the MAC addresses of all the cable modems associated to the IP address of the CMTS to the Subscriber Manager Database.
To enable the import option, configure the import-subs-into-db-on-device-add parameter in the vlink.cfg file.
From Cisco Service Control Subscriber Manager Release 3.8.5, the Cisco Service Control Subscriber Manager has an option to add the cable modem to the primary queue for every CPE login, regardless of whether the subscriber has a Vlink ID. Cable modem is added to the primary queue even if it is fully mapped.
To use this feature, configure the enable_bg_query_on_cpe parameter in the IPDR LEG. For details about configuring the IPDR LEG, see the Cisco Service Control Subscriber Manager LEGs User Guide.
From Cisco Service Control Subscriber Manager Release 3.8.5, the Cisco Service Control Subscriber Manager has an option to enable periodic bulk query for all subscribers at different vlink modes and subscribers at different DOCSIS versions.
To enable the option to periodic bulk query for all subscribers at different vlink modes and subscribers at different DOCSIS versions, configure the following parameters in the vlink.cfg file:
For details on configuring these parameters, see the “Configuring the Virtual Links Manager” section.
To query the CMTS on a need basis for converging all subscribers with proper UpVlink and DownVlink ID, use the CLU p3vlink --snmp-bg-query command. For details about the CLU, see the “Monitoring Using the p3vlink Utility” section.
The Cisco Service Control Subscriber Manager queries Vlinks of all the subscribers with full, partial, and no Vlink mappings. This periodic Vlink refreshment is performed on the Cisco Service Control Subscriber Manager database for subscribers regardless of whether they are active or inactive in Cisco SCE (introduced or unintroduced).
Effective with Cisco SCE Release 4.1.0, the Cisco Service Control Subscriber Manager can query the database only for the active subscribers. Cisco SCE Release 4.1.0 introduces the subscribers_for_snmp_bg parameter in the vlink.cfg file. This feature is enabled if you configure the parameter as introduced and is applicable if the Cisco Service Control Subscriber Manager is configured in pull mode. For more details, see the “Configuring the Virtual Links Manager” section.
During a periodic query, if the Subscriber Manager detects that some of the interfaces are removed, it assigns the associated subscribers to Vlink ID 0. But during the next topology learning, these interfaces may get detected and may be added back to the Cisco Subscriber Manager database. In this scenario, the subscribers who belong to a specific interface that was removed can get back the correct vlink IDs only after the Subscriber Manager receives the IPDR messages or after a manual trigger of the partial vlink query for that device.
From Cisco Service Control Subscriber Manager Release 3.8.5, if new interfaces are learned, the subscribers that are associated with the default vlinks are queried for UpVlink and DownVlink associations.
From Cisco Service Control Subscriber Manager Release 3.8.5, the Cisco Service Control Subscriber Manager allows vlink association of subscribers introduced through DHCP Lease Query LEG and the DHCPv6 Lease Query LEG.
Subscribers introduced through DHCP Lease Query LEGs or DHCPv6 Lease Query LEGs are added to the Cisco Subscriber Manager database. The cable modem MAC of the corresponding Subscribers are added to the SNMP BG queue for vlink association if the subscribers are updated with the giaddr of the corresponding CMTS.
To enable the vlink association of subscribers introduced through the DHCP Lease Query LEG feature, configure the enable_snmp_bg_for_vlinks parameter in the DHCP Lease Query configuration file. For details about configuring the DHCP Lease Query LEG, see the Cisco Service Control Subscriber Manager LEGs User Guide.
This feature is applicable in scenarios where the DHCP Lease Query LEG introduces the subscribers with IP mapping and lease time, and the IPDR LEG is used to update the vlink association of each of these subscribers.
From Cisco Service Control Subscriber Manager Release 3.8.5, you can configure the global_ignore_subscriber_ip parameter or the ignore_subscriber_ip parameter in the IPDR configuration file to ignore the IP mapping of the subscribers who log in through the IPDR LEG. By enabling these parameters, updation of the lease time for IP mappings for each IPDR login is also prevented.
For details about configuring the IPDR LEG, see the Cisco Service Control Subscriber Manager LEGs User Guide.
Cisco SCE virtual links emulate the physical interfaces of the CMTSs and the VLM provisions the links with the bandwidth required to control the traffic:
1. For each CMTS physical interface (either upstream or downstream), the VLM creates a virtual link on the Cisco SCE.
2. VLM maps traffic that travels from a subscriber that is associated with this interface to the virtual link.
3. To create the proper association of subscribers to virtual links, the VLM creates a mapping between the DHCP information (CMTS-ID, upstream-ID, downstream-ID) and the virtual link IDs.
– VLM creates a channel and an upstream virtual link for every upstream-ID on a CMTS.
– VLM creates a legacy channel or wideband and legacy channels for a downstream virtual link for every downstream-ID on a CMTS.
Subscriber management logic is required to associate subscribers with their upstream and downstream virtual links based on the attributes that the DHCP LEG extracts from the DHCP traffic.
For a downstream virtual link, the Subscriber Manager login determines if the subscriber is associated with legacy or wideband cable modems. Depending on the modem types, subscribers are mapped either to wideband or legacy (primary) channels:
In addition to the virtual links association, the subscriber is also assigned a package. In terms of bandwidth management, you can use only schemes that use one virtual-link-controller per direction; therefore, you should design the bandwidth controller architecture (committed information rate, peak information rate, and assurance level) accordingly.
Note You can disable periodic topology learning using VLM. For more details, about this, see the “Configuring the Virtual Links Manager” section.
These limitations are applicable to the VLM device learning feature:
The following VLM device learning limitations are applicable only to Cisco Service Control SM Releases earlier than Release 3.8.5: