From: Henk de Tombe (henk.de.tombe@qi.nl)
Date: Fri Dec 31 2004 - 03:57:49 GMT-3
Hi Guys,
I've been following this topic with great interest (just like all other
topics) and would like to throw in another feature which can be enabled to
get an ip address for R4 from R1 via R5. With the command "ip address-pool
dhcp-proxy-client" under global config R1 acts as a DHCP proxy for incoming
PPP connections over a PPP link.
This command makes it possible to setup a flexible dialin solution because
you only need to configure "peer default ip address pool" on your dialer
interface. With the ip address pool dhcp-proxy-client command the router
looks for a configured ip dhcp server in the config. If it finds one it will
send a DHCP request to the DHCP server and proxy it back through via IPCP to
R4.
The above feature is running at some places I've been, and it's working fine
till now. I don't say that the above feature is the solution for LAB 13 (I
haven't got the book yet, I hope the mailman brings it to me in about a week
:-) but it's just another way to build a solution.
Regards,
Henk
Link to this feature is below:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fdia
l_r/drfeip.htm#wp1034924
-----Oorspronkelijk bericht-----
Van: nobody@groupstudy.com [mailto:nobody@groupstudy.com] Namens Andy Mrozek
Verzonden: donderdag 30 december 2004 18:41
Aan: Andy Mrozek
CC: Group study; ccielab@groupstudy.com
Onderwerp: Re: I E lab 13 - dhcp-server vs ip helper
peer ip default address
To specify an IP address, an address from a specific IP address pool, or an
address from the Dynamic Host Configuration Protocol (DHCP) mechanism to be
returned to a remote peer connecting to this interface, use the peer default
ip address command in interface configuration mode...
I think this also reinforces the theory that r5 is doing dhcp for the
requesting DDR connected neighbor and passing results back to r4 via ipcp
language....
Andy Mrozek wrote:
>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
>>
>>
>
>_______________________________________________________________________
>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:33 GMT-3