Filter
Top Products
Intel
®
IXP400 Software
Access-Layer Components: Ethernet Database (IxEthDB) API
April 2005 IXP400 Software Version 2.0 Programmer’s Guide
158 Document Number: 252539, Revision: 007
— Port 0 searches for the destination address (00:00:00:00:00:01) in its learning tree, it is
found therefore Port 0 knows that both Node 1 and Node 2 are connected on the same side
of the network, and this network already has a frame forwarder (in this case Hub A) – the
frame is filtered (dropped) to prevent unnecessary propagation
10.3.1.2 Other MAC Learning/Filtering Usage Models
If a terminal (source of Ethernet traffic on the network) is moved from one NPE port to another,
IxEthDB is responsible for ensuring the consistency of the XScale Learning/Filtering Database.
The Intel XScale core database and NPE Learning/Filtering Trees are updated within one second
of the terminal move being detected. The change is detected when traffic is first received from the
terminal on the new NPE port. This behavior is described as “migrating”.
One of the advantages of the split NPE/XScale model is that the NPE can attempt to identify if an
incoming frame is destined for another known port in the system. For example, the NPE Learning/
Filtering Tree for port 1 may contain an entry that shows the frames destination MAC address as
having been learned on port 2. The NPE will include the destination port id in the
IX_OSAL_MBUF header fields as part of the receive callback.
There are some situations in which the NPE Learning/Filtering Trees may not have learned the
proper destination port for a received packet. The NPEs will then pass the packet to the IxEthAcc
component to allow it to search the XScale Learning/Filtering Database for the proper destination
port. If the system is operating in a bridging or switching fashion, the XScale Learning/Filtering
Database will know the appropriate port to send the packet out on. If the XScale Learning/Filtering
Database does not know the appropriate destination port, the receive callback function will set the
port ID field in the IX_OSAL_MBUF header to a value of IX_ETH_DB_UNKNOWN_PORT,
indicating that the destination port of this packet is unknown. The client may then broadcast on all
ports in the hopes that a node somewhere on the network will respond.
10.3.1.3 Learning/Filtering General Characteristics
Port Definitions
IxEthDB is not strictly limited to the NPE-based Ethernet ports available on the IXP4XX product
line or IXC1100 control plane processor. The user can define up to 255 ports (including the one to
three Ethernet NPE ports), which will be recognized by the component. Adding user-defined ports
(such as one representing a PCI-based Ethernet adapter) allows the manual provision of MAC
address/port records to the XScale Learning/ Filtering Database and the NPE Learning/Filtering
Trees via the IxEthDB API. The NPEs will then be able to detect that an incoming frame is
destined for the user-defined port, and report the destination port ID in the IX_OSAL_MBUF
header for the frame.
These definitions are static and cannot be changed at run-time. The only requirement is that port ID
0, 1, and 2 are reserved for Ethernet NPE B, NPE C, and NPE A, respectively, and cannot be used
for user ports (nor should they be removed). Port IDs therefore range between 0 and 0xFE.
Port definitions are located in the public include file xscale_sw/src/include/IxEthDBPortDefs.h.
All user ports must be defined as ETH_GENERIC with NO_CAPABILITIES.
Do not change or remove the first three ports — the IxEthAcc component relies on this definition.
Accordingly, IX_ETH_DB_NUMBER_OF_PORTS should have a value of at least 3 at any time.
Other components may have also defined their own ports (see the header file for up-to-date
information).