Re: [pmacct-discussion] BGP-related fields do not show up in the memory table
Hi, To conclude this thread: - The association of flow records to BGP RIB via the map works just fine. As Paolo discovered, the cause of the problem I reported was a typo :( - Regarding AS 0 I haven't tried yet any solution or workaround to have our own ASN appear in pmacct tables instead. If necessary I will start a new thread about this in due time. - The unknown template warnings are probably related to netflow v9 sampling options and should be fixed with v9 sampling support in pmacct 0.12.0 RC3. Thanks again, Z. ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] BGP-related fields do not show up in the memory table
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=:::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
Re: [pmacct-discussion] BGP-related fields do not show up in the memory table
Hi Zenon, Thanks very much for your feedback first of all; please follow my replies in-line. On Fri, Oct 23, 2009 at 02:23:34AM +0300, Zenon Mousmoulas wrote: 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? 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=:::x.x.x.10 * 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. Let me know on this. 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 * 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. - 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. Very open to feedback, privately or here on list, on this matter. 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? Cheers, Paolo ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] BGP-related fields do not show up in the memory table
Hi Zenon, 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 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. Cheers, Paolo ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
