![[previous]](../../../graphics/l_arrow.gif){kind=icon}
![[next]](../../../graphics/r_arrow.gif){kind=icon}
This section describes the X25 Service.
A fully meshed X.25 topology is a topology where each node on a network is directly connected to all other nodes on the network. Each node is connected to the other nodes through a virtual circuit, and each virtual circuit has a DTE associated with it. Figure 377 shows an example of a fully meshed X.25 topology.
Figure 377 
Fully Meshed X.25 Topology
The topology in Figure 377 consists of NETBuilder II bridge/routers. Through the established virtual circuits, bridge/router A is connected to bridge/routers B, C, and D; bridge/router B is connected to bridge/routers A, C, and D; and so on.
A nonmeshed X.25 topology is a topology where each node on a network is not necessarily connected to all other nodes on the network. Figure 378 shows an example of a nonmeshed X.25 topology.
Figure 378 
Nonmeshed X.25 Topology
The topology in Figure 378 consists of NETBuilder II bridge/routers. Through the established virtual circuits, bridge/router A is connected to bridge/routers B, C, and D. bridge/routers B, C, and D are connected to bridge/router A only, but not to one another.
Two possible solutions exist to work around the lack of connectivity between bridge/routers B, C, and D. If you are routing IP-RIP, IPX, or AppleTalk, these protocols offer the next-hop split horizon feature. In IP-RIP, this feature is enabled when -RIPIP CONTrol is set to NonMesh. In IPX, it is enabled by manually configuring neighbors. In AppleTalk, next-hop split horizon is configured by adding static mappings to the address mapping table.
For example, if you are routing IP-RIP, use the SETDefault !<port> -RIPIP CONTrol = NonMesh syntax. If you are routing IPX, you can configure bridge/routers B, C, and D as neighbors using the PolicyControl and AdvToNeighbor parameters in the -NRIP and SAP Services. If routing AppleTalk, you can add the address of bridge/routers B, C, and D to an address mapping table. After taking such action, bridge/router A, the root bridge/router, learns available routes from each neighbor and then updates each neighbor with available routes other than that particular neighbor's own routes. Even though bridge/routers B, C, and D are not directly connected to one another, they can still learn of routes other than their own through bridge/router A. For more information on next-hop split horizon, see the Configuring AppleTalk Routing chapter, the Configuring IP Routing chapter, and the Configuring IPX Routing chapter.
Another solution in a topology where there is a lack of connectivity is to create virtual ports. Virtual ports are supported by bridging and all routing protocols over an X.25 network. You must use virtual ports in a Boundary Routing over X.25 topology and when bridging or routing DECnet, IP-OSPF, VINES, or XNS over X.25 in a partially meshed or nonmeshed topology. Using virtual ports in all other bridging or routing scenarios over an X.25 network is optional.
For information on the number of virtual ports supported per platform, see Table 11 in the Configuring Advanced Ports and Paths chapter.
Virtual ports allow the creation of multiple logical ports on one path. Each virtual circuit attaches a separate logical network. Figure 379 shows a Boundary Routing over X.25 topology where virtual ports are configured. In this topology, even though the SuperStack II NETBuilder boundary routers are not directly connected to one another, information about each of their networks can still be propagated through the NETBuilder II bridge/router.
Figure 379 
Using Virtual Ports in a Boundary Routing Over X.25 Topology
For more information on virtual ports and Boundary Routing over X.25, see the Configuring Advanced Ports and Paths chapter and the Configuring Boundary Routing System Architecture chapter, respectively.
A partially meshed X.25 topology is a topology where some nodes on a network are directly connected to all other nodes on the network (as in a fully meshed topology) and other nodes are not (as in a nonmeshed topology). Figure 380 shows an example of a partially meshed X.25 topology.
Figure 380 
Partially Meshed X.25 Topology
The topology in Figure 380 is composed of four NETBuilder II bridge/routers. Through the established virtual circuits, bridge/routers A, B, and C are connected to one another, but bridge/router D is connected to bridge/router A only.
The lack of connectivity between bridge/routers B, C, and D can be worked around using the same two solutions discussed earlier in this section that apply to nonmeshed topologies.
In addition to the basic X.25 functionality that is supported by all PDNs, another feature called facilities is optionally supported on some PDNs. Use of facilities is controlled at subscription time or on a call-by-call basis, depending on the facility.
The bridge/router supports the following facilities: