Filtering Database (FDB) Configuration Guide

1. Introduction

This document describes Filtering Database related configuration and retrieval of status information.

The Filtering Database is also called the Forwarding Database or MAC Address Table. It helps direct network frames to their intended destination. The database has these basic functions:

Dynamic entries:
When a frame ingresses on a port, the port, the classified VLAN, and the source MAC address are saved in the database - this is called a dynamic entry. Over time, the switch builds a table mapping MAC addresses to specific ports in specific VLANs.

Static entries:
In the database, entries can be saved by management, this is called a static entry.

Forwarding:
When a frame ingresses on a port in a classified VLAN, the switch looks in the database to find the destination MAC address in this VLAN. If found, the switch forwards the frame to the corresponding port.

Flooding:
If the destination MAC address in the VLAN is not found in the table, the switch will send the frame to all ports except the one on which it was received.

Aging of dynamic entries:
If a dynamic entry source MAC address is not seen on the learned port for a certain period (age-time), then it is removed from the database.

Flush: The database can be flushed by management, meaning the dynamic entries are deleted and the learning process is restarted.

Filtering:
The switch uses the MAC address table to filter traffic. Frames are only forwarded to the necessary ports. For example, if an ingress frame has a destination MAC address that is learned on the ingress port, it is not forwarded.

2. Static entries.

Static entries are added to the FDB by management and are never removed by aging.
Static entries can have multiple destination ports, meaning that the frame matching the entry is forwarded to all those ports.
Static entries can be deleted by management.

2.1. Add a unicast static entry with one destination port.

The entry has only one destination port.

iPATCH request message:

- ? "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
     filtering-database/filtering-entry"
  : database-id: 0
    address: 00-00-00-00-00-01
    vids: '10'
    entry-type: static
    port-map:
    - port-ref: 2

2.2. Add a multicast static entry with two destination ports:

The entry has multiple destination ports.

iPATCH request message:

- ? "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
     filtering-database/filtering-entry"
  : database-id: 0
    address: 01-00-00-00-00-01
    vids: '10'
    entry-type: static
    port-map:
    - port-ref: 2
    - port-ref: 3

3. Dynamic entries.

Dynamic entries are added due to frames ingressing on a port and can be removed due to aging.
Dynamic entries have only one destination port, the port it was last seen at ingress.
Dynamic entries can be flushed or deleted by management.

3.1. Flush the Filtering Database.

To remove dynamic entries, the Filtering Database can be flushed in different ways:

  • Flush the whole database.

  • Flush all entries on a port.

  • Flush all entries in a VLAN.

  • Flush all entries on a port in a VLAN.

It is controlled by the 'vid' and 'port' input leaves in the 'fdb-flush' action as described in the YANG.

Let’s start by showing the content of the Filtering Database:

FETCH request message:

- "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
   filtering-database/filtering-entry"

FETCH response message:

- ? "/ieee802-dot1q-bridge:bridges/bridge/component/filtering-database/\
     filtering-entry"
  : - database-id: 0
      vids: '1'
      address: 00-00-00-00-01-01
      entry-type: dynamic
      port-map:
      - port-ref: 1
    - database-id: 0
      vids: '10'
      address: 00-00-00-00-00-01
      entry-type: static
      port-map:
      - port-ref: 2
    - database-id: 0
      vids: '10'
      address: 01-00-00-00-00-01
      entry-type: static
      port-map:
      - port-ref: 2
      - port-ref: 3

In our case, the Filtering Database only included 1 dynamic entry:
(VLAN: 1, MAC:`00-00-00-00-01-01` learned at port 1).

Now flush (vid=1, port=1)

POST request message:

- ? "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
     mchp-velocitysp-bridge:fdb-flush"
  : input:
      port: 1
      vid: 1

Show that the dynamic entry is removed from the Filtering Database:

FETCH request message:

- "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
   filtering-database/filtering-entry"

FETCH response message:

- ? "/ieee802-dot1q-bridge:bridges/bridge/component/filtering-database/\
     filtering-entry"
  : - database-id: 0
      vids: '10'
      address: 00-00-00-00-00-01
      entry-type: static
      port-map:
      - port-ref: 2
    - database-id: 0
      vids: '10'
      address: 01-00-00-00-00-01
      entry-type: static
      port-map:
      - port-ref: 2
      - port-ref: 3

3.2. Entry aging timer.

The entry aging timer for all dynamically learned entries in the Filtering Database can be configured.

The aging time is set to 100 seconds.

iPATCH request message:

- ? "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
     filtering-database/aging-time"
  : 100

Let’s confirm that the aging time indeed has been changed:

FETCH request message:

- "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
   filtering-database/aging-time"

FETCH response message:

- ? "/ieee802-dot1q-bridge:bridges/bridge/component/filtering-database/\
     aging-time"
  : 100

3.3. All entry aging.

By default, the dynamic Filtering Database entries are subject to aging and will eventually be deleted.

This disables aging for all entries in the Filtering Database:

iPATCH request message:

- ? "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
     filtering-database/mchp-velocitysp-bridge:ageing-disable"
  : true

Let’s read back the global MAC-aging setting:

FETCH request input data:

- "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
   filtering-database/mchp-velocitysp-bridge:ageing-disable"

FETCH result data:

- ? "/ieee802-dot1q-bridge:bridges/bridge/component/filtering-database/\
     mchp-velocitysp-bridge:ageing-disable"
  : true

3.4. Specific entry aging.

Aging of a learned (dynamic) MAC entry can be disabled by converting it to a static entry.

Let’s start by showing the content of the Filtering Database:

FETCH request message:

- "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
   filtering-database/filtering-entry"

FETCH response message:

- ? "/ieee802-dot1q-bridge:bridges/bridge/component/filtering-database/\
     filtering-entry"
  : - database-id: 0
      vids: '1'
      address: 00-00-00-00-01-01
      entry-type: dynamic
      port-map:
      - port-ref: 1
    - database-id: 0
      vids: '10'
      address: 00-00-00-00-00-01
      entry-type: static
      port-map:
      - port-ref: 2

In our case, the Filtering Database only included 1 dynamic entry (VLAN: 1, MAC: 00-00-00-00-01-01 learned at port '1').

To disable aging on this entry, we will convert it into a static entry:

iPATCH request message:

- ? "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
     filtering-database/filtering-entry"
  : database-id: 0
    address: 00-00-00-00-01-01
    vids: '1'
    entry-type: static
    port-map:
    - port-ref: 1

Let’s dump the Filtering Database again to see that the entry is now static:

FETCH request message:

- "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
   filtering-database/filtering-entry"

FETCH response message:

- ? "/ieee802-dot1q-bridge:bridges/bridge/component/filtering-database/\
     filtering-entry"
  : - database-id: 0
      vids: '1'
      address: 00-00-00-00-01-01
      entry-type: static
      port-map:
      - port-ref: 1
    - database-id: 0
      vids: '10'
      address: 00-00-00-00-00-01
      entry-type: static
      port-map:
      - port-ref: 2

Enable aging again on a MAC address by deleting the static entry:

iPATCH request message:

- ? "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
     filtering-database/\
     filtering-entry[database-id='0'][vids='1'][address='00-00-00-00-01-01']"
  :

The next ingress frame with SMAC '00-00-00-00-01-01' will create a dynamic entry with aging enabled.

3.5. MAC address learning.

By default, dynamic MAC address learning is enabled on all ports; this can be disabled per port.

Disable learning on port '1':

iPATCH request message:

- ? "/ietf-interfaces:interfaces/interface[name='1']/\
     ieee802-dot1q-bridge:bridge-port/\
     mchp-velocitysp-bridge:fdb-learning-disable"
  : true

Let’s confirm that the MAC address learning has been disabled on port '1':

FETCH request message:

- "/ietf-interfaces:interfaces/interface[name='1']/\
   ieee802-dot1q-bridge:bridge-port/\
   mchp-velocitysp-bridge:fdb-learning-disable"

FETCH response message:

- ? "/ietf-interfaces:interfaces/interface/ieee802-dot1q-bridge:bridge-port/\
     mchp-velocitysp-bridge:fdb-learning-disable"
  : true

3.6. One-Shot MAC address learning.

By default in 802.1Q, MAC addresses shall be learned on the last port they are seen on. This means that it is possible for a MAC address to be moved from one port to another (if it is first seen on port A, and then on port B).

If this is not the desired behavior, then this can be disabled by enabling one-shot mode in the switch and the entry will stay learned on the ingress port first seen.
In one-shot mode, aging is disabled, meaning entries can only be removed from the database by management delete or flush.

iPATCH request message:

- ? "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
     filtering-database/mchp-velocitysp-bridge:one-shot"
  : true

Let’s read back the one-shot settings:

FETCH request input data:

- "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
   filtering-database/mchp-velocitysp-bridge:one-shot"

FETCH result data:

- ? "/ieee802-dot1q-bridge:bridges/bridge/component/filtering-database/\
     mchp-velocitysp-bridge:one-shot"
  : true

3.7. MAC entry limit.

The Filtering Database is a resource shared by all ports and has a given limited capacity. By default, there is no restriction on how many entries can be learned on a given port.
An entry limit per port can be configured.

This can be used to protect against an attack, where the database is being filled with entries on one port. When the database is full, no entries can be learned on other ports, which will create undesired flooding. Flooding should be avoided as it can create congestion in the switch and in the network.

Following is an example of how to limit the learning budget to 200 entries on port '1':

iPATCH request message:

- ? "/ietf-interfaces:interfaces/interface[name='1']/\
     ieee802-dot1q-bridge:bridge-port/\
     mchp-velocitysp-bridge:fdb-learning-limit"
  : 200

Let’s read back the MAC-learning budget on port '1':

FETCH request message:

- "/ietf-interfaces:interfaces/interface[name='1']/\
   ieee802-dot1q-bridge:bridge-port/\
   mchp-velocitysp-bridge:fdb-learning-limit"

FETCH response message:

- ? "/ietf-interfaces:interfaces/interface/ieee802-dot1q-bridge:bridge-port/\
     mchp-velocitysp-bridge:fdb-learning-limit"
  : 200

4. Common entries.

These are the functions that are common for both static and dynamic entries.

4.1. Delete an entry in the Filtering Database.

Both static and dynamic entries can be deleted. The entry is identified by VID and MAC address.

Delete the static multicast entry:

iPATCH request message:

- ? "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
     filtering-database/\
     filtering-entry[database-id='0'][vids='10'][address='01-00-00-00-00-01']"
  :

4.2. Get the Filtering Database.

Get all entries in the Filtering Database - dynamic and static.

FETCH request message:

- "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
   filtering-database/filtering-entry"

In the FDB, there is a static unicast and a dynamic address entry.

FETCH response message:

- ? "/ieee802-dot1q-bridge:bridges/bridge/component/filtering-database/\
     filtering-entry"
  : - database-id: 0
      vids: '1'
      address: 00-00-00-00-01-01
      entry-type: dynamic
      port-map:
      - port-ref: 1
    - database-id: 0
      vids: '10'
      address: 00-00-00-00-00-01
      entry-type: static
      port-map:
      - port-ref: 2

5. Advanced operations.

This section is about the more advanced operations.

5.1. Shared VLAN Filtering Database.

For each VID, an FID can be configured. If more VIDs have the same FID, then they share a filtering database, meaning there can only be one entry for a given MAC in all the VIDs with the same FID.
This is known as 'shared' learning mode and can be used to reduce the size of entries in the database, if it is known that the same MAC only exists in one VLAN.

Confirm that the vid-to-fid list is empty:

FETCH request message:

- "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
   bridge-vlan/vid-to-fid"

FETCH response message:

- ? "/ieee802-dot1q-bridge:bridges/bridge/component/bridge-vlan/vid-to-fid"
  : []

Add VID 100 and 200 to FID 10:

IPATCH request message:

- ? "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
     bridge-vlan/vid-to-fid"
  : - vid: 100
      fid: 10
    - vid: 200
      fid: 10

Let’s confirm that the VIDs have been added to the vid-to-fid table:

FETCH request message:

- "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
   bridge-vlan/vid-to-fid"

FETCH response message:

- ? "/ieee802-dot1q-bridge:bridges/bridge/component/bridge-vlan/vid-to-fid"
  : - vid: 100
      fid: 10
    - vid: 200
      fid: 10

Now delete the VID 200 entry:

iPATCH request message:

- ? "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
     bridge-vlan/vid-to-fid[vid='200']"
  :

Let’s confirm that the VID 200 entry has been deleted from the vid-to-fid table:

FETCH request message:

- "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
   bridge-vlan/vid-to-fid"

FETCH response message:

- ? "/ieee802-dot1q-bridge:bridges/bridge/component/bridge-vlan/vid-to-fid"
  : - vid: 100
      fid: 10

The deleted VID 200 is now in 'independent' learning mode.

5.2. Disable flooding of unknown MAC.

By default, frames with an unknown (not learned) destination MAC are flooded on all ports being members of the classified VLAN. If this is not desired, then it is possible to further exclude selected ports from the flooding masks.

This can be used as a protection of the switch and the network against undesired flooding that can create congestion.

The switch will use the most specific of the following 4 flood masks to limit the flooding:

  • IPv4 Multi-Cast

  • IPv6 Multi-Cast

  • Multi-Cast

  • Uni-Cast

If a frame is an IP multicast and an L2 multicast, then the IPv4/6 flood-mask-disable is used.

If all flood masks are empty, then normal flooding as defined by 802.1Q will happen. If all ports are included in all flood-disable-masks, then no flooding will happen.

Following is an example of how to use each of the 4 flood-disable-masks.

Unknown Uni-Cast Flooding is disabled to a set of ports (1,3,5): iPATCH request message (Uni-Cast):

- ? "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
     filtering-database/mchp-velocitysp-bridge:unknown-mac-flooding"
  : uc-disable:
    - '1'
    - '3'
    - '5'

Unknown Multi-Cast Flooding is disabled to a set of ports (2,4,6): iPATCH request message (Multi-Cast):

- ? "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
     filtering-database/mchp-velocitysp-bridge:unknown-mac-flooding"
  : mc-disable:
    - '2'
    - '4'
    - '6'

Unknown IPv4 Multi-Cast Flooding is disabled to a set of ports (1,2,3): iPATCH request message (IPv4-Multi-Cast):

- ? "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
     filtering-database/mchp-velocitysp-bridge:unknown-mac-flooding"
  : ipv4-mc-disable:
    - '1'
    - '2'
    - '3'

Unknown IPv6 Multi-Cast Flooding is disabled to a set of ports (4,5,6): iPATCH request message (IPv6-Multi-Cast):

- ? "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
     filtering-database/mchp-velocitysp-bridge:unknown-mac-flooding"
  : ipv6-mc-disable:
    - '4'
    - '5'
    - '6'

Let’s read back all the unknown-mac-flooding masks to confirm that the settings were accepted:

FETCH request message:

- "/ieee802-dot1q-bridge:bridges/bridge[name='b0']/component[name='c0']/\
   filtering-database/mchp-velocitysp-bridge:unknown-mac-flooding"

FETCH response message:

- ? "/ieee802-dot1q-bridge:bridges/bridge/component/filtering-database/\
     mchp-velocitysp-bridge:unknown-mac-flooding"
  : uc-disable:
    - '1'
    - '3'
    - '5'
    mc-disable:
    - '2'
    - '4'
    - '6'
    ipv4-mc-disable:
    - '1'
    - '2'
    - '3'
    ipv6-mc-disable:
    - '4'
    - '5'
    - '6'