5406zl Vlan setup

[synaesthesia]

More progress.

If we put the physical cable link between the two vlans on each switch, it works again - DHCP picks up, clients can ping servers on both sites etc. RIP is therefore working at least certainly between the sites. Is it just not working between the vlans? Do I just need to tag a port on both rather than use a physical link?

[krbre]

Upon reading this thread I took some focus on the DHCP and the statements. I may have misunderstood but it sounded as if the DHCP server is dual homed in the server vlan and the devices vlan. If so that would force it to deal with dual gateways. I have pasted in the vlan 101 and 103 info below as the ip helper on vlan 101 for IP 192.168.3.13 provides NO function as the server interface is local on the 192.168.3.0/24 segment. The same can be stated for the vlan 103 segment for the IP helper 10.12.148.13 as that is local to the segment. The addition of the ip helper is only necessary on the remote vlans where a client's DHCP broadcast request needs to be forwarded to a server in a remote segment for a response. The server then resonds with the DHCP offer as a unicast packet as I recall. If you have a Windows server with the dual gateways it will probably only wreak havoc for you. (i.e. confuse the sever badly) A sever should be hosted in the server vlan to protect it from dangerous traffic in a client vlan. The IP  helper insures the necessary DHCP broadcast traffic from the client vlan reaches the server. Single home the server if it is not single homed. The earlier comment about a link between the vlans is troubling as a bridge between two segments pretty much defeats the purpose of vlan segmentation and broadcast isolation. Bad idea.

vlan 101

  name "Site A Devices"

  untagged A1-A24,B1-B12

  ip helper-address 10.12.148.13

  ip helper-address 192.168.3.13

  ip address 192.168.3.9 255.255.255.0

  exit

vlan 103

  name "Site A Servers"

  untagged B13-B23

  ip helper-address 10.12.148.13

  ip helper-address 192.168.3.13

  ip address 10.12.148.14 255.255.252.0

  exit

At any rate look at this DHCP problem from a simple part first. If the scope is set up correctly then use sniffer traces to determine if the DHCP requests are reaching the server or not and if the DHCP replies are getting back to the client segment. The sniffer traces will provide clarity. Set up a mirror port and connect a sniffer to it then monitor the traffic in and out for a port in the path of the intended traffic.

Upon seeing that there are servers and clients at both Site A and Site B and the IP helpers configured at both sites I would assume that there is a DHCP server for DHCP services at Site A and seperate services for Site B. The transit net between the sites only provide the site to site connectivity as I see it. I am not sure why you would put an IP helper on the server vlan and direct DHCP requests to the "Devices" vlan unless there is a DHCP server there providing DHCP addresses?

[synaesthesia]

That was extremely in-depth, thank you.

Was not sure of the correct location of the IP-helper address, if it needed to be where the servers are serving the DHCP or for the devices to know what IP/subnet to look at (hence in the devices vlan).

The physical bridges serve only one purpose - troubleshooting why DHCP wasn't working, so we're not worried about that in the long term :)

Currently, and until these switches go in, we have a large number of layer 2 cheap gigabit switches with no core. There is no separation, and although server setup is identical, it's all one flat subnet (10.12.148.0/22) with devices and printers on 192.168.3.0/24. DHCP is currently provided by one server at site A. 

We've hit a threshold where switches have started acting as hubs because there are now too many MAC addresses for them to handle (even D-Link are unsure as to whether an 8k mac address table means 8000 addresses or 8000 bytes for addresses (circa 500 mac addresses). Traffic over the single mode fibre between sites is crippling performance chronically. Nothing has gone live yet re a new implentation with the 5406zls, it's all been tested virtually.

[OmarDBG]

Hello, 

just from a quick look at the configurations, you have mistake done, i don't know how you managed to untagged the port for the three vlans??? Like B20 it untagged member in all the vlans.

Secondly you don't have any tagged ports, you need to tag b21 in all the vlans or at least the ones that you want to pass to the other site,  same with the other switch on the other side, 

so tag b21 in vlan 101, 102, 103 so the traffic will pass from one side to there via the link.

[scifan3]

As it stands now your configuration does nothing to stop broadcasts etc from traversing the link between the sites because you have just extended all your VLANs across the link.
If you are trying to cutdown on the traffic going across the link between sites then you really need to look at a dedicated VLAN linking the two sites and then route through this VLAN.
 
Assuming B21 is your site to site link
 
So site A would have
VLAN 101 (Site A devices) - 192.168.3.9 255.255.255.0 (Make sure port B21 is NOT in this VLAN)
VLAN 103 (Site A servers) - 10.12.148.14 255.255.252.0 (Make sure port B21 is NOT in this VLAN)
VLAN 999 (link to site B) - 10.0.0.1 255.255.255.252 - Untagged B21
 
So site B would have
VLAN 102 (Site B devices) - 192.168.2.10 255.255.255.0 (Make sure port B21 is NOT in this VLAN)
VLAN 104 (Site B servers) - 10.12.152.14 255.255.252.0 (NOTE: Different IP and VLAN to site A) (Make sure port B21 is NOT in this VLAN)
VLAN 999 (link to site B) - 10.0.0.2 255.255.255.252 - Untagged B21
 
You could either use RIP to advertise the routes between the switches or setup the correct static routes in the switches so each site knows how to get to the other sites subnets.
 
Also regarding the premium licensing for 5400zl series. Depending on the age and the model purchased you might already have the premium license. I can only comment on Australia but all v2 chassis (and some v1) and bundles can now only be purchased with the premium license already embeded in the switch. Run the command "show licenses" and see what is reported for your chassis.

This looks like a very valid solution... Honestly with as simple as your site is, I wouldn't bother with a routing protocol... rip, ospf or otherwise.  I would just have static routes pointing at the two network segments on either side of the link:

Site A)

ip route 192.168.2.0 255.255.255.0 10.0.0.2

ip route 10.12.152.0 255.255.252.0 10.0.0.2

Site B)

ip route 192.168.3.0 255.255.255.0 10.0.0.1

ip route 10.12.148.0 255.255.252.0 10.0.0.1

You will need to make sure you change your DHCP scopes to reference your new gateway on site B, and you can have multiple scopes on your dhcp server...