Hardware, Config or Circuit, how can I tell? 1

[jwintersoccom]

I am trying to get an ATM connection of 1Mb between a new T3 (mine) and an existing T3 for Internet bandwidth on a Cisco 7206 VXR.

This has been going on for a couple weeks and I am at the end of a drop dead date for getting it running.

The tech at the remote ISP has done the configuration at both ends. Supposedly it was all correct but initially we were getting an red Rx Alarm light on my end.

It was supposedly the telcos problem but when he had me type something over the phone the light went out.

The telco gave out the wrong VPI/VCI's a couples times I was told, causing us to not be able to link up.

Now for the past few days I am told the telco did not build the circuit out for his end and it went to a "dangling circuit". They were supposedly working to build it out.

After not hearing back from the ISP, I checked the status of the trouble ticket with the telco. The telco indicated they were asked by the ISP for the VPI/VCI which thery provided and that was all they did.

I don't know which to believe. The telco could be correct, but being that it is Qwest I am not in a hurry to jump to their side.

I am wondering how I can know for sure it is not the Enhanced ATM card (not questioned by anyone yet) which I bought used, or narrow it between the ISP and the telco.

I have a green enabled and Rx Carrier lights. I never see the Rx Cells green light but think it is only on when traffic is passed. Qwest indicated they see equipment and it seems to be working right.

I believe there is indication of outgoing traffic but no incoming from both routers.

This is a show run from my router.

Things you should know:

1. Anything 207.174.8.* is from an old network and is not used. I am told this will not affect at least reaching the Inet and could be cleaned up later.
2. I can't ping his routher from the router but can from another unrelated network. (I think this just started woking.)
3. His router interface should be 207.174.17.65 and mine 207.174.17.66.
4. We added a 207.174.17.67 the other day I think just for troubleshooting but I'm wondering if it even could work with the restricted subnet.
5. The 209.169.3.* should be my new IPs routed through the fast ethernet port.
6. There is a serial port that is not used but present.
7. I'm ignorant about this. (Oh, you could tell?)
---------------------------------------

AS1#ping 207.174.17.66

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 207.174.17.66, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
AS1#ping 207.174.17.65

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 207.174.17.65, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
AS1#show run
Building configuration...

Current configuration : 1466 bytes
!
version 12.0
service config
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname AS1
!
enable secret
enable password
!
syscon address 207.174.8.4 something..
syscon shelf-id 0
ip subnet-zero
!
!
ip ssh time-out 120
ip ssh authentication-retries 3
no mpls traffic-eng auto-bw timers frequency 0
!
!
!
!
interface FastEthernet0/0
ip address 209.169.3.1 255.255.255.0
no ip redirects
no ip unreachables
no ip directed-broadcast
no ip proxy-arp
no ip mroute-cache
no cdp enable
!
interface Serial1/0
ip address 207.174.8.5 255.255.255.0
no ip directed-broadcast
no ip mroute-cache
fair-queue 64 256 0
dsu bandwidth 44210
framing c-bit
cablelength 10
!
interface ATM2/0
no ip address
no ip unreachables
no ip directed-broadcast
no ip proxy-arp
no ip mroute-cache
atm scrambling cell-payload
atm framing cbitplcp
atm idle-timeout 0
no atm enable-ilmi-trap
no atm ilmi-keepalive
!
interface ATM2/0.10 point-to-point
description Indra Upstream ATM
ip address 207.174.17.66 255.255.255.252
no ip directed-broadcast
no atm enable-ilmi-trap
pvc indra 1/32
protocol ip 207.174.17.67 broadcast
ubr 942
encapsulation aal5snap
!
!
ip classless
ip route 0.0.0.0 0.0.0.0 207.174.17.65
ip route 209.169.3.0 255.255.255.0 FastEthernet0/0
!
!
!
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
password somethingelse
login
!
end

----------------------------

Any suggestions at all would be greatly appreciated. I don't mind looking myself and hate simple questions that people should have been able to find on their own.

Perhaps I'm just not that bright, but i have been looking at material for many, many hours and can't find what I need.

Thank you in advance for any pointers or suggestions. I am really really at wits end here.

J. Winters

 

[NTPeave]

Well, you've probably missed your deadline by now (sorry - I haven't checked tek-tips for a while) so I hope you're still employed.

Lets start with some basic stuff. You don't need the second static route - "ip route 209.169.3.0 ..." Static routes are one of many ways of telling the router "These numbers (address/mask) are out this interface..." Static routes are, by default, the second most trusted routes that most routers learn - the MOST trusted routes are directly connected routes, which this route already is. If you connect a valid ethernet cable into Fa0/0, this route will already be available to the router. Do the command "show ip route" in this router and notice the 'C', for "connected" beside that route. Change the static route address to something you won't need to route to, like "ip route 109.169.3.0 255.255.255.0 fa0/0" and do 'sh ip route' again - you'll see the new fake route with an 'S' beside it.

Next, "protocol ip 207.174.17.67 broadcast" should have the IP address of the remote end: 207.174.17.65 - the broadcast does NOT indicate that you need to include the 'broadcast' address for this subnet! The broadcast keyword means that (in this case) IP related broadcasts can be used with this map entry - eg: OSPF broadcasts if you were to use OSPF.

None of this fixes your main problem of the VPI/VCI not matching between you/telco/remote end. You must get that sorted first. Router configurations don't matter a bit if they're not even connected. Get back on the phone to telco and ISP...

Depending on the IOS version you're using, look at what commands you can enter starting with "show atm", such as "sh atm pvc". If you still think you and the telco have a VPI/VCI mismatch, maybe "sh atm traffic" will give you some evidence in the output lines similar to:

"0 Packets received on non-existent VC

6 Packets attempted to send on non-existent VC"

If you have a loging to

http://www.cisco.com

that gives you access to "ouput interpreter" paste in your output to some of these "sh atm ..." commands. If you don't have such access, start asking your local Cisco Support staff now for next time ;-)