frame relay circuit issue

[volleyman]

All,

I have a new frame relay circuit that will not connect.

On my local side, I am seeing the interface up/up and when I do a "sh frame pvc" I am only seeing packets going out but nothing coming back. I am seeing the same thing on the remote side. Here is the running config:

interface Serial1/0
no ip address
encapsulation frame-relay
no ip mroute-cache
priority-group 1
service-module t1 remote-alarm-enable
frame-relay lmi-type ansi

interface Serial1/0.2 point-to-point
description Tempe
bandwidth 384
ip address 10.130.64.14 255.255.255.252
frame-relay class wsc
frame-relay interface-dlci 35

router rip
version 2
network 10.0.0.0
no auto-summary
!
ip default-gateway 10.130.68.238
ip classless
ip route profile
ip route 0.0.0.0 0.0.0.0 10.130.68.238
ip route 10.130.127.0 255.255.255.248 10.130.68.237
ip http server
!
!
map-class frame-relay wsc
frame-relay adaptive-shaping becn
frame-relay cir 128000
frame-relay bc 8000
frame-relay be 16000
frame-relay mincir 128000
priority-list 1 protocol ip high tcp 3389
priority-list 1 protocol ip low tcp 1080
snmp-server engineID local 00000009020000309432CC80
snmp-server community public RO
snmp-server location Carol Stream
snmp-server contact John Lucito,630-682-4500,jlucito@pellawin.com
!
line con 0
exec-timeout 0 0
password 7 1101180B104205
login
line aux 0
line vty 0 4
password 7 1101180B104205
login
!
end

carolstream#sh frame pvc

DLCI = 35, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/0.2

input pkts 0 output pkts 840 in bytes 0
out bytes 330572 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 686 out bcast bytes 323356
pvc create time 01:15:19, last time pvc status changed 01:15:19

 

[volleyman]

is it possible that the telco hasn't mapped the circuit correctly or does this point to a config problem? oh, btw:

rolstream#sh ip int s1/0.2
Serial1/0.2 is up, line protocol is up
Internet address is 10.130.64.14/30
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.9
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP fast switching on the same interface is enabled
IP Flow switching is disabled
IP Fast switching turbo vector
IP multicast fast switching is enabled
IP multicast distributed fast switching is disabled
IP route-cache flags are Fast
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Probe proxy name replies are disabled
Policy routing is disabled
Network address translation is disabled
WCCP Redirect outbound is disabled
WCCP Redirect inbound is disabled
WCCP Redirect exclude is disabled
BGP Policy Mapping is disabled
IP multicast multilayer switching is disabled

 

[lgarner]

try "term monitor" and "debug frame lmi" to see what is going between the router and the CO switch.

 

[volleyman]

tried that...nothing unusual. the results for this particular interface match those of other interfaces that are connecting and working just fine.

 

[techkiwi]

You could try "show frame-relay lmi" and check to make sure that "Num Status Enq. Sent" and "Num Status msgs Rcvd" are both incrementing every 10 seconds.

 

[volleyman]

Spoke with Sprint. As I thought, they haven't mapped the frame circuits correctly. Looks like my config is probably good. Is it really that difficult to map frame relay circuits from the telco side? This seems to be a common problem I've run into...either not mapped correctly or mappings are accidentally deleted.

 

[vipergg]

Make sure your mtu sizes match on both ends otherwise routing might not come up . OSPF will not come up with the newer codes unless the mtu size on the serial interfaces on each end match .

 

[routerman]

Volleyman,

I work for a global ISP, we provide a lot of frame circuits and yes, we do get those mappings wrong from time to time.

Its not complex, usually someones messed up the paperwork...

 

[volleyman]

vipergg: if you'll notice, we're not using OSPF...sticking with good old RIP. But thanks.

Routerman: I worked for a global drug company up until 2 weeks ago. It was VERY common for the telco to delete mappings on circuits that had been in place for years. We had a difficult time figuring out why. Our on-site service manager couldn't come up with an answer. Maybe you can shed some light on the topic for me.

thanks for your responses!!!

 

[techkiwi]

Have you got this working now?

 

[volleyman]

sure do, as mentioned above, Sprint acknowledged that they mapped the circuits incorrectly. Thanks!!