Traffic flow bug

rucevzhuru · May 2, 2009, 3:57pm

I tried several linux flows capturers and none of them worked with Mikrotik Traffic flows.

Router: ROS 3.10 (IP 192.168.6.1)
Server: Debian squeeze (connected to router via ethernet cable)

Both PC’s have almost unused cpu power.

Software: flowd, pmacct, flow-tools.

For example log from flow-tools:

May  2 17:47:29 ali flow-capture[4393]: ftpdu_seq_check(): src_ip=192.168.6.1 dst_ip=192.168.6.2 d_version=5 expecting=13785 received=13873 lost=88
May  2 17:47:29 ali flow-capture[4393]: ftpdu_seq_check(): src_ip=192.168.6.1 dst_ip=192.168.6.2 d_version=5 expecting=13903 received=13873 lost=4294967265
May  2 17:47:29 ali flow-capture[4393]: ftpdu_seq_check(): src_ip=192.168.6.1 dst_ip=192.168.6.2 d_version=5 expecting=13903 received=13873 lost=4294967265
May  2 17:47:29 ali flow-capture[4393]: ftpdu_seq_check(): src_ip=192.168.6.1 dst_ip=192.168.6.2 d_version=5 expecting=13903 received=13873 lost=4294967265
May  2 17:47:29 ali flow-capture[4393]: ftpdu_seq_check(): src_ip=192.168.6.1 dst_ip=192.168.6.2 d_version=5 expecting=13903 received=13873 lost=4294967265
May  2 17:47:29 ali flow-capture[4393]: ftpdu_verify(): src_ip=192.168.6.1 failed.
May  2 17:47:29 ali flow-capture[4393]: ftpdu_verify(): src_ip=192.168.6.1 failed.
May  2 17:47:29 ali flow-capture[4393]: ftpdu_verify(): src_ip=192.168.6.1 failed.
May  2 17:47:29 ali flow-capture[4393]: ftpdu_verify(): src_ip=192.168.6.1 failed.
May  2 17:47:29 ali flow-capture[4393]: ftpdu_verify(): src_ip=192.168.6.1 failed.
May  2 17:47:29 ali flow-capture[4393]: ftpdu_verify(): src_ip=192.168.6.1 failed.

I saw several similar bugs in the forum and there aren’t answers. Have somebody seen similar behaviour?
Thanks

JJCinAZ · May 4, 2009, 4:10pm

I’ve never had those issues with NTOP (http://www.ntop.org/overview.html) or commercial tools from IPSwitch and others. I can’t vouch for flowd, pmacct, flow-tools, etc.

changeip · May 4, 2009, 4:48pm

i used 2.9.x versions with flowd, never tried 3.x…

rucevzhuru · May 8, 2009, 7:24pm

Ntop seems to work with flows version 5 but there are some errors with version 9

Pá 8. květen 2009, 21:20:45 CEST  **WARNING** Template len mismatch [tot_len=1230][flow_len=1234]
Pá 8. květen 2009, 21:20:45 CEST  **WARNING** Template len mismatch [tot_len=1148][flow_len=1152]
Pá 8. květen 2009, 21:20:47 CEST  **WARNING** Template len mismatch [tot_len=1230][flow_len=1234]
Pá 8. květen 2009, 21:20:47 CEST  **WARNING** Template len mismatch [tot_len=1230][flow_len=1234]
Pá 8. květen 2009, 21:20:47 CEST  **WARNING** Template len mismatch [tot_len=1230][flow_len=1234]
Pá 8. květen 2009, 21:20:47 CEST  **WARNING** Template len mismatch [tot_len=820][flow_len=824]
Pá 8. květen 2009, 21:20:49 CEST  **WARNING** Template len mismatch [tot_len=1230][flow_len=1234]
Pá 8. květen 2009, 21:20:49 CEST  **WARNING** Template len mismatch [tot_len=1230][flow_len=1234]
Pá 8. květen 2009, 21:20:49 CEST  **WARNING** Template len mismatch [tot_len=1230][flow_len=1234]
Pá 8. květen 2009, 21:20:49 CEST  **WARNING** Template len mismatch [tot_len=410][flow_len=414]
Pá 8. květen 2009, 21:20:51 CEST  **WARNING** Template len mismatch [tot_len=1230][flow_len=1234]
Pá 8. květen 2009, 21:20:51 CEST  **WARNING** Template len mismatch [tot_len=1230][flow_len=1234]
Pá 8. květen 2009, 21:20:51 CEST  **WARNING** Template len mismatch [tot_len=1230][flow_len=1234]
Pá 8. květen 2009, 21:20:51 CEST  **WARNING** Template len mismatch [tot_len=1230][flow_len=1234]
Pá 8. květen 2009, 21:20:51 CEST  **WARNING** Template len mismatch [tot_len=369][flow_len=373]

We have some routers with 2.9.x and i can confirm that 2.9.x works perfectly but 3.x doesnt.

changeip · May 8, 2009, 8:29pm

please email support and work with them to fix it. It looks like all those packets are 4 bytes too big.

Chupaka · May 9, 2009, 2:35pm

why do you need v9?

rucevzhuru · May 15, 2009, 10:59pm

I thought there are more informations within ipflows v9 but there aren’t so you are right, v5 is enough for me.

savage · October 7, 2009, 1:16pm

various 3.30 systems on x86, mibsbe as well as mibsbe… Problem is persisting…

flow-capture: ftpdu_seq_check(): src_ip=192.168.1.1 dst_ip=192.168.1.253 d_version=5 expecting=556786 received=556756 lost=4294967265
flow-capture: ftpdu_seq_check(): src_ip=192.168.1.1 dst_ip=192.168.1.253 d_version=5 expecting=556764 received=556806 lost=42
flow-capture: ftpdu_seq_check(): src_ip=192.168.1.1 dst_ip=192.168.1.253 d_version=5 expecting=556836 received=556806 lost=4294967265
flow-capture: ftpdu_seq_check(): src_ip=192.168.1.1 dst_ip=192.168.1.253 d_version=5 expecting=556807 received=556851 lost=44
flow-capture: ftpdu_seq_check(): src_ip=192.168.1.1 dst_ip=192.168.1.253 d_version=5 expecting=556881 received=556851 lost=4294967265
flow-capture: ftpdu_seq_check(): src_ip=192.168.1.1 dst_ip=192.168.1.253 d_version=5 expecting=556860 received=556892 lost=32

Chupaka · October 7, 2009, 1:40pm

btw, ‘[Ticket#2009070666000202]’

still no answer…

savage · December 9, 2009, 7:46am

At v4.3 now - STILL not fixed…

savage · December 9, 2009, 8:19am

The below patch to flow-tools will at least stop it filling my logs with useless errors due to MT netflow exports. It’s hardly a fix to the problem and I’m pretty sure the issue is on the MT, but this stops the errors in the logs being generated by flow-tools. Use it, abuse it, do with it as you please.

--- src/flow-capture.c.orig 2009-12-09 10:10:29.000000000 +0200
+++ src/flow-capture.c      2009-12-09 10:10:58.000000000 +0200
@@ -960,12 +960,14 @@
         fmt_ipv4(fmt_src_ip, ftch_recexp.src_ip, FMT_JUST_LEFT);
         fmt_ipv4(fmt_dst_ip, ftch_recexp.dst_ip, FMT_JUST_LEFT);
         fmt_uint16(fmt_dst_port, ftch_recexp.dst_port, FMT_JUST_LEFT);
+/*
         fterr_warnx(
           "ftpdu_seq_check(): src_ip=%s dst_ip=%s d_version=%d expecting=%lu received=%lu lost=%lu",
           fmt_src_ip, fmt_dst_ip, (int)ftpdu.ftv.d_version,
           (u_long)ftch_recexpp->ftseq.seq_exp,
           (u_long)ftch_recexpp->ftseq.seq_rcv,
           (u_long)ftch_recexpp->ftseq.seq_lost);
+ */

         /* only count these lost if "lost" is a reasonable number */
         if (ftch_recexpp->ftseq.seq_lost < FT_SEQ_RESET) {

EDIT: And as per the code, the error is being generated due to flow-tools receiving the netflows ‘out of sequence’. It will only receive them out of sequence because MT is sending them out of sequence…

changeip · December 9, 2009, 5:36pm

regarding out of sequence - do you have ANY QoS rules in place anywhere between the sending router and the flow receiver?

Chupaka · December 9, 2009, 6:18pm

changeip, it’s not QoS, it’s just a bug: about every two seconds ‘flush’ of NF info happens, and for every such flush all NF packets have the same sequence_id - sequence_id that firsh packet should have. you can see it even in posts above

rucevzhuru · January 23, 2010, 4:00am

Where can I see these tickets? i can’t find anything on the mikrotik web.

Chupaka · January 23, 2010, 11:18am

it’s internal MT system, you cannot see it

rucevzhuru · January 23, 2010, 4:28pm

Thanks for the reply. Any possibility to see it? Why is it not public? Or at least possible to login for registered owners of license.

Chupaka · January 23, 2010, 6:31pm

it’s available only for Support team of MikroTik =) any ticket number mentioning on the forum is only for MT staff

gjallen · March 26, 2010, 3:32am

I am trying to implement netflows. V1 has no erors V5 has the exact erros in this post.

Is this still a bug in V3.30? Has it been fixed in 4.4?

Jerry

savage · March 26, 2010, 6:21am

Not fixed in latest 4.6, nevermind 4.5…

Chupaka · March 26, 2010, 9:26am

still not ‘fixed’… developer is pretty sure that all is working correctly

there’s no RFC about NF v5, so I have nothing to say against that

if anybody can collect exports from MT and correct ones from Cisco - please send them to support =)