**Highly Technical Question** Network Bandwidth and CIR usage problems **Highly Technical Question**

[Santa]

The company I work for right now has recently added a pipeline to another company where they are sectioning off bandwidth and data access because our company is splitting and eventually the half that is using the newly sectioned off data connection will be off the network.

The Problem:
Since we added the pipeline to their company we have had intermittent problems with certain apps that require a continious connection to the internet or other internet based servers.

Example: FTP connections upload and download will cause a queue of multiple to fail after a large file ~1-2+ MB file will upload but then the queue will stop after the file has finished uploading as if it is waiting for aknowledgment for continueing on to the next files. Using bullet proof I the program is able to reconnect to the site and reupload the file but this is unexceptable. I belieave that the FTP connection information packet is being dropped during the upload but the upload connection stays open but when the upload ends and the FTP program goes to look for the connection pipe it is no longer there.

Example: AOL Instant Messanger will lose its connection and reconnect to the AOL's server ever 5 mins or less. This I also think is because we are either dropping packets too much for a stable connection within tolerble limits of the program.

Solution: We have been told that it may be up to 1-2 months where we have to have this company on our connection with their company data being pushed through our lines. We asked our T-1 provider if upping the CIR rate would help the matter but they said that it wouldn't I would image if it is bandwidth related that upping the CIR would help it out but I am not an expert on the matter.

Does anyone know why this would matter or any good documentation that I could read to tell me about the limitations of data connections and their thresh-holds?

I appreciate any help anyone out there in the feild can provide.

 

[Xanathar]

Those are common problems with using to many computers on a single IP nat overload with not enough memory in the router... CHECK your NAT and firewall settings.

Check the link bandwith see how it is with respect to your CIR (assume frame relay) then either you or your ISP look for FECN and BECN flags (congestion) which mean that the problem isnt even CIR, but overloaded links and equipment further up the line.

Odds are the new company is now using your connect for their internet access, so your link to the internet should now be larger then the link combining the two locations or else you will have issues.

Work closly with your provider, and whoever is competent with routers and how they truly work. You may need/want to spend the money on a consultant for a day It may save his/her cost +++ on frustration and link optimization.

 

[Santa]

Thanks for the reply Xanathar

1st off they are not using the link to their company for Internet but for a cobol based application that connects to a mainframe I do belieave. What or how could I determine if the router is overloaded and or the congestion is on my end? Is there software or techniques that I can use to tell where the congestion lies?

Network diagram for our company is kinda stupid but this is how it is setup at the moment (will quickly change as we are being sold also and changing our network settings)

We are an outside remote office with a T-1 connection but our Internet pipes down to another state for a Proxy server and the rest of the internet access. We are protected by their Checkpoint firewall persay.

What is FECN and BECN flags? are they congestion/dropped packet markers? I will post what types of routers we currently hav e but if my memory serves me correctly we have the Cisco 7000 series.

How do we relieve overloaded links besides kicking those parasitic fools off our line?

Perhaps the best way for me to look at this problem is to work with the Phone company but from what they explained to my other collegue is that we have overextended ourselves whatever that means. We asked if upping our CIR would improve the problem and they said no. I don't know if he knew to ask the questions about where the congestion was.

Besides routers and so called "links" are there any other physical or network places that could be conjested I should look? I would assume from the smaller sized company that a T-1 would be sufficient but apparently it was not. Before we added the pipeline to their place we never had a problem. Now we are plagued with unstable connection and its starting to hurt the business.

Oh yea P.S. we don't run a firewall or a NAT on site it actually is filtered through a proxy/firewall down in our current main office in another state.

 

[Damaged]

<< What is FECN and BECN flags? are they congestion/dropped packet markers? >>



Yup.

You can read more here: Frame Relay Forum

 

[Xanathar]

Yes, but the way routing works is the new company.link may still be using your link to the main office, and their nat system unless you have explicitly firewalled or not routed their connection onward.

 

[barebottoms]

Sorry, but NO router in the Industry obey's FECN's and BECN's.
I think we need to figure out how you're load balancing here.

The time out might be in the method you choose. Even HSRP can loose sessions in the time it takes for the hot swap router to come up.

Check you interfaces for DROPs and frag counts. Compare the WAN interface to your internal interface.

Check your WAN link for FRAME slips. Frame slips and clock drifts can cause all kinds of havoc on session based applications.

If this is an Frame Relay Link, do an LMI dump, capture about 1 minutes (good for 2 full status updates) of Frame Frames.

 

[Xanathar]

Will they router Obey the flags, NO, will it receive the flags, YES. Are they good things to look for to let you know if the problem is the cloud or your link, YES. Carrier networks use the same bandwith schemes everyone else does and They overload their links just as bad. Those flags give you the ability to call them and blame your performance on their hardware.

But back to the original problem If you dont know how to check the load on the router, on the links, and see how traffic is traversing your network you really need to find.hire someone who does. Watch and learn form him.her but fumbling your way throu performance troubleshooting is the worst way to learn

 

[barebottoms]

Opps.. sorry, didn't mean to sound like that. I meant basically what Xanathar said. The router wouldn't do anything with the FLAGs so if you see high counts of them, tell your provider. I didn't mean. That its was the wrong thing to look at. Sorry Xanathar.

But I still like to know how you're accomplishing to load balancing. That would shed some light to the problem as well.

 

[Santa]

Well perhaps one of the problems that I might know is that we don't load balance to the best of my knowledge. We were never meant to be as busy as we are I guess or upper managment with the purse string decided (like always) this was not necessary.

I will go check tommorow on the link lights and perhaps consider a consultant also. I would rather try to figure it out myself because according to past experience with asking for things such as external help has always been rejected because of cost tight wads hehe..

I will also walk through or try to identify where the flags appear and see if it is the cloud or my link ..

appreciate the input xanathar, damaged, and barebottoms.. I will post back when I get some more info..

Also thanks for the links Damaged

 

[Damaged]

If the connection is terminated to a Cisco router then these links will probably help out as well:

Frame Relay

Troubleshooting Frame Relay

Troubleshooting Frame Relay (with pretty pictures)

Here's a fairly simple one: any idea how far you've extended the DEMARC? If it's over 50'and it's NOT STP (Shielded Twisted Pair) I've seen some pretty funky things happen. Actually I've never seen anything bad happen at that distance, but I had a hell of time convincing a customer that his 350' run of CAT 5 (UTP, Unshielded Twisted Pair) just might be the problem. After much arguing, since I could rule EVERYTHING else out...finally, lo and he behold he runs STP and all is well. Still a pretty long extension though.

As I recall Cisco's official stance on extending the DEMARC is along the lines of 35'.

barebottoms is right on with what you need to examine for possible causes.