Filter
Top Products
Intel
®
IXP400 Software
Access-Layer Components: Ethernet Database (IxEthDB) API
Programmer’s Guide IXP400 Software Version 2.0 April 2005
Document Number: 252539, Revision: 007 159
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