From owner-rtfm@auckland.ac.nz Fri May 4 20:11:45 2001 Received: from mailhost.auckland.ac.nz ([130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22658 for ; Fri, 4 May 2001 20:11:43 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id KAA17880; Sat, 5 May 2001 10:24:59 +1200 (NZST) Received: from smtp.SLAC.Stanford.EDU (SMTP.SLAC.Stanford.EDU [134.79.18.80]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id KAA17871 for ; Sat, 5 May 2001 10:24:57 +1200 (NZST) Received: from CONVERSION-DAEMON by smtp.slac.stanford.edu (PMDF V5.2-33 #37476) id <0GCU00I010XH4F@smtp.slac.stanford.edu> for RTFM@AUCKLAND.AC.NZ; Fri, 4 May 2001 15:24:53 -0700 (PDT) Received: from smtpserv1.SLAC.Stanford.EDU (SMTPSERV1.SLAC.Stanford.EDU [134.79.18.81]) by smtp.slac.stanford.edu (PMDF V5.2-33 #37476) with ESMTP id <0GCU00EBE0XGN9@smtp.slac.stanford.edu> for RTFM@AUCKLAND.AC.NZ; Fri, 04 May 2001 15:24:53 -0700 (PDT) Received: from agamemnon.slac.stanford.edu ([134.79.18.86]) by smtpserv1.slac.stanford.edu (PMDF V5.2-33 #37476) with ESMTP id <0GCU00NIC0XG1A@smtpserv1.slac.stanford.edu> for RTFM@AUCKLAND.AC.NZ; Fri, 04 May 2001 15:24:52 -0700 (PDT) Received: by AGAMEMNON.SLAC.Stanford.EDU with Internet Mail Service (5.5.2653.19) id ; Fri, 04 May 2001 15:24:48 -0700 Content-return: allowed Date: Fri, 04 May 2001 15:24:48 -0700 From: "Logg, Connie A." Subject: UDP fragment packets To: "'RTFM@AUCKLAND.AC.NZ'" Message-id: <76A109862EAED4119176009027EECD1E03D6838D@AGAMEMNON.SLAC.Stanford.EDU> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7BIT I am wondering if there is any concensus on how UDP fragment packets could be counted for flow purposes. I am anaylzing data from Cisco's Netflow feature which is generated by one of our Catalyst 6509s with a MSFC in it. The majority of the UDP data is accounted in records with a source port and destination port of 0. In fact, these packets that are counted in these records are fragments of AFS flows, and I think they should be counted as AFS packets by the Netflow generation code. Here is a detailed decode of a series of packets (transferring a 5700 byte datagram) (hope I have the terminology correct).. I had posed the question to Cisco of how these packets are handled, and the response I first got back is that "we do not understand why anyone would want to count fragment packets". Such is life. I am wondering if you folks have an opinion on how these types of packets should be counted? Thanks, COnnie Connie Logg - Network Analyst - 650-926-2879 Stanford Linear Accelerator Center MS 97; 2575 SandHill Road; Menlo Park CA 94025 "Happiness is found along the way, not at the end of the road" ################################## This example involves the transfer of 5700 bytes of data. Since the mtu is only 1500, this data must be broken up into multiple packets (fragments of the data stream). There are 4 packets in this flow. The first UDP packet contains the port numbers and first part of the data, and the following 3 UDP packets contain the rest of the data. I want to have these counted, because they represent a large portion of the data. The statistics from analyzing the netflow data will be grossly wrong if they are not since we have a lot of large data transfers. The identification field is the key to counting the packets correctly. For the results that I see when I compare a packet capture with the netflow records, it appears that the last 3 packets are not counted. The last 3 fragment packets of the file transfer are indeed complete packets. The term "fragment" comes from the IP spec. That is why I called them fragments. If you look at the packet decodes I sent you will see the "fragment" bits. I pointed to them. Packet 1: has ports in it for level 3 decode --------- ----- Level # 1 is ETHERNET Offset: 0 Size: 14 Dest Address : Cisco -07-ac-10 00 00 0c 07 ac 10 ...... Source Address : Sun -9a-d8-b3 08 00 20 9a d8 b3 .. ... Type : 2048 (DoD IP) 08 00 .. ----- Level # 2 is DoD IP Offset: 14 Size: 20 Version : 4 4 . Header Length : 20 5 . Type Of Service: 0 00 . : 000..... Routine : ...0.... Normal Delay : ....0... Normal Throughput : .....0.. Normal Reliability Total Length : 1500 05 dc .. Identification : 2736 0a b0 <---critical info Flags : 3 3 . : 0.. Reserved : .1. Don't Fragment : ..1 More Fragments <--- note more fragments to come Fragment Offset: 0 60 00 `. Time To Live : 255 ff . Protocol : 17 (DODUDP) 11 . Header Checksum: 44704 ae a0 .. Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 6d .O.m Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 79 ...y ----- Level # 3 is DoD UDP Offset: 34 Size: 8 < note has ports in it Source Port : 7000 (AFS3-FILESERVER) 1b 58 .X Dest Port : 7001 (AFS3-CALLBACK) 1b 59 .Y Length : 5700 16 44 .D Checksum : 23042 5a 02 Z. ----- Level # 7 is UserData Offset: 42 Size: 1476 00032: a5 f5 c1 83 67 08 ....g. 00048: 90 3c 00 00 00 07 00 00 00 01 00 00 00 08 01 02 .<.............. .... Packet 2: UDP data packet with NO port info...just data --------- Frame 49 Size 1518 Absolute Time Apr 26 15:41:35.401 ASCII MODE ------------------------------------------------------------------------------- ----- Level # 1 is ETHERNET Offset: 0 Size: 14 Dest Address : Cisco -07-ac-10 00 00 0c 07 ac 10 ...... Source Address : Sun -9a-d8-b3 08 00 20 9a d8 b3 .. ... Type : 2048 (DoD IP) 08 00 .. ----- Level # 2 is DoD IP Offset: 14 Size: 20 Version : 4 4 . Header Length : 20 5 . Type Of Service: 0 00 . : 000..... Routine : ...0.... Normal Delay : ....0... Normal Throughput : .....0.. Normal Reliability Total Length : 1500 05 dc .. Identification : 2736 0a b0 <- critical info Flags : 3 3 . : 0.. Reserved : .1. Don't Fragment : ..1 More Fragments <--more fragments to come Fragment Offset: 1480 60 b9 `. Time To Live : 255 ff . Protocol : 17 (DODUDP) 11 . Header Checksum: 44519 ad e7 .. Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 6d .O.m Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 79 ...y ----- Level # 7 is UserData Offset: 34 Size: 1484 00032: 65 64 75 20 4e 4f 5f 55 4e 49 58 49 44 20 edu NO_UNIXID Packet 3: Another fragment...udp data packet only --------- Frame 50 Size 1518 Absolute Time Apr 26 15:41:35.402 ASCII MODE ------------------------------------------------------------------------------- ----- Level # 1 is ETHERNET Offset: 0 Size: 14 Dest Address : Cisco -07-ac-10 00 00 0c 07 ac 10 ...... Source Address : Sun -9a-d8-b3 08 00 20 9a d8 b3 .. ... Type : 2048 (DoD IP) 08 00 .. ----- Level # 2 is DoD IP Offset: 14 Size: 20 Version : 4 4 . Header Length : 20 5 . Type Of Service: 0 00 . : 000..... Routine : ...0.... Normal Delay : ....0... Normal Throughput : .....0.. Normal Reliability Total Length : 1500 05 dc .. Identification : 2736 0a b0 <--critical info Flags : 3 3 . : 0.. Reserved : .1. Don't Fragment : ..1 More Fragments <--------more fragments to come Fragment Offset: 2960 61 72 ar Time To Live : 255 ff . Protocol : 17 (DODUDP) 11 . Header Checksum: 44334 ad 2e .. Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 6d .O.m Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 79 ...y ----- Level # 7 is UserData Offset: 34 Size: 1484 00032: 73 61 2e 69 6e 66 6e 2e 69 74 20 43 4f 53 sa.infn.it COS 00048: 54 41 4e 54 49 20 43 6f 73 74 61 6e 74 69 6e 69 TANTI Costantini Packet 4: Last UDP data packet --------- Frame 51 Size 1298 Absolute Time Apr 26 15:41:35.402 ASCII MODE ------------------------------------------------------------------------------- ----- Level # 1 is ETHERNET Offset: 0 Size: 14 Dest Address : Cisco -07-ac-10 00 00 0c 07 ac 10 ...... Source Address : Sun -9a-d8-b3 08 00 20 9a d8 b3 .. ... Type : 2048 (DoD IP) 08 00 .. ----- Level # 2 is DoD IP Offset: 14 Size: 20 Version : 4 4 . Header Length : 20 5 . Type Of Service: 0 00 . : 000..... Routine : ...0.... Normal Delay : ....0... Normal Throughput : .....0.. Normal Reliability Total Length : 1280 05 00 .. Identification : 2736 0a b0 <- critical info Flags : 2 2 . : 0.. Reserved : .1. Don't Fragment : ..0 Last Fragment < last fragment Fragment Offset: 344 42 2b B+ Time To Live : 255 ff . Protocol : 17 (DODUDP) 11 . Header Checksum: 52561 cd 51 .Q Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 6d .O.m Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 79 ...y ----- Level # 7 is UserData Offset: 34 Size: 1264 00032: 70 69 73 61 2e 69 6e 66 6e 2e 69 74 20 42 pisa.infn.it B ##################################### Connie Logg - Network Analyst - 650-926-2879 Stanford Linear Accelerator Center MS 97; 2575 SandHill Road; Menlo Park CA 94025 "Happiness is found along the way, not at the end of the road" From owner-rtfm@auckland.ac.nz Fri May 4 22:47:39 2001 Received: from mailhost.auckland.ac.nz ([130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25919 for ; Fri, 4 May 2001 22:47:36 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id NAA27899; Sat, 5 May 2001 13:12:09 +1200 (NZST) Received: from smtp7ve.mailsrvcs.net (smtp7vepub.gte.net [206.46.170.28]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id NAA27894 for ; Sat, 5 May 2001 13:12:06 +1200 (NZST) Received: from sphynx (adsl-162-83-199-204.nyc.adsl.bellatlantic.net [162.83.199.204]) by smtp7ve.mailsrvcs.net (8.9.1/8.9.1) with SMTP id BAA17683401; Sat, 5 May 2001 01:20:39 GMT Reply-To: From: "Carter Bullard" To: "'Logg, Connie A.'" , "'RTFM@AUCKLAND.AC.NZ'" Subject: RE: UDP fragment packets Date: Fri, 4 May 2001 21:11:19 -0400 Message-ID: <38E99DA2CEFA7248B5828BBF99344D86CC05@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D0_01C0D4DE.C6D80D10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <76A109862EAED4119176009027EECD1E03D6838D@AGAMEMNON.SLAC.Stanford.EDU> Sender: owner-rtfm@auckland.ac.nz Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00D0_01C0D4DE.C6D80D10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hey Connie, Argus-2.0.1 accounts for fragments by updating the parent flow, i.e. the flow that is indexed by the first packet in a collection of fragments. If the first packet is not observed, then there is no information that will allow you to index back to the parent flow, and so Argus generates a separate flow for the stream of fragments, that is defined by: src IP addr dst IP addr proto ip_id This is reported as a special fragmented packet flow. These are generally 2-4 packet flows, and so its rather inefficient when there are a lot of them. Aggregation can merge these fragmented packet flows together by ignoring the ip_id tag, allowing you to minimize the number of flows reported when there are a lot of fragments where the first packet is not seen. The aggregated flow should retain the indication that the flow is a partially assembled fragment flow. Because Cisco has no state for tracking fragments, they are just aggregating with the information available in the immediate packet, src, dst addrs and proto. Hope this helps, Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter@qosient.com Phone +1 212 588-9133 Fax +1 212 588-9134 http://qosient.com > -----Original Message----- > From: owner-rtfm@auckland.ac.nz [mailto:owner-rtfm@auckland.ac.nz]On > Behalf Of Logg, Connie A. > Sent: Friday, May 04, 2001 6:25 PM > To: 'RTFM@AUCKLAND.AC.NZ' > Subject: UDP fragment packets > > > I am wondering if there is any concensus on how UDP fragment > packets could be counted for flow purposes. > > I am anaylzing data from Cisco's Netflow feature which is > generated by one of our Catalyst 6509s > with a MSFC in it. > > The majority of the UDP data is accounted in records with a > source port and destination port of 0. > > In fact, these packets that are counted in these records are > fragments of AFS flows, and I think they should be > counted as AFS packets by the Netflow generation code. > > Here is a detailed decode of a series of packets > (transferring a 5700 byte datagram) (hope I have the terminology > correct).. I had posed the question to Cisco of how these > packets are handled, and the response I first > got back is that "we do not understand why anyone would want > to count fragment packets". Such is life. > > I am wondering if you folks have an opinion on how these > types of packets should be counted? > > Thanks, COnnie > > Connie Logg - Network Analyst - 650-926-2879 > Stanford Linear Accelerator Center > MS 97; 2575 SandHill Road; Menlo Park CA 94025 > "Happiness is found along the way, not at the end of the road" > > ################################## > This example involves the transfer of 5700 bytes of data. > Since the mtu is only 1500, this data must be broken up into > multiple packets (fragments of the data stream). There are 4 > packets in this flow. The first UDP packet contains the port > numbers and first part of the data, and the following 3 UDP > packets contain the rest of the data. I want to have these > counted, because they represent a large portion of the data. > The statistics from analyzing the netflow data will be > grossly wrong if they are not since we have a lot of large > data transfers. The identification field is the key to > counting the packets correctly. For the results that I see > when I compare a packet capture with the netflow records, it > appears that the last 3 packets are not counted. > > The last 3 fragment packets of the file transfer are indeed > complete packets. The term "fragment" comes from the > IP spec. That is why I called them fragments. If you look > at the packet decodes I sent you will see the "fragment" > bits. I pointed to them. > > Packet 1: has ports in it for level 3 decode > --------- > > ----- Level # 1 is ETHERNET Offset: 0 Size: 14 > > Dest Address : Cisco -07-ac-10 00 00 0c > 07 ac 10 ...... > Source Address : Sun -9a-d8-b3 08 00 20 > 9a d8 b3 .. ... > Type : 2048 (DoD IP) 08 00 > .. > ----- Level # 2 is DoD IP Offset: 14 Size: 20 > > Version : 4 4 > . > Header Length : 20 5 > . > Type Of Service: 0 00 > . > : 000..... Routine > : ...0.... Normal Delay > : ....0... Normal Throughput > : .....0.. Normal Reliability > Total Length : 1500 05 dc > .. > Identification : 2736 0a b0 > <---critical info > Flags : 3 3 > . > : 0.. Reserved > : .1. Don't Fragment > : ..1 More Fragments > <--- note more fragments to come > Fragment Offset: 0 60 00 > `. > Time To Live : 255 ff > . > Protocol : 17 (DODUDP) 11 > . > Header Checksum: 44704 ae a0 > .. > Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 > 6d .O.m > Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 > 79 ...y > ----- Level # 3 is DoD UDP Offset: 34 Size: 8 > < note has ports in it > > Source Port : 7000 (AFS3-FILESERVER) 1b 58 > .X > Dest Port : 7001 (AFS3-CALLBACK) 1b 59 > .Y > Length : 5700 16 44 > .D > Checksum : 23042 5a 02 > Z. > ----- Level # 7 is UserData Offset: 42 Size: 1476 > > 00032: a5 f5 c1 83 67 08 > ....g. > 00048: 90 3c 00 00 00 07 00 00 00 01 00 00 00 08 01 02 > .<.............. > .... > > Packet 2: UDP data packet with NO port info...just data > --------- > > Frame 49 Size 1518 Absolute Time Apr 26 15:41:35.401 ASCII MODE > -------------------------------------------------------------- > ----------------- > ----- Level # 1 is ETHERNET Offset: 0 Size: 14 > > Dest Address : Cisco -07-ac-10 00 00 0c > 07 ac 10 ...... > Source Address : Sun -9a-d8-b3 08 00 20 > 9a d8 b3 .. ... > Type : 2048 (DoD IP) 08 00 > .. > ----- Level # 2 is DoD IP Offset: 14 Size: 20 > > Version : 4 4 > . > Header Length : 20 5 > . > Type Of Service: 0 00 > . > : 000..... Routine > : ...0.... Normal Delay > : ....0... Normal Throughput > : .....0.. Normal Reliability > Total Length : 1500 05 dc > .. > Identification : 2736 0a b0 > <- critical info > Flags : 3 3 > . > : 0.. Reserved > : .1. Don't Fragment > : ..1 More Fragments > <--more fragments to come > Fragment Offset: 1480 60 b9 > `. > Time To Live : 255 ff > . > Protocol : 17 (DODUDP) 11 > . > Header Checksum: 44519 ad e7 > .. > Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 > 6d .O.m > Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 > 79 ...y > ----- Level # 7 is UserData Offset: 34 Size: 1484 > > 00032: 65 64 75 20 4e 4f 5f 55 4e 49 58 49 44 20 > edu NO_UNIXID > > > Packet 3: Another fragment...udp data packet only > --------- > > Frame 50 Size 1518 Absolute Time Apr 26 15:41:35.402 ASCII MODE > -------------------------------------------------------------- > ----------------- > ----- Level # 1 is ETHERNET Offset: 0 Size: 14 > > Dest Address : Cisco -07-ac-10 00 00 0c > 07 ac 10 ...... > Source Address : Sun -9a-d8-b3 08 00 20 > 9a d8 b3 .. ... > Type : 2048 (DoD IP) 08 00 > .. > ----- Level # 2 is DoD IP Offset: 14 Size: 20 > > Version : 4 4 > . > Header Length : 20 5 > . > Type Of Service: 0 00 > . > : 000..... Routine > : ...0.... Normal Delay > : ....0... Normal Throughput > : .....0.. Normal Reliability > Total Length : 1500 05 dc > .. > Identification : 2736 0a b0 > <--critical info > Flags : 3 3 > . > : 0.. Reserved > : .1. Don't Fragment > : ..1 More Fragments > <--------more fragments to come > Fragment Offset: 2960 61 72 > ar > Time To Live : 255 ff > . > Protocol : 17 (DODUDP) 11 > . > Header Checksum: 44334 ad 2e > .. > Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 > 6d .O.m > Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 > 79 ...y > ----- Level # 7 is UserData Offset: 34 Size: 1484 > > 00032: 73 61 2e 69 6e 66 6e 2e 69 74 20 43 4f 53 > sa.infn.it COS > 00048: 54 41 4e 54 49 20 43 6f 73 74 61 6e 74 69 6e 69 > TANTI Costantini > > > Packet 4: Last UDP data packet > --------- > > Frame 51 Size 1298 Absolute Time Apr 26 15:41:35.402 ASCII MODE > -------------------------------------------------------------- > ----------------- > ----- Level # 1 is ETHERNET Offset: 0 Size: 14 > > Dest Address : Cisco -07-ac-10 00 00 0c > 07 ac 10 ...... > Source Address : Sun -9a-d8-b3 08 00 20 > 9a d8 b3 .. ... > Type : 2048 (DoD IP) 08 00 > .. > ----- Level # 2 is DoD IP Offset: 14 Size: 20 > > Version : 4 4 > . > Header Length : 20 5 > . > Type Of Service: 0 00 > . > > : 000..... Routine > : ...0.... Normal Delay > : ....0... Normal Throughput > : .....0.. Normal Reliability > Total Length : 1280 05 00 > .. > Identification : 2736 0a b0 > <- critical info > Flags : 2 2 > . > : 0.. Reserved > : .1. Don't Fragment > : ..0 Last Fragment > < last fragment > Fragment Offset: 344 42 2b > B+ > Time To Live : 255 ff > . > Protocol : 17 (DODUDP) 11 > . > Header Checksum: 52561 cd 51 > .Q > Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 > 6d .O.m > Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 > 79 ...y > ----- Level # 7 is UserData Offset: 34 Size: 1264 > > 00032: 70 69 73 61 2e 69 6e 66 6e 2e 69 74 20 42 > pisa.infn.it B > > ##################################### > > > Connie Logg - Network Analyst - 650-926-2879 > Stanford Linear Accelerator Center > MS 97; 2575 SandHill Road; Menlo Park CA 94025 > "Happiness is found along the way, not at the end of the road" > ------=_NextPart_000_00D0_01C0D4DE.C6D80D10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: UDP fragment packets

Hey Connie,
   Argus-2.0.1 accounts for fragments by = updating the parent
flow, i.e. the flow that is indexed by the first = packet in
a collection of fragments.  If the first packet = is not observed,
then there is no information that will allow you to = index back
to the parent flow, and so Argus generates a separate = flow
for the stream of fragments, that is defined = by:
   src IP addr
   dst IP addr
   proto
   ip_id

This is reported as a special fragmented packet = flow.
These are generally 2-4 packet flows, and so its = rather
inefficient when there are a lot of them.  = Aggregation can
merge these fragmented packet flows together by = ignoring
the ip_id tag, allowing you to minimize the number of = flows
reported when there are a lot of fragments where the = first
packet is not seen.  The aggregated flow should = retain
the indication that the flow is a partially = assembled
fragment flow.

   Because Cisco has no state for tracking = fragments,
they are just aggregating with the information = available
in the immediate packet, src, dst addrs and = proto.

Hope this helps,

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

carter@qosient.com
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com



> -----Original Message-----
> From: owner-rtfm@auckland.ac.nz [mailto:owner-rtfm@auckland.ac.n= z]On
> Behalf Of Logg, Connie A.
> Sent: Friday, May 04, 2001 6:25 PM
> To: 'RTFM@AUCKLAND.AC.NZ'
> Subject: UDP fragment packets
>
>
> I am wondering if there is any concensus on how = UDP fragment
> packets could be counted for flow = purposes.
>
> I am anaylzing data from Cisco's Netflow feature = which is
> generated by one of our Catalyst 6509s
> with a MSFC in it.
>
> The majority of the UDP data is accounted in = records with a
> source port and destination port of 0.
>
> In fact, these packets that are counted in these = records are
> fragments of AFS flows, and I think they should = be
> counted as AFS packets by the Netflow generation = code.
>
> Here is a detailed decode of a series of packets =
> (transferring a 5700 byte datagram) (hope I have = the terminology
> correct)..  I had posed the question to = Cisco of how these
> packets are handled, and the response I = first
> got back is that "we do not understand why = anyone would want
> to count fragment packets".  Such is = life.
>
> I am wondering if you folks have an opinion on = how these
> types of packets should be counted?
>
> Thanks, COnnie
>
> Connie Logg - Network Analyst - = 650-926-2879
> Stanford Linear Accelerator Center
> MS 97; 2575 SandHill Road; Menlo Park CA = 94025
> "Happiness is found along the way, not at = the end of the road"
>
> ##################################
> This example involves the transfer of 5700 bytes = of data. 
> Since the mtu is only 1500, this data must be = broken up into
> multiple packets (fragments of the data stream). = There are 4
> packets in this flow.  The first UDP packet = contains the port
> numbers and first part of the data, and the = following 3 UDP
> packets contain the rest of the data.  I = want to have these
> counted, because they represent a large portion = of the data. 
> The statistics from analyzing the netflow data = will be
> grossly wrong if they are not since we have a = lot of large
> data transfers. The identification field is the = key to
> counting the packets correctly.  For the = results that I see
> when I compare a packet capture with the netflow = records, it
> appears that the last 3 packets are not = counted.
>
> The last 3 fragment packets of the file transfer = are indeed
> complete packets. The term "fragment" = comes from the
> IP spec.  That is why I called them = fragments.  If you look
> at the packet decodes I sent you will see the = "fragment"
> bits.  I pointed to them.
>
> Packet 1:  has ports in it for level 3 = decode
> ---------
>
> ----- Level # 1 is ETHERNET Offset: 0 Size: = 14
> 
>  Dest Address   : = Cisco   = -07-ac-10          &nbs= p;     00 00 0c
> 07 ac 10  ......
>  Source Address : = Sun     = -9a-d8-b3          &nbs= p;     08 00 20
> 9a d8 b3  .. ...
>  = Type           : 2048 = (DoD = IP)           &nbs= p;        08 = 00     
>         = ..
> ----- Level # 2 is DoD IP Offset: 14 Size: = 20
> 
>  = Version        : = 4            =             &= nbsp;        = 4        
>         = .
>  Header Length  : = 20            = ;            =         = 5        
>         = .
>  Type Of Service: = 0            =             &= nbsp;       = 00        
>         = .
>          =        : 000..... Routine
>          =        : ...0.... Normal Delay
>          =        : ....0... Normal Throughput
>          =        : .....0.. Normal = Reliability
>  Total Length   : = 1500           &nb= sp;           &nbs= p;     05 dc     
>         = ..
>  Identification : = 2736           &nb= sp;           &nbs= p;     0a b0     
>         = <---critical info     
>  = Flags          : = 3            =             &= nbsp;        = 3        
>         = .
>          =        : 0.. Reserved
>          =        : .1. Don't Fragment
>          =        : ..1 More = Fragments          &nbs= p;            = ;  
>         = <--- note more fragments to come
>  Fragment Offset: = 0            =             &= nbsp;       60 = 00     
>         = `.
>  Time To Live   : = 255           &nbs= p;            = ;      = ff        
>         = .
>  = Protocol       : 17 = (DODUDP)           = ;           = 11        
>         = .
>  Header Checksum: = 44704           &n= bsp;           &nb= sp;    ae a0     
>         = ..
>  Source Address : [134.79.16.109] = AFS09.SLAC.Stanfo86 4f 10
> 6d        = .O.m
>  Dest Address   : = [128.138.133.121] blanca.Colorado80 8a 85
> 79        = ...y
> ----- Level # 3 is DoD UDP Offset: 34 Size: = 8            =     
>         = < note has ports in it
> 
>  Source Port    : 7000 = (AFS3-FILESERVER)         &n= bsp; 1b 58     
>         = .X
>  Dest Port      : = 7001 = (AFS3-CALLBACK)         &nbs= p;   1b 59     
>         = .Y
>  = Length         : = 5700           &nb= sp;           &nbs= p;     16 44     
>         = .D
>  = Checksum       : = 23042           &n= bsp;           &nb= sp;    5a 02     
>         = Z.
> ----- Level # 7 is UserData Offset: 42 Size: = 1476
> 
>   = 00032:           &= nbsp;           &n= bsp;       a5 f5 c1 83 67 = 08     
>        = ....g.
>   00048: 90 3c 00 00 00 07 00 00 00 01 = 00 00 00 08 01 02  
> .<..............
> ....
>
> Packet 2: UDP data packet with NO port = info...just data
> ---------
>
> Frame 49 Size  1518 Absolute Time Apr 26 = 15:41:35.401 ASCII MODE
> = --------------------------------------------------------------
> -----------------
> ----- Level # 1 is ETHERNET Offset: 0 Size: = 14
> 
>  Dest Address   : = Cisco   = -07-ac-10          &nbs= p;     00 00 0c
> 07 ac 10  ......
>  Source Address : = Sun     = -9a-d8-b3          &nbs= p;     08 00 20
> 9a d8 b3  .. ...
>  = Type           : 2048 = (DoD = IP)           &nbs= p;        08 = 00     
>         = ..
> ----- Level # 2 is DoD IP Offset: 14 Size: = 20
> 
>  = Version        : = 4            =             &= nbsp;        = 4        
>         = .
>  Header Length  : = 20            = ;            =         = 5        
>         = .
>  Type Of Service: = 0            =             &= nbsp;       = 00        
>         = .
>          =        : 000..... Routine
>          =        : ...0.... Normal Delay
>          =        : ....0... Normal Throughput
>          =        : .....0.. Normal = Reliability
>  Total Length   : = 1500           &nb= sp;           &nbs= p;     05 dc     
>         = ..
>  Identification : = 2736           &nb= sp;           &nbs= p;     0a b0     
>          = <- critical info
>  = Flags          : = 3            =             &= nbsp;        = 3        
>         = .
>          =        : 0.. Reserved
>          =        : .1. Don't Fragment
>          =        : ..1 More = Fragments          &nbs= p;            = ;  
>          = <--more fragments to come
>  Fragment Offset: = 1480           &nb= sp;           &nbs= p;     60 b9     
>         = `.
>  Time To Live   : = 255           &nbs= p;            = ;      = ff        
>         = .
>  = Protocol       : 17 = (DODUDP)           = ;           = 11        
>         = .
>  Header Checksum: = 44519           &n= bsp;           &nb= sp;    ad e7     
>         = ..
>  Source Address : [134.79.16.109] = AFS09.SLAC.Stanfo86 4f 10
> 6d        = .O.m
>  Dest Address   : = [128.138.133.121] blanca.Colorado80 8a 85
> 79        = ...y
> ----- Level # 7 is UserData Offset: 34 Size: = 1484
> 
>   = 00032:       65 64 75 20 4e 4f 5f 55 4e 49 = 58 49 44 20    
> edu NO_UNIXID
>
>
> Packet 3: Another fragment...udp data packet = only
> ---------
>
> Frame 50 Size  1518 Absolute Time Apr 26 = 15:41:35.402 ASCII MODE
> = --------------------------------------------------------------
> -----------------
> ----- Level # 1 is ETHERNET Offset: 0 Size: = 14
> 
>  Dest Address   : = Cisco   = -07-ac-10          &nbs= p;     00 00 0c
> 07 ac 10  ......
>  Source Address : = Sun     = -9a-d8-b3          &nbs= p;     08 00 20
> 9a d8 b3  .. ...
>  = Type           : 2048 = (DoD = IP)           &nbs= p;        08 = 00     
>         = ..
> ----- Level # 2 is DoD IP Offset: 14 Size: = 20
> 
>  = Version        : = 4            =             &= nbsp;        = 4        
>         = .
>  Header Length  : = 20            = ;            =         = 5        
>         = .
>  Type Of Service: = 0            =             &= nbsp;       = 00        
>         = .
>          =        : 000..... Routine
>          =        : ...0.... Normal Delay
>          =        : ....0... Normal Throughput
>          =        : .....0.. Normal = Reliability
>  Total Length   : = 1500           &nb= sp;           &nbs= p;     05 dc     
>         = ..
>  Identification : = 2736           &nb= sp;           &nbs= p;     0a b0     
>          =    <--critical info
>  = Flags          : = 3            =             &= nbsp;        = 3        
>         = .
>          =        : 0.. Reserved
>          =        : .1. Don't Fragment
>          =        : ..1 More = Fragments          &nbs= p;            = ;  
>          =    <--------more fragments to come
>  Fragment Offset: = 2960           &nb= sp;           &nbs= p;     61 72     
>         = ar
>  Time To Live   : = 255           &nbs= p;            = ;      = ff        
>         = .
>  = Protocol       : 17 = (DODUDP)           = ;           = 11        
>         = .
>  Header Checksum: = 44334           &n= bsp;           &nb= sp;    ad 2e     
>         = ..
>  Source Address : [134.79.16.109] = AFS09.SLAC.Stanfo86 4f 10
> 6d        = .O.m
>  Dest Address   : = [128.138.133.121] blanca.Colorado80 8a 85
> 79        = ...y
> ----- Level # 7 is UserData Offset: 34 Size: = 1484
> 
>   = 00032:       73 61 2e 69 6e 66 6e 2e 69 74 = 20 43 4f 53    
> sa.infn.it COS
>   00048: 54 41 4e 54 49 20 43 6f 73 74 = 61 6e 74 69 6e 69  
> TANTI Costantini
>
>
> Packet 4: Last UDP data packet
> ---------
>
> Frame 51 Size  1298 Absolute Time Apr 26 = 15:41:35.402 ASCII MODE
> = --------------------------------------------------------------
> -----------------
> ----- Level # 1 is ETHERNET Offset: 0 Size: = 14
> 
>  Dest Address   : = Cisco   = -07-ac-10          &nbs= p;     00 00 0c
> 07 ac 10  ......
>  Source Address : = Sun     = -9a-d8-b3          &nbs= p;     08 00 20
> 9a d8 b3  .. ...
>  = Type           : 2048 = (DoD = IP)           &nbs= p;        08 = 00     
>         = ..
> ----- Level # 2 is DoD IP Offset: 14 Size: = 20
> 
>  = Version        : = 4            =             &= nbsp;        = 4        
>         = .
>  Header Length  : = 20            = ;            =         = 5        
>         = .
>  Type Of Service: = 0            =             &= nbsp;       = 00        
>         = .
>
>          =        : 000..... Routine
>          =        : ...0.... Normal Delay
>          =        : ....0... Normal Throughput
>          =        : .....0.. Normal = Reliability
>  Total Length   : = 1280           &nb= sp;           &nbs= p;     05 00     
>         = ..
>  Identification : = 2736           &nb= sp;           &nbs= p;     0a b0     
>          =   <- critical info
>  = Flags          : = 2            =             &= nbsp;        = 2        
>         = .
>          =        : 0.. Reserved
>          =        : .1. Don't Fragment
>          =        : ..0 Last = Fragment           = ;            =    
>          =   < last fragment
>  Fragment Offset: = 344           &nbs= p;            = ;      42 2b      =
>         = B+
>  Time To Live   : = 255           &nbs= p;            = ;      = ff        
>         = .
>  = Protocol       : 17 = (DODUDP)           = ;           = 11        
>         = .
>  Header Checksum: = 52561           &n= bsp;           &nb= sp;    cd 51     
>         = .Q
>  Source Address : [134.79.16.109] = AFS09.SLAC.Stanfo86 4f 10
> 6d        = .O.m
>  Dest Address   : = [128.138.133.121] blanca.Colorado80 8a 85
> 79        = ...y
> ----- Level # 7 is UserData Offset: 34 Size: = 1264
> 
>   = 00032:       70 69 73 61 2e 69 6e 66 6e 2e = 69 74 20 42    
> pisa.infn.it B
>
> #####################################
>
>
> Connie Logg - Network Analyst - = 650-926-2879
> Stanford Linear Accelerator Center
> MS 97; 2575 SandHill Road; Menlo Park CA = 94025
> "Happiness is found along the way, not at = the end of the road"
>

------=_NextPart_000_00D0_01C0D4DE.C6D80D10-- From owner-rtfm@auckland.ac.nz Sun May 6 03:43:38 2001 Received: from mailhost.auckland.ac.nz ([130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05533 for ; Sun, 6 May 2001 03:43:36 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id SAA15074; Sun, 6 May 2001 18:07:24 +1200 (NZST) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id SAA15067 for ; Sun, 6 May 2001 18:07:22 +1200 (NZST) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.10.0/8.10.0) id f4667LK25555; Sat, 5 May 2001 23:07:21 -0700 (PDT) Message-Id: <200105060607.f4667LK25555@daffy.ee.lbl.gov> To: rtfm@auckland.ac.nz Subject: SIGCOMM Internet measurement workshop in November Date: Sat, 05 May 2001 23:07:21 PDT From: Vern Paxson Sender: owner-rtfm@auckland.ac.nz Precedence: bulk [apologies to those who also get a copy of this via end2end-interest or ippm] SIGCOMM is sponsoring an Internet measurement workshop in November of this year. For those potentially interested, I've appended the CFP. We look forward to considering any submissions you might have. Thanks, Vern ACM SIGCOMM Internet Measurement Workshop 2001 November 1-2, 2001 San Francisco Bay Area This ACM SIGCOMM Internet Measurement Workshop is a one and a half day event focusing on Internet measurement and analysis. Submissions should contribute to the current understanding of how to collect or analyze Internet measurements, or give insight into how the Internet behaves. Examples of relevant topics are: * Workload characterization * Traffic engineering * Web measurements * Inter-domain and intra-domain routing * Active measurement techniques * Passive measurement techniques * Anonymization/privacy issues * Calibration * Measurement-based inference of network properties * Efficacy of content distribution networks * Reassessment/testing of previous measurement findings * Assessment of previous simulation/testbed findings Submissions on new ideas and work-in-progress are encouraged. Papers that do not in some fashion rely on measuring Internet properties are out of scope. The workshop is sponsored by ACM SIGCOMM. In addition to the published proceedings, the Program Committee may also select a few papers for fast-track submission for possible publication in IEEE/ACM Transactions on Networking. Attendance will be limited to 50 participants, with priority given to authors of accepted papers, program committee members, and authors of submitted papers. The workshop is open to three forms of submissions: * full papers (up to 15 pages) should exhibit succinctness appropriate to the topics and themes they discuss. * extended abstracts (up to 4 pages), conveying work expected to mature somewhat between submission and presentation at the workshop. * brief abstracts (less than a single page) to be considered for a possible work-in-progress session. Submissions must be in electronic form, as plain text, Postscript, or PDF documents, following the instructions found at: http://www.aciri.org/vern/sigcomm-imeas-2001.submit.html All manuscripts must be in English. The top of the first page of each paper should include the title of the paper, the authors and their affiliations, and the full address for the contact author (e-mail, phone, fax, mailing address). Papers and extended abstracts accepted for presentation at the workshop will be published by ACM in proceedings. Important dates --------------- June 29, 2001: HARD submission deadline August 3, 2001: Notification August 31, 2001: Camera Ready Copy due Steering committee ------------------ Christophe Diot, Sprint ATL (cdiot@sprintlabs.com) Balachander Krishnamurthy, AT&T--Labs Research (bala@research.att.com) Vern Paxson, ACIRI (vern@aciri.org) Jennifer Rexford, AT&T--Labs Research (jrex@research.att.com) Program committee ----------------- Mark Allman (NASA GRC, USA) Martin Arlitt (Hewlett-Packard Labs, USA) Paul Barford (U. of Wisconsin, USA) Anja Feldmann (Univ. Saarbruecken, Germany) Geoff Huston (Telstra, Australia) Jeffrey Mogul (Compaq WRL, USA) Henk Uijterwaal (RIPE NCC, Netherlands) From owner-rtfm@auckland.ac.nz Sun May 6 23:46:49 2001 Received: from mailhost.auckland.ac.nz ([130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18870 for ; Sun, 6 May 2001 23:46:48 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id OAA24133; Mon, 7 May 2001 14:22:51 +1200 (NZST) Received: from rooster.cisco.com ([64.102.19.200]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id OAA24126 for ; Mon, 7 May 2001 14:22:49 +1200 (NZST) Received: from kshah-w2k.cisco.com (kshah-dsl4.cisco.com [10.83.17.29]) by rooster.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA03708; Sun, 6 May 2001 22:22:14 -0400 (EDT) Message-Id: <4.3.2.7.2.20010506221953.01e336f8@rooster.cisco.com> X-Sender: kshah@rooster.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 06 May 2001 22:22:01 -0700 To: "Logg, Connie A." , "'RTFM@AUCKLAND.AC.NZ'" From: Kamlesh Shah Subject: Re: UDP fragment packets In-Reply-To: <76A109862EAED4119176009027EECD1E03D6838D@AGAMEMNON.SLAC.St anford.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Connie, From what I understand, NFC does take this into account since it is able to identify the three packets recevied as part of the same "flow". What aggregation scheme did you use ? Remember, in Cisco's NetFlow implementation, unless you are doing router based aggrgation, version 8, it is the NFC which is doing a lot of processsing and "aggregation" of flows.. At 03:24 PM 5/4/2001 -0700, Logg, Connie A. wrote: >I am wondering if there is any concensus on how UDP fragment packets could be counted for flow purposes. > >I am anaylzing data from Cisco's Netflow feature which is generated by one of our Catalyst 6509s >with a MSFC in it. > >The majority of the UDP data is accounted in records with a source port and destination port of 0. > >In fact, these packets that are counted in these records are fragments of AFS flows, and I think they should be >counted as AFS packets by the Netflow generation code. > >Here is a detailed decode of a series of packets (transferring a 5700 byte datagram) (hope I have the terminology >correct).. I had posed the question to Cisco of how these packets are handled, and the response I first >got back is that "we do not understand why anyone would want to count fragment packets". Such is life. > >I am wondering if you folks have an opinion on how these types of packets should be counted? > >Thanks, COnnie > >Connie Logg - Network Analyst - 650-926-2879 >Stanford Linear Accelerator Center >MS 97; 2575 SandHill Road; Menlo Park CA 94025 >"Happiness is found along the way, not at the end of the road" > >################################## >This example involves the transfer of 5700 bytes of data. Since the mtu is only 1500, this data must be broken up into multiple packets (fragments of the data stream). There are 4 packets in this flow. The first UDP packet contains the port numbers and first part of the data, and the following 3 UDP packets contain the rest of the data. I want to have these counted, because they represent a large portion of the data. The statistics from analyzing the netflow data will be grossly wrong if they are not since we have a lot of large data transfers. The identification field is the key to counting the packets correctly. For the results that I see when I compare a packet capture with the netflow records, it appears that the last 3 packets are not counted. > >The last 3 fragment packets of the file transfer are indeed complete packets. The term "fragment" comes from the >IP spec. That is why I called them fragments. If you look at the packet decodes I sent you will see the "fragment" >bits. I pointed to them. > >Packet 1: has ports in it for level 3 decode >--------- > >----- Level # 1 is ETHERNET Offset: 0 Size: 14 > > Dest Address : Cisco -07-ac-10 00 00 0c 07 ac 10 ...... > Source Address : Sun -9a-d8-b3 08 00 20 9a d8 b3 .. ... > Type : 2048 (DoD IP) 08 00 .. >----- Level # 2 is DoD IP Offset: 14 Size: 20 > > Version : 4 4 . > Header Length : 20 5 . > Type Of Service: 0 00 . > : 000..... Routine > : ...0.... Normal Delay > : ....0... Normal Throughput > : .....0.. Normal Reliability > Total Length : 1500 05 dc .. > Identification : 2736 0a b0 <---critical info > Flags : 3 3 . > : 0.. Reserved > : .1. Don't Fragment > : ..1 More Fragments <--- note more fragments to come > Fragment Offset: 0 60 00 `. > Time To Live : 255 ff . > Protocol : 17 (DODUDP) 11 . > Header Checksum: 44704 ae a0 .. > Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 6d .O.m > Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 79 ...y >----- Level # 3 is DoD UDP Offset: 34 Size: 8 < note has ports in it > > Source Port : 7000 (AFS3-FILESERVER) 1b 58 .X > Dest Port : 7001 (AFS3-CALLBACK) 1b 59 .Y > Length : 5700 16 44 .D > Checksum : 23042 5a 02 Z. >----- Level # 7 is UserData Offset: 42 Size: 1476 > > 00032: a5 f5 c1 83 67 08 ....g. > 00048: 90 3c 00 00 00 07 00 00 00 01 00 00 00 08 01 02 .<.............. >.... > >Packet 2: UDP data packet with NO port info...just data >--------- > >Frame 49 Size 1518 Absolute Time Apr 26 15:41:35.401 ASCII MODE >------------------------------------------------------------------------------- >----- Level # 1 is ETHERNET Offset: 0 Size: 14 > > Dest Address : Cisco -07-ac-10 00 00 0c 07 ac 10 ...... > Source Address : Sun -9a-d8-b3 08 00 20 9a d8 b3 .. ... > Type : 2048 (DoD IP) 08 00 .. >----- Level # 2 is DoD IP Offset: 14 Size: 20 > > Version : 4 4 . > Header Length : 20 5 . > Type Of Service: 0 00 . > : 000..... Routine > : ...0.... Normal Delay > : ....0... Normal Throughput > : .....0.. Normal Reliability > Total Length : 1500 05 dc .. > Identification : 2736 0a b0 <- critical info > Flags : 3 3 . > : 0.. Reserved > : .1. Don't Fragment > : ..1 More Fragments <--more fragments to come > Fragment Offset: 1480 60 b9 `. > Time To Live : 255 ff . > Protocol : 17 (DODUDP) 11 . > Header Checksum: 44519 ad e7 .. > Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 6d .O.m > Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 79 ...y >----- Level # 7 is UserData Offset: 34 Size: 1484 > > 00032: 65 64 75 20 4e 4f 5f 55 4e 49 58 49 44 20 edu NO_UNIXID > > >Packet 3: Another fragment...udp data packet only >--------- > >Frame 50 Size 1518 Absolute Time Apr 26 15:41:35.402 ASCII MODE >------------------------------------------------------------------------------- >----- Level # 1 is ETHERNET Offset: 0 Size: 14 > > Dest Address : Cisco -07-ac-10 00 00 0c 07 ac 10 ...... > Source Address : Sun -9a-d8-b3 08 00 20 9a d8 b3 .. ... > Type : 2048 (DoD IP) 08 00 .. >----- Level # 2 is DoD IP Offset: 14 Size: 20 > > Version : 4 4 . > Header Length : 20 5 . > Type Of Service: 0 00 . > : 000..... Routine > : ...0.... Normal Delay > : ....0... Normal Throughput > : .....0.. Normal Reliability > Total Length : 1500 05 dc .. > Identification : 2736 0a b0 <--critical info > Flags : 3 3 . > : 0.. Reserved > : .1. Don't Fragment > : ..1 More Fragments <--------more fragments to come > Fragment Offset: 2960 61 72 ar > Time To Live : 255 ff . > Protocol : 17 (DODUDP) 11 . > Header Checksum: 44334 ad 2e .. > Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 6d .O.m > Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 79 ...y >----- Level # 7 is UserData Offset: 34 Size: 1484 > > 00032: 73 61 2e 69 6e 66 6e 2e 69 74 20 43 4f 53 sa.infn.it COS > 00048: 54 41 4e 54 49 20 43 6f 73 74 61 6e 74 69 6e 69 TANTI Costantini > > >Packet 4: Last UDP data packet >--------- > >Frame 51 Size 1298 Absolute Time Apr 26 15:41:35.402 ASCII MODE >------------------------------------------------------------------------------- >----- Level # 1 is ETHERNET Offset: 0 Size: 14 > > Dest Address : Cisco -07-ac-10 00 00 0c 07 ac 10 ...... > Source Address : Sun -9a-d8-b3 08 00 20 9a d8 b3 .. ... > Type : 2048 (DoD IP) 08 00 .. >----- Level # 2 is DoD IP Offset: 14 Size: 20 > > Version : 4 4 . > Header Length : 20 5 . > Type Of Service: 0 00 . > > : 000..... Routine > : ...0.... Normal Delay > : ....0... Normal Throughput > : .....0.. Normal Reliability > Total Length : 1280 05 00 .. > Identification : 2736 0a b0 <- critical info > Flags : 2 2 . > : 0.. Reserved > : .1. Don't Fragment > : ..0 Last Fragment < last fragment > Fragment Offset: 344 42 2b B+ > Time To Live : 255 ff . > Protocol : 17 (DODUDP) 11 . > Header Checksum: 52561 cd 51 .Q > Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 6d .O.m > Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 79 ...y >----- Level # 7 is UserData Offset: 34 Size: 1264 > > 00032: 70 69 73 61 2e 69 6e 66 6e 2e 69 74 20 42 pisa.infn.it B > >##################################### > > >Connie Logg - Network Analyst - 650-926-2879 >Stanford Linear Accelerator Center >MS 97; 2575 SandHill Road; Menlo Park CA 94025 >"Happiness is found along the way, not at the end of the road" ((((((((((((()))))))))))) Kamlesh Shah CCIE # 2803 Technical Marketing Engineer - MPLS, ISBU From owner-rtfm@auckland.ac.nz Mon May 7 20:04:08 2001 Received: from mailhost.auckland.ac.nz ([130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24862 for ; Mon, 7 May 2001 20:04:06 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id JAA02524; Tue, 8 May 2001 09:45:51 +1200 (NZST) Received: from smtp.SLAC.Stanford.EDU (SMTP.SLAC.Stanford.EDU [134.79.18.80]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id JAA02342 for ; Tue, 8 May 2001 09:45:09 +1200 (NZST) Received: from CONVERSION-DAEMON by smtp.slac.stanford.edu (PMDF V5.2-33 #37476) id <0GCZ00801J2SA4@smtp.slac.stanford.edu> for RTFM@AUCKLAND.AC.NZ; Mon, 7 May 2001 14:44:53 -0700 (PDT) Received: from smtpserv1.SLAC.Stanford.EDU (SMTPSERV1.SLAC.Stanford.EDU [134.79.18.81]) by smtp.slac.stanford.edu (PMDF V5.2-33 #37476) with ESMTP id <0GCZ0054IJ2RDS@smtp.slac.stanford.edu>; Mon, 07 May 2001 14:44:52 -0700 (PDT) Received: from agamemnon.slac.stanford.edu ([134.79.18.86]) by smtpserv1.slac.stanford.edu (PMDF V5.2-33 #37476) with ESMTP id <0GCZ00FFLJ2RVP@smtpserv1.slac.stanford.edu>; Mon, 07 May 2001 14:44:51 -0700 (PDT) Received: by AGAMEMNON.SLAC.Stanford.EDU with Internet Mail Service (5.5.2653.19) id ; Mon, 07 May 2001 14:44:48 -0700 Content-return: allowed Date: Mon, 07 May 2001 14:44:47 -0700 From: "Logg, Connie A." Subject: RE: UDP fragment packets To: "'Kamlesh Shah'" Cc: "'RTFM@AUCKLAND.AC.NZ'" Message-id: <76A109862EAED4119176009027EECD1E03D68392@AGAMEMNON.SLAC.Stanford.EDU> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7BIT I am using the CALLREC aggregation scheme. One day I spent a day capturing packets (spanning to a switch probe) and correlating the traffic to a particular server (it was its port that was spanned) to the netflow records that were cut for the traffic. There were a series of 7 AFS transfers between two nodes. There were 3 udp fragment packets for each transfer, and the netflow record showed 20 for port 0(one was taken in by the MSFC). There were 6 for the AFS first packets (one was taken in by the msfc). This took all day (actually a day and a half) to find a consistent transfer that I could study. Thus came my conclusion that the fragments were counted as port 0. I replicated this several times that day. Now unless netflow looks at the "Identification" field, it (I think) will have no way to know that the 4 packets are actually part of the same flow. I have been hoping that someone knowledgable would look at the code in the switch which collects the stats, and generates the flow records. It sounds like I may be wrong on my concept of the NFC (there is no thorough detailed documentation that I have been able to find). I did not think (still do not) that it really does much work except to aggregate the netflow records into files which represent the aggregation scheme desired. Thus I am using the aggregation scheme CALLREC to give me all the records that are cut into one file (per 10 minutes). I then process these records into my own "schemes" by examining the protocol field and source and destination port fields. Thus, when I separate the data in this way, I get a lot of UDP port0 traffic, most of which is to/from our AFS servers. Of course, I could create filters and my own aggregation schemes with the NFC (and I tried), but I ran into problems that TAC could not solve, so I decided to do it myself. That way I know precisely what heuristics I am applying when deciding how to classify a flow record. I appreciate any info that you can provide me on understanding this. Thanks, Connie Connie Logg - Network Analyst - 650-926-2879 Stanford Linear Accelerator Center MS 97; 2575 SandHill Road; Menlo Park CA 94025 "Happiness is found along the way, not at the end of the road" -----Original Message----- From: Kamlesh Shah [mailto:kshah@cisco.com] Sent: Sunday, May 06, 2001 10:22 PM To: Logg, Connie A.; 'RTFM@AUCKLAND.AC.NZ' Subject: Re: UDP fragment packets Connie, From what I understand, NFC does take this into account since it is able to identify the three packets recevied as part of the same "flow". What aggregation scheme did you use ? Remember, in Cisco's NetFlow implementation, unless you are doing router based aggrgation, version 8, it is the NFC which is doing a lot of processsing and "aggregation" of flows.. At 03:24 PM 5/4/2001 -0700, Logg, Connie A. wrote: >I am wondering if there is any concensus on how UDP fragment packets could be counted for flow purposes. > >I am anaylzing data from Cisco's Netflow feature which is generated by one of our Catalyst 6509s >with a MSFC in it. > >The majority of the UDP data is accounted in records with a source port and destination port of 0. > >In fact, these packets that are counted in these records are fragments of AFS flows, and I think they should be >counted as AFS packets by the Netflow generation code. > >Here is a detailed decode of a series of packets (transferring a 5700 byte datagram) (hope I have the terminology >correct).. I had posed the question to Cisco of how these packets are handled, and the response I first >got back is that "we do not understand why anyone would want to count fragment packets". Such is life. > >I am wondering if you folks have an opinion on how these types of packets should be counted? > >Thanks, COnnie > >Connie Logg - Network Analyst - 650-926-2879 >Stanford Linear Accelerator Center >MS 97; 2575 SandHill Road; Menlo Park CA 94025 >"Happiness is found along the way, not at the end of the road" > >################################## >This example involves the transfer of 5700 bytes of data. Since the mtu is only 1500, this data must be broken up into multiple packets (fragments of the data stream). There are 4 packets in this flow. The first UDP packet contains the port numbers and first part of the data, and the following 3 UDP packets contain the rest of the data. I want to have these counted, because they represent a large portion of the data. The statistics from analyzing the netflow data will be grossly wrong if they are not since we have a lot of large data transfers. The identification field is the key to counting the packets correctly. For the results that I see when I compare a packet capture with the netflow records, it appears that the last 3 packets are not counted. > >The last 3 fragment packets of the file transfer are indeed complete packets. The term "fragment" comes from the >IP spec. That is why I called them fragments. If you look at the packet decodes I sent you will see the "fragment" >bits. I pointed to them. > >Packet 1: has ports in it for level 3 decode >--------- > >----- Level # 1 is ETHERNET Offset: 0 Size: 14 > > Dest Address : Cisco -07-ac-10 00 00 0c 07 ac 10 ...... > Source Address : Sun -9a-d8-b3 08 00 20 9a d8 b3 .. ... > Type : 2048 (DoD IP) 08 00 .. >----- Level # 2 is DoD IP Offset: 14 Size: 20 > > Version : 4 4 . > Header Length : 20 5 . > Type Of Service: 0 00 . > : 000..... Routine > : ...0.... Normal Delay > : ....0... Normal Throughput > : .....0.. Normal Reliability > Total Length : 1500 05 dc .. > Identification : 2736 0a b0 <---critical info > Flags : 3 3 . > : 0.. Reserved > : .1. Don't Fragment > : ..1 More Fragments <--- note more fragments to come > Fragment Offset: 0 60 00 `. > Time To Live : 255 ff . > Protocol : 17 (DODUDP) 11 . > Header Checksum: 44704 ae a0 .. > Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 6d .O.m > Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 79 ...y >----- Level # 3 is DoD UDP Offset: 34 Size: 8 < note has ports in it > > Source Port : 7000 (AFS3-FILESERVER) 1b 58 .X > Dest Port : 7001 (AFS3-CALLBACK) 1b 59 .Y > Length : 5700 16 44 .D > Checksum : 23042 5a 02 Z. >----- Level # 7 is UserData Offset: 42 Size: 1476 > > 00032: a5 f5 c1 83 67 08 ....g. > 00048: 90 3c 00 00 00 07 00 00 00 01 00 00 00 08 01 02 .<.............. >.... > >Packet 2: UDP data packet with NO port info...just data >--------- > >Frame 49 Size 1518 Absolute Time Apr 26 15:41:35.401 ASCII MODE >------------------------------------------------------------------------------- >----- Level # 1 is ETHERNET Offset: 0 Size: 14 > > Dest Address : Cisco -07-ac-10 00 00 0c 07 ac 10 ...... > Source Address : Sun -9a-d8-b3 08 00 20 9a d8 b3 .. ... > Type : 2048 (DoD IP) 08 00 .. >----- Level # 2 is DoD IP Offset: 14 Size: 20 > > Version : 4 4 . > Header Length : 20 5 . > Type Of Service: 0 00 . > : 000..... Routine > : ...0.... Normal Delay > : ....0... Normal Throughput > : .....0.. Normal Reliability > Total Length : 1500 05 dc .. > Identification : 2736 0a b0 <- critical info > Flags : 3 3 . > : 0.. Reserved > : .1. Don't Fragment > : ..1 More Fragments <--more fragments to come > Fragment Offset: 1480 60 b9 `. > Time To Live : 255 ff . > Protocol : 17 (DODUDP) 11 . > Header Checksum: 44519 ad e7 .. > Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 6d .O.m > Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 79 ...y >----- Level # 7 is UserData Offset: 34 Size: 1484 > > 00032: 65 64 75 20 4e 4f 5f 55 4e 49 58 49 44 20 edu NO_UNIXID > > >Packet 3: Another fragment...udp data packet only >--------- > >Frame 50 Size 1518 Absolute Time Apr 26 15:41:35.402 ASCII MODE >------------------------------------------------------------------------------- >----- Level # 1 is ETHERNET Offset: 0 Size: 14 > > Dest Address : Cisco -07-ac-10 00 00 0c 07 ac 10 ...... > Source Address : Sun -9a-d8-b3 08 00 20 9a d8 b3 .. ... > Type : 2048 (DoD IP) 08 00 .. >----- Level # 2 is DoD IP Offset: 14 Size: 20 > > Version : 4 4 . > Header Length : 20 5 . > Type Of Service: 0 00 . > : 000..... Routine > : ...0.... Normal Delay > : ....0... Normal Throughput > : .....0.. Normal Reliability > Total Length : 1500 05 dc .. > Identification : 2736 0a b0 <--critical info > Flags : 3 3 . > : 0.. Reserved > : .1. Don't Fragment > : ..1 More Fragments <--------more fragments to come > Fragment Offset: 2960 61 72 ar > Time To Live : 255 ff . > Protocol : 17 (DODUDP) 11 . > Header Checksum: 44334 ad 2e .. > Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 6d .O.m > Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 79 ...y >----- Level # 7 is UserData Offset: 34 Size: 1484 > > 00032: 73 61 2e 69 6e 66 6e 2e 69 74 20 43 4f 53 sa.infn.it COS > 00048: 54 41 4e 54 49 20 43 6f 73 74 61 6e 74 69 6e 69 TANTI Costantini > > >Packet 4: Last UDP data packet >--------- > >Frame 51 Size 1298 Absolute Time Apr 26 15:41:35.402 ASCII MODE >------------------------------------------------------------------------------- >----- Level # 1 is ETHERNET Offset: 0 Size: 14 > > Dest Address : Cisco -07-ac-10 00 00 0c 07 ac 10 ...... > Source Address : Sun -9a-d8-b3 08 00 20 9a d8 b3 .. ... > Type : 2048 (DoD IP) 08 00 .. >----- Level # 2 is DoD IP Offset: 14 Size: 20 > > Version : 4 4 . > Header Length : 20 5 . > Type Of Service: 0 00 . > > : 000..... Routine > : ...0.... Normal Delay > : ....0... Normal Throughput > : .....0.. Normal Reliability > Total Length : 1280 05 00 .. > Identification : 2736 0a b0 <- critical info > Flags : 2 2 . > : 0.. Reserved > : .1. Don't Fragment > : ..0 Last Fragment < last fragment > Fragment Offset: 344 42 2b B+ > Time To Live : 255 ff . > Protocol : 17 (DODUDP) 11 . > Header Checksum: 52561 cd 51 .Q > Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 6d .O.m > Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 79 ...y >----- Level # 7 is UserData Offset: 34 Size: 1264 > > 00032: 70 69 73 61 2e 69 6e 66 6e 2e 69 74 20 42 pisa.infn.it B > >##################################### > > >Connie Logg - Network Analyst - 650-926-2879 >Stanford Linear Accelerator Center >MS 97; 2575 SandHill Road; Menlo Park CA 94025 >"Happiness is found along the way, not at the end of the road" ((((((((((((()))))))))))) Kamlesh Shah CCIE # 2803 Technical Marketing Engineer - MPLS, ISBU From owner-rtfm@auckland.ac.nz Tue May 8 00:05:09 2001 Received: from mailhost.auckland.ac.nz ([130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00157 for ; Tue, 8 May 2001 00:05:08 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id NAA29214; Tue, 8 May 2001 13:57:46 +1200 (NZST) Received: from rooster.cisco.com (rooster.cisco.com [64.102.19.200]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id NAA29150 for ; Tue, 8 May 2001 13:57:29 +1200 (NZST) Received: from kshah-w2k.cisco.com (kshah-dsl4.cisco.com [10.83.17.29]) by rooster.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA25973; Mon, 7 May 2001 21:27:24 -0400 (EDT) Message-Id: <4.3.2.7.2.20010507212613.01d250c0@rooster.cisco.com> X-Sender: kshah@rooster.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 May 2001 21:27:12 -0700 To: "Logg, Connie A." From: Kamlesh Shah Subject: RE: UDP fragment packets Cc: "'RTFM@AUCKLAND.AC.NZ'" In-Reply-To: <76A109862EAED4119176009027EECD1E03D68392@AGAMEMNON.SLAC.St anford.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Connie, I am teaching a class tomorrow and wednesday..I will certainly look into the details of this, including code if needed soon after that. Please standby for more.. Regards. At 02:44 PM 5/7/2001 -0700, Logg, Connie A. wrote: >I am using the CALLREC aggregation scheme. > >One day I spent a day capturing packets (spanning to a switch probe) and correlating the traffic to a particular server (it was its port that was spanned) to >the netflow records that were cut for the traffic. There were a series of 7 AFS transfers between two nodes. >There were 3 udp fragment packets for each transfer, and the netflow record showed 20 for port 0(one was taken in by the MSFC). >There were 6 for the AFS first packets (one was taken in by the msfc). This took all day (actually a day and a half) >to find a consistent transfer that I could study. > >Thus came my conclusion that the fragments were counted as port 0. I replicated this several times that day. > >Now unless netflow looks at the "Identification" field, it (I think) will have no way to know that the 4 packets are actually part of the >same flow. > >I have been hoping that someone knowledgable would look at the code in the switch which collects the stats, and >generates the flow records. > >It sounds like I may be wrong on my concept of the NFC (there is no thorough detailed documentation that I have been able to find). I did not think (still do not) that it really does much work >except to aggregate the netflow records into files which represent the aggregation scheme desired. Thus I am >using the aggregation scheme CALLREC to give me all the records that are cut into one file (per 10 minutes). > >I then process these records into my own "schemes" by examining the protocol field and source and destination >port fields. Thus, when I separate the data in this way, I get a lot of UDP port0 traffic, most of which is to/from >our AFS servers. Of course, I could create filters and my own aggregation schemes with the NFC (and I tried), but I >ran into problems that TAC could not solve, so I decided to do it myself. That way I know precisely what heuristics >I am applying when deciding how to classify a flow record. > >I appreciate any info that you can provide me on understanding this. > >Thanks, > >Connie >Connie Logg - Network Analyst - 650-926-2879 >Stanford Linear Accelerator Center >MS 97; 2575 SandHill Road; Menlo Park CA 94025 >"Happiness is found along the way, not at the end of the road" > > >-----Original Message----- >From: Kamlesh Shah [mailto:kshah@cisco.com] >Sent: Sunday, May 06, 2001 10:22 PM >To: Logg, Connie A.; 'RTFM@AUCKLAND.AC.NZ' >Subject: Re: UDP fragment packets > > >Connie, > > From what I understand, NFC does take this into account since it is able to identify the three packets recevied as part of the same "flow". > >What aggregation scheme did you use ? > >Remember, in Cisco's NetFlow implementation, unless you are doing router based aggrgation, version 8, it is the NFC which is doing a lot of processsing and "aggregation" of flows.. > > >At 03:24 PM 5/4/2001 -0700, Logg, Connie A. wrote: >>I am wondering if there is any concensus on how UDP fragment packets could be counted for flow purposes. >> >>I am anaylzing data from Cisco's Netflow feature which is generated by one of our Catalyst 6509s >>with a MSFC in it. >> >>The majority of the UDP data is accounted in records with a source port and destination port of 0. >> >>In fact, these packets that are counted in these records are fragments of AFS flows, and I think they should be >>counted as AFS packets by the Netflow generation code. >> >>Here is a detailed decode of a series of packets (transferring a 5700 byte datagram) (hope I have the terminology >>correct).. I had posed the question to Cisco of how these packets are handled, and the response I first >>got back is that "we do not understand why anyone would want to count fragment packets". Such is life. >> >>I am wondering if you folks have an opinion on how these types of packets should be counted? >> >>Thanks, COnnie >> >>Connie Logg - Network Analyst - 650-926-2879 >>Stanford Linear Accelerator Center >>MS 97; 2575 SandHill Road; Menlo Park CA 94025 >>"Happiness is found along the way, not at the end of the road" >> >>################################## >>This example involves the transfer of 5700 bytes of data. Since the mtu is only 1500, this data must be broken up into multiple packets (fragments of the data stream). There are 4 packets in this flow. The first UDP packet contains the port numbers and first part of the data, and the following 3 UDP packets contain the rest of the data. I want to have these counted, because they represent a large portion of the data. The statistics from analyzing the netflow data will be grossly wrong if they are not since we have a lot of large data transfers. The identification field is the key to counting the packets correctly. For the results that I see when I compare a packet capture with the netflow records, it appears that the last 3 packets are not counted. >> >>The last 3 fragment packets of the file transfer are indeed complete packets. The term "fragment" comes from the >>IP spec. That is why I called them fragments. If you look at the packet decodes I sent you will see the "fragment" >>bits. I pointed to them. >> >>Packet 1: has ports in it for level 3 decode >>--------- >> >>----- Level # 1 is ETHERNET Offset: 0 Size: 14 >> >> Dest Address : Cisco -07-ac-10 00 00 0c 07 ac 10 ...... >> Source Address : Sun -9a-d8-b3 08 00 20 9a d8 b3 .. ... >> Type : 2048 (DoD IP) 08 00 .. >>----- Level # 2 is DoD IP Offset: 14 Size: 20 >> >> Version : 4 4 . >> Header Length : 20 5 . >> Type Of Service: 0 00 . >> : 000..... Routine >> : ...0.... Normal Delay >> : ....0... Normal Throughput >> : .....0.. Normal Reliability >> Total Length : 1500 05 dc .. >> Identification : 2736 0a b0 <---critical info >> Flags : 3 3 . >> : 0.. Reserved >> : .1. Don't Fragment >> : ..1 More Fragments <--- note more fragments to come >> Fragment Offset: 0 60 00 `. >> Time To Live : 255 ff . >> Protocol : 17 (DODUDP) 11 . >> Header Checksum: 44704 ae a0 .. >> Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 6d .O.m >> Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 79 ...y >>----- Level # 3 is DoD UDP Offset: 34 Size: 8 < note has ports in it >> >> Source Port : 7000 (AFS3-FILESERVER) 1b 58 .X >> Dest Port : 7001 (AFS3-CALLBACK) 1b 59 .Y >> Length : 5700 16 44 .D >> Checksum : 23042 5a 02 Z. >>----- Level # 7 is UserData Offset: 42 Size: 1476 >> >> 00032: a5 f5 c1 83 67 08 ....g. >> 00048: 90 3c 00 00 00 07 00 00 00 01 00 00 00 08 01 02 .<.............. >>.... >> >>Packet 2: UDP data packet with NO port info...just data >>--------- >> >>Frame 49 Size 1518 Absolute Time Apr 26 15:41:35.401 ASCII MODE >>------------------------------------------------------------------------------- >>----- Level # 1 is ETHERNET Offset: 0 Size: 14 >> >> Dest Address : Cisco -07-ac-10 00 00 0c 07 ac 10 ...... >> Source Address : Sun -9a-d8-b3 08 00 20 9a d8 b3 .. ... >> Type : 2048 (DoD IP) 08 00 .. >>----- Level # 2 is DoD IP Offset: 14 Size: 20 >> >> Version : 4 4 . >> Header Length : 20 5 . >> Type Of Service: 0 00 . >> : 000..... Routine >> : ...0.... Normal Delay >> : ....0... Normal Throughput >> : .....0.. Normal Reliability >> Total Length : 1500 05 dc .. >> Identification : 2736 0a b0 <- critical info >> Flags : 3 3 . >> : 0.. Reserved >> : .1. Don't Fragment >> : ..1 More Fragments <--more fragments to come >> Fragment Offset: 1480 60 b9 `. >> Time To Live : 255 ff . >> Protocol : 17 (DODUDP) 11 . >> Header Checksum: 44519 ad e7 .. >> Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 6d .O.m >> Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 79 ...y >>----- Level # 7 is UserData Offset: 34 Size: 1484 >> >> 00032: 65 64 75 20 4e 4f 5f 55 4e 49 58 49 44 20 edu NO_UNIXID >> >> >>Packet 3: Another fragment...udp data packet only >>--------- >> >>Frame 50 Size 1518 Absolute Time Apr 26 15:41:35.402 ASCII MODE >>------------------------------------------------------------------------------- >>----- Level # 1 is ETHERNET Offset: 0 Size: 14 >> >> Dest Address : Cisco -07-ac-10 00 00 0c 07 ac 10 ...... >> Source Address : Sun -9a-d8-b3 08 00 20 9a d8 b3 .. ... >> Type : 2048 (DoD IP) 08 00 .. >>----- Level # 2 is DoD IP Offset: 14 Size: 20 >> >> Version : 4 4 . >> Header Length : 20 5 . >> Type Of Service: 0 00 . >> : 000..... Routine >> : ...0.... Normal Delay >> : ....0... Normal Throughput >> : .....0.. Normal Reliability >> Total Length : 1500 05 dc .. >> Identification : 2736 0a b0 <--critical info >> Flags : 3 3 . >> : 0.. Reserved >> : .1. Don't Fragment >> : ..1 More Fragments <--------more fragments to come >> Fragment Offset: 2960 61 72 ar >> Time To Live : 255 ff . >> Protocol : 17 (DODUDP) 11 . >> Header Checksum: 44334 ad 2e .. >> Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 6d .O.m >> Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 79 ...y >>----- Level # 7 is UserData Offset: 34 Size: 1484 >> >> 00032: 73 61 2e 69 6e 66 6e 2e 69 74 20 43 4f 53 sa.infn.it COS >> 00048: 54 41 4e 54 49 20 43 6f 73 74 61 6e 74 69 6e 69 TANTI Costantini >> >> >>Packet 4: Last UDP data packet >>--------- >> >>Frame 51 Size 1298 Absolute Time Apr 26 15:41:35.402 ASCII MODE >>------------------------------------------------------------------------------- >>----- Level # 1 is ETHERNET Offset: 0 Size: 14 >> >> Dest Address : Cisco -07-ac-10 00 00 0c 07 ac 10 ...... >> Source Address : Sun -9a-d8-b3 08 00 20 9a d8 b3 .. ... >> Type : 2048 (DoD IP) 08 00 .. >>----- Level # 2 is DoD IP Offset: 14 Size: 20 >> >> Version : 4 4 . >> Header Length : 20 5 . >> Type Of Service: 0 00 . >> >> : 000..... Routine >> : ...0.... Normal Delay >> : ....0... Normal Throughput >> : .....0.. Normal Reliability >> Total Length : 1280 05 00 .. >> Identification : 2736 0a b0 <- critical info >> Flags : 2 2 . >> : 0.. Reserved >> : .1. Don't Fragment >> : ..0 Last Fragment < last fragment >> Fragment Offset: 344 42 2b B+ >> Time To Live : 255 ff . >> Protocol : 17 (DODUDP) 11 . >> Header Checksum: 52561 cd 51 .Q >> Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 6d .O.m >> Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 79 ...y >>----- Level # 7 is UserData Offset: 34 Size: 1264 >> >> 00032: 70 69 73 61 2e 69 6e 66 6e 2e 69 74 20 42 pisa.infn.it B >> >>##################################### >> >> >>Connie Logg - Network Analyst - 650-926-2879 >>Stanford Linear Accelerator Center >>MS 97; 2575 SandHill Road; Menlo Park CA 94025 >>"Happiness is found along the way, not at the end of the road" > >((((((((((((()))))))))))) >Kamlesh Shah CCIE # 2803 >Technical Marketing Engineer - MPLS, ISBU ((((((((((((()))))))))))) Kamlesh Shah CCIE # 2803 Technical Marketing Engineer - MPLS, ISBU From owner-rtfm@auckland.ac.nz Sat May 12 14:23:55 2001 Received: from mailhost.auckland.ac.nz ([130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18935 for ; Sat, 12 May 2001 14:23:54 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id EAA13298; Sun, 13 May 2001 04:26:58 +1200 (NZST) Received: from nis-master.office-mail.co.uk (nis-master.office-mail.co.uk [217.15.160.51]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id EAA12981; Sun, 13 May 2001 04:18:24 +1200 (NZST) From: sean.kelly@the-web-works.co.uk Received: from localhost (localhost [127.0.0.1]) by nis-master.office-mail.co.uk (Postfix) with SMTP id A6CE51D632; Sat, 12 May 2001 17:12:48 +0100 (BST) To: netramet@auckland.ac.nz Cc: rtfm@auckland.ac.nz subject: Monitoring and reporting network usage Message-Id: <20010512161248.A6CE51D632@nis-master.office-mail.co.uk> Date: Sat, 12 May 2001 17:12:48 +0100 (BST) Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hi there, Apologies in advance if the cross-posting is not appropriate. I am looking for some advice on monitoring and reporting network usage. I am currently running a FreeBSD box with an application called 'Snuffle' to produce reports as to how much traffic is going to each of the hosts on my network. Recently we have spotted that not all the traffic is getting logged (with the biggest example being that we seemed to miss every packet of a 1.5Gb upload last week) and so I have now decided to look elsewhere for this kind of application. Will NeTraMet be able to log the network usage for each of the IPs on my network? If this is not be best choice in application, has anyone got any other suggestions? I mentioned that I am using FreeBSD. The reason for this is that I was once told the *BSD operating systems have a better packet capturing library. When I ported the snuffle code to Linux it seemed to miss a lot of the traffic. Does anyone have any advice as to an appropriate operating system for packet capture? Thanks in advance, -- Sean Kelly From owner-rtfm@auckland.ac.nz Tue May 15 01:58:10 2001 Received: from mailhost.auckland.ac.nz ([130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09923 for ; Tue, 15 May 2001 01:58:06 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id OAA11329; Tue, 15 May 2001 14:03:16 +1200 (NZST) Received: from rooster.cisco.com ([64.102.19.200]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id OAA11310 for ; Tue, 15 May 2001 14:03:13 +1200 (NZST) Received: from kshah-w2k.cisco.com (kshah-dsl4.cisco.com [10.83.17.29]) by rooster.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA08628; Mon, 14 May 2001 22:02:25 -0400 (EDT) Message-Id: <4.3.2.7.2.20010514215402.01d9cd70@rooster.cisco.com> X-Sender: kshah@rooster.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 May 2001 22:02:06 -0400 To: "Logg, Connie A." From: Kamlesh Shah Subject: RE: UDP fragment packets Cc: "'RTFM@AUCKLAND.AC.NZ'" In-Reply-To: <76A109862EAED4119176009027EECD1E03D68392@AGAMEMNON.SLAC.St anford.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Connie, I did some more digging into this issue. Sorry for taking long to get back to you, I am preparing for a trip right after teaching a class..but that's a different story :-) What I found is that your observations about NFC NOT being able to do flow co-relation is correct in that it does not know if the next 3 packets received are part of the same flow or not, since it is doing its work purely on the aggregation scheme fields, keys. I also found that this is the case since call record aggregation scheme is simply counting {SA, SP, DA, DP} for address and port combination, it does not know when the port changes to zero in the export packet. This is really an issue with how IP fragmentation works, since as I realized after looking around that IP fragments do not carry the application level port information, and hence port 0, which NFC treats as a new flow and shows up else where in the NFC collected files. Hope this helps, essentially your filtering idea would possibly help here. Let me know if you run into any other issues here. Regards. At 05:44 PM 5/7/2001 -0700, Logg, Connie A. wrote: >I am using the CALLREC aggregation scheme. > >One day I spent a day capturing packets (spanning to a switch probe) and correlating the traffic to a particular server (it was its port that was spanned) to >the netflow records that were cut for the traffic. There were a series of 7 AFS transfers between two nodes. >There were 3 udp fragment packets for each transfer, and the netflow record showed 20 for port 0(one was taken in by the MSFC). >There were 6 for the AFS first packets (one was taken in by the msfc). This took all day (actually a day and a half) >to find a consistent transfer that I could study. > >Thus came my conclusion that the fragments were counted as port 0. I replicated this several times that day. > >Now unless netflow looks at the "Identification" field, it (I think) will have no way to know that the 4 packets are actually part of the >same flow. > >I have been hoping that someone knowledgable would look at the code in the switch which collects the stats, and >generates the flow records. > >It sounds like I may be wrong on my concept of the NFC (there is no thorough detailed documentation that I have been able to find). I did not think (still do not) that it really does much work >except to aggregate the netflow records into files which represent the aggregation scheme desired. Thus I am >using the aggregation scheme CALLREC to give me all the records that are cut into one file (per 10 minutes). > >I then process these records into my own "schemes" by examining the protocol field and source and destination >port fields. Thus, when I separate the data in this way, I get a lot of UDP port0 traffic, most of which is to/from >our AFS servers. Of course, I could create filters and my own aggregation schemes with the NFC (and I tried), but I >ran into problems that TAC could not solve, so I decided to do it myself. That way I know precisely what heuristics >I am applying when deciding how to classify a flow record. > >I appreciate any info that you can provide me on understanding this. > >Thanks, > >Connie >Connie Logg - Network Analyst - 650-926-2879 >Stanford Linear Accelerator Center >MS 97; 2575 SandHill Road; Menlo Park CA 94025 >"Happiness is found along the way, not at the end of the road" > > >-----Original Message----- >From: Kamlesh Shah [mailto:kshah@cisco.com] >Sent: Sunday, May 06, 2001 10:22 PM >To: Logg, Connie A.; 'RTFM@AUCKLAND.AC.NZ' >Subject: Re: UDP fragment packets > > >Connie, > > From what I understand, NFC does take this into account since it is able to identify the three packets recevied as part of the same "flow". > >What aggregation scheme did you use ? > >Remember, in Cisco's NetFlow implementation, unless you are doing router based aggrgation, version 8, it is the NFC which is doing a lot of processsing and "aggregation" of flows.. > > >At 03:24 PM 5/4/2001 -0700, Logg, Connie A. wrote: >>I am wondering if there is any concensus on how UDP fragment packets could be counted for flow purposes. >> >>I am anaylzing data from Cisco's Netflow feature which is generated by one of our Catalyst 6509s >>with a MSFC in it. >> >>The majority of the UDP data is accounted in records with a source port and destination port of 0. >> >>In fact, these packets that are counted in these records are fragments of AFS flows, and I think they should be >>counted as AFS packets by the Netflow generation code. >> >>Here is a detailed decode of a series of packets (transferring a 5700 byte datagram) (hope I have the terminology >>correct).. I had posed the question to Cisco of how these packets are handled, and the response I first >>got back is that "we do not understand why anyone would want to count fragment packets". Such is life. >> >>I am wondering if you folks have an opinion on how these types of packets should be counted? >> >>Thanks, COnnie >> >>Connie Logg - Network Analyst - 650-926-2879 >>Stanford Linear Accelerator Center >>MS 97; 2575 SandHill Road; Menlo Park CA 94025 >>"Happiness is found along the way, not at the end of the road" >> >>################################## >>This example involves the transfer of 5700 bytes of data. Since the mtu is only 1500, this data must be broken up into multiple packets (fragments of the data stream). There are 4 packets in this flow. The first UDP packet contains the port numbers and first part of the data, and the following 3 UDP packets contain the rest of the data. I want to have these counted, because they represent a large portion of the data. The statistics from analyzing the netflow data will be grossly wrong if they are not since we have a lot of large data transfers. The identification field is the key to counting the packets correctly. For the results that I see when I compare a packet capture with the netflow records, it appears that the last 3 packets are not counted. >> >>The last 3 fragment packets of the file transfer are indeed complete packets. The term "fragment" comes from the >>IP spec. That is why I called them fragments. If you look at the packet decodes I sent you will see the "fragment" >>bits. I pointed to them. >> >>Packet 1: has ports in it for level 3 decode >>--------- >> >>----- Level # 1 is ETHERNET Offset: 0 Size: 14 >> >> Dest Address : Cisco -07-ac-10 00 00 0c 07 ac 10 ...... >> Source Address : Sun -9a-d8-b3 08 00 20 9a d8 b3 .. ... >> Type : 2048 (DoD IP) 08 00 .. >>----- Level # 2 is DoD IP Offset: 14 Size: 20 >> >> Version : 4 4 . >> Header Length : 20 5 . >> Type Of Service: 0 00 . >> : 000..... Routine >> : ...0.... Normal Delay >> : ....0... Normal Throughput >> : .....0.. Normal Reliability >> Total Length : 1500 05 dc .. >> Identification : 2736 0a b0 <---critical info >> Flags : 3 3 . >> : 0.. Reserved >> : .1. Don't Fragment >> : ..1 More Fragments <--- note more fragments to come >> Fragment Offset: 0 60 00 `. >> Time To Live : 255 ff . >> Protocol : 17 (DODUDP) 11 . >> Header Checksum: 44704 ae a0 .. >> Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 6d .O.m >> Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 79 ...y >>----- Level # 3 is DoD UDP Offset: 34 Size: 8 < note has ports in it >> >> Source Port : 7000 (AFS3-FILESERVER) 1b 58 .X >> Dest Port : 7001 (AFS3-CALLBACK) 1b 59 .Y >> Length : 5700 16 44 .D >> Checksum : 23042 5a 02 Z. >>----- Level # 7 is UserData Offset: 42 Size: 1476 >> >> 00032: a5 f5 c1 83 67 08 ....g. >> 00048: 90 3c 00 00 00 07 00 00 00 01 00 00 00 08 01 02 .<.............. >>.... >> >>Packet 2: UDP data packet with NO port info...just data >>--------- >> >>Frame 49 Size 1518 Absolute Time Apr 26 15:41:35.401 ASCII MODE >>------------------------------------------------------------------------------- >>----- Level # 1 is ETHERNET Offset: 0 Size: 14 >> >> Dest Address : Cisco -07-ac-10 00 00 0c 07 ac 10 ...... >> Source Address : Sun -9a-d8-b3 08 00 20 9a d8 b3 .. ... >> Type : 2048 (DoD IP) 08 00 .. >>----- Level # 2 is DoD IP Offset: 14 Size: 20 >> >> Version : 4 4 . >> Header Length : 20 5 . >> Type Of Service: 0 00 . >> : 000..... Routine >> : ...0.... Normal Delay >> : ....0... Normal Throughput >> : .....0.. Normal Reliability >> Total Length : 1500 05 dc .. >> Identification : 2736 0a b0 <- critical info >> Flags : 3 3 . >> : 0.. Reserved >> : .1. Don't Fragment >> : ..1 More Fragments <--more fragments to come >> Fragment Offset: 1480 60 b9 `. >> Time To Live : 255 ff . >> Protocol : 17 (DODUDP) 11 . >> Header Checksum: 44519 ad e7 .. >> Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 6d .O.m >> Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 79 ...y >>----- Level # 7 is UserData Offset: 34 Size: 1484 >> >> 00032: 65 64 75 20 4e 4f 5f 55 4e 49 58 49 44 20 edu NO_UNIXID >> >> >>Packet 3: Another fragment...udp data packet only >>--------- >> >>Frame 50 Size 1518 Absolute Time Apr 26 15:41:35.402 ASCII MODE >>------------------------------------------------------------------------------- >>----- Level # 1 is ETHERNET Offset: 0 Size: 14 >> >> Dest Address : Cisco -07-ac-10 00 00 0c 07 ac 10 ...... >> Source Address : Sun -9a-d8-b3 08 00 20 9a d8 b3 .. ... >> Type : 2048 (DoD IP) 08 00 .. >>----- Level # 2 is DoD IP Offset: 14 Size: 20 >> >> Version : 4 4 . >> Header Length : 20 5 . >> Type Of Service: 0 00 . >> : 000..... Routine >> : ...0.... Normal Delay >> : ....0... Normal Throughput >> : .....0.. Normal Reliability >> Total Length : 1500 05 dc .. >> Identification : 2736 0a b0 <--critical info >> Flags : 3 3 . >> : 0.. Reserved >> : .1. Don't Fragment >> : ..1 More Fragments <--------more fragments to come >> Fragment Offset: 2960 61 72 ar >> Time To Live : 255 ff . >> Protocol : 17 (DODUDP) 11 . >> Header Checksum: 44334 ad 2e .. >> Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 6d .O.m >> Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 79 ...y >>----- Level # 7 is UserData Offset: 34 Size: 1484 >> >> 00032: 73 61 2e 69 6e 66 6e 2e 69 74 20 43 4f 53 sa.infn.it COS >> 00048: 54 41 4e 54 49 20 43 6f 73 74 61 6e 74 69 6e 69 TANTI Costantini >> >> >>Packet 4: Last UDP data packet >>--------- >> >>Frame 51 Size 1298 Absolute Time Apr 26 15:41:35.402 ASCII MODE >>------------------------------------------------------------------------------- >>----- Level # 1 is ETHERNET Offset: 0 Size: 14 >> >> Dest Address : Cisco -07-ac-10 00 00 0c 07 ac 10 ...... >> Source Address : Sun -9a-d8-b3 08 00 20 9a d8 b3 .. ... >> Type : 2048 (DoD IP) 08 00 .. >>----- Level # 2 is DoD IP Offset: 14 Size: 20 >> >> Version : 4 4 . >> Header Length : 20 5 . >> Type Of Service: 0 00 . >> >> : 000..... Routine >> : ...0.... Normal Delay >> : ....0... Normal Throughput >> : .....0.. Normal Reliability >> Total Length : 1280 05 00 .. >> Identification : 2736 0a b0 <- critical info >> Flags : 2 2 . >> : 0.. Reserved >> : .1. Don't Fragment >> : ..0 Last Fragment < last fragment >> Fragment Offset: 344 42 2b B+ >> Time To Live : 255 ff . >> Protocol : 17 (DODUDP) 11 . >> Header Checksum: 52561 cd 51 .Q >> Source Address : [134.79.16.109] AFS09.SLAC.Stanfo86 4f 10 6d .O.m >> Dest Address : [128.138.133.121] blanca.Colorado80 8a 85 79 ...y >>----- Level # 7 is UserData Offset: 34 Size: 1264 >> >> 00032: 70 69 73 61 2e 69 6e 66 6e 2e 69 74 20 42 pisa.infn.it B >> >>##################################### >> >> >>Connie Logg - Network Analyst - 650-926-2879 >>Stanford Linear Accelerator Center >>MS 97; 2575 SandHill Road; Menlo Park CA 94025 >>"Happiness is found along the way, not at the end of the road" > >((((((((((((()))))))))))) >Kamlesh Shah CCIE # 2803 >Technical Marketing Engineer - MPLS, ISBU ((((((((((((()))))))))))) Kamlesh Shah CCIE # 2803 Technical Marketing Engineer - MPLS, ISBU From owner-rtfm@auckland.ac.nz Fri May 18 19:37:06 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19350 for ; Fri, 18 May 2001 19:37:04 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id KAA07952; Sat, 19 May 2001 10:15:54 +1200 (NZST) Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id KAA07946 for ; Sat, 19 May 2001 10:15:52 +1200 (NZST) Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 150sP6-0001b2-00; Fri, 18 May 2001 17:07:24 -0500 Date: Fri, 18 May 2001 17:07:24 -0500 From: Dave Plonka To: ipfx@net.doit.wisc.edu Cc: rtfm@auckland.ac.nz Subject: DRAFT proposed charter for IPFX WG Message-ID: <20010518170724.A5261@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Organization: UW-Madison, DoIT, Network Services X-VMS-Error: %SYSTEM-E-SYSERROR, system service error X-Shakespearean-Insult: Thou goatish rough-hewn mammet Sender: owner-rtfm@auckland.ac.nz Precedence: bulk IPFX folks, Below is the proposed draft charter that Mike MacFaden, Kevin Zhang, and Nevil Brownlee assisted in preparing and that has been submitted for consideration by the Operations and Management Area Directors. Randy's recent Cc's to the list were in response to this draft. Please send comments and suggestions on the charter to the ipfx mailing list. Thanks, Dave >>>>>>>>>>>>> DRAFT proposed charter for IPFX WG <<<<<<<<<<<<<<<<< (ipfx_charter_00.txt) IP Flow Export (IPFX) IETF Area: Operations and Management Area Chair(s): Nevil Brownlee Dave Plonka Operations and Management Area Director(s): Randy Bush Bert Wijnen Responsible Area Director: TBD Mailing Lists: General Discussion: ipfx@net.doit.wisc.edu To Subscribe: majordomo@net.doit.wisc.edu with "subscribe ipfx" in message body Archive: http://ipfx.doit.wisc.edu/ Description of Working Group: There is a need in industry and the Internet research community for IP devices such as routers to export flow information in a standard way to external systems such as mediation systems, accounting/billing systems, and network management systems to facilitate services such as measurement, accounting, and billing. This group will define a protocol by which IP flow information can be transferred in a timely fashion from an "exporter" to a collection station or stations. The "exporter", which is typically an IP router or IP traffic measurement device, will employ the IP flow export protocol to report "IP flows", these being series of related IP packets that have been either forwarded or dropped. The reported flow details will include both (1) those attributes derived from the IP packet headers such as source and destination address, protocol, and port number and (2) those attributes often known only to an IP router such as timestamps, ingress and egress ports, IP (sub)net mask, and autonomous system numbers. In doing so, the group has the following specific goals: o Devise a protocol that provides a flexible but specialized, high performance, online IP Flow export capability which meets the work-load, reliability and timeliness requirements of existing applications that rely on IP flow export. o Define the notion of a "standard IP flow" within the protocol specification. The flow definition will be a practical one, similar to those currently in use by existing non-standard flow export protocols which have attempted to acheive similar goals but have not documented their flow defintion. o Devise data encodings that support analysis of MPLS, IPv4 and IPv6 unicast and multicast flows traversing a network element at packet header level and other levels of aggregation as requested by the network operator according to the capabilities of the given router implementation. o Ensure that the protocol is reasonable to implement by router and instrumentation developers and is easy to deploy by network operators. o Design the protocol to be reliable in that it will minimize the likelihood of flow data being lost and to accurately report such loss if it occurs. This may involve supporting the use of firewall/proxy between network element and collectors as well as load balance amongst multiple collectors. o Consider the notion of IP flow export based upon packet sampling. Goals and Milestones: Jun 2001 Request BOF at IETF 51 in London. BOF would discuss the charter, continue the requirements discussion, and begin discussion on Transport Layer protocol and Data encoding model. Late Jun 2001 Submit Internet-Draft on IP Flow Export Requirements IPFX-REQUIREMENTS Late Sep 2001 Submit Revised Internet-Draft on IP Flow Export Requirements IPFX-REQUIREMENTS Early Feb 2002 Submit IPFX-REQUIREMENTS to IESG for publication, Informational RFC Submit Internet-Draft on IP Flow Export Protocol IPFX-PROTOCOL Submit Internet-Draft on IP Flow Export Data Model IPFX-DATAMODEL Early May 2002 Submit IPFX-DATAMODEL to IESG for publication, Informational RFC Submit IPFX-PROTOCOL to IESG for publication, Proposed Standard RFC (also need an Applicability Statement RFC) -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI From owner-rtfm@auckland.ac.nz Tue May 22 12:57:50 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25486 for ; Tue, 22 May 2001 12:57:48 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id AAA01817; Wed, 23 May 2001 00:13:16 +1200 (NZST) Received: from wi3x05.informatik.uni-wuerzburg.de (qmailr@wi3x05.informatik.uni-wuerzburg.de [132.187.106.5]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id AAA01806 for ; Wed, 23 May 2001 00:13:14 +1200 (NZST) Received: (qmail 17316 invoked from network); 22 May 2001 12:12:48 -0000 Received: from wi3d28.informatik.uni-wuerzburg.de (HELO MUSA.informatik.uni-wuerzburg.de) (132.187.106.128) by wi3x05.informatik.uni-wuerzburg.de with SMTP; 22 May 2001 12:12:48 -0000 Message-Id: <4.3.1.2.20010522083425.00b6bf30@nero.informatik.uni-wuerzburg.de> X-Sender: tutschku@nero.informatik.uni-wuerzburg.de X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 22 May 2001 11:12:27 -0100 To: netramet@auckland.ac.nz, rtfm@auckland.ac.nz From: Kurt Tutschku Subject: Flowtime distribution and distribution-valued attributes Cc: tutschku@informatik.uni-wuerzburg.de Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Dear NeTraMet and RTFM community, I'm looking for more information respectively for experience with the new "distribution-valued" attributes as defined in RFC 2724. Particular , I'd like to measure the "Flowtime distribution" of certain applications. In detail, I have the following questions: a) Specifying Distributions: --------------------------------------- To clarify my view: when using the logarithmic transformation, as defined in Section 3.2 of RFC 2724, the upper limits of each bucket are defined as: upper_limit_of_bucket_i = lower_limit * m^(i-1) with m = (upper_limit/lower_limit)^(1/(number_of_buckets-1)) where: "lower_limit": highest value for the first bucket "upper_limit": is the highest value for the last bucket "number_of_buckets": Number of buckets; does not include the 'overflow' bucket. Is this correct? b) Flows and Streams: --------------------------------- The new release of the NeTraMet meter is able to identify "Streams" in "Flows" , see also Nevil Brownlee's new paper "Streams, Flows and Torrents", cf. [1]. I'm using NeTraMet Version 44b9 My questions is, has any one experience in the determination of "StreamLastTime" and the tuning the variable "Interval" (which defines the end of a "Stream")? Where can I find the compile-time variables for "InactTime" and "TimeMultiplier" in NeTraMet? During my tests with the "Flowtime" distribution attribute, sometimes the distribution was empty (that means only a single "0" as output for the complete distribution) and sometime the distribution contained values. Thus, here my question is, when is the distribution updated by the meter? And when are the values printed/accessable? Literature: [1] Nevil Brownlee: "Streams, Flows and Torrents" in Proceedings of PAM'2001 available at: http://www.ripe.net/pam2001/program.html Cheers Kurt ---- Dr. Kurt Tutschku Institute of Computer Science Am Hubland 97074 Wuerzburg Germany Tel.: +49-931-8886641 FAX.: +49-931-8886632 mailto:tutschku@informatik.uni-wuerzburg.de or mailto:kurttutschku@hotmail.com http://www-info3.informatik.uni-wuerzburg.de/staff/tutschku From owner-rtfm@auckland.ac.nz Thu May 24 12:03:00 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16262 for ; Thu, 24 May 2001 12:02:59 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id CAA21154; Fri, 25 May 2001 02:22:52 +1200 (NZST) Received: from budgie.cerbernet.co.uk (postfix@budgie.cerbernet.co.uk [193.243.233.95]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id CAA20764; Fri, 25 May 2001 02:15:36 +1200 (NZST) From: sean.kelly@the-web-works.co.uk Received: from localhost (localhost [127.0.0.1]) by budgie.cerbernet.co.uk (Postfix) with SMTP id 04DA62FD3; Thu, 24 May 2001 15:14:35 +0100 (BST) To: netramet@auckland.ac.nz Cc: rtfm@auckland.ac.nz subject: re: Monitoring and reporting network usage Message-Id: <20010524141436.04DA62FD3@budgie.cerbernet.co.uk> Date: Thu, 24 May 2001 15:14:36 +0100 (BST) Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hi there, Thanks to all those who replied to my first message. I have a few points I wish to reply to and some new questions to ask. As a reminder, I will say that my problem is finding a new network traffic monitoring application - preferably a free one! Some people asked me to explain my current setup a little more. I have a 4.2-RELEASE FreeBSD box with a 600Mhz Pentium III processor and 64Mb RAM. This is running 'Snuffle' by Thomas Ptacek using a 100Mbit RTL8139-based network card. We have a 2Mbit Internet connection supplied with a Cisco router (we have no access to the router itself). We have plugged this Cisco into a 10Mbit 4-port Netgear hub along with the FreeBSD monitoring box and our main network switch. The hub's collision light flashes 2 or 3 times every couple of seconds. The switch has various routers plugged into it, but basically we have about 16 machines (50 IPs) in our network centre, about 40 IPs allocated to leased lines customers and about 70 IPs allocated to ADSL customers. According to MRTG readings from our main router, our average traffic over the past few months in about 48kB/s in both dorections. However, if we look at the smaller time frames we see peaks sometimes reaching nearly 200kB/s for output. The problem we are seeing with Snuffle is that it seems to be missing some traffic. On the above information, is the assumption that the fault lies with Snuffle reasonable? Could the problem actually be that our machine simply cannot log all the traffic that passes through it? What are your opinions in running NeTraMet in the above situation? Thanks in advance, -- Sean Kelly From owner-rtfm@auckland.ac.nz Thu May 24 21:49:15 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24633 for ; Thu, 24 May 2001 21:49:14 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id MAA14569; Fri, 25 May 2001 12:22:21 +1200 (NZST) Received: from caida.org (ipn.caida.org [192.172.226.30]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id MAA14557; Fri, 25 May 2001 12:22:18 +1200 (NZST) Received: from localhost (nevil@localhost) by caida.org (8.9.3+Sun/8.9.1) with ESMTP id RAA03061; Thu, 24 May 2001 17:22:16 -0700 (PDT) Date: Thu, 24 May 2001 17:22:16 -0700 (PDT) From: Nevil Brownlee To: Kurt Tutschku cc: , Subject: Re: Flowtime distribution and distribution-valued attributes In-Reply-To: <4.3.1.2.20010522083425.00b6bf30@nero.informatik.uni-wuerzburg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello Kurt: I've just produced a first - very preliminary - version of a distribution file for those wishing to use distribution-valued attributes. Its on the distribution site as beta-versions/distrib-progs.tar.gz It contains a .txt file with fairly lengthy notes, copies of the .srl rulesets used for my PAM2001 papers, and my perl programs for working with the distributions. Do please try the rulesets - you'll have to change the IP netblocks to suit your own network, of course. I suggest you start with data-rate.srl. (Of course you may find it quicker/easier to write your own scripts for processing flow data files which contain distributions :-) > a) Specifying Distributions: > --------------------------------------- > To clarify my view: when using the logarithmic transformation, as defined > in Section 3.2 of RFC 2724, the upper limits of each bucket are > defined as: > > upper_limit_of_bucket_i = lower_limit * m^(i-1) > > with > > m = (upper_limit/lower_limit)^(1/(number_of_buckets-1)) > > where: > "lower_limit": highest value for the first bucket > "upper_limit": is the highest value for the last bucket > "number_of_buckets": Number of buckets; does not include the > 'overflow' bucket. > > Is this correct? Yes. distrib-progs contains a script called scale_test.pl which will compute and display the upper values for each bin for a given set of distribution parameters. > b) Flows and Streams: > --------------------------------- > > The new release of the NeTraMet meter is able to identify "Streams" in > "Flows" , see > also Nevil Brownlee's new paper "Streams, Flows and Torrents", cf. [1]. > > I'm using NeTraMet Version 44b9 > My questions is, has any one experience in the determination of > "StreamLastTime" and the tuning the variable "Interval" (which defines > the end of a > "Stream")? I did quite a bit of testing of this, without coming to any definite conclusions. That's why all I could say at PAM was "using any dynamic timeout scheme means making some assuption(s) about the time behaviour of the streams!" > Literature: > [1] Nevil Brownlee: "Streams, Flows and Torrents" in Proceedings of > PAM'2001 available > at: http://www.ripe.net/pam2001/program.html Cheers, Nevil ------------------------------------------------------------- Nevil Brownlee Internet Researcher Phone: (858) 534 8338 CAIDA, San Diego From owner-rtfm@auckland.ac.nz Wed May 30 10:32:10 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12934 for ; Wed, 30 May 2001 10:32:08 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id AAA13179; Thu, 31 May 2001 00:50:01 +1200 (NZST) Received: from babar.switch.ch (babar.switch.ch [130.59.4.2]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id AAA13152 for ; Thu, 31 May 2001 00:49:55 +1200 (NZST) Received: (from leinen@localhost) by babar.switch.ch (8.9.3+Sun/8.9.3) id OAA20212; Wed, 30 May 2001 14:49:18 +0200 (MEST) X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f To: plonka@doit.wisc.edu Cc: ipfx@net.doit.wisc.edu, rtfm@auckland.ac.nz Subject: MPLS flows out of scope? [Re: DRAFT proposed charter for IPFX WG] References: <20010518170724.A5261@doit.wisc.edu> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: <20010518170724.A5261@doit.wisc.edu> Date: 30 May 2001 14:49:17 +0200 Message-ID: Lines: 23 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Dave & all, thanks for your work on the draft charter. Looks very good to me. Once of the the suggested goals is described as: > o Devise data encodings that support analysis of MPLS, IPv4 and > IPv6 unicast and multicast flows traversing a network element at > packet header level and other levels of aggregation as requested > by the network operator according to the capabilities of the > given router implementation. I'd prefer to *not* have MPLS explicitly mentioned in the charter. MPLS has its own concepts of flows (FECs, LSPs, TE trunks...), and the MPLS and Traffic Engineering working groups are developing their own mechanisms for looking at traffic within those. We should concentrate on IP flows and treat MPLS as one of many possible link (or "linkwork") layers. If we find it useful/necessary to add support for lower-layer-specific information in flow data (such as LSPs for MPLS, or MAC addresses for 802 links, or VC ids for ATM/Frame Relay etc.), then that's fine with me. -- Simon. From owner-rtfm@auckland.ac.nz Wed May 30 10:56:15 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13733 for ; Wed, 30 May 2001 10:56:14 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id BAA14874; Thu, 31 May 2001 01:20:50 +1200 (NZST) Received: from rooster.cisco.com (rooster.cisco.com [64.102.19.200]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id BAA14869 for ; Thu, 31 May 2001 01:20:49 +1200 (NZST) Received: from kshah-w2k.cisco.com (dhcp-64-102-78-109.cisco.com [64.102.78.109]) by rooster.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA25229; Wed, 30 May 2001 09:19:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20010530090823.0175aa80@rooster.cisco.com> X-Sender: kshah@rooster.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 May 2001 09:19:23 -0400 To: Simon Leinen , plonka@doit.wisc.edu From: Kamlesh Shah Subject: Re: MPLS flows out of scope? [Re: DRAFT proposed charter for IPFX WG] Cc: ipfx@net.doit.wisc.edu, rtfm@auckland.ac.nz In-Reply-To: References: <20010518170724.A5261@doit.wisc.edu> <20010518170724.A5261@doit.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Simon, One of the things that differentiates MPLS from other examples you have below (such as vlan ids) is that it is an end-to-end thing in many ISP networks today. If we do not account for MPLS, then we run the risk of ignoring a large portion of networks that will benefit. The problem in covering MPLS as just another link layer technology is that we will loose capturing the information that is needed to complete end-to-end flow definition/capture as part of the charter. Where as IETF has several RFCs and work in progress documents covering various aspects of MPLS networks, I do not know of any single one of them covering something similar to NetFlow (of Cisco). Regards. At 02:49 PM 5/30/2001 +0200, Simon Leinen wrote: >Dave & all, > >thanks for your work on the draft charter. Looks very good to me. >Once of the the suggested goals is described as: > >> o Devise data encodings that support analysis of MPLS, IPv4 and >> IPv6 unicast and multicast flows traversing a network element at >> packet header level and other levels of aggregation as requested >> by the network operator according to the capabilities of the >> given router implementation. > >I'd prefer to *not* have MPLS explicitly mentioned in the charter. >MPLS has its own concepts of flows (FECs, LSPs, TE trunks...), and the >MPLS and Traffic Engineering working groups are developing their own >mechanisms for looking at traffic within those. > >We should concentrate on IP flows and treat MPLS as one of many >possible link (or "linkwork") layers. If we find it useful/necessary >to add support for lower-layer-specific information in flow data (such >as LSPs for MPLS, or MAC addresses for 802 links, or VC ids for >ATM/Frame Relay etc.), then that's fine with me. >-- >Simon. ((((((((((((()))))))))))) Kamlesh Shah CCIE # 2803 Technical Marketing Engineer - MPLS, ISBU From owner-rtfm@auckland.ac.nz Wed May 30 11:22:39 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14714 for ; Wed, 30 May 2001 11:22:37 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id CAA17812; Thu, 31 May 2001 02:12:37 +1200 (NZST) Received: from rooster.cisco.com (rooster.cisco.com [64.102.19.200]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id CAA17805 for ; Thu, 31 May 2001 02:12:35 +1200 (NZST) Received: from kshah-w2k.cisco.com (dhcp-64-102-78-109.cisco.com [64.102.78.109]) by rooster.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA03250; Wed, 30 May 2001 10:11:07 -0400 (EDT) Message-Id: <4.3.2.7.2.20010530100924.01e2d008@rooster.cisco.com> X-Sender: kshah@rooster.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 May 2001 10:10:47 -0400 To: Randy Bush From: Kamlesh Shah Subject: Re: MPLS flows out of scope? [Re: DRAFT proposed charter for IPFX WG] Cc: Simon Leinen , plonka@doit.wisc.edu, ipfx@net.doit.wisc.edu, rtfm@auckland.ac.nz In-Reply-To: References: <20010518170724.A5261@doit.wisc.edu> <4.3.2.7.2.20010530090823.0175aa80@rooster.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rtfm@auckland.ac.nz Precedence: bulk And your point is ?? Please, if you are going to waste my in box, I will have to add you to the spam list..lets be reasonable here..and give me a break. Regards. At 07:04 AM 5/30/2001 -0700, Randy Bush wrote: >> One of the things that differentiates MPLS from other examples you have >> below (such as vlan ids) is that it is an end-to-end thing in many ISP >> networks today. > >and pigs fly > >randy ((((((((((((()))))))))))) Kamlesh Shah CCIE # 2803 Technical Marketing Engineer - MPLS, ISBU From owner-rtfm@auckland.ac.nz Wed May 30 18:04:57 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25948 for ; Wed, 30 May 2001 18:04:55 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id IAA18297; Thu, 31 May 2001 08:40:11 +1200 (NZST) Received: from rooster.cisco.com (rooster.cisco.com [64.102.19.200]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id IAA18267 for ; Thu, 31 May 2001 08:40:08 +1200 (NZST) Received: from kshah-w2k.cisco.com (kshah-dsl4.cisco.com [10.83.17.29]) by rooster.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA15049; Wed, 30 May 2001 16:39:04 -0400 (EDT) Message-Id: <4.3.2.7.2.20010530163457.01e3ae98@rooster.cisco.com> X-Sender: kshah@rooster.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 May 2001 16:38:45 -0400 To: Randy Bush From: Kamlesh Shah Subject: Re: MPLS flows out of scope? [Re: DRAFT proposed charter for IPFX WG] Cc: ipfx@net.doit.wisc.edu, rtfm@auckland.ac.nz In-Reply-To: References: <20010518170724.A5261@doit.wisc.edu> <4.3.2.7.2.20010530090823.0175aa80@rooster.cisco.com> <4.3.2.7.2.20010530100924.01e2d008@rooster.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Randy, I certainly do not take your comments personally, and no MPLS is not my religion. Its just something I do, and am trying to learn a few things about in this little brain of mine. I think it is a good idea to consider it in our discussions in case it does stay around for a couple of days and in a couple of ISPs networks. Regards. At 10:56 AM 5/30/2001 -0700, Randy Bush wrote: >>>> One of the things that differentiates MPLS from other examples you have >>>> below (such as vlan ids) is that it is an end-to-end thing in many ISP >>>> networks today. >>> and pigs fly >> And your point is ?? > >apologies for being terse. and for stepping on your religion. > >despite some vendor madly pushing atm-2, it's being used by very few isps. >and they are having a heck of a time with implementation issues. and the >wonderful benefits may be as elusive as atm-1. > >so it would be best if the bof and wg focus on normal internet solutions >as well as trying to sort out how to cover atm-2 approaches as well. > >randy ((((((((((((()))))))))))) Kamlesh Shah CCIE # 2803 Technical Marketing Engineer - MPLS, ISBU From owner-rtfm@auckland.ac.nz Wed May 30 20:12:47 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27813 for ; Wed, 30 May 2001 20:12:45 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id JAA00749; Thu, 31 May 2001 09:29:07 +1200 (NZST) Received: from babar.switch.ch (babar.switch.ch [130.59.4.2]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id JAA00728 for ; Thu, 31 May 2001 09:29:05 +1200 (NZST) Received: (from leinen@localhost) by babar.switch.ch (8.9.3+Sun/8.9.3) id XAA21062; Wed, 30 May 2001 23:28:23 +0200 (MEST) X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f To: Kamlesh Shah Cc: Dave Plonka , ipfx@net.doit.wisc.edu, rtfm@auckland.ac.nz Subject: Re: MPLS flows out of scope? [Re: DRAFT proposed charter for IPFX WG] References: <20010518170724.A5261@doit.wisc.edu> <20010518170724.A5261@doit.wisc.edu> <4.3.2.7.2.20010530090823.0175aa80@rooster.cisco.com> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: <4.3.2.7.2.20010530090823.0175aa80@rooster.cisco.com> Date: 30 May 2001 23:28:23 +0200 Message-ID: Lines: 51 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-rtfm@auckland.ac.nz Precedence: bulk >>>>> "ks" == Kamlesh Shah writes: > One of the things that differentiates MPLS from other examples you > have below (such as vlan ids) is that it is an end-to-end thing in > many ISP networks today. Actually this may not be such a good example, because ATM is also something that is an end-to-end thing (customer-to-customer service) in several otherwise IP networks today, including the one I help operate. > If we do not account for MPLS, then we run the risk of ignoring a > large portion of networks that will benefit. Sure, but since we won't make everybody happy anyway, we should try to make our task as clearly defined as possible. And adding MPLS to the picture just makes it a whole lot fuzzier to me. There's a lot of experience with flow export mechanisms for IPv4 (such as LFAP and NetFlow), so I think we have a good basis for building a standard on that - which doesn't mean we're guaranteed to succeed. Extension to IPv6 is natural and shouldn't provide much contention, so it makes sense to include that from the beginning. But extending the flow concept to "MPLS traffic flows" looks hairier to me (different domain), and we certainly cannot build on a comparable amount of operational experience with it. So as a practical matter (to keep our task tractable), I'd suggest to remove it from the list of initial goals in the charter. Or at least move it to a "for extra points^H^H^H^H^H^H^H^H^H^H^H^Hfurther study" section. But personally I'd prefer to delegate responsibility for this to the MPLS group. > The problem in covering MPLS as just another link layer technology > is that we will loose capturing the information that is needed to > complete end-to-end flow definition/capture as part of the charter. > Where as IETF has several RFCs and work in progress documents > covering various aspects of MPLS networks, I do not know of any > single one of them covering something similar to NetFlow (of Cisco). Maybe a NetFlow-like mechanism isn't really necessary for MPLS networks, because MPLS has its own "natural" ways of grouping traffic into aggregates, and defines mechanisms to count traffic in those aggregates that are more convenient to use than the flow-export schemes that are the topic of this group. -- Simon Leinen simon@babar.switch.ch SWITCH http://www.switch.ch/misc/leinen/ Computers hate being anthropomorphized. From owner-rtfm@auckland.ac.nz Wed May 30 23:01:51 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01458 for ; Wed, 30 May 2001 23:01:50 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id NAA05833; Thu, 31 May 2001 13:51:22 +1200 (NZST) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id NAA05828 for ; Thu, 31 May 2001 13:51:21 +1200 (NZST) Received: from mordor.yagosys.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id SAA02751; Wed, 30 May 2001 18:50:49 -0700 (PDT) Received: from celtic.riverstonenet.com by mordor.yagosys.com (SMI-8.6/SMI-SVR4) id SAA17036; Wed, 30 May 2001 18:50:47 -0700 Message-Id: <5.0.2.1.1.20010530221425.029faaa0@mordor> X-Sender: mrm@mordor X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 31 May 2001 01:52:01 -0700 To: ipfx@net.doit.wisc.edu, rtfm@auckland.ac.nz From: Mike MacFaden Subject: Re: MPLS flows out of scope? [Re: DRAFT proposed charter for IPFX WG] In-Reply-To: References: <4.3.2.7.2.20010530090823.0175aa80@rooster.cisco.com> <20010518170724.A5261@doit.wisc.edu> <20010518170724.A5261@doit.wisc.edu> <4.3.2.7.2.20010530090823.0175aa80@rooster.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rtfm@auckland.ac.nz Precedence: bulk At 11:28 PM 5/30/01 +0200, Simon Leinen wrote: >Sure, but since we won't make everybody happy anyway, we should try to >make our task as clearly defined as possible. And adding MPLS to the >picture just makes it a whole lot fuzzier to me. I agree having MPLS risks the overall delivery of IPFX. >But extending the flow concept to "MPLS traffic flows" looks hairier >to me (different domain), and we certainly cannot build on a >comparable amount of operational experience with it. > >So as a practical matter (to keep our task tractable), I'd suggest to >remove it from the list of initial goals in the charter. Or at least >move it to a "for extra points^H^H^H^H^H^H^H^H^H^H^H^Hfurther study" >section. But personally I'd prefer to delegate responsibility for >this to the MPLS group. I like the idea of moving it to an "extra points" section to reduce the risk to the schedule and to keep the group (if chartered) more focused on one clear goal. I do not believe we should punt the responsiblity just yet. Having reviewed the MPLS-TE-MIB and TE-MIB modules as well as the LSR and LDP and ... I happen to think there is a good match for the kinds of information that will be shipped to mgmt apps from LSRs. >Maybe a NetFlow-like mechanism isn't really necessary for MPLS >networks, because MPLS has its own "natural" ways of grouping traffic >into aggregates, and defines mechanisms to count traffic in those >aggregates that are more convenient to use than the flow-export >schemes that are the topic of this group. Perhaps, but current reading of the TE-MIB and MPLS-TE MIB modules at least to me shows IPFX could be a vehicle for delivering vast quantities of information as found in these MIB modules in a way that scales. For example, given the indexing schemes of teTunnelList and mplsTunnelTable, the number of rows in these tables can grow very large. Both drafts define a tunnel name (32 or 255 chars depending on the author) and provide byte and packet counters. Still, I'm not sure how well this class of data behaves compared to ipv4/6 which as I stated before might only serve to complicate an IPFX protocol needlessly. And even if MPLS is ruled out of the charter, somehow relating flows to mpls tunnels or dlci's or pvcs would be a good thing. Regards, Mike MacFaden From owner-rtfm@auckland.ac.nz Thu May 31 00:07:24 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02436 for ; Thu, 31 May 2001 00:07:22 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id PAA21529; Thu, 31 May 2001 15:00:41 +1200 (NZST) Received: from smtp5ve.mailsrvcs.net (smtp5vepub.gte.net [206.46.170.26]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id PAA21510 for ; Thu, 31 May 2001 15:00:38 +1200 (NZST) Received: from sphynx (adsl-162-83-198-57.nyc.adsl.bellatlantic.net [162.83.198.57]) by smtp5ve.mailsrvcs.net (8.9.1/8.9.1) with ESMTP id DAA11841740; Thu, 31 May 2001 03:04:44 GMT From: "Carter Bullard" To: "'Kamlesh Shah'" , "'Simon Leinen'" Cc: "'Dave Plonka'" , , Subject: RE: MPLS flows out of scope? [Re: DRAFT proposed charter for IPFX WG] Date: Wed, 30 May 2001 22:59:24 -0400 Message-ID: <38E99DA2CEFA7248B5828BBF99344D8608C29B@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <4.3.2.7.2.20010530213154.01e5cb10@rooster.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7bit Gentle People, If you have a flexible flow key descriptor that is separate from the flow attributes that are reported in a flow data record (FDR), reporting on MPLS flows, or DSbyte flows, IPv6 flow_id flows, Layer 2 flows, ifIndex flows, VP flows, AS-AS flows, RTP based streaming media flows, ESP tunnel flows or traditional 5-tuple flows, whether they are uni-directional or bi-directional is really a very simple matter. The trick is to work within the limits of relational algebra. With a little bit of attention paid to flow key and flow attribute concepts, the FDR can be well structured such that it can handle all the semantics that the TE WG has discussed, as well as the semantics that are supported by all the current flow based technology. Just a thought, Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter@qosient.com Phone +1 212 588-9133 Fax +1 212 588-9134 http://qosient.com -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Kamlesh Shah Sent: Wednesday, May 30, 2001 10:22 PM To: Simon Leinen Cc: Dave Plonka; ipfx@net.doit.wisc.edu; rtfm@auckland.ac.nz Subject: Re: MPLS flows out of scope? [Re: DRAFT proposed charter for IPFX WG] Simon, You have raised some very valid/good points to consider. Please see in line. At 11:28 PM 5/30/2001 +0200, Simon Leinen wrote: >>>>>> "ks" == Kamlesh Shah writes: >> One of the things that differentiates MPLS from other examples you >> have below (such as vlan ids) is that it is an end-to-end thing in >> many ISP networks today. > >Actually this may not be such a good example, because ATM is also >something that is an end-to-end thing (customer-to-customer service) in >several otherwise IP networks today, including the one I help operate. I need to better explain my thought. I was thinking that since we are trying to do "IP Flow Export", the focus needs to be able to capture IP flows information end-to-end. This is somewhat different than IP packets that traverse an ATM cloud, which is similar in category to flows which traverse a FR cloud, where IP is mapped into layer 2 technology to traverse the cloud and really the only Layer 3 relationship exist between the edge devices. In case of MPLS, even though it is layer 2 and a half technology, the layer 3 relationship is carried thought out the cloud and is often transformed (read copied) from out of the cloud to in the cloud, gfor instance TTL and TOS bits. Hence the comment about considering MPLS as an aspect. >> If we do not account for MPLS, then we run the risk of ignoring a >> large portion of networks that will benefit. > >Sure, but since we won't make everybody happy anyway, we should try to >make our task as clearly defined as possible. And adding MPLS to the >picture just makes it a whole lot fuzzier to me. That is a matter of consensus, and I have no problem with this line of reasoning if generally speaking we want to keep it that way as a group. >There's a lot of experience with flow export mechanisms for IPv4 (such >as LFAP and NetFlow), so I think we have a good basis for building a >standard on that - which doesn't mean we're guaranteed to succeed. >Extension to IPv6 is natural and shouldn't provide much contention, so >it makes sense to include that from the beginning. Agree, IPV6 is much easier extension to consider as well as the fact that we all have a lot more experience with Flow export in the context of plane old IPv4 networks. >But extending the flow concept to "MPLS traffic flows" looks hairier to >me (different domain), and we certainly cannot build on a comparable >amount of operational experience with it. > >So as a practical matter (to keep our task tractable), I'd suggest to >remove it from the list of initial goals in the charter. Or at least >move it to a "for extra points^H^H^H^H^H^H^H^H^H^H^H^Hfurther study" >section. But personally I'd prefer to delegate responsibility for this >to the MPLS group. Please note, I am tuned into a lot of MPLS work in Cisco, and have some exposure to MPLS work out side of Cisco as well. I do NOT think there is *ANY* work going on to capture the flows or to define MPLS flows from the point of view of doing something similar to what we do with NetFlow export for instance. I would suggest to consider this for discussion here with some valid reasoning behind our actions besides the fact that we do not feel fully comfortable to handle this aspect or to keep it simple. At best, I can suggest to keep it as an item of discussion some what later in the process rather than dropping it altogether. >> The problem in covering MPLS as just another link layer technology is >> that we will loose capturing the information that is needed to >> complete end-to-end flow definition/capture as part of the charter. > >> Where as IETF has several RFCs and work in progress documents >> covering various aspects of MPLS networks, I do not know of any >> single one of them covering something similar to NetFlow (of Cisco). > >Maybe a NetFlow-like mechanism isn't really necessary for MPLS >networks, because MPLS has its own "natural" ways of grouping traffic >into aggregates, and defines mechanisms to count traffic in those >aggregates that are more convenient to use than the flow-export schemes >that are the topic of this group. I would go with this line of reasoning if MPLS was somewhat of a proprietary thing. Where as MPLS does have a concept of FECs (Forwarding Equivalence Class), to group traffic into "classes", this is still a layer 3 thing, and as such if we ignore this completely, we ignore a very crucial part of (at least some) SP networks. When you report a flow export from such a network, how do we treat the IP traffic flows behavior ?? How does an SP who is trying to charge for an IP flow account this part of his network ? So, I think we need to think thru this. At the very least, we should make a statement about things like this and Layer 2 VPNs to untangle this later in the process if that is what most folks here think, and I would be willing to table this for now. >-- >Simon Leinen simon@babar.switch.ch >SWITCH http://www.switch.ch/misc/leinen/ > > Computers hate being anthropomorphized. ((((((((((((()))))))))))) Kamlesh Shah CCIE # 2803 Technical Marketing Engineer - MPLS, ISBU -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfx" in message body Archive http://ipfx.doit.wisc.edu/list/ipfx/archive/ From owner-rtfm@auckland.ac.nz Thu May 31 00:41:25 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.191.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02775 for ; Thu, 31 May 2001 00:41:24 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id OAA13280; Thu, 31 May 2001 14:23:55 +1200 (NZST) Received: from rooster.cisco.com (rooster.cisco.com [64.102.19.200]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id OAA13268 for ; Thu, 31 May 2001 14:23:53 +1200 (NZST) Received: from kshah-w2k.cisco.com (kshah-dsl4.cisco.com [10.83.17.29]) by rooster.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA01330; Wed, 30 May 2001 22:22:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20010530213154.01e5cb10@rooster.cisco.com> X-Sender: kshah@rooster.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 May 2001 22:22:28 -0400 To: Simon Leinen From: Kamlesh Shah Subject: Re: MPLS flows out of scope? [Re: DRAFT proposed charter for IPFX WG] Cc: Dave Plonka , ipfx@net.doit.wisc.edu, rtfm@auckland.ac.nz In-Reply-To: References: <4.3.2.7.2.20010530090823.0175aa80@rooster.cisco.com> <20010518170724.A5261@doit.wisc.edu> <20010518170724.A5261@doit.wisc.edu> <4.3.2.7.2.20010530090823.0175aa80@rooster.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Simon, You have raised some very valid/good points to consider. Please see in line. At 11:28 PM 5/30/2001 +0200, Simon Leinen wrote: >>>>>> "ks" == Kamlesh Shah writes: >> One of the things that differentiates MPLS from other examples you >> have below (such as vlan ids) is that it is an end-to-end thing in >> many ISP networks today. > >Actually this may not be such a good example, because ATM is also >something that is an end-to-end thing (customer-to-customer service) >in several otherwise IP networks today, including the one I help >operate. I need to better explain my thought. I was thinking that since we are trying to do "IP Flow Export", the focus needs to be able to capture IP flows information end-to-end. This is somewhat different than IP packets that traverse an ATM cloud, which is similar in category to flows which traverse a FR cloud, where IP is mapped into layer 2 technology to traverse the cloud and really the only Layer 3 relationship exist between the edge devices. In case of MPLS, even though it is layer 2 and a half technology, the layer 3 relationship is carried thought out the cloud and is often transformed (read copied) from out of the cloud to in the cloud, gfor instance TTL and TOS bits. Hence the comment about considering MPLS as an aspect. >> If we do not account for MPLS, then we run the risk of ignoring a >> large portion of networks that will benefit. > >Sure, but since we won't make everybody happy anyway, we should try to >make our task as clearly defined as possible. And adding MPLS to the >picture just makes it a whole lot fuzzier to me. That is a matter of consensus, and I have no problem with this line of reasoning if generally speaking we want to keep it that way as a group. >There's a lot of experience with flow export mechanisms for IPv4 (such >as LFAP and NetFlow), so I think we have a good basis for building a >standard on that - which doesn't mean we're guaranteed to succeed. >Extension to IPv6 is natural and shouldn't provide much contention, so >it makes sense to include that from the beginning. Agree, IPV6 is much easier extension to consider as well as the fact that we all have a lot more experience with Flow export in the context of plane old IPv4 networks. >But extending the flow concept to "MPLS traffic flows" looks hairier >to me (different domain), and we certainly cannot build on a >comparable amount of operational experience with it. > >So as a practical matter (to keep our task tractable), I'd suggest to >remove it from the list of initial goals in the charter. Or at least >move it to a "for extra points^H^H^H^H^H^H^H^H^H^H^H^Hfurther study" >section. But personally I'd prefer to delegate responsibility for >this to the MPLS group. Please note, I am tuned into a lot of MPLS work in Cisco, and have some exposure to MPLS work out side of Cisco as well. I do NOT think there is *ANY* work going on to capture the flows or to define MPLS flows from the point of view of doing something similar to what we do with NetFlow export for instance. I would suggest to consider this for discussion here with some valid reasoning behind our actions besides the fact that we do not feel fully comfortable to handle this aspect or to keep it simple. At best, I can suggest to keep it as an item of discussion some what later in the process rather than dropping it altogether. >> The problem in covering MPLS as just another link layer technology >> is that we will loose capturing the information that is needed to >> complete end-to-end flow definition/capture as part of the charter. > >> Where as IETF has several RFCs and work in progress documents >> covering various aspects of MPLS networks, I do not know of any >> single one of them covering something similar to NetFlow (of Cisco). > >Maybe a NetFlow-like mechanism isn't really necessary for MPLS >networks, because MPLS has its own "natural" ways of grouping traffic >into aggregates, and defines mechanisms to count traffic in those >aggregates that are more convenient to use than the flow-export >schemes that are the topic of this group. I would go with this line of reasoning if MPLS was somewhat of a proprietary thing. Where as MPLS does have a concept of FECs (Forwarding Equivalence Class), to group traffic into "classes", this is still a layer 3 thing, and as such if we ignore this completely, we ignore a very crucial part of (at least some) SP networks. When you report a flow export from such a network, how do we treat the IP traffic flows behavior ?? How does an SP who is trying to charge for an IP flow account this part of his network ? So, I think we need to think thru this. At the very least, we should make a statement about things like this and Layer 2 VPNs to untangle this later in the process if that is what most folks here think, and I would be willing to table this for now. >-- >Simon Leinen simon@babar.switch.ch >SWITCH http://www.switch.ch/misc/leinen/ > > Computers hate being anthropomorphized. ((((((((((((()))))))))))) Kamlesh Shah CCIE # 2803 Technical Marketing Engineer - MPLS, ISBU