Bottom line: Coordinate the address-allocation policy before joining guest networks from multiple clusters. Keep the configured generation prefix and the actual addresses of existing guests in separate parts of the review.
\nThe Proxmox datacenter reference defines mac_prefix as the prefix for automatically generated virtual-guest MAC addresses, defaulting to BC:24:11. It identifies that default as the IEEE OUI assigned to Proxmox and permits its use on local networks not directly reachable by the public. For clusters sharing guest networks, it recommends extending the default prefix or generating a valid custom prefix to reduce collision risk, with logical network separation as an alternative. For publicly accessible guests, it recommends obtaining an organization’s own OUI or coordinating with the relevant network or hosting administrators.
This article addresses the documented automatic-allocation policy, not a guarantee of unique addresses across every network. It does not establish that changing the prefix renumbers existing guests or approve an unreviewed custom MAC-address format.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE recommends a shared-network map listing the clusters, guest network boundaries and responsible administrators. Record the current prefix and observed guest-address population independently. Resolve an undocumented shared segment before treating two separately managed clusters as unrelated address-allocation domains.
\nFor a proposed two-cluster expansion, have the administrators allocate distinct valid prefixes or choose reviewed logical network separation. Use the documentation’s examples only as illustrations, not as universally reserved values. Keep the final policy in a common record that both teams can consult before creating new guests.
\nInspect existing manually assigned addresses separately. Do not assume a configuration edit repairs an already duplicated address or changes a running guest’s identity. Plan any existing-guest correction as its own authorized operation with the guest and network owners.
\nFor publicly reachable guest networks, involve the responsible network or hosting administrator before choosing an allocation. Preserve the prior configuration and avoid changing guest identities during an unrelated maintenance task. Name the owner who updates the policy when another cluster or network is added.
\nProposed verification: on an approved isolated network, inspect the effective prefixes and create disposable guests through the intended provisioning path. Compare their observed addresses with the reviewed policy and current address inventory. Record manual overrides explicitly rather than treating them as generated examples.
\nCheck that the tested guests attach to the intended network and perform a harmless approved connectivity transaction. Preserve the actual addresses and cluster references in the protected operational record. Accept only the observed allocation behavior; leave existing-guest remediation and public-network authorization to their separately approved checks.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: Coordinate the address-allocation policy before joining guest networks from multiple clusters. Keep the configured generation prefix and the actual addresses of existing guests in separate parts of the review.\nSource fact: what the authority says\nThe Proxmox datacenter reference defines mac_prefix as the prefix for automatically generated virtual-guest MAC addresses, defaulting to BC:24:11. It identifies that default as the IEEE OUI assigned to Proxmox and permits its use on local networks not directly reachable by the public. For clusters sharing guest networks, it recommends extending the default prefix or generating a valid custom prefix to reduce collision risk, with logical network separation as an alternative. For publicly accessible guests, it recommends obtaining an organization’s own OUI or coordinating with the relevant network or hosting administrators.\nWhat the source does not establish\nThis article addresses the documented automatic-allocation policy, not a guarantee of unique addresses across every network. It does not establish that changing the prefix renumbers existing guests or approve an unreviewed custom MAC-address format.\nApplicability questions\n\nWhich clusters share or will share the same guest Layer 2 networks?\nWhat generation prefix is configured in each cluster?\nWhich actual guest addresses and manually assigned exceptions already exist?\nAre any guests publicly reachable, requiring a separately coordinated allocation policy?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a shared-network map listing the clusters, guest network boundaries and responsible administrators. Record the current prefix and observed guest-address population independently. Resolve an undocumented shared segment before treating two separately managed clusters as unrelated address-allocation domains.\nFor a proposed two-cluster expansion, have the administrators allocate distinct valid prefixes or choose reviewed logical network separation. Use the documentation’s examples only as illustrations, not as universally reserved values. Keep the final policy in a common record that both teams can consult before creating new guests.\nInspect existing manually assigned addresses separately. Do not assume a configuration edit repairs an already duplicated address or changes a running guest’s identity. Plan any existing-guest correction as its own authorized operation with the guest and network owners.\nFor publicly reachable guest networks, involve the responsible network or hosting administrator before choosing an allocation. Preserve the prior configuration and avoid changing guest identities during an unrelated maintenance task. Name the owner who updates the policy when another cluster or network is added.\nVerification and evidence\nProposed verification: on an approved isolated network, inspect the effective prefixes and create disposable guests through the intended provisioning path. Compare their observed addresses with the reviewed policy and current address inventory. Record manual overrides explicitly rather than treating them as generated examples.\nCheck that the tested guests attach to the intended network and perform a harmless approved connectivity transaction. Preserve the actual addresses and cluster references in the protected operational record. Accept only the observed allocation behavior; leave existing-guest remediation and public-network authorization to their separately approved checks.\nOfficial references\n\nProxmox — datacenter.cfg(5) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: Coordinate the address-allocation policy before joining guest networks from multiple clusters. Keep the configured generation prefix and the actual addresses of existing guests in separate parts of the review.\n\n## Source fact: what the authority says\n\nThe [Proxmox datacenter reference](https://pve.proxmox.com/pve-docs/datacenter.cfg.5.html) defines mac_prefix as the prefix for automatically generated virtual-guest MAC addresses, defaulting to BC:24:11. It identifies that default as the IEEE OUI assigned to Proxmox and permits its use on local networks not directly reachable by the public. For clusters sharing guest networks, it recommends extending the default prefix or generating a valid custom prefix to reduce collision risk, with logical network separation as an alternative. For publicly accessible guests, it recommends obtaining an organization’s own OUI or coordinating with the relevant network or hosting administrators.\n\n## What the source does not establish\n\nThis article addresses the documented automatic-allocation policy, not a guarantee of unique addresses across every network. It does not establish that changing the prefix renumbers existing guests or approve an unreviewed custom MAC-address format.\n\n## Applicability questions\n\n- Which clusters share or will share the same guest Layer 2 networks?\n\n- What generation prefix is configured in each cluster?\n\n- Which actual guest addresses and manually assigned exceptions already exist?\n\n- Are any guests publicly reachable, requiring a separately coordinated allocation policy?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends a shared-network map listing the clusters, guest network boundaries and responsible administrators. Record the current prefix and observed guest-address population independently. Resolve an undocumented shared segment before treating two separately managed clusters as unrelated address-allocation domains.\n\nFor a proposed two-cluster expansion, have the administrators allocate distinct valid prefixes or choose reviewed logical network separation. Use the documentation’s examples only as illustrations, not as universally reserved values. Keep the final policy in a common record that both teams can consult before creating new guests.\n\nInspect existing manually assigned addresses separately. Do not assume a configuration edit repairs an already duplicated address or changes a running guest’s identity. Plan any existing-guest correction as its own authorized operation with the guest and network owners.\n\nFor publicly reachable guest networks, involve the responsible network or hosting administrator before choosing an allocation. Preserve the prior configuration and avoid changing guest identities during an unrelated maintenance task. Name the owner who updates the policy when another cluster or network is added.\n\n## Verification and evidence\n\nProposed verification: on an approved isolated network, inspect the effective prefixes and create disposable guests through the intended provisioning path. Compare their observed addresses with the reviewed policy and current address inventory. Record manual overrides explicitly rather than treating them as generated examples.\n\nCheck that the tested guests attach to the intended network and perform a harmless approved connectivity transaction. Preserve the actual addresses and cluster references in the protected operational record. Accept only the observed allocation behavior; leave existing-guest remediation and public-network authorization to their separately approved checks.\n\n## Official references\n\n- [Proxmox — datacenter.cfg(5)](https://pve.proxmox.com/pve-docs/datacenter.cfg.5.html) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/coordinate-proxmox-guest-mac-prefixes-across-shared-cluster-networks/", "url": "https://update.dsesecurity.com/updates/coordinate-proxmox-guest-mac-prefixes-across-shared-cluster-networks/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/coordinate-proxmox-guest-mac-prefixes-across-shared-cluster-networks/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Networks & Infrastructure", "item": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "@type": "ListItem", "position": 3, "name": "Coordinate Proxmox guest MAC prefixes across shared cluster networks", "item": "https://update.dsesecurity.com/updates/coordinate-proxmox-guest-mac-prefixes-across-shared-cluster-networks/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/coordinate-proxmox-guest-mac-prefixes-across-shared-cluster-networks/#article", "identifier": "https://update.dsesecurity.com/updates/coordinate-proxmox-guest-mac-prefixes-across-shared-cluster-networks/", "url": "https://update.dsesecurity.com/updates/coordinate-proxmox-guest-mac-prefixes-across-shared-cluster-networks/", "headline": "Coordinate Proxmox guest MAC prefixes across shared cluster networks", "description": "The Proxmox datacenter reference recommends distinct extended or custom MAC prefixes when clusters share guest networks.", "abstract": "The Proxmox datacenter reference recommends distinct extended or custom MAC prefixes when clusters share guest networks. Its default OUI is intended for local use, with public-network coordination reviewed separately.", "articleBody": "Bottom line: Coordinate the address-allocation policy before joining guest networks from multiple clusters. Keep the configured generation prefix and the actual addresses of existing guests in separate parts of the review.\nSource fact: what the authority says\nThe Proxmox datacenter reference defines mac_prefix as the prefix for automatically generated virtual-guest MAC addresses, defaulting to BC:24:11. It identifies that default as the IEEE OUI assigned to Proxmox and permits its use on local networks not directly reachable by the public. For clusters sharing guest networks, it recommends extending the default prefix or generating a valid custom prefix to reduce collision risk, with logical network separation as an alternative. For publicly accessible guests, it recommends obtaining an organization’s own OUI or coordinating with the relevant network or hosting administrators.\nWhat the source does not establish\nThis article addresses the documented automatic-allocation policy, not a guarantee of unique addresses across every network. It does not establish that changing the prefix renumbers existing guests or approve an unreviewed custom MAC-address format.\nApplicability questions\n\nWhich clusters share or will share the same guest Layer 2 networks?\nWhat generation prefix is configured in each cluster?\nWhich actual guest addresses and manually assigned exceptions already exist?\nAre any guests publicly reachable, requiring a separately coordinated allocation policy?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a shared-network map listing the clusters, guest network boundaries and responsible administrators. Record the current prefix and observed guest-address population independently. Resolve an undocumented shared segment before treating two separately managed clusters as unrelated address-allocation domains.\nFor a proposed two-cluster expansion, have the administrators allocate distinct valid prefixes or choose reviewed logical network separation. Use the documentation’s examples only as illustrations, not as universally reserved values. Keep the final policy in a common record that both teams can consult before creating new guests.\nInspect existing manually assigned addresses separately. Do not assume a configuration edit repairs an already duplicated address or changes a running guest’s identity. Plan any existing-guest correction as its own authorized operation with the guest and network owners.\nFor publicly reachable guest networks, involve the responsible network or hosting administrator before choosing an allocation. Preserve the prior configuration and avoid changing guest identities during an unrelated maintenance task. Name the owner who updates the policy when another cluster or network is added.\nVerification and evidence\nProposed verification: on an approved isolated network, inspect the effective prefixes and create disposable guests through the intended provisioning path. Compare their observed addresses with the reviewed policy and current address inventory. Record manual overrides explicitly rather than treating them as generated examples.\nCheck that the tested guests attach to the intended network and perform a harmless approved connectivity transaction. Preserve the actual addresses and cluster references in the protected operational record. Accept only the observed allocation behavior; leave existing-guest remediation and public-network authorization to their separately approved checks.\nOfficial references\n\nProxmox — datacenter.cfg(5) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T19:49:30+00:00", "dateModified": "2026-10-29T19:50:09+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/coordinate-proxmox-guest-mac-prefixes-across-shared-cluster-networks/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/coordinate-proxmox-guest-mac-prefixes-across-shared-cluster-networks/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Coordinate Proxmox guest MAC prefixes across shared cluster networks" }, "articleSection": [ "Networks & Infrastructure" ], "keywords": [ "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 517, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Proxmox — datacenter.cfg(5)", "url": "https://pve.proxmox.com/pve-docs/datacenter.cfg.5.html" } } ] } }