Please don't drop the list!
On Fri, Mar 20, 2015 at 09:40:23AM +0530, deepaksingh wrote:
> Hi Ben ,
>
> the L3 flows for wireless-client communicate with wireless-client in
> another VLAN will look like below.
>
> In_port=ats,vlan=10,src_mac=client1's
> MAC,dst_mac=vRouter'sMAC,eth_type=0x800,dstip=
> 20.1.1.2/32,action=set_src_mac=vRouter's MAC, set_dst_mac=client2's MAC,
> set_vlan=20,output=ats
>
> In_port=ats,vlan=20,src_mac=client2's
> MAC,dst_mac=vRouter'sMAC,eth_type=0x800,dstip=
> 10.1.1.2/32,action=set_src_mac=vRouter's MAC, set_dst_mac=client1's MAC,
> set_vlan=10,output=ats
>
>
>
> Apparently, above flow will not forward traffic traffic as in_port and
> output is the same port "ats". As you mentioned controller have to use
> "IN_PORT". So instead of using "IN_PORT" can ats (Physical port) be used in
> this case?
Please read the FAQ.
### Q: I added a flow to send packets out the ingress port, like this:
ovs-ofctl add-flow br0 in_port=2,actions=2
but OVS drops the packets instead.
A: Yes, OpenFlow requires a switch to ignore attempts to send a packet
out its ingress port. The rationale is that dropping these packets
makes it harder to loop the network. Sometimes this behavior can
even be convenient, e.g. it is often the desired behavior in a flow
that forwards a packet to several ports ("floods" the packet).
Sometimes one really needs to send a packet out its ingress port
("hairpin"). In this case, output to OFPP_IN_PORT, which in
ovs-ofctl syntax is expressed as just "in_port", e.g.:
ovs-ofctl add-flow br0 in_port=2,actions=in_port
This also works in some circumstances where the flow doesn't match
on the input port. For example, if you know that your switch has
five ports numbered 2 through 6, then the following will send every
received packet out every port, even its ingress port:
ovs-ofctl add-flow br0 actions=2,3,4,5,6,in_port
or, equivalently:
ovs-ofctl add-flow br0 actions=all,in_port
Sometimes, in complicated flow tables with multiple levels of
"resubmit" actions, a flow needs to output to a particular port
that may or may not be the ingress port. It's difficult to take
advantage of OFPP_IN_PORT in this situation. To help, Open vSwitch
provides, as an OpenFlow extension, the ability to modify the
in_port field. Whatever value is currently in the in_port field is
the port to which outputs will be dropped, as well as the
destination for OFPP_IN_PORT. This means that the following will
reliably output to port 2 or to ports 2 through 6, respectively:
ovs-ofctl add-flow br0 in_port=2,actions=load:0->NXM_OF_IN_PORT[],2
ovs-ofctl add-flow br0 actions=load:0->NXM_OF_IN_PORT[],2,3,4,5,6
If the input port is important, then one may save and restore it on
the stack:
ovs-ofctl add-flow br0 actions=push:NXM_OF_IN_PORT[],\
load:0->NXM_OF_IN_PORT[],\
2,3,4,5,6,\
pop:NXM_OF_IN_PORT[]
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
