Re: PPPOE, MTU, and boom.
On Wed, 18 Jul 2001, Chris Wedgwood wrote:
On Wed, Jul 18, 2001 at 07:57:23AM +0100, Stephen J. Wilcox wrote:
Could it be Path MTU/fragmentation issues on account of the low MTU you have in combination with some ICMP issues where network admins have some screwy setup?
That's exactly what it is... a large (1500 byte probably) TCP datagram with the DF bit set will be heading towards his edge device which are PPPoE connected.
Great domain, btw (f00f.org, brings back memories of division)... Anyway, a great stride was just made in my lab^H^H^Hbasement. First off, it appears a 'ip mtu 1492' on the Virtual-Template of the IOS Router aggregating the PPPOE session is not strictly enforced, especially with windows. Another words, I saw in the PPP debug that the MRU wasn't being negotiated. So, I found this really nifty utility, aptly named 'Mr. TCP': http://www.dslreports.com/front/drtcp.html It allows you to tinker with the Windows settings of TCP. I adjusted MTU to 1400, wham-o, all the sites I listed started working; including, what I didn't list before, the downloading of transactions via Quicken. Seems to be a fixall. -- Alex Rubenstein, AR97, K2AHR, alex@nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
On Wed, 18 Jul 2001, Alex Rubenstein wrote:
It allows you to tinker with the Windows settings of TCP. I adjusted MTU to 1400, wham-o, all the sites I listed started working; including, what I didn't list before, the downloading of transactions via Quicken. Seems to be a fixall.
I can tell it's getting late, when I reply to myself. In the scenerio where you have a router be the PPPOE client (in my test case, it's a Cisco 827 running 12.1(3)XG4), things are still somewhat broken. The 827 is routing between an ethernet and a PPPOE session, and even with the 827 having the MTUs at 1492 or 1400, windoze boxen are still stuck up there at 1500 and those sites don't work. I then use Mr. TCP and set the ethernet card of the windows box to a MTU of 1400, and voila, it works. This really sucks for those folks who will have many machines bechind said router; it will require a Mr. TCP on each and every one of them. Sheesh. -- Alex Rubenstein, AR97, K2AHR, alex@nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
On Wed, 18 Jul 2001, Alex Rubenstein wrote:
On Wed, 18 Jul 2001, Alex Rubenstein wrote:
It allows you to tinker with the Windows settings of TCP. I adjusted MTU to 1400, wham-o, all the sites I listed started working; including, what I didn't list before, the downloading of transactions via Quicken. Seems to be a fixall.
I can tell it's getting late, when I reply to myself.
In the scenerio where you have a router be the PPPOE client (in my test case, it's a Cisco 827 running 12.1(3)XG4), things are still somewhat broken. The 827 is routing between an ethernet and a PPPOE session, and even with the 827 having the MTUs at 1492 or 1400, windoze boxen are still stuck up there at 1500 and those sites don't work. I then use Mr. TCP and set the ethernet card of the windows box to a MTU of 1400, and voila, it works.
This really sucks for those folks who will have many machines bechind said router; it will require a Mr. TCP on each and every one of them.
You do not need to use a third party app. for this. You can set MTU on 9x and NT/2k with a registry setting. Under 9x : HKLM -> System -> CurrentControlSet -> Services -> Class -> NetTrans -> 00x (where x is the number of the adapter whose MTU you wish to change), you create a new String Value called MaxMTU and set it to the byte size you wish to use. Under NT/2k : HKLM -> System -> CurrentControlSet -> Services -> <adapterX> -> Parameters -> TCPIP (where adapterX is (in my case) E100B), you create a new DWORD called MTU and set it to the MTU you wish to use. The easy way to find where to create these is just enter regedit and search on the machines IP address. If you have multiple hardware profiles in NT/2k you may end up in ControlSet00x. Another option is the use DHCP, which has a setting for MTU if I recall (but you would want to read the docs on this). Doing a quick look through the registry on my laptop under Win2k shows the possibilities are 3, with CurrentControlSet, ControlSet001, and ControlSet002 all have the current IP parameters in them. Trial and error would reveal which section actually needs the MTU dword (maybe all 3). I can't believe I know this much about MS's TCP stack, someone please shoot me. Jamie Bowden -- "It was half way to Rivendell when the drugs began to take hold" Hunter S Tolkien "Fear and Loathing in Barad Dur" Iain Bowen <alaric@alaric.org.uk>
You do not need to use a third party app. for this. You can set MTU on 9x and NT/2k with a registry setting.
<* snip *> While I agree, It's 10498% easier when you have a cluless DSL customer on the horn, and you want to change thier MTU, if you use this app rather than trying to explain to them what a registry even is. -- Alex Rubenstein, AR97, K2AHR, alex@nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
On Wed, 18 Jul 2001, Alex Rubenstein wrote:
While I agree, It's 10498% easier when you have a cluless DSL customer on the horn, and you want to change thier MTU, if you use this app rather than trying to explain to them what a registry even is.
Not being a real windows know-it-all, this is a guess, but I had to diddle with registry settings yesterday to get Outlook to stop crashing on startup. Short version is that you can export a "piece" of the registry as a .reg file. It seems you could go to the section where MTU is set and export it, and then simply put a link to the file on your support site. Have the user clicky-click on the link and answer "yes" to everything, and wham-o. A similar example is here: http://www.dslreports.com/tweaks?item=RWIN A bit off-track, but can anyone using Redback stuff give a quick yes/no to this: Can the Redback, on a 1483-bridged customer where the pvc is known do dhcp based on the pvc the dhcp request comes from? What other trickery does it do if you are dead-set against PPPoE but still need some authentication and enforcement of addresses? Alex - Does VZ do one pvc/customer or group hundreds together on one pvc still? Charles
-- Alex Rubenstein, AR97, K2AHR, alex@nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
At 11:55 AM 7/18/2001 -0400, Charles Sprickman wrote:
Alex - Does VZ do one pvc/customer or group hundreds together on one pvc still?
They do. They have a group of 19 PVCs currently in NJ on which any customer's traffic may terminate. Each PVC goes back to a Reback which aggregates traffic from a certain area. However, I have also been told that the PVCs are randomly assigned and there is no correlation between physical location and which PVC is used. It sounds terrible, but it actually works pretty well. -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "It is never too late to be what you might have been." -George Eliot
Also sprach Charles Sprickman
Short version is that you can export a "piece" of the registry as a .reg file. It seems you could go to the section where MTU is set and export it, and then simply put a link to the file on your support site. Have the user clicky-click on the link and answer "yes" to everything, and wham-o.
Problem here being that the piece of the registry that needs to be modified will change depending on what interfaces there are on the system, how many interfaces there are on the system, maybe what phase the moon is in, and probably some other stuff. Since the entries are numbered, it could conceivably be dependant on which order the interfaces get added (ethernet card added later, or dun set up later?).
A bit off-track, but can anyone using Redback stuff give a quick yes/no to this:
Can the Redback, on a 1483-bridged customer where the pvc is known do dhcp based on the pvc the dhcp request comes from? What other trickery does it do if you are dead-set against PPPoE but still need some authentication and enforcement of addresses?
Sort of. It won't send its own DHCP request, but it'll serve as a DHCP relay agent, and will add the DHCP relay agent options to the DHCPDISCOVER message...including the relay sub-option for circuit. This sub-option could be used in your DHCP server to specify what IP addresses are assigned to customers (static IP address assignment via DHCP is possible this way, or dynamically assign them, but limit each circuit to only getting x number of addresses). Incidentally, the SMS can use the DHCP info to build its secured-arp table, and with an SRAM card in it, it can preserve that secured-arp table between reboots so customers don't have to release then renew to get their connectivity back if your RedBack reboots for whatever reason.
Alex - Does VZ do one pvc/customer or group hundreds together on one pvc still?
We get one customer per pvc in Lexington (former GTE territory). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
On Wed, 18 Jul 2001, Charles Sprickman wrote:
A bit off-track, but can anyone using Redback stuff give a quick yes/no to this:
Can the Redback, on a 1483-bridged customer where the pvc is known do dhcp based on the pvc the dhcp request comes from? What other trickery does it do if you are dead-set against PPPoE but still need some authentication and enforcement of addresses? To my knowledge, no: Redback is a transparent device, it'll just forward your DHCP request along to the ISP.
When you find the holy grail [100% reliable authentication of rfc1483-bridged customers], please let all of us know ;)
Alex - Does VZ do one pvc/customer or group hundreds together on one pvc still?
I'm the other Alex, but the answer is the latter (one pvc per gateway router/VLAN combination). -- Alex Pilosov | http://www.acedsl.com/home.html CTO - Acecape, Inc. | AceDSL:The best ADSL in the world 325 W 38 St. Suite 1005 | (Stealth Marketing Works! :) New York, NY 10018 |
In article <Pine.BSF.4.33.0107181141000.5717-100000@shell.inch.com>, Charles Sprickman <spork@inch.com> wrote:
Can the Redback, on a 1483-bridged customer where the pvc is known do dhcp based on the pvc the dhcp request comes from?
Yes. We do it. Works fine. Your DHCP server must support it, though. You need to be able to use the circuit-id to select a customer, which is complicated by the fact the the redback only adds this circuit-id on DHCPDISCOVERS, it doesn't intercept (that is act as a relay agent for) unicast DHCP packets. We're using ISC DHCPD. Use stash-agent-options, classes, pools with only one address in it (one per customer) and you'll get there ;) Mike. -- "dselect has a user interface which scares small children" -- Theodore Tso, on debian-devel
participants (7)
-
Alex Pilosov -
Alex Rubenstein -
Charles Sprickman -
Jamie Bowden -
Jeff Mcadams -
miquels＠cistron-office.nl -
Robert Boyle