Healing with two NSEs could keep previous IPContext values #9888
Comments
denis-tingaikin
changed the title
github-project-automation
bot
moved this from Moved to next release
to Done
in Release v1.11.0
|
Hello @barby1138, The problem with re-connecting has been fixed. It'd be perfect if you could test it with NSM v1.11.2-rc.1. |
|
It's done |
|
Hi @denis-tingaikin, as part of v1.12.0-rc, I experienced some issue with the solution. |
|
@LionelJouin might be. Let's consider this a bit deeper. Could you say more about the issue that you caught? |
|
I have a custom NSC requesting VIP addresses, the internal addresses (communication between NSC and NSE) are handled by the NSE. The NSE detects the VIPs and keep them in the context, and reset the internal IPs if they are incorrect. |
|
Hmm.. I suspect that the VIP address was set by NSC on the first request, right? |
|
If so I think we should do reselect always with the initial request parameters. What do you think about this solution? |
|
no, the VIPs can be set during the first request but can be updated with additional request (mostly that case). |
|
Got it. Am I getting it correct that the VIP address could also be updated by the NSC during runtime? |
|
yes, this is correct |
|
OK, good. I feel that fixing it on the NSE might not be effective because NSEs are not under our control, and we don't know if it will keep the VIP address or not. So the solution, from my point of view, should be in the NSC. For example, we can do re-election by doing this: |
denis-tingaikin
added
bug
|
In my case, the NSE is a custom one too. But in case of your example, the nse-2 should remove the IP since they are not assigned for the NSC in its IPAM and they don't belong to the same subnet. |
|
Currently, I see these options for how to resolve the problem:
I think we can start with option 1 and implement option2/option3 in release v1.13.0. Thoughts? |
|
For the 3rd solution, I see it more like a policy for the IPAM. In the current NSM NSE and IPAM, the default behavior should just be to replace remove all IPs that does not belong to the correct subnet or that have not been allocated for the particular NSC. |
Question.. How can we detect that the address from the IPContext is VIP and we should not replace it? |
|
Also, a question: Is it possible for you to add a chain element that appends the VIP address to the request? For example, we can simply add a new chain element that simply appends to the request the VIP address. package addvipaddress
type client struct{
}
func (c *client) Request(ctx context.Context, request *networkservice.NetworkServiceRequest, opts ...grpc.CallOption) (conn *networkservice.Connection, err error) {
request.GetConnection().GetIpAddress().SrcIpAddrs = append( ... ) //TODO: check contains
return next.Client(ctx).Request(ctx, request, opts...)
}
func (c *client) Close(ctx context.Context, request *networkservice.Connection, opts ...grpc.CallOption) (*emptry.Empty, err error) {
return next.Client(ctx).Close(ctx, request, opts...)
}nsmClient := client.NewClient(ctx, client.WithAdditionalFunctionality(addvipaddress.NewClient())UPD: Also, if we go with this solution, we'll be able to update the VIP address immediately via using go func() {
<-vipAddressChangeCh
begin.FromContext(ctx).Request()
}() |
|
In my case, the NSE takes care only about the IPs that belongs to the same subnet and checks if they have been allocated for that particular requesting NSC. VIPs could be an example, but this would also apply to MAC addresses and routes. Isn't the NSE supposed to control these properties and correct them if they contains incorrect information? Yes, a chain element could be a workaround. |
|
@denis-tingaikin Is it possible that when we fixed this initial problem by setting the ConnectionContext on reselect in the NSC to nil, we should have instead had the ipam module in the NSE check to see if the IP address provided was either: a) Understood to be associated with the connection id or before permitting it, and reassigned it if not? @LionelJouin what are your thoughts? @barby1138 what are your thoughts? |
|
@edwarnicke Sure, it's possible, and if you feel that it's a better way, we can do that. The problem that I am seeing here is that NSM users will need to manage the IPAM module, which adds complexity. |
github-project-automation
bot
moved this from Moved to next release
to Done
in Release v1.12.0
|
Seems like done |
Steps to reproduce
Actual: Reconnect is slow and nse2 & nsc have old IP context values
Expected: Reconnect is quick and nse2 & nsc havn't old IP context values
Additional information
What was done:
After test onstall
network service: connects client to nse-1
apiVersion: v1
items:
kind: NetworkService
metadata:
...
spec:
matches:
app: nse-kernel-1
source_selector: null
payload: ETHERNET
...
This is not what expected:
client and nse-2 has 2 ips from nse-1 and nse-2 expected from nse-2 only
It tooks too much time to switch
The text was updated successfully, but these errors were encountered: