Novell is now a part of Micro Focus

Understanding SCMD Mechanics and Processes

Articles and Tips: article

STEVE KESLER
Consultant
Novell Consulting

01 Aug 1999


One of the most useful yet misunderstood features of NetWare 5 is the Server Compatibility Mode Driver (SCMD). This AppNote shines some light on the inner workings of SCMD in the context of three implementation scenarios.

Introduction

With the introduction of IP-based NetWare Core Protocols (NCP) in conjunction with NetWare 5, there needed to be a way to provide upgrade compatibility for legacy IPX applications and devices, while allowing only IP to travel the network. In earlier versions of NetWare, the add-on product NetWare/IP provided similar functionality by encapsulating IPX in IP datagrams. In NetWare 5, the functionality of NetWare/IP has been replaced with NCP over IP, and legacy support of IPX is accomplished through the Server Compatibility Mode Driver (SCMD.NLM).

SCMD is a tool designed to help customers in the process of upgrading from IPX to IP. As with any network upgrade project, proper planning, design, and configuration is essential to the success of the project.

This AppNote provides information related to the inner workings of SCMD.NLM that was introduced with the release of NetWare 5. Throughout this AppNote, three configuration options will be discussed along with various design and implementation considerations. These configurations include:

  • Migration Agent in Backbone Support Mode

  • Migration Agent with CMD Servers

  • Migration Agent with IP/CMD Clients

Readers should have a good understanding of IPX/IP encapsulation, Routing Information Protocol (RIP), Service Advertising Protocol (SAP), and NetWare Link State Protocol (NLSP) concepts. Additional resources on these and other related topics are listed at the end of this AppNote.

Terminology

Before launching into the explanation of the configuration options, it might be helpful to review some basic terms.

NetWare Core Protocol over IP: Traditional NCPs have been dependent on the IPX stack. When NetWare 5 shipped, it was capable of NCP communication over IPX or TCP (port 524). Although NCP over IP and SCMD are both based on TCP/IP, neither of the two protocols is capable of direct communication with each other. They operate over different TCP/UDP ports and offer different services.

Service Location Protocol (SLP): A new service discovery protocol (RFC 2165) introduced with NetWare 5, SLP provides the mechanism for discovering networked IP devices and services. SLP is a data store where network devices register their names and services for other network services or users to query. This provides a means to locate and resolve a required network service name and address. SLP operates over UDP port 427.

Migration Agent (MA): A term that is used when SCMD.NLM is configured to provide access between IPX and IP/CMD servers or clients. In addition, multiple MAs can be deployed to provide connectivity between two disconnected IPX networks across an IP only backbone.

MA with IP Backbone Support

The term "backbone support" is an early definition of SCMD which defines an IP-only backbone connecting two or more IPX networks. As shown in Figure 1, the backbone support option is used to connect two IPX networks across an IP-only backbone.

Figure 1: Connecting two IPX networks across an IP-only backbone.

All IPX data between the two IPX networks is transferred as IPX data encapsulated in UDP 2645 data packets. This provides a reduced cost model by only having to support one protocol on the WAN, while still allowing IPX networks to communicate throughout the enterprise.

When NetWare 5 originally shipped, the version of SCMD.NLM included the command line switches "/BS", "/G", or "/MA". Depending on which switch was used, the operation of SCMD.NLM changed. For example, the /BS switch enabled the MA as a "Backbone Support" server capable of encapsulating IPX in IP, then passing the packet across a WAN link to another Backbone Support MA, which would in turn unencapsulate the IPX packet and put it back on the wire as IPX.

As of NetWare 5 Support Pack 1, the /G, /BS, and /MA switches have been combined, and the functionality of SCMD is no longer differentiated by the command line switches. When a new MA is loaded (using either /G or /BS), MAs are auto-configured with Backbone Support already included. To enable the backbone support functionality between MAs, each MA must have the same CMD network number, and NetWare Link State Protocol (NLSP) must be loaded with RIP/SAP compatibility enabled.

MA Backbone Support Requirements and Operation

MAs can be configured in a number of different modes to provide scalability and support for any network upgrade path. MAs in Backbone Support mode can be configured with one or more adapters. If you are using a single adapter, it will need IPX and IP bound to it. All IPX traffic will be filtered at the router, thus allowing only IP traffic across the backbone.

As mentioned previously, MAs that will be configured to provide backbone support require NLSP. This is enabled on the MA by loading the INETCFG utility and selecting Protocols | IPX | NLSP with RIP/SAP Compatibility, as shown in Figure 2.

Figure 2: Configuring NLSP for backbone support.

NLSP is a link state protocol that CMD uses in the communication between MAs. Traditional RIP and SAP use a distance vector method for determining the best path to a network device. Both RIP and SAP use a broadcast-based technology where routes and services are advertised to other devices on the network. In large networks, this can become "chatty" on the wire and consume unnecessary bandwidth. NLSP removes the regular interval RIP and SAP broadcast requirements for the MAs. NLSP depends on Link State Packets (LSPs) that contain routing and service information. These packets are based on NLSP Hello packets that define MA "neighbor" systems to build an entire database picture of the network (similar to the Open Shortest Path First (OSPF) protocol in TCP/IP).

This AppNote does not attempt to provide a detailed view of the mechanics of NLSP, but more of an understanding of how SCMD in Backbone Support mode uses NLSP in the building of route tables. Additional resources for NLSP mechanics can be found at the end of this AppNote.

When SCMD is first loaded, it needs to be able to discover other similar MAs that have the same CMD network number. The CMD network number is a virtual IPX network number that is used by the MA's IPXRTR.NLM in the routing of IPX traffic through the MA. All MAs that will need to communicate with each other require the same CMD network number. By default, the CMD network number is FFFFFFFD. This can be changed to any valid hexadecimal value through the command line or through MONITOR.NLM.

Methods of Discovery

There are two methods of discovery that can be used by the MA in the discovery of other MAs in the Backbone Support mode configuration. These two methods are the Service Location Protocol (SLP) and the MA-MA communication protocol.

SLP Discovery Mode. SLP is a mechanism that was introduced with NetWare 5 for the discovery of TCP/IP-based network services. Network services register their services with SLP, and can also query available services from SLP over UDP port 427. When SCMD is loaded from the server console in Backbone Support mode (/G, /BS, or /MA), an SLP registration process takes place. New Universal Resource Locators (URLs) are created with service types of sapsrv.novell and mgw.novell. The sapsrv.novell URLs map IPX SAP types to IP addresses. The mgw.novell URLs identify other MAs on the network.

For example, assume that you are configuring the first MA on the network via the following command:

LOAD SCMD /MA

When this NLM is loaded with the /MA switch on a NetWare 5 server, the following service entries are added to SLP:

mgw.novell:__192_168_20_1 sapsrv_novell_054e3244:000000000001:0451_0004_c0a81401_c0a81400 sapsrv_novell_054e3244:000000000001:0640_0278_c0a81401_c0a81400 sapsrv_novell_054e3244:000000000001:0007_026B_c0a81401_c0a81400

Figure 3 is a detailed view of the information contained within a sapsrv.novell object. From this information, you can see how SCMD correlates legacy IPX information with IP information to be able to locate IPX-dependent services.

Figure 3: Information contained within a sapsrv.novell object.

Each sapsrv.novell service registered with SLP has a default lifetime of 60 minutes. This provides a mechanism, in the event the MA goes down without deregistering, for the service to time out and not be returned in future SLP replies.

Once all of the SLP service registrations have completed, the MA will send an SLP attribute request asking for all other network service URLs that are of type service:mgw.novell with a virtual IPX network address equal to its own (FFFFFFFD) at the cumulative intervals of 30, 60, 120, 240, and 480 seconds, and then once every 5 minutes.

SLP replies with all service:mgw.novell objects with a matching VIPX network number but that do not have expired "time to live" values. The MA enables NLSP communication between its router (IPXRTR) and each of the other MAs associated with all mgw.novell URLs. Once this communication is enabled, the NLSP routers exchange LAN Hello packets and initiate communication. By default, NLSP Hello packets are sent every 20 seconds, with a multiplier of 3. During the exchange of Hello packets with the other MAs, each MA responds with its list of neighbors which is used to build an adjacency and forwarding database for the routing of CMD traffic.

Every 5 minutes, the User Agent on the MA will send an SLP attribute request to SLP for the URLs of mgw.novell objects. This provides an updated list of MAs on the network, which in turn NLSP uses to build its link state tables.

If SCMD is unloaded on an MA, or if the MA is shut down gracefully, it will deregister from SLP so that it is not included in the next SLP attribute query response for all other MAs. NLSP will be notified through non-receipt of destined LAN Hello packets, purge the MA from its routing tables, and start the process to notify other MAs. However, if an MA goes down without deregistering its services from SLP, the SLP URL would be marked as expired after the 60 minute Time To Live. NLSP would still be able to mark the MA as unreachable and available for purge through normal NLSP Hello packet transactions.

As you can see, SLP is used in conjunction with SCMD and NLSP. The initial list is a SLP service request query sent to SLP from the MA. The returned list of other MAs is then used by NLSP to begin building the routing and service adjacency and forwarding databases.

MA-MA Communication Protocol (No SLP Option). The second method to configure MAs in Backbone Support mode is without the use of SLP. Known as the MA-MA Communication Protocol, this provides a method for discovery of other MAs without the use of SLP.

The initialization phase is similar to that described above; however, rather than sending an attribute request to SLP for URLs of service type mgw.novell with matching CMD network numbers, a static list is used. Each MA is statically configured with a list of up to five other MAs. Each MA will contact the other MAs in its list, update the receiving MA with its information, and request all other MAs that the receiving MA knows of. The MA enables NLSP communication between its router (IPXRTR) and each of the other MAs associated with all mgw.novell URLs. Once this communication is enabled, the NLSP routers exchange LAN Hello packets and initiate communication.

This contact between MAs is accomplished once every 10 minutes by default rather than once every 5 minutes as when configured to use SLP. This value is configurable through the MA Communication Time variable. Once the MA Communication Time interval is reached, the MA follows the same process and requests new MAs that might have come up since the last interval. With this approach, MA convergence might take 10 to 20 minutes, depending on the current interval countdown for each MA.

To configure an MA in Backbone Support mode without SLP, the following configuration options are required:

SET NO SLP OPTION = ON

This turns off SLP only for the discovery of other MAs by SCMD. SLP is still loaded and can reply to all other network service requests.

SET MA COMMUNICATION TIME = 10

This is the default value that each MA uses to contact the other MAs in its Migration Agent List.

SET MIGRATION AGENT LIST = xxx.xxx.yyy.zz; xxx.xxx.yyy.zzz/

The MA List is limited to five IP addresses of other MAs on the network, delimited by a semicolon ( ; ) and terminated with a slash ( / ).

Note: SCMD SET parameters are accessible through MONITOR.NLM under Server Parameters | Communication or directly through the console. NetWare 5 uses a registry to store environment SET parameters. These values are not visible through MONITOR.NLM until SCMD has initially been loaded. Any time a SCMD SET parameter is modified, SCMD must be unloaded and reloaded for the changes to take effect.

Filtering

As IPX networks got larger, there was a need to filter various SAPs and RIPs. In the past, this was generally handled at the infrastructure (router) level or on individual servers through FILTCFG.NLM. When using FILTCFG.NLM, all filtering must be defined for a specific network interface.

The current version of SCMD.NLM (version 1.69) does not provide an interface for which filtering can be applied. This means that all services that the MA knows about will be forwarded to all other MAs in the network. However, this can be managed by applying filters in either of two configurations: filters on IPX servers or filters on MAs.

Filters on IPX Servers. Figure 4 shows a implementation of MAs with backbone support forming a Pure IP backbone while still allowing connectivity to the IPX-only servers on segments 2 and 3.

Figure 4: Filtering RIP and SAP packets on IPX servers.

If a specific SAP type (for example, RCONSOLE 0x107) should not be visible to users on segments 2 and 3, one possible alternative would be to set up filters on all of the servers on segment 1 so that the MA does not learn of this service, and thus advertise it to the other MAs. By applying filters to all of the IPX servers on the MA's segment, you can control what services the MA knows about, and thus what information it propagates.

Filters on MAs. An easier method of applying filtering in a backbone support network is through the use of filters on the individual MAs, as shown in Figure 5.

Figure 5: Using filters on individual MAs in a backbone support network.

By default, all RIP/SAP packets are allowed to be passed onto the backbone support network. Each MA learns of all services in the network, but can be configured to filter what services are propagated onto each IPX network that it supports. This provides much greater granularity and flexibility by allowing specific services to be managed at each MA.

Design Considerations

When using SLP, it is important to take into consideration the design and configuration being used. Here are some factors to consider.

Configuring for a Large Number of Servers. By default, SLP is enabled in Multicast mode on group address 224.0.1.22 for each NetWare 5 server. This configuration is generally acceptable for up to 30 servers on the network. If the number of servers exceeds this amount, or if Multicast is not enabled, a Directory Agent (DA) and SLP Scopes should be included in the design and architecture.

In large networks, SLP scalability is managed through the use of Scopes and Directory Agents. At regular intervals, MAs in Backbone Support mode that use SLP discovery send queries to SLP which include the Scope defined at the individual server through the SET SLP SCOPE LIST=" " parameter. For MAs to be visible to each other through SLP, each Scope in which an MA belongs must be able to be queried by every other MA in the backbone support network. This can be managed by setting a common Scope for registering mgw.novell services through the SYS:ETC/SLP.CFG, or by configuring each MA so that all SLP queries are sent to multiple Scopes and Directory Agents. This can result in additional bandwidth requirements, and should therefore be analyzed and designed in conjunction with an SLP strategy.

Modifying MA Communication Time. To speed convergence, the MA Communication Time can be modified to a smaller value. This will increase the interval that the MA uses to contact other MAs in maintaining its current list of other MAs. The MA Communication Time must be the same on all MAs that will be communicating via the MA-MA communication protocol.

Having a Consistent Method of Discovery. SCMD does not support a mixed SLP/MA-MA Communication Protocol discovery configuration. The chosen method of discovery must be consistent across all MAs.

Using Static MAs. To speed convergence and reduce management overhead, five core MAs can be selected and configured as the static MAs for all other MAs. Since the MA uses this list to send and receive MA information about itself and other MAs, this will increase the learned converged list of all MAs that is used by NLSP. It is not necessary to chain different MAs together to achieve global visibility of MAs. As long as the list is consistent on all MAs, they will discover all other MAs and be able to provide an accurate list to NLSP.

Tuning NLSP Metrics. Low WAN speed or heavily utilized links might require analysis and tuning of NLSP metrics to compensate for NLSP Hello packet latency. As indicated earlier, by default NLSP sends a Hello packet every 20 seconds to its immediate neighbors, with a multiplier of 3. The sending NLSP router in turn expects a Hello packet acknowledgment at the interval of 20 seconds multiplied by 3 (20 x 3 = 60 seconds). If the NLSP router does not receive an acknowledgement within the calculated value (60 seconds), it will mark the route as Unreachable. (This can be seen through IPXCON under NLSP Information | Routers.) Although marked as Unreachable, the route is not immediately purged from the NLSP database.

To compensate for slow links or high utilization segments, several configuration options are available:

  • Increment the Holding Time Multiplier. This will increase the window time size for acknowledgment of the Hello packets. This value is changed through the following options in INETCFG: IPX | Expert Configuration Options | NLSP Convergence Rate (you must first change from Default to Manual to allow changes) | NLSP Convergence Rate Configuration | Holding Time Multiplier (see Figure 6).

    Figure 6: Setting the Holding Time Multiplier in INETCFG.

  • Split the Virtual IPX network into multiple segments. This reduces the number of MAs and communication requirements in each VIPX ring, but still allows the transfer of IPX information between disconnected IPX segments (see Figure 7).

    Figure 7: Splitting the Virual IPX network into multiple segments.

  • The current version of SCMD (version 1.69) supports only one VIPX per MA. Future versions of SCMD may allow the binding of multiple VIPXs per MA.

MA with CMD Servers

Another way that SCMD can be used in an upgrade to a Pure IP environment is through the use of SCMD as a tool to support legacy IPX applications on IP servers. When SCMD is loaded without any command line switches, it provides the ability to execute legacy IPX applications that would not be possible on an IP-only server.

For example, say that you migrated a server to NetWare 5 with TCP/IP, but you still want legacy IPX clients to control the new NetWare 5 server remotely via RCONSOLE.NLM. Figure 8 demonstrates how the RCONSOLE service is executed on a CMD server. When the application makes a call to the IPX stack, CMD intercepts the request before it is put on the wire, and encapsulates the IPX packet in a UDP 2645 datagram.

Figure 8: RCONSOLE, an IPX application, communicates on a Pure IP network through CMD.

To provide support for this, you simply load SCMD.NLM in the CMD Server mode of operation. CMD Servers depend on MAs to exchange information in the advertisement of services/routes, and to provide a gateway to the IPX network segments for data traffic. When a new CMD server is added to the network, it first needs to register its services with SLP, and then discover an MA that it will use for all of its communications.

CMD Server Startup Process

CMD servers can either use SLP or a static list in the discovery of a Migration Agent. Detailed below is the startup process of a new CMD server in both configurations.

CMD Server Using SLP to Discover an MA. Once SCMD is loaded on the CMD Server, all services on the new CMD Server that have a SAP type (0x004=NCP Server, 0x278=If holds replica, 0x107=if RCONSOLE is loaded, and so on) are registered with SLP. As detailed earlier, each legacy SAP type on the new CMD server registers a sapsrv.novell object. All services that have a SAP type on the CMD server are registered in SLP under the Scope defined in the SLP Scope List variable, or Unscoped if no variable exists.

Once the new CMD Server registers its services with SLP, it will send either a Scoped or Unscoped SLP service request to SLP for mgw.novell objects that match its CMD network number. SLP will return a dataset that matches the defined query values for mgw.novell objects.

Upon receipt, the new CMD server will give preference to any mgw.novell object that has a subnet which matches its own for its connection. By giving preference to any mgw.novell object with a matching subnet, it provides a means to minimize the distance to its servicing MA. If the returned list does not have a mgw.novell object with a matching subnet, it will select a MA from the list randomly.

CMD Server Using a Static List to Discover an MA. The process for a new CMD Server to connect to a MA is similar in that each CMD server needs a qualified list of MAs that it can connect with. The CMD server can be configured to use a static list by setting the IP addresses of various MAs through the Preferred Migration Agent List variable.

Although being set through a static list, there is still a requirement for the CMD server to be able to query SLP for mgw.novell objects. The CMD server will still send an SLP attribute request to SLP for mgw.novell objects that match its own CMD network address, and then perform a comparison with the returned dataset and the list set through the Preferred Migration Agent List variable. The purpose of the compare between the static list in conjunction with the SLP dataset is to validate the static list with registered MAs.

If the first value in the static list matches an entry in the dataset from SLP, it will use that value to connect to the MA. If the values do not match, it will go to the second entry, and so on until it reaches the end of the list. If none of the values in the static list match the data returned from the SLP service request, the CMD server will pick one MA from the list returned by SLP.

Updating Service and Route Information

Once the new CMD server has completed the MA discovery process and identified the MA it will connect with, it initiates a connection on TCP port 2302. (TCP is a connection-oriented protocol that provides reliable delivery of data.) Once the connection is established, it will remain constant between the CMD server and the MA unless it is reset or broken. Upon successful connection to the MA, the CMD server will request a copy of the service and routing tables from the MA to populate its own tables.

After the connection has been established and the CMD server has been updated with the service and route information, the MA will still need to forward new SAP and RIP changes from the IPX segments to the CMD segments, and vice versa. The MA receives regular 60-second SAP updates since IPX is bound the interface to support the IPX segments. Upon receipt of a new SAP that is not in the MA's service table, a bindery change event is triggered on the MA which forces the MA to push out the new SAP to each connected CMD Server.

A full refresh of the MA's service and routing tables is accomplished only if the CMD Server's TCP connection is reset or broken. Each MA maintains a TCP connection list of all connected CMD servers, which can be seen through TCPCON or through the SCMD /STAT console command.

RIP updates received from the IPX network do not trigger a bindery change event when they are added to the MA's routing tables. To provide RIP updates to connected CMD Servers, a RIP cache is maintained on the MA which schedules a compare to cache every 60 seconds. When a change is detected, the new RIP is forwarded to each of the connected CMD servers on TCP port 2302.

The same requirement exists for CMD servers to provide any new service information to nodes on the IPX segments through the MA. As mentioned previously, once a new IPX service is added to a CMD server, a sapsrv.novell object is registered with SLP with the associated SAP type. The MA does a SLP service request every 3 minutes for sapsrv.novell objects. If any new services have been registered by CMD servers since the last query, the MA will populate its own service and route tables with the new sapsrv.novell object, which in turn will produce a SAP made visible to all nodes on the IPX segment, with a route of the MA to reach the service.

In addition to TCP port 2302, the CMD server and MA use UDP port 2645 in the transmission of data packets. These packets make up the actual encapsulated IPX data in a IP datagram.

Design Considerations

In developing a strategy for CMD server deployment, it is important to understand the strategy and use of SLP in your environment.

Server Visibility. CMD servers will need to query SLP whether in static or full SLP discovery mode to find an MA to establish a session. If the Scopes that the MA and the CMD register with are different, the CMD server will not be able to make a successful connection with the MA. In addition, to provide service and route updates from CMD servers to IPX nodes, the MA will need visibility to all relevant sapsrv.novell objects. If the MA is not able to query and receive the sapsrv.novell objects, they will not be made visible to the nodes on the IPX segments.

Only CMD servers register legacy IPX SAP information with SLP. NetWare 3.x/4.x servers or any other devices that use IPX SAP will not register their services with SLP unless they are also functioning as a CMD Server or MA.

IP Filtering. If IP filtering is enabled on the network, the following ports should not be restricted:

  • TCP 2302 (used for MA/CMD service/route information)

  • UDP 2645 (used for MA/CMD data communications)

  • TCP/UDP 427 (used by SLP)

  • TCP 524 (used by NCP)

MA with IP/CMD Clients

The last configuration that could be used during an upgrade is the use of IP/CMD clients. The IP/CMD client provides a means for a workstation to connect to legacy IPX devices through an MA. Slightly different than the MA/CMD server communications, all MA/IP-CMD workstation traffic, data, and service/route information is encapsulated inside of UDP 2645 packets (see Figure 9.

Figure 9: The IP/CMD client connects to IPX devices through an MA.

The IP/CMD client can be configured to prefer IP or IPX as the initial protocol. If the client is configured to prefer IP, it will attempt to make an IP connection first by querying SLP, and then make a request to the MA on UDP 2645 if it cannot make an IP connection. The IP/CMD client will need to be configured with the IP address or fully qualified DNS name for the MA that it should communicate with. This can be done through static configuration, DHCP, or multicast.

A new feature introduced with NetWare 5 Service Pack 2 is the ability for CMD servers to provide RIP/SAP broadcast emulation. This allows an IP/CMD client to be configured to use any CMD server as a proxy to the MA. The IP/CMD client will connect with the CMD server to get its route and service information over UDP 2645, and then use the CMD server as a proxy to the MA. This provides a means for IP/CMD clients to get route and service information without having to go directly to the MA. This reduces bandwidth overhead in situations where the MA is located across a WAN link, and client would previously need to cross to retrieve service information.

In developing an upgrade path to an IP-only infrastructure, fault tolerance of the MAs becomes necessary since they take on a critical role in delivery of data and services between the IP/CMD and IPX networks. Fault tolerance is managed by configuring secondary and tertiary MAs on the IP/CMD client. On boot-up, the client will use the first MA which is configured. In the event that the primary MA goes down, the client will roll to the next MA in its list, and restart the data transmission.

Design Considerations

DHCP is a valuable tool in the configuration and management of IP/CMD clients. When a fault tolerant solution is used, DHCP can be used to load balance the MA-IP/CMD client configurations based on subnets. Various third-party DHCP servers do not correctly support the new DHCP tags associated with the Pure-IP options. This can be managed by using a fully qualified DNS name in place of the multiple IP addresses as long as the DNS server supports round robin.

Troubleshooting Tools

Various tools and utilities can help you better understand and troubleshoot configuration issues related to SCMD. Some of these include the combination of a packet analyzer, IPXCON, TCPCON, INETCFG, and various console commands.

For example, IPXCON is an NLM that provides a complete list of services and configuration settings used in conjunction with INETCFG. As defined earlier, MAs are dependent on NLSP with RIP/SAP compatibility to exchange route and service information. When NLSP is enabled on an MA and HELLO packets are exchanged, each MA will show up in IPXCON as a NLSP router. To see this, select NLSP Information | Neighbors. Each MA under the NLSP Neighbors section will show its current state (Up, Initializing, or Down). The NLSP router state for each MA can be used to help understand the current status of the source MA to each target MA.

Other tools that have been useful in deploying SCMD include the following console commands:

DISPLAY SLP SERVICES mgw.novell

This will return a list of MAs that are registered with SLP.

DISPLAY SLP ATTRIBUTES

This will return a list of attributes for a specified MA.

Conclusion

This AppNote has provided information on the inner workings of SCMD and the design considerations that should be taken into account when planning an upgrade to NetWare 5 using SCMD. Using SCMD provides a means to move from an IPX to IP infrastructure, while providing support for legacy IPX applications. Moving from IPX to IP should be planned and coordinated with all parties that have an interest in the existing IP infrastructure (DHCP, DNS, WAN, SLP, and so on).

Additional information on related topics can be found in the following AppNotes:

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates