Cisco PIX 515 (fragment-packet)

Discussion in 'Cisco' started by sintral, Mar 6, 2009.

  1. sintral

    sintral Guest

    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 <mss 1460,nop,nop,sackOK>(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 <nop,nop,sack sack 1 {192336743:192340883} >(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
     
    sintral, Mar 6, 2009
    #1
    1. Advertisements

  2. sintral

    bod43 Guest

    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.

    http://www.cisco.com/en/US/docs/security/pix/pix62/command/reference/c.html#wp1053548

    "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.
     
    bod43, Mar 7, 2009
    #2
    1. Advertisements

  3. sintral

    sintral Guest

    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)
     
    sintral, Mar 16, 2009
    #3
  4. sintral

    bod43 Guest

    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.
     
    bod43, Mar 17, 2009
    #4
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.