![[previous]](../../../graphics/l_arrow.gif){kind=icon}
![[next]](../../../graphics/r_arrow.gif){kind=icon}
This section decribes the concept of virtual ports, how to use virtual ports (text deleted), and how to configure virtual ports. For information on virtual port concepts, see "Concepts of Virtual Ports" next. For information on using virtual ports with wide area technologies, see "Virtual Ports over Frame Relay, ATM DXI, and X.25." For information on using virtual ports for virtual LANs (VLANs) and Token ring In Fast Ethernet (TIFE), see "Virtual Ports for 802.1Q Virtual LANs." For information on how to configure virtual ports, see "Configuring Virtual Ports."
You can configure multiple logical ports over one physical path on the platforms listed in Table 11. To configure multiple ports over one path, you create new logical interfaces called virtual ports. A virtual port is an object you define using software and associate with a nonvirtual port called the parent port (see Figure 8). A virtual port functions in the same way as a nonvirtual port, that is, as a logical interface that represents a connection to a network. The virtual port and its parent port share most of their properties. However, a virtual port and its parent port can be referenced separately by port-oriented software features, such as route policy and packet filtering, and can be distinguished by distinct wide area addresses.
Figure 8 
Parent Port and Virtual Port
A virtual port can be connected to a network through a path providing a Frame Relay, ATM, or X.25 virtual circuit, or an SMDS Subscriber Network Interface (SNI). A connection can also be made using PPP with dial-up features to achieve multidestination dialing (modem pooling and WAN Extender virtual path pooling).
Table 11 lists the bridge/routers that support virtual ports and the maximum number of virtual ports that can be configured on each bridge/router. There is no per-path limit, except that the total number of virtual ports configured on all paths cannot exceed the maximum for the bridge/router.
| 1
These platforms can act as a central node in a Boundary Routing topology.
|
Virtual ports function in the same way as nonvirtual ports. Table 12 provides information on topologies that require virtual ports and the node in the topology on which the virtual ports should be created.
The sample Boundary Routing topology in Figure 9 demonstrates the use of virtual ports. This topology shows a NETBuilder II bridge/router with two paths labeled path 1 and path 2. Path 1 is an Ethernet interface. Path 2 is connected to a Frame Relay network that interconnects multiple local area networks through two SuperStack II boundary routers. Two virtual ports have been created on path 2. Each virtual port is a logical interface that represents a connection to one of the remote local area networks.
Figure 9 
Topology Using Virtual Ports
Virtual ports are numbered Vn, where n is a number from 1 through 28, which is the maximum supported on a SuperStack II bridge/router.
In Figure 10 virtual ports are configured on the wide area ports of two SuperStack II bridge/routers on both sides of an X.25 network. Each bridge/router has a virtual port defined over the path directly connected to the X.25 network. On SuperStack II bridge/router #1, virtual port V1 is defined over path 2. On SuperStack II bridge/router #2, virtual port V2 is defined over path 3.
Figure 10 
Virtual Ports on a SuperStack II Bridge/Router
Virtual ports are used differently for different WAN media technologies. This section describes practical applications of virtual ports for different WAN media. For more information, see the following sections:
Frame Relay, ATM DXI, and X.25 are peer-to-peer protocols that connect two nodes on the network. Boundary Routing and bridging, Internet Protocol-Open Shortest Path First (IP-OSPF), DECnet IV, VINES, and Xerox Network Systems (XNS) require virtual ports because they do not provide a method for dealing with Frame Relay, ATM DXI, or X.25 topologies where bridge/routers are not directly connected to all others (full mesh). With Boundary Routing system architecture, when you create a virtual port over a particular path, each remote network attached to the Frame Relay, ATM DXI, or X.25 cloud is treated as a separate network.
Internet Protocol-Routing Information Protocol (IP-RIP), IP-Integrated Intermediate System-to-Intermediate System (IIS-IS) (NETBuilder II bridge/router only), Internetwork Packet Exchange (IPX), Intermediate System-to-Intermediate System (IS-IS), DECnet V, and AppleTalk can operate over partially meshed or nonmeshed Frame Relay, ATM DXI, or X.25 topologies without the use of virtual ports. The next-hop split horizon feature in IP-RIP, IPX, and AppleTalk allows communication between bridge/routers that are not directly connected to one another. To configure next-hop split horizon for these routing protocols, you must have a list of neighbors, which can be dynamically generated or manually configured in IP-RIP.
In IPX, you must manually configure neighbors for broadcast multiaccess (BMA) networks. For nonbroadcast multiaccess (NBMA) networks, for example, X.25 and Frame Relay, you can configure dynamic neighbor learning through the CONTrol parameter in the NRIP, SAP, and NLSP Services.
In AppleTalk, next-hop split horizon is configured by adding static mappings to the address mapping table.
You do not need to further configure IP-Integrated IS-IS and IS-IS to run over partially meshed or nonmeshed Frame Relay, ATM DXI, or X.25 topologies; you only need to configure neighbors.
Although it is not necessary to define virtual ports on IP-RIP, IPX, or AppleTalk routers in partially meshed or nonmeshed Frame Relay, ATM DXI, or X.25 topologies, virtual ports do provide the following additional benefits:
If you want your NETBuilder II bridge/router or SuperStack II bridge/router to act as an Open System Interconnection (OSI) router in a Frame Relay, ATM DXI, or X.25 topology, you do not need to create virtual ports.
Table 13 lists each bridging and routing protocol and the technique you must use to deal with the lack of connectivity in partially meshed and nonmeshed Frame Relay, ATM DXI, and X.25 topologies.
| 1
When configuring this protocol and another protocol that requires virtual ports over the same path, use
virtual ports.
2 The SuperStack II bridge/router does not support this protocol.
|
In an ATM environment, virtual ports are required in fully meshed and partially meshed topologies when bridging and routing. Nonmeshed topologies are supported, but they are not recommended.
Each ATM virtual port has a unique media access control (MAC) address.
PPP virtual ports differ from Frame Relay, ATM, X.25, and SMDS virtual ports in the following ways:
Frame Relay, ATM, X.25, and SMDS virtual ports are always associated with a particular path.
Frame Relay, ATM, X.25, and SMDS virtual ports inherit the attributes of the path over which they are defined. For more information, see "Parent Ports for X.25, PPP, Frame Relay, ATM and SMDS" later in this chapter.
Frame Relay, ATM, X.25, and SMDS virtual ports cannot be used with dial-up related parameters.
You can use virtual ports and WAN Extender virtual paths in a PPP environment to provide dial pooling at the central site router. With dial pooling, a set of dynamic paths is unbound from their default ports and waits in the dial pool for an incoming call. When a call is received, the dynamic path that answers is assigned to a virtual port, which is standing by with the appropriate configuration information for the calling network. Because not all sites using a dial pool call the central site at the same time, it is possible to share a small group of paths with a larger group of sites. Each site that can potentially call into the dial pool has its own virtual port defined, so there are usually more virtual ports configured for the dial pool than dynamic paths assigned to it. For more information about WAN Extender virtual paths, see "Virtual Paths (WAN Extender only)" later in this chapter.
Unlike Frame Relay, ATM, and X.25, SMDS provides a connection-less wide area network that also has multicast delivery capability, giving it LAN-like characteristics. Each attachment point to the SMDS network, the Subscriber Network Interface (SNI), can be assigned up to 16 individual addresses by the SMDS service provider. These addresses can be used to distinguish up to 16 distinct virtual SMDS ports over the same SNI. Unlike virtual ports for Frame Relay, ATM, or X.25, which connect to a single remote device, each virtual port in an SMDS environment connects to a distinct group of fully meshed devices. This connection allows the creation of a hierarchical, partially meshed structure that can exceed the SMDS address-screen-imposed limitation of 128 addresses in an SMDS network.
SMDS virtual ports provide additional points of control for configuring network and routing protocols, and for selectively applying port-level features such as filtering, route policy control, and route aggregation. Boundary Routing is not supported over SMDS.
When you configure an X.25, Frame Relay, ATM, or SMDS virtual port, it inherits the attributes of the path over which it is defined. It also inherits some of the attributes of its parent port. There are two kinds of inheritance: one is the inherited default for all VCs, and the other is when the port picks up the value of the parent port.
For PPP dial virtual ports, no parent port exists because the path was unbound from its port and placed into the dynamic dial path pool.
Unlike Frame Relay, ATM, X.25, and SMDS virtual ports, which are always associated with a particular path, PPP virtual ports can potentially use any path in the dynamic dial path pool. PPP virtual ports also can be used with dial-up related parameters.
For example, if you create a Frame Relay, ATM, X.25, or SMDS virtual port associated with a wide area port, the virtual port inherits port attributes from the following sources:
The parameters in this list do apply to PPP virtual ports, such as SysCallerID virtual ports.
When you add a WAN Extender to a NETBuilder II bridge/router, it provides virtual paths that can be dynamically bound to a NETBuilder II physical or virtual port if PPP is running over the port. The NETBuilder II bridge/router can currently support up to 75 virtual paths. Because virtual paths are used by ports running PPP, multiple paths can be bound to a single port using the MultiLink Protocol.
Virtual paths can be used for WAN Extender ISDN and switch-56 dial-up lines and for WAN Extender T1 and E1 permanent leased channelized connections.
WAN Extender virtual paths are not bound to a port until a connection is established. While they are not bound, the virtual paths that are not configured to be used for channelized leased lines can serve as dynamic paths in a dial-up path pool. The paths in the dial-up path pool are used for calls going through a port running PPP.
On ISDN or switch-56 dial-up lines, a virtual path binds to a port when an outgoing call is started or when an incoming call is received by the port. The virtual path goes back into the dial pool after the call is ended.
Like other dynamic paths, specific virtual paths in the dial-up pool can be dynamically bound to a port for bandwidth-on-demand or disaster recovery. After the demand and recovery is complete, the virtual paths unbind from their port or ports and return to the dial pool.
For channelized connections, such as T1 and E1, the virtual path binds to the port when the NETBuilder bridge/router and the WAN Extender synchronize with each other and the PPP negotiation is completed. The virtual paths used by channelized connections do not increase the number of paths in the dial pool after the call is ended.
This section explains how to configure virtual ports on your bridge/router. See Table 11 to determine whether your platform supports virtual ports.
Before setting up virtual ports for the ISDN interface on SuperStack II bridge/routers with an ISDN interface, you must decide how you want to use the ISDN interface.
In a virtual LAN environment, stations on a single physical bridged LAN are divided into logical groups, and are only allowed to communicate with other stations in that group. Each such subdivsion is a virtual LAN (VLAN). The NETBuilder bridge/router implements standard IEEE 802.1Q VLANs and uses virtual ports to attach to VLANs.
When you create a VLAN virtual port, you specify the port that attaches to the physical LAN, and the 802.1Q vlan identifier. Routing protocols can then use this virtual port to route traffic for the member stations of that VLAN.
Each virtual port on a VLAN uses the same MAC addresses as the physical port.
Bridging between ports or virtual ports on the same physical LAN is not supported on the NETBuilder bridge/router.
A special use of VLANs as defined in 802.1Q is to tunnel token ring traffic over ethernet LANs. Other 3Com products see this as "Token ring In Fast Ethernet", or TIFE. This type of traffic is useful in environments that are converting from token ring to ethernet LANs, or that support both.
The NETbuilder bridge/router supports TIFE traffic with VLAN tunnel vitual ports. Although these virtual ports connect to an Ethernet, they support source routing just like token ring ports.
Before configuring virtual ports, make sure that the owner of the wide area parent port is set appropriately.
To set up virtual ports, follow these steps:
1 . Create a virtual port for each remote network that is attached to a Frame Relay, X.25, SMDS, ATM, or ISDN cloud, or that is running the PPP Protocol, using:
ADD !<port> -POrt VirtualPort {<path> {<FR_DLCI> | <X.25 DTE> | SMDS | MPATM | ETHATM | TRATM | VLan <vlid> | VLanTun <vlid>} | SysCallerID"<callerid>" }
ADD !V1 -PORT VirtualPort 1@35
ATM DXI ports also use the FR_DLCI value.
ADD !V3 -PORT VirtualPort 3#31107551234
ADD !V4 -PORT VirtualPort 5 SMDS
ADD !V5 -PORT VirtualPort 4 MPATM
ADD !V5 -PORT VirtualPort 4 ETHATM
ADD !V3 -PORT VirtualPort SysCallerID"NewYork"
To create a VLAN virtual port on port 1, for the vlan using 802.1Q identifier 42 (hex 3A), enter:
ADD !V9 -POrt VirtualPort 1 VLan 42
To create a VLAN virtual port for token ring tunneled traffic (aka TIFE) on port 2 with vlan id 7, enter:
ADD !V17 -POrt VirtualPort 2 VLanTun 7
2 . If necessary, re-enable the virtual port.
SETDefault !V3 -PORT CONTrol = Enabled
3 . Assign a name to the virtual port (optional).
SETDefault !V3 -PORT NAme = "First_St"
4 . Repeat steps 1 through 3 for each virtual port you configure.
This completes the configuration of virtual ports. The new settings take effect immediately. For information on Remote Access Services (RAS) virtual ports, see Chapter 12.