I need to understand low level lp subsystem

[Shannon Petry]

This question is in regards to trying to get printer clustering to work, or rather why I can not seem to get it working.

Scenario: 2 print servers, scripts to create devices/drivers on both machines simultaneously, an IP that floats from machine to machine. The printer devices and drivers are all configured with HP network printing (hpnpl).

The problem is that I can not seem to make this work.

The resolver works fine for the IP. Clients are configured to print to "lphost!queue". The IP for lphost is up, and resolvable. Normally "lphost" IP is configured on the primary server. In times of outage, I ifconfig the same IP onto the secondary.

The print queues are made identically. /opt/hpnpn/bin/addqueue --all args

When the primary server goes down, clients will not print to the secondary. They seem to still be getting status based on the primary. Clients list jobs that were queued before the primary server goes down.

Rebooting the clients (mix of Sun/HP/Linux) does not change this.

I'm missing something in my logic of how/what the low level print subsystem may be doing.

Thanks for any input you can provide.

[KapilRaj]

Try the following though i am not sure these will work.

1. Bounce the lpdaemon after u ifconfig'ed the ip on the secopndary server ..
2. Delete the ARP cache after u have ifconfig'ed the IP.

Regds,

Kaps

[Bill Hassell]

I'm not sure I understand what you have done with the 2 boxes. The IP address of the printer should not be affected by the HP-UX boxes. Any number of HP-UX or Windows boxes can print to the JetDirect printer regardless of changes on the box itself. All JetDirect printing is done with the program hpnpf...lp knows nothing about JetDirect printers. It is just scheduling the print jobs to use the lp interface script.

Now it sounds like you are trying to implement a computer cluster where if one HP-UX box fails, you are changing the IP address of the backup machine. Most likely you are running into arp cache issues where the IP address of the primary server is still active and ifconfg will not clear this cache in all the routers. arp -a shows the current cache for each system. The IP change will be effective for the different clients until the cache is updated with the secondary machine's MAC address.

[Shannon Petry]

I can say for sure that it is not the ARP cache, and not the printer IP issues causing a problem.

If I down the primary server "lphost" interface and bring "lphost" up on the secondary, the clients will still stat the primary.

I have flushed the ARP table on a client with no success. I have stopped and started the lpscheduler on the client, again with no success. I have rebooted a client to reset everything, again with no success.

Lets say I print from a client when the primary server is up. I get a job "lp-1".

When I down the primary server, clients of course stat the print server as down, but see the job lp-1.

Bringing up the "lphost" interface on the secondary server does not help either error. A client (not the one who originally submitted the job lp-1) can be completely rebooted, and on boot will still know about the job "lp-1" and say that "lphost" is not responding. Yet it can ping, telnet, etc... to lphost.

It seems like something is being broadcast, or cached in an un-documented fashion for the lp sub-system, yet this occurs on Sun and HP clients.

lphost resolves as an IP on a virtual interface which is up on the primary print server, but can be brought up on the secondary if the primary is down.

Thanks for the replies.