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).
