4 ms·

In my experience with said expensive hardware, it greatly depends on your use-case / scale. You have to pay attention to stay within the limits of the hardware

by yokaze 5y ago

In my experience with said expensive hardware, it greatly depends on your use-case / scale. You have to pay attention to stay within the limits of the hardware the switches (TCAM, etc...). And correct me, if I am wrong, but most NICs are fairly constrained in their hardware support on the numbers of MACs they can filter for. And those two combined, you might end up with a lot of flooding, which needs to be handled by the CPU again. You also have to rely on the implementation of your vendor. And at least with one major vendor, who shall remain nameless, it is a major effort just to get acknowledged that there is a bug.

dfox 5y ago
The point about number of MAC filters is fairly moot as when you do bridging in hardware you are not going to utilize any kind of hardware MAC filtering capability anyway. Also the issue of flooding tends to be solved by the physical switches in the network.
- yokaze 5y ago
  So, we are in agreement in that point: if you are going that way, you are relying on the physical switches. I'm not sure about the problem being solved, depending on the scale. If you are with your use-case (number of rules, macs, five-tuples, ...) outside the capabilities of the hardware, then, in my experience, it breaks down quickly. (I.e. flooding, or becoming unresponsive to configuration commands and needed to be _power cycled_, ...). And those are switches costing easily five figures, and from two different well known vendors. If you have practical experience with a setup, which scales more gracefully, please share. But I'm sceptical that it exists, considering Google, Facebook, AWS all went with custom hardware. I'm wondering, if at a certain scale of virtual NICs/flows per port, you are not better off with a hybrid approach, where software is part of a decision hierarchy. E.g Openflow. No practical experience though.

by yokaze 5y ago

dfox 5y ago

The point about number of MAC filters is fairly moot as when you do bridging in hardware you are not going to utilize any kind of hardware MAC filtering capability anyway. Also the issue of flooding tends to be solved by the physical switches in the network.

yokaze 5y ago
So, we are in agreement in that point: if you are going that way, you are relying on the physical switches. I'm not sure about the problem being solved, depending on the scale. If you are with your use-case (number of rules, macs, five-tuples, ...) outside the capabilities of the hardware, then, in my experience, it breaks down quickly. (I.e. flooding, or becoming unresponsive to configuration commands and needed to be _power cycled_, ...). And those are switches costing easily five figures, and from two different well known vendors. If you have practical experience with a setup, which scales more gracefully, please share. But I'm sceptical that it exists, considering Google, Facebook, AWS all went with custom hardware. I'm wondering, if at a certain scale of virtual NICs/flows per port, you are not better off with a hybrid approach, where software is part of a decision hierarchy. E.g Openflow. No practical experience though.