[cisco-voip] Of Expressways and max-forwards...

[Wes Sisk (wsisk)]

I think maybe you're referring to "forward maximum hop count". That parameter is used to guard against call routing loops caused by numbers being forwarded.

There is also a "max hop" parameter for multicast music on hold. That might be more related to high cpu on boundary devices or failing to receive MMoH.

The risk of increasing the forward hop loop detection is that call routing loops caused by forwarded numbers will consume more circuits. For IP circuits this may not be a big deal. For your pots/t1/e1 circuits you are more likely to consume all available channels and experience fully used circuits. When this happens you're like to see spikes in CPU usage and may experience call throttling like code yellow depending on the rate and extent of the forward loop.

Forward max hop count was put in place to address the situation where 2 users forward their calls to each other. Example: Market and Sales both leave for different appointments and forward their call to the other "for coverage". A call to marketing will reach that marketing line and be forwarded to sales. It reaches sales and is forwarded to marketing. Forwards can be internal or external, and can use number translations and different call routing paths. The forwards are end user initiated and the end user stations/lines may existing on separate systems where there is no single administrative, monitoring, or operational domain.

IP trunks do change this picture some. Call flows that involve this many forwards may be worth a design review.

Expected impact: In the event of a call forwarding loop you are more likely to consume all available traditional trunks. You may experience high cpu and potentially call throttling or code yellow.
Unexpected impacts: Introducing that many touch points in a call flow creates many opportunities for unexpected impacts. Pretty cool that that many call processing events can happen in close enough to real time for the call to be delivered end to end.

Good persistence and great find Gary! Even more kudos for taking time to share your experience with the community.

-Wes

On Nov 15, 2021, at 10:34 AM, Gary Parker <G.J.Parker at lboro.ac.uk<mailto:G.J.Parker at lboro.ac.uk>> wrote:

Eventually we narrowed it down to calls from MRA registered devices on our expressways (mostly Jabber but with a small number of 8845s in staff home offices), as all failed calls had the same source IP address when we looked at the corresponding CDRs; although this wasn’t visible in the SIP traces which made diagnosis harder (source IP address is the subscriber when looking at the CUBE’s SIP ). A quick look at edge and core expressways showed that “max hops” was to set to 15 in the relevant zones. Cisco documentation says this is the default, but suggests to set it higher if calls are failing with a 483 code. So we set the max hops to 70 and calls are now connecting as expected.



So…question: why is the max hops set so low (15) on expressway zones by default when it’s set to 70 on CUBEs, and is there anything this is likely to break/that I should look out for now I’ve made the change?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20211115/c52c3ebd/attachment.htm>