It does not support unlimited when running as a Cable modem Bridge, the spec says at least 64 but that is all that is guaranteed, Arris modem spec sheets don't list what they support, you could call up Arris and ask them. When you use BSOD mode however, the CM is no longer a Bridge and forwards unlimited MAC addresses See latter part of this post.
here is the relevant blurb from MULPI spec
9.1.2.1 MAC Address Acquisition
The CM maintains a forwarding database (bridging table) including entries for the CM's own MAC address and
CPE MAC addresses.
The CM MUST acquire CPE Ethernet MAC addresses, either from the provisioning process or from learning, until
the CM acquires its maximum number of CPE MAC addresses (the lesser of the Max CPE from the config file
(Annex C.1.1.7, Max CPE) or a device-dependent value). Once the CM acquires its maximum number of CPE MAC
addresses, then newly discovered CPE MAC addresses MUST NOT replace previously acquired addresses. The CM
MUST support acquisition of at least 64 CPE MAC addresses.
The CM MUST NOT learn any MAC addresses for its forwarding database prior to registration. The CM MUST
allow configuration of CPE MAC addresses during the provisioning process (up to its maximum number of CPE
addresses) to support configurations in which learning is not practical, nor desired. The CM MUST give provisioned
addresses precedence over learned addresses when adding entries to the forwarding database. The CM MUST NOT
age out CPE MAC addresses. The CM MUST place all acquired CPE MAC addresses in its forwarding database
[RFC 1493].
In order to allow modification of user MAC addresses or movement of the CM, addresses are not retained in nonvolatile storage. On a CM reset (e.g., power cycle), the CM MUST discard all provisioned and learned addresses.
In addition, a CM can be configured such that it will discard any dynamically learned MAC addresses associated
with a CMCI port if it has determined that the link has been lost for that port or that the port has been disabled
(interface status changed from 'UP' to 'DOWN'). This behavior is controlled via the MAC Address Learning
configuration file TLV as defined in Section C.1.2.18. When the MAC Address Learning Control sub-TLV is set to
'Remove', if the CM determines that a CMCI link has been lost or that the interface has been administratively
disabled, the CM MUST initiate the MAC Address Learning Holdoff timer and perform the following for
dynamically learned MAC addresses associated with the CMCI:
• If link is re-established on the interface or the interface status is transitioned back to 'UP' before the timer
expires, the modem clears the timer and no further action is taken.
• If the timer expires without re-establishing link or without the interface status transitioning back to 'UP', the CM
removes all learned MAC addresses associated with the interface on which link was lost, and transmits a CMStatus Message indicating the MAC addresses that were removed (if such reporting has been enabled).
Once a MAC address has been removed, the CM is able to continue acquiring MAC addresses up to the maximum
permitted as noted above. The MAC address learning configuration TLV is not applicable to a statically provisioned
MAC address or eSAFE MAC addresses, and therefore does not affect the learning and retention of those addresses
in any way.
On Arris modems you can turn off the Docsis specific behavior with arrisCmDoc30SetupL2VPNPromiscuousMode
the info on that:
Set to true(1) to enable L2VPN promiscuous mode. When in promiscuous mode all
upstream and downstream L2VPN traffic will be bridged by the CM regardless of source or
destination MAC address. Learned MAC addresses from L2VPN traffic will not be added to the
CPE table. Set to false(2) to disable the feature. When set to false all unknown
(i.e. previously unlearned) unicast and broadcast L2VPN traffic will be processed in accordance
with the DOCSIS MULPI specification as required by the BSoD L2VPN specification.
When you switch into promiscuous mode and configure the appropriate BSOD information on CM and CMTS, the CM becomes a forwarder rather than a bridge and can forward any number of mac addresses.
From BSOD Spec
5.2.2 Point-to-Point and Multipoint L2VPN Forwarding Modes
This standard uses the term layer 2 forwarding rather than bridging because commercial L2VPN service can be
offered without necessarily implementing a learning MAC Layer Bridge on the CMTS as defined by [802.1Q]. The
CMTS MAY implement a Point-to-Point layer 2 forwarding mode that forwards packets between a single NSI port
and a single CM (or SF). If the CMTS does implement a learning MAC layer bridge between NSI and RF interfaces,
this standard terms it the Multipoint layer 2 forwarding mode.
In Point-to-Point L2VPN Forwarding Mode, each attachment circuit has a different NSI Encapsulation value. For
example, with IEEE 802.1Q encapsulation, each attachment circuit (i.e., CM or SF) is configured with a different
802.1Q VLAN ID. Similarly, using point-to-point Ethernet over MPLS [RFC 4385] [RFC 4448] encapsulation, each
attachment circuit is configured with a different pseudowire identifier. In Point-to-Point mode, the L2VPN
forwarder simply forwards upstream and downstream data between one NSI port and one attachment circuit, without
learning the MAC addresses of CPE packets. The logical VPNID to which a CM or SF attaches should be
configured with the attachment circuit, but its value is otherwise ignored by the CMTS in Point-to-Point forwarding
mode. An external L2VPN Bridge on the cable operator's backbone actually performs the layer 2 MAC address
learning for each L2VPN, and bridges packets between the VLAN IDs or pseudo-wires of the packets within their
NSI Encapsulation.
Most modern CMTSes do not learn mac address when using BSOD and just forward the frames out the appropriate VLAN interface, like a normal switch port
It does not support unlimited when running as a Cable modem Bridge, the spec says at least 64 but that is all that is guaranteed, Arris modem spec sheets don't list what they support, you could call up Arris and ask them. When you use BSOD mode however, the CM is no longer a Bridge and forwards unlimited MAC addresses See latter part of this post.
here is the relevant blurb from MULPI spec
9.1.2.1 MAC Address Acquisition
The CM maintains a forwarding database (bridging table) including entries for the CM's own MAC address and
CPE MAC addresses.
The CM MUST acquire CPE Ethernet MAC addresses, either from the provisioning process or from learning, until
the CM acquires its maximum number of CPE MAC addresses (the lesser of the Max CPE from the config file
(Annex C.1.1.7, Max CPE) or a device-dependent value). Once the CM acquires its maximum number of CPE MAC
addresses, then newly discovered CPE MAC addresses MUST NOT replace previously acquired addresses. The CM
MUST support acquisition of at least 64 CPE MAC addresses.
The CM MUST NOT learn any MAC addresses for its forwarding database prior to registration. The CM MUST
allow configuration of CPE MAC addresses during the provisioning process (up to its maximum number of CPE
addresses) to support configurations in which learning is not practical, nor desired. The CM MUST give provisioned
addresses precedence over learned addresses when adding entries to the forwarding database. The CM MUST NOT
age out CPE MAC addresses. The CM MUST place all acquired CPE MAC addresses in its forwarding database
[RFC 1493].
In order to allow modification of user MAC addresses or movement of the CM, addresses are not retained in nonvolatile storage. On a CM reset (e.g., power cycle), the CM MUST discard all provisioned and learned addresses.
In addition, a CM can be configured such that it will discard any dynamically learned MAC addresses associated
with a CMCI port if it has determined that the link has been lost for that port or that the port has been disabled
(interface status changed from 'UP' to 'DOWN'). This behavior is controlled via the MAC Address Learning
configuration file TLV as defined in Section C.1.2.18. When the MAC Address Learning Control sub-TLV is set to
'Remove', if the CM determines that a CMCI link has been lost or that the interface has been administratively
disabled, the CM MUST initiate the MAC Address Learning Holdoff timer and perform the following for
dynamically learned MAC addresses associated with the CMCI:
• If link is re-established on the interface or the interface status is transitioned back to 'UP' before the timer
expires, the modem clears the timer and no further action is taken.
• If the timer expires without re-establishing link or without the interface status transitioning back to 'UP', the CM
removes all learned MAC addresses associated with the interface on which link was lost, and transmits a CMStatus Message indicating the MAC addresses that were removed (if such reporting has been enabled).
Once a MAC address has been removed, the CM is able to continue acquiring MAC addresses up to the maximum
permitted as noted above. The MAC address learning configuration TLV is not applicable to a statically provisioned
MAC address or eSAFE MAC addresses, and therefore does not affect the learning and retention of those addresses
in any way.
On Arris modems you can turn off the Docsis specific behavior with arrisCmDoc30SetupL2VPNPromiscuousMode
the info on that:
Set to true(1) to enable L2VPN promiscuous mode. When in promiscuous mode all
upstream and downstream L2VPN traffic will be bridged by the CM regardless of source or
destination MAC address. Learned MAC addresses from L2VPN traffic will not be added to the
CPE table. Set to false(2) to disable the feature. When set to false all unknown
(i.e. previously unlearned) unicast and broadcast L2VPN traffic will be processed in accordance
with the DOCSIS MULPI specification as required by the BSoD L2VPN specification.
When you switch into promiscuous mode and configure the appropriate BSOD information on CM and CMTS, the CM becomes a forwarder rather than a bridge and can forward any number of mac addresses.
From BSOD Spec
5.2.2 Point-to-Point and Multipoint L2VPN Forwarding Modes
This standard uses the term layer 2 forwarding rather than bridging because commercial L2VPN service can be
offered without necessarily implementing a learning MAC Layer Bridge on the CMTS as defined by [802.1Q]. The
CMTS MAY implement a Point-to-Point layer 2 forwarding mode that forwards packets between a single NSI port
and a single CM (or SF). If the CMTS does implement a learning MAC layer bridge between NSI and RF interfaces,
this standard terms it the Multipoint layer 2 forwarding mode.
In Point-to-Point L2VPN Forwarding Mode, each attachment circuit has a different NSI Encapsulation value. For
example, with IEEE 802.1Q encapsulation, each attachment circuit (i.e., CM or SF) is configured with a different
802.1Q VLAN ID. Similarly, using point-to-point Ethernet over MPLS [RFC 4385] [RFC 4448] encapsulation, each
attachment circuit is configured with a different pseudowire identifier. In Point-to-Point mode, the L2VPN
forwarder simply forwards upstream and downstream data between one NSI port and one attachment circuit, without
learning the MAC addresses of CPE packets. The logical VPNID to which a CM or SF attaches should be
configured with the attachment circuit, but its value is otherwise ignored by the CMTS in Point-to-Point forwarding
mode. An external L2VPN Bridge on the cable operator's backbone actually performs the layer 2 MAC address
learning for each L2VPN, and bridges packets between the VLAN IDs or pseudo-wires of the packets within their
NSI Encapsulation.
Most modern CMTSes do not learn mac address when using BSOD and just forward the frames out the appropriate VLAN interface, like a normal switch port
Hi,
can a CM learn and age MAC addresses but not operating in BSOD mode?