[tforum] Novell SLP and multicast

Joe breen Joe.Breen@utah.edu
Fri, 1 Mar 2002 16:28:35 -0700 (MST)

I wrote this note up some months ago for solving a particular problem.
I thought this info might also be of use to others.  Enjoy.

	Univ. of Utah Center for High Performance Computing

*** Note some urls may wrap ***


An entity such as a school, department or college wants to have the
freedom of deploying multicast and Novell 5.x without repercussions to
itself or to others.  In order to accomplish this objective, an entity
will want to ensure that it has the proper Access Control List filters in
place when using multicast and Novell 5.x Service Location Protocol.
Without the proper filters at the edge router, another entity can bring up
a Novell server and possibly "grab" the clients of the unsuspecting
original entity.  An entity will also want to ensure that the clients have
proper multicast scoping/multicast radius installed on their individual


Novell 5.x uses multicast by default in its Service Location Protocol.
Detrimental network situations can occur if two entities, i.e. schools,
university departments or colleges, communicate via multicast trees and
bring up Novell 5.x servers without proper filtering at the border
routers.  An example of a detrimental network situation is a new Novell
server that comes on-line and the clients of another department choose the
new server rather than the hard-coded server in their configs.  The Univ.
of Utah has seen this situation at least twice, even though the clients
had static configurations for their respective Service Agents and
Directory Agents.  By employing proper multicast radius scoping on the
clients and proper multicast Access Control Lists on the edge routers of
the entity, each entity should be able to employ the power of multicast
without disrupting others or having others disrupt the activities of the


Novell uses the Service Locator Protocol (SLP) to provide a "plug and
play" environment without the broadcast liabilities of the Service
Adverisement Protocol (SAP) or IPX RIP.  The SLP allows Novell 5.x servers
to deploy in an "IP-only" environment but still learn about servers,
printers and other Novell services.  SLP uses multicast group
in IP (01005E000116 for OSI layer 2 Ethernet multicast addressing) to
distribute the advertisements.  SLP uses multicast group for
requests for Directory Agents and for responses by Directory Agents.  

See the following for more detail on how Novell's SLP works and how it
uses multicast:

* What is SLP, Service Location Protocol? --

* SLP Overview --
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10014788.htm for
more information

* How SLP uses Multicasting --

An example of a detrimental network situation: 

A client comes online and sends a multicast request for a particular
service such as file services.  Even though the client might have the
correct server hard-coded in its config files and the correct order for
searching, i.e. hard-coded and then multicast, the client sends a
multicast request first.  A Service Agent (SA) on a server in a different
department (provided multicast routes across the campus backbone) will see
the request on the multicast group and will respond via unicast
that it has the available service.  The client then sends a unicast
request to the SA on the fileserver for details of the Novell Directory
Service (NDS) service.  The SA on the server will send all the attributes
of the filesharing service to the client via a unicast packet.  The client
then authenticates into the NDS tree via TCP/IP for the filesharing

See the following bug report for a similar (though not the same) example
of the above problem:

* When a DA is statically configured on the workstation, Windows MAP
command and "Find Computer" operation produces SLP requests to the
multicast address instead of first sending a unicast to the DA. 
  * Reference:

An example of how to protect oneself and other neighboring entities:

An entity should take steps to protect itself from its neighbors and to
protect its neighbors from itself.  Two general methods exist to help
protect entities and their neighbors

* Limit the multicast radius/scope of the clients
  * Decide how many router hops clients' service requests should propagate
before the service
    * In Advanced Settings of the properties of the client, set the SLP
Multicast Radius to define the number of subnets that the multicast should
cross in search of DAs or SAs (default is 32).
      * Reference:

* Create Access Control lists on the border router of an entity to block
multicast groups and from entering or exiting the
  * A cisco router might have the following lines in its access control
    * Access list definition
      ! access-list 1 deny
      ! access-list 1 permit
    * Interface definition
      ! interface ethernet 0
	! ip multicast boundary 1
    * Reference:
    * Reference:
    * Reference:

  * A cisco router could also include the following lines in its access
control lists to prevent any non-multicast SLP info from crossing the
    * Access list definition
      ! access-list 198 deny tcp 427 any any
      ! access-list 198 deny udp 427 any any
    * Reference: SLP Design and Implementation --

Other useful references for SLP are:

* SLP Design and Implementation --
* SLP Terms and Configuration Reference --
* Configuring SLP for the Netware client --
* Configuring SLP for the server --