0

could I check if it is possible to convert TCP traffic to UDP multicast and if there are any appliances / switches that can do so?

E.g. Workstations A, B and C establishes a TCP connection with Server1. When messages are sent from Server1 back to either Workstations A, B or C, would it be possible to convert these messages from Server1 into UDP multicast and allow all workstations to listen into multicast group? I need a workstation to be able to listen to all traffic from Server1 that were originally meant for any of the other workstations.

Thanks.

  • Very much doubt it – Matt Douhan Jan 7 at 8:36
  • An application can, of course, use multiple TCP connections and also use UDP (both unicast and multicast). In any case, the use of TCP or UDP is determined by the application (really the programmer's choice), not a network engineer. – Ron Maupin Jan 7 at 14:41
  • Hi Matt Thank you for your comment. – nelson Jan 23 at 1:05
  • Hi Ron, Yes. I do agreed application can do the work. We are just looking for alternate way to see if it's possible to do it with network appliances. and wheather doing with hardware appliances will gain more performance compared to software (programming). Thank you. – nelson Jan 23 at 1:08
3

Not with Multicast, I wouldn't know how.

What might help is port mirroring ("span ports", "monitor ports") as many managed switches offer them.

Within the bandwidth limits of the port you select as your egress/destination/output port , you can even monitor multiple ports (for example the switch ports of Workstations A,B and C), or you can monitor the server's port. Of course, monitoring multiple loaded 1G ports to one single destination port might not be the best of ideas.

Then you connect an additional computer's NIC to the destination/output port. That NIC must be set to monitoring or promiscuous mode. And there needs to be an application running that can capture (optionally: .. and analyze in real-time) ethernet frames as they come in, and the computer needs suitably sized and suitably quick storage or RAM for the amount of data you want to capture and keep.

Please note that port mirroring does not offer any filtering mechanisms or selective mirroring of data streams - they just copy the ethernet frames as they come.

Setting up a capture filter might be advisable, based on criteria like MAC/IP address(es) or TCP/UDP ports of interest to the given situation, to reduce the amount of storage needed, and to cancel out some of the "noise".

Depending on your scenario, your needs might vary from specialized high volume/high speed capturing appliances, down to a simple laptop with a gigabit NIC, with (for example) pcap, winpcap or npcap as the capture library, and Wireshark for a) controlling the capture library (start, stop, capture filter) and b) for analyzing and dissecting the packets and flows. (Please be aware that ressource recommendations are actually off-topic here).


Addon 1

And then, there's ERSPAN on some switches and routers. With ERSPAN, a mirroring setup's destination/output is not another port on the same switch. Instead, data packets captured from the monitored/mirrored ports are encapsulated into a GRE/IP packet and sent from the Switch's management IP adress to an IP destination.

That destination might bei another ERSPAN capable switch/router, but in might also be a Wireshark instance configured to receive and decapsulate ERSPAN packets.

See here: Remote sniffing with ERSPAN to the desktop


Addon 2

Please also take into consideration:

Full packet capture and analysis is a "big hammer", and is usually called upon when a particular problem has been identified and needs to be fully understood down to the latest bit (quite literally) in the packet payloads or headers.

If your'e looking for statistical/meta information of the style "which computer talked to which other computer when and for how long, using which protocols and how much data did they exchange?" over extended periods of time, you should be looking at NetFlow technology.

NetFlow capable switches and routers collect (meta) information about data flows and forward it to a "netflow collector" which then can summarize, statistic-i-fy, report, correlate, graph, analyze ... etc. This will be a lot quicker than sifting through an immense amount of captured data.

Of course, you could extract/condense all of this information from the immense data mountains a full packet capture will generate for the given period of time. This will be a somewhat expensive, in terms of storage and computing (and financial) ressources.

| improve this answer | |
  • Hi Marc, thanks for your explanation. my situation is more to data distribution, so port mirroring might not be a good idea. :-| – nelson Jan 23 at 1:15
3

You cannot convert TCP to UDP or IGMP in general.

What you are asking for requires some mechanism in the application layer - e.g. some kind of proxy could do it. Note that layers above the transport layer are off-topic here, however.

If you just require a copy of the TCP segments sent to/from Server1 to listen in on the connections, that is exactly what port mirroring is for, see Marc's answer.

| improve this answer | |
  • Hi Zac67, thank you for your reply. As I explain to Ron above, I do agreed application can do the work. just looking for alternate way if network appliances can do it. The solution is more toward data distribution, so I think port mirroring might not be a good idea. Thank you. – nelson Jan 23 at 1:11
  • @user64237 Note that application layer protocols are off-topic here. Of course, you can "restream" a TCP payload using IGMP at the application level (a kind of proxy), but probably not using network appliances. – Zac67 Jan 23 at 7:34
  • Hi Zac67, thanks for your advise. noted. – nelson Jan 24 at 9:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.