From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Mon Nov 08 2004 - 13:35:01 GMT-3
> 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