*gulp* VLANage.

[synaesthesia]

OK, trying to get my head around this, in very very little time.

 

2 routers, one per site.

DHCP/DNS and file server per site, and one site has a lot more servers besides.

 

Test setup worked brilliantly.

Live - not so much, despite identical setups.

 

For instance:

 

Servers, being ESX dont seem to like the VLANS much. That's one big difference I think, the fact that we tested with physical boxes therefore the SERVERS vlan was untagged for the relevant ports. ESX doesn't play ball with that, and only seems to work when we add the relevant vlan tags on ESXi and then tag the ports on the switch. Does that sound right/usual?

Our boxes are also in the SERVERS vlan (untagged) as we'll need access to pretty much everything.

 

Trouble is, tomorrow it's going to be all or nothing - I don't want to give up and flatten it again when the tests worked so well

Any input or known gimme's with ESXi stuff?

Pair of Procurve 5406zl's doing the gruntwork and nearly all the edges are Dlink DGS-1224s or DGS-1210-24s.

[nicholab]

Sorry it a while since I used VMware. Do you have a septate port for management? To me it sound like that the virtual switch is not set up correctly you need to have a virtual have a trunk port on the network. You create Vlan on the virtual switch and then put the port in the server vlan. Edited April 3, 2013 by nicholab

[synaesthesia]

Yeah, thought that might be the case. Thankfully ports are a-plenty.

So it would be right, that you would have it tagged on the switch rather than untagged?

[nicholab]

You can do it both ways. You can either set up the HP port to the ESXi box as trunk port and then have the Vlan on the the Vswitch or you can have the Vswitch in one vlan.

[FN-GM]

No idea what you mean with your vmware. But we have it setup on EXSi where the link from the Host to the switch is a trunk port. You then setup your management network with a VLAN ID. You then setup your networks inside the software and just set as many as you like using the VLAN ID's.

[synaesthesia]

Oh my giddy good god. That simple. I've been forgetting that it's a virtual switch too, hence of course it's just a trunk. There we go then

 

Cheers!

[DMcCoy]

Yes, just tag all the VLANs you want to be available on the vswitch for that port. You can also tag the management console if you want, I never used untagged for vmware boxes after they added management tagging in 3.0.

 

Procurve has no concept of "trunk" ports that just send all vlans below 1000, unless specified, in the same way cisco does.

[synaesthesia]

Aye that's right - trunking in procurve terms is link aggregation. The only real difficulty faced is the different terms between manufacturers.

 

Daft really, it was easier (in fact, possible at all) to get vlans working across dlink edges and our big procurve cores than it is to do it at all on procurve 1800's. Say what you like about D-Link, they make the PC 1800's look like kiddies toys. And that's just because HP keep changing their own terminology too.

[DMcCoy]

The 1800s are nice, small, all Gb silent switches (at least the 24 port ones). However they suffer from the same issue as dlinks and netgears, PVIDs which I really don't see a need for. I'm sure there is a good reason for them, but I prefer the larger procurve options of no, forbid, tagged, untagged without a need for pvid.

[synaesthesia]

That's exactly it - and there's no way around them. Thankfully no PVID's on the dlinks hence they work (in testing). And there's no option to manage the small procurves other than the GUI

 

Right, so I'm now at a dead end. Everything worked in testing and it's not now it's vaguely live.

 

Config is thus:

 

Running configuration:

ip routing
vlan 1
  name "Management"
  untagged A6-A24,B1-B14,B16,B18-B24
  ip address 10.12.149.1 255.255.255.0
  no untagged A1-A5,B15,B17
  exit
vlan 100
  name "Servers"
  untagged A5
  ip address 10.12.148.2 255.255.255.0
  tagged A1-A4,A6-A18,B11,B20,B24
  exit
vlan 200
  name "LRClients"
  untagged B15
  ip helper-address 10.12.148.12
  ip address 10.12.152.1 255.255.252.0
  tagged A1,B1-B12,B20
  exit
vlan 105
  name "WiFi"
  untagged B17
  ip helper-address 10.12.148.12
  ip address 10.12.160.1 255.255.240.0
  tagged A1,B1-B12,B24
  exit
ip route 0.0.0.0 0.0.0.0 10.12.148.1
ip route 10.12.156.0 255.255.252.0 10.12.148.3

 

As said, this worked in testing with no issues. The only difference is internet router behind it now (not worried, we can get it running without internet until ISP can config it for us).

10.12.148.12 being the DHCP server, obviously.

This is a VM on an ESXi 5 box.

 

IP setup on that VM is 10.12.148.12 255.255.255.0 gateway being the vlan address of 10.12.148.2

Tried all sorts on the ESXi vlan setup but currently that NIC connected to the DC is set to vlan 100.

DC can ping the switch but only on the gateway/vlan address of 148.12 - it can't ping the switch itself, nor anything connected to it on the same IP range.

I'm guessing this is an ESXi related issue but not so sure.

 

Any help would be MASSIVELY appreciated!

[gshaw]

Only read this quickly but assuming the DC is a VM with its network set to 100 have you got another VM set up with the same network on the same ESXi host? If so can the DC ping that?

 

If you set a port on the switch untagged in VLAN 100 with a physical PC plugged into it can the DC ping that?

[DMcCoy]

I assume you have the vlan on the vswich, and the NIC on the vm is assigned to that vlan?

 

If you add a vlan to a vswitch after the VM is created you need to change the NIC properties for it as it will be unassigned still.

[synaesthesia]

I'm working on EST tagging which is all done at the physical switch and not at the virtual switch. That allows me to ping to and from just about everything. DHCP helper is currently the only thing not working as a result.

 

When on a VST (so the VM network was set to vlan100) it could ping other devices in the same vlan only. Routing appears to be OK:

 

 IP Route Entries

 Destination        Gateway         VLAN Type      Sub-Type   Metric     Dist.
 ------------------ --------------- ---- --------- ---------- ---------- -----
 0.0.0.0/0          10.12.148.1     100  static               1          1
 10.12.148.0/24     Servers         100  connected            1          0
 10.12.149.0/24     Management      1    connected            1          0
 10.12.152.0/22     LRClients       200  connected            1          0
 10.12.156.0/22     10.12.148.3     100  static               1          1
 10.12.160.0/20     WiFi            105  connected            1          0
 127.0.0.0/8        reject               static               0          0
 127.0.0.1/32       lo0                  connected            1          0

[DMcCoy]

I suggest you use to normal VST method, I don't see why you would want to use EST.

[synaesthesia]

OK. May I ask what you mean by "Change the NIC properties" please?

[DMcCoy]

OK. May I ask what you mean by "Change the NIC properties" please?

 

Just that the NIC will display all the VLANs available on the drop down for the vswitch it is connected to, it may have a value already, but note that it does not update if you rename or recreate a vlan on the vswitch.

 

http://www.dasblinkenlichten.com/wp-content/uploads/2011/06/image16.png

[synaesthesia]

Pretty much what I've got now but nada. The two servers ping eachother and the vlan gateway now.

 

So to confirm:

Both servers on the same vlan/vswitch in ESX which is set on VLAN ID: 100

Switch is set to TRUNK mode and tagged for 100 (interface is TRK1)

TRK1 is also untagged for the management vlan.

 

DHCP isn't working, nor can I ping any of the above from other stations.

[DMcCoy]

What is ip route 10.12.156.0 255.255.252.0 10.12.148.3 for?

Also I assume you are using TRK1 for aggregation of multiple interfaces to the server? There is also some config for static teams that needed to be configured on esxi if you are using multiple NICs on a vswitch.

 

I assume the new scopes for the ip ranges are created in DHCP and the gateways for clients and server VMs are set to their vlan address?

[synaesthesia]

They are indeed. That static route points to our other site switch which is as yet unconfigured (that site will serve that client address range). Actually already removed that to make sure things aren't going squiffy with that.

The TRK1 is for multiple interface use and it's configured in line with VMWare's recommendations. Again, currently I'm already only using a single connection to rule out such issues.

 

Currently I have everything untagged and naturally things are pinging away happily but that's rather against the point.

[synaesthesia]

Woo, nearly there!

 

Firstly, a huge thanks to Dan Jackson at TalkStraight ( @SchoolsBroadband ) who's been massively helpful in getting our router reconfigured to speak to everything correctly. Probably the best part of 3 hours on the phone and a lot of learning done in the process, but all good! I suspect certain other large providers would have told us to go hang, or charge extortionate amounts on top of the fees!

 

Everything is speaking to everything else, NEARLY, as it should! The big problem causer this morning mostly for the internet access side was my mistake - thinking that I would need the setting "enable management-vlan". No! Took it out and things started to behave!

Plus, getting the VMware stuff down has been good. In a nutshell:

Vswitch to physical switch set up as a trunk, tagged with all the relevant vlans on the physical switch.

Virtual NIC's set up on VLAN 100 (Servers VLAN)

NIC Teaming set up to route by IP hash rather than the default option

 

That's gotten that down. DHCP working like a dream at both sites, picking up the relevant IP's from each specific server.

SCCM IP change didn't bat an eyelid, thank god for working DNS!

 

**** EDIT ****

 

Couldn't get from one sites clients to the other site's server. Turned out I'd removed the static IP routes I'd put in to do that for testing. Back in and job's a good'un Roll on monday!

Edited April 5, 2013 by synaesthesia

[apeman]

You need to make sure the Trunk on the HP switch is NOT set to TRUNK and SHOULD be set to LACP

 

A Trunk on a HP switch is a proprietary protocol used for bonding multiple links to increase bandwidth.

LACP is the industry standard for bonding multiple links and should be common across vendors

 

If you run "show trunk" on your HP switch the type should show as LACP

[synaesthesia]

It's just "TRUNK" as advised to me by a Finnish friend who runs an almost identical setup. As it's working exactly as it should I'm not too inclined to go playing much further.

[DMcCoy]

You need to make sure the Trunk on the HP switch is NOT set to TRUNK and SHOULD be set to LACP

 

Until ESXi 5.1 vmware didn't support LACP...

 

I used trunk for many years as recommend by vmware like in this KB here VMware KB: Sample configuration of EtherChannel / Link Aggregation Control Protocol (LACP) with ESXi/ESX and Cisco/HP switches

[synaesthesia]

Indeed. Both our main boxes are 5.1 however we have a lot still on 4.1. No point upgrading them as it just continues to work through thick and thin. It's that very article above that I was pointed to (and also found previously in older searches) to get my setup working well.

[SchoolsBroadband]

Woo, nearly there!

 

Firstly, a huge thanks to Dan Jackson at TalkStraight ( @SchoolsBroadband ) who's been massively helpful in getting our router reconfigured to speak to everything correctly. Probably the best part of 3 hours on the phone and a lot of learning done in the process, but all good! I suspect certain other large providers would have told us to go hang, or charge extortionate amounts on top of the fees!

 

Everything is speaking to everything else, NEARLY, as it should! The big problem causer this morning mostly for the internet access side was my mistake - thinking that I would need the setting "enable management-vlan". No! Took it out and things started to behave!

Plus, getting the VMware stuff down has been good. In a nutshell:

Vswitch to physical switch set up as a trunk, tagged with all the relevant vlans on the physical switch.

Virtual NIC's set up on VLAN 100 (Servers VLAN)

NIC Teaming set up to route by IP hash rather than the default option

 

That's gotten that down. DHCP working like a dream at both sites, picking up the relevant IP's from each specific server.

SCCM IP change didn't bat an eyelid, thank god for working DNS!

 

**** EDIT ****

 

Couldn't get from one sites clients to the other site's server. Turned out I'd removed the static IP routes I'd put in to do that for testing. Back in and job's a good'un Roll on monday!

 

 

no problem @synaesthesia all our customers get unlimited support built into their package no matter how long it takes and how complex the config

 

Dave