So what did we decide?

1. That there are likely NetFlow caching bugs that cause SRC and DST to be (yes Kevin, I have indeed seen this, though it's SUPER rare).
2. That PROTO 0 is valid and can be seen when the PROTO in the original
datagram is 0.
3. That MPLS encap non-IP can cause PROTO == 0 but is characterized by other
null fields such as TCP, TOS, and SRC/DST L4 port.

Gotta love this NetFlow stuff at times.

On 9/6/05 5:08 PM, "Mike Hunter" <[EMAIL PROTECTED]> wrote:

> On Sep 05, "Vladimir Kotal" wrote:
>> On Thu, Sep 01, 2005 at 10:03:43AM -0400, Adam Powers wrote:
>>> Proto 0 is actually a valid IP proto number though I've never really seen it
>>> used, especially not in large quantity (It's Hop by Hop IPv6 Option).
>> This holds only for Netflow implementations which support IPv6 pkts, right ?
>> (v9 ?)
>>> Vladimir, can you elaborate on the dropped flow indicator? I'm curious.
>>> Flows that are sent to Null0 or otherwise do not leave the router due to no
>>> valid route will usually have a egress IF set to null and a nexthop of null
>>> but I don't think I've seen Proto set to zero yet.
>> According to one CCIE, generally it holds that
>>   'dropped packet => NULL DstIf'
>> However, the opposite implication is not valid, so this means that nothing
>> can be deduced from NULL DstIf. It could mean process-switching punt,
>> unroutable, no cef or route to Null0. To distinguish between these cases,
>> it is necessary to look into counters like:
>>   sh policy-map int
>>   sh tcam int Vl10 acl in ip
>>   sh int stats
>>   sh ip traffic
>> According to the CCIE, Protocol 0 could be present in Netflow packets only if
>> it was present in original IP packet (so I was wrong in that assumption).
>> Protocol 0 could be also present in MPLS Netflow for MPLS-encapsulated
>> non-IP traffic but in that case also src/dst IP addr, TOS, ports, TCP
>> flags were 0.
> Just to throw more uncertainty and rumor into the mix, I've known 6500s to
> produce netflow PDUs with source and destination ips, presumably
> because of some bug (i.e. I looked hard and didn't see any traffic to or
> from anybody claiming to actually be


Adam  Powers
Director of Technology
Lancope, Inc.
c. 678.725.1028

Flow-tools mailing list

Reply via email to