Hey Alexander,
Can you send me a sample of the IPv6 packets by unicast email? Ideally
two tcpdump captures, ie. 'tcpdump -i lo -n -w <out_file> port <port>'
and 'tcpdump -i <ext interface> -n -w <out_file> port 2101', taken in
parallel. Shall i find you positive on generating a sample, please do
not do one single capture with '-i any' as that would cut out some of
the lower layers data which could be of interest for the analysis.
Paolo
On 28/07/2020 13:07, Alexander Brusilov wrote:
I've tested in latest code 1.7.5-git (20200510-00) with same result.
Some clarification to my previous message
In ipv4 all checksums and lengths in all packets are fine.
About ipv6 bad packet example:
BAD UDP LENGTH 1332 > IP PAYLOAD LENGTH] Len=1324 [ILLEGAL CHECKSUM (0)
Data (1304 bytes)
UDP header: Length: 1332 (bogus, payload length 1312) <<< in my
understanding length should be 1312 (data + 8 bytes)
IPV6 header: Length: 1332 (bogus, payload length 1312) <<< in my
understanding length should be 1372 (data + 8 bytes + 40)
вт, 28 июл. 2020 г. в 12:34, Alexander Brusilov <belya...@gmail.com
<mailto:belya...@gmail.com>>:
Hi all,
i use following scenario in ipv4 and it work fine:
tee plugin listen on external interface and replicate sflow data in
two streams via loopback interface, here is part of configs:
/opt/etc/sf_tee.conf
promisc: false
interface: <ext ifname>
!
sfacctd_port: 2101
sfacctd_ip: <ext ipv4 ip>
!
plugins: tee[sf]
tee_receivers[sf]: /opt/etc/tee_receivers_sf.lst
tee_transparent: true
!
pre_tag_map: /opt/etc/pretag.map
!
/opt/etc/tee_receivers_sf.lst
id=2101 ip=127.0.0.1:2101 <http://127.0.0.1:2101>
id=111 ip=127.0.0.1:20111 <http://127.0.0.1:20111> tag=111
/opt/etc/pretag.map
set_tag=111 ip=<ip>
i am trying do same with ipv6, but with no success, here is configs:
/opt/etc/sf_tee_v6.conf
promisc: false
interface: <ext ifname>
!
sfacctd_port: 2101
sfacctd_ip: <ext ipv6 ip>
!
plugins: tee[sf]
tee_receivers[sf]: /opt/etc/tee_receivers_sf_v6.lst
tee_transparent: true
!
pre_tag_map: /opt/etc/pretag.map
!
/opt/etc/tee_receivers_sf_v6.lst
id=2101 ip=[::1]:2101
id=111 ip=[::1]:20111 tag=111
ipv6 sflow data stream replicated according configs, but
sfacctd backend (and some other software too) ignore this replicated
packets.
I've run tcpdump on external and lo interface and see that packets
on lo interface (replicated by tee plugin) have wrong payload length
in ipv6 header (in udp may be too). In ipv4 all checksums in
all packets fine.
It's normal behaviour or not? Can this cause that sfaccd backend
ignore this packets? Or may be i missing something?
Here example some info of bad packet from wireshark
BAD UDP LENGTH 1332 > IP PAYLOAD LENGTH] Len=1324 [ILLEGAL CHECKSUM (0)
Data (1304 bytes)
UDP: Length: 1332 (bogus, payload length 1312)
IPV6: Length: 1332 (bogus, payload length 1312) <<< in my
understanding length should be 1372
# /opt/sbin/sfacctd -V
sFlow Accounting Daemon, sfacctd 1.7.4-git (20191126-01+c6)
Arguments:
'--prefix=/opt' '--enable-geoipv2' '--enable-jansson'
'--enable-zmq' '--enable-pgsql'
'PKG_CONFIG_PATH=/usr/pgsql-11/lib/pkgconfig' '--enable-l2'
'--enable-64bit' '--enable-traffic-bins' '--enable-bgp-bins'
'--enable-bmp-bins' '--enable-st-bins'
System:
Linux 3.10.0-1127.13.1.el7.x86_64 #1 SMP Tue Jun 23 15:46:38 UTC
2020 x86_64
# cat /etc/redhat-release
CentOS Linux release 7.8.2003 (Core)
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
