0

In response to my question Propagating Static MAC Addresses , I realize I can not avoid the unknown unicast problem. Essentially I have hosts that forward their traffic via an L2 frame to a destination MAC. Given there is no IP there is no ARPs and no way for the switches in the middle to 'learn' the MAC.

I was thinking I could have a Cisco switch with an SVI send gratuitous ARPs that flood the network and 'teach' all switches in the middle. I would need the gratuitous ARPs sent out on a regular interval, greater than the expiry timeout of any middle switch. I would then port mirror off that SVI. That way these raw frames are no longer destined to an unknown unicast destination and flooded.

Any way I can accomplish this?

  • Why is flooding the unknown unicast frames a problem? That happens on networks all the time. If it is just the hosts and server for this application on the VLAN, then I really do not see the problem. If there are other hosts on the same VLAN, then the SVI idea is a bad idea because you can end up sending frames from the other hosts to the server, too. – Ron Maupin Jul 30 at 16:05
  • Because this is essentially port mirrored traffic. If 1G ingress is coming into Host1 it will forward 1G egress to the special MAC address. I don't want 1G of traffic flooded to all other hosts due to the unknown unicast issue. – o8uijoipjasdfjiloasdfjl Jul 30 at 16:21
  • @RonMaupin The above will be further multiplied by the number of hosts that have this mirroring requirement. – o8uijoipjasdfjiloasdfjl Jul 30 at 16:21
  • "If 1G ingress is coming into Host1 it will forward 1G egress to the special MAC address." No, a host receiving a frame that is not destined to its MAC address simply drops the frame. That happens in the NIC. – Ron Maupin Jul 30 at 16:22
  • 1
    Did you ever consider RSPAN for this? You wouldn't even need a software on the host anymore that copies and forwards ingress traffic to another host. Rspan-monitor the monitored hosts' switch ports (rx, tx or rx/tx, as needed). RSPAN will copy the hosts' frames into/through the RSPAN VLAN. At the monitoring server's switch, configure an an RSPAN destination port and attach that special IP-less NIC to it. Put that NIC into promiscuous mode and start capturing. – Marc 'netztier' Luethi Jul 30 at 21:11
2

As we explained in your original question, the node to which this traffic should be flowing MUST send a frame for the connected switch to learn its location. And it must be a broadcast frame if you want the entire network to learn it. For IPv4, ARP takes care of this; IPv6 NDP. A gratuitous arp from a switch will only get the traffic to that switch, but not necessarily the correct port.

While, yes, flooding does naturally occur in switched networks ("fabrics"), it's a rare event that doesn't last for more than a few frames. The ARP process will usually fill the switch tables, and re-verification will keep it filled. If you doubt how little traffic is actually flooding, go to any node on any switch in your network -- preferably one in a VLAN with many other nodes -- and start a promiscuous tcpdump filtering out the local MAC and all broadcast traffic. There will be very little "foreign" traffic showing up.

This kind of unicast flooding is Very Bad(tm). It is effectively a broadcast storm, but because it's not actually broadcast traffic, the switches cannot detect and block it like a real broadcast storm. If it's only 10pps, then it's much less of a catastrophe. But when it's a significant amount of traffic, it becomes a huge problem because every port in the entire network (carrying that VLAN) will have to carry the traffic. Yes, your NIC will filter it out, but it still consumed bandwidth crossing the link. (your NIC received it, but didn't pass it on to you.) Do you want every node in the network eating 800mbps of traffic it doesn't want?

| improve this answer | |

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.