I got it, thanks.

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

On Thu, May 29, 2014 at 8:04 PM, Lichunhe 
<lichu...@huawei.com<mailto:lichu...@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
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Reply via email to