From: Edwards, Andrew M (andrew.m.edwards@boeing.com)
Date: Mon Nov 08 2004 - 20:25:53 GMT-3
Brian,
Myself I have not labbed this up. I will tonight after I finish the
current lab I'm on... I see IPCP being used for R4 to negotiate the IP
address for R5 via DHCP. What I'm interested in seeing now (tonight...)
is if the DHCP negotiation is done before R5 dials, or each time R5
dials. Seeing is how the default peer ip address is set by R4 via DHCP,
it would also seem that this negotiation could take place before hearing
from R5 in the first place.... IOW, R4 says, "If I am asked during IPCP
to get an IP address for whatever peer calls me, I'll use this one I
already got from DHCP."
I'll know more by tomorrow.
-----Original Message-----
From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
Sent: Monday, November 08, 2004 1:25 PM
To: ccie2be; ccielab@groupstudy.com
Subject: RE: dhcp and address negotiation over an isdn link
Tim,
I don't see why you're making the distinction nor how it affects
the scenario. The below config works as well:
R4#
interface BRI0/0
ip address 45.0.0.4 255.0.0.0
ip helper-address 34.0.0.3
ip router isis
encapsulation ppp
dialer map ip 45.0.0.5 broadcast 5272025
dialer-group 1
isdn switch-type basic-ni
isdn spid1 5272024
peer default ip address dhcp
R5#
interface BRI0/0
ip address negotiated
encapsulation ppp
dialer map ip 45.0.0.4 broadcast 5272024
dialer-group 1
isdn switch-type basic-ni
isdn spid1 5272025
Whether the address results in a direct BOOTP request, as on an
Ethernet interface, or through the IPCP stage of PPP, the address is
still obtained from a DHCP pool. The reason I mention a dialup client
is that their address is assigned through IPCP. Does this mean that
dial-up clients are not using DHCP?
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
________________________________________
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Monday, November 08, 2004 2:34 PM
To: Brian McGahan; ccielab@groupstudy.com
Subject: Re: dhcp and address negotiation over an isdn link
Thanks Brian,
That link confirms what I thought - that R5 is doing dhcp proxy client
on behalf of R4. It is NOT acting as a dhcp relay agent that just
forwards dhcp discover messages from R4 to the dhcp server.
* DHCP retrieved IP address-If configured, the routers acts as a proxy
client for the dialup user and retrieves an IP address from a DHCP
server. That address is returned to the DHCP server when the timer
expires or when the interface goes down.
Also, see this link:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/
fipr_c/ipcprt1/1cfdhcp.htm#xtocid2
where it says,
The Cisco IOS DHCP client now enables you to obtain an IP address from a
DHCP Server dynamically using the DHCP protocol as specified in RFC
2131. In Cisco IOS Release 12.2, only Ethernet interfaces are supported;
work is in progress to support all interface types. The Cisco IOS DHCP
client offers the following benefits:
Since R4's isdn interface isn't supported as a dhcp client as of IOS
12.2, we now know that R4 is NOT and can NOT be a dhcp client.
Regarding what happens when a PC dials into an ISP, I don't know the
details or the sequence of what exactly happens. I know that with
Windows based PC's, if the check box, Obtain IP address Automatically,
isn't checked, dialup connections usually don't work.
Thanks again. It's feel good to finally have this issue sorted out.
----- Original Message -----
From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
To: "ccie2be" <ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
Sent: Monday, November 08, 2004 2:09 PM
Subject: RE: dhcp and address negotiation over an isdn link
When you have a PC with dial-up access to an ISP, is it a DHCP client?
Just because the actual address exchange occurs during the IPCP phase of
PPP negotiation does not mean the device is not a client of DHCP.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/
fdial_c/fnsprt9/dcdppp.htm#1001245
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: Monday, November 08, 2004 12:04 PM
> To: Brian McGahan; ccielab@groupstudy.com
> Subject: Re: dhcp and address negotiation over an isdn link
>
> Thanks for your response.
>
> So, then it's true that dhcp is only taking place, in your example,
> between the dhcp server and R5, but, technically, NOT over the isdn
> link.
Over
> the
> isdn link IPCP is the mechanism used to provide an ip address to the
> remote side of the isdn link and therefore we shouldn't expect to see
> any
dhcp
> messages crossing the isdn link. Thus, to be technically precise, R4
is
> NOT
> a dhcp client even though it's address does, in fact, come from a dhcp
> server. True?
>
> So, in this example, from a dhcp perspective, what is R5's role? It's
not
> a
> dhcp client because it's not getting an ip address for itself. It's
> obviously not a dhcp server. It's not a dhcp relay agent because it's
not
> getting a dhcp request from R4 and then forwarding the request to the
dhcp
> server. That only leaves a dhcp proxy client, but yet the command, ip
> address-pool dhcp-proxy-client, isn't needed for this process to work.
Is
> that because the command, peer default ip address dhcp, is configured
on
> R5's bri interface and that command automatically makes the dhcp
discover
> request on R4's behalf?
>
> On the other hand, we should see dhcp messages from the dhcp server to
R5
> and once R5 has a dhcp provided ip address for R4, R5 uses IPCP to
provide
> that address to R4.
>
> Thanks for bearing with me on this. Hopefully, you see I've taken
Brain
> Dennis's advice to heart and I'm not trying to memorize this stuff as
much
> as I'm trying to learn what's really going on.
>
> Tim
>
>
> ----- Original Message -----
> From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
> To: "ccie2be" <ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
> Sent: Monday, November 08, 2004 11:35 AM
> Subject: RE: dhcp and address negotiation over an isdn link
>
>
> > From that output below it's clear that ip address negotiation is
> taking
> > place and that it results in R5 getting an address. But, from that
> > output, why should I think that dhcp is part of the process between
> > R5 and
R4?
> It
> > looks like IPCP negotiation, not dhcp negotiation.
>
> The assignment occurs through IPCP. However, the address that is
> assigned is retrieved from a remote DHCP pool.
>
> > One last point/question: Couldn't R4 be configured in such a way,
for
> > example, with a local pool of addresses that R4 could provide remote
> hosts
> > with ip addresses without ever using dhcp?
>
> You can use a local pool (peer default ip address pool), a local dhcp
> pool (peer default ip address dhcp-pool) or just a specific address
> (peer default ip address 1.2.3.4).
>
>
> HTH,
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
> 24/7 Support: http://forum.internetworkexpert.com
> Live Chat: http://www.internetworkexpert.com/chat/
>
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > ccie2be
> > Sent: Friday, November 05, 2004 10:02 PM
> > To: Brian McGahan; Edwards, Andrew M; ccielab@groupstudy.com
> > Subject: Re: dhcp and address negotiation over an isdn link
> >
> > Thanks Brain,
> >
> > From that output below it's clear that ip address negotiation is
> taking
> > place and that it results in R5 getting an address. But, from that
> > output, why should I think that dhcp is part of the process between
> > R5 and
R4?
> It
> > looks like IPCP negotiation, not dhcp negotiation.
> >
> > True, I see that the ip address provided to R5 is the ip address set
> up on
> > the dhcp server for R5, but if R5 is a dhcp client doesn't it HAVE
TO
> send
> > a
> > dhcp discover message to R4 which then, it turn, forwards the
request
> to
> > the
> > dhcp server?
> >
> > And, when I run a debug dhcp on R4 (the dhcp relay agent), shouldn't
I
> see
> > the dhcp request from R5 being received by R4 and then forwarded to
> the
> > dhcp
> > server? In the debug dhcp from R4 (that I posted earlier), there
were
> no
> > dhcp messages being shown; either dhcp messages from R5 to R4 or
dhcp
> > messages being forwarded from R4 to the dhcp server.
> >
> > One last point/question: Couldn't R4 be configured in such a way,
for
> > example, with a local pool of addresses that R4 could provide remote
> hosts
> > with ip addresses without ever using dhcp? I'm fuzzy on the details
> but I
> > had the impression that since ppp installs a host route for the
remote
> > side
> > of the link, ppp can do it's thing and not need dhcp to supply ip
> > addresses for the remotes calling in. Am I anywhere close to being
> > correct
> about
> > this?
> >
> > Thanks again, Tim
> >
> > ----- Original Message -----
> > From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
> > To: "ccie2be" <ccie2be@nyc.rr.com>; "Edwards, Andrew M"
> > <andrew.m.edwards@boeing.com>; <ccielab@groupstudy.com>
> > Sent: Friday, November 05, 2004 6:25 PM
> > Subject: RE: dhcp and address negotiation over an isdn link
> >
> >
> > Tim,
> >
> > The output is there, you're just looking at the wrong debug. You
> > should be looking at the PPP negotiation, as seen in my previous
> > post.
> >
> > The below is from R5's perspective, the DHCP client
> >
> > *Mar 1 21:13:16.034: BR0/0:1 IPCP: O CONFREQ [Closed] id 1 len 10
> > *Mar 1 21:13:16.038: BR0/0:1 IPCP: Address 0.0.0.0
> (0x030600000000)
> >
> > R5 to R4: I have no address, please give me one
> >
> > *Mar 1 21:13:16.050: BR0/0:1 IPCP: I CONFNAK [ACKsent] id 1 len 10
> > *Mar 1 21:13:16.050: BR0/0:1 IPCP: Address 45.0.0.5
> (0x03062D000005)
> >
> > R4 to R5: How about 45.0.0.5?
> >
> > *Mar 1 21:13:16.050: BR0/0:1 IPCP: O CONFREQ [ACKsent] id 2 len 10
> > *Mar 1 21:13:16.054: BR0/0:1 IPCP: Address 45.0.0.5
> (0x03062D000005)
> >
> > R5 to R4: Mmmm.... okay
> >
> > *Mar 1 21:13:16.062: BR0/0:1 IPCP: I CONFACK [ACKsent] id 2 len 10
> > *Mar 1 21:13:16.062: BR0/0:1 IPCP: Address 45.0.0.5
> (0x03062D000005)
> >
> > R4 to R5: It's all yours
> >
> > *Mar 1 21:13:16.062: BR0/0:1 IPCP: State is Open
> > *Mar 1 21:13:16.066: BR0/0 IPCP: Install negotiated IP interface
> > address 45.0.0.5
> >
> > R5: 45.0.0.5 is my address now
> >
> >
> >
> > HTH,
> >
> > Brian McGahan, CCIE #8593
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987 x 705
> > Outside US: 775-826-4344 x 705
> > 24/7 Support: http://forum.internetworkexpert.com
> > Live Chat: http://www.internetworkexpert.com/chat/
> >
> >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
Behalf
> > Of
> > > ccie2be
> > > Sent: Friday, November 05, 2004 5:05 PM
> > > To: Edwards, Andrew M; ccielab@groupstudy.com
> > > Subject: Re: dhcp and address negotiation over an isdn link
> > >
> > > Andy,
> > >
> > > According to Brain McGahan, we're barking up the wrong tree.
> > >
> > > As you can see, I'm still trying to fit all the pieces together
but
> > I'm
> > > sure
> > > I don't have the complete picture or some of the info I'm hearing
> > isn't
> > > 100%
> > > correct. It's always hard to know.
> > >
> > > Anyway, contrary to what I described before, Brain tells me that,
in
> > fact,
> > > R4 is a dhcp client and negotiate it's ip address via ppp's ipcp.
> > >
> > > Maybe it's terminology, but here's the problem I'm having with
this.
> > >
> > > If R4 is, in fact, a dhcp client, then once the link comes up,
> > shouldn't
> > > R4
> > > send to R5 a dhcp discover message?
> > >
> > > Looking again at the debug dhcp output from R5, the lnk is up, but
> > there's
> > > no dhcp discover message.
> > >
> > > ********************************************
> > >
> > > For those of you just joining this thread, here's the basic setup.
> > >
> > > R4 --- isdn ---- R5 ----- R1
> > >
> > > R4's dialer int is configured with encap ppp and ip address
> > negotiated.
> > >
> > > R5's dialer int is configured with encap ppp and peer default ip
> > address
> > > dhcp and the global command, ip dhcp-server <ip addr>.
> > >
> > > R1 is the dhcp server. It's connected to R5 directly via f/r.
> > >
> > > At this point, no routing is configured, so after R1 gets a dhcp
> > request,
> > > it
> > > wouldn't know how to respond as it doesn't know about the subnet
> > > connecting R4 and R5 over the isdn link.
> > >
> > > ************************************************
> > >
> > > The problem is that once the isdn link comes up, R4 never gets an
ip
> > > address
> > > assigned to it's dialer interface. Now, even though R1 without
> > routing
> > > configured, can't respond to a dhcp request, it should still
recieve
> > the
> > > requests. However, a debug dhcp on R1 shows that R1 never recieves
a
> > dhcp
> > > request.
> > >
> > > I'm trying to figure why and where in the process things are going
> > wrong.
> > > If you scroll down to the first post of this thread, you can see
the
> > debug
> > > dhcp output from R5 after the link comes. Notice, there's no
> > indication
> > > that R5 is gettting a dhcp request from R4.
> > >
> > > If what Brain says about R4 being a dhcp client is really true,
> > shouldn't
> > > we
> > > see in R5's debug dhcp output, a dhcp request from R4?
> > >
> > > Let me know what you think.
> > >
> > > Thanks, 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:13 PM
> > > Subject: RE: dhcp and address negotiation over an isdn link
> > >
> > >
> > > Well, I guess its kind of caveat emptor...
> > >
> > > But, I think between the two of us we've nailed this one.
> > >
> > > With R4 being negotiate, R5 has to be setup for both ip
dhcp-server
> > and
> > > ip dhcp-proxy.
> > >
> > > If R4 were an ip add dhcp-client though... R5 would need
> > helper-address.
> > >
> > > Of course, its blind leading the blind here... But I do know a bit
> > about
> > > DHCP. 8)
> > >
> > >
> > > -----Original Message-----
> > > From: ccie2be [mailto:ccie2be@nyc.rr.com]
> > > Sent: Friday, November 05, 2004 12:16 PM
> > > To: Edwards, Andrew M; ccielab@groupstudy.com
> > > Subject: Re: dhcp and address negotiation over an isdn link
> > >
> > >
> > > Hi Andrew,
> > >
> > > I was thinking about what you said below about using the command,
ip
> > > address-pool dhcp-proxy-client. And, it made me wonder if I was
> > > thinking about this all wrong.
> > >
> > > Initially, I was thinking that once the link between R4 and R5
came
> > up,
> > > R4 because it has ip address negotiated configured on it becomes a
> > dhcp
> > > client and therefore would send out a dhcp request.
> > >
> > > But, maybe this is wrong because R4 is connecting to R5 via PPP
and
> > > using PPP to negotiate an ip address. In other words, R4 isn't a
> > really
> > > dhcp client so it doesn't send out a dhcp request for an address.
> > >
> > > But, now, looking at R5's configuration. It has the interface
> > command,
> > > peer default ip address dhcp, on it's Dialer interface which means
> it
> > > should use dhcp to get and assign an ip address to R4 when it gets
a
> > > dhcp request from R4. But, because R4 isn't really (or rather R4
> > > doesn't consider itself) a dhcp client, R4 never sends a dhcp
> request.
> > >
> > > Therefore, for R5 to get an ip address for R4, it must send a dhcp
> > > request on R4's behalf to the dhcp server and that's why the
global
> > > command, ip address-pool dhcp-proxy-client, is needed.
> > >
> > > Realize that I'm completely making this up, but it seems
plausible.
> > Am
> > > I getting warm?
> > >
> > > Thanks, 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:40 GMT-3