Restricting ONT's Ethernet port to singe active IP address - working

Thu Apr 23 20:34:13 UTC 2009

Thanks for everyone's feedback.  We tested this afternoon and it worked
great.  We were able get two leases handed out, but the third resulted in a
log entry of 

Apr 23 14:57:28 a.b.c.d dhcpd: DHCPDISCOVER from 00:22:6b:71:e2:bb via
e.f.g.254: no available billing

Apr 23 14:57:46 a.b.c.d dhcpd: DHCPDISCOVER from 00:22:6b:71:e2:bb via
e.f.g.254: no available billing

The Calix gear supports two kinds of Option 82: "Standard" and "DSL Forum
1".  

"Standard" results in the following:

agent.circuit-id: n1-1-vb1-1-vlan2

agent.remote-id: Ont:N30-1-14-1-32-OntEth1-1

"DSL Forum 1" results in the following:

agent.circuit-id: RST1 atm ont 1-14-1-32-1:1

agent.remote-id:

The "Standard" has a circuit-id that refers to the name of the uplink
Ethernet port, not the customer facing Ethernet interface.  So I shouldn't
spawn on that.  You can see that the "DSL Forum 1" has no remote-id and
doesn't refer to the shelf number, but the shelf name.  In our case not all
shelf names are unique, and it's kind of arbitrary.  So we settled on
"Standard".  We do have a few shelves that overlap shelf numbers, but we can
re-number those in advance, and the other site doesn't have ONTs.

So this what I entered into my configuration file:

class "ONTs"

{

    lease limit 2;

    match if substring(option agent.remote-id,0,3)="Ont";

    spawn with option agent.remote-id;

}

And here's what was in my lease file.

lease e.f.g.253 {

  starts 4 2009/04/23 19:46:53;

  ends 6 2009/05/23 19:46:53;

  tstp 6 2009/05/23 19:46:53;

  binding state active;

  next binding state free;

  billing subclass "ONTs"
4f:6e:74:3a:4e:33:30:2d:31:2d:31:34:2d:31:2d:33:32:2d:4f:6e:74:45:74:68:31:2
d:31:00;

  hardware ethernet 00:1e:e5:73:ed:c8;

  uid "\001\000\036\345s\355\310";

  option agent.circuit-id "n1-1-vb1-1-vlan2";

  option agent.remote-id "Ont:N30-1-14-1-32-OntEth1-1";

}

lease e.f.g.252 {

  starts 4 2009/04/23 19:56:28;

  ends 6 2009/05/23 19:56:28;

  tstp 6 2009/05/23 19:56:28;

  binding state active;

  next binding state free;

  billing subclass "ONTs"
4f:6e:74:3a:4e:33:30:2d:31:2d:31:34:2d:31:2d:33:32:2d:4f:6e:74:45:74:68:31:2
d:31:00;

  hardware ethernet 00:22:6b:9a:12:3b;

  uid "\001\000\"k\232\022;";

  option agent.circuit-id "n1-1-vb1-1-vlan2";

  option agent.remote-id "Ont:N30-1-14-1-32-OntEth1-1";

  client-hostname "00226B9A123B";

}

Thanks for all the help!

Frank

From: dhcp-users-bounces at lists.isc.org
[mailto:dhcp-users-bounces at lists.isc.org] On Behalf Of Frank Bulk
Sent: Wednesday, April 22, 2009 2:47 PM
To: dhcp-users at isc.org
Subject: Restricting ONT's Ethernet port to singe active IP address

In the cable modem and DSL world it's pretty easy to restrict the premise
equipment to a single IP address.  

-       In the cable modem world that can be assigned to the CM
configuration file or on the CMTS.  

-       DSL has a couple of flavors.  With PPPoA it's a single IP address
per vp/vc.  With PPPoE it can be nicely controlled on a per username or
connection basis.  With Cisco's RBE there's "DHCP Lease Limit per ATM RBE
Unnumbered Interface" to control handing out IP addresses.

But an RFC-1483-like FTTH implementation doesn't come with all those
benefits.  We could put a $50 CPE in each home with PPPoE and be responsible
for managing it, but we would prefer to let customers plug in their own
equipment into the ONT, but just get one IP address.

Option 82 support seems like the closest way to get it done, by creating
classes and handing out an static IP, but I understand the process
correctly, it requires generating a class for each Option 82 string and
assigning a static IP address.  That has the negatives of creating classes
in advance and giving out statics when I don't want to give out statics.

What it seems I want is to be able to use dynamic classes and hand out just
one IP address for each Option 82 string.  I know that dhcp is built around
using the MAC address as the standard identifier, but is there any solutions
to the challenge we're facing?

We also want our customers to be able to change CPE half-way through a lease
and not have to call the helpdesk to flush their legacy DHCP leases because
their new CPE doesn't get an IP address. ;)

I'm open for suggestions, and for those who can design an elegant solution
that doesn't require any re-compiling of code, a bounty.

Frank

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090423/eeb73616/attachment-0001.html>