UDP Fragmentation of SIP INVITES packets lost

[SLH]

Hello everyone,

I've read many forum posts over the years which helped me solve many problems.  Today, I just can't wrap my head around a solution even though I see lots of information on it.

Cisco IOS XE Software, Version 03.16.03.S

ASR1001-X

The basic problem is UDP fragmentation of large (3k) SIP INVITE packets.  Small SIP OPTIONS packets flow just fine.

The far-side of the ingress interface is a Juniper.  The ingress interface (nat outside) receives all 3 UDP packets sized @ 1514, 1514, 437.  VFR, NAT, and ALG are all enabled.  The egress interface (nat inside) never sees the packets according to Wireshark.  I feel like VFR is reassembling the packet for NAT, then dropping it for some reason.  I've had a similar problem before, but matching up the MTUs, or just using a different port so ALG, VFR didn't get involved seemed to fix the issue.  In this case, I don't have that option and  ingress and egress interfaces are both 1500.  The egress interface is set with encapsulation dot1Q.    

The SIP INVITE is originated outside on the Juniper and will ingress on the GigabitEthernet0/0/4 interface. The Juniper is sending to 10.10.20.100 and the ASR is NATing that to 10.10.10.100. Everything works as intended so long as the UDP packets are small. Once the Juniper sends fragmented UDP (total size 3k, fragmented into 3 udp packets), the packets arrive at the ASR 0/0/4 interface but do not egress out the 0/0/0.2042 interface.

Well, that's it in a nutshell.  

interface GigabitEthernet0/0/4
 ip address 192.168.1.10 255.255.255.254
 ip nat outside
 negotiation auto

interface GigabitEthernet0/0/0
no ip address
negotiation auto

interface GigabitEthernet0/0/0.2042
encapsulation dot1Q 2042
ip address 172.16.72.101 255.255.255.252
ip nat inside

ip nat inside source 10.10.10.100 10.10.20.100

 

[Richard Burts]

We do not know much about your situation including how you have configured NAT. Am I correct in assuming that it is the traditional dynamic nat (private inside to Public outside)? With traditional dynamic nat packets from outside to inside work if they are replies to something originated from inside (there is an entry in the translate table for the private inside address). But packets originated from outside sent to inside do not work if there is not an entry in the translate table for the private IP. Would I be correct in assuming that the SIP INVITE is originated outside and not a response?

[SLH]

Hello Richard, I'm only using static nat on the inside interface such as 

ip nat inside source 10.10.10.100 10.10.20.100

The SIP INVITE is originated outside on the Juniper and will ingress on the GigabitEthernet0/0/4 interface.  The Juniper is sending to 10.10.20.100 and the ASR is NATing that to 10.10.10.100.  Everything works as intended so long as the UDP packets are small.  Once the Juniper sends fragmented UDP (total size 3k, fragmented into 3 udp packets) , the packets arrive at the ASR 0/0/4 interface but do not egress out the 0/0/0.2042 interface.

 

[Richard Burts]

Thanks for clarifying that it is static nat. In that case there is an entry in the translate table and my suggestion that the issue might be nat was not correct. Perhaps you might try setting the MTU of the interface to something larger than the frame size of the INVITE frame?

[ntteducollab]

Hello, have you checked if the router didn't activate the "VFR Detection of Fragment Attacks" feature? Check if there are events with signatures "P_VFR-4-FRAG_*" in the logs or check statistics "show ip virtual-reassembly ethernet1".
In a similar case during peak hours the fragmented package was dropped, disabling Virtual Fragmentation Reassembly helped me.
https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ip-addressing/b-ip-addressing/m_virt-frag-reassembly.html