From: Andy Mrozek (AndyMrozek@yahoo.com)
Date: Thu Dec 30 2004 - 14:23:47 GMT-3
Tim,
Not that I am saying no to what Brian is saying as obviously he knows
this subject well, so I guess that is right .... to call it an
interpretation of terminology ... But I believe r5 is the dhcp client
not r4 if you watch the debugs on r1 the dhcp server for dhcp requests
coming in , he seems it all coming from r5 ... So I think the only
thing r4 is doing is the command <ip address negotiate > is r4 firing
up a process that uses the ipcp process/daemon if you will to call on
its directly called neighbor r5 to ask for help getting an address ,
between r4/r5 is ipcp , and during this negotiation r5 calls another
process which ip dhcp-server 1.1.1.1 and then sends a request and via
ipcp again sends it to r4 , the most important piece I have seen so far
is the fact that the dhcp server is seeing requests from r5........
Also the solution only shows using < ip dhcp-server > command not the ip
helper-address command , as you saw the other stuff I sent you ip
helper-address only works when you change r4 to ip address dhcp
client-id f0/0 ... So I believe unless seeing a working config that as
in Brians book ipcp requres the 3 commands:
ip address negotiate ---------> fires off call to ipcp to start
conversation with r5
peer default ip address dhcp -----------> talks to ipcp with r4 to call
local ip dhcp-server command
ip dhcp-server 1.1.1.1 ---------> makes normal dhcp request to set
configured server then if successfull hands result to ipcp process and
hands back to r4...
Brian McGahan wrote:
>Tim,
>
> We just went over this exact issue just recently. Look at the
>below posting.
>
>
>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: Brian McGahan
>Sent: Friday, November 05, 2004 5:25 PM
>To: 'ccie2be'; 'Edwards, Andrew M'; 'ccielab@groupstudy.com'
>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
>>
>>
>>
>>
>_______________________________________________________________________
>
>
>>Subscription information may be found at:
>>http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>_______________________________________________________________________
>
>
>>Subscription information may be found at:
>>http://www.groupstudy.com/list/CCIELab.html
>>
>>
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon Jan 03 2005 - 10:31:32 GMT-3