Experts,
out of the well-known values for ip options:
X@r4# set ip-options ?
Possible completions:
<range> Range of values
[ Open a set of values
any Any IP option
loose-source-route Loose source route
route-record Route record
router-alert Router alert
security Security
stream-id Stream ID
strict-source-route Strict source route
timestamp Timestamp
I can only think of:
- RSVP using router-alert
- ICMP using route-record, timestamp
But I can not think of any other use of any other IP option.
Considering the security hazard that they imply, I am therefore thinking
to drop them.
Is any other ip options used by: ospf, isis, bgp, ldp, igmp, pim, bfd?
Thanks,
Luca.
There is a debate among our engineering staff as to the best means of provisioning broadband service over copper facilities. Due to our history, we have a mix out in the field. Some customers are on DSLAMS set up for bridged connections with DHCP; isolated by a variety of means including VLANS. Some customers are on PPPoE over ATM. Some customers are on PPPoE over ethernet (PPPoEoE ?? ).
There seem to be pros and cons to both directions. Certainly true bridging has less overhead. But modern CPEs can minimize the impact of PPPoE. PPPoE allows for more flexible provisioning; including via RADIUS. Useful for the call center turning customers on/off without NOC help. But VLAN tricks can sometimes do many of the same things.
Opinions on this? I'd be interested in hearing the latest real world experience for both and the direction most folks are going in.
BTW, I doubt it is relevant to the discussion, but most of our DSLAMS are Adtran TA5000s (or are being migrated to that platform.) We are mostly a cisco shop for the upstream routers.
There seem to be pros and cons to both directions. Certainly true bridging has less overhead. But modern CPEs can minimize the impact of PPPoE. PPPoE allows for more flexible provisioning; including via RADIUS. Useful for the call center turning customers on/off without NOC help. But VLAN tricks can sometimes do many of the same things.
Call your vendor and demand better radius backend support for dhcp.
The largest fallback to PPPoE is the CPE needing to terminate the PPPoE or the customer's router/computer/etc needing to do so. This can be a pain especially in business environments. I have one section of my network (maintained by counterpart, not me) that is 90% PPPoE/A. The other 10% is bridge due to customer needs and CPE limitations.
I personally run all my stuff as bridge, including all the CPEs.
BTW, I doubt it is relevant to the discussion, but most of our DSLAMS are Adtran TA5000s (or are being migrated to that platform.) We are mostly a cisco shop for the upstream routers.
I have been extremely happy with unnumbered vlans in the cisco work for terminating mass vlans from dslams that support 802.1ad. The fact that it works right next to RBE works great for me. The current IPv6 layouts aren't as pretty for this setup, though.
On Cisco hardware PPPoE was cleaner if you have other ISPs' customers on
your network and you want to put them in their own VRF's. I've been out of
that world for a while now, so maybe it's changed.
Opinions on this? I'd be interested in hearing the latest real world
experience for both and the direction most folks are going in.
I can't speak to which would be better on copper specifically, but in
general I'd favor DHCP over PPPoE. Either way, most of the back-end stuff
will be similar (you'll need a way to authenticate users, turn them off and
on, et cetera); the differences won't be all that big. Either you're storing
their MACs in a database, or their port assignments and VLAN tags, or their
usernames and passwords.
With PPPoE, however, the end-user can't just plug in and go - they'll have
to configure their PC, or a DSL modem, or something. That means a phone call
to your tech support, most likely. In many cases, DHCP can lead to
plug-and-play simplicity, which means they don't have to call you, and you
don't have to answer their calls. Everyone wins.
Most aDSL modems if set to PPPoE (I think Actiontec's come this way by
default) will send the mac as the pppoe un/pw.
David E. Smith wrote:
Opinions on this? I'd be interested in hearing the latest real world
experience for both and the direction most folks are going in.
I can't speak to which would be better on copper specifically, but in
general I'd favor DHCP over PPPoE. Either way, most of the back-end stuff
will be similar (you'll need a way to authenticate users, turn them off and
on, et cetera); the differences won't be all that big. Either you're storing
their MACs in a database, or their port assignments and VLAN tags, or their
usernames and passwords.
With PPPoE, however, the end-user can't just plug in and go - they'll have
to configure their PC, or a DSL modem, or something. That means a phone call
to your tech support, most likely. In many cases, DHCP can lead to
plug-and-play simplicity, which means they don't have to call you, and you
don't have to answer their calls. Everyone wins.
We like PPPoE on the edge because we can use RADIUS to apply policy to the subscribers for bandwidth management, class-of-service, SNPs, etc. You probably have some of these features via your DSLAM, but we found it easier to do via RADIUS with a web based GUI for our provisioning folks. So if we need to snip someone's Internet and leave voice or VPN packets alone due to an abuse issue for example, we can apply the policy that references the appropriate ACL.
Most aDSL modems if set to PPPoE (I think Actiontec's come this way by
default) will send the mac as the pppoe un/pw.
David E. Smith wrote:
Opinions on this? I'd be interested in hearing the latest real world
experience for both and the direction most folks are going in.
DOCSIS cable networks use DHCP and have for a long time. If you have
Ethernet based DSLAMs, they can usually do the a number of tricks (e.g.
Option 82 insertion into the DHCP request) that would make a DHCP ADSL
deployment no harder (or easier) than a DOCSIS cable network.
It seems to me that the fundamental purpose of PPPoE is to be able to
uniquely identify the customer for billing/provisioning purposes. Even
though you only need to be able to do that at the start of their
session, with PPPoE you pay an 8 byte per packet overhead, on _every_
packet sent and received by the customer. Other methods of
distinguishing the customer, e.g. Option 82, static DHCP mapped to a
customer MAC address, or possibly 802.1x if it were available, have
much, much lower overhead.
I think PPPoE really only exists to make ADSL look like high speed
dial-up, so that ISPs dial up backend systems didn't need to be changed
when ADSL was introduced. That was a valid concern in the past, but
with existing solutions or models such as the DOCSIS Cable methods, and
Ethernet based DSLAMS, I'd suggest avoiding PPPoE if you can.
I think the important thing is to have a separate L2 isolation per customer so you can more easily deploy IPv6 in the future. q-in-q or PPPoX will both solve this problem, but deploying multicast TV offering might be harder in this deployment model.
There is really no devices out there to securely do IPv6 to the end user natively when you have a shared L2 domain (in v4 this implies the L2 device will do DHCP snooping and do filtering based on that).
I don't really like tunneling, so I'd advocate the q-in-q model with separate vlan per customer (or having the L3 routing very close to the customer so you don't need to do q-in-q but still can do separate vlan per customer).
One of the reasons for UUNET's PPPOE design was to reduce phone calls and configuration hassles. But in a different way. In the "old" days, people thought there would be separation between the ISP and the wholesale network. The idea that the provider could control/manage the CPE, like a cable set-top box, was probably more radical at the time than a dumb
modem and PPPOE client on the PC.
PPPOE can allow changing ISPs just by changing the username@domain, without needing to call wholesale provider's tech support and reconfiguring the circuit. You could even have multiple PC's sharing the same circuit, each connecting to different ISPs at the same time. Or use PPPOE to "call" a business' DSLAM pool for work access, and then call AOL's DSLAM pool for personal use. The concept of multiple "dialers" was well supported on most operating systems, and more familar to the public at the time than trying to set hostnames or read MAC addresses in DHCP configurations.
In those days, VPN/IPSEC tunnel support wasn't very common. Businesses still had dial-up modem pools, X.25 PADs, and private PPP/PPPOE/PPPOA/PPPOx connections. Compared to the overhead for other point-to-point and tunneling protocols at the time, PPPOE's overhead didn't look that bad. And since it was based on PPP, PPPOE made route addressing (and other routing stuff) easy. Addressing a single host is
the simple case of the more general router PPP information.
As Milo used to say, with enough thrust you could get DHCP to do many of those same things too. There were a lot of experiments, and not all of them worked well.
As they say, the world changed.
Ethernet won, vertically integrated ISPs won, VPN won, and yes DHCP (with lots of options) won too. We can have a betamax/vhs-style argument of technical superiority; but the market made a choice.
I think the important thing is to have a separate L2 isolation per customer so you can more easily deploy IPv6 in the future. q-in-q or PPPoX will both solve this problem, but deploying multicast TV offering might be harder in this deployment model.
In general, it shouldn't be. Local multicast TV offerings should be transmitted out of band from the standard internet connection, either different vlan or outside of the PPPoE. The nature of it usually indicates a specialized CPE maintained by the provider to support the necessary QOS, and division of Internet and Video traffic.
For public multicast, splitting in the local pop just doesn't matter much.
There is really no devices out there to securely do IPv6 to the end user natively when you have a shared L2 domain (in v4 this implies the L2 device will do DHCP snooping and do filtering based on that).
Several vendors claim to have v6 support for this in the next year. Currently, many of them completely break v6 due to the v4 security.
Adds the username/password that PPP has to DHCP and I believe support IPv6.
Now if we could just tweak things perfectly so customers can hook up, log in to the ISP, and use tickets to access everything and it's dog, that would rock.
A nice extension to allow corporate networks to interface with that system would be even cooler.
Others commented on things I already had in mind only the username/password
thing of PPPoE. We use the same username/pw on the modem as the customer
users for their e-mail, so a password change necessitates a truck roll (I
know, I know, TR-069). We started with PPPoE for our FTTH, because we were
familiar with it, but we moved over to a "VLAN per service" model which ends
up something like RBE in function. We can track customers based on the
Option 82 info, so we're good to go in terms of tracking them.
It may be worth noting here that there are times were one wants
barriers between automation to keep malfunction or malice from
spreading too far without human involvement.
Of course, most of the current barriers we have are accidental,
random, and ill-defined, so there's clearly room for improvement
either way.
For telco-delivered IPTV, the multicast channel, bi-directional control
channel, and video are transmitted on different VP/VC. For VDSL2, I'm
guessing it would be a different VLAN.
That's what makes protocol wars so much fun. With enough options, almost any protocol can do almost anything.
As you know, I did my best to kill PPPOx at an ISP and in the IPTV architecture several vendors were selling at the time. I still think that sometimes DHCP is the answer, and other times PPPOx is the answer, but you can usually make either work if necessary. And even though I chose DHCP, the vendor needed to fix several things. I haven't kept track if all of them were really fixed.
