cc/td/doc/product/rtrmgmt/tv/tv4
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Controlling Broadcast Frames with Virtual LANs

Controlling Broadcast Frames with Virtual LANs

The Catalyst 1600 supports broadcast filtering and port-to-port blocking. This enables you to block or enable the forwarding of packets between specified ports on a Catalyst 1600, to include or exclude particular rings, by the configuration of logical workgroups, known as virtual LANs.


Note The proprietary implementation of virtual LANs in the Catalyst 1600 software is not interoperable with other implementations of virtual LANs.

By defining virtual LANs, you can:

Controlling Broadcast Frames

Besides virtual LANs, Catalyst 1600 Manager provides two methods for controlling broadcast frames:


  1. RIP/SAP Suppression and ARE Conversion features determine whether the Catalyst 1600 suppresses IPX RIP and SAP frames on ports that do not have an IPX router or server attached, and converts All Routes Explorer (ARE) frames into Spanning Tree Explorer (STE) frames.

    For more information, see the section "Configuring RIP/SAP Suppression and ARE Conversion" in Chapter 5, "Managing Bridging".



  2. Identification of the type of stations connected to each Token Ring switch port enables the Catalyst 1600 to control the forwarding of broadcast frames on a network with centralized servers. On IPX and NetBIOS networks, the Catalyst 1600 uses the information to block broadcast frames originating on workstation-only rings and destined for other workstation-only rings. However, the Catalyst 1600 continues to forward broadcast frames originating on rings with workstations and servers attached, and destined for rings with workstations attached.

    For more information, see the section "Configuring the Station Type" in Chapter 5, "Managing Bridging".


Configuring Virtual LANs

A virtual LAN consists of two or more Token Ring segments that are joined by Catalyst 1600 devices, where stations can only make connections to other stations or servers that are part of the same virtual LAN. The result is that broadcast traffic originating on any ring is only received by stations on rings that belong to the same virtual LAN.

This means that service advertisement, address resolution, and route discovery packets that originate on a ring that does belong to a virtual LAN are not received by stations on rings that do not belong to the same virtual LAN.

For example, you can define several overlapping virtual LANs that share common resources like file servers and print servers. In Figure B-1, the workgroup rings are divided into two virtual LANs that both include the centrally-located server ring 203. The Marketing virtual LAN includes rings 203 and 204, and the Finance virtual LAN includes rings 003, 004, 101, and 203. Although the virtual LANs share the ring on which the servers are located, broadcast frames are not forwarded from either virtual LAN onto rings that only belong to the other.


Figure B-1: Example of a Virtual LAN

If the workgroups move to a new physical location, the administrator can redefine the virtual LAN to ensure that the workgroup can continue to access the ring to which the server is attached.

Types of Virtual LANs

The Catalyst 1600 supports the definition of permeable and impermeable virtual LANs, which can be configured using TrueView Catalyst 1600 Manager. See Table B-1.


Table  B-1: Types of Virtual LANs
Type Description
Impermeable You can define impermeable virtual LANs by specifying an explicit list of the ring numbers that belong to the virtual LAN.

Define impermeable virtual LANs when one or more Catalyst 1600 devices connect a number of rings to form a large LAN.

For more information see "Impermeable Virtual LANs" later in this appendix.

Permeable You can define permeable virtual LANs by specifying a list of ring numbers. Permeable virtual LANs do not restrict the forwarding of broadcast traffic to an explicit list of the rings.

Define permeable virtual LANs when Catalyst 1600 devices are installed in a large source-routed network, to define logical workgroups without explicitly specifying the rings that belong to each virtual LAN.

For more information see "Permeable Virtual LANs" later in this appendix.

Impermeable Virtual LANs

In an impermeable virtual LAN, forwarding decisions are based on the ring on which the frame originated, which is determined from the Routing Information Field (RIF) in each source-routed frame. This means that broadcast traffic is restricted to the explicit list of rings that belong to the virtual LAN.


Note Impermeable virtual LANs that span multiple Catalyst 1600 devices must include a ring that connects the devices.

In Figure B-2, two impermeable virtual LANs both include a ring that has servers attached. The Marketing virtual LAN includes rings 003, 101, and 203, and the Finance virtual LAN includes rings 004, 101, and 203.

Broadcast frames are restricted to the list of rings that belong to the virtual LAN and are not forwarded from either virtual LAN onto rings that only belong to the other. For example, broadcast frames originating on ring 204 are not forwarded to rings that belong to either virtual LAN and the ring is treated as a third, undefined virtual LAN.


Figure B-2: Example of an Impermeable Virtual LAN

Permeable Virtual LANs

In a permeable virtual LAN, any ring that is connected directly to a ring that belongs to the virtual LAN can forward broadcast frames onto the virtual LAN, and receive broadcast frames from inside the virtual LAN.

In Figure B-3, a permeable virtual LAN includes rings 003, 004, 101, and 203. However, because the virtual LAN is permeable, rings 001 and 002 can forward broadcast frames onto the virtual LAN, and receive broadcast frames from inside the virtual LAN.

Ring 204 is not directly connected to a ring that is included in the virtual LAN. Therefore, the stations on the ring cannot forward broadcast frames onto the virtual LAN or receive broadcast frames from inside the virtual LAN.


Figure B-3: Example of a Permeable Virtual LAN

hometocprevnextglossaryfeedbacksearchhelp
Copyright 1989-1997 © Cisco Systems Inc.