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.
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.