Hi Andy,
Thanks for opening the issue on GitHub and the kind words.
Thing is all you want to achieve is supported in pmacct when working in
collector mode where the proper inspection of each flow is performed.
Why don't you leave the tee part barebone and implement these features
in the collector? Just an idea as a perfectly valid answer could be that
performing this enrichment in the replicator then also 3rd party tools
could benefit from this info. Let me know.
Paolo
On 16/3/24 01:51, Andrew Lake wrote:
Hi Paolo,
Thanks for reply! I have created the issue as requested:
https://github.com/pmacct/pmacct/issues/770
<https://github.com/pmacct/pmacct/issues/770>. Apologies for missing the
docs about tee/replication mode and what you described make sense.
Your comment about the matching RD in the BGP messages I think is
somewhat related to my ultimate goal, which is to enrich the IPFIX
records with the AS Path using the BGP table for the matching VRF.
Balancing this with the fact that our routers have limitations in the
number of addresses to which they will forward IPFIX, my plan was to
have pmacct in tee mode forward the IPFIX records to a pmacct instance
dedicated to peering with only one VRF where it could do the BGP lookup.
Alternative would be to try to lookup up the path by mapping the IPFIX
VRF ID to the BGP RD and then basing the lookup on that value in
addition to the prefix, but this seems like non-hanging fruit as you
said. if you are able to get the VRF ID matching against IPFIX working
so we can tee it from there, that will be fantastic.
Thanks again for all your help…and also just in general building an
awesome product :)
Andy
On March 15, 2024 at 2:18:01 AM, Paolo Lucente (pa...@pmacct.net
<mailto:pa...@pmacct.net>) wrote:
Hi Andy,
mpls_vpn_rd is supported in pre_tag_map however it is not supported when
in tee / replication mode (this is documented).
For your specific use-case, since you are interested in matching the VRF
ID, which in turn is self-consistent as part of an IPFIX record, this is
something that can be achieved. However this may then open the door to
somebody wanting to match the RD for a prefix as coming from a BGP / BMP
feed, and for this a few (non-hanging-fruit) steps would be needed; then
again the limitation to the self-contained VRF ID scenario can be
documented.
May i ask you to open an Issue on GitHub? I'll flag it as Enhancement
right away and will be able to make progress pretty soon for the VRF ID
case.
Paolo
On 13/3/24 03:11, Andrew Lake wrote:
> Hi,
>
> I recently tried creating a setup where I have an instance of nfacctd
> running that has a pretag.map that I want to look at the value of
> mpls_vpn_rd as determined from the IPFIX record and then set a tag. The
> plan is to then use the tee plugin to send the IPFIX traffic to a
> different nfacctd instance based on the tag set. I can get more into why
> we’re doing this if interested, but I ran into a snag that I can’t seem
> to figure out on my own. nfacctd doesn’t seems to like when I add
> mpls_vpn_rd to the pretag.map. I get messages like:
>
> [/etc/pmacct/pretag.map:3] unknown key 'mpls_vpn_rd'. Ignored.
>
> The pretag.map is pretty vanilla. Just lines like:
>
> set_tag=1 mpls_vpn_rd=<VRFID>
>
> My nfacctd.conf:
>
> ! Port where nfacctd listens
> nfacctd_port: 9996
>
> ! Adds debugging output to logs. Disable in production.
> debug: true
>
> ! tag flow values to determine where tee sends them next
> pre_tag_map: /etc/pmacct/pretag.map
>
> plugins: tee
> tee_receivers: /etc/pmacct/tee_receivers.lst
> tee_transparent: true
>
>
>
> I went so far as to copy the exact mpls_vpn_rd line from the example in
> the git repo just to see if it would accept it and it still complained.
> From looking at the documentation looks like mpls_vpn_rd should be
> allowed in nfacctd (I think?). I tried following the code path in the
> source but was having trouble telling which “Ignored” message was
> getting triggered, and figured maybe I was better off just asking before
> I got too far down the rabbit hole.
>
> Is a pretag.map with mpls_vpn_rd supported by nfacctd? If yes, any ideas
> where to look next? Or any other info I should send?
>
> Thanks,
> Andy
>
>
>
>
> _______________________________________________
> pmacct-discussion mailing list
> http://www.pmacct.net/#mailinglists <http://www.pmacct.net/#mailinglists>
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists