Proto 0 not displaying in ra
Carter Bullard
carter at qosient.com
Wed Jun 26 13:17:30 EDT 2013
Hey Jesse,
The racount() zero protocol is a bug... Understanding how to print protocol numbers from different domains (L2 and L3) at the same time is the challenge?
Carter
Carter Bullard, QoSient, LLC
150 E. 57th Street Suite 12D
New York, New York 10022
+1 212 588-9133 Phone
+1 212 588-9134 Fax
On Jun 25, 2013, at 9:59 PM, Jesse Bowling <jessebowling at gmail.com> wrote:
> I got a chance to go back to this data, and running racount with and " - ip" filter does remove the listing of a protocol 0. Although my post seems to have spurred some discussion in terms of the IANA numbering, I'm curious how I should treat this in terms of argus? Should I accept that anything "proto 0" is in fact something non-IP that argus has used this code for? It looks like arp is broken out as named protocol
>
> Data from the two runs:
>
> # racount -M proto -M addr -r 6-18-13.argus - ip
> racount records total_pkts src_pkts dst_pkts total_bytes src_bytes dst_bytes
> sum 42310429 3498573047 1291460600 2207112447 2990829486929 366790210172 2624039276757
> Protocol Summary
> 1 558725 1547010 1505761 41249 148147003 144938401 3208602
> 2 285 683 683 0 40980 40980 0
> 6 34738307 3217255811 1154399642 2062856169 2819466925049 284311900921 2535155024128
> 17 7007354 279008003 134875703 144132300 170964108974 82107361536 88856747438
> 41 4619 103971 54270 49701 12014753 5172234 6842519
> 47 28 68631 35603 33028 41941733 24487663 17454070
> 50 823 585925 585925 0 196103535 196103535 0
> 103 286 3012 3012 0 204816 204816 0
> 255 1 1 1 0 86 86 0
> Address Summary
> IPv4 Unicast src 318111 dst 399255
> IPv4 Unicast This Network src 1 dst 0
> IPv4 Unicast Private src 918 dst 25645
> IPv4 Unicast Reserved src 391436 dst 412168
> IPv4 Multicast Local src 0 dst 2
>
> # racount -M proto -M addr -r 6-18-13.argus
> racount records total_pkts src_pkts dst_pkts total_bytes src_bytes dst_bytes
> sum 42313038 3498960999 1291848528 2207112471 2990879509318 366840231121 2624039278197
> Protocol Summary
> 1 558725 1547010 1505761 41249 148147003 144938401 3208602
> 2 285 683 683 0 40980 40980 0
> 6 34738307 3217255811 1154399642 2062856169 2819466925049 284311900921 2535155024128
> 17 7007354 279008003 134875703 144132300 170964108974 82107361536 88856747438
> 41 4619 103971 54270 49701 12014753 5172234 6842519
> 47 28 68631 35603 33028 41941733 24487663 17454070
> 50 823 585925 585925 0 196103535 196103535 0
> 103 286 3012 3012 0 204816 204816 0
> 255 1 1 1 0 86 86 0
> 0 1148 6377 6377 0 2710225 2710225 0
> arp 25 49 25 24 2940 1500 1440
> Address Summary
> IPv4 Unicast src 318111 dst 399255
> IPv4 Unicast This Network src 1 dst 0
> IPv4 Unicast Private src 918 dst 25645
> IPv4 Unicast Reserved src 391436 dst 412168
> IPv4 Multicast Local src 0 dst 2
>
> I stripped this down to remove all the known protocols:
>
> # ra -r 6-18-13.argus -w non-ip.argus - 'not (proto 1 or proto 2 or proto 6 or proto 17 or proto 41 or proto 47 or proto 50 or proto 103 or proto 255 or arp)'
>
> and what was left was:
>
> StartTime Flgs Proto SrcAddr Sport Dir DstAddr Dport TotPkts TotBytes State
> 06/18/13 00:00:00.000000 34825 00:18:74:3f:98:00.0 -> 01:80:c2:00:00:02.0 644 79856 INT
> 06/18/13 00:00:00.694927 34825 01:80:c2:00:00:02.0 -> 5c:5e:ab:d8:bb:c1.0 20 2480 INT
> 06/18/13 00:00:08.407125 0 00:14:a9:82:11:d5.170 -> 01:00:0c:cc:cc:cc.170 6 2550 INT
> 06/18/13 00:00:32.103352 0 00:14:a9:82:11:d4.170 -> 01:00:0c:cc:cc:cc.170 5 2125 INT
> 06/18/13 00:00:00.000000 34825 00:17:0f:9d:a8:00.0 -> 01:80:c2:00:00:02.0 646 80104 INT
> 06/18/13 00:00:03.922070 0 00:17:5a:34:44:91.170 -> 01:00:0c:cc:cc:cc.170 6 2550 INT
> 06/18/13 00:00:21.751165 34825 01:80:c2:00:00:02.0 -> 5c:5e:ab:d8:cc:c1.0 20 2480 INT
> 06/18/13 00:00:34.638375 0 00:17:5a:34:44:90.170 -> 01:00:0c:cc:cc:cc.170 6 2550 INT
> 06/18/13 00:05:00.000000 34825 00:18:74:3f:98:00.0 -> 01:80:c2:00:00:02.0 643 79732 INT
> <snip>
>
> At least some of this might be explainable by looking up the OUI's for these MAC addresses:
>
> 00:17:0F CISCO SYSTEMS, INC.
> 5C:5E:AB Juniper Networks
> 01:00:0C:CC:CC:CC CDP/VTP/DTP/PAgP/UDLD
> 01:80:C2:00:00:00 Spanning-tree-(for-bridges)
> 01:80:C2:00:00:02 Slow-Protocols
>
> We definetly have Juniper and Cisco routers in this observation domain, and the other three would seem to make sense here as well. Would it make sense to break these protocols out of 'proto 0' into their own named protocols (similar to 'arp') for argus? Would an extract of this traffic (either argus with 128 bytes of user data) or some pcaps help?
>
> Cheers,
>
> Jesse
>
>
> On Mon, Jun 24, 2013 at 10:57 AM, Carter Bullard <carter at qosient.com> wrote:
>> Hey Jesse, David,
>> The proto 0 should be an argus artifact, an internal protocol
>> number so that we can process L2 and L3 protocol numbers
>> in the same code set, so you shouldn't see that.
>>
>> Zero should be illegal for L2 and L3. We make a distinction
>> between IPv6 options and the next header protocol number.
>>
>> Very curious that IANA doesn't make that distinction. That
>> seems like an error.
>>
>> David is right, with an " - ip " filter, does it go away?
>> Got some data you can share that generates the error, so I
>> can check it out?
>>
>> Carter
> --
> Jesse Bowling
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130626/4e0b086e/attachment.html>
More information about the argus
mailing list