I’m sure there’s more than one way to do this. This seems like one of those things that has a few knobs that all do different things, and if you have those knobs arranged in a certain order then things work. And there’s enough of those knobs that it’s easy to get lost and find yourself in a special DHCP/PPP hell where clients have no addresses, and servers have 0 available addresses, even though there’s only one address in the pool, and there’s only one client on the wire.
I think I should start by saying that this isn’t PPPoE specific, even though I’m going to use a PPPoE example. This config should work with any PPP config where you would like to use DHCP.
As usual, we’ll set the stage with a little diagram of our topology. I fear that today, my dear reader, the simplicity of the topology will be something of a letdown…
Please, restrain yourself. This is Hi-Tech stuff here, and looks can be deceiving!
For our starting config we have a vanilla PPPoE setup. R1 is going to be our PPP (and DHCP) server, and R2 is our PPPoE client. To begin with R2 has a static address assigned simply for the purpose of proving connectivity to act as a baseline.
R1
bba-group pppoe global
virtual-template 1
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
pppoe enable group global
!
interface Virtual-Template1
ip address 10.0.12.1 255.255.255.0
R2
interface FastEthernet0/0
no ip address
duplex auto
speed auto
pppoe enable
pppoe-client dial-pool-number 1
!
interface Dialer1
mtu 1492
ip address 10.0.12.2 255.255.255.0
encapsulation ppp
dialer pool 1
!
So now that we have everything working let’s break it shall we?
Since the point of this whole thing is to get a dynamic address via DHCP lets set R2 to use DHCP
Our client is now ready to go. No further effort needed here. R1 is where all the trickery is going to happen.
Our first task on R1 is to create our DHCP pool.
You’ll notice that here we are using the host command instead of our usual network command. This is because in this case I’m going adding a manual binding for a single host and not really a whole pool of addresses for an entire subnet of hosts. When you’re configuring a static binding you are also going to need some additional information in the pool to identify the host that this manual binding is to be assigned to. For DHCP this is usually a client-identifier. If no client-identifier is present, or this is for BootP, then you will need to specify the hardware-address instead.
This is now where I encourage you to quickly read over the relevant section of the DocCD. I’ll even provide the link.
http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr_dhcp/configuration/12-4t/config-dhcp-server.html#GUID-68D87544-7C6F-48C9-9DFE-56F5B7E4A89D
So what should I be adding here? Are we going to use the client-identifier or the hardware-address? The answer is of course the client-identifier since this is DHCP afterall!
How do we find the client-identifier? Well, there are a couple ways. The first, and likely the best since it doesn’t change anything needlessly, is to debug the DHCP packets on the DHCP server.
Well, looky here. We now know the correct value. And yes, it is that very LONG string of hex characters. All of it. Yes, really.
And we’re good, yes?
That's certainly a good sign!
Will it ping?
Success!
As a test I saved the config and rebooted both of these routers, and everything came back up nicely. This appears to be a valid configuration and performs as expected. If you have any comments, or know why this may still be a broken config please do let me know. As I said at the onset I'm sure that there's other ways to do this, and I might be missing something that my labbing has missed that could bite me in the ass in the real Lab.
No comments:
Post a Comment