I am trying to direct TCP traffic returning from external. and push that to different internal devices. The selection if the traffic should be pushed to multiple devices is being based the src-port of the external server. There are more than one IP addresses, but the src-port (external) is always the same.

The internal devices have each their own switch port. It would be nice to be able only push specific traffic instead of just all.

Using 6.49.2 on that router.

Who knows how this is done....?

What do you mean with returning traffic?
If you start a request on an Internal device (e.g. PC) to an external source (e.g. www.google.de) it doesn't make sense do direct the answer to a different internal device.
If you have internal server that should be requestet from the Internet (e.g. own webserver) than you can use port forwarding.
You can set up rules that match to a specific port (e.g. 443) or a port ip combination (e.g. 1.2.3.4:443 to -192.168.0.10:443, 4.5.6.7:443 -> 192.168.0.20:443).
Or do you need a load balancer?

Indeed returning traffic. It is a iptv stream and I want to offer it to two devices.

It is also unicast to multicast but simpler. I put in a dst-nat in, for returning traffic to multiple dst-addresses, but that one is not being hit.

Sending unicast packets over multiple ports, that is the trick that Microsoft used for it's Terminal Server Cluster. All Terminal Server servers must receive all RDP requests from clients, the NLB process would then assign the server that must process the request. https://docs.microsoft.com/en-us/troubl ... ation-mode

Basic for this is to use unicast flooding. (It used to be documented that they used illegal MAC addresses to trigger this. Illegal MAC addresses cannot be stored in the address table of the switch, so the switch has to send it to all ports). With unicast flooding the switch acts as a HUB for it's traffic control. So the easier setup was to insert a HUB before the servers. But fast Hubs are difficult to find, so a switch with permanent unicast flooding set is used. The disadvantage of that illegal MAC address was that all RDP traffic was flooded to all ports on all switches in the entire L2 network. VLAN and port isolation might contain this.

"Mirror" in a switch is limited to one extra copy only AFAIK.

TCP doesn’t work that way. Only the one endpoint requesting the traffic will accept the returning packets. The other will reject it as noise.

Multicast is UDP-only for that reason.

What you want is a software IPTV gateway of some sort, but the exact type depends on the service you’re trying to echo and the endpoints.

Don’t be coy. Details, man!

If you get a already a multicast, you only need clients on both devices to register to it.
If not you probably need something like a multicast proxy (if something like this exists and is legal to use).

It used to be documented that they used illegal MAC addresses to trigger this. Illegal MAC addresses cannot be stored in the address table of the switch, so the switch has to send it to all ports

Not exactly - they used a multicast MAC address as unmanaged switches, or managed with IGMP snooping disabled, will by design not learn the address and flood packets to all ports.

Indeed not exactly, forgot how it avoided storing tn the MAC table. (Is a long time ago, but that's the way I simplified the idea)
But there are 3 methods and, one was unicast (the one we used)
Found the detailed description: https://blogs.msmvps.com/clusterhelp/20 ... addresses/ (some SSL problem here)
Well ... not so easy to implement on just any device.

"What each NLB node does, when sending traffic, is it spoofs the MAC as above except it replaces BF with the priority number. For example, if the NLB cluster node were configured with the number three as its priority (unique) number, then it would identify itself to the switch as being MAC address 02-03-c0-a8-02-0b. This allows the switch to happily enter the MAC Address in its table and have a one to one mapping of MAC Addresses to ports.



So, when an NLB client tries to connect to the IP address of the NLB cluster and does an ARP on the IP to identify the MAC Address, the switch fabric flips out because it can’t find any ports that contain that MAC address and thus flood the fabric. The use of the priority number stops the switch fabric from trying to learn the actual MAC address of the NLB cluster and provides a bit of sanity/reality for the switch so that it is happy.



So, to summarize, each client connecting to the NLB cluster will use the bf MAC address as the destination which causes the switches to flood all ports with the traffic. Each NLB node sends data using the priority number instead of bf to stop the switch from learning the bf MAC address and trying to map it to a single port. "

@msatter, maybe using Multicast Routing ?
Have you searched for PIM ? It is a multicast routing protocol.

Hope that helps...

@msatter, maybe using Multicast Routing ?
Have you searched for PIM ? It is a multicast routing protocol.

OP said “TCP traffic”, which rules out multicast. There are ways to turn a single TCP unicast stream into multicast internally, but only if we learn the answers to the questions I posed in my prior post.

I highly doubt RouterOS provides the solution here. This needs a server somewhere.

@tangent you 're right...
I missed that...

Thanks for directions and I am lot wiser now. I think the best solution is to kind of proxy/caster, to which each device connects. Only one channel can be watched at the same time, so all devices will receive the same downstream.

The MAC/HUB trick is a last resort here.

When I have it running I will post here the setup.

so all devices will receive the same downstream.

The MAC/HUB trick is a last resort here.

It certainly is , as even with all devices receiving all packets, only one can have the (unicast) TCP session. It is just open which one actually takes that session.