|
|
Use the information in this chapter to configure LAN interfaces supported on Cisco routers and access servers.
This chapter describes the processes for configuring LAN interfaces. It contains these sections:
For examples of configuration tasks, see "LAN Interface Configuration Examples" at the end of this chapter.
For hardware technical descriptions and information about installing interfaces, refer to the hardware installation and maintenance publication for your product. For a complete description of the LAN interface commands used in this chapter, refer to the "Interface Commands" chapter of the Configuration Fundamentals Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
Cisco supports both 10 Mbps Ethernet and 100 Mbps Fast Ethernet.
Support for the 10 Mbps and 100 Mbps Ethernet interface is supplied on various Ethernet network interface cards or systems.
The Fast Ethernet NP-1FE Module, for example, provides the following benefits:
Refer to the Cisco Product Catalog for specific platform and hardware compatibility information.
Use the show interfaces, show controllers mci, and show controllers cbus EXEC commands to display the Ethernet port numbers. These commands provide a report for each interface supported by the router or access server.
Use the show interface fastethernet command to display interface statistics, and use the show controller fastethernet to display the information about the Fast Ethernet controller chip. The output shows statistics, including information about initialization block information, transmit ring, receive ring and errors.
Perform the tasks in the following sections to configure features on an Ethernet or Fast Ethernet interface. The first task is required; the remaining tasks are optional.
To specify an Ethernet interface and enter interface configuration mode, perform one of the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Begin interface configuration. | interface ethernet number |
| Begin interface configuration for the Cisco 7200 and 7500 series. | interface ethernet slot/port |
| Begin interface configuration for Cisco 7500 series. | interface ethernet slot/port-adapter/port |
| Begin interface configuration for the Cisco 4000 series with a Fast Ethernet NIM installed. | interface fastethernet number |
| Specify a Fast Ethernet interface and enter interface configuration mode on the Cisco 7200 series or the Cisco 7500 series. | interface fastethernet slot/port |
| Specify a Fast Ethernet interface and enter interface configuration mode on the Cisco 7500. | interface fastethernet slot/port-adapter/port |
Use the show interfaces fastethernet command to display the Fast Ethernet slots and ports. The Fast Ethernet NIM and the FEIP default to half-duplex mode.
Currently, there are three common Ethernet encapsulation methods:
The encapsulation method you use depends upon the routing protocol you are using, the type of Ethernet media connected to the router or access server and the routing or bridging application you configure.
Establish Ethernet encapsulation of IP packets by performing one of the following tasks in interface configuration mode:
| Task | Command |
|---|---|
| Select ARPA Ethernet encapsulation. | encapsulation arpa |
| Select SAP Ethernet encapsulation. | encapsulation sap |
| Select SNAP Ethernet encapsulation. | encapsulation snap |
For an example of selecting Ethernet encapsulation for IP, see the section "Enable Ethernet Encapsulation Example" at the end of this chapter. See also the chapters describing specific protocols or applications.
You can specify that the Ethernet network interface module (NIM) on the Cisco 4000 uses either the default of an AUI and a 15-pin connector, or 10BaseT and an RJ45 connector. To do so, perform one of the following tasks in interface configuration mode:
| Task | Command |
|---|---|
| Select a 15-pin Ethernet connector. | media-type aui |
| Select an RJ45 Ethernet connector. | media-type 10baset |
On a Cisco 4000 or Cisco 4500, you can extend the twisted-pair 10BaseT capability beyond the standard 100 meters by reducing the squelch (signal cutoff time). This feature applies only to the LANCE controller 10BaseT interfaces. LANCE is the AMD controller chip for the Cisco 4000 and Cisco 4500 Ethernet interface.
To reduce squelch, perform the first task that follows in interface configuration mode. You can later restore the squelch by performing the second task.
| Task | Command |
|---|---|
| Reduce the squelch. | squelch reduced |
| Return squelch to normal. | squelch normal |
The 100VG-AnyLAN port adapter (PA-100VG) is available on Cisco 7200 series routers and on Cisco 7500 series routers.
The PA-100VG provides a single interface compatible with and specified by IEEE 802.12 to support 100 Mbps over Category 3 or Category 5 unshielded twisted-pair (UTP) cable with RJ-45 terminators. The PA-100VG supports 802.3 Ethernet packets and can be monitored with the IEEE 802.12 Interface MIB.
| Task | Command |
|---|---|
| Step 1 Specify a 100VG-AnyLAN interface and enter interface configuration. | interface vg-anylan slot/port-adapter/port (Cisco 7500)
interface vg-anylan slot/port (Cisco 7200) |
| Step 2 Specify the IP address and subnet mask to the interface. | ip address ip-address mask |
| Step 3 Configure the frame type. Currently, only Ethernet frames are supported. The frame type defaults to Ethernet. | frame-type ethernet |
Configuring the PA-100VG interface is similar to configuring an Ethernet or Fast Ethernet interface. To display information about the 100VG-AnyLAN port adapter, use the show interfaces vg-anylan EXEC command.
The Fiber Distributed Data Interface (FDDI) is an ANSI-defined standard for timed 100-Mbps token passing over fiber-optic cable. FDDI is not supported on access servers.
An FDDI network consists of two counter token-passing fiber-optic rings. On most networks, the primary ring is used for data communication and the secondary ring is used as a hot standby. The FDDI standard sets a total fiber length of 200 kilometers. (The maximum circumference of the FDDI network is only half the specified kilometers because of the wrapping or looping back of the signal that occurs during fault isolation.)
The FDDI standard allows a maximum of 500 stations with a maximum distance between active stations of two kilometers when interconnecting them with multimode fiber or ten kilometers when interconnected via single mode fiber, both of which are supported by our FDDI interface controllers. The FDDI frame can contain a minimum of 17 bytes and a maximum of 4500 bytes. Our implementation of FDDI supports Station Management (SMT) Version 7.3 of the X3T9.5 FDDI specification, offering a single MAC dual-attach interface that supports the fault-recovery methods of the dual attachment stations (DASs). The mid-range platforms also support single attachment stations (SASs).
Refer to the Cisco Product Catalog for specific information on platform and interface compatibility. For installation and configuration information, refer to the installation and configuration publication for the appropriate interface card or port adapter.
Source-route bridging (SRB) is supported on the FDDI interface to the Cisco 4000-M, Cisco 4500-M, and Cisco 4700-M routers. For instructions on configuring autonomous FDDI SRB or fast-switching SRB over FDDI, refer to the "Configuring Source-Route Bridging" chapter of the Bridging and IBM Networking Configuration Guide.
Source-route bridging (SRB) is supported over Fiber Distributed Data Interface (FDDI).
Particle-based switching is supported for SRB packets (over FDDI and Token Ring) by default.
Particle-based switching adds scatter-gather capability to SRB to improve performance. Particles represent a communications data packet as a collection of noncontiguous buffers. The traditional Cisco IOS packet has a packet type control structure and a single contiguous data buffer. A particle packet has the same packet type control structure, but also maintains a queue of particle type structures, each of which manages its own block.
The scatter-gather architecture used by particle-based switching provides the following advantages:
For information about configuring SRB over FDDI, refer to the "Configure Source-Route Bridging" chapter of the Cisco IOS Bridging and IBM Networking Configuration Guide.
Connection management (CMT) is an FDDI process that handles the transition of the ring through its various states (off, on, active, connect, and so on) as defined by the X3T9.5 specification. The FIP provides CMT functions in microcode.
A partial sample output of the show interfaces fddi command follows, along with an explanation of how to interpret the CMT information in the output.
Phy-A state is active, neighbor is B, cmt signal bits 08/20C, status ALS Phy-B state is active, neighbor is A, cmt signal bits 20C/08, status ILS CFM is thru A, token rotation 5000 usec, ring operational 0:01:42 Upstream neighbor 0800.2008.C52E, downstream neighbor 0800.2008.C52E
The show interfaces fddi example shows that Physical A (Phy-A) completed CMT with its neighbor. The state is active and the display indicates a Physical B-type neighbor.
The sample output indicates CMT signal bits 08/20C for Phy-A. The transmit signal bits are 08. Looking at the PCM state machine, 08 indicates that the port type is A, the port compatibility is set, and the LCT duration requested is short. The receive signal bits are 20C, which indicate the neighbor type is B, port compatibility is set, there is a MAC on the port output, and so on.
The neighbor is determined from the received signal bits, as follows:
| Bit Positions | 9 8 7 6 5 4 3 2 1 0 |
| Value Received | 1 0 0 0 0 0 1 1 0 0 |
Interpreting the bits in the diagram above, the received value equals 0x20C. Bit positions 1 and 2 (0 1) indicate a Physical B-type connection.
The transition states displayed indicate that the CMT process is running and actively trying to establish a connection to the remote physical connection. The CMT process requires state transition with different signals being transmitted and received before moving on to the state ahead as indicated in the PCM state machine. The ten bits of CMT information are transmitted and received in the Signal State. The NEXT state is used to separate the signaling performed in the Signal State. Therefore, in the preceding sample output, the NEXT state was entered 11 times.
The CFM state is through A in the sample output, which means this interface's Phy-A has successfully completed CMT with the Phy-B of the neighbor and Phy-B of this interface has successfully completed CMT with the Phy-A of the neighbor.
The display (or nondisplay) of the upstream and downstream neighbor does not affect the ability to route data. Since the upstream neighbor is also its downstream neighbor in the sample, there are only two stations in the ring: the network server and the router at address 0800.2008.C52E.
Perform the tasks in the following sections to configure an FDDI interface. The first task is required; the remaining tasks are optional.
To specify an FDDI interface and enter interface configuration mode, perform one of the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Begin interface configuration | interface fddi number |
| Begin interface configuration for the Cisco 7200 or Cisco 7500 series. | interface fddi slot/port |
Cisco FDDI by default uses the SNAP encapsulation format defined in RFC 1042. It is not necessary to define an encapsulation method for this interface when using the FIP.
FIP fully supports transparent and translational bridging for the following configurations:
Enabling FDDI bridging encapsulation places the FIP into encapsulation mode when doing bridging. In transparent mode, the FIP interoperates with earlier versions of encapsulating interfaces when performing bridging functions on the same ring. When using the FIP, you can specify the encapsulation method by performing the following task in interface configuration mode:
| Task | Command |
|---|---|
| Specify the encapsulation method for the FIP. | fddi encapsulate |
When you are doing translational bridging, you have to route routable protocols and use translational bridging for the rest (such as LAT).
We are currently aware of problems with the following protocols when bridged between Token Ring and other media: AppleTalk, DECnet, IP, Novell IPX, Phase IV, VINES, and XNS. Further, the following protocols might have problems when bridged between FDDI and other media: Novell IPX and XNS. We recommend that these protocols be routed whenever possible.
To enable full-duplex mode on the PA-F/FD-SM and PA-F/FD-MM port adapters, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Enable full-duplex on the FDDI interface of the PA-F/FD-SM and PA-F/FD-MM port adapter. | full-duplex
or no half-duplex |
| Task | Command |
|---|---|
| Set the FDDI token rotation time. | fddi token-rotation-time microseconds |
The FDDI standard restricts the allowed time to be greater than 4000 microseconds and less than 165,000 microseconds. As defined in the X3T9.5 specification, the value remaining in the token rotation timer (TRT) is loaded into the token holding timer (THT). Combining the values of these two timers provides the means to determine the amount of bandwidth available for subsequent transmissions.
You can set the transmission timer to recover from a transient ring error by performing the following task in interface configuration mode:
| Task | Command |
|---|---|
| Set the FDDI valid transmission timer. | fddi valid-transmission-time microseconds |
You can set the FDDI control transmission timer to control the FDDI TL-Min time, which is the minimum time to transmit a Physical Sublayer or PHY line state before advancing to the next Physical Connection Management or PCM state as defined by the X3T9.5 specification. To do so, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Set the FDDI control transmission timer. | fddi tl-min-time microseconds |
You can modify the C-Min timer on the PCM from its default value of 1600 microseconds by performing the following task in interface configuration mode:
| Task | Command |
|---|---|
| Set the C-Min timer on the PCM. | fddi c-min microseconds |
You can change the TB-Min timer in the PCM from its default value of 100 milliseconds. To do so, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Set TB-Min timer in the PCM. | fddi tb-min milliseconds |
You can change the FDDI timeout timer in the PCM from its default value of 100 milliseconds. To do so, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Set the timeout timer in the PCM. | fddi t-out milliseconds |
You can disable and reenable SMT frame processing for diagnostic purposes. To do so, perform one of the following tasks in interface configuration mode:
| Task | Command |
|---|---|
| Disable SMT frame processing. | no fddi smt-frames |
| Enable SMT frame processing. | fddi smt-frames |
| Task | Command |
|---|---|
| Enable duplicate address checking capability. | fddi duplicate-address-check |
You can set the FDDI bit control to control the information transmitted during the Connection Management (CMT) signaling phase. To do so, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Set the FDDI bit control. | fddi cmt-signal-bits signal-bits [phy-a | phy-b] |
You can control whether the CMT onboard functions are on or off. The FIP provides CMT functions in microcode. These functions are separate from those provided on the processor card and are accessed through EXEC commands.
The default is for the FIP CMT functions to be on. A typical reason to disable is when you work with new FDDI equipment and have problems bringing up the ring. If you disable the CMT microcode, the following actions occur:
To disable the CMT microcode, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Disable the FCIT CMT functions. | no fddi if-cmt |
In normal operation, the FDDI interface is operational once the interface is connected and configured. You can start and stop the processes that perform the CMT function and allow the ring on one fiber to be stopped. To do so, perform either of the following tasks in EXEC mode:
| Task | Command |
|---|---|
| Start CMT processes on FDDI ring. | cmt connect [interface-name [phy-a | phy-b]] |
| Stop CMT processes on FDDI ring. | cmt disconnect [interface-name [phy-a | phy-b]] |
Do not do either of the preceding tasks during normal operation of FDDI; they are performed during interoperability tests.
You can set the maximum number of unprocessed FDDI Station Management (SMT) frames that will be held for processing. Setting this number is useful if the router you are configuring gets bursts of messages arriving faster than the router can process them. To set the number of frames, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Set SMT message queue size. | smt-queue-threshold number |
The FCI card preallocates three buffers to handle bursty FDDI traffic (for example, NFS bursty traffic). You can change the number of preallocated buffers by performing the following task in interface configuration mode:
| Task | Command |
|---|---|
| Preallocate buffers to handle bursty FDDI traffic. | fddi burst-count |
The Cisco 2500 series includes routers that have hub functionality for an Ethernet interface. The hub is a multiport repeater. The advantage of an Ethernet interface over a hub is that the hub provides a star-wiring physical network configuration while the Ethernet interface provides 10BaseT physical network configuration. The router models with hub ports and their configurations are as follows:
We provide SNMP management of the Ethernet hub as specified in RFC 1516.
To configure hub functionality on an Ethernet interface, perform the tasks in the following sections. The first task is required; the remaining are optional.
See the "Hub Configuration Examples" section the end of this chapter.
To enable a hub port, perform the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Step 1 Specify the hub number and the hub port (or range of hub ports) and enter hub configuration mode. | hub ethernet number port [end-port] |
| Step 2 Enable the hub ports. | no shutdown |
Automatic receiver polarity reversal is enabled by default. To disable this feature on a per-port basis, perform the following task in hub configuration mode:
| Task | Command |
|---|---|
| Disable automatic receiver polarity reversal. | no auto-polarity |
To reenable automatic receiver polarity reversal on a per-port basis, perform the following task in hub configuration mode:
| Task | Command |
|---|---|
| Reenable automatic receiver polarity reversal. | auto-polarity |
The link test function applies to Ethernet hub ports only. The Ethernet ports implement the link test function as specified in the 802.3 10BaseT standard. The hub ports will transmit link test pulses to any attached twisted pair device if the port has been inactive for more than 8 to 17 milliseconds.
If a hub port does not receive any data packets or link test pulses for more than 65 to 132 milliseconds and the link test function is enabled for that port, that port will enter link fail state and be disabled from transmit and receive functions. The hub port will be reenabled when it receives four consecutive link test pulses or a data packet.
The link test function is enabled by default. To allow the hub to interoperate with 10BaseT twisted-pair networks that do not implement the link test function, the hub's link test receive function can be disabled on a per-port basis. To do so, perform the following task in hub configuration mode:
| Task | Command |
|---|---|
| Disable the link test function. | no link-test |
To reenable the link test function on a hub port connected to an Ethernet interface, perform the following task in hub configuration mode:
| Task | Command |
|---|---|
| Enable the link test function. | link-test |
To enable source address control on a per-port basis, perform the following task in hub configuration mode:
| Task | Command |
|---|---|
| Enable source address control. | source-address [mac-address] |
If you omit the optional MAC address, the hub remembers the first MAC address it receives on the selected port, and allows only packets from the learned MAC address.
See the examples of establishing source address control at the end of this chapter in "Hub Configuration Examples."
To enable the router to issue an SNMP trap when an illegal MAC address is detected on an Ethernet hub port, perform the following tasks in hub configuration mode:
| Task | Command |
|---|---|
| Step 1 Specify the hub number and the hub port (or range of hub ports) and enter hub configuration mode. | hub ethernet number port [end-port] |
| Step 2 Enable the router to issue an SNMP trap when an illegal MAC address is detected on the hub port. | snmp trap illegal-address |
You may need to set up a host receiver for this trap type (snmp-server host) for a Network Management System (NMS) to receive this trap type. The default is no trap. For an example of configuring a SNMP trap for an Ethernet hub port, see the section "Hub Configuration Examples" at the end of this chapter.
The Cisco 1001 and Cisco 1002 LAN Extenders are two-port chassis that connect a remote Ethernet LAN to a core router at a central site (see Figure 19). The LAN Extender is intended for small networks at remote sites. Overview information for LAN extender interfaces is provided in these sections:
The remote site can have one Ethernet network. The core router can be a Cisco 2500 series, Cisco 4000 series, Cisco 4500 series, Cisco 4700 series, Cisco 7500 series, or AGS+ router running Cisco IOS Release 10.2(2) or later, which support the LAN Extender host software. The connection between the LAN Extender and the core router is made via a short leased serial line, typically a 56-kbps or 64-kbps line. However, the connection can also be via T1 or E1 lines.
Figure 20 is an expanded view of Figure 19 that shows all the components of the LAN Extender connection to a core router. On the left is the core router, which is connected to the LAN Extender as well as to other networks. In the core router, you configure a LAN Extender interface, which is a logical interface that connects the core router to the LAN Extender chassis. In the core router, you also configure a serial interface, which is the physical interface that connects the core router to the LAN Extender. You then bind, or associate, the LAN Extender interface to the physical serial interface.
Figure 20 shows the actual physical connection between the core router and the LAN Extender. The serial interface on the core router is connected by a leased serial line to a serial port on the LAN Extender. This creates a virtual Ethernet connection, which is analogous to having inserted an Ethernet interface processor into the core router.
Although there is a physical connection between the core router and the LAN Extender, what you actually manage is a remote Ethernet LAN. Figure 21 shows the connection you are managing, which is a LAN Extender interface connected to an Ethernet network. The virtual Ethernet connection (the serial interface and LAN Extender) has been removed from the figure, and points A and B, which in Figure 20 were separated by the virtual Ethernet connection, are now adjacent. All LAN Extender interface configuration tasks described in this chapter apply to the interface configuration shown in Figure 21.
To install a LAN Extender at a remote site, refer to the Cisco 1000 Series Hardware Installation publication.
After the LAN Extender has been installed at the remote site, you need to obtain its MAC address. Each LAN Extender is preconfigured with a permanent (burned-in) MAC address. The address is assigned at the factory; you cannot change it. The MAC address is printed on the LAN Extender's packing box. (If necessary, you can also display the MAC address with the debug ppp negotiation command.) The first three octets of the MAC address (the vendor code) are always the hexadecimal digits 00.00.0C.
You can upgrade software for the LAN Extender on the host router with a TFTP server that is local to the host router.
The LAN Extender and core router communicate using the Point-to-Point Protocol (PPP). Before you can configure the LAN Extender from the core router, you must first enable PPP encapsulation on the serial interface to which the LAN Extender is connected.
You configure the LAN Extender from the core router--either a Cisco 4000 series or Cisco 7000 series router--as if it were simply a network interface board. The LAN Extender cannot be managed or configured from the remote Ethernet LAN or via a Telnet session.
To configure the LAN Extender, you configure a logical LAN Extender interface on the core router and assign the MAC address from your LAN Extender to that interface. Subsequently, during the PPP negotiation on the serial line, the LAN Extender sends its preconfigured MAC address to the core router. The core router then searches for an available (preconfigured) LAN Extender interface, seeking one to which you have already assigned that MAC address. If the core router finds a match, it binds, or associates, that LAN Extender interface to the serial line on which that MAC address was negotiated. At this point, the LAN Extender interface is created and is operational. If the MAC address does not match one that is configured, the connection request is rejected. Figure 22 illustrates this binding process.
To configure a LAN Extender interface, perform the tasks described in the following sections. The first task is required; the remainder are optional.
To monitor the LAN Extender interface, see the section "Monitor and Maintain the Interface" in the "Overview of Interface Configuration" chapter. For configuration examples, see the "Enable a LAN Extender Interface Example" and the "LAN Extender Interface Access List Examples" sections at the end of this chapter.
To configure and create a LAN Extender interface, you configure the LAN Extender interface itself and the serial interface to which the LAN Extender is physically connected. The order in which you configure these two interface interfaces does not matter. However, you must first configure both interfaces in order for the LAN Extender interface to bind (associate) to the serial interface.
To create and configure a LAN Extender interface, perform the following tasks:
| Task | Command |
|---|---|
| Step 1 Configure a LAN Extender interface in global configuration mode and enter interface configuration mode. or Configure a LAN Extender on a Cisco 7000. | interface lex number interface lex slot/port |
| Step 2 Assign the burned-in MAC address from your LAN Extender to the LAN Extender interface. | lex burned-in-address ieee-address |
| Step 3 Assign a protocol address to the LAN Extender interface. | ip address ip-address mask |
| Step 4 Return to global configuration mode. | exit |
| Step 5 Configure a serial interface in global configuration mode and enter interface configuration mode. | interface serial number |
| Step 6 Enable PPP encapsulation on the serial interface in interface configuration mode. | encapsulation ppp |
| Step 7 Exit interface configuration mode. | Ctrl-Z |
| Step 8 Save the configuration to memory. | copy running-config startup-config |
Note that there is no correlation between the number of the serial interface and the number of the LAN Extender interface. These interfaces can have the same or different numbers.
You can configure specific administrative filters that filter frames based on their source MAC address. The LAN Extender forwards packets between a remote LAN and a core router. It examines frames and transmits them through the internetwork according to the destination address, and it does not forward a frame back to its originating network segment.
You define filters on the LAN Extender interface in order to control which packets from the remote Ethernet LAN are permitted to pass to the core router. (See Figure 23.) These filters are applied only on traffic passing from the remote LAN to the core router. Filtering on the LAN Extender interface is actually performed in the LAN Extender, not on the core router. This means that the filtering is done using the LAN Extender CPU, thus off-loading the function from the core router. This process also saves bandwidth on the WAN, because only the desired packets are forwarded from the LAN Extender to the core router. Whenever possible, you should perform packet filtering on the LAN Extender.
You can also define filters on the core router to control which packets from the LAN Extender interface are permitted to pass to other interfaces on the core router. (See Figure 24.) You do this using the standard filters available on the router. This means that all packets are sent across the WAN before being filtered and that the filtering is done using the core router's CPU.
The major reason to create access lists on a LAN Extender interface is to prevent traffic that is local to the remote Ethernet LAN from traversing the WAN and reaching the core router. You can filter packets by MAC address, including vendor code, and by Ethernet type code. To define filters on the LAN Extender interface, perform the tasks described in one or both of the following sections:
When defining access lists, keep the following points in mind:
You can create access lists to administratively filter MAC addresses. These access lists can filter groups of MAC addresses, including those with particular vendor codes. There is no noticeable performance loss in using these access lists, and the lists can be of indefinite length. You can filter groups of MAC addresses with particular vendor codes by performing the tasks that follow:
Step 1 Create a vendor code access list.
Step 2 Apply an access list to an interface.
To create a vendor code access list, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Create an access list to filter frames by canonical (Ethernet-ordered) MAC address. | access-list access-list-number {permit | deny} address mask |
Once you have defined an access list to filter by a particular vendor code, you can assign this list to a particular LAN Extender interface so that the interface will then filter based on the MAC source addresses of packets received on that LAN Extender interface. To apply the access list to an interface, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Assign an access list to an interface for filtering by MAC source addresses. | lex input-address-list access-list-number |
For an example of creating an access list and applying it to a LAN Extender interface, see the section "LAN Extender Interface Access List Examples" in the section "LAN Interface Configuration Examples" at the end of this chapter.
You can filter by creating a type-code access list and applying it to a LAN Extender interface.
The LAN Extender interface can filter only on bytes 13 and 14 of the Ethernet frame. In Ethernet packets, these two bytes are the type field. For a list of Ethernet type codes, refer to the "Ethernet Type Codes" appendix in the Bridging and IBM Networking Command Reference. In 802.3 packets, these two bytes are the length field.
To filter by protocol type, perform the following tasks:
Step 1 Create a protocol-type access list.
Step 2 Apply the access list to an interface.
To create a protocol-type access list, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Create an access list to filter frames by protocol type. | access-list access-list-number {permit | deny} type-code wild-mask |
To apply an access list to an interface, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Add a filter for Ethernet- and SNAP-encapsulated packets on input. | lex input-type-list access-list-number |
For an example of creating an access list and applying it to a LAN Extender interface, see the section "LAN Extender Interface Access List Examples" in the section "LAN Interface Configuration Examples" at the end of this chapter.
Priority output queuing is an optimization mechanism that allows you to set priorities on the type of traffic passing through the network. Packets are classified according to various criteria, including protocol and subprotocol type. Packets are then queued on one of four output queues. For more information about priority queuing, refer to the "Managing System Performance" chapter.
To control priority queuing on a LAN Extender interface, perform the following tasks:
To establish queuing priorities based on the protocol type, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Establish queuing priorities based on the protocol type. | priority-list list protocol protocol {high | medium | normal | low} or priority-list list protocol bridge {high | medium | normal | low} list list-number |
You then assign a priority list to an interface. You can assign only one list per interface. To assign a priority list to a LAN Extender interface, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Assign a priority list to a LAN Extender interface, thus activating priority output queuing on the LAN Extender. | lex priority-group group |
Each time the core router sends a command to the LAN Extender, the LAN Extender responds with an acknowledgment. The core router waits for the acknowledgment for a predetermined amount of time. If it does not receive an acknowledgment in this time period, the core router resends the command.
By default, the core router waits 2 seconds for an acknowledgment from the LAN Extender. You might want to change this interval if your connection to the LAN Extender requires a different amount time. To determine whether commands to the LAN Extender are timing out, use the debug lex rcmd privileged EXEC command. To change this interval, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Set the amount of time that the core router waits to receive an acknowledgment from the LAN Extender. | lex timeout milliseconds |
By default, the core router sends each command ten times before giving up. The core router displays an error message when it gives up sending commands to the LAN Extender. To change this default, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Set the number of times the core router sends a command to the LAN Extender before giving up. | lex retry-count number |
From the core router, you can shut down the LAN Extender's Ethernet interface. This stops traffic on the remote Ethernet LAN from reaching the core router, but leaves the LAN Extender interface that you created intact.
Note that logically it makes no sense to shut down the serial interface on the LAN Extender. There are no commands that might allow you to do this.
| Task | Command |
|---|---|
| Shut down the LAN Extender's Ethernet interface. | shutdown |
To restart the LAN Extender's Ethernet interface, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Restart the LAN Extender's Ethernet interface. | no shutdown |
To reboot the LAN Extender and reload the software, perform the following task in privileged EXEC mode:
When the LAN Extender is powered on, it runs the software image that is shipped with the unit. You can download a new software image from Flash memory on the core router or from a TFTP server or from Flash memory on the core router to the LAN Extender.
| Task | Command |
|---|---|
| Download a software image from Flash memory on the core router. | copy flash lex number |
| Download a software image from a TFTP server. | copy tftp lex number |
| Download a software image from Flash memory. | copy flash lex number |
The primary means of troubleshooting the LAN Extender is by using the light emitting diodes (LEDs) that are present on the chassis. This section will help you assist the remote user at the LAN Extender site who can observe the LEDs.
The Cisco 1000 series LAN Extender uses multiple LEDs to indicate its current operating condition. By observing the LEDs, any fault conditions that the unit is encountering can be observed. The system LEDs are located on the front panel of your LAN Extender (see Figure 25).
When there is a problem with the LAN Extender, a user at the remote site should contact you and report the condition of the LEDs located on the front panel of the LAN Extender. You can then use this information to diagnose or verify the operation of the system. explains the LEDs.
For more complete network troubleshooting information, refer to the Troubleshooting Internetworking Systems publication.
Cisco supports various Token Ring interfaces. Refer to the Cisco Product Catalog for information about platform and hardware compatibility.
The Token Ring interface supports both routing (Layer 3 switching) and source-route bridging (Layer 2 switching). Routing and bridging function on a per-protocol basis. For example, IP traffic could be routed while SNA traffic is bridged. Routing features enhance source-route bridges.
The Token Ring MIB variables support the specification in RFC 1231, "IEEE 802.5 Token Ring MIB," by K. McCloghrie, R. Fox, and E. Decker, May 1991. The mandatory Interface Table and Statistics Table are implemented, but the optional Timer Table of the Token Ring MIB is not. The Token Ring MIB has been implemented for the TRIP.
Use the show interfaces, show controllers token, and show controllers cbus EXEC commands to display the Token Ring numbers. These commands provide a report for each ring that Cisco IOS software supports.
By default, the Token Ring interface uses the SNAP encapsulation format defined in RFC 1042. It is not necessary to define an encapsulation method for this interface.
Particle-based switching is supported for SRB packets (over FDDI and Token Ring) by default.
Particle-based switching adds scatter-gather capability to SRB to improve performance. Particles represent a communications data packet as a collection of noncontiguous buffers. The traditional Cisco IOS packet has a packet type control structure and a single contiguous data buffer. A particle packet has the same packet type control structure, but it also maintains a queue of particle type structures, each of which manages its own block.
The scatter-gather architecture used by particle-based switching provides the following advantages:
For information about configuring SRB over FDDI, refer to the "Configure Source-Route Bridging" chapter of the Bridging and IBM Networking Configuration Guide.
Perform the tasks in the following sections to configure a Token Ring interface. The first task is required; the remaining tasks are optional.
To specify a Token Ring interface and enter interface configuration mode, perform one of the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Begin interface configuration. | interface tokenring number |
| Begin interface configuration for the Cisco 7200 or Cisco 7500 series. | interface tokenring slot/port |
| Begin interface configuration for the Cisco 7500 series. | interface tokenring slot/port-adapter/port |
Cisco Token Ring interfaces support early token release, a method whereby the interface releases the token back onto the ring immediately after transmitting rather than waiting for the frame to return. This feature can help to increase the total bandwidth of the Token Ring. To configure the interface for early token release, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Enable early token release. | early-token-release |
The Token Ring interface on the AccessPro PC card can be managed by a remote LAN manager over the PCbus interface. Currently, the LanOptics Hub Networking Management software running on an IBM-compatible PC is supported.
To enable LanOptics Hub Networking Management of a PCbus Token Ring interface, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Enable PCbus LAN management. | local-lnm |
This section provides examples to illustrate configuration tasks described in this chapter. These examples are included:
The following example illustrates how to begin interface configuration on a serial interface. It assigns Point-to-Point (PPP) encapsulation to serial interface 0.
interface serial 0 encapsulation ppp
The same example on a Cisco 7500 requires the following commands:
interface serial 1/0 encapsulation ppp
This example shows how to configure the access server so that it will use the default address pool on all interfaces except interface 7, on which it will use an address pool called lass:
ip address-pool local ip local-pool lass 172.30.0.1 async interface interface 7 peer default ip address lass
These commands enable standard Ethernet Version 2.0 encapsulation on the Ethernet interface processor in slot 4 on port 2 of a Cisco 7500:
interface ethernet 4/2 encapsulation arpa
configure terminal interface vg-anylan 1/0/0 ip address 1.1.1.10 255.255.255.0 no shutdown exit exit
The following sections provide examples of hub configuration:
The following example configures port 1 on hub 0 of Ethernet interface 0:
hub ethernet 0 1 no shutdown
The following example configures ports 1 through 8 on hub 0 of Ethernet interface 0:
hub ethernet 0 1 8 no shutdown
The following example configures the hub to allow only packets from MAC address 1111.2222.3333 on port 2 of hub 0:
hub ethernet 0 2 source-address 1111.2222.3333
The following example configures the hub to remember the first MAC address received on port 2, and allow only packets from that learned MAC address:
hub ethernet 0 2 source-address
The following example shuts down ports 3 through 5 on hub 0:
hub ethernet 0 3 5 shutdown
The following example shuts down port 3 on hub 0:
hub ethernet 0 3 shutdown
The following example specifies the gateway IP address, enables an SNMP trap to be issued to the host 172.69.40.51 when a MAC address violation is detected on hub ports 2, 3, or 4, and specifies that interface Ethernet 0 is the source for all traps on the router. The community string is defined as the string public and the read/write parameter is set.
ip route 0.0.0.0 0.0.0.0 172.22.10.1 snmp-server community public rw snmp-server trap-source ethernet 0 snmp-server host 172.69.40.51 public hub ethernet 0 2 4 snmp trap illegal-address
The following simple example configures and creates a LAN Extender interface. In this example, the MAC address of the LAN Extender is 0000.0c00.0001.
interface serial 4 encapsulation ppp interface lex 0 lex burned-in-address 0000.0c00.0001 ip address 131.108.172.21 255.255.255.0
This section provides these examples of LAN extender interface configuration:
The following is an example that controls which traffic from Macintosh computers on the remote Ethernet LAN reaches the core router:
access-list 710 permit 0800.0298.0000 0000.0000.FFFF access-list 710 deny 0800.0276.2917 0000.0000.0000 access-list 710 permit 0800.0000.0000 0000.FFFF.FFFF interface lex 0 lex input-address-list 710
The first line of this access list permits traffic from any Macintosh whose MAC address starts with 0800.0298. The remaining two octets in the MAC address can be any value because the mask for these octets is FFFF ("don't care" bits).
The second line specifically rejects all traffic originating from a Macintosh with the MAC address of 0800.0276.2917. Note that none of the mask bits are "don't care" bits.
The third line specifically permits all traffic from other Macintoshes whose MAC addresses start with 0800. Note that in the mask, the "don't care" bits are the rest of the address.
At the end of the list is an implicit "deny everything" entry, meaning that any address that does not match an address or address group on the list is rejected.
Using the same configuration as in the previous section, you could allow only the Macintosh traffic by Ethernet type code with the following access list:
access-list 220 permit 0x809B 0x0000 interface lex 0 lex input-type-list 220
This access list permits only those messages whose protocol number matches the masked protocol number in the first line. The implicit last entry in the list is a "deny everything" entry.
The examples in this section include a simple configuration and a configuration for two routers back to back.
In the following example, the default framing, MTU, and clock source are accepted, and the interface is configured for the IP protocol:
interface posi 3/0 ip address 172.18.2.3 255.0.0.0
To connect two routers, attach the cable between the Packet OC-3 port on each. By default, the POSIP uses loop timing mode. For back-to-back operation, only one of the POSIPs may be configured to supply its internal clock to the line.
In the following example, two routers are connected back to back through their Packet OC-3 interfaces:
interface posi 3/0 ip address 170.1.2.3 255.0.0.0 no keepalive pos internal-clock
interface posi 3/0 ip address 170.1.2.4 255.0.0.0 no keepalive
The following example shuts down the entire T1 line physically connected to a Cisco 7500:
controller t1 4/0 shutdown
|
|