7 replies to this topic

[nwbell]

Hello!

They say everybody is a n00b on some subject. IOS is one of many such subjects for me.

Here's the situation: I have a Cisco 2620 running 12.3(26)c. FastEthernet0/0 is the onboard 10/100 interface, and is hooked to my private network (10.22.0.0/24). FastEthernet1/0 is the 10/100 interface on a NM-1FE-TX WIC, and is hooked to my ISP's network (obscured here as 71.x.x.x). My config is as follows:

no aaa new-model
ip subnet-zero
ip cef
!
ip dhcp excluded-address 10.22.0.1 10.22.0.100
ip dhcp excluded-address 10.22.0.200 10.22.0.254
!
ip dhcp pool mypad
   network 10.22.0.0 255.255.255.0
   dns-server 8.8.8.8 4.2.2.2
   default-router 10.22.0.254
   domain-name mypad.mydomain.net
!
ip audit po max-events 100
!
interface FastEthernet0/0
 ip address 10.22.0.254 255.255.255.0
 ip nat inside
 duplex auto
 speed auto
!
interface FastEthernet1/0
 ip address 71.x.x.x 255.255.255.0
 ip nat outside
 duplex auto
 speed auto
!
ip nat inside source list 1 interface FastEthernet1/0 overload
ip http server
ip classless
ip route 0.0.0.0 0.0.0.0 71.x.x.254

Everything is working just peachy, but there's one problem: I can't get through to a fair number of hosts, particularly ones in the 69/8 space. We'll use car-part.com (69.24.29.68) for example - try to access it from behind the Cisco, no go; connect the outside connection directly to one of my machines and try it, all good.

Right now my main issue is identifying the problem specifically. Once that's done, I (obviously) need to resolve it.

Anyone willing/able to give me some direction here?


--nwbell

[wwwd40]

Sorry, Don't know anything about the iphone OS Im sure there is more, but here are some questions that sprung to mind.

1. That doesn't look to be a full config, but what is there looks all good. I take it there are no ACL's etc that could be blocking the traffic? What does the acl 1 specify that is used to limit the NAT? "ip nat inside source list 1 interface FastEthernet1/0 overload"

2. Is it just web traffic or is all connectivity affected?

3. When the machine behind the Cisco has an issue (unable to web? ping?) are you able to hit the address from the Cisco itself (fake a web session with telnet; ping address)

4. Where does the traceroute from the PC towards the problem address stop? At the Cisco?

5. Is there any loss towards the problem address (from enable, "ping")?

6. Seems strange that it should only be a range of addresses affected. Can you reconfigure fe0/0 to be the WAN interface?


~wd

Edited by wwwd40, 09 August 2011 - 04:43 AM.

[phaedrus]

ip route 0.0.0.0 0.0.0.0 71.x.x.254

Shouldn't that be :-

ip route 0.0.0.0 0.0.0.0 fe1/0

In that you define the routing, the netmask then tell it what interface to take out, and it works out the routing to the 71.x.x. range from the interface definition you specified earlier.

Also the entire 69/8 space used to be a reserved netblock for ARIN, and ended up being filtered out by a lot of old router configs as it was used as spoofed source in lots of DOS and other activities, so its possible that your upstream is still doing this even today.
Link on the whole 69/8 thing.
http://puck.nether.n...s/69-paper.html

You should connect at command line level to your cisco and do a show ip route to see if theres anything in place your end, and check onward connectivity using the usual telnet/traceroute etc. Odds on if you started with a clean config on the cisco, its upstream at your ISP.

[wwwd40]

Shouldn't that be :-

ip route 0.0.0.0 0.0.0.0 fe1/0

As per OP, it's working for all addresses other than 69/8 so the default route statement must be OK. Additionally it works when PC is directly connected to 'modem', just not when via the cisco so its unlikely to be a throwback to pre 2002 filtering on the SP side - nice reference tho From the description it does seem to point to the cisco however its a little inconsistent.

I'm guessing the show ip route will give the default route but worth a go. Either way, some cli from the router is the best way to narrow down further on the issue.

~wd

[nwbell]

I take it there are no ACL's etc that could be blocking the traffic?

What you see is what I'm running. I trimmed the lines related to the router's hostname, passwords, and console lines; everything else is as-is. There are no ACLs in use.

When the machine behind the Cisco has an issue (unable to web? ping?) are you able to hit the address from the Cisco itself (fake a web session with telnet; ping address)

Yes. Simple test: "telnet 69.24.29.68 80", then "GET /" - from behind the Cisco, session opens but no response from the GET; from the Cisco itself, the page is returned.
Strangely enough, I also tried some other requests ("GET /foo", for example, to get a 404). THAT works from machines behind the Cisco. I can make the same request from Safari, too; the 404 page appears but Safari waits endlessly for "/favicon.ico" (which, like "/", won't load from machines behind the Cisco).

Where does the traceroute from the PC towards the problem address stop? At the Cisco?

Oddly, it doesn't stop.

Is there any loss towards the problem address (from enable, "ping")?

Haven't been able to determine - this is the only IP I've been able to single out so far, and it doesn't return pings.

[wwwd40]

Interesting stuff. So the pages return when hit straight from the Cisco, but not when tried from the hosts on the lan. The 404 behaviour you describe is not making much sense to me!

It could be some strange session issue though the only config I see that is questionable is the NAT source list. Try configuring the NAT list with a network and mask suitable for your internal network, for example

hostname(config)# access list 1 permit 10.22.0.0 0.0.0.254


Also could you provide a copy of the (sanatised) output from "show ip nat translation verbose" when you have a web session towards the problem IP and also while you have a traceroute running from one of the internal hosts? This will help ascertain whether NAT is working correctly.

~wd

[nwbell]

access list 1 permit 10.22.0.0 0.0.0.254

I did end up adding that exact line to my config in the process of testing; it made no difference. I also tried swapping the interfaces around, clearing the config and starting over, etc. Even tried removing my switch from the equation, just to be sure (recently moved from a 32-port 10/100 HP ProCurve to a Catalyst 2948). None of my changes made any noticeable difference.

Also could you provide a copy of the (sanatised) output from "show ip nat translation verbose" when you have a web session towards the problem IP and also while you have a traceroute running from one of the internal hosts? This will help ascertain whether NAT is working correctly.

I'll have to get that together. Got sick of messing around and swapped in my spare (a 2514) last night, so I'll have to put things back first.

Edited by nwbell, 11 August 2011 - 08:56 PM.

[phaedrus]

Is there any more diagnostics/updates or a resolution on this?
I'm as curious as everyone else, and I have some lingering doubts about why it seems to affect the 68/8 netblock.
It may come up in daily life for at least someone else and be useful to know.