|
|
The chapter describes the configuration parameters most commonly used with the Cisco Optical Networking System (ONS) 15304 Ethernet LAN interfaces. Examples of the configuration tasks are described in the "LAN Interface Configuration Examples" section."
The Cisco ONS 15304 platform supports nine 10BaseT Ethernet LAN interfaces, which are distinguished into two different types reflecting the differing purposes for the interfaces.
Figure 5-1 shows the Ethernet ports on the Cisco ONS 15304.
From a functional perspective in carrier type applications, the eight Ethernet "payload" interfaces operate as "user-plane" interfaces, whereas the single Ethernet "console" interface serves as an access path to the management plane of the network. The Ethernet console port can be configured to participate in the management plane network constructed from DCC links.
From a configuration perspective, the console and payload interfaces are configured using similar configuration commands. Differences in the configuration options are highlighted below where applicable.
The console and payload Ethernet interfaces are for hardware technical descriptions. For information about installing interfaces, refer to the Cisco Optical Networking System 15304 Hardware Installation Guide. 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.
The Cisco ONS 15304 supports 10BaseT Ethernet interfaces. These Ethernet interfaces can function in full- or half-duplex mode, and can support IP or bridge-mode operation. The interfaces are configured from within the "configuration mode" using interface Ethernet number.
You can use the show interfaces and show controllers EXEC commands to display the Ethernet status and statistics information. These commands provide a report for each interface, including the Ethernet LAN interfaces.
To configure the Ethernet interfaces, complete these steps:
| Task | Command |
|---|---|
Access the config mode. | ONS # configure terminal |
Select the interface to configure. The Ethernet interfaces are numbered 1-8. | ONS # interface ethernet <1-8> |
If routing, specify an IP address and proceed to step 5. If bridging, proceed to step 4. | ONS (config-if)# ip address 192.168.0.0 255.255.0.0 |
Specify a bridge-group number. The range is between 1 and 8. | ONS (config-if)# bridge-group 1 |
Administratively place the port in- service. | ONS (config-if)# no shutdown |
Repeat tasks 1-4 for each Ethernet interface. |
|
The sections that follow provide more information on other options that can be configured.
There are three common Ethernet encapsulation methods:
The encapsulation method you use depends on the network layer protocol you are using, the type of Ethernet media connected to the Cisco ONS 15304, and the routing or bridging application you configure. For IP applications, the default ARPA encapsulation is often sufficient, and no further configuration is required. You can specify the Ethernet encapsulation of IP packets by completing one of the following tasks in the interface configuration mode:
| Task | Command |
|---|---|
Select ARPA Ethernet encapsulation. | |
Select SAP Ethernet encapsulation. | |
Select SNAP Ethernet encapsulation. |
For an example of selecting Ethernet encapsulation for IP, see the "Enable Ethernet Encapsulation Example" section. See also the chapters describing specific protocols or applications.
The Ethernet interfaces will normally operate in half-duplex Ethernet mode, if no further configuration is specified. To enable full-duplex mode on the Ethernet payload interfaces, complete the task in interface configuration mode. To disable full-duplex mode, complete the second command.
| Task | Command |
|---|---|
Enable full-duplex on the Ethernet interface. |
or no half-duplex |
Disable full-duplex on the Ethernet interface. |
or |
On an Ethernet interface port only, you might optionally specify a MAC address to override the address that is burned into the EEPROM of the chassis. A user does not normally need to specify the MAC address, and the choice of address should be selected with care. Duplicate MAC addresses will cause the Ethernet interfaces sharing the same address not to function properly.
| Task | Command |
|---|---|
Enable source address control. | mac-address [mac-address] |
You might 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, complete the following task in global configuration mode:
| Task | Command |
|---|---|
Create an access list to filter frames by canonical (Ethernet-ordered) MAC address. |
After you have defined an access list to filter by a particular vendor code, you can assign this list to a particular interface so that the interface will then filter based on the MAC source addresses of packets received on that 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. |
For an example of creating an access list and applying it to an interface, see the "LAN Interface Configuration Examples" section.
You can filter by creating a type-code access list and applying it to an Ethernet interface. To filter by protocol type, complete these 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, complete this 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, complete this task in interface configuration mode:
| Task | Command |
|---|---|
Add a filter for Ethernet- and SNAP-encapsulated packets on input. |
For an example of creating an access list and applying it to a Ethernet interface, see the "LAN Interface Configuration Examples" section.
Ethernet ports 1 through 8 do not support the "loopback" configuration command. To loop packet traffic issued on these ports, a loopback connector must be attached to the Champ connector or to each wire pair. In addition, software loopback processing is not present for packets sent to the local address. When logged into the Cisco ONS 15304, packets issued using one of the IP addresses assigned to Ethernet 1 through 8 interface will not succeed unless a loopback connector is present. This mode of operation allows you to test the wire that terminates on the Cisco ONS 15304 when a loopback plug is inserted at the far-end.
Ethernet interfaces 1 through 8 include a simple, high-performance ingress policing mechanism to help regulate the processing and forwarding of packet traffic to ensure all active Ethernet interfaces receive fair service. The goal of ingress policing is to help reduce the impact on forwarding performance received by subscribers when one or more misbehaving stations attached to different Ethernet interfaces send traffic to the Cisco ONS 15304 at a rate greater than the system can process, or send more traffic than can be forwarded on egress serial links.
The ability to regulate resource consumption on a per-interface basis is often useful in carrier, multisubscriber applications where buffer and processing resources need to be controlled and shared among multiple competing traffic sources. While the Cisco ONS 15304 partitions ingress buffer resources for each Ethernet interface, a common processing engine is used to handle all packet traffic, and it is necessary to ensure this resource does not become saturated by a misbehaving Ethernet interface.
The policing mechanism applies only to traffic arriving from the Ethernet interfaces for forwarding to the serial interfaces, and operates at the interface level. (This direction of traffic flow is referred to here as the ingress direction.) The policing mechanism does not attempt to provide fairness between different competing streams of traffic within an interface. Policing takes place between interfaces. To help ensure fairness within an interface, subscriber-attached equipment should regulate and prioritize the traffic before passing it to the Cisco ONS 15304. The Ethernet input policing mechanism operates independent of protocol, and applies for all traffic including both bridged and IP traffic.
Turning on Ethernet input policing mechanism reduces forwarding performance slightly. The input policing is implemented in software, and processing takes place as each Ethernet frame is received. To ensure high forwarding performance, the policing mechanism is kept to a minimum number of instructions. In most applications, the amount of performance reduction is offset by the value of being able to prevent one or more ports from dominating others.
Ethernet interfaces 1 through 8 include a simple, high-performance ingress traffic policing mechanism to regulate reception, processing, and forwarding of packet traffic to help ensure all Ethernet interfaces receive fair service. The ingress policing mechanism is intended to help reduce the impact on forwarding performance received by subscribers when one or more misbehaving stations attached to different Ethernet interfaces send traffic to the Cisco ONS 15304 at a rate greater than the system can process, or send more traffic than can be forwarded on egress serial links.
The ability to regulate resource consumption on a per-interface basis is often useful in multisubscriber applications where buffer and processing resources need to be controlled and shared among multiple competing traffic sources. While the Cisco ONS 15304 partitions ingress buffer resources for each Ethernet interface, a common processing engine is used to handle all packet traffic, and it is necessary to ensure this resource does not become saturated by a misbehaving Ethernet interface.
The policing mechanism applies only to traffic arriving from the Ethernet interfaces for forwarding to the serial interfaces, and operates at the interface level. (Arrival of traffic from Ethernet interfaces for forwarding onto the Serial interfaces is referred to here as the ingress direction.) The policing mechanism does not attempt to provide fairness between different competing streams of traffic within an interface. To help ensure fairness between multiple traffic streams arriving on an interface, the subscriber-attached equipment should regulate and prioritize the traffic before passing it to the Cisco ONS 15304. The Ethernet input policy mechanism operates independently of protocol, and apply for all traffic including both bridged and IP traffic.
Ethernet ingress policing is implemented through two leaky bucket rate control mechanisms: one for controlling the rate of packet arrivals, and another for controlling the actual data rate taking into account the length of each arriving packet. The two leaky buckets are referred to as the packet rate leaky bucket and the data rate leaky bucket. Each of the two leaky buckets function similarly and differ only in the unit of measure that is being counted and regulated. The packet rate leaky bucket counts packets, while the data rate leaky bucket counts bits.
A leaky bucket can be thought of as holding credits that are used when a packet or a data bit is received and forwarded. The bucket is initially filled up to its maximum depth, and when traffic arrives, the number of credits is checked to see if the frame should be forwarded. As incoming packets are received, the credits will be used up. If there are insufficient credits, the incoming packet is discarded.
The leaky bucket is replenished at an average rate. This replenishment rate controls the average rate that packets or data will be received. The user can configure both the average replenishment rate and the depth of the leaky bucket, and control the average forwarding rate and the briskness of the traffic arrivals, before arriving frames are discarded. Note that the depth of the leaky bucket will allow bursty traffic to arrive at a rate exceeding the average rate, but only for a limited period of time.
The configuration of the ingress policing mechanism takes place through two interface configuration mode commands: ingress-pkt-rate and ingress-data-rate. These two commands set the operating parameters required to control leaky bucket operation. Each of the two leaky buckets can be independently enabled and configured on a per-interface basis. Ingress policing can be enabled on some ports, and not on others, although normally, ingress policing will be enabled on all payload Ethernet interfaces.
Use the ingress-data-rate command to specify the rate at which data will be received, processed, and forwarded. Use the "no" form of the command to disable ingress data rate policing.
| Task | Command |
|---|---|
Enables/disables ingress data rate limiting feature with the specified average rate and burst length parameter. | config# interface ethernet 1 config-if# [no] Ingress-data-rate avg-data-rate data-burst-len |
Use the ingress-pkt-rate command to specify the rate at which packets will be received, processed, and forwarded. Use the "no" form of the command to disable ingress packet rate policing.
| Task | Command |
Specify the average rate to enforce on the given Ethernet. The number-of-links is specified in units of serial links. | config# interface ethernet 1 config-if# [no] ingress-pkt-rate avg-pkt-rate pkt-burst-len |
Ingress packet rate policing is automatically enabled by default, but ingress data rate policing is not enabled by default.
To help summarize, a typical configuration with Ethernet ingress policing enabled would look like this:
interface Ethernet 1 ingress-pkt-rate 2000 50 ingress-data-rate 1500 1000 no shutdown interface Ethernet 2 ingress-pkt-rate 4000 50 ingress-data-rate 4500 1000 no shutdown interface Ethernet 3 ingress-pkt-rate 2000 50 ingress-data-rate 3000 1000 no shutdown interface Ethernet 4 ingress-pkt-rate 2000 50 ingress-data-rate 1500 1000 no shutdown
This section provides two examples to illustrate configuration tasks described in this chapter:
The following example illustrates how to begin interface configuration on an Ethernet interface:
interface Ethernet 1 no shutdown
This example shows how to assign an IP address to Ethernet Interface 1:
interface Ethernet 1 ip address 192.168.1.1 255.255.255.0 no shutdown
These commands enable standard Ethernet Version 2.0 encapsulation on the Ethernet interface 1:
interface ethernet 1 encapsulation arpa
Posted: Thu Feb 24 12:26:10 PST 2000
Copyright 1989 - 2000©Cisco Systems Inc.