Destination Mac address mapping according to backend IP address about glb-director HOT 2 CLOSED

I understand the bypassing arp process and using MAC of the gw as destination MAC. But this may cause CPU issue on the network device as all packets are designated to the device itself is CPU processed.

We haven't observed switches doing this, because in our typical top of rack switch deployment the switches are essentially acting the same as when packets are incoming to the rack and performing hardware routing (MAC destination of the switch / default gw), rather than rack-local switching (MAC of the end machine on the same rack).

As all configuration process of backed are automatized via CI/CD, MAC address of each backend can also be included in the configuration file.

It should be possible to add an optional field for backend MAC address, though it does add additional complexity, and it very much depends on the type of deployment. For example, it may not always be trivial to know the MAC address without using ARP. Additionally, only machines on the same rack (switch) will be addressable via their direct MAC, and switches on other racks must still use the default gateway MAC.

If you've got a deployment where this does cause a problem and having MAC addresses in the forwarding table for rack-local machines or some other scenario would make sense, we could definitely accept a patch, as long as it's optional (enabled only if the MAC addresses are explicitly defined). 👍

from glb-director.

Hi Theo,

From the routing perspective it's same as routing packet outside network as long as GLB and backend are installed on different networks. Also as you experienced, modern routing process is hardware switched on switches.
We already checked with our switches (Arista) and packets are hardware switched which will not cause any issue. Although its very weird for the host on same subnet:)
We will watch the performance and update it we come up with any problem.
Thanks a lot .

from glb-director.