How to restrict cifs traffic to a specific interface on DD2500

Yes , can possible .

Create a separate interface with dedicated ports and use this interface for eithor CIFS or NFS .

Hope this clarifies your concern .

Sam

Interesting. Let me ask you this: I have configured an ifgroup with 4 onboard interfaces in it for Veeam DDBOST backups, and I configured 4 interfaces from an additional IO module in LACP for CIFS backups. I have assigned a virtual IP to the LACP for CIFS backups, and I have assigned each DDBOOST interface an individual IP. I have also created a DNS record for the CIFS interface, and entered it in the 'hosts' file on the backup host, to make sure that all the CIFS traffic goes to that CIFS LACP interface. I have mounted my DD CIFS share on the backup server using that DNS name which is associated with the LACP IP that I have configured for CIFS backups. In this case all my CIFS traffic will go via that LACP interface that I have configured on the DD and registered in DNS, won't it? It is not going to randomly grab the interfaces that I have assigned to an ifgroup, simply because that client is not allowed access to that ifgroup, is it?

$@m wrote: Yes , can possible . Create a separate interface with dedicated ports and use this interface for eithor CIFS or NFS . Hope this clarifies your concern . Sam

i have multiple interfaces with dedicated ports, all ports are servicing CIFS and NFS.  How do you recommend restricting which ones are providing CIFS and or NFS ?

i am trying to find this discussion we had maybe a year ago. We talked about how to use an ifgroup for DDBoost and how it would be load-balanced by using an LACP/DNS name inside of Veam/DDBoost plugin. DDBoost/Veam would point to the CIFS/LACP DNS name but upon connection would automatically jump to ifgroup. That's how it was described.

That is true, when you are using DDBOOST, from Veeam you connect to any interface on DD - even CIFS/LACP DNS name, but not the ones in the ifgroup, and from there DDBOOST protocol on Veeam picks up the ifgroup and sends all data to the interfaces that are in that ifgroup.

This is incorrect.  If you check the interfaces with nmap or other TCP port-checking tools, all interfaces reply with all services.  Checking the CIFS interfaces via Powershell clearly shows an IPC$ listener on each port.  There's nothing to prevent a CIFS client from connecting to - and using - any interface they can detect like this.

Even if I configure DNS name for the specific interface that I want to use for CIFS, and put it in the CIFS client hosts file, CIFS backups will go via any interface configured on DD?

i am not using ifgroups yet but if you specify CIFS or NFS to connect to specific DNS name/interface, it will do just that. CIFS/NFS will not bounce and start using ifgroups like DDBoos does.

In one of the examples above we are talking about 8 physical ports.

4x NIC's are in an LACP group with a single IP address, it resolves to the hostname and backups are started against it as the target NIC.

The other 4x NIC's have an IP address each, those IP's are added to an ifgroup for use by DDBoost.

(You do not need any name resolution for these).

When the CIFS backup starts, it won't ask about ifgroups because those are for DDBoost only and so the backup will stay on that LACP interface and balance based on network aggregation (ifgroups are DBoost software aggregation essentially).

When the DDBoost backup starts (via the LACP interface, AND assuming you didn't add it as an ifgroup member), it will ask about ifgroups, the DD will confirm it has 4 members (4 standalone NIC's) and tell the backup which one is least loaded and the backup will be moved to that IP/interface directly.

This will repeat with each new stream and cause the 4x NIC's to load equally - regardless of differing NIC speeds in those 4 members. If you lose a member (maybe a physical fault), it just won't get chosen and so will be ignored - leaving you with 3.

It's important that you have resilience for the initial connection or your backup will fail to start because it failed to get that initial connection and make your ifgroup pointless - so LACP is perfect but you can also setup a host-failover lookup (host file) to choose a different IP upon failure of the configured initial NIC/IP, in this way, you technically don't need any failover or aggregated interfaces on the DD but for CCR/AIR/replication you may still need/want it.

An important point here...

The interfaces (IP's!) in the ifgroup are not dedicated to the ifgroup(s), the are simply allocated/designated.

There is nothing to stop them being used by something else too but I would assume they would need to resolve and route in some way to be targeted.

If they are being used for something else and so are loaded up with other data, DDBoost/ifgroup member allocation will still take account of that 'load' and allocate the next ifgroup member to the next DDBoost save accordingly to try an balance their utilization equally.

The replication (MFR) network path between 2x DDR's for AIR-SLP/CCR etc.. often gets overlooked, ideally you would (in this case) specify a route to force it over the LACP path DD-2-DD.

Regards,

Jonathan