You can force the cisco device to connect at a slower/more stable connection. Go into config and type the following:
service internal
int atm 0
dsl noise-margin (a value between -3 and 3).

The service internal command exposes the dsl noise-margin command (and other hidden/non standard commands)
dsl noise-margin forces the router to training at a higher noise margin (sacrificing speed for stability). Setting this to 3 for example should see you get a higher noise margin, slower speed (and depending on fimware) a higher attenuation.
Start at 3 and work your way down to 0 in 0.5 steps until you get a stable connection. A value of 0 is the same as not having this command at all (eg: normal settings).
If you add a dsl noise-margin command, after a reload you'll see "WARNING: Unsupported Command. May cause violation to ADSL standards." on bootup, ignore it, it's just the addition of the noise-margin command.

Handy - Notes

To reset a Cisco router to factory default (removing the startup configuration file), perform these steps:

1.	To erase the configuration file, issue the erase nvram: command.

Reload the router by issuing the reload command. 2. If this does not solve the problem, attempt to break into ROM Monitor (ROMmon) by issuing the break sequence (usually Ctrl and break from the Hyperterminal) from a console connection.

Refer to:

Cisco Standard Break Key Combinations

You should see this ROMmon prompt:

rommon 1>

3. Change the configure register value to ignore the startup configuration by issuing the confreg command, as shown in this example:

rommon 2> confreg 0x2142

4. To reload the router, issue the reset command, as shown in this example:

rommon 3> reset

5. After the router boots, issue the enable command at the Router > prompt.

The prompt changes to Router#, indicating that the router is now in privileged mode.

6. To enter config mode, issue the config terminal command.

You should now see a Router(config)# prompt.

7. To change the configure register to recognize the startup configuration, issue the config-register command, as shown in this example:

Router (config)# config-register 0x2102

To break out of configuration mode, press Cntl and Z.

To save the blank configuration, issue the copy-running config-startup config command.

notes

Step 1. Verify that the Date, Time, and Time Zone Values are Accurate

ASDM Procedure

1. Click Configuration, and then click Device Setup.

2. Expand System Time, and choose Clock.

3. Verify that the information listed is accurate.

   The values for Date, Time, and Time Zone must be accurate in order for proper certificate validation to occur.

   

Command Line Example

ciscoasa
ciscoasa#show clock 11:02:20.244 UTC Thu Jul 19 2007 ciscoasa#

Step 2. Generate a Certificate Signing Request

A certificate signing request (CSR) is required in order for the 3rd party CA to issue an identity certificate. The CSR contains your ASA's distinguished name (DN) string along with the ASA's generated public key. The ASA uses the generated private key to digitally sign the CSR.

ASDM Procedure

1. Click Configuration, and then click Device Management.

2. Expand Certificate Management, and choose Identity Certificates.

3. Click Add.

   

4. Click the Add a new identity certificate radio button.

5. For the Key Pair, click New.

   

6. Click the Enter new key pair name radio button. You should distinctly identify the key pair name for recognition purposes.

7. Click Generate Now.

   The key pair should now be created.

8. To define the Certificate Subject DN, click Select, and configure the attributes listed in this table:

   Table 4.1: DN Attributes

   Attribute	Description
   CN	FQDN (Full Qualified Domain Name) that will be used for connections to your firewall. EX: webvpn.cisco.com
   OU	Department Name
   O	Company Name (Avoid using Special Characters)
   C	Country Code (2 Letter Code without Punctuation)
   St	State (Must be spelled out completrly EX: North Carolina)
   L	City

   In order to configure these values, choose a value from the Attribute drop-down list, enter the value, and click Add.

   

   Note: Some 3rd party vendors require particular attributes to be included before an identity certificate is issued. If you are unsure of the required attributes, check with your vendor for details.

9. Once the appropriate values are added, click OK.

   The Add Identity Certificate dialog box appears with the Certificate Subject DN field populated.

10. Click Advanced.

    

11. In the FQDN field, enter the FQDN that will be used to access the device from the internet.

    This value should be same FQDN you used for the Common Name (CN).

12. Click OK, and then click Add Certificate.

    You are prompted to save the CSR to a file on your local machine.

    

13. Click Browse, choose a location in which to save the CSR, and save the file with the .txt extension.

    Note: When you save the file with a .txt extension, you can open the file with a text editor (such as Notepad) and view the PKCS#10 request.

14. Submit the saved CSR to your 3rd party vendor. Once you submit the CSR to your 3rd party vendor, they will provide you the identity certificate to be installed on the ASA.

Works well - GoDaddy / Starfield 5 year cert for $130

A lot of people use the Cisco IOS rate-limit feature. They have a real need. What they don't have is real documentation. Cisco itself hasn't produced a decent explanation of how rate-limit works. Yeah, there are some books that pretend to explain what the 'normal burst' and 'extended burst' settings do. But they STILL don't tell you how to figure them out in real life.

I'm going to tell you. And after I tell you, you're going to feel better. The network will be faster.

Why the burst settings matter?

A normal router interface is limited by the inherent speed of the wire. When incoming packets arrive faster than they can head out the interface, they are placed in the outgoing packet queue. Each interface has one, typically 40 packets in size. As packet flow reaches and surpasses the wire speed, this queue begins filling up. Those packets belong to someone -- a particular TCP connection. (We are ignoring other packet types, but that is okay.) When those packets end up in the queue, they are being delayed. This would be similar to ping times starting to rise. The TCP protocol notices this delay (because the receiving computer will take slightly longer to send back an ACKnowledgement packet), and the flow slows slightly. If too many packets fill the queue, they start dropping. When TCP sees dropped packets, it slows more significantly. This is how TCP works, and it works well.

What happens when you rate-limit instead of letting an interface reach line-speed?

When you rate-limit, the outgoing packet queue never comes in to play. When the rate-limit sees a flow exceeding the limit, it simply drops a packet. There is no outgoing queue to slow the packet momentarily. This is why there are two settings: the normal burst size, and the extended burst size. The size of the burst is essentially telling the router how tightly you want to apply the rate-limit. Too loose, and flows may momentarily exceed the limit by an undesirable amount. (What constitutes undesirable is completely up to you; some folks are using rate-limit to sell bandwidth, and others are using it to keep a line from ever reaching saturation and hence keep latency down.) When the extended burst is exceeded, ALL packets are dropped until the flow comes back under the limit. That will happen from time to time, but it is bad for consistent performance. The normal burst drop can occur many times as the flow oscillates around the rate-limit. The smaller the normal burst is, the more drops it can accomplish, which is good in moderation, bad when overdone. A good rate-limit can actually improve performance under heavy load versus no rate-limit. But a bad rate-limit screws up everything.

Too tight

Usually, the burst settings end up too tight. When they are set too tight, three things may happen: 1) The combined traffic flows will have trouble reaching the limit. 2) TCP flows will be jerky, resulting in un-smooth web page loading or wildly fluctuating download speeds. 3) A single TCP flow (ie a speed test) will NEVER get close to the limit. (Insufficient TCP Window size on server or client can also cause this)

Burst settings end up set too low because people are concerned that setting them higher is going to cause the rate-limit to be too loose. This isn't true; for every byte sent above the rate-limit, a byte must not be sent (or worse, dropped!) below the rate-limit. So don't be too tight with burst!

Just right

Cisco IOS reference manuals (certain editions, at least) say that normal burst should be (RATE-SPEED/8 * 1.5), and that extended burst should be double the normal burst. These suggested settings are great for smooth TCP, but they are sometimes too loose.

I'm a tightwad; what's the lowest burst I should use?

There is one more variable you should know in order to figure this out: The typical or highest-typical ping time. If you are in the US, accessing primarily US sites, a ping-time of 150ms is probably a safe tight-wad number.

So here is your formula for normal burst: (RATE-SPEED/8 / 20)

The formula for extended burst: NormalBurst + (RATE-SPEED/8 * 0.150)

Using an example of 20Mbps, your rate limit would be:

rate-limit out 20000000 125000 500000 conform-action transmit exceed-action drop

Cisco says extended burst should be double the normal burst, but that assumes you are also using their formula for normal burst. I don't assume that you are, which is why I specify extended burst as an amount that should be added to normal burst. In this way, you can use very small normal burst values, and still know what your extended burst should be in order to ensure smooth TCP performance.

Why is that the lowest?

150ms is your round-trip time (RTT). That is how long it takes a packet to be sent, and the acknowledgement to be received. Once a flow reaches this speed, and exceeds for a burst of the size/duration for one twentieth of a second, a packet will be dropped. The extended burst is the normal burst, plus the total bytes that can be transferred in the RTT. That is how long it takes TCP to notice that a packet was dropped and was never acknowledged. So, when you set the parameters thus, you are giving TCP enough time to "take the hint" of a single dropped packet before it gets the major punishment of all packets being dropped.

If you don't like these burst settings, and they are causing the flow to exceed the rate-limit too much or too often, I would suggest that it is NOT the burst sizes that you want to reduce, but the rate-limit speed itself. Knock it down a percent or two and see if that helps you out.

Oh, so you want to push the envelope, and want to have even lower settings? Well, in that case, you could use 24000 for the normal, and 399000 for the extended. The important thing is that you've still got one RTT between the first packet drop and the complete packet drop. You may not get full speed at this level, but it will be smooth. The potential harm is that with only a 24000 burst, the router is looking too closely at the flow. In our 20Mbps example, 24000 bytes is only one-hundredth of the per second speed of the flow. When you measure the flow this tightly, the rate limit will end up being applied too often, when the overall speed is actually not in excess of the rate-limit. For instance, a web browser that suddenly opens a bunch of connections as a page is loaded could (although statistically unlikely) cause a 24,000 byte burst as that handful of connections are opened and their first 2 or 3 packets are sent without waiting for acknowledgement. Use your judgment. If your judgment sucks, use bigger numbers for the burst, and smaller numbers for the speed.

An exception: These rules don't apply on high speed links with hundreds of TCP (or other) connections. If the router starts to drop all packets, the randomness works in your favor. It is likely that every packet dropped is part of a different TCP connection than every other packet dropped. No single download through this link should expect to use more than 2% of the link capacity in order for this to apply. In this case, the extended burst value can approach the normal burst value without impeding TCP performance.

 

Good explanation - Notes

Bandwidth Throttling / Policing on Cisco ASA

August 17th, 2009 David Leave a comment Go to comments

If If you are looking to control the amount of bandwidth for a particular host using a Cisco ASA Security Appliance, you’ve come to the right place.  When I was first asked to look into this capability on the ASA I knew that I could perform some sort of Quality of Service (QOS).  In fact, all of the documentation that I came across either on Cisco’s website or from third party integrators have detailed information on controlling quality for VoIP, traffic shaping, and how to do those things across a VPN tunnel.  While the information on these great features of the ASA is helpful, finding articles on limiting bandwidth to a particular IP address was more difficult to track down.  In fact, it took a TAC case and several hours of reading papers on the above services until I was able to figure out how to police bandwidth using my ASA.  In the example below I am throttling bandwidth to 1Mb for the host 1.1.1.1:

For the sake of simplicity, I will show you how to limit inbound and outbound bandwidth for one host.  In order to do this for multiple hosts you simply replicate the steps making a few changes to access-list names, class-maps, and policy-maps.

The first step is to create the access list that define “interesting traffic” or what IP you want to control.

access-list throttle_me extended permit ip host 1.1.1.1 any
access-list throttle_me extended permit ip any host 1.1.1.1

The second step is to define the class-map.

class-map throttle-me
match access-list throttle_me

Now you need to define your policy-map and call the class-map.

policy-map throttle-policy
class throttle-me
police output 1000000 2000
police input 1000000 2000

The final step is to apply the new service-policy to the PHYSICAL interface where the traffic will flow.  You CANNOT apply this to a sub-interface.

service-policy throttle-policy interface outside

In summary, this configuration was applied to the outside interface of my ASA.  This is the “choke point” for traffic and can be considered the edge of my network.  As stated above, you must apply the policy to a physical interface on your ASA.  The IP address 1.1.1.1 represents a public address that is statically mapped to a private address behind a sub-interface on my ASA.  The method above combines a little bit of each QOS function from the ASA to get what I want it to do.

Using this on a WSUS server, works great.

.

Install VPN Client 5.0.4.0300

Install the Citrix DNE update (google)

Take ownership of c:\windows\system32\drivers\ndis.sys

Delete ndis.sys

reboot; the system will try to fix itself, leave all defaults

reboot again and login

restart the cisco vpn client service

connect as usual

Simple and works great!