Inter-Cluster "Locations" Calculations

We have three CUCM 8.5 clusters globally, connected via an MPLS network. The North American cluster has a SIP trunk to Polycom DMA- both the North American CUCM cluster and Polycom DMA cluster is within the same data center. I have a SIP trunk between the NA CUCM and DMA so audio calls from CUCM can join conferences within the Polycom world, and have a route pattern in NA CUCM pointed to DMA.
For redundancy/effeciency pusposes, the EMEA and APAC CUCM clusters should also have route patterns/trunks pointing directly to the DMA in North America. However, my concern is that while those local cluster may be able to calculate BW consumption correctly to North America (because they'll define their SIP trunks to be in the "North America" location), since it doesn't traverse through the NA CUCM, the NA
"Locations" BW caculation will not show an accurate portrayal of calls active to those remote clusters (or amount of voice BW being consumed on our local MPLS access circuit). Therefore, my preference is to have the remote cluster point their DMA route pattern over our Intercluster Trunks, so WAN BW calculations are correct.
My question is: There is no LOCATIONS "Information sharing" between clusters in CUCM 9.1 (target version), so that EMEA cluster would notify N.A. CUCM cluster that he is utilizing his "NA Locations" for calls (going directly to Polycom DMA), and not going through the NA CUCM cluster, so NA CUCM cluster includes that in his Call Admission Control? I'm comfortable with that not existing in CUCM 8.5, but I know there are Locations/CAC enhancements in 9.1 which I'm not too familiar with.
Thanks!

There is definitely location sharing between clusters in 9.1 using enhanced CAC.
Please refer to the SRND here
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab09/clb09/cac.html#pgfId-1593372
A snapshot is posted here..
Location Bandwidth Manager
The Location Bandwidth Manager (LBM) is a Unified CM Feature Service managed from the serviceability web pages and responsible for all of the Enhanced Location CAC bandwidth functions. The LBM can run on any Unified CM subscriber or as a standalone service on a dedicated Unified CM server in the cluster. A minimum of one instance of LBM must run in each cluster to enable Enhanced Location CAC in the cluster. The LBM performs the following functions:
Locations and links path assembly
Bandwidth calculations over the effective paths in the assembly
Servicing bandwidth requests from the Cisco CallManager service (Unified CM call control)
Replication of bandwidth information to other LBMs within the cluster and between clusters when intercluster Enhanced Location CAC is enabled
Providing configured and dynamic information to serviceability
Updating Location Real-Time Monitoring Tool (RTMT) counters
Using Extensible Markup Language (XML) over TCP for communication to/from the Cisco CallManager service as well as between LBMs

Similar Messages

Inter cluster calling

Hi ,
We have 4 CUCM (7.x) cluster for four regions. Each cluster has 1 Pub. And 3 Subs. I want to enable inter cluster calling because all regions are at our MPLS Network.
Kindly suggest what to do to enable calling across 4 regions.
Regards,
Soni

Hi,
this is the "Contact Center" forum, your post would get better exposure in the "IP Telephony" section, but anyway. The easiest thing would be to set up intercluster trunks between clusters, and perhaps use Locations-based CAC to control the number of calls.
Or, a bit sophisticated approach: use a Gatekeeper (or a cluster of gatekeepers) to decide where to route the calls. You may also use Locations-based CAC or Gatekeeper CAC (or their combination).
G.

Callmanager make the ONnet/Offnet between inter-cluster.

Hi,
I know that the onnet/offnet function can prevent the conference call between outside call to outside call. But i want to run the function between to inter-cluster. If the call from other clusters to call in which is on net phone. it can provide the function. but if the call call in from other cluster which is outside call in. I can separate this traffic by onnet/ off net ?
CCM versiion of Both clusters is 4.13sr3c

Try this link for more information
http://cisco.com/en/US/products/sw/voicesw/ps556/products_administration_guide_chapter09186a00803edae2.html

No Inter-Cluster RTP Stream with Gatekeepers

Hello,
Firstly I am no expert in Cisco telephony as we have just recently migrated to a full Cisco solution, so apologies if I ask a fundamental question.
Client A = Site A
Client B = Site B
Client C = Site C
Site A and Site B are in 1 cluster
Site C is in another cluster
Intra-Cluster Traffic Works
Client A -> Client B within the same cluster (across 2 sites with a low latency link) RTP stream comes up and the call functions as expected.
Inter-Cluster Traffic Fails (GK to GK)
Client C -> Client A this works, the RTP stream comes up and the call functions as expected.
Client A -> Client C this call connects but there is no RTP stream.
We are using G711 across the board and I have captured a wireshark capture from a Client A -> Client C failed call.
I have been going through this capture and noticed that when I search H225 (for the gatekeepers) I see the following –
CS: setup
RAS: admissionRequest
RAS: admissionConfirm
CS: callProeeding
CS: alerting
CS: notify
RAS: registrationRequest
RAS: registrationConfirm
CS: notify
CS: connect
CS: notify
CS: releaseComplete
RAS: disengageRequest (DISCONECT_REASON=2,TIME=1321266127,DURATION=24,DISCONNECT_STRING=no resource,ORIGIN=0,LINE_NUMBER=GK,OUTBUND_GW_IP=..
RAS: disengageConfirm
There are firewalls inbetween and these were the first thing I looked at, but I dont even see any RTP stream trying to be initiated from the far side. Would anyone have any ideas where I could start looking?
Thanks,
Peter

Pat,
I can not talk to the UC540, but I ran into a situation recently where the SIP gateway was sending out the private extension of the phone number instead of the full DID that was registered to the provider. The provider was then blocking call.
In our SIP debugs we saw the RDNIS information of the private extension I believe. The error code we were getting back from SP was code 404 or something along those lines.
I recommend you do some debugs and track where the calls fails, compare the SNR call versus a normal call in the debugs, and then if you still get stuck post running configs and debugs back here.

Callmanager Inter cluster trunk - 6608 MGCP problem

Hi
We have two callmanager clusters linked together with an Inter cluster link and then there is a 6608 GW registered with one cluster here below is a logical ASCII drawing of the setup.
6608--Cluster1--Cluster2
Calls that are made to and from the Cluster1 that the GW is registered to work fine.
But calls that are made to and from the Cluster2 that is on the other end of the Inter cluster trunk ring once and are then disconnected.
I have gone over all codec settings for all the regions and they are all set to G711.
I also tried the same thing with a H323 GW like this.
H323GW--Cluster1--Cluster2
And then all calls work fine.
If anyone has any clue on this I would really appreciate some input.
Kind regards
Gudmundur Thor Johannsson

Sounds like MGCP is not supported on callmanager for inter-cluster gateway . Or it could be a bug. Any thoughts?????

Inter cluster trunks

Is it possible to conect a intercluster trunk between the following 2 CUCM versions
version 5.1 and version 8.5?
All routing is correct and wokting fine however the inter cluster trunk will not allow calls to go through.
Dialed number analyzer confirms the path of teh call is reaching the inter cluster trunk
WHan adding a route pattern to the trunk the status and ip address changes to unknow within the version 5 cucm?

Yes, you can create ICTs from CUCM 5.1 and 8.5. When you create these trunks, it is as good as adding a H323 trunk. Therefore the trunk status would show unknown.
On calls not going through, you might want to consider the number of digits being dialed and what is being sent across the trunk. Also, what message do you get on the call when you dial through the trunk ?

Inter Cluster Trunk DisplayName and AlertingName issue

Hi All
I have an inter cluster trunk between two cluster , one is version 9 and other is 7.
When version 7 phone calls version 9 phone, the Alerting Name on version 7 Phone is not displayed.
When version 9 Phone calls version 7 Phone, the Display Name on version 7 Phone is not displayed.
Any idea?
Fei

Hi,
Can you please change the Service Parameter "Always Display Original Dialed Number" to "False" in the 7.x cluster and try again?
Regards,
Tere.
Please rate useful posts.

CallManager 4.1(3) - Inter-cluster Trunk (ICT) behaviour and config

Hi Guys,
Trying to get some clarification on this. Currently chasing a few different avenues. If anyone knows of some good detailed docco on this (have tried the standard stuff). Or if anyone has any best practice advice, otherwise any one have any comments or insight on the following conversation:
Stage 1 describes the impact of the device pool setting, which is basically how the local CallManager is selected to process the call.
Stage 2 describes how the local callmanager selects the remote destination callmanager
Stage 1 - Phone on side A attempts to make a call to phone on cluster B
If the source phone is in the same device pool as the ICT on cluster A, then the call will be processed by the primary ccm for that device pool. (assuming it is available)
- It will be processed by the Call Manager is homed to rather than the primary Call Manager.
If the source phone is in a different device pool than the ICT on cluster A, then a random ccm in the ICT config will be selected. (Have asked for clarification here)
- Yep, the docs actually say "Selection of Cisco CallManager nodes occurs in a random order"
Stage 2 - One of the Callmanagers in cluster A now has the call to send to the remote cluster B. This is where your ICT config of the 3 callmanagers comes in. The Callmanager will use a round robin basis to select the destination callmanager.
I am still running with this, but initial thoughts are that if your phones are in the same DP as the ICT, then you are basically going to end up with the primary ccm in that DP processing all the calls. In this instance the primary CCM still selects the remote destination callmanager via round robin basis, so the calls will be distributed fairly evenly to the 3 destination servers.
- Not sourced from primary as stated above
- A key point is for them to understand is that all the Call Managers configured in Cluster A ICT must be in the same device pool in the remote cluster B, and the ICT must also be a member of that device pool. So, if they configure CMgr 4 to be a target device within the ICT configuration, yet CMgr 4 isn't a member of the remote ends ICT device pool they will get failing calls. This is because CMgr 4 will receive an H323 call (H225 signalling) from a source IP address that it knows nothing about and hence the H225 daemon will reject the call. Not sure how the local call Mgr handles the rejection of call.
If you wanted to balance the call processing on the local side. I.e. instead of always selecting the primary CCM in the device pool and therefore splitting the call processing amongst the 3 local ccm's in a random fashion. Then you would want to put your phones into a different device pool than the ICT. This will mean that the local callmanager is selected at random.
- Well maybe, random may not mean truely random so they'd just have to give it a go and monitor it. However, it's unclear at this time if the monitoring tools tell us how many outgoing vs incoming calls are processed, and you need to understand this to determine the outgoing loading of each Call Manager. The CallsActive counter registers both incoming and outgoing calls hence you can't really tell. To monitor it for sure they could set up two ICTs, one for incoming calls on for outgoing then at least the loading would be a little clearer. I think the only overhead here is the config effort which shouldn't be too tricky.
The interesting thing is the "random" part. It doesnt make a lot of sense considering device pools are the perfect place to manually distribute the load evenly. I.e. if I had 3 device pools for the end phones, each of them using a different callmanager as it's primary call processor in the CallManager groups.
- Agreed although I would say the usual top down and circular algorithms should be available.

Trunk configuration in Cisco CallManager Administration depends on the network design and call control protocols that are used in the IP WAN. All protocols require that either a signaling interface (trunk) or a gateway must be created to accept and originate calls. For some IP protocols, such as MGCP, you configure trunk signaling on the gateway. You specify the type of signaling interface when you configure the gateway in Cisco CallManager. For example, to configure QSIG connections to Cisco CallManager, you must add an MGCP voice gateway that supports QSIG protocol to the network. You then configure the T1 PRI or E1 PRI trunk interface to use the QSIG protocol type
This URL should help you:
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_administration_guide_chapter09186a00801ec5ce.html

Inter cluster trunk/ ip to ip communication with remote office without ccm

dear sir,
We've both ipipgateway configured to communicate with each other. Attachment pngipipgw1 is our local voice router with destination pattern 3XXXX that need to link with other country Japan with destination pattern 7xxxx . All other country locations is ok except the japan which are using non cisco callmanager to link to our local site with cisco call manager 4.1(3) with destination pattern 3XXXX.
Q1.) Based on the ipipgateway configurations of both parties, please advise any finding/thoughts?
Q2.)At our local site, We have nm-hdv with 2 pvdm simm that configured as dspfarm transcoder. Is it enough to have only 2 pvdm simm out of 5 in the nm-hdv? If we add in new pvdm, do we need any configuration at the voice gateway or we just plug in the hardware?
please advise. thank you very much.
-regards-

Hello chialun
Regarding
Q1. Could you explain a little more about what is the problem you have with the calls between those two sites? Please share which number on one side is calling which other number on the other side and what happens with the call.
Q2. It depends on how are you using your Xcoder resources. If some of your conferences or calls are being terminated because you are running out of resources, it will be advisable to add some more pvdm2 to your router. Also after adding the hardware, you would like to change the configuration to increas the maximum number of transcoding sessions.
Regards
Xabier

Inter-cluster JMS?

We are using weblogic 6.1
Is there a way to set up a JMS destination that is visible
to 2 clusters? For example, I set up a topic for two clusters.
When a message is sent, message driven beans in both clusters
will be notified. How would one set this up? Which cluster
does the destination "live in" and how does the other cluster
learn about it?

I'd suggest posting this in the JMS newsgroup.
-- Rob
Chris wrote:
We are using weblogic 6.1
Is there a way to set up a JMS destination that is visible
to 2 clusters? For example, I set up a topic for two clusters.
When a message is sent, message driven beans in both clusters
will be notified. How would one set this up? Which cluster
does the destination "live in" and how does the other cluster
learn about it?

Call preservation with Gatekeeper controlled inter-cluster trunks on CM8.5

Is call preservation possible with gatekeeper contolled ICT on CM 8.5 when a subscriber goes down? My testing shows the call drops. Can this be corrected?

In the Service Parameters for CUCM H323. Make sure the Allow Peer Preserve H.323 Call is set to True. By default, its False. I noticed this on my H323 gateways I just migrated... dropped CUCM and my calls dropped when they should have stayed up, but did not. See that helps on the GK

Asking for advice for Jabber deployment - multi CUCM cluster\AD domains

I would like some design advice for deploying Jabber and CUPS in our company. We have 2 locations, west coast (SiteA) and east coast (SiteB). Each site have their own CUCM 7.15 clusters, Unity clusters, AD domains (trusted, but not in the same forest).
At SiteA I have setup CUPS (8.6.3.10000-20) and jabber and have it working great.
I would like to setup CUPS\Jabber for SiteB, but they need to be able to IM\call\etc to SiteA (And vice-versa).
SiteA and SiteB both have CUCM LDAP sync turned on, and LDAP directory synced with both domains (although SiteA cannot authenticate to CUCM at SiteB, and vice-versa due to the fact you can only LDAP sync authentication with one domain, CUCM user database contain users from SiteA and SiteB).
We have SIP trucks setup to pass internal calls and line status(BLF) between the trunks, and can communicate via internal extensions just fine.
The problem I’m running into is my jabber-config files uses the EDI directory – which can only look at one domain, so I cannot search the other domain. I believe changing to UDS fixes this, but I understand it would require me to upgrade both CUCM clusters to 8.6.2 - unless I’m mistaken.
I’m aware the desktop sharing will not work until CUCM is upgraded to 8.6.1 or 8.6.2.
I’m wondering if anyone has any advice, or can confirm I’m on the right track. Thanks in advance!

The thing that's important to understand is how CUP and Jabber build the XMPP URI. The URI has a left- and right-hand side; the left is the username while the right is the XMPP domain. CUP uses the LDAP attribute specified in CUCM's LDAP System page, sAMAccountName by default, for the left-hand-side. The right-hand side is the FQDN of the CUP cluster. Jabber must use the same values as CUP when displaying search results. Take note that nowhere in this process does the entire XMPP URI originate from the directory source.
In your case you have two separate CUP clusters in two separate domains. This won't work because when a user searches for a contact in the directory using Jabber, the client will build the XMPP URI as [email protected]. Even if you got the other domain's user objects into the search results the right-hand-side of the URI would be wrong and the presence subscription would never succeed since the other cluster is in another domain. As such your first task must be to move the CUP clusters into the exact same fully-qualified DNS domain. Once this is done you can use Inter-Cluster Peering to build a larger XMPP network in which all users have the same presence domain. If you intend to do Inter-Domain Federation in the future this must be your public DNS domain, not your internal active directory domain. If you use a non-public DNS domain TLS handshake will never succeed for inter-domain federation requests.
Once you have Inter-Cluster Peering in place you can use Active Directory Lightweight Directory Services (the new name for ADAM) to front-end both forests. Both CUCM clusters would need to import the full list of users representing both domains and the sAMAccountNames must be unique across both domains.
Finally, you can instruct Jabber to use UDS and query it's local CUCM cluster which will be able to return a search result from both domains. Since the CUP clusters are peered in the same domain the XMPP URI can be built properly, the presence subscription can be routed to the correct cluster, and life will be good.
By this point hopefully it's clear that EDI won't cut it since it would be limited to only returning search results from the local forest.
Please remember to rate helpful responses and identify helpful or correct answers.

Jabber windows 9.2.6 certificates (sub cluster)

Hi,
We have a 2 node implementation of CIMP 9.1.1 and are attemping to upgrade our jabber for windows client to 9.2.6
Being aware of the cert requirements needed for 9.2.5 onwards we have had the tomcat and cup-xmpp certs signed by our internal CA.
When you https to both the cimp servers they are both OK and the certs and the path look good with no errors.
When you load the jabber client you get different results depending on which member of the subcluster your account is associated with (they are a HA pair).
Having cleared the locally accepted certs from windows first. If I make my account be on the cimp_subscriber I log in (default server using SRV records) and everything is straight in and fine in no problems.
If however I move my accounts to the cimp_publisher I get a vertify certificate warning, which when I accept works fine. If I look at the certificate it only has itself in the certification path, not the root ca's etc.
Looking on OS admin and the certificate manager the cup-xmpp cert is signed by the cup-xmpp-trust cert so I'm a bit stuck!
Any ideas greatefully received!
Thanks
Jon

Is the cup-xmpp certificate on cimp_publisher what you expect it to be if you look at it under Certificate Management? You should be able to see the signing CA information and all in it.
If yes, restart XCP Router and give it another try. The -trust store is mostly irrelevent here. The cup-xmpp-trust store is only used during inter-cluster peering and domain federation because it's what the server will accept from the other party in the TLS handshake. The cup-xmpp is the certificate the server presents to Jabber as the server.
The SRV record isn't checked against the CN of the certificate.
Please remember to rate helpful responses and identify helpful or correct answers.

Automating the creation of a HDinsight cluster

Hi,
I am trying to automate the creation of a HDinsight cluster using Azure Automation to execute a powershell script (the script from the automation gallery). When I try and run this (even without populating any defaults), it errors with the following error:
"Runbook definition is invalid. In a Windows PowerShell Workflow, parameter defaults may only be simple value types (such as integers) and strings. In addition, the type of the default value must match the type of the parameter."
The script I am trying to run is:
<#
This PowerShell script was automatically converted to PowerShell Workflow so it can be run as a runbook.
Specific changes that have been made are marked with a comment starting with “Converter:”
#>
<#
.SYNOPSIS
Creates a cluster with specified configuration.
.DESCRIPTION
Creates a HDInsight cluster configured with one storage account and default metastores. If storage account or container are not specified they are created
automatically under the same name as the one provided for cluster. If ClusterSize is not specified it defaults to create small cluster with 2 nodes.
User is prompted for credentials to use to provision the cluster.
During the provisioning operation which usually takes around 15 minutes the script monitors status and reports when cluster is transitioning through the
provisioning states.
.EXAMPLE
.\New-HDInsightCluster.ps1 -Cluster "MyClusterName" -Location "North Europe"
.\New-HDInsightCluster.ps1 -Cluster "MyClusterName" -Location "North Europe" `
      -DefaultStorageAccount mystorage -DefaultStorageContainer myContainer `
      -ClusterSizeInNodes 4
#>
workflow New-HDInsightCluster99 {
param (
    # Cluster dns name to create
    [Parameter(Mandatory = $true)]
    [String]$Cluster,
    # Location
    [Parameter(Mandatory = $true)]
    [String]$Location = "North Europe",
    # Blob storage account that new cluster will be connected to
    [Parameter(Mandatory = $false)]
    [String]$DefaultStorageAccount = "tavidon",
    # Blob storage container that new cluster will use by default
    [Parameter(Mandatory = $false)]
    [String]$DefaultStorageContainer = "patientdata",
    # Number of data nodes that will be provisioned in the new cluster
    [Parameter(Mandatory = $false)]
    [Int32]$ClusterSizeInNodes = 2,
    # Credentials to be used for the new cluster
    [Parameter(Mandatory = $false)]
    [PSCredential]$Credential = $null
# Converter: Wrapping initial script in an InlineScript activity, and passing any parameters for use within the InlineScript
# Converter: If you want this InlineScript to execute on another host rather than the Automation worker, simply add some combination of -PSComputerName, -PSCredential, -PSConnectionURI, or other workflow common parameters as parameters of
the InlineScript
inlineScript {
  $Cluster = $using:Cluster
  $Location = $using:Location
  $DefaultStorageAccount = $using:DefaultStorageAccount
  $DefaultStorageContainer = $using:DefaultStorageContainer
  $ClusterSizeInNodes = $using:ClusterSizeInNodes
  $Credential = $using:Credential
  # The script has been tested on Powershell 3.0
  Set-StrictMode -Version 3
  # Following modifies the Write-Verbose behavior to turn the messages on globally for this session
  $VerbosePreference = "Continue"
  # Check if Windows Azure Powershell is avaiable
  if ((Get-Module -ListAvailable Azure) -eq $null)
      throw "Windows Azure Powershell not found! Please make sure to install them from
  # Create storage account and container if not specified
  if ($DefaultStorageAccount -eq "") {
      $DefaultStorageAccount = $Cluster.ToLowerInvariant()
      # Check if account already exists then use it
      $storageAccount = Get-AzureStorageAccount -StorageAccountName $DefaultStorageAccount -ErrorAction SilentlyContinue
      if ($storageAccount -eq $null) {
          Write-Verbose "Creating new storage account $DefaultStorageAccount."
          $storageAccount = New-AzureStorageAccount –StorageAccountName $DefaultStorageAccount -Location $Location
      } else {
          Write-Verbose "Using existing storage account $DefaultStorageAccount."
  # Check if container already exists then use it
  if ($DefaultStorageContainer -eq "") {
      $storageContext = New-AzureStorageContext –StorageAccountName $DefaultStorageAccount -StorageAccountKey (Get-AzureStorageKey $DefaultStorageAccount).Primary
      $DefaultStorageContainer = $DefaultStorageAccount
      $storageContainer = Get-AzureStorageContainer -Name $DefaultStorageContainer -Context $storageContext -ErrorAction SilentlyContinue
      if ($storageContainer -eq $null) {
          Write-Verbose "Creating new storage container $DefaultStorageContainer."
          $storageContainer = New-AzureStorageContainer -Name $DefaultStorageContainer -Context $storageContext
      } else {
          Write-Verbose "Using existing storage container $DefaultStorageContainer."
  if ($Credential -eq $null) {
      # Get user credentials to use when provisioning the cluster.
      Write-Verbose "Prompt user for administrator credentials to use when provisioning the cluster."
      $Credential = Get-Credential
      Write-Verbose "Administrator credentials captured. Use these credentials to login to the cluster when the script is complete."
  # Initiate cluster provisioning
  $storage = Get-AzureStorageAccount $DefaultStorageAccount
  New-AzureHDInsightCluster -Name $Cluster -Location $Location `
        -DefaultStorageAccountName ($storage.StorageAccountName + ".blob.core.windows.net") `
        -DefaultStorageAccountKey (Get-AzureStorageKey $DefaultStorageAccount).Primary `
        -DefaultStorageContainerName $DefaultStorageContainer `
        -Credential $Credential `
        -ClusterSizeInNodes $ClusterSizeInNodes
Many thanks
Brett

Hi,
it appears that [PSCredential]$Credential = $null is not correct, i to get the same
error, let me check further on it and revert back to you.
Best,
Amar

RD (Rogue Detector) or RLDP (Rogue Location Discovery Protocol)

Hi all,
Cisco documentaion states that there are two ways for detecting Rogues.
Rogue Detector Access Point
You can make an AP operate as a rogue detector, which allows it to be placed on a trunk port so that it can hear all wired-side connected VLANs. It proceeds to find the client on the wired subnet on all the VLANs. The rogue detector AP listens for Address Resolution Protocol (ARP) packets in order to determine the Layer 2 addresses of identified rogue clients or rogue APs sent by the controller. If a Layer 2 address that matches is found, the controller generates an alarm that identifies the rogue AP or client as a threat. This alarm indicates that the rogue was seen on the wired network.
Rogue Location Discovery Protocol (RLDP)
RLDP is an active approach, which is used when rogue AP has no authentication (Open Authentication) configured. This mode, which is disabled by default, instructs an active AP to move to the rogue channel and connect to the rogue as a client. During this time, the active AP sends deauthentication messages to all connected clients and then shuts down the radio interface. Then, it will associate to the rogue AP as a client.
The AP then tries to obtain an IP address from the rogue AP and forwards a User Datagram Protocol (UDP) packet (port 6352) that contains the local AP and rogue connection information to the controller through the rogue AP. If the controller receives this packet, the alarm is set to notify the network administrator that a rogue AP was discovered on the wired network with the RLDP feature.
So how do you turn on the latter (RLDP)?
Many thx indeed
Ken
The following modes of operations exist:
http://www.cisco.com/en/US/products/hw/wireless/ps430/products_qanda_item09186a00806a4da3.shtml
Q. What are the different modes in which a lightweight access point (LAP) can operate?
A. An LAP can operate in any of these modes:
•Local mode—This is the default mode of operation. When an LAP is placed into local mode, the AP will transmit on the normally assigned channel. However, the AP also monitors all other channels in the band over a period of 180 seconds to scan each of the other channels for 60ms during the non-transmit time. During this time, the AP performs noise floor measurements, measures interference, and scans for IDS events.
•REAP mode—Remote Edge Access Point (REAP) mode enables an LAP to reside across a WAN link and still be able to communicate with the WLC and provide the functionality of a regular LAP. REAP mode is supported only on the 1030 LAPs.
•H-REAP Mode— H-REAP is a wireless solution for branch office and remote office deployments. H-REAP enables customers to configure and control access points (APs) in a branch or remote office from the corporate office through a WAN link without the need to deploy a controller in each office. H-REAPs can switch client data traffic locally and perform client authentication locally when the connection to the controller is lost. When connected to the controller, H-REAPs can also tunnel traffic back to the controller.
•Monitor mode—Monitor mode is a feature designed to allow specified LWAPP-enabled APs to exclude themselves from handling data traffic between clients and the infrastructure. They instead act as dedicated sensors for location based services (LBS), rogue access point detection, and intrusion detection (IDS). When APs are in Monitor mode they cannot serve clients and continuously cycle through all configured channels listening to each channel for approximately 60 ms.
Note: From the controller release 5.0, LWAPPs can also be configured in Location Optimized Monitor Mode (LOMM), which optimizes the monitoring and location calculation of RFID tags. For more information on this mode, refer to Cisco Unified Wireless Network Software Release 5.0.
Note: With controller release 5.2, the Location Optimized Monitor Mode (LOMM) section has been renamed Tracking Optimization, and the LOMM Enabled drop-down box has been renamed Enable Tracking Optimization.
Note: For more information on how to configure Tracking Optimization, read the Optimizing RFID Tracking on Access Points section.
•Rogue detector mode—LAPs that operate in Rogue Detector mode monitor the rogue APs. They do not transmit or contain rogue APs. The idea is that the rogue detector should be able to see all the VLANs in the network since rogue APs can be connected to any of the VLANs in the network (thus we connect it to a trunk port). The switch sends all the rogue AP/Client MAC address lists to the Rogue Detector (RD). The RD then forwards those up to the WLC in order to compare with the MACs of clients that the WLC APs have heard over the air. If MACs match, then the WLC knows the rogue AP to which those clients are connected is on the wired network.
•Sniffer mode—An LWAPP that operates in Sniffer mode functions as a sniffer and captures and forwards all the packets on a particular channel to a remote machine that runs Airopeek. These packets contain information on timestamp, signal strength, packet size and so on. The Sniffer feature can be enabled only if you run Airopeek, which is a third-party network analyzer software that supports decoding of data packets.
•Bridge Mode— Bridge mode is used when the access points are setup in a mesh environment and used to bridge between each other.

Found this in another post here on the forum :
There are 3 ways to detect rogue Aps:
1. Ap in monitor mode (sits and scans all channels. Can detect rogue Aps under 30 seconds
2. RLDP (done passively from normal Aps. Can take up to 15 minutes to detect rogue AP)
3. Rogue Detector (looks for broadcast packets from wireless clients on wired network)
For case number 2, a normal AP would be one in local or h-reap connected mode that normally have clients attached, but that are going off channel occasionally to scan for rogues / noise. The process of trying to validate that there is a network attached rogue (RDLP enabled) could likely be service interrupting depending on your AP layout.
-John

Inter-Cluster "Locations" Calculations

Similar Messages

Maybe you are looking for