This has been discussed before elsewhere so I don't want to belabor the
point (http://ipfix.doit.wisc.edu/archive/1078.html) but the router itself
has no way of knowing what the port is as the L4 port number was in a
previous packet. Since the IP ID field is not tracked in a v5 Netflow
record, the router has no way of matching a fragmented packet up with the
appropriate flow. The router has no alternative but to create a new flow
entry with a "null" port number. Since the fragmented packet does have the
"next protocol" field set, the new "frag flow" does have the "protocol"
field set to TCP but there is no port field. This results in a "port 0"
flow.
But you don't have to trust me, here's a more concrete example...
Run a packet capture to find actual fragmented packets:
[EMAIL PROTECTED] tcpdump -i eth0 -n "ip[6] & 0x1f != 0"
07:21:25.398704 1.1.16.228 > 2.2.44.114: udp (frag 30051:[EMAIL PROTECTED])
07:21:25.492367 1.1.16.228 > 2.2.44.114: udp (frag 30058:[EMAIL PROTECTED])
07:21:25.695525 1.1.16.228 > 2.2.44.114: udp (frag 30071:[EMAIL PROTECTED])
07:21:25.992371 1.1.16.228 > 2.2.44.114: udp (frag 30088:[EMAIL PROTECTED])
07:21:26.492375 1.1.16.228 > 2.2.44.114: udp (frag 30122:[EMAIL PROTECTED])
07:21:26.929876 1.1.16.228 > 2.2.44.114: udp (frag 30156:[EMAIL PROTECTED])
07:21:27.226781 1.1.16.228 > 2.2.44.114: udp (frag 30174:[EMAIL PROTECTED])
Then check the resulting flows:
[EMAIL PROTECTED] flow-cat ft-v05.2005-02-03.072100-0500 | ../bin/flow-print -f
5 | awk '{if(($5==0 && $8==0 && $9==17)) print $0}' | grep "1.1.16.228"
0203.07:21:26.938 0203.07:21:36.032 1 1.1.16.228 0 255
2.2.44.114 0 17 0 7 4227
Without formatting the above is hard to read, so I'll clean it up...
startime srcip srcp dstip dstp pro pkts
07:21:26.938 1.1.16.228 0 2.2.44.114 0 17 7
So we clearly see that fragmented UDP datagrams are causing port 0 flows.
This is painful for many NetFlow technologies as it forces the technology to
"guess". Such is the nature of IP. :(
On 2/2/05 10:12 PM, "jing shen" <[EMAIL PROTECTED]> wrote:
> Hi Adam��
>
>
>
>
>> BTW: Here's an example frag causing port 0...
>
>> startime srcip srcp dstip dstp pro pkts
>> 17:01:18.307 1.1.69.40 0 2.2.16.61 0 6 4
>> 17:01:18.187 1.1.69.40 2969 2.2.16.61 25 6 18
>> 17:01:18.188 2.2.16.61 25 1.1.69.40 2969 6 18
>
>> This is an SMTP flow that started a new flow at t.187 then a second frag
>> flow at t.307.
>
>> .40 was the client so I would suspect that a large email was sent caused the
>> need for larger packets and ultimately the need for fragmentation.
>
> To my understanding the above record just shows there is something
> wrong with traffic between 1.1.69.40 & 2.2.16.61. If the router
> fragments packets fill port number with 0, this breaks the IP packet
> forwarding requirement. If client host send packet with port 0, this
> should means its OS has something buggy, as port 0 is reserved.
>
>
>
>> Look through your flow logs with something like:
>> flow-cat ft* | flow-print -f 5 | awk '{if(($5==0 && $8==0 && $9==6)) print
>> $0}'
>> Any output you get should be a fragged TCP packet else an actual TCP flow on
>> port 0 (which can happen, it's just rare).
>
>
>
>
>
>> On 2/2/05 12:21 PM, "Dustin" <[EMAIL PROTECTED]> wrote:
>
>>> Hello,
>>>
>>> This may have been discussed, but I don't find any results in the archives.
>>>
>>> We are troubleshooting some performance issues, have Cisco routers, and just
>>> started using flow-tools to capture data. I've issued flowstat with the
>>> following args:
>>>
>>> flow-stat -f5 -p -S2
>>>
>>> # port flows octets packets
>>> #
>>> 0 425 68968722 51238
>>> 445 10886 51125320 372789
>>> 1494 710 26667144 524757
>>> 31889 1800 21081243 50199
>>> 3905 101 20985596 19102
>>>
>>> As you can see, most of the traffic is generated with lower number of
>>> sessions
>>> & packets, but w/ higher amount of data. We would like to know exactly what
>>> this traffic is, why is the majority of traffic lumped into "port 0"?
>>>
>>> TIA,
>>>
>>> Dustin
>>>
>>>
>>> _______________________________________________
>>> Flow-tools mailing list
>>> [EMAIL PROTECTED]
>>> http://mailman.splintered.net/mailman/listinfo/flow-tools
>
>
>
>
--
Adam Powers
Senior Security Engineer
Advanced Technology Group
c. 678.725.1028
o. 770.225.6521
f. 770.225.6501
e. [EMAIL PROTECTED]
AOL IM: adampowers22
StealthWatch by Lancope - Security through network intelligence�
_______________________________________________
Flow-tools mailing list
[EMAIL PROTECTED]
http://mailman.splintered.net/mailman/listinfo/flow-tools
