Need help with routing on HP ProCurve 2848

[AlmightyOne]

Greetings everyone:

I need some help with the HP ProCurve 2848 in routing, this is what the configuration looks like:

time timezone -480
time daylight-time-rule Continental-US-and-Canada
sntp server 216.239.32.15
ip routing
timesync sntp
sntp unicast
snmp-server community "dnalogic" Unrestricted
vlan 1
   name "DEFAULT_VLAN"
   untagged 1-48
   ip address 192.168.0.100 255.255.255.0
   ip address 192.168.1.100 255.255.255.0
   ip address 192.168.2.100 255.255.255.0
   exit
ip route 0.0.0.0 0.0.0.0 192.168.2.1
ip ssh
ip ssh version 1-or-2
password manager
password operator

192.168.0.0 and 192.168.1.100 are both local LANS. 
192.168.2.0 is basically a cable connecting from the LAN Ethernet side of a NETGEAR R7000 WiFi router to port 48 on the HP ProCurve 2848.  The NETGEAR has a IP address of 192.168.2.1 and is also the internet gateway.  NETGEAR has static routes of 192.168.0.0/24 would use 192.168.0.100 as the gateway and 192.168.1.0/24 would use 192.168.1.100 as the gateway.  .100 is the HP 2848.

What am I doing wrong because I have tried adding:
"ip default-gateway 192.168.2.1" which didn't work so removed that and did:

ip route 0.0.0.0 0.0.0.0 192.168.2.1

I can telnet to the HP 2848 fine from both 192.168.0.120/192.168.1.120 (same machine running Windows XP) that is connected to the switch directly as well as my Windows 10 notebook which is connected to the NETGEAR via WiFi as 192.168.2.182.  

From the notebook, I can ping 192.168.0.100, 192.168.1.100 and 192.168.2.100 as well as other nodes on 192.168.0.0 and 192.168.1.0 except there is a bit of latency.    The .100 is the HP 2848 switch.  

C:\WINDOWS\system32>ping -n 1 192.168.0.100

Pinging 192.168.0.100 with 32 bytes of data:
Reply from 192.168.0.100: bytes=32 time=18ms TTL=64

Ping statistics for 192.168.0.100:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 18ms, Maximum = 18ms, Average = 18ms

C:\WINDOWS\system32>ping -n 1 192.168.1.100

Pinging 192.168.1.100 with 32 bytes of data:
Reply from 192.168.1.100: bytes=32 time=16ms TTL=64

Ping statistics for 192.168.1.100:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 16ms, Maximum = 16ms, Average = 16ms

C:\WINDOWS\system32>ping -n 1 192.168.2.100

Pinging 192.168.2.100 with 32 bytes of data:
Reply from 192.168.2.100: bytes=32 time=1ms TTL=64

Ping statistics for 192.168.2.100:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 1ms, Average = 1ms

C:\WINDOWS\system32>ping -n 1 192.168.0.120

Pinging 192.168.0.120 with 32 bytes of data:
Reply from 192.168.0.120: bytes=32 time=181ms TTL=128

Ping statistics for 192.168.0.120:
 Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
 Minimum = 181ms, Maximum = 181ms, Average = 181ms

C:\WINDOWS\system32>ping -n 1 192.168.1.120

Pinging 192.168.1.120 with 32 bytes of data:
Reply from 192.168.1.120: bytes=32 time=20ms TTL=128

Ping statistics for 192.168.1.120:
 Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
 Minimum = 20ms, Maximum = 20ms, Average = 20ms

C:\WINDOWS\system32>tracert 192.168.0.120

Tracing route to SOLAR [192.168.0.120]
over a maximum of 30 hops:

 1 1 ms 1 ms <1 ms NETGEAR-R7000-1 [192.168.2.1]
 2 21 ms 15 ms 14 ms 192.168.2.100
 3 13 ms 13 ms 13 ms SOLAR [192.168.0.120]

Trace complete.

C:\WINDOWS\system32>tracert 192.168.1.120

Tracing route to 192.168.1.120 over a maximum of 30 hops

 1 5 ms <1 ms <1 ms NETGEAR-R7000-1 [192.168.2.1]
 2 31 ms 14 ms 13 ms 192.168.2.100
 3 13 ms 13 ms 15 ms 192.168.1.120

Trace complete.

So it seems the routing going through the HP switch is adding 15ms of latency as going from one machine on 192.168.0.0/24 which both are connected to the switch is usually less than 1ms in ping times.

Anyways, from the HP 2848, I can ping 192.168.0.0/24, 192.168.1.0/24 but not 192.168.2.0/24:

HP2848# ping 192.168.0.120
192.168.0.120 is alive, time = 1 ms
HP2848# ping 192.168.1.120
192.168.1.120 is alive, time = 1 ms
HP2848# ping 192.168.2.120
Target did not respond.
HP2848# ping 192.168.2.182
Target did not respond.
HP2848# ping 192.168.2.1
Target did not respond.
HP2848# ping 192.168.2.1
192.168.2.1 is alive, time = 1 ms
HP2848# ping 192.168.2.1
Target did not respond.
HP2848# ping 192.168.2.182
Target did not respond.

Yet I can ping 192.168.2.1 and 192.168.2.100 (HP2848) fine from 192.168.2.182:

C:\WINDOWS\system32>ping -n 1 192.168.2.1

Pinging 192.168.2.1 with 32 bytes of data:
Reply from 192.168.2.1: bytes=32 time=17ms TTL=64

Ping statistics for 192.168.2.1:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 17ms, Maximum = 17ms, Average = 17ms

C:\WINDOWS\system32>ping -n 1 192.168.2.100

Pinging 192.168.2.100 with 32 bytes of data:
Reply from 192.168.2.100: bytes=32 time=1ms TTL=64

Ping statistics for 192.168.2.100:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 1ms, Average = 1ms

Outgooing routes aren't working either from the HP 2848 as I can't traceroute to 8.8.8.8 which is the Google DNS Server:

HP2848# trace 8.8.8.8
traceroute to 8.8.8.8 ,
              1 hop min, 30 hops max, 5 sec. timeout, 3 probes
 1  *  *  *
 2  *  *  *
 3  *  *  *
 4  *  *  *
 5  *  *  *
 6  *  *  *
 7  *  *  *
 8  *  *  *
HP2848#

This is making the clock wrong:

HP2848# sh time
Mon Jan  1 01:12:01 1990

And here is the routing table:

HP2848# sh ip route

                                IP Route Entries

  Destination        Gateway         VLAN Type      Sub-Type   Metric     Dist.
  ------------------ --------------- ---- --------- ---------- ---------- -----
  0.0.0.0/0          192.168.2.1     1    static               1          1
  127.0.0.0/8        reject               static               0          250
  127.0.0.1/32       lo0                  connected            0          0
  192.168.0.0/24     DEFAULT_VLAN    1    connected            0          0
  192.168.1.0/24     DEFAULT_VLAN    1    connected            0          0
  192.168.2.0/24     DEFAULT_VLAN    1    connected            0          0


HP2848#

Hopefully someone can help.  Thanks in advance!

[16again]

The netgear has internal IP address of 192.168.2.1/24, so its next hop for internal routes should be in 192.168.2.0/24 segment!
This will solve your internet problem.

To me it isn't clear why all L3 interfaces of the switch.......are on the same VLAN.  This defeats the purpose of creating smaller broadcast domains.  If there isn't a good reason not to do it, I'd assign a separate VLAN to each network  , so you will end up with 3 VLANs.

[AlmightyOne]

You're right about the netgear having the internal IP address of 192.168.2.1/24 but what did you mean exactly about the next hop for internal routes should be in 192.168.2.0/24 segment as it has a default route going out the WAN which is a a dynamic DHCP address from the Comcast Business Class Internet Modem.   

On the Netgear, I have added the following static routes:

192.168.0.0  Netmask 255.255.255.0 Gateway 192.168.2.100

192.168.1.0   Netmask 255.255.255.0 Gateway 192.168.2.100

Actually, this is what it looks like at the NETGEAR:
http://i.imgur.com/0y4j64E.jpg

The reason for multiple L3 interfaces on the switch is because 192.168.0.0/24 is my general wired LAN.

192.168.1.1/24 is because the DSL Modem is at 192.168.1.254/24 and can't be changed.  

192.168.2.1/24 is what's connected to the NETGEAR which is usually the wireless segment.  

If I assigned each of the above /24 to a separate VLAN, how will I get the routing to work between them because earlier, I actually tried to put each one on a separate VLAN except only 192.168.0.0/24 would work as I could not even connect to it from 192.168.2.182/24.

[16again]

The internal netgear routes in your latest post are fine.   But topic start stated netgear was using 192.168.0.100 and ..1.100 as next hops:
"NETGEAR has static routes of 192.168.0.0/24 would use 192.168.0.100 as the gateway and 192.168.1.0/24 would use 192.168.1.100 as the gateway. "

When using multiple VLANs,  give the switch a L3 interface in each VLAN.  All clients in each VLAN use the corresponding L3 switch IP address  as default gateway. This gives you routing between VLANs. 
For internet connectivity, on the switch add default route to Netgear.

[AlmightyOne]

Yes, what I meant was the .100 in each /24 was the HP2848 switch.   It seems like traceroutes that uses the /24 of the 2848 for routing all seem to have 15ms or higher latencies as you can see, going through the netgear to the Comcast gateway is only 2ms. 

So what I'm trying to figure out is why doesn't the internet connecitivity work in this case since the default route that is pointing at the comcast gateway IP is working from 192.168.2.0/24 clients. 

This is from my WIndows 10 notebook connected to the Netgear as 192.168.2.182:

C:\WINDOWS\system32>tracert 8.8.8.8

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  router.asus.com [192.168.2.1]
  2     2 ms     8 ms     9 ms  10.1.10.1
  3   161 ms    18 ms    20 ms  96.120.88.205
  4    23 ms    29 ms    22 ms  te-0-7-0-4-sur04.sfmission.ca.sfba.comcast.net [68.85.190.217]
  5    20 ms    26 ms    25 ms  be-310-ar01.hayward.ca.sfba.comcast.net [162.151.79.81]
  6    24 ms    25 ms    29 ms  hu-0-19-0-0-ar01.santaclara.ca.sfba.comcast.net [68.85.154.253]
  7     *        *        *     Request timed out.
  8    24 ms    29 ms    28 ms  he-0-11-0-0-pe02.529bryant.ca.ibone.comcast.net [68.86.86.70]
  9    65 ms    65 ms    72 ms  66.208.228.70
 10    19 ms    15 ms    17 ms  216.239.49.11
 11    25 ms    29 ms   267 ms  216.239.58.193
 12    76 ms    27 ms    31 ms  google-public-dns-a.google.com [8.8.8.8]

Trace complete.

What I tried doing was add a VLAN2 with:

vlan 1
   name "DEFAULT_VLAN"
   untagged 1-48
   ip address 192.168.0.100 255.255.255.0
exit
vlan 2
   name "VLAN2"
   untagged 1-48
   ip address 192.168.2.100 255.255.255.0
exit

and I could not even telnet to the switch on the 192.168.2.100 IP from 192.168.2.182 with the above config.

Since the NETGEAR will assign the 192.168.2.100 via DHCP anyways, would doing it via DHCP on port 48 be better since the DHCP will also send it the default gateway.

[16again]

-To put a PC in VLAN 2, you have to set its switch port to untagged VLAN2
- Don't pay too much attention to ping times.  For instance, routed traffic through the switch should be handled by switch hardware at wire speed.  However, pinging the switch itself involves the much slower switch CPU and its network stack
-Make sure the netgear does NAT for other networks, and not only its own 192.168.2.x range
-On most of your output , source IP address isn't clear (at least to me)

[AlmightyOne]

There is only one PC which is connected wired on port 3 to the switch as both 192.168.0.120 and 192.168.1.120 and also wirelessly connected to the Netgear as 192.168.2.120.  

Interesting about the pinging times but what I'm more concerned about is I couldn't ping anything on the LAN from the CLI of the switch which is the ones with the # prompt.  The source IP of the other outputs are all from 192.168.2.182 which is a wireless notebook running WIndows 10 connected to the Netgear.

As for the Netgeat NAT, it only will do it's own 192.168.2.x range.  

In any case, since the Netgear is talking to the switch via 192.168.2.1, shouldn't it forward the packet to the default route for the switch at 192.168.2.100 just like it does for 192.168.2.182 which is what I am trying to fix as I couldn't get it to get the time.  

[16again]

-Don't give the PC multiple addresses on its LAN NIC.  This way, the PC thinks both networks are local. and won't use the gateway,
Also, during test, disable wireless on the PC, so you're sure which interface is sourcing packets.
-Beware when ping windows hosts. Default their firewall is up, blocking incoming PING
-Netgear route table is fine: default route to provider, internal 192.168.0.0/24 and 192.168.1.0/24 via 192.168.2.100

[AlmightyOne]

Actually, the PC does use the correct gateway as I setted it up so the gateway is 192.168.2.1.    The routing to the internet on the PC's work fine, I'm saying the routing from the HP Switch to the outside world is not working as it can't tracert to 8.8.8.8 for example so the clock is not getting updated.  When I had a Unix box running FreeBSD before the RAID HDD suffered a crash which is why it was down, it actually acted as 192.168.0.1 and it worked for traceroutes from the HP Switch without problems as 192.168.0.1 was the gateway.   As for pinging windows hosts, my PCs are opened to pinging as it's enabled since for example, from 192.168.2.182, I can ping the other PC just fine but you are right, that 192.168.2.182 has icmp blocked by Norton Security 2016:

C:\WINDOWS\system32>ping -n 1 192.168.0.120

Pinging 192.168.0.120 with 32 bytes of data:
Reply from 192.168.0.120: bytes=32 time=14ms TTL=128

Ping statistics for 192.168.0.120:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 14ms, Maximum = 14ms, Average = 14ms

C:\WINDOWS\system32>ping -n 1 192.168.1.120

Pinging 192.168.1.120 with 32 bytes of data:
Reply from 192.168.1.120: bytes=32 time=13ms TTL=128

Ping statistics for 192.168.1.120:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 13ms, Maximum = 13ms, Average = 13ms

So maybe 192.168.2.182 might have ping's blocked as this is what's on the PC that has 192.168.0.120, 192.168.1.120, 192, 168.2.120:

C:\Documents and Settings\vince>netstat -r

Route Table
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 50 56 c0 00 08 ...... VMware Virtual Ethernet Adapter for VMnet8
0x3 ...00 50 56 c0 00 01 ...... VMware Virtual Ethernet Adapter for VMnet1
0x4 ...00 11 2f 2a b7 5c ...... Intel(R) PRO/1000 CT Network Connection - Packet
 Scheduler Miniport
0x5 ...00 26 37 bd 39 42 ...... PdaNet Broadband Adapter #2 - Packet Scheduler M
iniport
0x6 ...00 ff 1b 58 03 73 ...... TeamViewer VPN Adapter - Packet Scheduler Minipo
rt
0x10008 ...a0 63 91 be 72 75 ...... NETGEAR A6210 WiFi USB3.0 Adapter - Packet S
cheduler Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
 0.0.0.0 0.0.0.0 192.168.2.1 192.168.2.120 1
 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
 192.168.0.0 255.255.255.0 192.168.0.120 192.168.0.120 10
 192.168.0.120 255.255.255.255 127.0.0.1 127.0.0.1 10
 192.168.0.255 255.255.255.255 192.168.0.120 192.168.0.120 10
 192.168.1.0 255.255.255.0 192.168.1.120 192.168.0.120 10
 192.168.1.120 255.255.255.255 127.0.0.1 127.0.0.1 10
 192.168.1.255 255.255.255.255 192.168.1.120 192.168.0.120 10
 192.168.2.0 255.255.255.0 192.168.2.120 192.168.2.120 10
 192.168.2.120 255.255.255.255 127.0.0.1 127.0.0.1 10
 192.168.2.255 255.255.255.255 192.168.2.120 192.168.2.120 10
 192.168.106.0 255.255.255.0 192.168.106.1 192.168.106.1 20
 192.168.106.1 255.255.255.255 127.0.0.1 127.0.0.1 20
 192.168.106.255 255.255.255.255 192.168.106.1 192.168.106.1 20
 192.168.220.0 255.255.255.0 192.168.220.1 192.168.220.1 20
 192.168.220.1 255.255.255.255 127.0.0.1 127.0.0.1 20
 192.168.220.255 255.255.255.255 192.168.220.1 192.168.220.1 20
 224.0.0.0 240.0.0.0 192.168.0.120 192.168.0.120 10
 224.0.0.0 240.0.0.0 192.168.2.120 192.168.2.120 10
 224.0.0.0 240.0.0.0 192.168.106.1 192.168.106.1 20
 224.0.0.0 240.0.0.0 192.168.220.1 192.168.220.1 20
 255.255.255.255 255.255.255.255 192.168.0.120 6 1
 255.255.255.255 255.255.255.255 192.168.0.120 192.168.0.120 1
 255.255.255.255 255.255.255.255 192.168.0.120 5 1
 255.255.255.255 255.255.255.255 192.168.2.120 192.168.2.120 1
 255.255.255.255 255.255.255.255 192.168.106.1 192.168.106.1 1
 255.255.255.255 255.255.255.255 192.168.220.1 192.168.220.1 1
Default Gateway: 192.168.2.1
===========================================================================
Persistent Routes:
 None

C:\Documents and Settings\vince>ping -n 1 192.168.2.1

Pinging 192.168.2.1 with 32 bytes of data:

Reply from 192.168.2.1: bytes=32 time=1ms TTL=64

Ping statistics for 192.168.2.1:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 1ms, Average = 1ms

C:\Documents and Settings\vince>ping -n 1 192.168.2.182

Pinging 192.168.2.182 with 32 bytes of data:

Request timed out.

Ping statistics for 192.168.2.182:
    Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

 
However, the HP Switch is the one that isn't working to the internet as both ping and traceroutes don't work to google's dns:

# ping 192.168.0.120
192.168.0.120 is alive, time = 1 ms
# ping 192.168.1.120
192.168.1.120 is alive, time = 1 ms
# ping 192.168.2.120
192.168.2.120 is alive, time = 1 ms
# trace 8.8.8.8
traceroute to 8.8.8.8 ,
              1 hop min, 30 hops max, 5 sec. timeout, 3 probes
 1  *  *  *
 2  *  *  *
 3  *  *  *
 4  *  *  *
# ping 8.8.8.8
Target did not respond.
# ping 8.8.8.8
Target did not respond.

while from the 192.168.2.182 and the 192.168.0.120 PC, it works fine:

192.168.2.182 PC on Wireless:

C:\WINDOWS\system32>ping -n 1 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=25ms TTL=54

Ping statistics for 8.8.8.8:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 25ms, Maximum = 25ms, Average = 25ms

C:\WINDOWS\system32>tracert 8.8.8.8

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  router.asus.com [192.168.2.1]
  2     6 ms     2 ms     6 ms  10.1.10.1
  3    13 ms    18 ms    30 ms  96.120.88.205
  4    15 ms    18 ms    20 ms  te-0-7-0-4-sur04.sfmission.ca.sfba.comcast.net [68.85.190.217]
  5   139 ms    25 ms    17 ms  be-310-ar01.hayward.ca.sfba.comcast.net [162.151.79.81]
  6    21 ms   247 ms    24 ms  he-0-19-0-0-ar01.santaclara.ca.sfba.comcast.net [68.85.154.253]
  7   215 ms    19 ms    25 ms  be-33651-cr01.sunnyvale.ca.ibone.comcast.net [68.86.90.93]
  8    19 ms    29 ms    24 ms  he-0-11-0-0-pe02.529bryant.ca.ibone.comcast.net [68.86.86.70]
  9    30 ms    19 ms    28 ms  66.208.228.70
 10    28 ms    29 ms    30 ms  216.239.49.11
 11    24 ms    26 ms    25 ms  216.239.58.193
 12    30 ms    29 ms    28 ms  google-public-dns-a.google.com [8.8.8.8]

Trace complete.

192.168.0.120 & 192.168.1.120 & 192.168.2.120 PC:

C:\Documents and Settings\vince>ping -n 1 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data&colon;

Reply from 8.8.8.8: bytes=32 time=24ms TTL=54

Ping statistics for 8.8.8.8:
 Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
 Minimum = 24ms, Maximum = 24ms, Average = 24ms

C:\Documents and Settings\vince>tracert 8.8.8.8

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

 1 <1 ms <1 ms <1 ms router.asus.com [192.168.2.1]
 2 3 ms 4 ms 3 ms 10.1.10.1
 3 31 ms 16 ms 17 ms 96.120.88.205
 4 20 ms 18 ms 18 ms te-0-7-0-4-sur04.sfmission.ca.sfba.comcast.net [
68.85.190.217]
 5 28 ms 29 ms 21 ms be-310-ar01.hayward.ca.sfba.comcast.net [162.151
.79.81]
 6 29 ms 36 ms 66 ms he-0-19-0-0-ar01.santaclara.ca.sfba.comcast.net
[68.85.154.253]
 7 18 ms 27 ms 29 ms be-33651-cr01.sunnyvale.ca.ibone.comcast.net [68
.86.90.93]
 8 26 ms 25 ms 30 ms he-0-11-0-0-pe02.529bryant.ca.ibone.comcast.net
[68.86.86.70]
 9 14 ms 28 ms 20 ms 66.208.228.70
 10 27 ms 21 ms 38 ms 216.239.49.11
 11 26 ms 21 ms 28 ms 216.239.58.193
 12 25 ms 29 ms 30 ms google-public-dns-a.google.com [8.8.8.8]

Trace complete.

[16again]

First try pinging the netgear from the switch.  (and check if switch port to the netgear is assigned correct VLAN.

The working pings and traceroute from PCs show that switch isn't involved in the routing (1st hop = netgear)