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:
service timestamps debug uptime
service timestamps log uptime
enable secret 5 xxxxxxxxxxxxxxxxxxxxxxxxxxx
ip address xxx.xxx.xxx.1 255.255.255.0
ip address xxx.xxx.xxx.138 255.255.255.252
encapsulation frame-relay IETF
frame-relay lmi-type ansi
ip route 0.0.0.0 0.0.0.0 22.214.171.124
no ip http server
line con 0
password 7 xxxxxxxxxxxxxxxxx
line aux 0
line vty 0 4
exec-timeout 0 1
transport input none
The only difference between the 2 routers are the IP addresses.
Does anyone out there have any suggestions for troubleshooting this issue?
2. If they can, can they ping the far end of your FR link (assume 126.96.36.199 by your default)?
If not there is more than likely a routing issue where your upstream router (188.8.131.52) does not have a route for your 184.108.40.206/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 220.127.116.11 network to make it back to this router.
ip route 18.104.22.168 255.255.255.0 22.214.171.124 on the upstream would do the trick.
Thanks for your input. From the ethernet side of the router (FastE 0) I have no problem pinging 126.96.36.199 or 188.8.131.52.
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.
I noticed that your provider is announcing 184.108.40.206/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 220.127.116.11/16 to the world?
We only announce the 18.104.22.168/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.
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?
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
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.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...