Subnetting Problems

[craig-allen]

Hello,

I have a question about the following:

Subnet 1: 10.0.0.0/16

Subnet 2: 10.1.0.0/16

Subnet 3. 10.7.0.0/16

Subnet 4: 10.8.0.0/16

Are the above valid/unique subnets based on what I've given?

The problem.

Host in subnet 1 cannot ping a host in subnet 2 or 7 -> packet doesn't even reach the gateway using traceroute. Appears an arp request is being sent therefore thinks host in subnet 2/7 is in subnet 1

Host in subnet 1 can ping host in subnet 4, can do a traceroute - first hop default gateway.

Thanks

Craig

[Richard Burts]

Craig

The addresses that you posted would be valid and unique subnets.

I find part of your question somewhat confusing: you talk about a host in subnet 1 and subnet 2 so I think that you are using the subnet numbers, but then you talk about subnet 7 and that appears to reference the second octet. Given the uncertainty I hope that I interpret your question correctly.

The problem might be in the router configuration or might be in the host configuration. I suspect that it is in the host configuration - specifically I believe that the host in subnet 1 is configured with an incorrect mask. If the host in subnet 1 were configured with mask 255.248.0.0 instead of 255.255.0.0 it would produce exactly the symptoms that you describe.

Can you check the configuration of the hosts and let us know?

HTH

Rick

[craig-allen]

Hello Rick,

Thanks for the reply.

Yes, I am indeed using the subnet numbers and not the IP address as my explanation.

What I'm trying to explain is that the following subnets:

10.1.0.0 -> 10.7.0.0 /16 do not seem to reach the default gateway. First hop in a traceroute is * * *

Whereas when tracing an ip in 10.8.0.0 /16 first hop is the default gateway (10.0.0.254)

The above traceroutes were performed in subnet 10.0.0.0/16

I have triple checked the subnet mask on all hosts as this was the first thing I thought of.

I in the process of trying to recreate thie above in a lab but time is not on my side.

[Kevin Dorrell]

I do not understand what you mean by "the default gateway (10.0.0.254)" and "The above traceroutes were performed in subnet 10.0.0.0/16". Normally, the default gateway configured on a host should be inside the host's subnet. So a host 10.1.a.b/16 would need to be configured with a default gateway somewhere in the range 10.1.x.y/16, and the router should have that address configured for that subnet.

What is the address and mask configured on your router? Is the mask 255.248.0.0 by any chance?

Kevin Dorrell

Luxembourg

[craig-allen]

Hello Kevin,

Thanks for the reply, let me explain with IP's instead.

I'm sitting @ a workstation with IP 10.0.0.100 255.255.0.0. Default Gateway is 10.0.0.254 255.255.0.0 (this is a PIX 515e)

If I try to ping the following host 10.1.0.10 255.255.0.0 I get request timed out. A traceroute reveals the first hop as * * * surely I should get the default gateway as the first hop??

The same happens for any hosts in subnets 10.2.0.0 -> 10.7.0.0

Now if I try to ping the following host 10.8.0.10 255.255.0.0 (still @ workstation 10.0.0.100) I get a request timed out (that's because the host doesn't exist). BUT if I do a traceroute my first hop is 10.0.0.254 and thereafter * * * Point being I'm reaching the default gateway.

So in summary any packets destined for subnets 10.1.0.0 -> 10.7.0.0 /16 are not reaching the default gateway whereas any packets for a subnets above 10.8.0.0 /16 get forwarded.

My confusion lies in the fact that even if the subnets don't exist the packets should still reach the default gateway

[Kevin Dorrell]

OK, I think I understand the problem now. That is, I understand what is happening, but not necessarily why.

One thing you should beware of is that traceroute is not always relieable. It depends on whether the particular hop can send back an ICMP "TTL expired" or not. Furthermore, a router's version of trace is entirely different from a PC's version - one uses ICMP echo and the other uses port 445, I think.

But having said all that, it does not explain why you see a difference in behaviour between a 10.0.0.0/21 address and a 10.8.0.0/21 address. I suspect it may be something to do with the PIX itself. Maybe the PIX has been programmed to send back ICMPs for the 10.8.0.0 subnet, but not for the others. Or maybe the PIX has routes for 10.[0-7].0.0/16, but not 10.8.0.0/16.

Is there any way you can snoop on the ingress side of the PIX?

Alternatively, could you do a netstat -r on the workstation, and see if there is anything strange in its routing table.

Kevin Dorrell

Luxembourg

[Richard Burts]

Windows PC traceroute is based on ICMP. traceroute on Cisco (and Unix and many other implementations) is based on UDP (not port 445).

I think it would be helpful to look at the configuration of the router and of the PIX. The idea that the PIX might have routes for 10.1.x.x to 10.7.x.x that are different from 10.8.x.x is a very interesting idea. It might also be possible that there is something in the router config that is causing the different results to traceroute.

HTH

Rick