networking-sfc

logical-source-port with IP prefix may create incorrect chains

Bug #1665960 reported by Fred S on 2017-02-19

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	networking-sfc	In Progress	Undecided	Unassigned

Bug Description

Current behaviour:
Configure a simple portchain as follows:
src --- sf1 --- sf2 ---- dst
Configure your flow-classifer as follows:
flow-classifier-create --logical-source-port <src> --protocol icmp fc
Your portchain will work just as you intended. So far so good.
Now, ping sf1 from another source (say src2).
The ICMP responses from sf1 back to src2 will also go through the chain even though in your flowclassifier you only specified ICMP traffic for src.
The reason is the flow rule programmed on sf1 is as follows:
inport=<sf1>, prot=icmp, actions=redirect to sf2
The logical-source-port specified in the flowclassifier has no relevance down the chain.

New behaviour:
Consider same portchain and flowclassifier as above.
src --- sf1 --- sf2 ---- dst
flow-classifier-create --logical-source-port <src> --protocol icmp fc
Say, src IP is 10.0.0.10
We now get the SRC IP (10.0.0.10) and put it in the flowclassifier.
Now, the rules programmed at sf1 will appear as follows:
inport=<sf1>, ip.src=10.0.0.10/32, prot=icmp, actions = redirect to sf2
Now, only icmp traffic from src will traverse through the chain. Pings from src2 to sf1 will no longer traverse through the chain which is what you wanted.

But if logical_source_port has multiple IPs then your change doesn't do anything. So I would say that we should have a bug logged for the fact that traffic from SF2 can unintentionally be funneled into the port chain and your commit message for this change should contain a partial-bug: line to reflect that it addresses the unintended behavior but only in the case where the source has only one IP.
The bug should get further attention. In particular, we could probably address a dual stack scenario where the source has one IPv4 address and one IPv6 address.

Revision history for this message

Paul Carver (pcarver) wrote on 2017-02-21:

Does this bug apply if an encapsulation is used? I think the problem is specifically due to the need to apply a flow classifier at every hop of the chain because there is no encapsulation used to uniquely identify traffic that belongs to a chain.

I'm wondering if the fix used in https://review.openstack.org/435281 will break service chains that modify the IP. Suppose a NAT service function is part of a chain and the user has deliberately not specified the source or destination IP because they expect that the IP will be changed when the packet traverses the NAT function.

Thinking about it even further, if src is a routing type function then it would not be expected that the source IP of the packet matches the IP of the src port. Consider the case where traffic from many WAN sources is funneled through src in order to pass it through a service chain. If src is NOT a NAT type SF but rather a router type SF then the source IPs of all the packets intended to pass through the chain would be the WAN IPs, not the cloud/LAN IP of the src VM.

Revision history for this message

Fred S (fsbiz) wrote on 2017-02-21:

Download full text (3.8 KiB)

1.
If the entity is a router created by neutron, then there is no issue
since the commit takes care of this scenario.
E.g.

   ext net1 net2
   | | |src1
   |---Router1---|---Router2---|src2
   | | |src3

2.
Your question is more about a SF performing routing/NAT.
E.g. In topoloy below, SF is a Router.

  ext |--SF1
   | | |--src1
   |---Router1--|--SF(Router)-|--src2
   | | |--src3
                |--SF2

In such a case, yes, you are right this commit will break things if only the logical-src-port is specified without the prefixes since it will insert the SRC IP address of SF(Router).

However, there are several easy workarounds for this.
1. - Specify the prefixes for the sources (most obvious one).
2. - Specify the SF(Router) interfaces to be router owned. (see below)

If the above SF is doing routing or NAT, then change the device owner to be network:router_interface instead of nova:compute

1.
If the entity is a router created by neutron, then there is no issue
since the commit takes care of this scenario.
E.g.

ext          net1          net2
   |             |             |src1
   |---Router1---|---Router2---|src2
   |             |             |src3

2.
Your question is more about a SF performing routing/NAT.
E.g. In topoloy below, SF is a Router.

ext           |--SF1        
   |            |             |--src1
   |---Router1--|--SF(Router)-|--src2
   |            |             |--src3
                |--SF2

In such a case, yes, you are right this commit will break things if only the logical-src-port is specified without the prefixes since it will insert the SRC IP address of SF(Router).

However, there are several easy workarounds for this.
1. - Specify the prefixes for the sources (most obvious one).
2. - Specify the SF(Router) interfaces to be router owned. (see below)

If the above SF is doing routing or NAT, then change the device owner to be network:router_interface instead of nova:compute

If the device_owner is a router_interface, the commit will not mess with it (not insert its source IP into the flow classifier)

Louis Fourie (lfourie) on 2017-06-07

Changed in networking-sfc:
status:	New → In Progress

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.