|
Home > Archive > CCNP > December 2001 > slow data on serial
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
slow data on serial
|
|
| peterd 2001-11-27, 9:39 am |
| Hi Everyone,
the problem: the other guys in IT using VNC to connect to remote users, but it's running very slowly.
It's a new link, new NTU's but using old 2503's that worked OK before. Only using one port, serial 0 at each end. Not much traffic, loading around 30/255, no increasing errors, drops, etc.
the carrier tested the line and says it's OK.
I think the problem is on the ethernet at the far end, an old 'exisiting' network that we inherited and connected to our WAN last week.
I've been doing some extended ping testing, sending 500 packets of 1500, etc, and timing with a stopwatch. It seems OK to me, comparable in time to another fully working circuit.
But here's something that I'm not sure of:
in the serial port troubleshooting guide it says to place the local CSU/DSU in local loop and do the extended ping test, then look for drops, etc. Then do the same again with the distant end in remote-loop.
So I tried the local end, and I can't ping the far address. Ah yes, I thought, obviously EIGRP drops the address from the routing table within a couple of seconds, so I set up a static route pointing out of the serial port but it still fails.
Am I missing something here? I have a feeling that I've done this test ages ago and it worked, or am I mistaken?
Has anyone managed to loop the CSU/DSU and send pings around that loop?
Regards
Peter | |
| Yankee 2001-11-28, 4:28 am |
| In the UK, BT provides your NTU so you don't have access to it. In the US we provide our CSU/DSU so we can get in it and loop it. I'm not sure what's on the other side of the NTU in the UK, but you may be able to put up a hard loop on the T1 cable (towards you) and run the ping test.
I know a little bit about UK circuits, but unfortunately not enough 
Yankee | |
|
| Peter,
I might be confusing things here, but if you have looped it back to yourself then the ping would never be getting to the interface and therefore you wouldn't get a reply??
I would have thought that by looping the NTU you would probably get line up protocol down - but this isn't proving your ethernet.
You say you used the kit before and that it worked OK - is the bandwidth adequate?? You mention load is only 30/255 - is the bandwidth set to the right amount, this may be misleading you??
My number one motto recently is never trust BT, they cost me days two weeks ago! Have you a Bert tester you can put on the line and test it yourself??
Off topic slightly (well completely), there was a presales post going in Scunthorpe advertised in the Yorkshire Post last week, unfortunately can't remember who with!! If you were interested I'm pretty sure Scunthorpe doesn't have that many resellers!! | |
| peterd 2001-11-28, 8:40 am |
| hi Guys,
Yankee: I thought the NTU on our premises was the CSU/DSU? Maybe it isn't and that's why it doesn't work...
MatP:looping the NTU gives 'Up' & 'looped' on the show interface. I recall doing extended ping testing some time ago and I think I looped the NTU bit I can't remember if it actually worked or not.
I've double and treble checked the set-up (as it's a new circuit that we've only just started using) so I'm sure that it's OK there. Having worked for BT for 23 years I have to agree with you...
As for resellers in Scunny, I didn't think we had any! What does PreSales do please? I've been a maintenace man for 29 years, I don't think I could sell anything, but if it was involving surveys, checking out what's there alrady...
I'd be interested in finding out who it was with, probably worth punting my CV over there.
Regards
Peter | |
|
| Up and looped is a new one on me - glad I asked it.
Pre sales at my company means working with a salesman rather than as a salesman. The salesman does the relationship building etc and you as the engineer determine what technical requirements the customer has and design a solution which gives it (hopefully). Recently though all our datasalesmen left so it's all up to the engineers!!
If I remember right they wanted CCNP/DP, and your almost all the way there. I first saw them in the paper, but also found them on Jobserve doing a search for "Cisco and Yorkshire", if your lucky it'll still be there - I'll have a look for the paper tonight and PM you if I find anything. | |
| peterd 2001-11-29, 2:40 am |
| Hi MatP,
sounds good though I'm not up to that standard yet, CIT, CCDA and CID in the way! I looked on the YP site yesterday, found the jobs section but the search failed with a '505' several times so I gave it up until today.
There's nothing listed in the local jobcentre but I'll find it eventually...
Regards
Peter | |
| Yankee 2001-11-29, 4:10 am |
| The NTU is your equivalent of our CSU/DSU. The difference is that we own ours and have management access so we can get into ours and loop it. When I'm working a UK site, I don't have that ability and have to rely on BT to troubleshoot.
The ping test when we loop the CSU tests most of the CSU and our V.35 cable (think you use an X21 or something) only, so there is not a great deal of value in the test.
Is this a frame circuit or point to point? Because there maybe other things you can check if it is frame-relay.
Yankee | |
| peterd 2001-11-29, 5:58 am |
| Hi Yankee,
I've been researching and playing around with a spare NTU that I have (BT *never* recover these things when they disconnect a circuit!). There's a simple user menu and a 'toggle' button to select the loopback options then you press a 'prog' button to activate a local or remote loopback.
According to: http://www.cisco.com/warp/public/471/hard_loopback.html
we place the NTU into local loop and ping 'the local serial port IP address'...I was pinging the distant end address and this is why it failed the other day.
What I was looking at doing was to send an extended ping of several hundred packets across a known good circuit and time it, then do the same with the suspect circuit.
Unfortunately I don't have access to *any* test gear so it's poke'n'hope time.
Anyway, with not having access to this test yesterday I was poking around with different tests, decided to start at the distant router pinging into the distand LAN and that's where the problem is.
For some reason it's only replying to around 50% of the pings and those it does respond to it's running very slowly...around 400ms.
As this is an old existing LAN with one hub and half a dozen PC's that's never had any kind of external access before, we may need to re-work the design a little to get it working.
Unfortuantely it's 250 miles away, which isn't much to you guys in the US but to us it's like the far end of the universe! :-)
I've sent a spare router down there on one of our own delivery trucks, given simple written instructions on how to swap it over in place of the other router and we'll take it from there.
Obviously if that doesn't cure the problem then it's a long ride out to look for something dodgy on the distant WAN.
It's a nice change for me to actually have *real* work to do!
Thanks for your help
Peter | |
| Yankee 2001-11-30, 4:10 am |
| Wow thanks for the info, you may have added a little more troubleshooting I can do for our UK circuits that I didn't know was an option!
Can you telnet to the remote router and look at its ethernet interface? Guess you probably don't have access to it or you already would have looked, but I bet you would have a pretty good idea what was wrong if you could see.
Thanks for the info on NTUs!
Yankee | |
| peterd 2001-11-30, 5:33 am |
| Hi Yankee,
glad I could help.
Actually we can telnet to the distant router without problems. It's just running slowly when the PC Support guys try to run a VNC Session...um, if you've not seen VNC before it's a free utility that lets you take control of a PC's Desktop and (in effect) you're sitting at their keyboard.
Works great on every site except this one!
So the PC Support guys said they'd checked out the distant LAN and it was all ok. I didn't believe it could be a router/line problem but I started at our local end to prove the fault.
That's when I started having problems as shown in earlier messages. When I couldn't do what I'd planned I started again from the distant end.
From the far router, pinging the PDC on that site fails around 50% of the time, every time.
As it turned out, it's probably a packet corruption problem (it's failing CRC) on the distant LAN. I was wondering if they might have a PC (or two) that are 'over-distance', ie, more than 100 yards away from the hub?
I just 'knew' it wasn't a router/line problem from the first time it was passed to me!
Anyway, the boss may, or may not, allow one of us to take a trip down there next week to sort it out. I'd like to run a packet capture there but he may send one of the PC support guys instead of me...we'll see.
Regards
Peter | |
|
| Peter,
It's still possible that the link is over used. Howabout taking the LAN out of the equation by shutting down the ethernet port one lunch or evening then trying the ping.
This way you'll know if the LAN is causing it or not.
Hope that helps,
Mat P. | |
| peterd 2001-11-30, 7:22 am |
| Hi Mat,
I don't think that's the problem. It's a new link, they have very little data over here
(it's still all on their own server) and we have nothing much down there that we need to access.
For now the main use of this line is to send e-mail batches around every half-hour or so between the two servers. I've not seen it using more than around 30/255 load yet.
As I have a loopback address, for emergency use in case the distant ethernet goes down, on most of my routers (and especially the new ones to unknown LANs), I could easily shut down the ethernet and still connect to the loopback, but again I can see the problem when telnetted into the distant router and pinging a PC (in fact the PDC) on the distant LAN.
From that point there's effectively no line or NTU's involved in the ping, it's router, Ethernet0, to PC and back again.
Or am I missing something silly? :-)
Regards
Peter | |
|
| quote:
Originally posted by peterd
Or am I missing something silly? :-)
I don't think so, youve covered all bases, telnetted into the remote router and pinged devices on the remote LAN, taking everything prior to that out of the equation.
As you said earlier it needs a sniffer on the network.
Out of interest is the loopback in the same subnet as the ethernet port?? It's not something i've ever done as you could still telnet to the WAN port. Or could it be for routing??
And just to be nosey what company is it you work for and how big are they?? | |
| peterd 2001-11-30, 10:39 am |
| Hi Mat,
taking your point from the earlier message, I telnetted into the loopback address and shutdown the ethernet, then pinged sucessfully from my local end to the loopback address, no problems.
Reading up on Cisco's site, searching on 'LAN CRC error' I found loads of stuff...it seems that increasing CRCs without increasing collisions is usually due to a noisy connection, bad cable, etc or possibly down to a faulty NIC (but I get the problem to various PC's so I reckon it's cabling or the Hub).
Actually, I wasn't sure that you could telnet into the wan address, when I tried it some time ago it didn't work. That's why I set up a loopback interface with a separate ip address, as you know they never go down.
I found out some time ago that if the ethernet interface goes down, like someone pulls the patchlead out, then I couldn't telnet into that router to check it out.
I'll have another go at connecting to the wan IP address later and see how it goes.
The distant LAN is 172.22.0.0, ethernet interface is 172.22.0.254 and the loopback interface is 172.21.0.254, all with standard subnet masks.
The company is Premier Fresh Foods, we cover about ten sites currently having sold some and gained some due to take-overs, mergers, etc. The four factories kill around 3,000,000 chickens a week on full production and we're probably the second or third biggest producer out of six (I think) in the UK.
Most of our sites are fairly small, one router, one hub and a dozen PC's, but our site has a couple of hundred PC's and two others have 50+.
There's just enough work for one Network Engineer which means I get to decide what I do and when. The four PC support guys don't touch my work and I don't touch thiers. The down-side is that I've no-one else to talk 'Cisco' with so I don't get to pick up any interesting bits and pieces of information.
So that's whay I'm in the Forum!
Regards
Peter | |
|
| Let us know when you finally resolve it.
That's a lot of chickens!! | |
| Yankee 2001-12-03, 4:41 am |
| If you are seeing CRCs and frame errors on the routers ethernet, the most likely cause is a duplex mismatch where the other end is set to full and your router is at half-duplex.
let us know!
Yankee | |
| peterd 2001-12-05, 3:17 am |
| Hi guys,
I've had a couple of days off after the weekend...car repairs to do...cutting a long story short, night-time, out in the country, doing 70 mph with a truck going in the opposite direction at around the same speed...
his slipstream hit my car with enough force to pop the bonnet up, which wrapped itself around the windscreen of my car, and for at least a second I carried on not realising that I couldn't see where I was going...
I stopped eventually...
Anyway, last Friday I left an E-mail for the boss explainig what I thought was wrong and expected to be sent down there when I got back to work this morning. He's already sent two of the other guys last night so it's their problem now! :-)
They may tell me what they find...
Regards
Peter |
|
|
|
|