Link to home
Start Free TrialLog in
Avatar of snowdog_2112
snowdog_2112Flag for United States of America

asked on

server 2003 - routes getting added to routing table - no rras

Server 2003 sp2 with Exchange 2003
RRAS is *not* configured

"Route print" shows hundres of routes with 255.255.255.255 netmask, all with gateway to my internet gateway.  When I delete the routes, they start coming back.

My default gateway points to a different router (into an mpls cloud wan to my other locations).

HELP!?!?!
Avatar of Netman66
Netman66
Flag of Canada image

It's likely picking them up out of the cloud.

If you tracert them do they end up out there?

If you have RIP Listener installed then you can remove it using Add/Remove>Windows Components>Networking Service> and uncheck RIP Listener.
Avatar of snowdog_2112

ASKER

There is no RIP listener in Win 2003 Server.  Unless I'm missing it...
netman66 - I am sure my server is listening to RIP traffic coming from the Internet router, but I don't now *HOW* it's listening - there's nothing on 520/udp in a "netstat -anb".  As mentioned, RRAS is not running.  There are no unknown services that would be doing anything RIP-wise.

The problem is that it's adding RIP routes with netmask 255.255.255.255 for hosts on the "internal WAN" (a private MPLS cloud to other locations in the company).  But those routes to the remote locations all have the gateway of the Internet connection - so it's not even the right route.

That's where I'm stumped.
So, in Add/Remove Programs>Windows Components>Network Services there is no RIP Listener?

I'll fire up a guest at home and take a look.

Is this Windows Server 2003 (not R2)?  at what SP level?

server 2003 r2 sp2

No RIP listener in add/rem programs-->windows components-->network services.

I checked a few other win 2003 servers - same thing: no RIP listener.
I'm home now.  I'll fire up a VM and see what I can see.

Ok.....

No RIP listener - that's in 2008.  It's in RRAS instead.

Open a command prompt.
Type in: netsh routing ip rip dump
Press enter.

Please post the screen output.

# ----------------------------------
# RIP configuration
# ----------------------------------
pushd routing ip rip
uninstall


popd
# End of RIP configuration
It's getting more and more weird.  ANother 2003 server on the same LAN is showing the same behavior.  I RDP'd into this second server, and I've got a /32 route in the routing table for the source IP of my RDP connection.

the netsh routing ip rip dump
on server #2 is the same as I pasted above from server #1.

I've not seen this on other servers.
Ok, well RIP isn't this issue.

Without looking at this myself, I have no idea what's causing this.

If you can post the output of this command, it may help:

netsh routing ip dump

Here's the output.  The router discovery section looks curious to me, bt I confess ignorance on this output.

# IP Configuration
pushd routing ip
reset
set loglevel error
add preferenceforprotocol proto=LOCAL preflevel=1
add preferenceforprotocol proto=STATIC preflevel=3
add preferenceforprotocol proto=NONDOD preflevel=5
add preferenceforprotocol proto=AUTOSTATIC preflevel=7
add preferenceforprotocol proto=NetMgmt preflevel=10
add preferenceforprotocol proto=OSPF preflevel=110
add preferenceforprotocol proto=RIP preflevel=120
add interface name="Local Area Connection 7" state=enable
set filter name="Local Area Connection 7" fragcheck=disable
add interface name="Internal" state=enable
set filter name="Internal" fragcheck=disable
add interface name="Loopback" state=enable
set filter name="Loopback" fragcheck=disable
popd
# End of IP configuration



# ----------------------------------
# DNS Proxy configuration            
# ----------------------------------
pushd routing ip dnsproxy
uninstall


popd
# End of DNS proxy configuration



# ----------------------------------
# IGMP Configuration                
# ----------------------------------
pushd routing ip igmp
uninstall


popd
# End of IGMP configuration



# ----------------------------------
# NAT configuration                  
# ----------------------------------
pushd routing ip nat
uninstall


popd




# ----------------------------------
# OSPF configuration                
# ----------------------------------

pushd routing ip ospf
uninstall

popd
# End of OSPF configuration




# ----------------------------------
# DHCP Relay Agent configuration    
# ----------------------------------
pushd routing ip relay
uninstall


popd
# End of DHCP Relay configuration



# ----------------------------------
# RIP configuration                  
# ----------------------------------
pushd routing ip rip
uninstall


popd
# End of RIP configuration



# ----------------------------------
# Router Discovery Configuration    
# ----------------------------------
pushd routing ip routerdiscovery
uninstall
add interface name="Local Area Connection 7" disc=disable minint=7 maxint=10 life=30 level=0
add interface name="Internal" disc=disable minint=7 maxint=10 life=30 level=0
add interface name="Loopback" disc=disable minint=7 maxint=10 life=30 level=0


popd


# ----------------------------------
# DHCP Allocator Configuration      
# ----------------------------------
pushd routing ip autodhcp
uninstall


popd
# End of DHCP Allocator Configuration


It shows that Local Area Connection 7 and Internal are both active - do you have both enabled?
Are they both connected to the same network or different ones?

If Internal is your primary NIC then you should make sure it's at the top of the binding order.

Please provide an ipconfig /all and a route print.  Attach them as text files if you want.




Only LAN 7 is active.  Nothing else shows in the network properties.  The "Internal" is probably legacy from when the box was  physical server (it's been p2v'd).

ipconfig:
H:\>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : ex03
   Primary Dns Suffix  . . . . . . . : mydomain.com
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : mydomain.com

Ethernet adapter Local Area Connection 7:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Citrix XenServer PV Ethernet Adapter
   Physical Address. . . . . . . . . : BE-12-EB-BC-D8-3F
   DHCP Enabled. . . . . . . . . . . : No
   IP Address. . . . . . . . . . . . : 192.168.1.254
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IP Address. . . . . . . . . . . . : 192.168.1.250
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.1.1
   DNS Servers . . . . . . . . . . . : 192.168.1.30
                                       192.168.1.31
   Primary WINS Server . . . . . . . : 192.168.1.30
   Secondary WINS Server . . . . . . : 192.168.1.31

H:\>


A "route print" is literally hundreds of entries, all with /32 netmask.  I believe they are coming from the Internet gateway firewall, since the IP's are only the external mail filtering service and one remote branch which is accessible over a VPN tunnel through that firewall.

I did a registry search, and the interface "Internal" only comes up in the key:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Interfaces

Again, this is *not* a RRAS server.  

Weird...
If you go into Device Manager and to View>Show Hidden devices, is it there?  I would make best effort to remove that because it might be part of the issue.

I see nothing in the netsh other than that rogue interface that suggests there is anything out of place.

Are there any proprietary services running that are leftovers from the physical server?  I know we have a lot of uninstalling to do when we P2V an HP server since there are plenty of HP-specific services and drivers running that won't play nice in ESX.

No "Internal" adapter in hidden devices.

Showing hidden devices, the network adapters lists several WAN Miniport adapters - one each for IP, L2TP, Network Monitor, PPPOE, and PPTP.  Again, this looks suspiciously like RRAS is running, but I even went so far as to enable RRAS just to disable it again.

I compared this to another (working) server, and see the same thing, so that appears to be "normal" behavior

Can I delete the entry from Remote Access in the reg, or will that break it further?
More info: the routes I am getting are all coming from incoming SMTP connections (it's an Exchange server).  I don't think it's related to Exchange, since the *only* inbound connections allowed from Internet are SMTP.  I am also seeing routes like 192.168.3.24/24 and 192.168.3.72/24, both of which are *workstations* in a remote location which also connect through the same firewall from which I am getting the SMTP/internet routes.

*Stumped*
Other than that phantom adapter, there is no harm having all those routes.  Since Exchange is running on this box, it may simply be normal behaviour.  I don't have access to our Exchange box at work or I would see if the same thing is happening on that one.

All those other adapters are normal - they're even on workstations.

No - it's not normal behavior.  I've checked several other Exch 03 boxes.  The problem is that it's adding routes for individual workstations, and I'm getting connectivity issues since the traffic is coming in over the inter-branch private WAN link and Exchange is sending it out the Internet connection.

Any other processes that may be adding routes to the local routing table?
ASKER CERTIFIED SOLUTION
Avatar of Netman66
Netman66
Flag of Canada image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
This server hasn't been "right in the head" since another tech did something to it a while ago.  I have scheduled a rebuild of the box this Friday.  As I mentioned, it's an Exchange 2003 server (no connection between Exch and the mysterious routes as far as I can tell).

I'll givbe you the points on your last comment for your perserverence, but I think it might just be a broken instance of Server 2003.

Thanks for your time!!!
Nothing points to infection, but we're rebuilding the box from ground up anyways.  This is the closest response to our resolution.  Sorry if it doesn't help anyone else with a simliar issue...