IP CIDR support in NSM_FORWARDER_SRC_IP

[pperiyasamy]

The forwarder daemonset configuration actually takes /32 ip address
in NSM_FORWARDER_SRC_IP to configure the tunnel endpoint in case of
remote vWire connection. But this would work on single node if we use
forwarding-plane.tpl with only changing the NSM_FORWARDER_SRC_IP to
different interface ip address.

This fix allows to support CIDR format (ex: 10.10.10.0/24) for the above
parameter so that forwarder pod on different node would choose corresponding
interface ip address on this network for vxlan local tunnel endpoint.

Signed-off-by: Periyasamy Palanisamy [email protected]

Description

This change detects the interface IP address for the given IP CIDR mentioned in the
NSM_FORWARDER_SRC_IP parameter and uses that as an Egress Interface IP address
for remote vWire connection between client and endpoint.

Motivation and Context

This is useful incase of forwarder is deployed in multiple k8s worker nodes and would
want to choose particular network interface as its egress interface IP address (other
than k8s primary network interface IP address)

How Has This Been Tested?

• Covered by existing integration testing
• Added integration testing to cover
• Tested locally
• Have not tested

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[haiodo]

@edwarnicke I think it could be interesting to incorporate to cmd-vppagent-forwarder?

[edwarnicke]

Hmm.. @pperiyasamy I'm still trying to fully wrap my head around this... usually the SRC_IP is acquired via the downward API for the Pod IP (which if in host:network is the Node IP). It sounds like you are wanting to set things up for a cluster with a different setup... using a single subnet that is supposed to contain all of the Node IPs... am I understanding you correctly?

[pperiyasamy]

Hmm.. @pperiyasamy I'm still trying to fully wrap my head around this... usually the SRC_IP is acquired via the downward API for the Pod IP (which if in host:network is the Node IP). It sounds like you are wanting to set things up for a cluster with a different setup... using a single subnet that is supposed to contain all of the Node IPs... am I understanding you correctly?

@edwarnicke Yes, NSM have provision to choose Node IP (via downward API for the Pod IP) which actually belongs to the interface used for k8s primary networking like Calico, But this use case (the page 8 in the slide provided here) needs another interface in the host as termination end point for NSM data plane. Looks this is not possible unless we introduce some logic into forwarding-plane.tpl to choose different IP address for NSM_FORWARDER_SRC_IP on each node (may be forwarder daemon set/deployment config per node).
I can understand your concern that this PR won't work if there are multiple interfaces with ip addresses on the same subnet. Please let me know your thoughts.

[edwarnicke]

Hmm.. @pperiyasamy I'm still trying to fully wrap my head around this... usually the SRC_IP is acquired via the downward API for the Pod IP (which if in host:network is the Node IP). It sounds like you are wanting to set things up for a cluster with a different setup... using a single subnet that is supposed to contain all of the Node IPs... am I understanding you correctly?

@edwarnicke Yes, NSM have provision to choose Node IP (via downward API for the Pod IP) which actually belongs to the interface used for k8s primary networking like Calico, But this use case (the page 8 in the slide provided here) needs another interface in the host as termination end point for NSM data plane. Looks this is not possible unless we introduce some logic into forwarding-plane.tpl to choose different IP address for NSM_FORWARDER_SRC_IP on each node (may be forwarder daemon set/deployment config per node).
I can understand your concern that this PR won't work if there are multiple interfaces with ip addresses on the same subnet. Please let me know your thoughts.

I'm actually mostly concerned with getting the most elegant generalization that would meet you needs and the needs of folks like you :)

What I noted is that you have basically taken things from a "Look from an interface with this IP" regime to a "Look for an interface on this subnet" regime.

Overall I'm super supportive of being able to support more than the K8s downward API here... just wanted to make sure we got the best generalization :)

So is it correct to say that your basic use case is: I want to be able to use as a management interface something different than the single IP coming from the downward API, in a DaemonSet (meaning I can't just specify it as a particular IP)?

My gut is telling me that whatever we do is likely to involve what you are suggesting here (also supporting "Look for an IP on this subnet"... but it might be the case that someone has a more sophisticated case as well... perhaps involving multiple possible subnets for example? What would your thoughts be on that?

[JanScheurich]

@edwarnicke For our use cases a single IP subnet would suffice. It has the advantage of uniqueness as typical hosts would not have more than one interface with an IP address in a subnet. With a list of IP subnets, uniqueness would depend more on correct host network configuration. On the other hand, there may be valid use cases where the relevant host IPs are from different, non-contiguous subnets, which might be difficult to handle with a single IP subnet parameter (a K8s cluster distributed over multiple DCs?).

[pperiyasamy]

@edwarnicke I think this PR is still valid as it supports to choose an interface for local tunnel endpoint from a subnet on each worker node. This would be just an add-on to the existing functionality i.e. choosing the interface using /32 IP address.