Skip to main content
added 66 characters in body
Source Link
Zac67
  • 88.1k
  • 4
  • 73
  • 137

You can't have two devices using the same MAC within the same L2 segment/broadcast domain/VLAN. A duplicate MAC address makes switching unreliable (the switch forwards a frame addressed for the duplicate MAC to the port that it last received a frame on). Also, it disrupts IP-to-MAC address mappings like with ARP or NDP.

Of course both of them get the same IP from DHCP

Apart from using a duplicate MAC address, those devices can be considered broken. RFC 2131 clearly states that a DHCP client is obligated[1] to check the address offered by the server before requesting it:

The client SHOULD[1] perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request.

You need to put both devices into separate segments or VLANs. That way the devices get different IP addresses via DHCP and can be addressed separately on the IP layer (L3), using an intermediate gateway/router (I'd use an L3 switch).

If intermediate routing isn't possible for some reason then you'd need to segregate those devices all the same, e.g. by using separate NICs (with or without separate switches or VLANs) or a proxy. More extensive alternatives include using a translating bridge made in software.

[1] SHOULD in IETF parlance is an obligation, with reasonable exceptions, see RFC 2119:

3. SHOULD     This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

You can't have two devices using the same MAC within the same L2 segment/broadcast domain/VLAN. A duplicate MAC address makes switching unreliable (the switch forwards a frame addressed for the duplicate MAC to the port that it last received a frame on).

Of course both of them get the same IP from DHCP

Apart from using a duplicate MAC address, those devices can be considered broken. RFC 2131 clearly states that a DHCP client is obligated[1] to check the address offered by the server before requesting it:

The client SHOULD[1] perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request.

You need to put both devices into separate segments or VLANs. That way the devices get different IP addresses via DHCP and can be addressed separately on the IP layer (L3), using an intermediate gateway/router (I'd use an L3 switch).

If intermediate routing isn't possible for some reason then you'd need to segregate those devices all the same, e.g. by using separate NICs (with or without separate switches or VLANs) or a proxy. More extensive alternatives include using a translating bridge made in software.

[1] SHOULD in IETF parlance is an obligation, with reasonable exceptions, see RFC 2119:

3. SHOULD     This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

You can't have two devices using the same MAC within the same L2 segment/broadcast domain/VLAN. A duplicate MAC address makes switching unreliable (the switch forwards a frame addressed for the duplicate MAC to the port that it last received a frame on). Also, it disrupts IP-to-MAC address mappings like with ARP or NDP.

Of course both of them get the same IP from DHCP

Apart from using a duplicate MAC address, those devices can be considered broken. RFC 2131 clearly states that a DHCP client is obligated[1] to check the address offered by the server before requesting it:

The client SHOULD[1] perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request.

You need to put both devices into separate segments or VLANs. That way the devices get different IP addresses via DHCP and can be addressed separately on the IP layer (L3), using an intermediate gateway/router (I'd use an L3 switch).

If intermediate routing isn't possible for some reason then you'd need to segregate those devices all the same, e.g. by using separate NICs (with or without separate switches or VLANs) or a proxy. More extensive alternatives include using a translating bridge made in software.

[1] SHOULD in IETF parlance is an obligation, with reasonable exceptions, see RFC 2119:

3. SHOULD     This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

added 29 characters in body
Source Link
Zac67
  • 88.1k
  • 4
  • 73
  • 137

You can't have two devices using the same MAC within the same L2 segment/broadcast domain/VLAN. A duplicate MAC address makes switching unreliable (the switch forwards a frame addressed for the duplicate MAC to the port that it last received a frame on).

Of course both of them get the same IP from DHCP

Apart from using a duplicate MAC address, those devices can be considered broken. RFC 2131 clearly states that a DHCP client is obligated[1] to check the address offered by the server before requesting it:

The client SHOULD[1] perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request.

You need to put both devices into separate segments or VLANs. That way the devices get different IP addresses via DHCP and can be addressed separately on the IP layer (L3), using an intermediate gateway/router (I'd use an L3 switch).

If intermediate routing isn't possible for some reason then you'd need a rather elaborate setup using and a TCP/UDP proxyto segregate those devices all the same, or NAT withe.g. by using separate NICs (with or without separate switches or VLANs) or a proxy ARP. More extensive alternatives include using a translating bridge made in software.

[1] SHOULD in IETF parlance is an obligation, with reasonable exceptions, see RFC 2119:

3. SHOULD     This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

You can't have two devices using the same MAC within the same L2 segment/broadcast domain/VLAN. A duplicate MAC address makes switching unreliable (the switch forwards a frame addressed for the duplicate MAC to the port that it last received a frame on).

Of course both of them get the same IP from DHCP

Apart from using a duplicate MAC address, those devices can be considered broken. RFC 2131 clearly states that a DHCP client is obligated[1] to check the address offered by the server before requesting it:

The client SHOULD[1] perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request.

You need to put both devices into separate segments or VLANs. That way the devices get different IP addresses via DHCP and can be addressed separately on the IP layer (L3), using an intermediate gateway/router (I'd use an L3 switch).

If intermediate routing isn't possible for some reason then you'd need a rather elaborate setup using and a TCP/UDP proxy, or NAT with or without proxy ARP. More extensive alternatives include using a translating bridge made in software.

[1] SHOULD in IETF parlance is an obligation, with reasonable exceptions, see RFC 2119:

3. SHOULD     This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

You can't have two devices using the same MAC within the same L2 segment/broadcast domain/VLAN. A duplicate MAC address makes switching unreliable (the switch forwards a frame addressed for the duplicate MAC to the port that it last received a frame on).

Of course both of them get the same IP from DHCP

Apart from using a duplicate MAC address, those devices can be considered broken. RFC 2131 clearly states that a DHCP client is obligated[1] to check the address offered by the server before requesting it:

The client SHOULD[1] perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request.

You need to put both devices into separate segments or VLANs. That way the devices get different IP addresses via DHCP and can be addressed separately on the IP layer (L3), using an intermediate gateway/router (I'd use an L3 switch).

If intermediate routing isn't possible for some reason then you'd need to segregate those devices all the same, e.g. by using separate NICs (with or without separate switches or VLANs) or a proxy. More extensive alternatives include using a translating bridge made in software.

[1] SHOULD in IETF parlance is an obligation, with reasonable exceptions, see RFC 2119:

3. SHOULD     This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

added 35 characters in body
Source Link
Zac67
  • 88.1k
  • 4
  • 73
  • 137

You can't have two devices using the same MAC within the same L2 segment/broadcast domain/VLAN. A duplicate MAC address makes switching unreliable (the switch forwards a frame addressed for the duplicate MAC to the port that it last received a frame on).

Of course both of them get the same IP from DHCP

Apart from using a duplicate MAC address, those devices can be considered broken. RFC 2131 clearly states that a DHCP client is obligated[1] to check the address offered by the server before requesting it:

The client SHOULD[*1]SHOULD[1] perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request.

You need to put both devices into separate segments or VLANs. That way the devices get different IP addresses via DHCP and can be addressed separately on the IP layer (L3), using an intermediate gateway/router (I'd use an L3 switch).

If intermediate routing isn't possible for some reason then you'd need a rather elaborate setup using and a TCP/UDP proxy, or NAT with or without proxy ARP. More extensive alternatives include using a translating bridge made in software.

[*1][1] SHOULD in IETF parlance is an obligation, with reasonable exceptions, see RFC 2119:

3. SHOULD     This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

You can't have two devices using the same MAC within the same L2 segment/broadcast domain/VLAN. A duplicate MAC address makes switching unreliable (the switch forwards a frame addressed for the duplicate MAC to the port that it last received a frame on).

Of course both of them get the same IP from DHCP

Apart from using a duplicate MAC address, those devices can be considered broken. RFC 2131 clearly states that a DHCP client is obligated to check the address offered by the server before requesting it:

The client SHOULD[*1] perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request.

You need to put both devices into separate segments or VLANs. That way the devices get different IP addresses via DHCP and can be addressed separately on the IP layer (L3), using an intermediate gateway/router (I'd use an L3 switch).

If intermediate routing isn't possible for some reason then you'd need a rather elaborate setup using and a TCP/UDP proxy, or NAT with or without proxy ARP. More extensive alternatives include using a translating bridge made in software.

[*1] SHOULD in IETF parlance is an obligation with reasonable exceptions, see RFC 2119:

3. SHOULD     This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

You can't have two devices using the same MAC within the same L2 segment/broadcast domain/VLAN. A duplicate MAC address makes switching unreliable (the switch forwards a frame addressed for the duplicate MAC to the port that it last received a frame on).

Of course both of them get the same IP from DHCP

Apart from using a duplicate MAC address, those devices can be considered broken. RFC 2131 clearly states that a DHCP client is obligated[1] to check the address offered by the server before requesting it:

The client SHOULD[1] perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request.

You need to put both devices into separate segments or VLANs. That way the devices get different IP addresses via DHCP and can be addressed separately on the IP layer (L3), using an intermediate gateway/router (I'd use an L3 switch).

If intermediate routing isn't possible for some reason then you'd need a rather elaborate setup using and a TCP/UDP proxy, or NAT with or without proxy ARP. More extensive alternatives include using a translating bridge made in software.

[1] SHOULD in IETF parlance is an obligation, with reasonable exceptions, see RFC 2119:

3. SHOULD     This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

added 254 characters in body
Source Link
Zac67
  • 88.1k
  • 4
  • 73
  • 137
Loading
added 425 characters in body
Source Link
Zac67
  • 88.1k
  • 4
  • 73
  • 137
Loading
added 557 characters in body
Source Link
Zac67
  • 88.1k
  • 4
  • 73
  • 137
Loading
added 23 characters in body
Source Link
Zac67
  • 88.1k
  • 4
  • 73
  • 137
Loading
Source Link
Zac67
  • 88.1k
  • 4
  • 73
  • 137
Loading