How can I enable promiscuous mode on an NSX-T Segment? “Mac Learning” is enabled, but the application which requires promiscuous mode doesn’t work. I can set promiscuous mode with the command:

nsxdp-cli vswitch l2sec set

But this has to be done on each ESXi host in the cluster and I would like to avoid having to do that.

Hello,

As a first post in the communities, I’d like to submit a case that I’ve been unable to achieve with good enough results to release to customers.

We’re trying to implement access to our file systems on DFS-NameSpaces through Content Gateway service on the UAG.

We want to map both Personal and Admin repositories to our users using DFS-N technology.

Content setup :

Repo Type : Network Share

Link : fqdn.domain.comDFS-NFolder{CustomAttribute1}{EnrollmentUser}

Content Gateway : UAG CG

All the DCs have the same DFS-N page set up for all locations as well as the information of all other DCs. We have opened the roads from our UAGs to both all DCs and all the file servers actually hosting the files. The FW opening were done on ports 139 (for legacy) and 445 (for SMB protocol). We have 0 package dropped on any port from our UAGs to destinations targets during the whole process.

When accessing a DFS-N Page, user will be redirected depending on the physical location he’s tagged. We’re using the {CustomAttribute1} to fetch from AD the location of users. This dynamic field in our setup is what enables the DCs to understand where the connection “comes from” and emulate the location of the user so the request is properly resolved to redirect the user to the file server which is hosting their files.

We know the DFS-N works because we can see we’re properly redirected to the actual file server, where the operations launched from Content on iOS client will complete most of the times. The issue is the latency of treatment of the requests. For instance, when downloading a file, the time between DOWNLOAD_INIT_REQ and DOWNLOAD_INIT_RESP is what is plumbing the performances of this. Once the DOWNLOAD_INIT_REQ has been treated, then the file, whether it’s a 10 ko file or a 200 mo file will download at full speed.

This is because the connection will reach out to several DCs before receiving the information.

From the wireshark traces, we could demonstrate that the connection to the different DCs is sequential and goes bouncing from DC to DC until a certain condition (see below) is fulfilled. In that case, the DC matching the conditions will properly return the path to files.

The conditions I’m talking about is about the “path” “alt path” and “node” values found in the FSCTL_DFS_GET_REFFERALS response of the wireshark traces.

A DC will successfully return file server connection information if path / alt path / node have the same value, matching the hostname of the interrogated DC. In that case, we will see indeed the redirection happening to the actual file server and the request being processed.

The behavior when hoping from DC to DC shows that the conditions path / alt path always match DC’s hostname but the node points out to the next hop. We can then see the UAG calling out to this node value.

Mapping the folder as a UNC path works perfectly fine, we access at once the end file server hosting actual data. Then again, in this case, the DFS-N redirection does not happen as we point out directly to the actual file server.

Authentication is not the issue here, we tried mapping an admin folder using my account’s credential and the latency/behavior is still present.

In all traced tests we did, we could not find any pattern that could explain the behavior. Sometimes there are a couple of hops before finding a DC that would match the conditions and return the proper file server to interrogate. Other times we have DC bouncing that goes around a globe and even some DCs which are interrogated 2 / 3 times and still forwarding the connection.

If any of you successfully implemented DFS-N protocol or encountered same kind of issues, I’ll be glad to hear from you.

Thanks,

Anton