Let me just jump in here, since I was on site.. On Sun, 31 Mar 2002, Craig Whitmore wrote:

A few things which may help (not in any order)

1) Look at Stats of Frame-Relay Connection (Any Errors??) (Geting Telecom to do BIR TEST)

Don't know - forgot the router's ip address, so I can't telnet in and check - sahil will though. (just do a show frame-relay pvc right?)

2) Are they getting what they are paying for? Are they getting CIR before before any errors occur? Remember the 384K is not promised, only 64K is promised, any extra bandwidth depends on ALOT of things.

Don't know - originally it was being traffic shapped at 384K - which I thought could give the same behavior (ie - the cisco over subscribes the bandwidth). After removing the traffic shaping - the pings were a little lower.

3) Define "Packet loss"? slow downloads?

Well - we've only heard from the asian guy (no offence, but kinda a little bad at english) that they get packet losses up to 45%, and when they get packet loss the whole internet is "slow", and people get the "cannot find server errors".

4) Check Settings on Routers on either end (Are both ends different hardware (Any compatibility issues between hardware))?

Nope - there is a cisco 2501 and a 2503.

5) Check Telecom has Circuit defined right.. Dunno - we should ask though.

6) Are routers running at high CPU? For example 2500's can't handle much bandwidth thru them without going Kaput and slowing things down

Umm.. both the routers were running at about 45ish% cpu usage. However, there was very little ram on the 2503 (4mb) - and it is handling about a meg of shaped traffic now - could that be it?

7) Check External Devices (ethernet convertor on 2500/Serial Cables/Ehternet)

The AUI trancivers seem fine.

8) On Frame Relay connections, you have not "over subscribed" the Access (ie trying to total of 2M CIR's over a 1M Circuit)?

Well - its possible with the traffic shaping rules we were using (ie - shaped to the PIR - when it is running a 25% CIR)

9) MTU set right on both ends?

Dunno - Sahil - check Thats just some info about what happenes - any more ideas? Thanks

Thanks Craig Whitmore Orcon Internet http://www.orcon.net.nz

--snip-- Best regards, Malcolm Lockyer -- owner/founder/managing director -= Nuron Net =- You're on the net! - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

On Sun, Mar 31, 2002 at 08:40:50PM +1200, Sahil Gupta - Net4U Limited wrote:

### He gets packet losses the moment they begin to download, he unfortunately pings "www.winz.co.nz" and "www.net4u.co.nz". While he pings www.net4u.co.nz he doesn't get any packet loss even while downloading, only thing when he jumps out of our network and onto the WWW he begins facing packet loss i.e. while pinging www.winz.co.nz

Check whether you can ping over the PVC with full MTU-sized packets as well as small ones. Try an "extended ping" on one of your ciscos and answer yes to "sweep range of sizes", and see if you notice a drop pattern for packets above a certain size. If you do, call Telecom and tell them to fix the PVC. If the PVC you have bought is implemented over an ATM network, and the ATM ingress queues are too shallow, you can start to get cells out of contract even before a single IP/FR/AAL5 frame has been sent. On such a network, the cell discard will mean that large packets are consistently dropped. Similar problems can occur with an interworking PVC where there is a big disparity in trunk sizes between the two ends of a PVC, and the fast end isn't rate-limiting. I saw something just like this the other day with an interworking PVC built between a customer's telecom frame relay trunk and an ATM-attached router at Xtra. Joe - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog