Intel IXP400 manual Port Dependency Map, Provisioning Static and Dynamic Entries, Aging

Intel® IXP400 Software

Access-Layer Components: Ethernet Database (IxEthDB) API

Warning: The id value assigned to NPE ports in IxEthDbPortDefs.h may not be the same as the value used to identify ports in the IXP_BUF fields written by the NPE’s, as documented in Table 21. The Ethernet device driver for the supported operating systems may enumerate the NPE ports differently as well.

Limits for Number of Supported Learning/Filtering Entries

Each NPE is capable of storing 511 MAC address entries in its NPE Learning/Filtering Tree. The XScale Learning/Filtering Database will handle all the addresses for all NPEs plus any number of addresses required for user-defined ports, up to 4096 records by default. This will suffice for the three NPEs and a considerable number of user-defined ports plus operating headroom. If the value is not large enough the user can tweak database pre-allocation structures by changing ixp400_xscale_sw/src/ethDB/include/IxEthDB_p.h.

It is not recommended to add more than 511 addresses per NPE port. While IxEthDB itself can learn more than 511 entries per port, the NPEs cannot use more than 511. In the event that more than 511 entries are defined for an NPE port, not all frames will be properly filtered.

Port Dependency Map

The IxEthDB API provides functions to set or retrieve Port Dependency Maps. The Port Dependency Maps are used to share filtering information between ports. By adding a port into another port's dependency map, the target port filtering data will import the filtering data from the port it depends on. Any changes to filtering data for a port — such as adding, updating or removing records — will trigger updates in the filtering information for all the ports depending on the updated port.

For example, if ports 2 and 3 are set in the port 0 dependency map the filtering information for port 0 will also include the filtering information from ports 2 and 3. Adding a record to port 2 will also trigger an update not only on port 2 but also on port 0.

This feature is useful in conjunction with the NPE destination port lookup service, where the NPE searches for the destination MAC of a received frame in its tree and, if found, copies the port ID from the record into the buffer header. This saves the Intel XScale core from having to perform this lookup in a switching application.

Provisioning Static and Dynamic Entries

The IxEthDB API provides a function allowing the user to statically provision entries in the XScale Learning/Filtering Database. Dynamic entries may also be provisioned via the API. It is important to note that if a static MAC address is provisioned for port X, but later a frame having this source MAC address is detected arriving from port Y, the record in the database will be updated from X to Y and the record will no longer be marked as static.

Aging

Aging is the process through which inactive MAC addresses are removed from the filtering database. At periodic intervals, the XScale Learning/Filtering Database is examined to determine if any of the learned (or dynamically provisioned) MAC addresses have become inactive during the last period (i.e., no traffic has originated from those MAC addresses/port pairs for a period of roughly 15 minutes). If so, they are removed from the XScale Learning/Filtering Database.

In the IXP400 software, if the NPE finds a match to a source MAC address in its NPE Learning/ Filtering Tree as part of the learning process, the NPE will update the record to indicate that the transmitting station is still active. At defined intervals, the NPE Learning/Filtering Tree data is merged into the XScale Learning/Filtering Database, so that it reflects the current age of MAC

Programmer’s Guide	IXP400 Software Version 2.0	April 2005
	Document Number: 252539, Revision: 007	159