Re: IEWB lab 13 dhcp & isdn task 4.3 and task 12.1

From: ccie2be (ccie2be@nyc.rr.com)
Date: Fri Nov 05 2004 - 19:34:47 GMT-3


Hey Andy,

I really appreciate all the time you're taking to explain this stuff to me
( and the rest of the GS community) and this is really helping.

Well, as so often happens, one answer leads to new questions and this is
true in this case.

You just pointed out that there's a distinction between a router configured
with a helper address for dhcp discover messages can be forwarded to a dhcp
server ( I don't know if there's a specific name that applies to such a
server, is there?) and server called a "dhcp-relay agent".

I was never aware of such a distinction. I thought any router configured
with the ip helper address (or ip dhcp-server <ip addr>) command was
considered a dhcp-relay agent. They get a dhcp discover message from a
client and "relay" it to the dhcp server. Can you confirm I'm wrong about
this?

Also, in the paragraph where you describe what the dhcp-relay agent does, I
have to admit I don't really follow what's going on or how that actually
works. If you can, would you tell me in greater detail what the dhcp-relay
agent does when it gets a dhcp request from a dhcp client. And, what
command is used to make a router a dhcp-relay agent. Where I'm still
confused is that somehow doesn't a dhcp-relay agent still have to send
requests to a dhcp server and therefore must have the address of the dhcp
server configured on it?

An example config for a dhcp-relay agent would really be great.

BTW, see my other post - dhcp and address nego over an isdn link. I spoke
to Brain McGahan and he tells we're wrong about how this works.

Thanks again, Tim

----- Original Message -----
From: "Edwards, Andrew M" <andrew.m.edwards@boeing.com>
To: "ccie2be" <ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
Sent: Friday, November 05, 2004 4:05 PM
Subject: RE: IEWB lab 13 dhcp & isdn task 4.3 and task 12.1

Well, DHCP provides both local and offsubnet automated IP addressing for
DHCP enabled clients.

So, if you are on the local subnet and so is the DHCP server, when the
client broadcasts for the DHCP server with a Request for a lease then
the DHCP server will see the request and make an offer after checking
availability.

However, if you are NOT on the same subnet, you have a few options. One
of which is using the helper-address command. As you are aware, helper
address simply re-encapsulates the 8 default broadcast based application
protocols into a unicast directed towards the helper address server IP.
Included in the request is the source requesting subnet (this gives the
DHCP server with mulitple scopes/zones, the capability of
differentiating what IP address to provide based on subnet.)

Anyhow, the response comes unicast back to the router that places the
offer onto the local subnet to the requesting client. The client binds
and all is wonderful in the world of IP.

The other way, is to use dhcp-relay agents. These are servers (or now a
router) that does NOT provide any unicast forwarding capability or local
DHCP server scope/zones itself. Instead it knows what server does by IP
and forwards the request directly to that server.

So, you are trying to do it with the relay agent by saying, "Hey router
you are a relay agent." Then you give it the DHCP server IP address to
say, "Here is the IP address of the DHCP server you should send requests
too." And the combination of these two tells the router to "get with
the program".

HTH,

andy

-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Friday, November 05, 2004 11:53 AM
To: Edwards, Andrew M; ccielab@groupstudy.com
Subject: Re: IEWB lab 13 dhcp & isdn task 4.3 and task 12.1

Hi Andrew,

Thanks for getting back to me. This problem has been driving me nuts.

I'm a bit surprised, though, with the first thing you said regarding
configuring the ip helper-address command on R5 to point to the dhcp
server address on R1.

I thought the command, ip dhcp-server <ip addr> does the same thing as
ip helper <ip addr> except it's more specific ie it only forwards dhcp
requests rather than all the things forwarded by the ip helper-address
command. Is my understanding of this wrong? Or, is there a different
issue with using this command - maybe something specific to how cisco
implements PPP?

Regarding the other command you mentioned, ip address-pool
dhcp-proxy-client, I looked that up on the Doc-CD, but honestly, I don't
really understand if or why this command is needed. This is what the
Doc-CD says about this command.

"To enable an address pooling mechanism used to supply IP addresses to
dial-in asynchronous, synchronous, or ISDN point-to-point interfaces,
use the ip address-pool command in global configuration mode."

It seems to be implying that dhcp won't work without an "address pooling
mechanism". Actually, I guess I don't understand what the heck are they
talking about? Is dhcp an "address pooling mechanism"? So, if you could
translate into English what they're saying, I'd be really, really
grateful.

Obviously, these various ip address mechanisms are about as clear as mud
to me. And, I thougth I understood DHCP. Well, I guess not. But, thank
you for confirming for me that R4, in fact, wasn't getting a dhcp
assigned address.

From the debug dhcp output below, how can you tell that R5 isn't
forwarding a dhcp request to R1 (as opposed to not receiving a response
from R1), or are you deducing that's what going on because of the
following lines, for example or what you're NOT seeing in the debug
output ?

*Mar 1 07:08:42.478: DHCP Lease server: 0.0.0.0, state: 1 Selecting
*Mar 1 07:08:42.478: DHCP transaction id: FCC10C
*Mar 1 07:08:42.478: Lease: 0 secs, Renewal: 0 secs, Rebind: 0

I apologize for all the questions, but my lab is next week and I'm kind
of nervous.

Thanks again, Tim

----- Original Message -----
From: "Edwards, Andrew M" <andrew.m.edwards@boeing.com>
To: "ccie2be" <ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
Sent: Friday, November 05, 2004 1:54 PM
Subject: RE: IEWB lab 13 dhcp & isdn task 4.3 and task 12.1

My thoughts....

On R5, you need ip helper-address to R1.

R5 is connecting to R4 on the callback but the DHCP lease is not being
negotiated. R5 see's the R4 request but it can't do anything with it...

So, get R5 to encapsulate (unicast) and forward the local link broadcast
from R4 for a DHCP Lease Request. Once you see NCP on the BRI link
negotiate the Network Control Protocol address received from R1 you will
get connectivity at layer 3 between r4 and r5.

Alternatively, if you want to specify the IP address of the DHCP server,
you will need to use the global ip address-pool dhcp-proxy-client
command to specify that R5 should proxy DHCP requests on behalf of
locally connected clients. Two ways to do the same thing.... One being
more efficient (I think the later).

HTH,

andy

-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Friday, November 05, 2004 6:57 AM
To: Group Study
Subject: Fw: IEWB lab 13 dhcp & isdn task 4.3 and task 12.1

Hey guys,

In the isdn portion of this task, I needed to configure dialer profiles
on both R4 and R5, have R5 call R4 and then make R4 hangup and callback
R5. I got this part to work. To confirm that this was working I used,
isdn test call int bri 0/0 5272034 and enabled debug dialer on R4. When
I reviewed the debug logs, I could see the call from R5 connect, then
disconnect and then R4 callback R5.

However, I also needed to configure R4 to get it's dialer's interface ip
address from a dhcp server directly connected to R5.

I also enabled debug dhcp on R4 and R5, but I can't tell from the debug
out what's really going on. So, I don't know if R4 ever really got an ip
address.

I've configured R4 and R5 as shown is the SG, but the dhcp part doesn't
seem to working, although I'm not 100% sure. Once the link was up after
R4 called back R5, I did several pings but those never were successful.

I was struggling with this for hours but never got pings to work across
the isdn link, so I'm hoping someone can help me understand what's going
on.

Here's some output from deb dhcp on R5:

*Mar 1 07:08:42.478: DHCP Lease server: 0.0.0.0, state: 1 Selecting
*Mar 1 07:08:42.478: DHCP transaction id: FCC10C
*Mar 1 07:08:42.478: Lease: 0 secs, Renewal: 0 secs, Rebind: 0
secs
*Mar 1 07:08:42.478: Next timer fires after: 00:00:03
*Mar 1 07:08:42.478: Retry count: 2 Client-ID:
cisco-139.3.45.5-BRI0/0:1
*Mar 1 07:08:42.478: DHCP: SDiscover: sending 285 byte length DHCP
packet *Mar 1 07:08:42.478: DHCP: SDiscover 285 bytes *Mar 1
07:08:53.078: DHCP: QScan: Purging entry *Mar 1 07:08:53.078: DHCP:
deleting entry 622AE8CC 0.0.0.0 from list *Mar 1 07:08:53.078: Temp IP
addr: 0.0.0.0 for peer on Interface: unknown *Mar 1 07:08:53.078: Temp
sub net mask: 0.0.0.0
*Mar 1 07:08:53.078: DHCP Lease server: 0.0.0.0, state: 8 Purging
*Mar 1 07:08:53.078: DHCP transaction id: FCC107
*Mar 1 07:08:53.078: Lease: 0 secs, Renewal: 0 secs, Rebind: 0
secs
*Mar 1 07:08:53.078: No timer running
*Mar 1 07:08:53.078: Retry count: 0 Client-ID:
*Mar 1 07:08:57.178: DHCP: QScan: Purging entry
*Mar 1 07:08:57.178: DHCP: deleting entry 629D70C0 0.0.0.0 from list
*Mar 1 07:08:57.178: Temp IP addr: 0.0.0.0 for peer on Interface:
unknown *Mar 1 07:08:57.178: Temp sub net mask: 0.0.0.0
*Mar 1 07:08:57.178: DHCP Lease server: 0.0.0.0, state: 8 Purging
*Mar 1 07:08:57.178: DHCP transaction id: FCC108
*Mar 1 07:08:57.178: Lease: 0 secs, Renewal: 0 secs, Rebind: 0
secs
*Mar 1 07:08:57.178: No timer running
*Mar 1 07:08:57.178: Retry count: 0 Client-ID:
*Mar 1 07:09:01.278: DHCP: QScan: Purging entry
*Mar 1 07:09:01.278: DHCP: deleting entry 622AE168 0.0.0.0 from list
*Mar 1 07:09:01.278: Temp IP addr: 0.0.0.0 for peer on Interface:
unknown *Mar 1 07:09:01.278: Temp sub net mask: 0.0.0.0
*Mar 1 07:09:01.278: DHCP Lease server: 0.0.0.0, state: 8 Purging
*Mar 1 07:09:01.278: DHCP transaction id: FCC109
*Mar 1 07:09:01.278: Lease: 0 secs, Renewal: 0 secs, Rebind: 0
secs
*Mar 1 07:09:01.278: No timer running
*Mar 1 07:09:01.278: Retry count: 0 Client-ID:
*Mar 1 07:09:05.378: DHCP: QScan: Purging entry
*Mar 1 07:09:05.378: DHCP: deleting entry 622A94C8 0.0.0.0 from list
*Mar 1 07:09:05.378: Temp IP addr: 0.0.0.0 for peer on Interface:
unknown *Mar 1 07:09:05.378: Temp sub net mask: 0.0.0.0
*Mar 1 07:09:05.378: DHCP Lease server: 0.0.0.0, state: 8 Purging
*Mar 1 07:09:05.378: DHCP transaction id: FCC10A
*Mar 1 07:09:05.378: Lease: 0 secs, Renewal: 0 secs, Rebind: 0
secs
*Mar 1 07:09:05.378: No timer running
*Mar 1 07:09:05.378: No timer running
*Mar 1 07:09:09.478: DHCP: QScan: Purging entry
*Mar 1 07:09:09.478: DHCP: deleting entry 629D34B0 0.0.0.0 from list
*Mar 1 07:09:09.478: Temp IP addr: 0.0.0.0 for peer on Interface:
unknown *Mar 1 07:09:09.478: Temp sub net mask: 0.0.0.0
*Mar 1 07:09:09.478: DHCP Lease server: 0.0.0.0, state: 8 Purging
*Mar 1 07:09:09.478: DHCP transaction id: FCC10B
*Mar 1 07:09:09.478: Lease: 0 secs, Renewal: 0 secs, Rebind: 0
secs
*Mar 1 07:09:09.478: No timer running
*Mar 1 07:09:09.478: Retry count: 0 Client-ID:
*Mar 1 07:09:13.578: DHCP: QScan: Purging entry
*Mar 1 07:09:13.578: DHCP: deleting entry 629D3684 0.0.0.0 from list
*Mar 1 07:09:13.578: Temp IP addr: 0.0.0.0 for peer on Interface:
BRI0/0:1 *Mar 1 07:09:13.578: Temp sub net mask: 0.0.0.0
*Mar 1 07:09:13.578: DHCP Lease server: 0.0.0.0, state: 8 Purging
*Mar 1 07:09:13.578: DHCP transaction id: FCC10C
*Mar 1 07:09:13.578: Lease: 0 secs, Renewal: 0 secs, Rebind: 0
secs
*Mar 1 07:09:13.578: No timer running
*Mar 1 07:09:13.578: Retry count: 0 Client-ID:
cisco-139.3.45.5-BRI0/0:1
*Mar 1 07:10:18.866: %ISDN-6-DISCONNECT: Interface BRI0/0:1
disconnected from 5272034 , call lasted 120 seconds *Mar 1
07:10:18.918: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to down
*Mar 1 07:10:18.922: %DIALER-6-UNBIND: Interface BR0/0:1 unbound from
profile D i1
************************************************************************
*****
********************

I also did a deb dhcp on R1, the dhcp server, but got nothing at all.

Here's R4's config. R4 is the dhcp client and is suppose to get an ip
address assigned to it dialer interface.

interface Dialer1
 ip address negotiated
 encapsulation ppp
 dialer pool 1
 dialer string 5272035
 dialer caller 5272035 callback

Here's R5's config:

ip dhcp-server 139.3.15.1

interface Dialer1
 ip address 139.3.45.5 255.255.255.0
 encapsulation ppp
 dialer pool 1
 dialer string 5272034
 dialer-group 1
 peer default ip address dhcp

Here's R1's config. R1 is the dhcp server.

ip dhcp excluded-address 139.3.45.5 139.3.45.255
ip dhcp excluded-address 139.3.45.0 139.3.45.3
!
ip dhcp pool FOR-R4
   network 139.3.45.0 255.255.255.0

Here's the topology:

R4 --- isdn ---- R5 --- f/r --- R1

I'm not running any routing protocols, but R5 and R1 can ping each
other.

R5 can call R4. When it does, R4 takes the call, hangup, and calls R5
back. But, once the call is connected, R4 and R5 still can't ping each
other. A debug on R5 shows the pings are "unroutable". I don't know
why since, of course, R4 and R5 are directly connected via the isdn
link.

Can anybody help me understand what's going on here with dhcp and the
ping problem?

Thanks for any insight.

Tim



This archive was generated by hypermail 2.1.4 : Thu Dec 02 2004 - 06:57:39 GMT-3