hsflowd on Debian12/VyOS unidentified src/dst interface #69
Comments
|
With this kind of pcap sampling hsflowd only has the MAC addresses to go on, and it looks like the various eth0. sub interfaces all have the same MAC so they collapse together - and then hsflowd recognizes them as local so it writes the port number as 0x3FFFFFFF to mean “internal” - which makes more sense for end-hosts than for routers, but that is what is going on. The sFlow standard is only supposed to report in/out interface index numbers by physical port anyway, so it’s actually defensible, and the right place to look for the VLAN detail is in the decode of the 802.1Q header… which appears as expected. Why only report in/out physical ports? To understand that you have to consider that sFlow was designed for whole-network monitoring, not just for individual routers. By adopting a data-model of “devices connected by links” you get link objects that mean the same thing to the neighboring devices. So you have a coherent model and can resolve the end-to-end traffic matrix for the network ( and avoid being presented with potentially thousands of sub-interfaces that only mean something to the router they are on). Once you have a stable and scalable network model, with counters for every link, then all the detail about VLANs, MPLS labels, priorities, routes, congestion bits, tunnels etc. can be captured in the annotated packet samples. So for a packet like this that came in on one VLAN and was routed to another the correct approach in sFlow would be to include the “extended_switch” structure and use it to indicate the in+out VLANs regardless of whether the packet was sampled on ingress or egress. The “extended_router” structure could also be used to report CIDR prefixes and nexthop. We have thought about what that would look like on Linux. It probably involves either (1) querying netlink for routing info (assuming we can know which routing table was applied, since that might have been set by nftables with a ‘mark’) or (2) moving the packet sampling so that it happens inside the routing engine (eg FRR) where the full picture is known. Another approach is for the sflow collector to peer with a route reflector and retrofit those routing interpretations as best it can. That is never as good as getting the details “straight from the horses mouth” but it’s good enough for many purposes. The pcap module is quite versatile, and the kernel-based sampling that it employs is good for performance. It’s not perfect, but it has been a lot easier to use than the ULOG and NFLOG modules that we started with. We might find that we can instrument a VPP dataplane more accurately in due course. Thoughts? |
Moin,
this is probably related to #68 ;
I experience a similar issue on a device with two vlans where hsflowd does not identify either the src or dst interface depending on the packet flow:
Capturing on the raw interface leads to a higher number of samples with in and out .
the sflow conf is:
A corresponding sflowtool dump looks as follows:
tcpdump of
tcpdump -i eth0 -n -s 1600 -w icmp6.pap src 2a06:d1c1:000a:0000:0195:0191:0197:0197 and dst 2a06:d1c3:2:3::1attached:icmp.zip
(Not the same packet as te sample, but same path/flow)
Could the issue be some confusion because the in and out vlan differ? (in eth0.742 out eth0.750)
edit: just saw that the debug log is for the reverse path; I in fact seem not to see any flows that get correctly attributed to eth0.742.
while logs for eth0.750 exist
The text was updated successfully, but these errors were encountered: