unable to reach 64.x.x.x nets thru router

Unanswered Question
Feb 25th, 2008

For some reason I am unable to reach any nets that start with 64.x.x.x like www.cnn.com. If I do a sho ip route to addresses I get this.

tuc-rtr#sho ip route 64.236.16.20

% Subnet not in table

tuc-rtr#sho ip route 66.18.100.2

% Network not in table

tuc-rtr#sho ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is 64.209.111.129 to network 0.0.0.0

What is the difference between subnet not in table and network not in table?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Richard Burts Mon, 02/25/2008 - 13:39

Juan

I believe that the difference is that you are in network 64.209.111 (especially based on this in what you posted: Gateway of last resort is 64.209.111.129 to network 0.0.0.0

Since you are in network 64 when you look for other addresses the IOS assumes that you are looking for other subnets. But when you look for network 66 it assumes that you are looking for a network.

HTH

Rick

Richard Burts Mon, 02/25/2008 - 13:57

Juan

I do not believe that the 0s static route is causing it. I believe that the addressing of the interface(s) is what is causing it. Please post the output of show ip interface brief so that we can see clearly what addresses are used by what interfaces.

HTH

Rick

cirrushelpdesk Mon, 02/25/2008 - 14:01

Rick,

Here you go.

tuc-rtr#sho ip int brief

Interface IP-Address OK? Method Status Protocol

FastEthernet0/0 208.51.255.193 YES NVRAM up up

FastEthernet0/1 198.90.240.1 YES NVRAM up up

Serial0/0/0 unassigned YES NVRAM up up

Serial0/1/0 unassigned YES NVRAM up up

Serial0/2/0 unassigned YES NVRAM up up

FastEthernet0/3/0 198.168.100.1 YES manual up up

Multilink1 64.209.111.130 YES NVRAM up up

Tunnel1 198.90.145.202 YES NVRAM up up

Tunnel80 198.90.145.182 YES NVRAM up up

tuc-rtr#

Richard Burts Mon, 02/25/2008 - 14:09

Juan

Thanks for posting the information. It confirms what I had thought. It is not because of the 0s route. It is because of the IP addressing of your interface. Your interface multilink1 is in the 64 network (Multilink1 64.209.111.130). so any time that you look for something else in 64 the IOS knows that you are not looking for the entire network (you already know where part of it is since you are connected to it) and therefore you must be looking for some other subnet. So the message you get when you look for 64 is about subnets. But when you look for 66 the IOS knows that you do not have any part of 66 already so you must be looking for the network rather than looking only for a subnet.

Perhaps it will help to understand this to think about how the IOS does lookups in the routing table. It is based on longest match. So when it is searching the routing table for 64.x.x.x and finds some entry in 64 but not an entry that matches what it is looking for then it knows that it must be looking for a subnet. And the message it gives is about subnet. But in searching the routing table for 66 it does not find any entry so it says it can not find the network.

HTH

Rick

kschleppenbach Mon, 02/25/2008 - 14:20

I suspect the mask is wrong on router interface with the 64.x.x.x address. what does its config look like?

cirrushelpdesk Mon, 02/25/2008 - 14:30

Here is the config on the interface

interface Multilink1

description Telstra 3xT1$FW_OUTSIDE$

bandwidth 4632

ip address 64.209.111.130 255.255.255.252

ip access-group 198 in

ip access-group 199 out

no ip redirects

no ip unreachables

no ip proxy-arp

no cdp enable

ppp multilink

ppp multilink group 1

ppp multilink fragment disable

crypto map cirrus-vpn-map

Here is the entry in the routing table for 64.0.0.0

64.0.0.0/8 is variably subnetted, 3 subnets, 2 masks

C 64.209.111.128/30 is directly connected, Multilink1

C 64.209.111.129/32 is directly connected, Multilink1

D EX 64.132.38.124/30 [170/14052608] via 198.90.145.181, 3d08h, Tunnel80

Richard Burts Mon, 02/25/2008 - 15:19

I am curious what made Kevin think that there was something wrong with the mask. It looks ok to me.

And the issue about why the message sometimes says subnet not in table and sometimes says network not in table is pretty clearly a function of whether the router has any existing subnet of the network in its routing table.

HTH

Rick

kschleppenbach Mon, 02/25/2008 - 20:28

Whenever the issue relates to a specific network, especially when it's directly connected, the first place to look is the gateway and mask. Now that we have seen the interface config I agree, that is not the issue. Next we need to look closer at the route table and the ACL applied to that interface.

cirrushelpdesk Tue, 02/26/2008 - 07:50

I dropped all acl's during this testing, here are some traceroutes.

Please see the traceroutes below, this is from my Tucson router, service ID for that circuit is TUS GID 80999. All access lists are dropped during this testing.

Here is to two 64 address sourcing my outside interface:

tuc-rtr#traceroute

Protocol [ip]:

Target IP address: 64.236.24.12

Source address: 64.209.111.130

Numeric display [n]:

Timeout in seconds [3]:

Probe count [3]:

Minimum Time to Live [1]:

Maximum Time to Live [30]:

Port Number [33434]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Type escape sequence to abort.

Tracing the route to 64.236.24.12

1 * * *

2

tuc-rtr#traceroute

Protocol [ip]:

Target IP address: 64.191.144.223

Source address: 64.209.111.130

Numeric display [n]:

Timeout in seconds [3]:

Probe count [3]:

Minimum Time to Live [1]:

Maximum Time to Live [30]:

Port Number [33434]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Type escape sequence to abort.

Tracing the route to 64.191.144.223

1 * * *

2 * * *

3

Here is to a 66 address sourcing both my outside and an internal interface

tuc-rtr#traceroute

Protocol [ip]:

Target IP address: 66.18.100.2

Source address: 64.209.111.130

Numeric display [n]:

Timeout in seconds [3]:

Probe count [3]:

Minimum Time to Live [1]:

Maximum Time to Live [30]:

Port Number [33434]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Type escape sequence to abort.

Tracing the route to 66.18.100.2

1 64.209.111.129 24 msec 24 msec 16 msec

2 67.17.110.2 20 msec 20 msec 20 msec

3 67.17.110.2 20 msec 28 msec 20 msec

4 64.212.107.86 16 msec 16 msec 24 msec

5 65.106.1.54 24 msec 24 msec 24 msec

6 65.106.1.53 [MPLS: Label 174416 Exp 0] 20 msec 20 msec 20 msec

7 65.106.1.50 [MPLS: Label 170240 Exp 0] 24 msec 20 msec 24 msec

8 65.106.0.13 [MPLS: Label 228112 Exp 0] 56 msec 56 msec 56 msec

9 65.106.1.38 [MPLS: Label 200976 Exp 0] 56 msec 56 msec 60 msec

10 65.106.0.9 72 msec 72 msec 72 msec

11 65.106.4.46 104 msec 80 msec 80 msec

12 207.88.85.106 76 msec 76 msec 76 msec

13 66.238.242.46 80 msec 76 msec 76 msec

14 67.216.160.17 80 msec 76 msec 80 msec

15 * * *

16

tuc-rtr#traceroute

Protocol [ip]:

Target IP address: 66.18.100.2

Source address: 208.51.255.193

Numeric display [n]:

Timeout in seconds [3]:

Probe count [3]:

Minimum Time to Live [1]:

Maximum Time to Live [30]:

Port Number [33434]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Type escape sequence to abort.

Tracing the route to 66.18.100.2

1 64.209.111.129 24 msec 24 msec 24 msec

2 67.17.110.2 24 msec 24 msec 24 msec

3 67.17.110.2 24 msec 24 msec 24 msec

4 64.212.107.86 24 msec 24 msec 16 msec

5 65.106.1.54 20 msec 20 msec 24 msec

6 65.106.1.53 [MPLS: Label 174416 Exp 0] 24 msec 24 msec 24 msec

7 65.106.1.50 [MPLS: Label 170240 Exp 0] 20 msec 24 msec 20 msec

8 65.106.0.13 [MPLS: Label 228112 Exp 0] 56 msec 56 msec 56 msec

9 65.106.1.38 [MPLS: Label 200976 Exp 0] 56 msec 56 msec 56 msec

10 65.106.0.9 72 msec 68 msec 72 msec

11 65.106.4.30 76 msec 76 msec 80 msec

12 207.88.85.122 84 msec 80 msec 76 msec

13 66.238.242.46 80 msec 76 msec 80 msec

14 67.216.160.1 76 msec 76 msec 80 msec

15 * *

Richard Burts Tue, 02/26/2008 - 08:22

juan

Up to this post I thought that the question that we were discussing was the question raised in your original post:

What is the difference between subnet not in table and network not in table?

This post shows that there is a different issue about failure to access the 64 network. We have not yet seen the complete router config and perhaps I should ask you to post it. But based on these symptoms I believe that I know what it is. I believe that your router is configured with "no ip classless". I believe that if you configure "ip classless" that you will be able to access those other addresses in the 64 network. If changing the ip classless does not fix the problem then please post the complete config of the router.

HTH

Rick

cirrushelpdesk Tue, 02/26/2008 - 08:41

Rick/Kevin,

Thanks for all your help, ip classless fixed the problem. I have looked at that config probably over 100 times in the last week and still didn't see that. It seems to be working now. Thanks again.

Juan

Danilo Dy Tue, 02/26/2008 - 21:13

Hi,

Just to add, "ip classless" is not enable by default in older IOS, in the configuration you will see it as "no ip classless", if you enable it you will see it as "ip classless". In 12.4 "ip classless" is enable by default and you will not see it in the configuration unless you disable it and it will show as "no ip classless" .

Regards,

Dandy

Richard Burts Tue, 02/26/2008 - 09:15

Thanks for the compliment. I am glad that we were able to resolve the issue. IP classless has been the default for so long that it is not something that we usually look for and it is sometimes hard to spot its impact when no ip classless has been configured.

HTH

Rick

Actions

This Discussion