1. Home
  2. Cisco Systems
  3. Bandwidth issue

Bandwidth issue

OK, Got a weird one.

Broadwing MPLS between two sites each having full DS3 access into 3662 router each site. was installed in November.

Do not have any baselines to go by, but at first we did get a good copy of SANs data several times across the link and seems ran about 30-35 mbps throughput, this was before Christmas.

Sometime around the first of the year we had MTU issues on the broadwing MPLS net, they had replaced hardware and had an incorrect MTU setting. Since that was fixed seems that we get very low bandwidth, varies between 2mpbs and will jump sometimes to 10-13 mbps and back down to different rates in between. Not seeing any errors on the circuits. Broadwing has went over their network and routers at great lengths.

Is their anything I can look at on the routers to see if anything on our routers configured wrong or other errors, etc ?

I can post configs, just do not have access to the routers until morning.

As mentioned, seemed like was working, and not after the MTU fix and we keep blaming broadwing but need to be 100 percent not on our end, Although I can not find anything wrong. Also router CPU is 3-5 percent total on each at the most. no interface ACL's, just a few for routing redistribution but just a few.

I'll take any suggestions to look at anything.

Thanks,

MC

Reply to
MC
Loading thread data ...

This is quite tricky. Measuring link bandwidth is not always straightforward and it is very easy to get the wrong answers.

You want to check for fragmentation:-

Get a packet capture tool (say Ethereal or Wireshark, BTH I find that anything later than 0.10.14 on Windows crashes frequently). Use it to find out how to send max size ping packets without fragmentation. Windows "ping -l xxxx", xxxx ~=1472. Send some across link and use capture at both ends to see if there is fragmentation.

To do a pure bandwidth test use iperf in UDP mode OR more gently and with fewer problems use TCP but add enough iperf copies to saturate the link. You can tell when saturated since the rate of remaining copies of iperf reduces as new ones are added.

Reply to
Bod43

Thanks very much, I'll give that a try when get back to the office. MC

Reply to
MC

One more thing. You can use the sh int command to get an idea of the data rate but be aware that the 5min (x min) number takes data from more than 5 mins. The "5" refers to a constant in the mathematical technique used to compute the value. Search for [exponential weighted average time constant]. When offered a full scale step change of traffic level (say from 0 to 100%) the displayed number takes 20 minutes to stabilise completely.

int xxx load-interval 30

changes the "time constant" to 30 seconds.

Also you can use snmp (getif.exe) to graph the values.

Reply to
Bod43

I do believe the testing we did was flawed, not sure why I did not think about it more. We were trying to compare FTP and other file transfer rates. Forgot about TCP default window sizing on windoz servers and effect of RTT delays across high speed WANs (45mb DS3 in this case).

So we downloaded the iperf program and seems will work just as we need using the UDP protocol. Other program we used did have UDP capability but had it's own limitations and did not give accurate results.

We were seeing server performance hang around 3mbps end-to-end across the WAN, 45mb DS3 on each side of the MPLS, running about 35 ms latency. This falls right into what should be expected. most of our WAN circuit have been no more than 3mb in the past. The only thing we had running across the DS3 at first was between two cisco 9216i SAN switches for SAN replication to the remote site which throughput was great. of course now realize they are optimized for WAN performance. The windows servers apps were originally all on the same LAN as all the clients, however now started having clients on the remote side use the servers at our local side. We had other remote sites on lower speed WANs and expected the slower performance. But when we brought up the new remote site on the

45mb WAN we did not get any better performance as other remote sites and thought we started having an issue. We did have the MTU problem on the WAN provider network and thought was related.

We now have decied anything we have done is meaningless and data can not be trusted so we are starting from scratch to se if we really do have any problems on the WAN.

May be that we are just needing TCP tuning on the windoz applications or something.

Thanks much for the info on the iperf tool.

I'll post back next week after we run some more tests this weekend.

Reply to
MC

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.