I didn't configure the router, but I was told to move router to another location and change WAN IP.
Changed and have it running, able to get out to net, but incredibly slow. Very, very slow.
I remove router and put in basic LinkSys router with same Static WAN IP and it's back up to normal 1.2MB/s downloads. With router it's at 60KB/s.
Can someone please take a look at the config and let me know if something could be causing major slowness? I'll worry about cleaning up the config later, right now I just need stability.
In a hurry, please help if possible.
Sorry about the format. Was really in a rush and didn't even think about it. I called it a night for now, after midnight. Gotta go back tomorrow, so hopefully can figure something out tonight.
I'm hoping the router isn't "bad". I try hooking up to the console point and get a constant stream of jibberish; no responses to key strokes, even after numerous reboots.
Console cable is fine. Can hook to a switch I have and config fine.
The issue with getting gibberish on the console is almost certainly a mismatch between the speed setting of your terminal emulator (probably set for the Cisco default of 9600) and the speed setting on the console port. And it is highly unlikely to be related to the performance problem. I would suggest that you systematically try various console speeds, starting from the lowest of 1200, and working your way up through 2400, 4800, up to the max of 115200. With some emulators like Hyperterm you will need to stop the connection and restart the connection to get the terminal emulator to recognize the speed change.
I believe that something else is responsible for the performance issue. I would agree with Steven that a duplex mismatch would be the first thing that I would look for.
If you believe that duplex settings are correct then it might help if you would post the output of show interface and the config from the router. This would help us to understand better what is going on and perhaps help us to find the source of the problem.
 after posting I see that you have already posted the router config. My first question is that if you are getting gibberish on the console how did you get this config and is there any possibility that there are differences between this and what is actually running?
And the posted config does in fact explain the gibberish on the console. In the config is this:
line con 0
I also notice that the outbound interface is Ethernet (not FastEthernet) and it is configured for duplex full. Since most Ethernet interfaces run half duplex, it really makes me wonder what you are connected to, and whether that device is really running full duplex.
As an experiment I would suggest removing the full duplex from the config of the Ethernet interface. Let it negotiate, and see if the performance improves.
Unfortunately we just switched in the other LinkSys home router to get the office up and running for now. It was well past midnight and we needed to get the Exchange up and running.
I have the router at home with me right now. I think the best bet for me now is to just rebuild the whole config. All those access rules and references to the old IP scheme (209.x.x.x) is now obsolete, so I guess it's best if I start from scratch.
I've just never setup VPN access on a router before, so it should be fun. I'll just go through the old config line by line and adjust or take out what is necessary.
If you guys could throw in any suggestions / comments based on the old running-config, I'd greatly appreciate any advice.
As for the console, I'll start the process of going through every console speed setting and hopefully get it working. If not, I'll try connecting to e0/1 and starting from there.
Edit: as for link/duplex, because I have the router at home now, I cannot verify this. Though I could only assume it would have been working correctly since the other consumer series LinkSys router is working fine? Would I be correct in this assumption?
There is no need to go through all the console speeds. As my edit, added a bit after my post, says the console is clearly set for 115200. Just set the emulator to that speed and you should be good to go.
I do not think that it is a good assumption about duplex settings. I doubt that the Linksys is forcing the interface to full duplex. My assumption would be that the linksys is probably operating at half duplex.
It may have been correct to force the interface to full duplex in its original location. But I would not assume that it was necessarily correct in the new location.
Ahh, didn't notice the edit. Sure enough. I hooked up to eth1/0 and changed the connection speed back to 9600 and everything works great! Can't believe I overlooked that.
Did a write erase and reload and have been reconfiguring from scratch. I noticed on the old config that eth1/0 was set to "half-duplex", though it was hooked up to a Cisco 2960...?
Could this have been the slowness issue? I should set this to "full-duplex", correct?
The console speed is an easy thing to overlook - and thank goodness an easy thing to fix. In my experience it is frequently a byproduct of someone who needed to do xmodem to restore an image to a router (xmodem is slow enough at 115200 and at the default of 9600 it is vvveeerrryyyyyy slow). When they finish the xmodem transfer they are so relieved that they sometimes forget to set the console speed back.
I would suggest caution about setting full duplex on Ethernet (not FastEthernet) interfaces. The chipset of many Ethernet interfaces does not support full duplex. Apparently the interfaces of your router do support it. And I would assume that the 2960 would support 10 Mb full duplex. So go ahead and set the interface to full duplex (it is probably necessary to set it to full duplex on both sides). I doubt that the interface would negotiate to full duplex on an Ethernet interface. So after you bring up the connection I would check both the router and the 2960 to make sure that duplex matches on both ends.
When there is a duplex mismatch (one side at full duplex and the other side at half duplex) performance is likely to be quite bad. Things will look just fine on the full duplex side and the interface will see no errors. But on the half duplex side there are likely to be many collisions, many late collisions, and probably a large number of runts. The half duplex side is dropping many frames because of the collisions and the retransmission of frames is what is impacting performance.
Thanks for all the input. Definitely helps. Whenever I bring the router back to the office to try it out, I'll make sure about the duplex settings.
Although, I'm connected locally now and "sh int eth 1/0" doesn't appear to be giving the duplex settings. What is the command to verify this?
I've been going through the old config line by line and have a question about this part:
crypto map mymap isakmp authorization list groupauthor
crypto map mymap client configuration address respond
crypto map mymap 10 ipsec-isakmp
set peer 188.8.131.52
set transform-set 3des_set
set pfs group2
match address 115
crypto map mymap 50 ipsec-isakmp dynamic dyn_map
The "! Incomplete" part is where I'm stuck. Are these statements trying to define a secure tunnel to the 66. address? If so, I'm fairly certain this is now obsolete. Just trying to figure out if it would be safe to remove.
show ip int br will give you a list of interfaces and settings speed/duplex
Also if you are running Gig-E there are two options 1000 Full or Auto-Negotiate I believe
set peer 184.108.40.206 /* Sets remote ipsec peer
set transform-set 3des_set /* Sets transform set to peer make sure both ends match
set pfs group2
match address 115 Matches ACL 115 usually for crypto traffic depending on your config
crypto map mymap 50 ipsec-isakmp dynamic dyn_map /* define crypto map for tunnel
A couple of observations about this:
crypto map mymap 10 ipsec-isakmp
set peer 220.127.116.11
yes it is setting up a secure connection to 18.104.22.168. If that is obsolete then it is fine to remove it.
I am a bit puzzled about it showing up as incomplete - especially considering that it did not show as incomplete in the original config that you posted. I would guess that you have not yet configured access list 115 which the crypto map references. A crypto map will show as incomplete until it has a valid definition of a peer and a valid access list to match against to identify traffic to be protected by IPSec.
Thanks for the replies about this crypto site-to-site tunnel. Yes, this need is obsolete, so I will be taking this section out.
I completely wiped the router and have been going through and trying to figure out what needs to stay and what needs to go. You are correct in that I did not create the ACL 115 yet. I was holding off on the ACL's till the very last thing so I could go through line-by-line to figure out what all I needed.
Thanks much for all the responses. I'm sure I'll stumble across a couple more questions. Till then, if you're looking at the config and could give any other pointers, I'd appreciate it.
I've managed to trim down quite a bit of the previous configuration.
These series of statements have me a bit stumped:
route-map nonat permit 10
match ip address 125
access-list 125 deny ip 10.0.20.0 0.0.0.255 10.0.10.0 0.0.0.255
access-list 125 deny ip 10.0.20.0 0.0.0.255 10.100.0.0 0.0.0.255
access-list 125 permit ip 10.0.20.0 0.0.0.255 any
ip nat inside source route-map nonat interface Ethernet0/0 overload
It sounds like it is saying to deny access from local IP's (10.0.20.x) to the VPN IP's (10.100.0.x) on the WAN interface. But only while NAT'ing? Confusion.
I agree that this concept of the nonat route map and the access list can be a bit confusing. The way that you verbalized it is actually fairly close to the real meaning.
First we need to clarify an aspect of access lists. We all first learned about access lists in terms of their ability to permit and deny certain traffic on an interface. And many of us tend to assume that is what they always do = permit and deny traffic on an interface. But access lists can actually do many things in addition to permit and deny traffic. In this case the access list is used to identify traffic that should go through address translation. If the access list permits the traffic then the traffic will be translated. And if the access list denies the traffic then the traffic will not be translated. The traffic still goes through the interface just fine, it is just not translated. So what the access list is really doing in this context is that it denies translation of traffic from your inside addresses to the VPN addresses. And it permits translation of other traffic.
If you are removing the VPN site to site then you probably can remove the nonat route map and access list 125 since you no longer need to deny those translations.