RPC Server Unavailable-another cause

  • Thread starter Thread starter Digital Doug
  • Start date Start date
D

Digital Doug

Just a note for those of you that cannot seem to get rid of the "RPC Server
Unavailable" message.

If for some reason, a system that gives the above message is multi-homed
then be aware that RPC is a little more finicky than Ping.

A system that is multi-homed will source the data stream with the ip address
that is directly connected to the def gateway.

The connection will be made to the destination, but if the destination is
behind a Nat router, it will see the source address (probably a registered
address) and route it out the Nat router (which now changes the original
source address). The RPC listener now sees a new ip address and refuses the
connection.

In my case (don't ask me why---a customer mandate) the customer multihomed a
box with a reg ip address and the def gtwy pointing to the egress Cisco
router. He then kept an int 172.17.1.x address. This box is also a W2K DC
and had been working.

At this point a ping from this box to another DC on the 172.17.2.x network
worked as did a ping in the opposite direction.

I then noticed that the DNS console on the 172.17.2.x DC box could manage
the DNS Server on the 172.17.1.x network, but not the other way around.

The fix was a route -p 172.17.2.x mask 255.255.255.0 172.17.1.254 on the DC
on the 172.17.1.x network. This forced the source address to be on the
172.17.1.x network thus avoiding the previous routing path.


--
Sincerely Yours,

Doug Stigall
Digital Machines Corp.
Houston, Tx 77082

(281) 870-8649
dougsatnetdashfixdotcom
 
Thank you for sharing that with us.

Bob Lin, MS-MVP, MCSE & CNE
Networking, Internet, Routing, VPN Troubleshooting on http://www.ChicagoTech.net
How to Setup Windows, Network, VPN & Remote Access on http://www.HowToNetworking.com
Just a note for those of you that cannot seem to get rid of the "RPC Server
Unavailable" message.

If for some reason, a system that gives the above message is multi-homed
then be aware that RPC is a little more finicky than Ping.

A system that is multi-homed will source the data stream with the ip address
that is directly connected to the def gateway.

The connection will be made to the destination, but if the destination is
behind a Nat router, it will see the source address (probably a registered
address) and route it out the Nat router (which now changes the original
source address). The RPC listener now sees a new ip address and refuses the
connection.

In my case (don't ask me why---a customer mandate) the customer multihomed a
box with a reg ip address and the def gtwy pointing to the egress Cisco
router. He then kept an int 172.17.1.x address. This box is also a W2K DC
and had been working.

At this point a ping from this box to another DC on the 172.17.2.x network
worked as did a ping in the opposite direction.

I then noticed that the DNS console on the 172.17.2.x DC box could manage
the DNS Server on the 172.17.1.x network, but not the other way around.

The fix was a route -p 172.17.2.x mask 255.255.255.0 172.17.1.254 on the DC
on the 172.17.1.x network. This forced the source address to be on the
172.17.1.x network thus avoiding the previous routing path.


--
Sincerely Yours,

Doug Stigall
Digital Machines Corp.
Houston, Tx 77082

(281) 870-8649
dougsatnetdashfixdotcom
 
The connection will be made to the destination, but if the destination is
behind a Nat router, it will see the source address (probably a registered
address) and route it out the Nat router (which now changes the original
source address). The RPC listener now sees a new ip address and refuses
the connection.
Click to expand...
The perils of multihoming! I've had numerous problems like this on
multihomed servers. A little knowledge of routing will go a long way here,
as your solution testifies. I've had no problems getting RPC to go over a
NAT router, but if there are two routes - one direct and one NAT - and the
direct route only exists on one end - that should cause some real confusion.
Ping and ARP are both pretty straightforward protocols and both have some
problems. ARP, for instance, doesn't care whether or not an ARP broadcast
was sent if it gets a reply. This is how masquerading "man-in-the-middle"
software, like ettercap are able to work on a switched network. It listens
for ARP broadcasts, learns its way around, then sends replys to both ends of
a connection using it's own MAC address, reads the packets, and sends them
on the way with neither end being the wiser. The computers at both ends
dutfully place the MAC entry in their ARP caches, even though they didn''t
do a broadcast request!

....kurt
 
Back
Top