5406zl Vlan setup

[synaesthesia]

Cheer's we will have a try. 

The whole idea of the operation is to cut out the broadcast traffic between the switches as they are on separate sites connected via single mode fiber and we don't have the ability to trunk (link aggregate) it. So we need to cut out data going unnecessarily over this link.

I think we already tried the ip-helper on all vlans except 103 but I can't remember the outcome. I'll give it another try.

Many thanks for the support so far.

[Helper]

OK, so the best solution is to dedicate vlan (user/server) by buildings. Then your RIP redundancy will be a good choice if you do some tuning to the timers.
At that time you should have asymetric routing so you should encounter ethernet flooding. This could be verified using wireshark, there are many articles on the web regarding asymetric routing behaviour.

Bye.

[Mark Wibaux]

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.

[synaesthesia]

Cheers, Mark - we basically wanted to get it to a working state and working from there up.

I didn't think about doing it like that - I will give that a try in new year (on holiday now)

I doubt we have premium licensing on the switches - I will also take a look but we got them for an absolute snip of a price!

Have a good christmas and many thanks for the support, both of you.

[synaesthesia]

Hope everyone had a good christmas!

Just about to try out the above config. Amusingly, just did "show licenses" and we do indeed have premium licence! Happy days!

[Helper]

Is a proof that Santa Claus exists !

[synaesthesia]

Indeed! Now reading up on VRRP as the more I read about it the more useful it sounds. Redundancy is never a bad thing!

Edit:

Argh. Can always find plenty of examples (including HP documentation, obviously) with regards to using VRRP in same-site setups however when splitting the sites and naturally avoiding cross link broadcast traffic things become infinitely blurrier. Can anyone help shed some light on using VRRP in this setup?

[synaesthesia]

Righty,

Mark, I've been attempting the changes you specified with little to no luck.

Config currently looks something like:

SITE A:

hostname "SiteA"

ip routing

vlan 1

  name "DEFAULT_VLAN"

  no untagged A1-A24,B1-B24

  no ip address

  exit

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

vlan 999

  name "Link"

  untagged B24

  ip address 10.0.0.1 255.255.255.252

  exit

router rip

  enable

  exit

snmp-server community "public" unrestricted

vlan 101

  ip rip 192.168.3.9

  exit

vlan 103

  ip rip 10.12.148.14

  exit

vlan 999

  ip rip 10.0.0.1

  exit

*********

SITE B:

hostname "SiteB"

ip routing

vlan 1

  name "DEFAULT_VLAN"

  no untagged A1-A24,B1-B24

  no ip address

  exit

vlan 102

  name "Site B Devices"

  untagged A1-A24,B1-B12

  ip helper-address 10.12.148.16

  ip helper-address 192.168.3.16

  ip address 192.168.2.9 255.255.255.0

  exit

vlan 104

  name "Site A Servers"

  untagged B13-B23

  ip helper-address 10.12.148.16

  ip helper-address 192.168.3.16

  ip address 10.12.152.14 255.255.252.0

  exit

vlan 999

  name "Link"

  untagged B24

  ip address 10.0.0.2 255.255.255.252

  exit

router rip

  enable

  exit

snmp-server community "public" unrestricted

vlan 102

  ip rip 192.168.2.9

  exit

vlan 104

  ip rip 10.12.152.14

  exit

vlan 999

  ip rip 10.0.0.2

  exit

*******

B24 is now the link (just to make it easier for me to test and type!)

Each switch can ping eachother without an issue. I'm concentrating on getting one switch working atm, which is Site A.

So, Site A, if a machine is in the DEVICES vlan (101) it cannot get an IP address from the server. The switch can ping the server's 10.12.148.13 address but NOT its 192.168.3.13 address. A client plugged into DEVICES vlan with a static address can ping both switch addresses but not the server 192 address.

It appears as if routing isn't working - I suspect this is a matter of tagging though - beforehand I guess RIP worked through the common tagged ports. As all are untagged, where would I need to tag, if this is indeed the case? Would I need a physical link between them?

[Mark Wibaux]

Perhaps as you have so few ip subnets it might be worthwhile starting off with just static routes in the two switches and see if it works.

Once you have that sorted then start looking at RIP. At least that way you might be able to narow down the issue.

So on the Site A switch the routes would be something like

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

and the 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

Don't forget to set the correct default routes (ip route 0.0.0.0 0.0.0.0 ??.??.??.??)

As for VRRP with different sites there really isn't much you can do about it, the VLANs have to be able to traverse the link just in case the routing engine is down at one site the other has to be able to take over routing duties for that VLAN.

However when you think about, it in the case of just 2 sites with a single link then VRRP doesn't do much for you as if either switch is down then the link between the sites is likely to be down and there is no way for traffic from a VLAN at site A to traverse to the backup router at Site B anyway.

Glad that Santa had a nice "premium" present for you :)

[synaesthesia]

Absolutely fantastic, Mark you are a lifesaver.

This has gone rather well - everything speaks to eachother as they should, clients can't speak to eachother which is great but can speak to servers and printers etc. It does mean we need to change the IP addresses on stations at the other site but that won't be a problem.

My last remaining concern is that we are connect to the internet via a Cisco router which we are not allowed to touch. It's IP is 10.12.148.1, and annoyingly sits on the other site.

Am I right, that with default route set as "ip route 0.0.0.0 0.0.0.0 10.12.148.1" that should allow us to continue as required?

One small thing is that this only works if we put a physical cable between the vlans (so one cable between the device and server vlans on each switch). I'm sure there's an easy way to negate that?

Thanks so much for the input, we've dived into this knowing next to nothing about the more advanced side of networking and your examples alone have gone a long way towards helping us understand static routes and the finer arts of vlans :)