Hi,
I will comment on your choice of addresses below, but don't wonder if the non-routed, pure layer 2 communication (required for addresses from 169.254.0.0/16, see
RFC3927) with device E will fail solely due to this choice!
Your scenario might work with the following asymmetric VLAN configuration of your DGS switch (for a general discussion of the basics of "asymmetric VLANs" see e.g.
here and the links embedded there):
.--------+----+----+----+----+----+----+----+----+-------------.
| Port | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | VLAN Name |
+--------+----+----+----+----+----+----+----+----+-------------+
| VID 3 | X | X | | | | | | X | deviceE |
+--------+----+----+----+----+----+----+----+----+-------------+
| VID 2 | X | X | | X | X | | | | devicesCD |
+--------+----+----+----+----+----+----+----+----+-------------+
| VID 1 | X | X | | X | X | | | X | default |
+--------+----+----+----+----+----+----+----+----+-------------+
| PVID | 1 | 1 | | 2 | 2 | | | 3 | |
`--------+----+----+----+----+----+----+----+----+-------------´
| | | | |
A B C D E
Here an 'X' means: The switch port denominated by the column's title is an untagged member of the VLAN denominated by the row's title.
This perfectly reflects the asymmetric VLAN descriptions and examples given elsewhere, where
VLAN 1 (default) is the shared VLAN and ports 1 and 2 span the shared port group.
VLAN 2 (devicesCD) is the first access VLAN with ports 4 and 5 spanning the corresponding access port group (C, D)
VLAN 3 (deviceE) is the second access VLAN with port 8 alone spanning the corresponding access port group (E)
This allows devices C, D and E to communicate with devices A and B, while devices C and D are disallowed to talk to device E and vice versa.
In addition communication between A and B is allowed, and C and D may also talk to each other.
<EDIT>
Some comment on the communication between devices A-B using "non-routable" addresses from 169.254.0.0/16 and the E-device, that has the "routable" address 198.162.1.76 (or is this a typo and RFC 1918 address 192.168.1.76 was meant instead?):
Addresses from range 169.254.0.0/16 are called "IPv4 Link-Local Addresses" (see also "
zeroconf" or "APIPA", as it is called by Microsoft), see
RFC3927. As mentioned in the RFC, those addresses are not routable and one would expect devices configured with these addresses to communicate with each other only but not with devices that have IP addresses other than 169.254.0.0/16, as your device E.
Nevertheless such a communication may be possible without any routing, as is mentioned in
section 1.8 of RFC3927:
There will be cases when devices with a configured Link-Local address
will need to communicate with a device with a routable address
configured on the same physical link, and vice versa. The rules in
Section 2.6 allow this communication.This demands ...
- ... devices A-B to do hardware address resolution via ARP for any destination IP address (including those outside the range 169.254.0.0/16 like the one for device E) and
- ... device E to do hardware address resolution via ARP for destination IP addresses within the range 169.254.0.0/16 (and hence prevent it from sending those IP packets to a router that might be configured as its default gateway).
Bullet [1] is guaranteed via
section 2.6.2 in RFC3927:
...
If the destination address is a unicast address outside the
169.254/16 prefix, then the host SHOULD use an appropriate routable
IPv4 source address, if it can. If for any reason the host chooses
to send the packet with an IPv4 Link-Local source address (e.g., no
routable address is available on the selected interface), then it
MUST ARP for the destination address and then send its packet, with
an IPv4 Link-Local source address and a routable destination IPv4
address, directly to its destination on the same physical link. The
host MUST NOT send the packet to any router for forwarding.
In the case of a device with a single interface and only an Link-
Local IPv4 address, this requirement can be paraphrased as "ARP for
everything".However, for device E doing ARP when trying to send to IP destinations 169.254.x.y is guaranteed only if it has implemented RFC3927. In this case
section 2.6 of RFC3927 should hold true ...
A host implementing this specification has additional rules to
conform to, whether or not it has an interface configured with an
IPv4 Link-Local address.... and consequently, it should conform to
section 2.6.2 of RFC3927:
... if the destination address is in the
169.254/16 prefix (excluding the address 169.254.255.255, which is
the broadcast address for the Link-Local prefix), then the sender
MUST ARP for the destination address and then send its packet
directly to the destination on the same physical link. This MUST be
done whether the interface is configured with a Link-Local or a
routable IPv4 address.Hence, if you find device E not conforming to this specification, communication will fail between device E and devices A-B.
But as also mentioned in
section 2.6.2 of RFC3927 ...
In many network stacks, achieving this functionality may be as simple
as adding a routing table entry indicating that 169.254/16 is
directly reachable on the local link.... you can force device E in this case to do ARP for 169.254-destinations by telling it, that it is directly connected to 169.254.0.0/16 via its local network interface.
For example, if device E is a Windows PC you can configure this via the following steps:
- Open a command prompt with administrative rights.
- Enter the command netsh int ip show int and notice the name of the local network interface, e.g ETHERNET
- Add a (permanent) route for 169.254.0.0/16: netsh int ip add route 169.254.0.0/16 "ETHERNET" metric=1 (of course instead of ETHERNET use your local interface's name!)
Apart from all that theoretical stuff your choice of address selection for devices A-D (and the management interface of the switch) contradicts RFC3927 in two ways:
- The range for autoconfigured addresses is 169.254.1.0 - 169.254.254.255, where subranges 169.254.0.0/24 and 169.254.255.0/24 are excluded, see section 8 of RFC3927. But the addresses you use for devices A-D and the switch's management interface lie in the first excluded range 169.254.0.0/24. Depending on the implementations of the devices involved using these addresses may result in an unexpected communication behaviour, e.g. communication failure.
- From the last bullet one can conclude, that you configured these addresses manually. Manual configuration contradicts section 1.6 of RFC3927.
So, why for heaven's sake do you use such a configuration? Why, if addresses were obviously configured manually, didn't you configure private IP addresses (
RFC1918) using the same private IP network as the one used for device E (if the address given in your network diagram is a typo, see above)? This would have made things much easier and have spared me to write these lengthy explanations.
</EDIT>
<EDIT2>
For devices A-D and the switch management address you selected mask /8. Unfortunately this was not a good choice, because as a consequence these devices now consider themselves to live in the network 169.0.0.0/8 and regard 169.255.255.255 to be their broadcast address. Hence, if E sends a packet to 169.254.255.255, which is the correct broadcast address for Link-Local IPv4 addresses (because the correct /16 was used in E's configuration), then this packet will not be accepted by these devices due to their misconfigured /8 prefix length.
To overcome this obstacle, for device E you should configure a route to the directly connected network 169.0.0.0/8 instead of 169.254.0.0/16 (with Windows you would have to configure
netsh int ip add route 169.0.0.0/8 "<if-name>" metric=1). But this makes your configuration even more nasty, as it is anyway. If device E has a default route to reach the Internet, all destinations that use public addresses 169.x.y.z where x<>254 will not be reachable anymore. Because of that, changing the prefix length of the other devices from /8 to /16 would of course be the better choice.
</EDIT2>
PT
