Troubleshooting the Remote Cable MSO Links Solution

Published: August 26, 2014

Introduction

This chapter describes several problem scenarios that you may encounter when using the solution. The problem scenarios and solutions are described under these sections:

Subscriber Complaints

To troubleshoot the cause of bad service to subscribers, consider these points:

  • Congestion in the backbone network may cause congestion in subscriber traffic.
  • Problem with the solution, such as assigning the incorrect policy to the subscriber, or an incorrect interface association, may exist.

To make sure that the problem is not with the Cisco SCE, perform these procedures:

Verifying if the Correct Policy is Enforced on a Specific Subscriber

Step 1 Verify that the Subscriber Manager-Cisco SCE subscriber data is synchronized.

In the Cisco SCE, use the show interface linecard 0 subscriber name < sub MAC > command to verify that the upvlinkId and downVlinkId values are the same as in the p3subs --show -s < sub MAC > Subscriber Manager CLU output and that the subscriber package ID is as expected.

This example shows the output of the Cisco SCE show interface command:

SCE8000#>show interface LineCard 0 subscriber name lynn_jones
 
Subscriber 'lynn_jones' manager: SM
Subscriber 'lynn_jones' properties:
downVlinkId=10
monitor=0
new_classification_policy=0
packageId=0
QpLimit[0..17]=0*17,8
QpSet[0..17]=0*17,1
upVlinkId=10
.
.
.
 

This example shows the output of the Subscriber Manager show command:

>p3subs --show -s lynn_jones
 
Name: lynn_jones
Domain: subscribers
Mappings:
IP: 5.101.5.129/32
Properties:
downVlinkId=10 Name=dev0_9_if19-down
upVlinkId=10 Name=dev0_9_if19-upstream0
Custom Properties:
giaddr=5.101.254.105
Command terminated successfully
 

Step 2 Verify that the Subscriber Manager-Cisco SCE virtual links data is synchronized.

Compare the output of the Cisco SCE show interface linecard 0 virtual-links different-from-template command with the Subscriber Manager p3vlink --show-vlink-data --vlink-name < UpVlinkId/DownVlinkId Name > command to make sure that the PIR configuration is correct.

NoteThe Cisco SCE PIR value is in kilobits. You can calculate the VLM value by performing a multiplication with the relevant CMTS device factor as defined in the vlink.cfg configuration file. The CMTS device factor value appears in the output of the Subscriber Manager CLUp3vlink --show-device -d <device-name>.

The following example shows the output of the Cisco SCE show interface linecard command:

SCE8000#> show interface LineCard 0 virtual-links different-from-template
 
Virtual Link enabled
upstream Virtual-Link:
virtual index=1, name=virtual link 1
channel index=1, name=virtual channel 1, pir=99999, cir=99, al=9, agc index=3
application index=1, name=appGC-1, pir=8000000, cir=0, al=5, agc index=2
virtual index=2, name=virtual link 2
channel index=2, name=virtual channel 2, pir=99999, cir=99, al=9, agc index=7
application index=1, name=appGC-2, pir=8000000, cir=0, al=5, agc index=6
downstream Virtual-Link:
virtual index=3, name=virtual link 3
channel index=3, name=virtual channel 3, pir=99999, cir=99, al=9, agc index=15
application index=1, name=appGC-3, pir=8000000, cir=0, al=5, agc index=12
application index=2, name=appGC1-3, pir=8000000, cir=0, al=5, agc index=13
application index=3, name=appGC2-3, pir=8000000, cir=0, al=5, agc index=14

 

This example shows the output of the p3vlink --show-vlink-data Subscriber Manager command:

p3vlink --show-vlink-data --vlink-name=device_Cmts0/0-downstream1
 
VLink Name: device_Cmts0/0-downstream1
VLink Id: 1
Direction: downstream
SCE Name: sce0
Device Name: device
PIR: 200000000
 
 
Channels related to VLink
<name>-L, index <index>, PIR <value>, CIR <value>
<name>-W, index <index>, PIR <value>, CIR <value>
 
 
Related upstream virtual links —Lists all upstream interface related to the same MAC layer as the selected downstream interface.
device_Cmts0/0-upstream0
device_Cmts0/0-upstream1
device_Cmts0/0-upstream2
device_Cmts0/0-upstream3
 
Command terminated successfully

This example shows the output of the p3vlink --show-device Subscriber Manager command:

p3vlink --show-device -d CMTS1 --detail
 
Name: CMTS1
Host Name: Paris
IP: 192.0.2.10
Type: Static
SCE Related: sce0
Upstream factor: 95
Downstream factor: 95
Last success Query: Thu Jun 19 17:54:48 IDT 2008
Last Query Attempt: Thu Jun 19 17:54:48 IDT 2008
Last Query Status: Completed
Sync state with SCE: done
Sync state with CM: done
Giaddr List: 127.0.0.1
Upstream Global Controllers: None
Downstream Global Controllers: <GC Name>=<GC Value>,<GC Name>=<GC Value>…
isLogAll: true
Num of up interfaces: 6
Num of down interfaces: 2
 
 
VLink Information:
1) Name: CMTS1_Cmts0/0-upstream2, Vlink Id: 1, Direction UP, PIR 5000 kbps.
2) Name: CMTS1_Cmts0/0-downstream1, Vlink Id:1, Direction DOWN, PIR 10000 kbps
Channel Name: <vlink Name>-W, index <value>, PIR <value> kpbs, CIR <value> kpbs
Channel Name: <vlink Name>-L<channel index>, index <value>, PIR <value> kpbs, CIR <value> kpbs
3) Name: CMTS1_Cmts0/0-upstream3, Vlink Id:2, Direction UP, PIR 10000 kbps.
4) Name: CMTS1_Cmts1/0-downstream1, Vlink Id:2, Direction DOWN, PIR 20000 kbps.
5) Name: CMTS1_Cmts0/0-upstream1, Vlink Id:3, Direction UP, PIR 10000 kbps.
6) Name: CMTS1_Cmts1/0-upstream2, Vlink Id:4, Direction UP, PIR 20000 kbps.
7) Name: CMTS1_Cmts1/0-upstream3, Vlink Id:5, Direction UP, PIR 20000 kbps.
8) Name: CMTS1_Cmts1/0-upstream1, Vlink Id:6, Direction UP, PIR 20000 kbps.
 
Command terminated successfully

 
 

To enforce the correct policy on a specific subscriber:

a. Monitor all CMTS device interfaces by using the Subscriber Manager p3vlink --show-device -d NAME [ --detail ] command.

b. Verify that in the output of the CLU Sync state with Cisco SCE is Done.

If Sync state with Cisco SCE is Not Done:

– View the connection state between the Subscriber Manager and the Cisco SCE by using the Subscriber Manager CLU p3net --show -n SCE_NAME .

– Synchronize the Cisco SCE with the CMTS device configuration by using the Subscriber Manager CLU p3vlink --resync -n SCE_NAME .

Step 3 Verify that the VLM-CMTS data is synchronized.

Compare the virtual link names from the Subscriber Manager CLU p3subs --show -s < sub MAC > output with the CMTS configuration to verify that the subscriber is assigned to the correct CMTS and CMTS interface.

NoteThe virtual link name structure is <CTMS_NAME>_<INTERFACE_DESCRIPTION> and is obtained from the configuration file and the SNMP ifTable data.

Ensure that the PIR value is the same as the CMTS interface speed (as taken from the SNMP ifTable data) by comparing the virtual link PIR values from the Subscriber Manager CLU p3vlink --show-vlink-data --vlink-name < UpVlinkId/DownVlinkId Name > with the CMTS configuration.

To ensure that the PIR value is the same as the CMTS interface speed:

a. Use p3vlink --show-device -d < DEVICE_NAME > to verify that:

– The monitor period is not 0.

– The last query completed successfully. Check the user log for reasons for failure.

b. Use p3vlink --start-query -d < DEVICE_NAME > to force a start query on a specific CMTS device.

 

Verifying if the Distribution of Subscribers to the Virtual Link is Correct

Step 1 Obtain the VLM name for a specific interface by using the p3subs --show -s < sub MAC > command, or build the interface name as <CTMS_NAME>_<INTERFACE_DESCRIPTION>.

Step 2 Retrieve the list of subscribers related to a specific interface and compare it with the CMTS data using the p3vlink --show-subs --vlink-name = < UpVlinkId/DownVlinkId Name > command:

p3vlink --show-subs --vlink-name test1_Cmts0/0-upstream2
Subscribers related to device: test1 vlink-id: 5, giaddr: 10.78.233.149, direction UP
010101010101
1 subscriber was found
Command terminated successfully
 

 

Inaccurate, Unavailable, or Missing Reports Information for a Specific CMTS Interface

The Cisco Insight can generate per interface consumption reports that can be used to monitor the solution. The VLM updates the reporter with the interface ID to name data and the Cisco SCE sends the raw data with the interface ID (virtual link).

A problem can stem from the VLM update or from the Cisco SCE RDRs.

Two possible solutions include:

  • Verifying if the Cisco SCE sends virtual link update RDRs (VLUR) to the Collection Manager. For information, see the Cisco SCE8000 10GBE Software Configuration Guide or the Cisco SCE8000 GBE Software Configuration Guide .
  • Verifying if the VLM updates the Collection Manager.

Verifying if the VLM Updates the Collection Manager

Step 1 Verify the connectivity between the Subscriber Manager and the Collection Manager.

View the configured network elements and verify that the Collection Manager exists by using the Subscriber Manager CLU p3net --show-all --detail command.

View the Subscriber Manager-Collection Manager connection properties and state by using the p3net --show -n CM_NAME command, and then verify that the Cisco SCE list property value contains the Cisco SCE to which the CMTS is connected.

To fix the communication problems confirm that the Subscriber Manager configuration file contains the relevant Collection Manager information:

– Check that a Collection Manager Section exists and points to the Cisco SCE section.

– Validate the Collection Manager IP and port.

– Check that the Cisco SCE is related to the Collection Manager.

See the “Information About Communication Failures” section in the “Subscriber Manager Overview” chapter of Cisco Service Control Management Suite Subscriber Manager User Guide .

Step 2 Verify that the VLM and Collection Manager data is synchronized.

Verify that the synchronization state with Collection Manager is set to done using the CLU p3vlink --show-device -d < CMTS_NAME > command. To view a list of configured virtual links, use the Collection Manager CLU update_vlinks.sh --sce =< SCE_IP > --show command.

To fix this problem:

a. Force the VLM and the Collection Manager to synchronize by using the p3vlink --resync -n < CM_NAME > command.

b. For manual configuration, see Cisco Service Control Management Suite Collection Manager User Guide to add virtual links by using the update_vlinks.sh --sce =< SCE_IP > --file=vlinks.csv command.

This example shows the output of the p3net --show -n command:

>p3net --show -n cm0
 
Network Element Information:
============================
Name: cm0
Host: 10.56.197.231
Ip: 10.56.197.231
Port: 14375
Status: Connection ready
Type: Collection Manager
SCE List: sce0
Synchronization Status: Not-done(100% failures)
Redundancy Status: Standalone
Quarantine Status: ok
Command terminated successfully

This example shows the output of the p3vlink --show-device -d command:

>p3vlink --show-device -d test1
 
Device Name: test1
Host Name: singleSimpleDevices
IP: 10.78.233.149
Type: Static
SCE Related: sce1
Upstream factor: 95
Downstream factor: 95
Last success Query: Fri Feb 19 14:29:11 IST 2010
Last Query Attempt: Fri Feb 19 14:29:11 IST 2010
Last Query Status: Completed
Sync state with SCE: Not-done
Sync state with CM: N/A
Giaddr List: 10.78.233.149;
Upstream Global Controllers: None
Downstream Global Controllers: None
isLogAll: true
Num of up interfaces: 8
Num of down interfaces: 2
 
Command terminated successfully

 

This example shows the output of the update_vlinks.sh script:

./update_vlinks.sh --sce=10.56.197.232 --show
.
.
.
TIME_STAMP| SE_IP| VLINK_ID| VLINK_DIRECTION| VLINK_NAME|
----------+------------------+------------------+------------------+------------------------+
.
.
.
2008-12-17| 10.56.197.232| 10| 0| dev0_9_if19-upstream0|
2008-12-17| 10.56.197.232| 10| 1| dev0_9_if19-down|
.
.
.

 

Cisco SCE is Congested, but Connected CMTSs are not Congested

If the virtual link assignment is incorrect or false subscriber login operations are not handled by the correct virtual link controller, virtual links can become congested. To resolve this issue, you must confirm that there are no subscribers associated with the virtual link and also verify that the distribution of subscribers to the virtual link is as expected.

To verify that the distribution of subscribers to the virtual link is as expected, see the “Verifying if the Distribution of Subscribers to the Virtual Link is Correct” section .

Verifying if no Subscriber is Associated with the Default Virtual Link

Step 1 Use the Cisco SCE show interface LineCard 0 subscriber property < upVlinkId|downVlinkId > equals 0 command to ensure that there are no subscribers associated with the default virtual link.

Subscribers in the Cisco SCE can have a virtual link ID set to 0 in several cases:

    • If the giaddr list is learned automatically, a few subscribers may have this policy if they performed the first login from this giaddr. In this case, compare the results with the Subscriber Manager database.
    • If a specific interface or CMTS is removed from the VLM, at some point all the subscribers associated with this interface or CMTS are set to use the default virtual link.
    • No match exists in the DHCP Sniffer LEG mapping table and the LEG is configured to log in a subscriber with the default virtual link.
    • If the interfaces are shut down and followed by a device query. In this case, all subscribers or cable modems associated to the interfaces that are shut down are set to use the default vlink ID. These subscribers or cable modems are added to the primary queue of the SNMP BG process to identify the new vlink associations. After the primary or retry queue completes its query, the subscribers get new vlink associations.
    • If a CMTS is removed from the Subscriber Manager and followed by a device query. In this case, all subscribers or cable modems associated to the removed CMTS are set to use the default vlink ID. As the CMTS is already removed, no SNMP BG query will be performed for these subscribers.
    • If a CMTS is moved from one Cisco SCE to another Cisco SCE. In this case, all subscribers or cable modems that are associated to the interfaces of the CMTS are set to use the default vlink ID. As the CMTS is already moved to another Cisco SCE, no SNMP BG query will be performed for these subscribers. After the IPDR message is received, these subscribers will be added to the primary queue of the SNMP BG process.

The following example shows the output of the show interface LineCard 0 subscriber property upVlinkId equals 0 command:

SCE8000#>show interface LineCard 0 subscriber property upVlinkId equals 0
N/A
000004650001
000004650002
000004650003
000004650004
000004650005
000004650006
000004650007
000004650008
000004650009
00000465000A
00000465006F
000004650070
000004650071
000004650072
000004650073
000004650074
000004650075
000004650076
000004650077
000004650078
0000046500DD
0000046500DE
0000046500DF

This example shows the output of the p3dhcpsniff --show-policy --policy=upVlinkId --detail command:

>p3dhcpsniff --show-policy --policy=upVlinkId --detail
 
Policy Name: upVlinkId
=======================
separator:_
use default: false
default value: 0
allow no package: true
concat option:giaddr,
concat option:82:1,
concat option type: integer,binary
log success: true
log default success: false
Number of mappings: 400
 
5.101.254.100_00010000=9
5.101.254.100_00010003=10
5.101.254.100_80010000=9
5.101.254.100_80010003=10
5.101.254.101_00010000=9
5.101.254.101_00010003=10
5.101.254.101_80010000=9
5.101.254.101_80010003=10
5.101.254.102_00010000=9
5.101.254.102_00010003=10
5.101.254.102_80010000=9
5.101.254.102_80010003=10
5.101.254.103_00010000=9
5.101.254.103_00010003=10
5.101.254.103_80010000=9
5.101.254.103_80010003=10
5.101.254.104_00010000=9
5.101.254.104_00010003=10
5.101.254.104_80010000=9
5.101.254.104_80010003=10
5.101.254.105_00010000=9
5.101.254.105_00010003=10
5.101.254.105_80010000=9
5.101.254.105_80010003=10
5.101.254.106_00010000=9
5.101.254.106_00010003=10
5.101.254.106_80010000=9

 

Verifying Subscribers SNMP BG Process through CLU

From Release 4.2.0, a CLU is added to perform p3vlink utility to check the subscriber's (Cable modem) service flow and vlink association details from the command line. This CLU can be used to check when the subscriber is left with partial vlink mapping and also to cross check the vlink association with actual channel mapping in CMTS.

New CLU will take subscriber id as input and query the CMTS to which the subscriber belongs, by using the giaddrIp property of the subscriber and will report command line about the MAC domain to which the subscriber's service flows are associated, Service flow details for both up/down stream with service flow id, Channel set idto which the service flows are associated, Vlink id of the upstream/downstream with mapping table entry.

The following CLI queries the subscriber vlink details:

>p3vlink --debug-snmp-bg -s <subscriber id>

The following example show the output of p3vlink --debug-snmp-bg -s command:

>p3vlink --debug-snmp-bg -s 010101010101

Subscriber:010101010101
 
Upstream Service flows:4
Service flow id:71 Mac domain:1001 Vlink id:66 ChannelName:cisco_Cable5/0/0-upstream6-L7
Service flow id:55 Mac domain:1001 Vlink id:66 ChannelName:cisco_Cable5/0/0-upstream6-L7
Service flow id:69 Mac domain:1001 Vlink id:66 ChannelName:cisco_Cable5/0/0-upstream6-L7
Service flow id:70 Mac domain:1001 Vlink id:66 ChannelName:cisco_Cable5/0/0-upstream6-L7
Downstream Service flows:4
Service flow id:74 Mac domain:1001 Vlink id:20 ChannelName:cisco_Modular-Cable5/0/0-downstream1-L2
Service flow id:72 Mac domain:1001 Vlink id:20 ChannelName:cisco_Modular-Cable5/0/0-downstream1-L2
Service flow id:73 Mac domain:1001 Vlink id:20 ChannelName:cisco_Modular-Cable5/0/0-downstream1-L2
Service flow id:56 Mac domain:1001 Vlink id:20 ChannelName:cisco_Modular-Cable5/0/0-downstream1-L2
Command terminated successfully
 

User log Messages

The messages that are written to the userlog are categorized based on their severity as:

These are the preconditions of the messages:

  • None—Messages are sent irrespective of the value set in the config file.
  • General.log_all—Messages are sent only if the log_all flag in the general section of the vlink.cfg file is set to true.
  • Device.log_all—Messages are sent only if the log_all flag in the device section is set to true.

User log Error Messages

Table 6-1 lists the error messages that can be written to the userlog.

 

Table 6-1 User log Error Messages

Message
Description
Precondition

Device {0} Error: Speed value {1} cannot be translated to int number.

The SNMP interface provides a non-integer value for the if speed.

None

Device {2}: Cannot create query factory class {0} from jar {1}: Error {3}

Cannot instantiate the class related to the device and responsible for the query operation.

None

Failed to send vlink message to Cisco SCE {0}

An error occurred when trying to update the Cisco SCE with Vlinks. The error is specified in the umlog.

None

Failed to update CM {0} with configuration related to SCE {1}

An error occurred when trying to update the Collection Manager. The error message is specified in the umlog.

None

Clearing {0} vlink information because of the following error:\n

System detected reduction in max valid vlink index in SCE <sceName>, valid vlink index was '<maxVlinkIdInDb>' and it was decreased to <maxValidVlinkIndexInSce>

The VLM deleted all vlinks related to a specific Cisco SCE, because the vlink max valid index was reduced.

None

System detected reduction in max valid vlink index in SCE {0} valid vlink index was '{1} ' and it was decreased to {2}

The VLM detected that the Cisco SCE max valid vlink index was reduced.

None

Failed to allocate virtual link index for interface {0} because of lack of vlink {upstream/downstream} resources in SE {name}

Cisco SCE free vlink indexes are no longer available; abort the vlink creation.

None

SCE {0}, Failed to set pir {1}, to vlink {2}, with vlink id {3}

The Cisco SCE was unable to set the PIR value on the GC. This can occur if the PIR value exceeds the MAX PIR value in the Cisco SCE.

None

Failed to set Host Name <name> to device <DeviceName_A> since it is already occupied by device < DeviceName_B>.

Host name (MIB .1.3.6.1.2.1.1.5.0) duplication, verify that DeviceName_A has different Host Name, remove DeviceName_A, and add it again.

None

SNMP SysName {0} is illegal value for static device {1}, expecting to get {2} value.

Found unexpected sysName for static device query failure.

IP related to static device cannot be moved to other device, IP returns an unexpected sysName value (null/different than current), query operation fails.

Work Around:

Set the sysName related to the IP to the expected one and start query on the device by using p3vlink –start-query CLU command.

If the device IP changes, update the configuration file, load config and restart the query on the device by using the p3vlink –start-query CLU command.

None

Failed to communicate with device {0}, using its giaddr list {1}, number of retries={2}, timeout between retries={3} ms

Device is not responsive to the VLM using its giaddr list. Check physical connection to the device.

None

Failure in Init process; error in LEG synchronization: {0}

The VLM has a failure in the boot, vlink mapping table is not created properly, and needs to provide a support file.

None

Failure in Init process; failed to synchronize LEG with all mappings on {0} minutes

The VLM has a failure in the boot, vlink mapping table is not created properly, and needs to provide a support file.

None

User log Warning Messages

Table 6-2 lists the warning messages that can be written to the userlog.

 

Table 6-2 User log Warning Messages

Message
Description
Precondition

VLM does not have valid RPC connection to Cisco SCE {0}, aborting VLink updates in SCE.

This message is sent when the VLM tries to update the Cisco SCE with vlink information but the RPC connection is missing.

None

Starting up VLM Solution

—

None

VLM Solution is stopped, going to clear all vlink information.

—

None

System detected change in max valid vlink index in SCE '{0} ', valid vlink index is increased from {1} to {2}

The VLM detected that the Cisco SCE max valid vlink index was increased.

None

giaddr value duplication; both devices {0} and {1} are having the same ip definition {2}.

The same IP Address is assigned to two different devices.

The VLM assigns the IP to the latest device.

None

PIR size of {0} kbps is more than SCE {1} max bw size, setting vlink {2} with max sce PIR value: {3}

The device interface bandwidth is higher than the maximum bandwidth of the Cisco SCE, the VLM sets the MAX Cisco SCE bandwidth value instead.

none

SCE {0} does not support vlink functionality, aborting VLink updates in SCE

VLM tries to send message to Cisco SCE, RPC connection is available PQI is installed but VLM is disabled.

To recover from the failure, download the policy that enables vlink support and perform VLM synchronization on the Cisco SCE.

None

VLM did not find any installed application in Cisco SCE {0}

VLM tries to send message to Cisco SCE, RPC connection is available but PQI is missing in the Cisco SCE or Cisco SCEs in cascade.

To recover from the failure, install PQI and download the policy that supports vlink. Perform the VLM synchronization by using the p3vlink –resynch operation/ .

None

Connection interrupts to SCE {0} while trying to download VLM data.

VLM tries to send message to Cisco SCE, RPC connection is not available.

Perform Cisco Subscriber Manager-Cisco SCE disconnection methodology.

None

Failed to set Host Name {0} to device {1} since it is occupied by device {2}

Failed to set hostname to a nonexisting device.

If the device is a static device, send the support file to the tech support.

If the device is dynamic, check if the device was previously deleted by the CLU command or by dynamic giaddr removal procedure.

None

Failed to create CommunityTarget to IP <IP Address>

If VLM is unable to create an SNMP session to the IP address, send the support file to Cisco support.

None

Failed to read sysName related to ip:port {0}, , number of retries={1}, timeout between retries={2} ms

VLM failed to get the sys name MIB value related to IP Address.

Validate that sysName value is set.

None

There are no giaddr related to device {0}, VLM is going to remove it from the system

VLM removes the dynamic device that does not have any giaddr related to it.

None

VLM is disabled or not supported in SCE {0}

Ensure that relevant PQI is installed in the Cisco SCE.

Ensure that the policy with vlink enabled is set in the Cisco SCE.

None

IP {0} Collision detected between Device {1} to the Device {2}, Deleting device {3} and moving its IP data to {4}.

—

None

Collision detected between Device {0} to the Device {1}, assigning IP {2} to device {3}.

—

None

IP {0} found in device {1} collide with main ip address related to Static Device {2}, operation aborted.

—

None

User log Information Messages

Table 6-3 lists the information messages that can be written to the userlog.

 

Table 6-3 User log Information Messages

Message
Description
Precondition

Device {0} was added to VLM

—

None

SCE {0} was added to VLM

—

None

SCE {0} was removed from VLM

—

None

<SCE Name> : Max valid vlink index is set to <value>

This value is read from the Cisco SCE. If the Cisco SCE is not available, the system uses the default value (1023).

General.log_all = true

or

Device.log_all = true

Add device to VLM {name} up factor={1} down factor={2} aliases={3}

Indicates that a new device was added to the VLM database.

The umlog contains the giaddr information.

Device.log_all = true

Create vlink {name} with id {1}, on device {name}

Adds vlink to the VLM.

The umlog contains the database internal data.

Device.log_all = true

delete vlink {name} with id {1}, direction-{2}, on device {name}

Removes vlink from the VLM.

The umlog contains the database internal data.

Device.log_all = true

Delete device {name}

Deletes device from the repository database.

Device.log_all = true

VLM device to remove device {0} since it does not have any giaddr.

The VLM automatically removes the Device {0} because all its giaddr were being removed by the aging mechanism.

None

Virtual Link mappings are missing for subscriber <subscriber_name>, login operation is being delayed, LEG is querying for mappings related to giaddr <ip value>.

While processing DHCP RDR, SCE DHCP SNIFFER detects that Mappings to up/down vlink id are missing.

The RDR message is stored in a queue, and the query operation is initiated.

logAll = true

Or

Print message every 100 occurrences

Virtual Link mappings are missing for subscriber <subscriber_name>, continue login operation with no mappings.

Perform login operation even if mappings are not found.

The VLM query on the device is complete before the message is generated.

logAll = true

Or

Print message every 100 occurrences

Blocking operation for mac <mac id> since vlink policy is still not set for giaddr <IP value>

If the LEG detects that policy mappings are not synchronized with the device, the login operation is blocked.

After the completion of device query, the login operations continue.

logAll = true

Or

Print message every 100 occurrences

Device {0} changed its IP to {1}

The dynamic device changes its IP when:

  • Current IP is not responsive.
  • sysName related to the IP is different from the one defined in the device.

None

Giaddr {0} which was related to device {1} found out to be related to device {2}, VLM starts query on this device

A giaddr which was related to device {1}, is currently related to another device, system tries to query this device.

None

Device {0} was removed

Indicates that a device was removed from the VLM.

None

VLM detected new dynamic device: Device {0} is related to SCE {1}

Creates a dynamic device.

None

Dynamic Device Creation feature is being enabled

The VLM detects configuration file with Dynamic Device Configuration feature enabled.

None

Dynamic Device Creation feature is being disabled.

The VLM detects configuration file with Dynamic Device Configuration feature disabled.

None

IP Collision between Static Device {0} to the Dynamic Device {1}, The Dynamic device is replaced by the Static device.

—

None