04-26-2018 03:38 AM - edited 03-18-2019 12:24 PM
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.
04-26-2018 05:39 AM
04-26-2022 10:32 AM - edited 04-26-2022 10:33 AM
In CUCM v14 the command to set MTU has been changed.
use set network mtu <value>
hth
04-26-2018 05:42 AM
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?
04-29-2018 09:37 AM
04-30-2018 04:21 AM
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.
05-01-2018 05:04 AM
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://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).
04-30-2018 04:16 AM
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.
05-30-2018 12:52 PM
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.
05-30-2018 12:56 PM
06-01-2018 07:36 AM
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.
07-29-2018 01:00 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide