1. Home
  2. Cisco Systems
  3. Cisco PIX 515 (fragment-packet)

Cisco PIX 515 (fragment-packet)

I've only recently learned about the capture feature of my PIX firewall, so I have a lot to read. I started trying to view our inbound and outbound packets because of connectivity/speed issues that our company has been having lately. From reading the capture snippets on other sites, one thing that stands our right away are all the (fragment-packet) messages at the end of every line. I saw them during our period of poor/no connectivity, but also afterward once our Internet connection was (mysteriously) restored.

Here is a snip of the lines I'm referring to. Does anyone have any insight as to the severity of this message?

08:39:39.236895 10.6.18.90.2496 > 68.16.146.91.80: S 314594479:314594479(0) win 16384 (fragment- packet) 08:39:39.251253 65.254.254.54.25 > 10.6.18.179.2710: . ack 740886420 win 65535(fragment-packet) 08:39:39.251665 10.6.18.179.2710 > 65.254.254.54.25: . 740890560:740891940(1380) ack 3069560882 win 65085(fragment-packet) 08:39:39.251802 10.6.18.179.2710 > 65.254.254.54.25: . 740891940:740893320(1380) ack 3069560882 win 65085(fragment-packet) 08:39:39.257021 64.213.163.59.80 > 10.6.18.192.2475: . 1476668818:1476670198(1380) ack 1418321126 win 6432(fragment-packet) 08:39:39.259508 64.213.163.59.80 > 10.6.18.192.2475: . 1476670198:1476671578(1380) ack 1418321126 win 6432(fragment-packet) 08:39:39.260026 10.6.18.192.2475 > 64.213.163.59.80: . ack 1476671578 win 65535(fragment-packet) 08:39:39.264650 64.213.163.59.80 > 10.6.18.192.2475: . 1476671578:1476672958(1380) ack 1418321126 win 6432(fragment-packet) 08:39:39.266984 64.213.163.59.80 > 10.6.18.192.2475: . 1476672958:1476674338(1380) ack 1418321126 win 6432(fragment-packet) 08:39:39.267487 10.6.18.192.2475 > 64.213.163.59.80: . ack 1476674338 win 65535(fragment-packet)

08:39:39.966868 74.203.76.250.25 > 10.6.18.179.2695: . ack 1797763617 win 65535(fragment-packet)

08:39:39.967235 10.6.18.179.2695 > 74.203.76.250.25: . 1797769137:1797770517(1380) ack 1948391813 win 65427(fragment-packet) 08:39:39.976862 71.74.56.243.25 > 10.6.18.179.2727: . ack 192335363 win 64860 (fragment- packet) 08:39:39.977229 10.6.18.179.2727 > 71.74.56.243.25: . 192335363:192336743(1380) ack 1095934245 win 65263(fragment-packet) 08:39:40.006942 205.178.149.7.25 > 10.6.18.179.2702: . ack 2158121081 win 16384(fragment-packet) 08:39:40.007323 10.6.18.179.2702 > 205.178.149.7.25: . 2158132121:2158133501(1380) ack 1714527716 win 65056(fragment-packet) 08:39:40.007461 10.6.18.179.2702 > 205.178.149.7.25: . 2158133501:2158134881(1380) ack 1714527716 win 65056(fragment-packet)

Thanks, Paul

Reply to
sintral
Loading thread data ...

A quick search does not turn up any description of the "fragment-packet" output.

Observing that the first packet is a TCP SYN "S" which has by definition a zero length payload (confirmed by "(0)") it cannot mean that the packet is fragmented. My best guess is that it means that the don't fragment bit is *not* set and so the packet can be fragmented.

OH! Or maybe that your capture length is set too short to record all of the packet. That seems more likely, however it must be VERY small to have dropped some of the SYN packet.

formatting link
"capture capture_name [access-list acl_id][buffer bytes] [ethernet-type type][interface name] [packet-length bytes]"

Try setting the packet-length to say 1500 and see what that does.

As to your "problem" I notice that the

I don't think that the "fragment-packet" message is indicative of any problem.

I do notice that the packet lengths are mostly "(1380)" bytes of TCP data. This is shorter than usual and suggests that you are using a VPN or GRE tunnel.

It's possible that path MTU discovery is not working in all cases I suppose.

You couls try setting the TCP MSS or MTU on one of your PC's to say 1400 (interface MTU) or 1300 TCp MSS) see if that makes the problem go away for that machine.

Reply to
bod43

I tried the 1500 packet length, but the results appear to be the same. Each line ends with "(fragment-packet)".

FergCopePIX(config)# capture test access-list acl_out interface inside packet-length 1500 FergCopePIX(config)# show capture test

161 packets captured 17:53:44.425866 10.6.18.10.22 > 97.82.130.132.37211: P 2091233534:2091233682(148) ack 2211605624 win 9648(fragment-packet) 17:53:44.425942 10.6.18.1.22 > 10.6.18.10.43242: P 1323615336:1323615372(36) ack 2224490963 win 4096(fragment-packet) 17:53:44.426125 10.6.18.10.43242 > 10.6.18.1.22: . ack 1323615372 win 63784(fragment-packet) 17:53:44.426369 10.6.18.10.22 > 97.82.130.132.37211: P 2091233682:2091233750(68) ack 2211605624 win 9648(fragment-packet) 17:53:44.560914 97.82.130.132.37211 > 10.6.18.10.22: . ack 2091233682 win 15952(fragment-packet) 17:53:44.731026 97.82.130.132.37211 > 10.6.18.10.22: . ack 2091233750 win 15884(fragment-packet) 17:53:45.259920 10.6.18.179.25 > 84.125.223.85.3380: P 2805034298:2805034583(285) ack 4047761810 win 65498(fragment-packet) 17:53:46.038968 10.6.18.2.1182 > 208.67.222.222.53: udp 30(fragment- packet) 17:53:46.087275 208.67.222.222.53 > 10.6.18.2.1182: udp 94(fragment- packet) 17:53:46.089121 10.6.18.2.1182 > 208.67.222.222.53: udp 44(fragment- packet) 17:53:46.142311 208.67.222.222.53 > 10.6.18.2.1182: udp 88(fragment- packet) 17:53:46.144081 10.6.18.2.1182 > 208.67.222.222.53: udp 48(fragment- packet) 17:53:46.190557 10.6.18.179.25 > 84.125.223.85.3380: . ack 4047761852 win 65456(fragment-packet) 17:53:46.194905 208.67.222.222.53 > 10.6.18.2.1182: udp 80(fragment- packet) 17:53:46.196202 10.6.18.179.25 > 84.125.223.85.3380: P 2805034583:2805034672(89) ack 4047761852 win 65456(fragment-packet) 17:53:46.196538 10.6.18.179.25 > 84.125.223.85.3380: F 2805034672:2805034672(0) ack 4047761852 win 65456(fragment-packet) 17:53:46.265061 10.6.18.83.39962 > 81.184.51.226.25187: udp 31 (fragment-packet) 17:53:46.414941 81.184.51.226.25187 > 10.6.18.83.39962: udp 18 (fragment-packet) 17:53:47.699655 10.6.18.41.3608 > 97.82.130.132.5086: udp 52(fragment- packet) 17:53:48.918348 10.6.18.70.3423 > 64.94.18.213.443: P 4053572625:4053572678(53) ack 2151408752 win 65026(fragment-packet) 17:53:49.120019 64.94.18.213.443 > 10.6.18.70.3423: . ack 4053572678 win 64881(fragment-packet) 17:53:49.280060 64.94.18.213.443 > 10.6.18.70.3423: P 2151408752:2151408805(53) ack 4053572678 win 64881(fragment-packet) 17:53:49.416528 10.6.18.70.3423 > 64.94.18.213.443: . ack 2151408805 win 64973(fragment-packet)
Reply to
sintral

As I said I cannot find any reference to this in the documentation.

You might like to check if it is the representation of the DF bit? Seems unlikely but you never know.

In Windows ping -f sets the DF bit.

I wouldn't worry about it. There are many instances of unexplained output in cisco equipment and one more does not concern me. If you are desperate get a service contract and open a support case with TAC.

Reply to
bod43

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.