• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2447
  • Last Modified:

Can't ping secondary subnet, possible routing issue?

What I thought would be a simple project has me pulling my hair out. I'm sure the answer is right in front of me, but I can't seem to find it. I'm hoping someone can help.

I have a fairly simple network set up using a layer3 switch to manage 2 subnets through 1 firewall & T1 line.

10.0.0.- subnet 1 (uses 10.0.0.1 port/ip on switch as gateway)
192.168.2.- subnet 2 (uses 192.168.2.1 port/ip on switch as gateway)
10.0.1.- uses only 2 ip addresses: 10.0.1.1 = trusted IP of firewall and 10.0.2.2 is the port/ip on the switch

The following is the routing table BEFORE i tried adding another subnet.
Network address     Subnet                Protocol   Next Hop     Next Hop IP       Best Route
0.0.0.0                   0.0.0.0                Default    0.1              10.0.1.1            Yes
10.0.0.0                 255.255.255.0      Local       0.3              10.0.0.1            Yes
10.0.1.0                 255.255.255.252   Local      0.1              10.0.1.2             Yes
192.168.2.0            255.255.255.0      Local      0.5              192.168.2.1        Yes

I wanted to add a 3rd subnet, so I enabled/configured another port on the switch. The routing table now looks like this:
Network address     Subnet                Protocol   Next Hop     Next Hop IP       Best Route
0.0.0.0                   0.0.0.0                Default    0.1              10.0.1.1            Yes
10.0.0.0                 255.255.255.0      Local       0.3              10.0.0.1            Yes
10.0.1.0                 255.255.255.252   Local      0.1              10.0.1.2             Yes
10.0.2.0                 255.255.255.0      Local       0.7              10.0.2.2             Yes   <-- new entry
192.168.2.0            255.255.255.0      Local      0.5              192.168.2.1        Yes

Now, I still have full functionality on the 10.0.0. and the 192.168.2. I can communicate freely between those 2 subnets as well as out through the firewall (10.0.1.1).

From both the 10.0.0 and the 192.168.2 I CAN ping the new 10.0.2.2 ip (which is the port on the switch) but I can't ping any other IP's on that subnet (10.0.2.1, 10.0.2.5, etc). All tracert's stop at the switch.

I have confirmed from a PC on the 10.0.2 subnet that I can ping the switch IP (10.0.2.2).
I can ping the same switch IP (10.0.2.2) from both the 10.0.0 subnet and the 192.168.2 subnet.
I can also use the switch's "internal" ping tool (run from the web interface) and can ping any IP on ANY subnet.

What am I missing????

Thanks in advance,
-Scott
0
spillsbury
Asked:
spillsbury
1 Solution
 
adamdrayerCommented:
what model switch is it?
0
 
spillsburyAuthor Commented:
NetGear GSM7312 (Layer 3, 12 port, Gigabit)
0
 
spillsburyAuthor Commented:
Getting this fixed has taken a higher priority, so I'm adding more points.

Any help is appreciated.
0
[Webinar] Improve your customer journey

A positive customer journey is important in attracting and retaining business. To improve this experience, you can use Google Maps APIs to increase checkout conversions, boost user engagement, and optimize order fulfillment. Learn how in this webinar presented by Dito.

 
adamdrayerCommented:
Not particularly sure about configuring NetGear routers...  I'll post a pointer in Networking where you will get more exposure.
0
 
SpankyxeonCommented:
based on what you're saying it would seem to me that the default gateway on the 10.0.2.1 and 10.0.2.5 devices have the wrong default gateway set.  Did you set the default gateway on the devices to 10.0.2.1 out of habit (the .1 part of it)?  It would need to be 10.0.2.2 based on what you've typed.

Another possibility, although I'm assuming it was just a typo on your
part:
"10.0.1.- uses only 2 ip addresses: 10.0.1.1 = trusted IP of firewall and 10.0.2.2 is the port/ip on the switch"

I'm assuming you meant 10.0.1.2 instead of 10.0.2.2.  If you meant to type what you did, then that's a problem.  The 10.0.1.1 and the 10.0.2.2 would be on different subnets, but you mention that they are the only 2 ip addresses in use on the 10.0.1. subnet.  That obviously wouldn't work because those 2 IP (the ones you provided) are on different subnets, not the same.

Lastly, it could be a problem with your f/w.  The f/w needs to know what networks exist on the inside of their private interface.  You may need to had a route statement in the f/w that says the 10.0.2.x network exists behind the 10.0.1.2 (what I believe should be the IP address of the switch that connects to the f/w).
0
 
The--CaptainCommented:
It sounds like the machines in 10.0.2.* do not have a route back to any of the other networks in question, but the info provided is rather vague.  

Can you provide a list of IP addresses for *all* interfaces of *all* equipment in question, as well as their respective routing tables?

Such a list would go a long way toward solving this one...

BTW, I agree that there is likely a typo in the original post, although I've seen stranger mickeysoft configs that worked despite such horrible disagreements WRT subnet mathematics.

Cheers,
-Jon
0
 
spillsburyAuthor Commented:
Yikes... YES... there is a typo.
"10.0.1.- uses only 2 ip addresses: 10.0.1.1 = trusted IP of firewall and 10.0.2.2 is the port/ip on the switch"
should read:
10.0.1.- uses only 2 ip addresses: 10.0.1.1 = trusted IP of firewall and 10.0.1.2 is the port/ip on the switch

I'll collect the other IP's and route tables and post them ASAP.
0
 
spillsburyAuthor Commented:
Turns out it was an "easy" problem. It was something I had completely forgotten about and hadn't even considered.

When I created the second subnet (10.0.2.x) I inadvertently chose the same subnet that I had already used for my VPN connections.

To fix, all I did was change my that subnet from 10.0.2.x to 172.16.1.x

Things work fine now.

Thanks for all the suggestions.
-Scott
0
 
moduloCommented:
PAQed with points refunded (500)

modulo
Community Support Moderator
0

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now