Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to handle TAP Traffic #42

Open
fionera opened this issue Feb 25, 2021 · 1 comment
Open

How to handle TAP Traffic #42

fionera opened this issue Feb 25, 2021 · 1 comment

Comments

@fionera
Copy link

fionera commented Feb 25, 2021

Hello,

I currently try to use hsflowd to generate sflow Data from tapped fiber connections. This has the result that I have multiple Interfaces which are receiving the rx and tx traffic of an uplink.

As example I have the following network interfaces:

4: ntt1_tx: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
5: ntt1_rx: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
6: level3_rx: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
7: level3_tx: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000

Can I configure hsflowd so that it reports incoming traffic from that interface as outgoing traffic? Or better is it possible to "merge" two interfaces to that they have the same id?

@sflow
Copy link
Owner

sflow commented Feb 25, 2021

There are no existing config options for remapping port1_rx to port2_tx if that what's you mean. However I'm not sure it would be advisable to add code to do this. It seems that the sFlow collector will need to make sense of the feed and fit it into whatever additional feeds it might be getting from other devices (sFlow, LLDP, MAC location etc.), so anything you do down on the agent to obscure what is really going on could cause confusion.

Reuniting the tx and rx for each link is something that your sFlow collector can probably do. It might be elegant to make it look as though the measurement was taken at the router port that terminates the fiber. Or it might be preferable to model your agent as if it were a 4-port switch sitting inline. Either way the collector software needs to be in control of the interpretation.

Maybe your collector software doesn't offer those features, but even if you just dump the data into a time-series database you could still combine the tx/rx results using a custom Grafana dashboard.

This use case has come up before. Some switch ASICs will sample packets even if they are not going to be forwarded, which makes it possible to use a low-cost 24-port switch as a 24-tap probe (perhaps telling the switch each port is on a different vlan). In that case the switch will do exactly as your hsflowd agent will do and report tx and rx on different ifIndex datasources. As long as the collector software can remap these then it can be a good way to add sFlow visibility to a legacy network.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants