Nice Little Problem

iproute

We have this issue at one of our remote sites. The remote site uses Qwest DSL for Internet connection. We currently have the following configuration:

[Qwest]

---

(N-O)[DSL Modem Appliance](N-I)

---

(N-O)[2600](N-I)

---

[LAN]

(N-O = NAT Outside, N-I = NAT Inside)

We're doing the double NAT here because when we authenticate via PPPoE on the 2600 (with the modem is bridge mode), users are unable to get to certain sites (such as microsoft.com, hotmail.com, usbank.com). We've yet to identify why that occurs.

However, the issue we're currently working on is that with the configuration diagrammed above, users on the [LAN] receive a reduced bandwidth (2.1-2.4Mbps). However, when I test from a client connected directly to the DSL modem appliance, the speed is 5-5.5Mbps.

We've also conducted the speed tests with the router doing NAT/PPPoE auth while the modem is in bridge mode with the same results.

Any ideas?

Netstudent

IS there a firewall between the modem and the router or anywhere in the mix? Looks like that router is causing a bottleneck. Do you have some kind of ADSL card in that router?

keenon

iproute wrote:

We have this issue at one of our remote sites. The remote site uses Qwest DSL for Internet connection. We currently have the following configuration:

[Qwest]

---

(N-O)[DSL Modem Appliance](N-I)

---

(N-O)[2600](N-I)

---

[LAN]

(N-O = NAT Outside, N-I = NAT Inside)

We're doing the double NAT here because when we authenticate via PPPoE on the 2600 (with the modem is bridge mode), users are unable to get to certain sites (such as microsoft.com, hotmail.com, usbank.com). We've yet to identify why that occurs.

However, the issue we're currently working on is that with the configuration diagrammed above, users on the [LAN] receive a reduced bandwidth (2.1-2.4Mbps). However, when I test from a client connected directly to the DSL modem appliance, the speed is 5-5.5Mbps.

We've also conducted the speed tests with the router doing NAT/PPPoE auth while the modem is in bridge mode with the same results.

Any ideas?

i ran into a similar issue that was due to incorrect mtu size. on dsl it should be 1492 and not 1500 due to the header needed for the pppoe

Netstudent

http://www.cisco.com/en/US/tech/tk175/tk15/technologies_tech_note09186a0080093bc7.shtml

here is a nice article that reinforces what Keenon said.

iproute

Thanks for the replies guys. I had the MTU set at 1492, but it may need further tweaking. I'll read through the document that you posted for any leads as to a possible solution. The issue described in the document seems to describe the problem experienced when we do PPPoE on the router exactly.

Thanks.

Netstudent

Also check that the clients have a deafult PPPoE MTU size of 1480? This is what PPPoE clients should default to. try checking the MTU on the clients and if isn't correct, then you may try editing the registry to modify the MTU. Also some ISP's require a MTU smaller than 1480 but not less than 1400 for PPPoE.

here is a document explainig how to use the ping with some flags to determine your ISP's MTU.
http://www.speedguide.net/read_articles.php?id=156


here is a good article on editing the registry to change the default MTU size for PPPoE.
It requires two new keys and 3 DWORD values. Pretty simple. Good luck tweaker
http://support.microsoft.com/default.aspx?scid=kb;en-us;283165

dtlokee

Netstudent wrote:

Also check that the clients have a deafult PPPoE MTU size of 1480? This is what PPPoE clients should default to. try checking the MTU on the clients and if isn't correct, then you may try editing the registry to modify the MTU. Also some ISP's require aN MTU smaller than 1480 but not less than 1400 for PPPoE. In that first article it explains that it doesn't matter what the MTU size is on the router because the client and the webserver will negotiate on an MTU.

here is a good article on editing the registry to change the default MTU size for PPPoE.
It requires two new keys and 3 DWORD values. Pretty simple. Good luck tweaker
http://support.microsoft.com/default.aspx?scid=kb;en-us;283165

I think this may be more the source of the problem because if the router needs to fragment the packet that it receives to send them onto the ADSL network it increases the latency and decreases the performance. If the MTU of the packets leaving the router going onto the PPPoE network, they would be dropped resulting in no connection, not slow connections. Try pinging from a client specifying the size of the payload, and use the option for "do not fragment" to see what the largest IP payload that is permitted.

Netstudent

yes

"In Dos Prompt(Command Prompt), type:
ping -f -l [packetsize] [www.yourisp.com] where [packetsize] is the amount of data you want to send ( between 0 and 1500 bytes ) and [www.yourisp.com] is your ISP's URL (you can also use your gateway, or any server your connection always passes through instead of your ISP's URL).

The largest value that does not give you the error "Packet needs to be fragmented, but DF set" will be your ISP's MTU - 28 (excluding the IP [20 bytes] and ICMP [8 bytes] headers). "

iproute

It's 1472. So that it means that the ISP's MTU is 1500, yes?

dtlokee

the 28 bytes would be the IP header and the ICMP header, you'd also need to allow for the 6 byte PPPoE header which is added to the data link header (LLC and MAC). After all that is added up the MTU on the wire is 1518 for Ethernet, so to find the Maximum Segment Size (at the transport layer) subtract that from 1518 and that's the MSS.

tech-airman

iproute wrote:

We have this issue at one of our remote sites. The remote site uses Qwest DSL for Internet connection. We currently have the following configuration:

[Qwest]

---

(N-O)[DSL Modem Appliance](N-I)

---

(N-O)[2600](N-I)

---

[LAN]

(N-O = NAT Outside, N-I = NAT Inside)

We're doing the double NAT here because when we authenticate via PPPoE on the 2600 (with the modem is bridge mode), users are unable to get to certain sites (such as microsoft.com, hotmail.com, usbank.com). We've yet to identify why that occurs.

However, the issue we're currently working on is that with the configuration diagrammed above, users on the [LAN] receive a reduced bandwidth (2.1-2.4Mbps). However, when I test from a client connected directly to the DSL modem appliance, the speed is 5-5.5Mbps.

We've also conducted the speed tests with the router doing NAT/PPPoE auth while the modem is in bridge mode with the same results.

Any ideas?

iproute,

What is the duplex setting for the N-I interface on the 2600 router?

iproute

tech-airman wrote:

iproute,

What is the duplex setting for the N-I interface on the 2600 router?

show run int fa0/0 (NAT Inside) shows:
speed 100
full-duplex

show int fa0/0 shows:
Full-duplex, 100Mb/s, 100BaseTX/FX


show run int fa0/1 (NAT Outside) shows:
duplex auto
speed auto

show int fa0/1 shows:
Full-duplex, 100Mb/s, 100BaseTX/FX

iproute

keenon wrote:

iproute wrote:

We have this issue at one of our remote sites. The remote site uses Qwest DSL for Internet connection. We currently have the following configuration:

[Qwest]

---

(N-O)[DSL Modem Appliance](N-I)

---

(N-O)[2600](N-I)

---

[LAN]

(N-O = NAT Outside, N-I = NAT Inside)

We're doing the double NAT here because when we authenticate via PPPoE on the 2600 (with the modem is bridge mode), users are unable to get to certain sites (such as microsoft.com, hotmail.com, usbank.com). We've yet to identify why that occurs.

However, the issue we're currently working on is that with the configuration diagrammed above, users on the [LAN] receive a reduced bandwidth (2.1-2.4Mbps). However, when I test from a client connected directly to the DSL modem appliance, the speed is 5-5.5Mbps.

We've also conducted the speed tests with the router doing NAT/PPPoE auth while the modem is in bridge mode with the same results.

Any ideas?

i ran into a similar issue that was due to incorrect mtu size. on dsl it should be 1492 and not 1500 due to the header needed for the pppoe

Upon forcing 1492 MTU size on a workstation, I saw much improvement in download speed (from 2Mbps to 5Mbps). In order to complete the testing process and start the resolution implementation process, I'll have to wait until tomorrow when the location clears out. I'll let you all know how it goes.