Re: FR traffic.

riju · ‎06-12-2005

Hi,

My company has got FR connection between H.O and its 4 B.O.

In H.O there is 2 FR routers. I one H.O FR router there 3 PVC and in another H.O FR router only one PVC is there.

The problem is that the connection is very slow between H.O and B.O thru FR.

FR connection is thru satellite.

From H.O speed is 1M upload and 128k download.

In B.O 1M best effort upload and 128k download.

I tested the connection speed with my provider by two ways.

First with no LAN interface connection at all side, only the WAN interface. The ping result is around 500 ms to 600 ms.

Next I tested with LAN interface connected (that is by all the LAN pc`s accessing the Internet and data’s, mails, Intranet web sites), the ping result is very bad, its around 2000 ms to 4000 ms.

In all my B.O there is only 10 to 15 pc`s connected to each of there LAN.

Also check for virus, there is no virus traffic at all.

And the MRTG graph of all the routers shows of normal traffic, which is very very very less.

The provider is saying that the traffic is very high, so that only the performance is bad.

Another information is that the PVC`s support only up to 1M data traffic in it and the H.O router interface support only 2M data traffic, so because of this the performance is bad.

The FR setup 7to8 years old and suddenly the traffic problem started now. Checked will the entire department for any new type of application running or not. Every body said, no body has added any new application or database.

How to check the PVC`s and interface maximum supported data traffic?

I have attached the tech-support details of all the router. Can some body tell what can be the problem?

riju · ‎06-13-2005

Hi,

I enabled traffic shaping now in R1 router, in which 3 PVC`s are there.

map-class frame-relay frshap

frame-relay traffic-rate 16000 170000

Below is the result of PVC 160(5 min difference):

in BECN pkts 129433????

R1#show traffic-shape

Access Target Byte Sustain Excess Interval Increment Adapt

I/F List Rate Limit bits/int bits/int (ms) (bytes) Active

Se0.1 16000 19500 16000 154000 125 250 BECN

Se0.2 16000 19500 16000 154000 125 250 BECN

Se0.3 56000 7875 56000 56000 125 875 BECN

Se0.4 56000 7875 56000 56000 125 875 BECN

Se0.5 16000 19500 16000 154000 125 250 BECN

R1#

R1#show frame-relay pvc 160

PVC Statistics for interface Serial0 (Frame Relay DTE)

DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1

input pkts 1262028 output pkts 1514883 in bytes 183658458

out bytes 1596373401 dropped pkts 12977 in FECN pkts 0

in BECN pkts 129433 out FECN pkts 0 out BECN pkts 0

in DE pkts 0 out DE pkts 0

out bcast pkts 8645 out bcast bytes 2507050

pvc create time 6d01h, last time pvc status changed 2d03h

cir 16000 bc 16000 be 154000 limit 19500 interval 125

mincir 8000 byte increment 250 BECN response yes

pkts 137846 bytes 114562123 pkts delayed 68052 bytes delayed 57048480

shaping active

Serial0.1 dlci 160 is first come first serve default queueing

Output queue 18/40, 2105 drop, 0 dequeued

R1#show traffic-shape statistics

Access Queue Packets Bytes Packets Bytes Shaping

I/F List Depth Delayed Delayed Active

Se0.1 148 137850 114568139 68054 57051488 yes

Se0.2 27 44190 34708956 18828 16100374 no

Se0.3 0 0 0 0 0 no

Se0.4 0 0 0 0 0 no

Se0.5 50 61935 48531609 24153 22614558 yes

R1#show frame-relay pvc 160

PVC Statistics for interface Serial0 (Frame Relay DTE)

DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1

input pkts 1262049 output pkts 1514904 in bytes 183659935

out bytes 1596391005 dropped pkts 12977 in FECN pkts 0

in BECN pkts 129433 out FECN pkts 0 out BECN pkts 0

in DE pkts 0 out DE pkts 0

out bcast pkts 8645 out bcast bytes 2507050

pvc create time 6d01h, last time pvc status changed 2d03h

cir 16000 bc 16000 be 154000 limit 19500 interval 125

mincir 8000 byte increment 250 BECN response yes

pkts 137876 bytes 114592083 pkts delayed 68067 bytes delayed 57063460

shaping active

Serial0.1 dlci 160 is first come first serve default queueing

Output queue 23/40, 2105 drop, 0 dequeued

R1#show traffic-shape statistics

Access Queue Packets Bytes Packets Bytes Shaping

I/F List Depth Delayed Delayed Active

Se0.1 154 137890 114599537 68074 57067187 yes

Se0.2 27 44195 34710444 18828 16100374 no

Se0.3 0 0 0 0 0 no

Se0.4 0 0 0 0 0 no

Se0.5 48 61997 48563405 24184 22630456 yes

R1#

sdoremus33 · ‎06-15-2005

Since there is a major latency on the LAN side, check MTU between the sites, it is possible that MTU sizes are incorrect and PMTU discovery protcol checks the link you are experiencing such a high latency

riju · ‎06-15-2005

Thankyou very much.

The problem was solved. Our provider screwed the settings in there side for our CIR and EIR seetings.

After a lot of R&D by both side, the problem was able to solve.

Actually the problem started by the 2 to 4 devices which got damaged around same time.

By troubleshooting and replacing the devices, the settings were also changed.

So when the new device were replaced, the FR connection got stable, but the traffic delay was very high.

After a detail checking of BECN and FECN and traffic shaping from my side and provider side, the problem was found and resolved.

Thankyou very much for the help.