Hi Wilfrid,
"we already capture all the flows matching the different rd because
of our netflow setup.". Although i may appreciate if you could elaborate
more on your netflow setup (it makes the exercise less a treasure hunt
for me), I am sure you do: can you paste me the content of one of your
f
Hi Paolo,
Unless I misunderstand the flow_to_rd_map, but this one would not help in
our case.
Indeed we already capture all the flows matching the different rd because
of our netflow setup.
nfacctd already receives only flows from the specific RDs involved in the
monitored L3VPN .
My concern is a
Hi Ionut,
Thanks for getting in touch with this.
From the log file you sent apparently the switch sends element #104
(layer2packetSectionData) to include portion of the sampled frame.
Unfortunately such element has been "deprecated in favor of 315
dataLinkFrameSection. Layer 2 packet section dat
Hi Wilfrid,
This is very possibly point #1 of my previous email. The need for a
flow_to_rd_map to associate flows to the right RD. You can find some
examples here on how to compose it:
https://github.com/pmacct/pmacct/blob/1.7.5/examples/flow_to_rd.map.example
Paolo
On Tue, May 19, 2020 at 0
Hi guys,
I'm struggling a bit to collect netflow-v9 lite from this particular device.
cisco configuration: https://paste.xinu.at/QLW0j/
nfacctd config: https://paste.xinu.at/bnKHc3/
nfacctd -f netflow.conf -d log: https://paste.xinu.at/oaJ/
pmacct -s doesn't have any information, is like nfacctd
Hi Paolo,
Could the issue be that correlation does not work because for each
"ip_prefix" there is not one, but two or three routes collected by pmbgpd
?
Indeed because of redundancies, each prefixes are received by several
different routers in our network and by design each of the routers use
diff
