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

Lichunhe lichunhe at huawei.com
Sat May 31 00:26:06 UTC 2014


I got it, thanks.

From: Nicholas Bastin [mailto:nick.bastin at gmail.com]
Sent: Friday, May 30, 2014 11:29 AM
To: Lichunhe
Cc: Ben Pfaff; discuss at openvswitch.org
Subject: Re: [ovs-discuss] 答复: Output port of mirror drops packet

On Thu, May 29, 2014 at 8:04 PM, Lichunhe <lichunhe at huawei.com<mailto: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/20140531/d78e9517/attachment-0002.html>


More information about the discuss mailing list