Subject: Re: How can we block Novell 5.0 SLP multicast using only one RP?

From: "Jim Erwin" <[email-masked]>
Date: Fri, 04 Jun 1999 08:17:17 -0600

Steinar,

Isn't SLP neat?  It finds things, just like it's suppose to!  Unfortunately many companies want to put restrictions on their users by putting restrictions on SLP.

I understand your question to basically be: How can I configure my routers to restrict multicast SLP traffic similar to they way they used to restrict IPX SAP traffic?  That is a question that rightly needs to be directed to your router-specific technical support, since each router model may work differently.

I'll give you three ideas as to how to modify SLP rather than the routers.  But before you go with any of these ideas, ask youself what it is hurting to have the users see more than they used to.  Each of these ideas has a big negative with it.  It would be much better to get the routers to do their jobs, or leave things the way they are.

1. Change the SLP multicast radius.  The default (from RFC2165 is 32 hops).  This is a configurable parameter in workstations and servers.  NEGATIVE: You have to change the configuration of every workstation that you don't want to see too much.

2. Use a SLP Directory Agent.  This basically replaces the multicast traffic with unicast traffic to the DA.  NEGATIVE: Workstations still see all the services, they just unicast the to DA instead of multicast.

3. Use scopes.  If each organization had its own scope, it would ask for and receive only the services within its scope.  NEGATIVE: Ugh. If you don't need to use scopes for any other reason, then this is probably not a good reason to get into the complications that scopes can cause you.  You may end up having to configure each workstation and server with the scope to use, in which case it would be simpler to do #1.

In conclusion, your best approach is the one you are trying ― get the routers to do their job.  In your case, that's a Cisco-specific question.

--Jim Erwin
[email-masked]

>>> <[email-masked]> 6/3/99 14:19:51 >>>
Warning: This message is Cisco specific in parts.

I sent this originally to the [email-masked] list, but was
recommended to try the SVRLOC list instead.

We are starting to see some deployment of Novell 5.0, which uses SLP
(RFC 2165) and thus multicast addresses 224.0.1.22 and 224.0.1.35
(and port 427) for a lot of the functions previously done by IPX SAP
announcements. This seems to work rather well, but has the interesting
effect that people are suddenly starting to see servers that are very
far away topologically (outside their own organization). This is a bit
disconcerting to many since they are used to only seeing file servers,
printers etc. within their own organization.

We would like to control this, and thus need to limit the distribution
of traffic to 224.0.1.22 and 224.0.1.35. This has turned out to be more
difficult than we thought.

Our multicast infrastructure is based on PIM SM, with only one RP in
the whole AS. We thought we could use the "ip multicast boundary"
statement to limit the distribution of multicast traffic to 224.0.1.22
and 224.0.1.35. Unfortunately, this seems to work *only* on the router
with has the RP - adding this statement to other routers (for instance
between each organization and the backbone) seems to have no effect.
Also, since the multicast traffic *to* the RP is often encapsulated,
using normal access lists between each organization and the backbone
doesn't work.

Any ideas of how we could keep SLP announcements within the organization
while at the same time letting other multicast traffic be distributed
through the whole AS? (We know we can do this with multiple RPs, but we
would prefer to avoid the multiple RPs if we could.)

Steinar Haug, Nethelp consulting, [email-masked]

---

From: James Kempf <[email-masked]>
Date: Fri, 4 Jun 1999 11:18:32 -0700 (PDT)

>
>> Actually, these two solutions in tandem are *exactly* the way to solve the
>> problem. As I understand it, the problem seems to be that users are
>> seeing services they "shouldn't".
>
>Yes and no. If I simply wanted to stop users in organization A from
>seeing SLP announcements from organizations B, C, etc (ie. outside A),
>I can use a normal packet filter in organization A's border router, and
>filter out 224.0.1.22/ 224.0.1.35 from the *incoming* traffic.
>
>The problem is - I really don't want these announcements getting *out*
>from organizations B, C, etc to the global Internet in the first place. 
>And this is the hard problem (which cannot be solved by a normal packet
>filter), because this traffic is *tunneled* from organizations B, C etc
>to the Rendezvous Point (due to PIM-SM).
>

That's why the two solutions must be used *in tandem*. If a DA is 
deployed in organizations B and C, then UAs unicast their requests
to the DA, not multicast. Similarly, SAs register themselves with
DAs rather than waiting for the UAs to multicast requests. This
is an important scalablilty feature of SLP, that is necessary
in large networks. Unlike SAP in Netware 4.0, SAs don't do periodic
multicast or broadcast, so by installing DAs, you drastically
reduce the amount of multicast traffic, which is necessary in
large networks.

With the deployment of DAs, the only multicast going on is when
an SA or UA comes up and tries to find a DA, and when a DA puts
out a heartbeat. You can limit users in organizations A, B, and
C to DAs within their organizations if you use DHCP to configure
the UAs and SAs with their DA and scope when they come up (or,
alternatively, if you don't use DHCP, do each workstation by hand). 
That way, the users in organization A will only use DAs having
scope-A, and similarly with B and c.

If you're interested in more information about system administration
of SLP, you might want to check out "Service Location Protocol for
Enterprise Networks" by James Kempf and Pete St. Pierre (available
at Amazon, Barnes and Noble, etc.). The entire second half of the
book discusses deploying, configuring, and administering SLP networks.
The discussion is slanted towards generic SLPv2, but much of it
should apply to Netware 5's implementation of SLPv1 as well.

		jak