PPPOE, MTU, and boom.

Mailman List Mirror (Read Only)
1

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 --

2

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 --

3

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

4

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 --

5

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

6

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

7

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).

8

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 :wink:

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).

9

In article <Pine.BSF.4.33.0107181141000.5717-100000@shell.inch.com>,

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 :wink:

Mike.