• October 28, 2020, 07:39:19 PM
  • Welcome, Guest
Please login or register.

Login with username, password and session length
Advanced search  


This Forum Beta is ONLY for registered owners of D-Link products in the USA for which we have created boards at this time.

Author Topic: DGS-1100-08 - bridge two VLAN/subnet?  (Read 3342 times)


  • Level 1 Member
  • *
  • Posts: 2
DGS-1100-08 - bridge two VLAN/subnet?
« on: October 31, 2017, 10:17:13 AM »


If it is possible, how may I use DGS-1100-08 to setup forwarding between two subnets?
So that Device A and B can connect to Device C, D and E, and Device C and D can connect to Device A and B?
It is fine if Device C and D can connect to Device E, but it is not a requirement, as is Device E does not necessarily have to be segregated from Device C and D.

Changing IP's is unfortunately not an option.

Illustrated below:

Google Drawings

Code: [Select]
Model No.: DGS-1100-08
H/W Ver.: B1
F/W Ver.: 1.00.016


  • Poweruser

  • ▲▲
  • *****
  • Posts: 49296
  • D-Link Global Forum Moderator
    • Router Troubleshooting
Re: DGS-1100-08 - bridge two VLAN/subnet?
« Reply #1 on: October 31, 2017, 10:22:35 AM »


  • What region are you located?

Have you reviewed the user manual regarding this?

"Nothing Funny about It...." We are not here to Impress anyone! You have a be a COMPETENT user first to under stand COMPETENT help!


  • Level 4 Member
  • ****
  • Posts: 439
Re: DGS-1100-08 - bridge two VLAN/subnet?
« Reply #2 on: November 01, 2017, 03:02:47 AM »


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, 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.

Some comment on the communication between devices A-B using "non-routable" addresses from and the E-device, that has the "routable" address (or is this a typo and RFC 1918 address was meant instead?):

Addresses from range 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, 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 like the one for device E) and
  • ... device E to do hardware address resolution via ARP for destination IP addresses within the range (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

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, 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 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 netsh int ip add route "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 -, where subranges and 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 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.


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 and regard to be their broadcast address. Hence, if E sends a packet to, 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 instead of (with Windows you would have to configure netsh int ip add route "<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.

« Last Edit: November 02, 2017, 04:09:09 AM by PacketTracer »


  • Level 4 Member
  • ****
  • Posts: 439
Re: DGS-1100-08 - bridge two VLAN/subnet?
« Reply #3 on: November 09, 2017, 04:40:12 AM »

... looks like this thread is of type "fire and forget" for reasons unknown except for the OP. If something can be learned from that, then it is at least the insight, that even for network scenarios that look "impossible" at first glance, it may nevertheless be possible to establish a working network communication as intended, if one accepts that some "unusual" configuration steps are needed in favour of a working scenario, that might have some drawbacks elsewhere. Hence, the time I spent on this was not lost due to the gain of this insight. For this reason I have to say: Thank you, wittrup!


  • Level 1 Member
  • *
  • Posts: 2
Re: DGS-1100-08 - bridge two VLAN/subnet?
« Reply #4 on: November 26, 2017, 12:55:56 PM »

Thank you!  :)
And please have my apologies.

Unfortunately I have been ill the past two and a half weeks.
Just had my two first days back at work.
And I have the first of three exams this coming week.
All of a sudden this network-project of mine bumped down a few steps on my priority list  ;)

I've read your reply a couple of times.
The quality, level of detail and the good references intrigues me.
I have simply not had enough time to both digest and test this.
« Last Edit: November 26, 2017, 04:50:05 PM by wittrup »


  • Poweruser

  • ▲▲
  • *****
  • Posts: 49296
  • D-Link Global Forum Moderator
    • Router Troubleshooting
Re: DGS-1100-08 - bridge two VLAN/subnet?
« Reply #5 on: November 26, 2017, 03:56:31 PM »

Let us know when you get time to try this. Hope it helps...
"Nothing Funny about It...." We are not here to Impress anyone! You have a be a COMPETENT user first to under stand COMPETENT help!