Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mx5gr]

We own two identical DGS-1210-28 switches, updated to the latest firmware.

We are using 4 different VLANs and the switch ports are either tagged or untagged. Ports 25 - 28 are bonded together and are used to interconnect the two switches. All VLANs that refer to these ports are tagged and allowed through.

The VLANs are:

VLAN1 - 192.168.11.0/24
VLAN2 - 192.168.12.0/24
VLAN3 - 192.168.13.0/24
VLAN4 - 192.168.14.0/24

The G/W of the switch is 192.168.12.1 .. however, all VLANs talk to each other through a firewall/router that is attached to all of them.

We have setup two management interfaces, 192.168.11.5 & 192.168.12.5 for the 1st switch and 192.168.11.6 & 192.168.12.6 for the other.

When the two switches are not connected to each other, if we attach a laptop to a port and ping the switch management interface or open the GUI, they work fine. If, however, we interconnect them as stated above, then two things happen:

(1) There is only access to the management interfaces of the 1st switch from any VLAN/ports/switch (i.e. a device connected to switch 2 cannot ping or open its management interface but can both open/ping the mgmt interface of switch 1)

(2) All devices connected to different VLANs and are spread among the ports of both switches can properly communicate to each other (as intended)

We have tried many combinations and different methods to test the mgmt interfaces of switch #2, there is no way (until now) to make them work (admin GUI/ping) when both switches are connected to each other.

Any hints?

[PacketTracer]

Hi,

I'm surprised how you could have managed to configure two management addresses (one per VLANs 1 and 2) per switch!
According to the manual, you can only configure a single management address (System > System Settings) per switch which is assigned to default VLAN 1. And you can change this VLAN assignment via "VLAN > 802.1Q Management VLAN" to another user created one, in your case e.g. VLAN 2.

PT

[mx5gr]

Hi,

I went to L3 Functions -> IP Interface and created one IPv4 interface per VLAN that is attached to the switch, apart from the one defined within System -> System Settings and assigned to the correct VLAN. Through these IPs (multiple VLANs) I can access the mgmt GUI.

[PacketTracer]

Hi,

ah - ok. The manual I referenced refers to an older DGS-1210-28 which doesn't provide L3 Functions. Found a more recent manual V5.00 for switch model DGS-1210-28MP, looks like this is the model you use?

Here the VLAN that the first management interface shall be assigned to can already be selected within "System > System Settings".

I studied about the L3 functions: It seems to me like any L3 Interface defined for another VLAN does not constitute an own routing context (VRF) but only extends the switch's global routing context by an additional SVI. Hence you can only have a single global routing table with a single default route defined via "System > System Settings". From what you said I conclude you selected VLAN 2 (192.168.12.0/24) within "System > System Settings" and set the Gateway to 192.168.12.1.

This would mean for L3 interfaces 192.168.11.5 and  192.168.11.6 that without additional host routes within your Firewall/Router or static routes within your switches they can only be accessed by clients within VLAN 1, because for clients within VLANs 2,3 and 4 you would have asymmetric routing that should be blocked by the firewall (routed traffic from these VLANs sent to the switches via VLAN 1, reverse traffic from the switches sent back via VLAN 2). For clients within VLANs 2,3 and 4 (assuming them to have configured your firewall/router as their gateway 192.168.X.1, X=11,12,13,14) you would either have to define the following host routes within your firewall/router:

192.168.11.5/32 next hop 192.168.12.5 via interface vlan2
192.168.11.6/32 next hop 192.168.12.6 via interface vlan2

Or, as an alternative and perhaps the better choice, you can instead define additional static routes within your switches for routing to VLANs 2, 3 and 4 via VLAN 1:

192.168.12.0/24 next hop 192.168.11.1 via interface vlan1
192.168.13.0/24 next hop 192.168.11.1 via interface vlan1
192.168.14.0/24 next hop 192.168.11.1 via interface vlan1 )

On the other hand the problems you observed cannot be explained by the missing of these routes.

Hence something else may possibly be wrong. What about the PVID settings of the switch ports. Did you set them accordingly or are they all left at their default values PVID=1 (which would be wrong for some set of ports)?

PT

[mx5gr]

I thought so myself regarding the VRF functionality as you described. I don't see why they could not program a proper L3 interface and they delivered such a crippled functionality.

I tried adding a few rules to the f/w to cover the asymmetric routing potential issue the other day, however I did not have the time to test them out.

However, the mgmt interface cannot be accessed even by clients belonging to the same subnet as the virtual L3 interfaces on the same switch, i.e. no gateway is involved. Furthermore, regarding sw 2, its mgmt interface albeit being within the same VLAN/subnet as the mgmt interface of sw 1 (settings as defined within System -> System Settings), it is inaccessible even by clients within the same VLAN when attached to the switch (#2) itself to ports that have this VLAN untagged. These sw2 ports at the same time can properly communicate with the clients on the same VLAN attached to the corresponding ports of sw1, as well as the sw1 mgmt interface itself.

Port PVIDs have been double checked and the switches operate properly (access to mgmt interface) when not interconnected via the trunk links. When the trunk is in place, no access to the mgmt interface of sw2 is feasible through any VLAN and irrespective to whether the client is directly attached to the switch or not.

It completely baffles me.. 

[PacketTracer]

Hm - sounds really strange ...

In such situations bottom up analysis might help. Within your switches have a look at their ARP tables (L3 Functions > ARP > ARP Table Global Settings). Can you see which MAC addresses the management interfaces have (btw: Are they unique per VLAN amongst both switches)?

Now if you go to some clients within VLAN 1 and VLAN 2 respectively and try to ping the corresponding neighbor management addresses of switch 2 within each VLAN (which should fail according to your observations) - do these clients at least have got resolved the MAC addresses of these management addresses (inspect the clients' ARP caches)? Conversely, does the 2nd switch's ARP table show the clients' MAC addresses?

If not, besides the question why, you could create static ARP cache entries for the management addresses within the clients and/or static ARP cache entries for the clients within the 2nd switch and then check if the 2nd switch's management addresses are reachable after that. If true the problem gets reduced to why ARP resolution fails for the second switch's management IP addresses.

Please check this and tell your results.

PT

[mx5gr]

Hi PT,

I have recorded the ARP addresses of the mgmt interfaces of sw1. Unfortunately, I cannot login into sw2 to see its mgmt ARP entries, I have recorded however the MAC address of the mgmt interface belonging to VLAN1, which I am using to connect to sw1 as well.

There are ARP entries within the directly-attached clients for both mgmt interfaces, sw1 & sw2, AND within sw1's System -> L2 functions -> MAC Address Table -> Dynamic Forwarding Table I can also see the IP and MAC address of the mgmt interface of sw2 belonging to VLAN1 only (not the other admin interfaces belonging to other VLANs however). In theory (even though we cannot see the ARP/MAC table of sw2), the mgmt interface of sw2 should be accessible even within VLAN1 only. Please note that from the directly attached clients (VLAN1), only the sw1 mgmt ip is pingable and not the one of sw2 (even though its MAC is within the client's ARP table AND the gateway on the sw2 [System settings] is the same as in sw1 - belonging to VLAN1).

There was no entry for the mgmt interface of sw2 (even for VLAN1) within L3 Functions -> ARP -> ARP Table Global Settings. I added it manually but, still, no access to it..

As I could not login to/access sw2 either through a sw1-connected client or through a directly-attached (sw2) one, I could not see its ARP table and/or add relevant entries.

Last but not least, if I change the switch gateway to 0.0.0.0 does this mean that there will be no routing for any VLAN through it (the common VRF issue) and the VLANs will be contained and accessible only through directly-attached clients only?

[PacketTracer]

Hi again,

a neighboring IP interface's MAC address may have been present in an ARP cache or switch's dynamic forwarding table, but it becomes deleted if no ingress Ethernet frame coming from this MAC address (e.g. an ARP reply) has been seen for more than some aging timeout interval. Hence it is important to inspect these caches quite soon after some ping test that provokes an ARP resolution.

As you can see sw2 management interfaces' MAC addresses within the ARP caches of pinging clients, MAC address resolution via ARP seems to work: Broadcast ARP requests sent from a client seem to reach the neighboring sw2 management interface and this seems to send back a unicast ARP reply. To be really sure about that, on a client you could delete its ARP cache, start a packet trace (e.g. via Wireshark) and initiate a ping to the sw2 management address in order to provoke an ARP resolution. The exchange of ARP packets as described should then be recorded in the trace.

I'm confused about your second statement: "Unfortunately, I cannot login into sw2 to see its mgmt ARP entries, I have recorded however the MAC address of the mgmt interface belonging to VLAN1, which I am using to connect to sw1 as well." Does this mean, that within VLAN 1 the management addresses of sw1 and sw2 share (for whatever reason) the same MAC address (that is 192.168.11.5 and 192.168.11.6 resolve to the same MAC address)?  This would be an error, because MAC addresses must be unique within the scope of a VLAN!

Some other question: Why at all a management address within each VLAN? Why not just a single management interface per switch within a single VLAN, say VLAN 1? Due to your router/firewall the management interfaces within VLAN 1 would be reachable from any VLAN. In addition using firewall rules you can restrict access to the management interfaces to selected (admin) clients within the other VLANs. Maybe both switches are reachable if you delete all management interfaces other than those within VLAN 1 (selected within "System > System Settings" and setting the Gateway to 192.168.11.1)?

To your last question: I would leave the Gateway field within "System > System Settings" just empty instead of typing 0.0.0.0. But this doesn't prevent routing between VLANs. For example consider a client 192.168.11.10 that connects to management interface 192.168.12.5: In forward direction packets become routed from 192.168.11.10 to 192.168.12.5 via your router/firewall (because this is the client's default gateway). In reverse direction the switch would just route back from 192.168.12.5 to 192.168.11.10 via its local L3 routing function.

PT