Change MTU Size of the Call Manager

[Nikhil.ranjan]

Hello There,

We are going to change the MTU size of the call manager because we have some traffic passing through the ipsec tunnel and the packets are dropping as the size of the packet is increasing as the CUCM is adding headers in the packet and hence the packet size is increasing above 1500. 

So I wanted to know if there is any adverse effects of changing the size of the MTU packet or what are the considerations that we need to keep in mind before making these changes. 

[Ratheesh Kumar]

Hi
This is from the CUCM Install guide. I couldn’t find any adverse effect on changing it, however all nodes should have the same MTU size as it can lead to DB replication errors.

The maximum transmission unit (MTU) represents the largest packet, in bytes, that this host will transmit on the network.


The MTU size that you configure must not exceed the lowest MTU size that is configured on any link in your network.


Default: 1500 bytes


The MTU setting must be the same on all nodes in a cluster

You can set MTU using the command

set network mtu size < value >

You should change on on all nodes. During this change a temporary network connectivity loss will be on the servers.


Cheers
Rath!

***Please rate helpful posts***

[hayden.begley]

In CUCM v14 the command to set MTU has been changed.

use set network mtu <value>

hth

[Dennis Mink]

i know it sounds corny, but it depends. what traffic are you sending down the IPsec tunnel? and how did you conclude that fragmented traffic is not getting through?

[Jonathan Schulenberg]

I used to be a big proponent of this approach since I preferred UDP for SIP trunks; however, the MTU arguably applys to ALL traffic, including received frames. You may see unintended consequences from reducing this unless the setting is truly universal for EVERYTHING that talks to CUCM. All it will take is one process within CUCM to strictly interpret the MTU setting and ingress frames in excess of that could be dropped.

I have somewhat begrudgingly moved to SIP over TCP to allow fragmentation as-needed by the network.

[Nikhil.ranjan]

Hi Jonathan,  

Are you sure that it will apply for the ingress packets as well. But so far we haven't had any issues with changing the MTU size and all seems to work just fine. 

[Jonathan Schulenberg]

After 20 minutes of searching I have not been able to find the specific CSC thread that changed my mind on this. There are other route/switch threads that discuss the topic more generally as well as Google search results which speak to MTU handling on GNU/Linux as a platform - remember that CUCM runs on RHEL. Here are a few examples:

https://supportforums.cisco.com/t5/lan-switching-and-routing/does-mtu-effect-packets-that-are-received-on-an-interface/td-p/2004157

https://supportforums.cisco.com/t5/lan-switching-and-routing/mtu-mismatch-asymmetric-mtu/td-p/2879991

https://stackoverflow.com/questions/6360916/do-mtu-modifications-impact-both-directions

If CUCM is indeed setting the DF bit that would suggest it's using PMTUD (RFC1191) to discover and lower the MTU as-needed. For that feature to work every hop in the path must support ICMP Fragmentation Needed responses - and these ICMP packets must be allowed back to the source (i.e. be careful with your firewall rules).

[Nikhil.ranjan]

I see in the captures that the packets generated for the SIP trunk are marked do not fragment. So we did a packet capture on the call Manager, another packet capture on the switch interface connected to the call Manager and then the capture on the other side of the IPsec tunnel. We saw packets on the CUCM and same packets on the switch directly connected to the switch, but then the packet never reached the other side of the tunnel. And then when we routed our traffic excluding the tunnel, every thing started to work fine. 

So this led to a conclusion that the tunnel was dropping the packets. 

[sicherr12]

Hi Team,

Currently having the same issue across DMVPN tunnel.  CUCM reinvites are not been seen by Voice Gateway running SIP, CUCM is at the hub site while the voice gateway is at the remote site.  When CUCM initiates a message it uses TCP however the router defaults to UPD for SIP unless we change it on dial-peer or global level.  So aside from this workaround what is the solution?  Our VPN tunnels have IP MTU 1400 configured. 

[R0g22]

Are you sure the fragments reach the gateway ? If yes, then add "ip virtual-assembly" to the ingress physical interface on the voice gateway and then test. Check with "show ip statistics" to see if the router is re-fragmenting packets or not.

[sicherr12]

Hi Nipun,

Thanks for your reply.

CUCM is sending DF bit set to "Do Not Fragment" so I'm thinking that this packet would be dropped by the originating DMVPN headend router rather than being fragmented.

The TAC engineer on gateway team confirm that the CUCM reinvite packets are slightly larger in size (1440 bytes) than the Tunnel MTU 1400.  After about 6 Re-Invites without answer the CUCM sends a BYE.

They are currently opening a collab case with the VPN team so that we can further progress this.  I will keep you updated.

[Nikhil.ranjan]

I had the same issue. The packets are sent as do not fragment. Generally it is the case that the larger are fragmented and then sent across the network. Since the packets are marked as do not fragment, router has no option to drop those packets. 

I changed the MTU size, and it is running smoothly for last 5 months.