Is it possible to tap and stream L4 traffic?

[pxpnetworks]

I have a lot of pods which process/proxy pure TCP traffic .. is it possible to have it tapped too or it only shows L7 traffic in the UI ?

BR,
Stoyan

[nimrod-up9]

Hi @pxpnetworks
Mizu specializes in API observability, meaning L7.
For pure TCP I would recommend the classic tcpdump + Wireshark.
What are you looking for in Mizu that is missing in Wireshark? (for L4)

[nimrod-up9]

Could describe what is the problem you are facing?
Maybe Mizu can still be of use to you.
If find that something is missing then we are happy to take feature requests.

[pxpnetworks]

Hi @nimrod-up9 ,

Sure, I understand Mizu specializes in L7 :)
I have in my clusters 50/50 split of HTTP traffic and the other half is pure TCP+TLS... mainly L4 proxies.
It would be nice to still be able to see the TCP traffic flows real time too alongside the HTTP traffic in Mizu as i really like its UI.

Thanks for your comment and will see what the future holds 👍

BR,
Stoyan

[haiut]

@pxpnetworks thanks for your question - can you clarify how would you like the TCP (L4) traffic presented - do you mean to see plain packet contents (tcpdump-style) or something different ?

[pxpnetworks]

Hi @haiut ,

To be honest i would like to see at this point just the communication flowing on L4 on the left hand side with basic IP:PORT info (source pod / destination pod too if possible). I'm not interested in seeing the TCP flags tcpdump style.
I understand currently Mizu tags the requests as HTTP/H2/GRPC/KAFKA/REDIS. The pure L4 traffic can be simply tagged as "TCP" or "UDP" or "TLS" or "QUIC".
In summary i need to be able to tap my L4 processing pods - I run a lot of Envoy proxies which are used as L4 forwarding proxies (utilizing TLS SNI) or in a Service Mesh pattern but again only to proxy L4 traffic like Syslog, MSSQL etc.

Right now I tap into such L4 proxy pod and see nothing in the UI.

When i do a service rollout i think Mizu can be a great tool to observe if the traffic is flowing as intended and catch any issues on the fly. (I know there are lots of other tools and methods to do this but again speaking from an end user perspective i find Mizu most appealing to me from the first try).

In the end if you decide it's worth and feasible to add showing the L4 traffic probably it needs to map to some kind of TCP flags similar to response.status/request.method for HTTP but it might be too noisy to live stream it. Don't know if something simpler tracking only Started / Completed TCP sessions will make more sense if the intention after all is not to make Mizu like tcpdump :)

BR,
Stoyan

BR,
Stoyan

[andrewnazarov]

At first I also missed L4 information as I wanted to investigate some networking anomalies we were facing. Another thing is that some of our services are communicating with external endpoints via https and this traffic is also not covered.

I understand that this might not be the case for Mizu and agree that it might be too noisy to get this presented.

Anyway, thanks for the great tool!

[nimrod-up9]

Regarding the external endpoints: Mizu is actually able to tap HTTPS traffic :)
It is an experimental feature that you can turn it on with the --tls flag. Note that currently Mizu only captures TLS traffic from pods which use the openssl library. For instance, traffic from Python and cURL is captured while traffic from Java and Go is not.

About the L4 support, we are considering if and how to display it.

[andrewnazarov]

Yes, I tried this flag out and it didn't work in our case. It seems the problem was that I tried to tap the Java service. Thanks for the clarification!

[mudged]

+1

I’d also like to see L4 support. My applications have a mix of HTTP and proprietary TCP messages.

[alongir]

@mudged would you mind opening a feature request issue? Can you clarify how would you like the TCP (L4) traffic presented - do you mean to see plain packet contents (tcpdump-style) or something different ?

[whites11]

Sorry for the intrusion, I can add my use case that I think is partially related. I would love to be able to use kubeshark for udp traffic as well. this would be for example useful when troubleshooting DNS in a cluster. Are there any plans to support UDP-based protocols?

[alongir]

@whites11 intrusion is very welcome! We are evaluating introducing DNS protocol support. I'm curious how common this need is.