Hi Paolo,
thanks for your replies. My answers/comments follow in-line:
> I am exporting netflow v9 (non-aggregated, for the time being) from
> a Cisco router (12000/PRP with 12.0S) to nfacctd (0.12.0rc2). I have
Can i ask you which 12.0S IOS version the C12k is running precisely?
12.0(33)S2
> However, I can not see this information in the memory table, for
> example:
Your configuration, bgp_agent_map and overall setup appears correct.
I've double-checked by reproducing the scenario on a testbed before
replying. I find two possible explanations on what's happening:
* if you compiled the package with support for IPv6 (--enable-ipv6)
- doesn't appear so, but better ask - the bgp_agent_map should be
rewritten as:
id=x.x.x.7 ip=::ffff:x.x.x.10
I did compile with --enable-ipv6. However I remember reading somewhere
(I think it was in the list archives) it would also suffice to specify
the ipv4 address to bind to, both for netflow and bgp, as I did in the
configuration I sent earlier. Anyway, I tried it with the syntax above
but nothing changed.
* the BGP Router-ID is set as x.x.x.7 but effectively BGP session is
established by using a different IP address, ie. you didn't impose
the "neighbor ... update-source <interface>" or you did but the
interface has multiple IP addresses assigned and another one is
picked.
The neighbor is a juniper router where "local-address 195.251.27.7" is
configured for the peering with nfacctd. You can also see this address
in the bgp debug messages I sent previously and I also confirmed this
earlier with a packet capture.
> Also, in the table above, AS 0 should be the exporting router's own
> AS (5408) but it isn't, probably because the corresponding prefixes
> are known via the IGP. Is it possible to translate with pre_tag_map?
> Any other ideas?
> I am reluctant to use 'nfacctd_as_new: bgp' RIB lookups since we
> probably have this information already (exporter is setup for
> origin-as).
I see two possible cases for the "AS 0", IHMO one more likely the
other slightly less:
* It could be static or connected routes redistributed in BGP; in
such a case you can use communities to assign a "fictious" ASN
to people on your own IP address space (see section XIc of the
EXAMPLES document, the bgp_stdcomm_pattern_to_asn entry in the
CONFIG-KEYS document and pages 19-20 of the following presentation:
http://www.pmacct.net/lucente_pmacct_uknof14.pdf
We are using communities to signal various things. We also have a
complex assortment of automation tools to manage route-map
configuration including prefix lists, communities etc. Therefore I
really don't want to mess with this for now, unless I absolutely have
to.
So, for the time being, I am rather looking for a "workaround" at the
collector, since I don't think I can influence how the exporter
decides what AS to put in there (I remember it has always been like
this on these Cisco routers).
* It could be, as you said, a prefix lying in the IGP; in such a
case you have two options:
- as you said, pre_tag_map. Note rc3, which will hopefully be out
very soon (by end of the month), will include a "tag2" field (ie.
a second field dedicated to tagging) - very useful when building
traffic matrices.
I still don't quite understand how pre_tag_map can be used to replace
the contents of a key such as src_as or dst_as. Can you point me to an
example showing just that? Also looking forward to learning more about
tag2 in the next release.
- You might re-distribute these routes in BGP; network-wise it
will cost slightly more memory (you shouldn't have that many
routes in the IGP, do you? Would expect in the order of a few
thousands if not less) while from a pure routing perspective,
the IGP will always win due to the higher protocol preference.
Having the prefixes in BGP will enable you to get back to the
previous case and use the bgp_stdcomm_pattern_to_asn feature.
The aggregates of these prefixes are redistributed in BGP, but see the
previous argument against using communities (for now).
Very open to feedback, privately or here on list, on this matter.
Thanks, so far I see no problem discussing it openly.
> Finally I should note that I am seeing some occasional warnings in
> the debug log of nfacctd about unknown templates:
>
> DEBUG ( default/core ): Discarded NetFlow V9 packet (R: unknown
> template 257 [195.251.27.10:259])
>
> The exporter is supposed to be resending the template every 20
> packets (the default); I did a packet capture and it looks like it
> is regularly doing so.
Would you mind sending me privately a brief capture of the template
and possibly a few NetFlow packets containing flowsets that match
such template?
OK, will do next.
One additional point to my previous reply.
On Fri, Oct 23, 2009 at 02:23:34AM +0300, Zenon Mousmoulas wrote:
I am reluctant to use 'nfacctd_as_new: bgp' RIB lookups since we
probably have this information already (exporter is setup for
origin-as).
Very true. And it depends on your goals whether that is sufficient
or not. An important piece of information, for peering purposes for
example, is correlating peer-as and origin-as. Getting ASN info
Indeed, this is roughly one of our goals.
straight from BGP enables you to do that. Perhaps also add BGP
next-hop if peering with the same people at multiple places or
for a bit of traffic engineering - granted that the network is
is running MPLS; but because you run NetFlow v9, you should be
able to get BGP next-hop from there aswell.
I want to implement bgp_peer_src_as_map, but I am wondering if it will
work using only bgp_nexthop as a key. Nfacctd sees the actual next hop
in the BGP RIB, but we normally set "next-hop self" in ibgp. Assuming
that we always count flows on the ingress and at the edge of the
network, this router may not have the actual BGP next-hop in order to
export it in the netflow record.
I have left it out for now, but will be looking into it next, after I
get the BGP RIB to work.
Thank you very much for all the help!
Best regards,
Z.
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
