Thursday, January 21, 2021

Makeshift Packet Broker?

I’ve read on here before that you can reuse retired data center switches, like N9Ks or QFXs as a makeshift packet broker switch to save a bunch of money buying a real one for your monitoring systems.

How does that work exactly? Do you just configure SPAN/Port Mirroring on a set of interfaces, plug your TAP outputs into those interfaces, and then configure the SPAN output ports to feed the monitoring system?

Would that actually work?

Usually you do port mirroring on revenue ports passing actual traffic. If you just configure SPAN ports and dump tap output into them, will that actually work?

I’m trying to envision in my head what the behavior would look like. The switch is going to receive a bunch of frames from the TAP output, frames all destined for mac addresses not present in the forwarding table, which would result in unknown unicast flood... frames with all manner of vlan tags probably not configured which would result in discards, frames that could be multicast etc... would port mirroring properly replicate all these to the output interface? Or would the forwarding rules of the switch get in the way, I.e it’s not going to be a passive replication of the tap traffic, we’d muddy that up with BUM traffic from the fake broker switch, we’d miss out on discards etc, and of course all the other drawbacks of SPAN like not getting malformed packets, etc.

How would you configure the interfaces? All ports access mode, each in their own VLAN to avoid cross-TAP BUM traffic from flooding to the other interfaces?

Also from a layer 1 point of view, would this even work? Would an in-line TAP output even bring a port on a switch to an up status? We’d only be receiving light from the in-like TAP. I’m not 100% sure if that would even bring the port status as up?



No comments:

Post a Comment