View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
2049 | RackTables | 802.1Q VLANs | public | 2021-08-24 15:53 | 2021-09-05 14:46 |
Reporter | iopsthecloud | Assigned To | infrastation | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Product Version | 0.21.4 | ||||
Summary | 2049: unable to have same mac address on 2 objects enven if thse objects are on 2 different 802.3 domains. | ||||
Description | We have 2 use cases with identical MAC addresses. The first concerns MAC addresses that are reused on separate and isolated Ethernet segments. This can happen in particular in data centres that are independent of each other. The second use case concerns special interfaces such as CARP interfaces under *BSD for which MAC addresses are dynamically constructed from external elements. This is the same as the previous case of having duplicate MAC addresses on separate Ethernet segments. | ||||
Tags | No tags attached. | ||||
The currently implemented data model allows a port MAC address to be duplicate only on a port of the same device. in other words, any two different devices must not use the same MAC address. To the best of my knowledge, this is consistent with the definition of Ethernet as an IEEE standard (less the special-purpose destination addresses, which are not assigned to ports and thus not documented in RackTables). If you can point to a particular technical specification to support the need to legalize duplicate source addresses, please do so. However, it would take time to relax the database constraint safely. Alternatively, you could make the MAC addresses unique (so long as you seem to be in control of the address value), which would automatically eliminate a space for potential fault if things go wrong and segments that are not bridged now become bridged later. |
|
MAC address can be duplicated at many times. Each vendor have a pool delegated by IANA https://bugs.racktables.org/view.php?id=2049#c4353 and pools used for special purpose, like https://www.iana.org/go/rfc5798 As reminder, the uniqueness of address MAC must be true at the LLC/MAC level of the OSI Model. At the vendor scale, MAC address are not unique globally, it must be unique in the broadcast domain. About the constraint, we already patch our version, it's not a DB constraint. racktables/inc/database.php <code> function assertUniqueL2Addresses ($db_l2addresses, $my_object_id) </code> On our side, we are reimplementing the function to have better granularity to take care of the MAC address prefix and if ports are linked to the same broadcast domain. |
|
Thank you for your comments. It is a bit unfortunate that we were talking past each other, but I have other work to do. | |
Date Modified | Username | Field | Change |
---|---|---|---|
2021-08-24 15:53 | iopsthecloud | New Issue | |
2021-08-26 15:25 | infrastation | Note Added: 0004353 | |
2021-08-26 18:34 | iopsthecloud | Note Added: 0004355 | |
2021-09-05 14:46 | infrastation | Assigned To | => infrastation |
2021-09-05 14:46 | infrastation | Status | new => closed |
2021-09-05 14:46 | infrastation | Resolution | open => no change required |
2021-09-05 14:46 | infrastation | Note Added: 0004357 |