dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
1293
share rss forum feed

mjmcmahon67

join:2013-01-23
Meridian, ID

Odd slowdowns with C1841 and Actiontec Q1000 bridge

Hi all -

I was lucky enough to receive a Cisco 1841 and want to use it as my internet router in place of the Actiontec Q1000. I've got it to connect properly, but when I do I get very slow connections. DNS resolution seems to be slow (regardless of my defined DNS server) and I have issues getting some sites to load at all. When I reset the Actiontec and switch back to using it as the router, everything works as expected. The config for my Cisco is below:

 
Current configuration : 1817 bytes
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname netrouter
!
boot-start-marker
boot-end-marker
!
enable secret 5 *******************************
!
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
ip cef
!
!
ip dhcp excluded-address 192.168.100.0 192.168.100.115
ip dhcp excluded-address 192.168.100.150 192.168.100.254
!
ip dhcp pool LocalLan
   network 192.168.100.0 255.255.255.0
   default-router 192.168.100.1
   dns-server 205.171.3.25 205.171.2.25 4.2.2.1
   lease 7
!
!
ip domain name qwest.net
ip name-server 205.171.3.25
ip name-server 205.171.2.25
ip ips po max-events 100
ipv6 unicast-routing
no ftp-server write-enable
!
!
!
!
!
!
!
!
!
!
!
!
!
!
username Admin password 0 ********
!
!
!
!
!
!
interface FastEthernet0/0
 description External
 no ip address
 duplex auto
 speed auto
 pppoe enable
 pppoe-client dial-pool-number 1
!
interface FastEthernet0/1
 description internal
 ip address 192.168.100.5 255.255.255.0
 ip nat inside
 ip virtual-reassembly
 duplex auto
 speed auto
!
interface Dialer1
 ip address negotiated
 ip mtu 1492
 ip nat outside
 ip virtual-reassembly
 encapsulation ppp
 dialer pool 1
 ppp authentication chap pap callin
 ppp chap password 0 ********
 ppp pap sent-username mcmike1123@qwest.net password 0 *******
!
ip classless
ip route 0.0.0.0 0.0.0.0 Dialer1
!
no ip http server
no ip http secure-server
ip nat inside source list DSL_ACCESSLIST interface Dialer1 overload
!
ip access-list extended DSL_ACCESSLIST
 permit ip 192.168.100.0 0.0.0.255 any
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
 exec-timeout 0 0
 logging synchronous
line aux 0
line vty 0 4
 password *******
 login local
 transport input all
!
end
 

Any suggestions on revisions to my config would be greatly appreciated. I'd considered calling CenturyLink support but frankly expect that they'll simply dismiss it without making any suggestions.

cramer
Premium
join:2007-04-10
Raleigh, NC
kudos:8

1 recommendation

First, I'd recommend finding ANYTHING newer than the 12.3 IOS it's apparently running.

- The DHCP pool sets the router to 100.1, yet the router's IP is 100.5.
- You have ipv6 routing enabled, but no IPv6 configured anywhere.
- You should avoid using 192.168.100/24 internally -- that's typically a bridged cablemodem subnet. (confusing, but shouldn't break anything)


mjmcmahon67

join:2013-01-23
Meridian, ID

Cramer -

thanks for the reply.

It is on 12.3, but that's the way it came. I'd considering changing IOS but, to be honest, I'm still too new to Cisco-land to have a clear understanding of what IOS package I need. I'm further hindered by a 32M CF card - I'd looked at some newer packages but they required 64

The IP settings on the FA0/1 interface were temporary so that I could have the router on-line while still using the Actiontec as the router.

I enabled IPv6 routing just in case Centurylink's system was using it. I can easily turn it off

I'm not addicted to the 192.168.100.x subnet...I can easily switch it.

Any other ideas?



TomS_
Git-r-done
Premium,MVM
join:2002-07-19
London, UK
kudos:5

Whats the speed of the broadband, and what speed are you expecting to get through the Cisco?


mjmcmahon67

join:2013-01-23
Meridian, ID

Broadband is 12M down, 3M up

Not expecting anything speed-wise out of the Cisco I wouldn't get out of the Actiontec...it's more about some of the other functionality (Router on a stick, etc) and increasing my familiarity since I don't have a test environment to 'play' with at work.



TomS_
Git-r-done
Premium,MVM
join:2002-07-19
London, UK
kudos:5
reply to mjmcmahon67

The sites not loading bit sounds like MTU.

I see you already have lowered your MTU to 1492 on the Dialer interface, but Im wondering if perhaps you should also stick in an MSS adjust command too.

Add this to your Dialer int:

ip tcp adjust-mss 1452
 

I think thats it (doing this from rusty memory...)

As for slow resolution of DNS, you have 3 name servers listed, have you tested each one to ensure that they are returning speedy replies? Im assuming that you got these from your existing configuration/ISPs support page?

Googles DNS server is usually touted as being pretty quick, maybe try 8.8.8.8/8.8.4.4. But 4.2.2.1 which belongs to Level3 (IIRC) I think is also pretty well regarded for speed.

If you have a *nix box, the dig utility is a pretty good tool to test with (provided it is installed...) e.g.

dig @server soa domain.com
 

And just get a feel for how quickly servers are responding. If they are slow to respond, that might explain what you are seeing. If only one of them is slow, try taking it out of your DHCP config and/or try a different one.

mjmcmahon67

join:2013-01-23
Meridian, ID

Thanks Tom...I'm going to update IOS tonight and I'll try your suggestion and see where I wind up.


mjmcmahon67

join:2013-01-23
Meridian, ID

Tom you are a lifesaver! I took your suggestion and put the ip tcp adjust-mss value to 1452 into the config for dialer1 and I confirmed that was the fix. I'd tried a number of things simultaneously (big mistake, I know) but then tried REMOVING the adjust-mss value and immediately began experiencing the same issues. Once I put the value back, things returned to the normal speed.

If you wouldn't mind, can you help me understand WHY this made a difference? I've googled a little (and will continue to do so tonight), but can't figure out what the router was using for a Max Segment size BEFORE the adjustment so I can understand why my performance was so poor.

Thanks again!

Mike



TomS_
Git-r-done
Premium,MVM
join:2002-07-19
London, UK
kudos:5

Typical MTU on a network is 1500 bytes. With 40 bytes of IP and TCP headers, machines will therefore try to negotiate an MSS of 1460.

But with PPPoE there are an additional 8 bytes of overhead for PPPoE related transport, so your effective MTU drops, and you need to therefore negotiate a lower MSS.

That command causes the router to modify TCP SYN packets to cause a smaller payload size to be negotiated. Most likely they are going out with 1460, and the remote machine is trying to send back packets that are too big, and thus they are not getting through.

You would get the same effect by lowing the MTU on your PCs NIC to 1492, as that would force the PC to negotiate the correct MSS based on the MTU it knows it can use.

Setting the MTU on the Dialer interface will cause the router to fragment packets to make them fit on the way out, but if this doesn't happen on the way back in, then the responses will never reach you. Negotiating a lower MSS with the remote machine will ensure they get back to you.

If your machine has PMTU discovery then it should work out its useable MTU/MSS figures automatically by sending packets (progressively smaller each time) with the DF bit set, and waiting for ICMP fragmentation needed messages to be sent back. When it doesn't receive that message it knows what its useable MTU is.


cramer
Premium
join:2007-04-10
Raleigh, NC
kudos:8

PMTU only works when there isn't some a-hole paranoid admin between A and B dropping ICMP messages (and/or IP fragments.)

(Or a broken NAT is screwing it up.)


aryoba
Premium,MVM
join:2002-08-22
kudos:4

said by cramer:

PMTU only works when there isn't some a-hole paranoid admin between A and B dropping ICMP messages (and/or IP fragments.)

As a note, by default incoming traffic including ICMP is blocked by Cisco PIX Firewall and ASA however I have never seen or heard such firewall screws up PPPoE connectivity with default configuration (without creating holes to permit incoming ICMP). This behavior is most likely regulated by the fixup command on OS 6.x or default inspect command on OS 7.x and up which have been doing a good job

cramer
Premium
join:2007-04-10
Raleigh, NC
kudos:8

The PIX does pay attention to connections, so it will route ICMP messages appropriately when it has enough information. (It has to when it's doing NAT.)



TomS_
Git-r-done
Premium,MVM
join:2002-07-19
London, UK
kudos:5
reply to cramer

said by cramer:

when there isn't some a-hole paranoid admin between A and B dropping ICMP messages (and/or IP fragments.)

That too.