Intel® IXP400 Software

Access-Layer Components: Ethernet Database (IxEthDB) API

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.2Other 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.3Learning/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).

April 2005

IXP400 Software Version 2.0

Programmer’s Guide

158

Document Number: 252539, Revision: 007

 

Page 158
Image 158
Intel IXP400 manual Other MAC Learning/Filtering Usage Models, Learning/Filtering General Characteristics, Port Definitions