[ovs-discuss] 答复: Output port of mirror drops packet

Nicholas Bastin nick.bastin at gmail.com
Fri May 30 03:29:28 UTC 2014


On Thu, May 29, 2014 at 8:04 PM, Lichunhe <lichunhe at huawei.com> wrote:

> I have seen the doc, and read the code, it is the implementation
> currently. But I want to
> Know why to do this? If the output port could send/recv normally, it will
> be a better way?


It would almost certainly not be better, neither historically nor in actual
functionality.

Historically this (not accepting incoming packets on mirror/span ports) was
necessary because it was very easy to build silicon that would copy a
packet to an arbitrary number of output ports so long as you could ignore
those ports for incoming packets.  Later, because this was the norm,
silicon and vswitches continued to enforce this restriction.  Now, for
legal reasons, it's *very* easy to perpetuate this restriction because
monitoring device vendors have *never* been in a position of trust in your
network.  If you allow the span/mirror port device to push packets into
your network there needs to be a trust relationship that has never existed,
and would incur some serious evaluation (that many enterprises would be ill
equipped to perform, and thus would punt entirely on monitoring and APM
boxes).  In the modern era, where this would be possible, the question
still extends to "why"?  The legal reasons still apply, and are very
compelling - it's a lot easier to build and sell an analysis box that
doesn't need to promise that it won't send, rather than validate that it
actually won't (and deal with the legal repercussions if it does).
 Additionally what would be the use case here?  If you have an IDS, etc.,
then you want this to live in the normal packet flow (not just the
span/mirror flow) already.  What is the use case for something that gets
copies of packets, but is not actually the forwarding element for those
packets?

As a separate aside, if you want to copy packets to a span/mirror port, you
can do this by systematically adding additional output actions to each flow
and you don't need new functionality for this.

--
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20140529/c301576c/attachment-0002.html>


More information about the discuss mailing list