Fragmentation

[emilio1973]

Hi all,

this message appears on  log in our Cisco 7200 few days ago:

Jun 22 09:50:00 eg07.mad3.anter-x.net 508779: Jun 22 09:49:59.053 CEST: %IP_VFR-4-FRAG_TABLE_OVERFLOW: Serial2/1: the fragment table has reached its maximum threshold 16

I know that is a fragmentation problem that is solved with the command ip virtual-reassembly xx,

but my boss  wants to know who may be sending the large number of fragments (server, vpn conection, and so), before talk with the client.  We know that recently have begun to deploy VoIP. Do you think that may be related?

Thanks

[Giuseppe Larosa · Accepted solution]

Hello Juan,

>> We know that recently have begun to deploy VoIP. Do you think that may be related?

you can exclude VoIP at least for bearer channels RTP packets carrying packetized voice are quite small.

Signalling may use big packets when it needs to download a configuration file in a Voice gateway but keepalives should be small

you should be able to take advantage of an ACL with a line like

permit ip any any fragment log

in order to understand who is sending those fragments the ACL will have other lines to permit other traffic and it may be integrated in current ACL if one is applied inbound to interface ser2/1

you will see messages in router log buffer and eventually exported to syslog

Hope to help

Giuseppe

[emilio1973]

Add an extract of result "debug ip virtual-reassembly" command. I  think that packets can not be reassembled are destined for the ip  address 217.93.163.21 but I'm not sure correctly interpret the output.

Jun 22 12:41:45.616 CEST:  IP VFR:Enqueing packet to IP queue
Jun 22 12:41:45.616 CEST: IP_VFR: all fragments have been switched.
Jun 22 12:41:45.616 CEST: IP_VFR: pak_subblock_free - pak 0x7033DB0
Jun 22 12:41:45.616 CEST: IP_VFR: deleted frag state for  sa:213.190.2.182, da:21                    7.93.163.21, id:57656
Jun 22 12:41:45.616 CEST: IP_VFR: pak_subblock_free - pak 0x8C9F8B4
Jun 22 12:41:45.620 CEST: IP_VFR: fragment (sa:213.190.2.xxx,  da:217.93.163.21,                     id:57657, offset:0, len:1280) in  fast path...
Jun 22 12:41:45.620 CEST: IP_VFR: created frag state for  sa:213.190.2.xxx, da:21                    7.93.163.21, id:57657...
Jun 22 12:41:45.620 CEST: IP_VFR: pak incomplete cpak-offset:0,  cpak-len:1280, f                    lag: 1
Jun 22 12:41:45.620 CEST: IP_VFR: dgrm incomplete, returning...
Jun 22 12:41:45.620 CEST: IP_VFR: fragment (sa:213.190.2.xxx,  da:217.93.163.21,                     id:57657, offset:1280, len:166) in  fast path...
Jun 22 12:41:45.620 CEST: IP_VFR: cpak-offset:0, cpak-len:1280,  npak-offset:1280
Jun 22 12:41:45.620 CEST: IP_VFR: dgrm complete, switching the frags.
Jun 22 12:41:45.620 CEST: IP_VFR: switching fragment (sa:213.190.2.xxx,  da:217.9                    3.163.21, id:57657, offset:0, len:1280)
Jun 22 12:41:45.620 CEST:  IP VFR:Enqueing packet to IP queue
Jun 22 12:41:45.620 CEST: IP_VFR: switching fragment (sa:xxx.190.2.xx,  da:217.93.163.21, id:57657, offset:1280, len:166)
Jun 22 12:41:45.620 CEST:  IP VFR:Enqueing packet to IP queue
Jun 22 12:41:45.620 CEST: IP_VFR: all fragments have been switched.
Jun 22 12:41:45.624 CEST: IP_VFR: pak_subblock_free - pak 0x7039C9C
Jun 22 12:41:45.624 CEST: IP_VFR: deleted frag state for  sa:xxx.190.2.182, da:217.93.163.21, id:57657

[emilio1973]

Thanks Guisseppe. I'll try it and comment the results.