MS Print servers

Hi there,

 

I'm also fighting with MS print servers behind the BIG-IPs.

 

Based on the two Threads here in the Forum we configured nPath as described and also configured a loopback on the print servers with the VS IP-address. Also the two mentioned Registry tweaks were implemented.

 

But we still only get the listing working, nothing more. With setting the Metric for the loopback to 2 nothing was working, also ping monitoring from the LB to the print server was red then. That's why we removed it again.

 

Basically I'm also wondering why nPath routing is necessary at all. Normally nPath routing will only be used if you have a huge amount of outgoing server traffic, which should not go through the BIG-IP (to save resources and internal throughput). From a technical point of view nPath or having SNAT enabled should be the same, only difference with SNAT you have one additional hop for the response.

 

So can someone explain, why nPath is technical required for MS print servers? And does anyone has an additional idea, why it's not working for me? Btw. the result, that only listing is working is the same using nPath or SNAT.

 

Thank you!

 

 

Ciao Stefan :)

 

Stefan,

 

 

Post your config and I'll compare to my working setup. Do you have the service port set to 0? My configuration is based off a lot of trial and error and a little less understanding. It does work though. I've been serving ~700 queues for a little over 2 years with multiple gigabytes of traffic going through the VIP every day.

 

 

Chris

Hi Chris,

as I'm only responsible for the Loadbalancer I can only provide this config (I hope the server guy has done his job correctly as well, he mentioned that he want's to test some additional things these days, but didn't get any feedback yet):

virtual mltprtp01 {
   destination 10.10.10.10:any
   translate address disable
   profile fastL4_print_profile
   pool printer_cluster_mltprtp01
   vlans Productie enable
}
pool printer_cluster_mltprtp01 {
   action on svcdown reselect
   monitor all check_mltprtp01_tcp_445
   member 10.10.10.20:any
   member 10.10.10.21:any
        
}
monitor check_mltprtp01_tcp_445 {
   defaults from tcp
   dest *:microsoft-ds
}
profile fastL4 fastL4_print_profile {
   defaults from fastL4
   tcp close timeout 51
   loose close enable
}

As you can see the VIP is in the same subnet as the printservers, but I hope this is not a problem.

Thank you for any additional ideas or information.

Ciao Stefan üôÇ

VIP in the same subnet shouldn't be an issue. Your config looks fine to me. I can remember having the same issue you are dealing with. I just can't remember the change that fixed it. If you can't see the windows config though, I'd just about guarantee that is where your problem is.

 

 

Chris

The way I remembered why npath routing is needed is because the packet capture showed that the F5 will NAT the IP address in the tcp header but not on the tcp data. TCP data still showed the virtual server address. So, when the request is sent to the print server with the virtual server address, the print server rejects it.

 

 

When you configure a loopback address on the print server which is the same as the virtual server address, the print server will accept the request because it knows that as a loopback address.

 

 

 

We had frequent issues with that design where the server group had to restart the services or the server but now it seems to be ok. Most of the problems were related to the config on the server side.

 

 

 

Meena

 

 

 

 

 

 

 

In the meanwhile I got feedback from the server guy and he got it working now.

 

He enabled "Client for MS networks" and "File and Printer Sharing" on the loopback adapter and printers can now be mapped.

 

This is maybe interesting for someone else.

 

Btw. he mentioned that the two Registry tweaks were only implemented on one print server and the other one is working fine as well. But maybe this depends on the OS of the print server. I don't know which version they are running.

 

Thx all for the great support here.

 

 

Ciao Stefan :)

 

No SNAT needed! The original client IP is preserved and the return traffic from the print server goes directly to the client. F5 just does the transparent load balancing.

Hi Meena,

my question was not if SNAT is technical required, but if it's also working with SNAT enabled.

As I mentioned in my previous post, MS printing service has nothing to do with nPath routing. Based on the findings with the destinationIP in the TCP header and data part, the only requirement is the loopback adapter on the print servers.

I tested this with my server guy and I can confirm now, that it is still working with basic and default Loadbalancer settings, following is our current setup:

virtual mltprtp01 {
   destination 10.10.10.10:any
   snat automap
   translate service enable
   persist source_addr
   pool printer_cluster_mltprtp01
   vlans Productie enable
}

I also get confirmed from the server guy, that he is not using the two mentioned Registry tweaks. The print servers are running on w2k3.

Maybe this is helpful and interesting for someone else as well.

Ciao Stefan üôÇ

Stefan, that's good to know. What Big-IP version are you running? I never thought to test using a standard config after upgrading. I think I was on 9.4 for the original setup. Since you got it working with a standard config, are you going to test tcp optimized profiles and one connect?

 

 

Chris

Hi Chris,

 

the affected cluster is running on 9.3.1

 

Further tests and optimizations are not planned, but with the default fastL4 profile TCP optimization is already at its best.

 

 

Ciao Stefan :)