IPv6 addresses jumbled in flow accounting
Open, NormalPublicBUG
Actions

Assigned To

None

Authored By

	AP
	Dec 31 2023, 5:49 PM

Description

We're running VyOS 1.3.5 with the following flow-accounting configuration:

# show system flow-accounting
 enable-egress
 interface eth0.20
 interface eth0.30
 interface eth0.99
 netflow {
     engine-id 1
     server 172.19.24.55 {
         port 9995
     }
     version 9
 }

This router is configured with IPv6 blocks 2602:fcad:1::/48 and 2602:fcad:2::/48 (which are broken up into a few /64s).

When checking the memory table, it seems the IPv6 addresses are "jumbled" (for lack of a better word to describe it :slight_smile: ). It seems the IPv4 addresses are correct.

$ show flow-accounting interface eth0.99
IN_IFACE    SRC_MAC            DST_MAC            SRC_IP                            DST_IP                          SRC_PORT    DST_PORT  PROTOCOL                 TOS    PACKETS    FLOWS    BYTES
----------  -----------------  -----------------  --------------------------------  ----------------------------  ----------  ----------  ---------------------  -----  ---------  -------  -------
...
eth0.99     52:54:00:9e:c9:58  52:54:00:47:a8:7f  63.6.136.116                      172.19.24.50                           0           0  78                         0          1        1       52
eth0.99     52:54:00:9e:c9:58  52:54:00:47:a8:7f  14d:63f:2602:fcad:2:fffe:5054:ff  fe9e:c958:2602:fcad:1::                0           0  L                          0          2        1    49262
eth0.99     52:54:00:9e:c9:58  52:54:00:47:a8:7f  20:640:2602:fcad:2:fffe:5054:ff   fe9e:c958:2602:fcad:1::                0           0  L                          0          9        1   221679
eth0.99     24:5a:4c:86:d4:35  52:54:00:47:a8:7f  63.6.178.195                      172.19.24.108                          0           0  ^N B^N^XB^N^PB^N^HA ...

Notice the DST_IP and SRC_IP seem to be the right length of 8 sections, but our prefix starts in the 3rd section.

We tried rolling back to 1.3.2 as we thought it was working in that version, but are running into the same issue.

Thanks,
AP

Details

Version: 1.3.5
Is it a breaking change?: Unspecified (possibly destroys the router)
Issue type: Bug (incorrect behavior)

Event Timeline

AP created this task.Dec 31 2023, 5:49 PM

You mean that for SRC_IP you expect it to be "2602:fcad:2:fffe:5054:ff" and not "14d:63f:2602:fcad:2:fffe:5054:ff" ?

pasik subscribed.Dec 31 2023, 11:39 PM

No -- I don't believe that's a valid IPv6 address. We just ran some iperf3 tests between two servers on our network 2602:fcad:1::12 <-> 2602:fcad:1:ffff::ffff. Here's what showed up in nfdump (our Netflow collector). I'm not seeing an obvious pattern on how the addresses are being mangled.

** nfdump -M /opt/nfsen/profiles-data/live/core1  -T  -R 2023/12/31/nfcapd.202312312120:2023/12/31/nfcapd.202312312140 -n 10 -s record/bytes -B -6
nfdump filter:
any
Command line switch -s overwrites -a

Aggregated flows 994799
Top 10 flows ordered by bytes:
Date first seen          Duration Proto                             Src IP Addr:Port                                  Dst IP Addr:Port   Out Pkt   In Pkt Out Byte  In Byte Flows
2023-12-31 21:35:14.109    10.003 182                      20:640:2602:fcad:1::.0     <->                 0:12:2602:fcad:1:ffff::.0            0   215737        0    5.3 G     1
2023-12-31 21:24:55.684    10.004 170                 20:63f:2602:fcad:1:ffff::.0     <->                    0:ffff:2602:fcad:1::.0            0   203440        0    5.0 G     1
2023-12-31 21:24:44.299    10.002 GGP                 20:63f:2602:fcad:1:ffff::.0     <->                    0:ffff:2602:fcad:1::.0            0   193461        0    4.8 G     1
2023-12-31 21:35:01.973    10.002 AX.25               20:63f:2602:fcad:1:ffff::.0     <->                    0:ffff:2602:fcad:1::.0            0   185360        0    4.6 G     1
2023-12-31 21:35:17.239     6.872 VINES             fb24:63f:2602:fcad:1:ffff::.0     <->                    0:ffff:2602:fcad:1::.0            0   120754        0    3.0 G     1
2023-12-31 21:24:44.301     9.999 MFESP                  fb24:640:2602:fcad:1::.0     <->                 0:12:2602:fcad:1:ffff::.0            0    50639        0    1.2 G     1
2023-12-31 21:24:55.687     9.998 227                    fb24:640:2602:fcad:1::.0     <->                 0:12:2602:fcad:1:ffff::.0            0    50546        0    1.2 G     1
2023-12-31 21:35:14.111     2.918 163               fb24:63f:2602:fcad:1:ffff::.0     <->                    0:ffff:2602:fcad:1::.0            0    49701        0    1.2 G     1
2023-12-31 21:35:01.977     9.997 163                    fb24:640:2602:fcad:1::.0     <->                 0:12:2602:fcad:1:ffff::.0            0    45849        0    1.1 G     1
2023-12-31 21:35:02.111     9.845 AX.25               2c:63f:2602:fcad:1:ffff::.0     <->                    0:ffff:2602:fcad:1::.0            0    24200        0  595.8 M     1
Summary: total flows: 2085674, total bytes: 68.8 G, total packets: 5.0 M, avg bps: 94.3 M, avg pps: 848, avg bpp: 13894
Time window: 2023-12-31 20:07:42 - 2023-12-31 21:44:59
Total flows processed: 2085674, Blocks skipped: 0, Bytes read: 141046980
Sys: 0.560s flows/second: 3722297.5  Wall: 0.557s flows/second: 3739053.6

Hmm, I also just realized the SRC_PORT and DST_PORT are 0 in both the IPv4 and IPv6 flows (also seen in the first example).

Yes but "2602:fcad:2:fffe:5054:ff" is a valid host in your case?

Sorry maybe I’m not understanding you. The address you’ve highlighted isn’t valid in any case (it only has 6 segments). At the very best it should look like 2602:fcad:2:fffe:5054:ff:XXXX:XXXX (with eight segments). 2602:fcad:2:fffe::/64 is a valid prefix on our network, but there would need to be another 4 segments at the end for SLAAC assigned addresses (which is how that particular address is being assigned). I’d need to look deeper into what the correct address should be, which is why we provided the iperf3 example given the shorter / defined host addresses (with the hope that someone else smarter than me might see the pattern of how the addresses are being mangled). Thanks.

Viacheslav triaged this task as Normal priority.Jan 20 2024, 2:06 PM

bweeks subscribed.Feb 2 2024, 7:03 AM

I can reproduce this on VyOS 1.4.0-rc3. It also appears that IPv6 addresses are only garbled on subinterfaces.

syncer edited projects, added VyOS 1.3 Equuleus (1.3.7), VyOS 1.4 Sagitta (1.4.0-epa1); removed VyOS 1.3 Equuleus.Feb 15 2024, 2:18 PM

syncer edited projects, added VyOS 1.3 Equuleus (1.3.8); removed VyOS 1.3 Equuleus (1.3.7).May 13 2024, 7:31 PM

syncer edited projects, added VyOS 1.4 Sagitta (1.4.0-GA); removed VyOS 1.4 Sagitta (1.4.0-epa1).May 15 2024, 9:30 AM

dmbaturin edited projects, added VyOS 1.3 Equuleus (1.3.9); removed VyOS 1.3 Equuleus (1.3.8).Jun 20 2024, 10:18 AM

dmbaturin edited projects, added VyOS 1.4 Sagitta (1.4.1); removed VyOS 1.3 Equuleus (1.3.9), VyOS 1.4 Sagitta (1.4.0-GA).Jul 2 2024, 7:29 PM

dmbaturin added a project: Bugs.Sep 15 2024, 5:03 PM

syncer edited projects, added VyOS Rolling; removed VyOS 1.4 Sagitta (1.4.1).Oct 30 2024, 9:36 PM

syncer moved this task from Need Triage to Backlog - Bug on the VyOS Rolling board.

syncer added a subscriber: Global Notifications.Nov 1 2024, 9:19 PM