Hi Ben,
I will give it a whack.
Problem description:
There are several service functions that are essentially bump-in-the-wire. Eg.
Firewall from Palo Alto Networks, URL filter from Trend Micro, etc.
With traditional hardware, this is not an issue. The setup is typically as
follows
Switch/Router-------------------Internet |Service Function (SF)
|Switch1| |PC1 PC2
With virtual appliances, both interfaces of the service function attach to the
same virtual switch.
SF | | OVS--------------------Router---- Internet| |PC1
PC2
If the interfaces of the SF are L3 interfaces, there is no issue.However, if
the SF is a bump-in-the-wire, the br-int on the OVS switch will get confused
when packets hit the NORMAL action. Take example of traffic from PC1 to
Internet.br-int will learn the SRC MAC address of PC1. This packet will be
sent to SF on its ingress interface.SF will do its work and then send the
packet out on the egress interface. Since the packet comes outwith the same
SRC as that of PC1, br-int will now learn that the SRC MAC PC1 is on the
egress interfaceof SF. (Yes, this will only happen if the packet hits NORMAL
action).
Proposal:We introduce the interface keyword "learn= no".E.g. ovs-vsctl set
interface foo learn=no
This will instruct br-int NOT to do MAC learning on packets received on
interface foo.
This cannot be applied to a bonded port with 2 or more interfaces.
I also have a prelimnary set of diffs which seem to be working but need more
testing.I can post the diffs to the dev alias if folks are comfortable with the
proposal.
thanks,Farhad.
On Thursday, April 14, 2016 10:53 AM, Ben Pfaff <b...@ovn.org> wrote:
On Thu, Apr 14, 2016 at 05:30:20PM +0000, Farhad Sunavala wrote:
> Hi,
> I am aware that the MAC address gets learnt only when the packet passes
> through a flow with NORMAL action.This is fine and works for some cases.
> However, it seems a little too restrictive.
> I am working on service function chaining and there are several network
> functionsthat are implemented as bump-in-the-wire. E.g.
> SRC----SF1---DST
> If SF1 is a bump-in-the-wire service function, I need to disable learning on
> the egress port of SF1 (towards DST). This can easily be done by
> actuallyspecifying the output port to point to DST.
> But, a general hook which disables learning and allows the packet to flow
> through "normal"action would be great.
Do you want to propose a mechanism?
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
