5406zl Vlan setup

[synaesthesia]

Right, more testing and all is good.

I'd like to get rid of the cables linking the vlans though - I'm guessing this is something that RIP would resolve instantly?

Where would we start with RIP? The config I would imagine would be identical to what wasn't working previously.

[Mark Wibaux]

Sorry been away for a few days.

Not sure what you mean about putting a cable between the VLANs. If your IP addressing is correct on the end devices and they are placed in the correct VLANs then the switches should handle routing between the different networks. You should not need to link the VLANs together physically.  

Based on the last configs you posted

At Site B

You would have any servers plugged in to ports B13-B23 and they would have IP addresses in the 10.12.152.0/255.255.252.0 subnet and would have their default gateway set to 10.12.152.14.

You would have any other devices plugged in to ports A1-A24,B1-B12  and they would have IP addresses in the 192.168.2.0/255.255.255.0 subnet and would have their default gateway set to 192.168.2.9.

As your internet link is at Site A then you could just set a default route on the Site B switch that points to the Site A switch. Command would be

ip route 0.0.0.0 0.0.0.0 10.0.0.1

At Site A

You would have any servers plugged in to ports B13-B23 and they would have IP addresses in the 10.12.148.0/255.255.252.0 subnet and would have their default gateway set to 10.12.148.14. You would also have your Internet router plugged in to one of these ports.

You would have any other devices plugged in to ports A1-A24,B1-B12 and they would have IP addresses in the 192.168.3.0/255.255.255.0 subnet and would have their default gateway set to 192.168.3.9.

As you internet link is at this site the default route for the Site A switch would be the Internet router. Command would be

ip route 0.0.0.0 0.0.0.0 10.12.148.1

If not using RIP you would also need to make sure that the Site A switch knows about the Site B subnets (which we've previously discussed)

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

Your biggest problem however is the Internet router. It needs to know about all the other subnets in your network so it knows how to route traffic back in to your environment. It would need the following four routes added all pointing at the IP address of the Site A switch (10.12.148.14).

ip route 192.168.3.0 255.255.255.0 10.12.148.14

ip route 10.0.0.0 255.255.255.252 10.12.148.14

ip route 192.168.2.0 255.255.255.0 10.12.148.14

ip route 10.12.152.0 255.255.252.0 10.12.148.14

If you can't get direct access to this router then you will need to request that your ISP add them in.

Of course the other option is to get RIP working but you will find that you will still need to talk to your ISP (or whomever controls the router) to get RIP enabled and working on it as well.

[synaesthesia]

No worries, hope it was for a break :)

The configs are identical to what you've specified, but something is ringing bells about the device gateways. Will double check those but I don't think that'd be hugely important as the devices were not even picking up DHCP addresses. 

Speaking to the ISP now about access to the router, I think they expect to make changes themselves on request however that's going to be daft. Testing will be a pain but I'm sure we're not the only ones to make changes on this scale.

I would like to get RIP working - do you have any suggestion, looking at  previous configs, as to why that might not have been working? It wouldn't surprise me if it's just a typo somewhere. Plenty of time to test, test, test though! :)

[synaesthesia]

Just realised one thing which may be a pain.

The internet router on 10.12.148.1 is on Site B. We definitely can't change that IP address and changing IP's on both sites will be nothing short of a nightmare. Could just swap roles on the switches and keep the 148 range at site B and the 152 for site A.

Think it's time for me to play with RIP some more :D

[synaesthesia]

Ok, ISP says we can have RIP enabled. Great, now just need to get it working.

With RIP enabled and verified with show ip rip it gives us:

RIP protocol :enabled

Auto-summary: enabled

Default metric: 1

Distance : 120

Route changes: 66

Queries: 0

RIP Interface information

IP Address         Status             Send mode           Recv mode     Metric    Auth

10.0.0.2               enabled            V2-only                 V2-only              1           none

10.12.152.14      enabled            V2-only                 V2-only              1           none

192.168.2.9        enabled            V2-only                  V2-only              1           none

RIP peer information

IP address     Bad routes    Last update timeout

10.0.0.1          0                      10

Thats the Site B unit. A is the same but vice versa.

But ignoring the two sites, it doesnt appear to be working between the vlans - so devices do not get a DHCP address nor when given a static IP do they communicate with the servers.

Inter-switch direct routing appears OK though - servers on one site can communicate with servers on the other.

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