Книга: Linux Network Administrator Guide, Second Edition

Internal IPX Networks and Routing

Internal IPX Networks and Routing

IPX hosts with more than one IPX interface have a unique network/node address combination for each of their interfaces. To connect to such a host, you may use any of these network/node address combinations. When SAP advertizes services, it supplies the network/node address associated with the service that is offered. On hosts with multiple interfaces, this means that one of the interfaces must be chosen as the one to propagate; this is the function of the primary interface flag we talked about earlier. But this presents a problem: the route to this interface may not always be the optimal one, and if a network failure occurs that isolates that network from the rest of the network, the host will become unreachable even though there are other possible routes to the other interfaces. The other routes are never known to other hosts because they are never propagated, and the kernel has no way of knowing that it should choose another primary interface. To avoid this problem, a device was developed that allows an IPX host to be known by a single route-independent network/node address for the purposes of SAP propagation. This solves our problem because this new network/node address is reachable via all of the host interfaces, and is the one that is advertised by SAP.

To illustrate the problem and its solution, Figure 15.1 shows a server attached to two IPX networks. The first network has no internal network, but the second does. The host in diagram Figure 15.1 would choose one of its interfaces as its primary interface, let's assume 0000001a:0800000010aa, and that is what would be advertised as its service access point. This works well for hosts on the 0000001a network, but means that users on the 0000002c network will route via the network to reach that port, despite the server having a port directly on that network if they've discovered this server from the SAP broadcasts.

Figure 15.1: IPX internal network


Allowing such hosts to have a virtual network with virtual host addresses that are entirely a software construct solves this problem. This virtual network is best thought of as being inside the IPX host. The SAP information then needs only to be propagated for this virtual network/node address combination. This virtual network is known as an internal network. But how do other hosts know how to reach this internal network? Remote hosts route to the internal network via the directly connected networks of the host. This means that you see routing entries that refer to the internal network of hosts supporting multiple IPX interfaces. Those routes should choose the optimal route available at the time, and should one fail, the routing is automatically updated to the next best interface and route. In Figure 15.1, we've configured an internal IPX network of address 0x10000010 and used a host address of 00:00:00:00:00:01. It is this address that will be our primary interface and will be advertised via SAP. Our routing will reflect this network as being reachable via either of our real network ports, so hosts will always use the best network route to connect to our server.

To create this internal network, use the ipx_internal_net command included in Greg Page's IPX tools package. Again, a simple example demonstrates its use:

# ipx_internal_net add 10000010 000000000001

This command would create an IPX internal network with address 10000010 and a node address of 000000000001. The network address, just like any other IPX network address, must be unique on your network. The node address is completely arbitrary, as there will normally be only one node on the network. Each host may have only one IPX Internal Network, and if configured, the Internal Network will always be the primary network.

To delete an IPX Internal Network, use:

# ipx_internal_net del

An internal IPX network is of absolutely no use to you unless your host both provides a service and has more than one IPX interface active.

Оглавление книги


Генерация: 7.500. Запросов К БД/Cache: 3 / 1
поделиться
Вверх Вниз