2 Frame DLCI's one works, the other won't carry a load, running EIGRP

preston · ‎05-01-2003

Situation,

2 main locations with 3600 series routers, these locations connected by T1.

Each main location also has a Frame T (sprint 0 CIR)

8 Remote Locations, useing 2600 connecting, to both the main locations via 2 dlci's. For example DLCi 30 goes to Main location 1 DLCI 31 goes to Main location 2.

EIGRP is my routing protocal, nothing fancy on it.

Router EIGRP 100

network 172.16.0.0 (my frame)

network 192.168.63.0 (my ethernet)

network 172.19.0.0 (my GRE Tunnel)

Each frame interface is configured via subinterface with its IP and its DLCI

Int s0/1.1

ip address 172.16.66.10 255.255.255.252 -----------.66.9 at hub site 1 dlci 50

frame-relay interface-dlci 30

int s0/1.2

ip address 172.16.33.10 255.255.255.252 -------------33.9 at hub site 2 dlci 51

frame-relay interface-dlci 31

The problem, everything works but one site, a remote and one of its DLCI's works great, the other one, works via ping average 50ms , but if you put some traffic on it my ping counts average in the 400's with spikes in the 1000's.

To rule out Routing, I have tried a Static route. I also have had Sprint remap the PVC and give me new DLCI numbers.

I am useing 12.2-10 IOS with the VPN set.

In this remote sight I do have an IPSEC backup, useing an INternet connection. It works fine. I am useing the "interface tunnel" to form a GRE tunnel to keep EIGRP talking. The Internet connection is on a second WIC, its Frame but not Sprint.

Even though I have the Internet there, I have kept NAT off for troubleshooting. At one point I only one access-list line in there which was for the VPN

"access-list 101 permit 192.168.63.0 0.0.0.255 192.168.0.0 0.0.255.255" Allowing my 63.0 to get to 1.0

Eigrp seems to do what it should, it wants to use the DLCI to location 1 which has the lower hop count, although this is the bad DLCI so I removed the subinterface config, putting it on DLCI 2 which works great, if I shut down that interface, EIGRP uses the Tunnel. If I bring the interface back up it goes back to frame.

Again, I don't think its routeing but I am at a loss and could use a second set of eyes if anybody has seen anything simular.

The main problem, is 1 DLCI just doesn't seem to have any real bandwidth on it. 512k port..... sprint's 0 CIR (yea I know) and no traffic shaping. Any ideas?

Sorry about the long post, but I am looking for something other than "Sprint issue"

rjackson · ‎05-02-2003

You can rule out routing just by pinging point to point across the interface. I assume you looked at Interface, PVC and LMI stats? Is there anything on either end indicating congestion or errors? Your sample doesn't show, are these subints point-to-point?

As an aside, our 170 sprint circuits with 0 cir each get better throughput than 400+ att circuits with 16k cir.

preston · ‎05-02-2003

Yea, they are Point to Point,

I can't check the PVC right now to see if there are errors. I need a window, although what would you be looking for, and what would the resolve be.

rjackson · ‎05-02-2003

On the lmi stats look for request timeouts or a discrepency between requests and replies. LMI is control commnication between the router and the F/R switch at that end of the circuit. Timeouts are often related to physical loop problems and might also show up on the interace stats as errors. However, LMI and interfaces errors would cause problems for both pvc if they are on the same local loop at the remote end. I cant remember if I asked about that.

PVC stats are more about the end to end condition inside the frame cloud. FECNS and BECNS indicate congestion in the path though the cloud. Also look for discards. You can check pvc anytime you can access the router without impacting the circuit. Just do a show frame pvc. That will show all of the pvcs that the f/r switch tells the router it knows about. sometimes you get surprised and see some that should not be there. Thats not usually an issue but..., you never know, it might help to clean up any unecessary stuff.

Also find out if Sprint did any end to end tests. Usually they just test from somewhere in the cloud to the end point where they think the problem is. An end to end test would more likely show up any congestion in their frame path.

preston · ‎05-05-2003

Sprint found the problem, their circuit was mapped incorrectly. One of the DLCI's was configured as a "shadow PVC" with a very low CIR inside sprints frame switch. I figured it was Sprint, but wanted to post to be sure I hadn't left anything out.

Bad thing about this problem is none of the troubleshooting stats applied on this.

Everything looked good, but if you put traffic on it a 512 frame looked like a dialup.

Hopefully this post saves somebody some leg work in the future.

Thanks for your help.