Wireshark-users: Re: [Wireshark-users] netflow v9 SRC_AS_PEER and DST_AS_PEER

Date: Fri, 17 Sep 2010 19:38:18 +0900 (JST)
Hello Bill,

Thank you for letting me know the URL. I have recorded it in my memo.

Regards,
-- 
Tomohiko Kurahashi <kura@xxxxxxxxx>


From: wmeier@xxxxxxxxxxx
Date: Tue Sep 14 2010 22:17:19 JST
>
> kura@xxxxxxxxx wrote:
> > Hello,
> > 
> > Currently wireshark decodes netflow v9 type=128 as "SRC_AS_PEER" and
> > type=129 as "DST_AS_PEER". Does anyone know in which RFC or other
> > documents they are defined?
> > 
> > - from packet-netflow.c:
> > |static const value_string v9_template_types[] = {
> > |...
> > |    { 128, "SRC_AS_PEER" },
> > |    { 129, "DST_AS_PEER" },
> > 
> > In RFC5102 (for IPFIX) id=128 is defined as "bgpNextAdjacentAsNumber"
> > and id=129 as "bgpPrevAdjacentAsNumber". I think the former is equal to
> > "DST_AS_PEER" and the latter is equal to "SRC_AS_PEER".
> > 
> > I'd like to know whether this difference is a bug of wireshark or not.
> > 
> > Regards,
> 
> A quick Google for <cisco netflow "source as peer"> shows 24 hits
> including the following:
> 
> http://www.cisco.com/en/US/docs/ios/fnetflow/command/reference/fnf_02.html
> 
> ----------
> <snip>
> Router# show flow exporter export-ids netflow-v9
> 
> Export IDs used by fields in NetFlow-common export format:
> 
> <snip>
> 
>    routing source as                          :    16
> 
>    routing destination as                     :    17
> 
>    routing source as peer                     :   129
> 
>    routing destination as peer                :   128
> 
>    routing source traffic-index               :    92
> 
> <snip>
> ---------
> 
> I'm a newbie with respect to netflow so I don't know if the two messages 
> are the same in v9 and IPFIX (v10) though I expect so. Further Googling 
> may provide an answer.
> 
> That being said: I could imagine displaying the correct name (depending 
> upon the protocol version) if the v9/v10 names are different even if the 
> v9/v10 semantics are the same for a type.
> 
> (I'm currently reworking the netflow dissector to fix various bugs and 
> to improve the protocol dissection/display but haven't been looking at 
> the actual types).