sflow fails to identify pppoe0 interface
Open, NormalPublicBUG
Actions

Assigned To

None

Authored By

	frebib
	Oct 3 2024, 7:04 PM

Description

I have a configuration that is ppp over vlan over bond over a physical ethernet device:

eth2 -> bond0 -> bond0.10 -> pppoe0

As I discovered, sflow only works when you attach it to the physical interfaces (not sure I understand/want to know why, but that's the only way I can get it to find any packets).
In doing so though, the collector I'm using complains that either the input or output interface is 0 in the sflow data, which I confirmed with tcpdump (they actually show as 0x3fffffff which is equivalent to 0 https://github.com/akvorado/akvorado/blob/7285c115b1a73c80c6cce6e0cdb718cc3a4e28f9/inlet/flow/decoder/sflow/root.go#L21)

Running hsflowd with -ddd also tells me the same thing:

mod_pcap:macsrc=1E43BED99C90, macdst=FEAA9ADDF555
mod_pcap:srcdev=bond0.40(10)(peer=0)
takeSample: hook=0 tap=eth2 in=bond0.40 out=<not found> pkt_len=76 cap_len=76 mac_len=14 (1E43BED99C90 -> FEAA9ADDF555 et=0x8100)
dbg2:selected sampler eth2 ifIndex=4
mod_pcap:macsrc=FEAA9ADDF555, macdst=1E43BED99C90
mod_pcap:dstdev=bond0.40(10)(peer=0)
takeSample: hook=0 tap=eth2 in=<not found> out=bond0.40 pkt_len=163 cap_len=114 mac_len=14 (FEAA9ADDF555 -> 1E43BED99C90 et=0x8100)

Above, and in all cases, the <not found> interface is the pppoe0 interface. Traffic transits from some device in my network, through some vlans, routed by Vyos, then out of the PPP interface to the ISP. Sometimes it's the same thing in reverse

In case it's relevant, the configuration is very simple

frebib@zeus# show system sflow
 agent-address $localip
 agent-interface lo
 interface eth2
 polling 5
 sampling-rate 100
 server $sflowserverip {
     port 6343
 }

Not sure what is wrong or why this is not working. Maybe I'm just misunderstanding. Maybe this is an hsflowd bug. Any help/guidance is welcome

Details

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

Event Timeline

frebib created this task.Oct 3 2024, 7:04 PM

frebib updated the task description. (Show Details)Oct 3 2024, 7:06 PM

frebib updated the task description. (Show Details)

pasik subscribed.Oct 3 2024, 7:39 PM

Can you open the issue here https://github.com/sflow/host-sflow ?
Only they can answer you if it works for PPP at all or not

I think the PPP interface will be recognized if hsflowd knows the MAC address (FEAA9ADDF555) belongs to it. That MAC address is supposed to be learned when the interfaces are read here:

https://github.com/sflow/host-sflow/blob/4dee8ad69baa3a55dc89fa185eb9c54eb5d0ee6c/src/Linux/readInterfaces.c#L778-L789

So if you look earlier in your "hsflowd -ddd" output (or stop it in gdb) you should be able to see what happened. Let me know if we should learn MAC addresses differently for PPP interfaces.

To follow up, however, please do raise the issue in the host-sflow project as Viacheslav suggests. (I am not confident that I will be notified if you reply here.)

vyosbot added a project: Bugs.Oct 14 2024, 8:16 AM

Looks like Linux doesn't provide the PPPoE interface MAC via SIOCGIFHWADDR :(

ioctl(7, SIOCGIFFLAGS, {ifr_name="pppoe0", ifr_flags=IFF_UP|IFF_POINTOPOINT|IFF_RUNNING|IFF_NOARP|IFF_MULTICAST}) = 0
ioctl(7, SIOCGIFHWADDR, {ifr_name="pppoe0", ifr_hwaddr={sa_family=ARPHRD_PPP, sa_data=00:00:00:00:00:00:00:00:00:00:00:00:00:00}}) = 0
ioctl(7, SIOCGIFINDEX, {ifr_name="pppoe0", ifr_ifindex=13}) = 0
ioctl(7, SIOCGIFADDR, {ifr_name="pppoe0", ifr_addr={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("??.??.??.??")}}) = 0
ioctl(7, SIOCETHTOOL, 0x7ffedafde390)   = 0
ioctl(7, SIOCETHTOOL, 0x7ffedafde390)   = -1 EOPNOTSUPP (Operation not supported)
dbg1:ETHTOOL_GMODULEINF0 pppoe0 failed : Operation not supported
ioctl(7, SIOCETHTOOL, 0x7ffedafde390)   = -1 EOPNOTSUPP (Operation not supported)
ioctl(7, SIOCETHTOOL, 0x7ffedafde390)   = -1 EOPNOTSUPP (Operation not supported)
ioctl(7, SIOCETHTOOL, 0x7ffedafde390)   = 0

Same as

frebib@zeus:~$ cat /sys/class/net/pppoe0/address

frebib@zeus:~$

iproute2 also shows this too

13: pppoe0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp
    inet <snip> peer <snip>/32 scope global pppoe0
       valid_lft forever preferred_lft forever
    inet6 <snip>::1/64 scope global dynamic mngtmpaddr proto kernel_ra
       valid_lft 2591533sec preferred_lft 604333sec
    inet6 fe80::f551:75ff:fedc:f28d/64 scope link
       valid_lft forever preferred_lft forever
    inet6 fe80::1 peer fe80::827f:f8ff:fe74:c8db/128 scope link
       valid_lft forever preferred_lft forever

If it's helpful, here's a tcpdump of me pinging a resolver, with the response

21:41:33.485179 1e:43:be:d9:9c:90 > 80:7f:f8:74:c8:db, ethertype 802.1Q (0x8100), length 110: vlan 10, p 0, ethertype PPPoE S (0x8864), PPPoE  [ses 0x72d] IP (0x0021), length 86: ??.??.??.?? > 1.1.1.1: ICMP echo request, id 1, seq 1, length 64
21:41:33.487988 80:7f:f8:74:c8:db > 1e:43:be:d9:9c:90, ethertype 802.1Q (0x8100), length 110: vlan 10, p 0, ethertype PPPoE S (0x8864), PPPoE  [ses 0x72d] IP (0x0021), length 86: 1.1.1.1 > ??.??.??.??: ICMP echo reply, id 1, seq 1, length 64

The underlying MAC address of the PPP interface is this

7: bond0.10@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9710 qdisc cake state UP mode DEFAULT group default qlen 1000
    link/ether 1e:43:be:d9:9c:90 brd ff:ff:ff:ff:ff:ff

Raised https://github.com/sflow/host-sflow/issues/68 with the above information. Will move over there to continue discussion

syncer edited projects, added VyOS Rolling; removed VyOS 1.5 Circinus.Nov 1 2024, 8:20 PM

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

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

sflow fails to identify pppoe0 interfaceOpen, NormalPublicBUGActions

Description

Details

Event Timeline

sflow fails to identify pppoe0 interface
Open, NormalPublicBUG
Actions