VCS Expressway - Search Loop Detected

[Anthony Chan]

in our VCS Expressway event log i am seeing this event, wondering if someone can tell me what it means please

tvcs: Event="Search Loop Detected" Service="SIP" Src-alias-type="SIP" Src-alias="jeibner.e20@med.ubc.ca" Dst-alias-type="SIP" Dst-alias="sip:jeibner.e20@med.ubc.ca" Call-serial-number="09607aea-572e-11e1-8d5b-0010f30f66b8" Tag="09607c16-572e-11e1-b1b3-0010f30f66b8

" Level="2" UTCTime="2012-02-14 17:05:03,586"

[cfiestas]

same origin as the destination...it seems

Cesar Fiestas

[Solvieg Pagan]

Anthony,

It shows what appears to be a loop in the VCS setup of some sort. Check your search rules and the priorities.

The best document to look at is probably the Basic VCS Control/Expressway configuration document – though this only talks about priorities in the VCS Control / VCS Expressway environment, not priorities to the Directory VCS.

The recommendation is to limit searches as far as possible.

• •a)      To speed up placement of calls
  
• •b)      To minimise unnecessary searches – which are especially a nuisance if trying to debug calling problems
  
• •c)       To ensure that large deployments do not get overloaded with the number of simultaneous searches needed.
  

This means:

• •a)      First search should be on the VCS that the call arrives on
  
• •b)      Then search VCS Control or VCS Expressway (whichever the call did not come in on)
  
• •c)       Then send call to Directory VCS
  
• •d)      Directory VCS forks to all regions simultaneously
  

So in practice this means our recommendations for a system where there are regional VCS Controls and Expressways and the regions are joined by a Directory VCS:

VCS Expressway:

• •a)      Priority 50 – search local zone
  
• •b)      Priority 100 – send to Control
  
• •c)       Priority 150 – DNS zone search (ensure that only non-local zones are sent to DNS zone)
  

VCS Control:

• •a)      Priority 50 – search local zone
  
• •b)      Priority 100 – send to Expressway
  
• •c)       Priority 120 – send to Directory VCS
  

Directory VCS:

• •a)      Priority 80 – send to all regional VCS Controls
  

The other rules are that:

• local domain calls can be sent to Expressway then Control then Directory VCS ... ie. From outside towards the middle
  
• non-local domain calls must always be sent towards the Expressway
  

the corollorary of this is that Directory VCS only ever routes ‘local domain’ calls.

Hope this makes sens.

[awinter2]

Anthony,

the search loop is most likely being seen because the search for 'jeibner.e20@med.ubc.ca' is being sent out the DNS zone and then coming back to the Expressway itself, assuming that the search loop is seen on the VCS for which the SIP DNS SRV records for the 'med.ubc.ca' domain point to.

A dig lookup for the _sips._tcp.med.ubc.ca SRV records show that this points to 'vcs.med.ubc.ca', which I assume is the VCS which this was seen on.

To prevent the Expressway from sending searches out the DNS zone for its own domains (Domains which have their H323 and SIP SRV records pointed to this same Expressway), you should --replace-- your current AnyAlias search rule for your DNS zone with a regex type search rule as follows:

Rule name: AnyAlias except local domains

Priority: The default 150 should be fine unless you have an unconventional search rule setup in which you should use the same priority as your current AnyAlias search rule

Mode: Alias Pattern Match

Pattern type: Regex

Pattern string: (?!.*@%localdomains%$).*

Pattern behaviour: Leave

What this search will do is that it will match any dialed alias as long as it does not end with one of the local SIP domains of this Expressway, meaning that if 'med.ubc.ca' is a local SIP domain on this VCS, the search rule will NOT match anything ending with 'med.ubc.ca' but will match any other non-local SIP domain such as 'alias@cisco.com'.

This is also mentioned in the Cisco TelePresence Video Communication Server Basic Configuration Cisco VCS Control with Cisco VCS Expressway Deployment Guide (X7.0), section 'DNS zone configuration'.

Hope this helps,

Andreas

[Paulo Souza]

Pagan / Andreas,

Folks, have you ever read this guide you're suggesting? I read this guide many times and I think that it is not correct at all when it suggests a example of create search rules to route call between both VCSs.

Look this table and let me know what you think about it:

Guys, following this deployment, no matter which priority my search rules have, if the user registered in any place (internal or external) dial some alias that does not exist, then a loop certainly will occur! Always!

It's like having the "router A" pointing its default route to "router B", and "router B" point its default route to "router A". You got a loop. That's all.

So, what do I do to solve that issue? I don't create a rule "any to any alias" in VCS Expressway, it's not necessary. I know exactly what aliases and E164s my internal endpoints are using, so I create rules that summarize my local endpoints's route.

Please, if I am wrong or didn't realize something, please let me know. I am here to learn with you.

Paulo Souza

[Jens Didriksen]

You use the search rule mentioned by Andreas (and which is in the x7.0 documentation) instead of the "AnyAlias" search rule you refer to above.Works for me.

jens

[Paulo Souza]

Jens,

If you create the DNS Zone as Andreas said and also create the search rules suggested by "Cisco TelePresence Video Communication Server Basic Configuration Cisco VCS Control with Cisco VCS Expressway Deployment Guide (X7.0)" to route call between both VCSs, and also define rule's priority as Pagan said, you will still have the possibilty of a loop to occur!

Do the test, do what the deployment guide tells you to do, then go to any user and ask him to dial "99999" for example. You will see a loop in VCS!

Fortunately, VCS has a loop detect feature!

Paulo Souza

[awinter2]

Paulo,

I think you might have misunderstood how searches work on VCS's. When you have a VCS-C and VCS-E with a traversal zone set up between them, it is totally fine and quite normal to have bi-directional AnyAlias search rules across this traversal zone.

This is fine because the VCS will not send a search back to the VCS it received the sarch from initially (unless the destination alias changes as it is received on the VCS, for example via transforms, FindMe or CPL). In other words, if VCS A sends a search for 'endpoint@company.com' to VCS B via an AnyAlias search rule, VCS B will not send a search back to VCS A for the same alias (But might do so if the alias changes from 'endpoint@company.com' to for instance 'endpoint2@company.com' via FindMe, CPL or a transform).

On top of this the VCS has the loop detection which normally detects loops such as the one described in the initial post, to prevent looping searches to consume all search resources on the VCS.

Hope this helps in clarifying things a bit,

Andreas

[Paulo Souza]

Andreas,

I understand what you said clearly. That's right, but only in theory...

Build a lab following the deployment which you have suggested. When a user dials a alias that does not exist, a alias that is not a "ramal@domain" or a IP address, for example "99999", then VCS-C forwards the call to VCS-E and VCS-E sends it back to VCS-C and... the event "Loop detected" appears.

As I said, the loop does not occur beacause of the loop detect feature in VCS, that's right! Otherwise, it would occur.

Thank for your reply.

Paulo Souza

[awinter2]

Paulo,

I would be very interested to see diagnostics logs from the VCS's where you are seeing this happening on (With 'Networking' set to DEBUG), because the VCS-E should not send the search back to the VCS-C unless the destination alias has changed or a loop has occured further upstream, so if you are able to reproduce this behaviour in lab, feel free to send me a PM and attach such log files.

Regards

Andreas

[Paulo Souza]

Hi Andreas,

I saw it happening in a project the I have made one time. If I have opportunity, I will test this behavior and send the logs to you. But look, what really matters here is: the loop does not occur, VCS cancels the call search after certain numbers of hops. That is nice!

Thank you!

Regards

Paulo Souza

[RAMEEZ RAHIM]

I see this behavior on my VCS.

The VCS doesn't seem to avoid sending the calls back to the Neighbor from which it received the call.