Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 761
  • Last Modified:

Blocking off segment NCP traffic causes netware authentication to slow to 60 seconds

We have a Netware 6.0 server with 4 NICs (,, and

there are a few 4 NIC windows 2000 server boxes running SQL and other jobs, but we do not have any windows DNS (on all 4 segments for speed reasons)

All inter-segment routing is done through our firewall (internet access as well)

NCP traffic is blocked segment to segment by the firewall to prevent clients from authenticating on a different segment and therefore loosing connection if the firewall is taken off line.

Before we blocked the NCP traffic, users authenticated quickly (albeit off segment).

Once the firewall rule blocked port 524 between the 4 segments, it takes almost EXACTLY 60 seconds to log in (using different NW client versions)

The firewall logs show that NCP traffic was blocked from Client WS to the NW Server's OTHER 3 segments (for a total of about 55 seconds).

It appears that the client somehow knows about the other 3 NICs on the Netware server, but, since NCP is blocked, it can not authenticate.

My questions :  
  How can the client know about the other segments of the netware server if I have blocked NCP?
     Is it possible that one of the other 4 NIC server boxes is passing some traffic but not the NCP?
     Is there some other port I need to block on the firewall to prevent discovery of the other segments?

  How can I block this knowledge or force the client only to look at it's own segment's Netware NIC?

Note: SLP had no effect on this problem.  It seems to be that the knowledge of other segments on the server cause the client to try them first... No idea why!


  • 4
  • 4
  • 3
  • +1
2 Solutions
Do you have DNS anywhere?  You don't mention...

How do you have the Novell client32 configured for login - do you have only the tree and perhaps context filled in but the server field blank, are you using the server name, or what?  Have you tried putting the server IP for that segment in the server field in the Novell client?

Does the firewall act as the default route for the NetWare server?  Is routing disabled on the NetWare server?  Remember, NetWare is an excellent multiprotocol router.

What are the various client versions you're using?
OK, NetWare v6.0...any Support Packs? Latest for NetWare v6.0 is Support Pack 5, and there have been some Post-SP5 patches, including TCP, SLP and eDirectory updates.

The client workstations can "hear about" things on other segments through SLP. That is, the SLP DA may list services that exist on the blocked segments.

You only have one NetWare server?
How is SLP configured?You are using a DA ,right?
On a multihomed server only one interface and ipaddress is bound to be the DA.
You can choose which interface board and ip address during the setup.
Otherwise the first interface bound becomes the DA.

Do you have the workstations configured to use a static DA(unicast) and not broadcast looking for one?

Try the following commands at the server console(one at a time) and post the info from the screens.

display slp da

display slp services

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

Sorry,I need to clear up the broadcast thing.

If the UA's are not configured for unicast ,they will multicast,not broadcast(my mistake).

Most routers will not forward broadcast packets,multicast is OK.
RGNCMExpertAuthor Commented:
Thanks for the quick responses...

Update: NW6 SP 4 Service Pack 4

Display slp da  returns:
    Total Active: 0  Total Inactive :0

display slp services returns lots of  refrecnces to other NICs and our other backup server.

The workstations are no longer configured for SLP since they may be moved off their current segment at any time, so we cant hard code an agent address.

The login speed seems to be a little better if we use the IP address for Tree/Server name in the login client, but we can't hard code for each workstation.

Novell Client 4.90 SP2 (but we have some older clients too... the login problem exists on ALL clients)

We have no DNS server on the network.  Our firewall is the Internet DNS proxy

How can I tell if we are running the router?  I don't belive it is running... but i could be mistaken.

My main goal here is to prevent the clients from knowing about the other NICs in the server, to reduce intra-segment traffic.



Is the server only connecting to the 4 segments through the router?  If so, blocking NCP would be a problem.  If the NetWare NIC's each connect directly to the segment it is supposed to service, then blocking NCP at the router shouldn't affect login time.

It doesn't sound like you have an SLP DA set up, which isn't a big deal in a small network, but  since SLP is not normally broadcast, but multicast or unicast, if you don't specify an SLP  server in the client, on startup it will send out a broadcast asking for a response from an SLP server and will take whichever one gets back to it first.

Do you use DHCP to hand out the IP addresses for the segments?  If so, are you using NetWare's DHCP or Windoze DHCP.  The reason I ask is, DHCP can hand out specific server information for a managed address pool, but the Windows-provided DHCP service is very limited in the DHCP service types it is preconfigured to hand out, forcing you to jump through hoops to have it give certain info to the client, while the NetWare DHCP service handles a whole lot more service types.  I know for a fact that the Windows DHCP server doesn't list SLP service type, for example.  It might not be able to hand out NetWare servers either.

The more info the client PC has on how to find the NetWare services, the better the login experience.
You have no DA configured.
Because of this, the clients’ multicast looking for services (printers, servers and such).
You are also crossing subnets and because of this, you will have issues with how things are being found.
When IPX is run, services are found using RIP/SAP and a routing table is built on what services are available using SAP. (A hop count)

When you go to a pure IP setting, services are found in a number of different ways (WINS broadcasts on a 'doze network) and Novell uses SLP to advertise services.

My advice to you is as follows:
Set up at least one DA on the LAN (two if you have a 2nd NW box).
Check this out:


Make sure that on the multihomed box that only one IP address is bound to the DA, exclude all other cards and IP addresses.
If you have a 2nd NW box, you can configure a 2nd DA for redundancy.
Configure the clients to use a static DA’s; this will cut down on network traffic.

>My main goal here is to prevent the clients from knowing about the other NICs in the server, to reduce intra-segment traffic.

So let me get this right, the reason you are using multiple NIC's is to off load traffic from other network segments?
Switches do this by default.
So, I don't see the reasoning behind the segmented approach.
If you aren't running IPX and hubs, this configuration to me, seems unnecessary.
The only reason I see for doing this is if you don't want to go to gigabit server links and you have SO much normal traffic that it would overwhelm a single 100Mb NIC or are using dumb hubs for your infrastructure and need to reduce your collision domains.  

As pbm554 indicated, if you're running all IP in a switched network, you don't need separate LAN segments to control traffic, and Ethernet collisions are almost eliminated because each switch poirt is its own colliision domain.
RGNCMExpertAuthor Commented:
To clarify a few things

DHCP is provided by our firewall (not a doze box or NW)

Pure IP (no IPX) on NW.

the NICs in the NW server are 1G.  All switches in our network, no hubs.

We use 4 segments to try to balance the load by keeping the number of pc's even.

I realize that we are doing this a little differently than most people do... We do most things differently in our company... It's just who we are ( old school (white hat, hardware & software) hackers from the 80's ).

It looks like we just need to block the multicast from getting off segment...
and verify that the NW server is not routing any traffic.

Is there any way to do this?  


Provided you use INETCFG for your NetWare networking config, you can go into Protocols, TCP/IP and right near the top it will have IP packet forwarding.  I believe it defaults to Enabled ("Router").  It should be set for Disabled ("End Node").
That might work if none of the switches on your network are connected to any others in any way shape or form and it is NW that is passing routing info on your network.
Remember that any router on the network will pass multicast traffic unless configured to do otherwise.

There are easy ways and hard ways to configure and setup load balancing , traffic management,and routing using NW and your infractruture.
A best practices approach would to be use the load balancing built into the NIC's along with an SLP services DA.
It sounds as if you are using a Checkpoint firewall for DHCP and it does do SLP when handing out IP addresses.

From what I can see,you are trying to do a poor man's VLAN.

Let the components of your network do what each one does best.
Let the switches segment the traffic, use SLP to discover services and let the NIC's do your load balancing.

To be blunt,you are doing things the hard way.

Anyway,excuse me while I step down off the pulpit.
Enough preaching for one day(it is Friday,not Sunday you know). :)
RGNCMExpertAuthor Commented:
pgm554 and ShineOn:

thanks for the help... Yes, it would be better to let each device do what it does best... but I cant just take down the network to make the changes....

I think the info you provided will let me work this out...

Thanks again!



Featured Post

Receive 1:1 tech help

Solve your biggest tech problems alongside global tech experts with 1:1 help.

  • 4
  • 4
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now