EthernetContext doesn't contain the src/dst MAC addresses

[johlj]

Expected Behavior

It should be possible to extract the src/dst MACs from
request.GetConnection().GetContext().GetEthernetContext()

Current Behavior

GetDstMac()
and
GetSrcMac()
both return null

Failure Information (for bugs)

Steps to Reproduce

Use the second argument of the request function (*networkservice.NetworkServiceRequest) in a NSE
and try to get:
request.GetConnection().GetContext().GetEthernetContext().GetDstMac()

[edwarnicke]

Question... which forwarder are you using? And which NSE?

[edwarnicke]

The real question I'm getting to with 'which NSE' is what mechanism is being used. Typically, the Forwarder (thus my question as to which one you are using) would populate that info. Which Mechanism is being used for the NSE might also be important to tracking down the bug, thus that question.

[johlj]

Hi,

the behavior is the same with both the VPP and the kernel forwarders + with everything on a single node/vm as well as multi-node setups. Seems it's quite generic for us.

Br,
Johan

[edwarnicke]

That's useful to know.

[denis-tingaikin]

@edwarnicke , @johlj The main issue here is that we are trying to get mac address on the endpoint side when actually information about it will be available on-forwarder side.

@johlj As a workaround, I can suggest generating mac addresses on the endpoint and put them into ethernet context then forwarder should try to apply it to creating interfaces.

[denis-tingaikin]

Also, we can try to use monitor staff from the endpoint to get actual information about the connection with fill ethernet context
https://github.com/networkservicemesh/networkservicemesh/blob/master/sdk/monitor/crossconnect/crossconnect_monitor_client.go#L30
https://github.com/networkservicemesh/networkservicemesh/blob/master/sdk/monitor/connectionmonitor/connection_monitor_client.go#L37

@johlj Is it solve the issue?

[johlj]

Not sure yet, we'd need some time to try this out (quite busy time here currently and we have a scripted workaround for the moment)

Our use case is varying a bit but the general idea is that it would be useful with some sort of notification of the status of the other "side" of the p2p link. For example if a NSE receives a request from a NSC, it might require information about

1. MAC of the NSC side of the link. 2. IP on the NSC side and 3. That the interface is up and running on the NSC and can receive traffic.
   We'd prefer if this mechanism can be as generic as possible (ie work over different forwarders/interface types etc)

This would also be helpful in the other direction (ie the NSE notifying the NSC).

[edwarnicke]

1. MAC of the NSC side of the link.

So normally, if the NSE wants to know the MAC address of the NSC side of the link, it provides the desired MAC address in the ConnectionContext.EthernetContext.SrcMac. I'm totally open to understanding use cases for which this is insufficient, is it for yours?

2. IP on the NSC side

Again, typically the NSE learns this because it has indicated the IP address which should be assigned to the NSC using ConnectionContext.IPContext.SrcIP. Do you have a usecase for which this is insufficient?

3. That the interface is up and running on the NSC and can receive traffic.
   This one is interesting... I totally see why this might be of interest, but it would help if you could describe your specific needs.

[LionelJouin]

I tried this monitor on the next gen NSM (multi-repo) and it was a bit unclear to which monitor I was supposed to connect to, so I tried to connect on the local one (on the NSE using the monitor adapter), and on the one on the NSMgr using gRPC, but in both cases, the link was not ready and the ethernet context empty.
https://github.com/networkservicemesh/sdk/blob/master/pkg/networkservice/common/monitor/server.go

On the NSE, is there a way to get an event on when the link is ready which can also return the Connection (containing EthernetContext...)? So the NSE could know which MAC addresses are used, what is the interface name...

[johlj]

@edwarnicke, seems we're getting a bit detracted from the original topic in the ticket :) Suppose we could close it and continue elsewhere if preferable.

Either way, at this point. Getting the MACs (which was the original focus) is not all that essential for us since we don't.
rely as heavily on them anymore.
For the IPs we can probably use the way you mentioned.

The functionality we're currently mainly looking for is to be able to know when the remote interface is fully initiated and ready to receive traffic. It seems the monitors could potentially be used for that, or?

[edwarnicke]

@LionelJouin I had setup some issues for implementing the EthernetContext in the multi-repo:

networkservicemesh/sdk-vpp#32

networkservicemesh/sdk-vpp#33

networkservicemesh/sdk-vpp#34

networkservicemesh/sdk-vpp#35

as starter issues (as someone was asking for starter issues to work in sdk-vpp)

As to the link being ready... it won't be on NSE return (because the NSE has just made its decisions about what its part of the link looks like.

Generally the link will be ready either:

1. After the client local Forwarder has returned (or in the case of your situation, notified MonitorConnections) for the case where we are dealing with kernel mechanism (since the Forwarder does the work for kernel mechanism)
2. For the case of memif... the client would still need to do its work to hook up the link.

On the NSE, is there a way to get an event on when the link is ready which can also return the Connection (containing EthernetContext...)? So the NSE could know which MAC addresses are used, what is the interface name...

So I think there's some confusion here, which may be you having requirements I simply don't understand. The NSE may optionally assign the client a Mac address (ethernetcontext). As to the link being ready... since decisions about mechanisms etc are made by the NSE, the construction of the link has to occur along the return chain for the Request. So when the NSE returns the Connection, it's provided the necessary information to construct the link, but the link is yet to be constructed down the chain.

It might help if I could understand why you are trying to detect (rather than assign) mac addresses from the NSE and why you want to know that the link is fully up from the NSE?

[edwarnicke]

@johlj I'm all for opening other issues to carry on the conversation :)

[LionelJouin]

Thanks for your help and explanation.

We are working on an alternative to the point to multipoint using a proxy. The proxy is a pod with privileges used, at the same time, as an NSE for the applications and as an NSC for the network service (load balancer...). All ready NSM interfaces on the proxy pod should be added to a bridge running on this proxy, so the application (NSC of the proxy) and network service (NSE of the proxy) can communicate together.

As an NSC, it is easy to know when an interface is ready since, when the NSC receives the response from its request without error, the interface has been created (at least with the vpp-forwarder with kernel mechanism).

But as an NSE, currently, the proxy is monitoring the interfaces based on their name (got from InterfaceNameKey in an endpoint) and when our interface monitor detects the creation of the NSM interface it adds it to the bridge.

In this case, getting the Connection (mac addresses...) is not critical, but as mentioned, we are more trying to detect when the interface is ready on the NSE.

[edwarnicke]

@LionelJouin Thank you for the detailed explanation :) I understand a lot better what you are working with.

[stale]

This issue has been automatically marked as stale because it has not had activity in 30 days. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it has been inactive for 37 days. Feel free to reopen it if you feel it has been closed in error.