Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

1721 Connectivity Problem

Hi -

We are using Cisco 1721 routers for Internet access. We have 2 of these 1721s each connected to its own frame-relay T1 via the internal WIC cards.

We are noticing that there are some IP addresses that we can ping from the routers via the console ports but are unable to do so from behind the router. We have gone as far as by passing our firewalls to ensure it is not a firewall issue. There are no access lists.

Below are the configuration of these routers:

version 12.2

service timestamps debug uptime

service timestamps log uptime

service password-encryption

!

hostname Internet-1

!

enable secret 5 xxxxxxxxxxxxxxxxxxxxxxxxxxx

!

ip subnet-zero

!

!

!

!

interface FastEthernet0

ip address xxx.xxx.xxx.1 255.255.255.0

speed auto

!

interface Serial0

bandwidth 1544

ip address xxx.xxx.xxx.138 255.255.255.252

encapsulation frame-relay IETF

frame-relay lmi-type ansi

!

ip classless

ip route 0.0.0.0 0.0.0.0 206.196.130.137

no ip http server

!

!

!

line con 0

password 7 xxxxxxxxxxxxxxxxx

login

line aux 0

line vty 0 4

no exec

exec-timeout 0 1

login

transport input none

!

end

The only difference between the 2 routers are the IP addresses.

Does anyone out there have any suggestions for troubleshooting this issue?

TIA

Mike

  • Other Network Infrastructure Subjects
7 REPLIES
Silver

Re: 1721 Connectivity Problem

Mike,

A couple things.

1. Can hosts on FastE 0 ping 167.86.144.1 ?

If not a local link issue might exist.

2. If they can, can they ping the far end of your FR link (assume 206.196.130.137 by your default)?

If not there is more than likely a routing issue where your upstream router (206.196.130.137) does not have a route for your 167.86.144.0/24 network that your hosts are on. Since you are not running any dynamic routing protocols on this router this would need to be statically done on the upstream router for return traffic from the 167.86.144.0 network to make it back to this router.

ip route 167.86.144.0 255.255.255.0 206.196.130.138 on the upstream would do the trick.

Hope this helps you,

Don

New Member

Re: 1721 Connectivity Problem

Don -

Thanks for your input. From the ethernet side of the router (FastE 0) I have no problem pinging 167.86.144.1 or 206.196.130.137.

The problem was brought to our attention when some email sites could not deliver email to us. Upon testing we found that we could not ping these sites from the FastE 0 port but could if we were pinging these sites directly from the router via the console port.

Keep in mind that this is only a handful of sites that we are having this problem with.

Mike

Bronze

Re: 1721 Connectivity Problem

Hi Mike,

I noticed that your provider is announcing 167.86.144.0/24 to the world (altough you have the full /16 assigned to you according to the Arin database), so maybe the route is getting filtered out by some providers because the netmask is too long. I would think /24s are not filtered but since it would cause the symptoms described I thought I'd mention it.

Any particular reason why your ISP is not announcing 167.86.0.0/16 to the world?

regards,

Herbert

New Member

Re: 1721 Connectivity Problem

Hi Herbert -

Thanks for taking the time to try to help me out.

We only announce the 167.86.144.0/24 on this link because it is the the only group of IPs we have exposed to the Internet.

If some providers were filtering these out because of the subnet mask then I would expect to see traffic fail to reach its destination from both the router and anything behind it. In our case the router can ping these problematic destinations with no problem, it is only a problem for anything behind the router.

Mike

Bronze

Re: 1721 Connectivity Problem

When you ping from the router it is sourcing from its serial address, not the address on the ethernet. Try an extended ping from the router using the ethernet address and see if that works.

New Member

Re: 1721 Connectivity Problem

RJackson -

When using an extened ping sourcing from the ethernet address I can not ping these hosts in question.

Do you think this is due to the subnet mask scenerio described above by Herbert? If so any thoughts on resolving this? I have more than 1 Internet link that uses our 167.86.x.x addresses. Might this be a scenerio for using NAT?

Any ideas would be greatly appreciated!

Mike

Bronze

Re: 1721 Connectivity Problem

To find out if this is really the cause, you could

- do a traceroute from the router, then from the ethernet (or an extended traceroute from the router with the ethernet interface as source) and see where it stops: the next hop probably does not have a route back to you (or is a firewall, but in that case the trace from the router should also stop there).

- then contact the administrators of the IP block of the hop that does not have a route to you.

To look up who an IP address belongs to, you can use

http://ws.arin.net/cgi-bin/whois.pl (for North American addresses, otherwise Arin will refer you to another registry, e.g. RIPE for Europe).

But to answer your question: if you only have traffic originating inside your network (i.e. you don't run any servers that are accessible via this link) then NAT could be a solution, as you could hide all your internal addresses behind the serial interface's address which appears to be globally reachable.

If you do have internal hosts that should be reachable (e.g. your mail server) than you could ask your ISP for an extra range of addresses (out of his block, so globally reachable) and assign these to your servers (or do static NAT) and use one for hiding (overload) NAT.

Another workaround might be to announce not just the /24, but a /22 for example; if that's possible without overlapping with the other ranges used.

hth

Herbert

88
Views
0
Helpful
7
Replies
This widget could not be displayed.