Procurve routing help

[caffrey]

I'm playying about with an old procurve (a 2626) to enable routing on a test vlan (I'm doing this to see if I can do it before justifying spending on a new Layer 3 switch)

 

Running configuration:

; J4900A Configuration Editor; Created on release #H.10.50

hostname "ProCurve Switch 2626"
ip default-gateway 192.168.5.252
snmp-server community "public" Unrestricted
vlan 1
  name "DEFAULT_VLAN"
  untagged 1-26
  ip address 192.168.5.80 255.255.254.0
  exit
vlan 50
  name "Test"
  ip address 11.11.0.1 255.255.254.0
  ip helper-address 192.168.5.51
  tagged 24-26
  exit

 

192.168.5.252 is a test smoothwall box

 

I'm unable to add a route from the vlan to the smoothwall. when I try I get the following :-

ProCurve Switch 2626(config)# ip route 0.0.0.0 0.0.0.0 192.168.5.252
0.0.0.0/0 next-hop 192.168.5.252: Inconsistent value.

 

I've looked at lots of other setups and I don't see any differences, so what is going wrong ? (It could be that the switch is just old)

 

Ignore me, I didnt have ip routing enabled, mustve forgot to mem wr

Edited July 6, 2015 by caffrey

[caffrey]

Actually still having issues, is there any reason that vlan 50 isn't picking up an IP from the DHCP server ?

[localzuk]

Do you have a scope matching the values for the vlan?

 

Also, did you really mean 11.11.0.1? That address belongs to the "DoD Network Information Center" and isn't a private usable address? Should it not be in the 10.x.x.x range?

[caffrey]

It's just a test for the moment, it's only internal , just in case I've set up a new scope and changed the IP

 

Running configuration:

; J4900A Configuration Editor; Created on release #H.10.50

hostname "ProCurve Switch 2626" 
ip default-gateway 192.168.5.252 
ip routing 
snmp-server community "public" Unrestricted 
vlan 1 
  name "DEFAULT_VLAN" 
  untagged 1-26 
  ip address 192.168.5.80 255.255.254.0 
  exit 
vlan 50 
  name "Test" 
  ip address 192.168.10.1 255.255.254.0 
  ip helper-address 192.168.5.51 
  tagged 24-26 
  exit 
ip route 0.0.0.0 0.0.0.0 192.168.5.252 

[localzuk]

What is the scope you've created on the DHCP server?

[caffrey]

192.168.10.0 /23 I've also created another too 192.168.16.0/23

 

weird thing was it worked for a while but the devices wouldn't go any further

[localzuk]

Ok, next things to check - what is the gateway address used by the DHCP server? Also, in the scope, what have you set as the default gateway for that scope?

[caffrey]

Might be the cause,

 

This is only a test and I've had to add 2 gateways to the DHCP server

 

Should the DHCP scope gateway be the switch or the smoothwall ? It's current set to 192.168.5.252 (test smoothwall box)

Edited July 6, 2015 by caffrey

[localzuk]

The DHCP scope should be pointing at the VLAN IP address 192.168.10.1, and the DHCP server's gateway should be set to the IP address of the VLAN it sits on - 192.168.5.80.

 

The core switch would then point at your smoothwall box as the default gateway (if you're wanting to do transparent proxying anyway), which would then route out to whatever the external router IP address is.

[caffrey]

So the scope options 003 router should point to 192.168.10.1

 

Is the default gateway of the switch okay ?

 

Main issue is I'm doing this on a live network side by side just to test which means I've added two gateways to the NIC on the DHCP server (one is the current Smoothwall IP) and this test core switch.

 

Devices (iPads / Android) are stuck on obtaining IP Address, which they appear to get (I can see the IP lease) but they go no further

[localzuk]

Yep, that option is correct.

 

If the smoothwall box is your next step router for this network, then yes that default gateway is fine on the router.

[caffrey]

Must be the smoothwall box then causing issues as the devices are just stuck on optaining IP Address, they are getting a lease then going no further

[localzuk]

So, the devices actually get their IP? Can they ping each other across your test network?

 

I believe you'd have to add the IP range you're using to the Smoothwall somewhere, to allow it through as it will likely be blocking it as unknown at the moment. Not used smoothwall for years though, so not sure on that point!

[caffrey]

The lease is showing on the DHCP server (So the devices are getting that far) but they go no further than that just stuck on obtaining IP address.

 

As long as the setup is okay I'm not too worried about the Smoothwall side of things, just trying to wrap my head around a procurve before spending £1300 on a core switch

[localzuk]

Ok, so that sounds like the DHCP request is hitting the DHCP server, but its replies aren't getting out. Therefore, I'd say the issue isn't your Smoothwall box - the data never gets to that, but is the DHCP server itself. It sounds to me like your DHCP server is replying on your other NIC, and not the one you've got connected to your temporary network.

 

To simplify things, is it possible to give the temp network its own DHCP server, not a shared one?

[caffrey]

Sounds plausible,

 

Haven't really got any facilities to set up another DHCP server temporarily (or time!). I was hoping I could set all this up ready for swap over with limited downtime.

 

Something weird is going on as I gave an iPad a static on the 192.168.10.* range and the traceroute isn't working (to 192.168.5.252) - just gets stuck at 192.168.10.1, so maybe the routing is scuppered too.

[localzuk]

Ok, that issue will specifically be the Smoothwall box blocking the traffic.

 

That'll be separate to the lack of DHCP responses from clients. If you were to give 2 clients static addresses on VLAN 50, they should be able to ping each other but will both face the issue your iPad is facing.

[caffrey]

Yeah looks like the smoothwall, I can ping the ipad from my pc after adding 192.168.5.80 as an extra gateway on the 192.168.10.* range (I didn't fall into the windows firewall being on trap )

 

Be so much easier if I didn't have to do this sideways! At least I know it works and I can worry about DHCP later when I put a proper core in and that's just probably a gateway issue.

 

Thanks for the help