From: NITIN NITIN (ccie_study_123@yahoo.com)
Date: Sat Aug 25 2007 - 13:37:34 ART
Hi ,
Its working :)....but last time I tried it didn't worked .....
Rack1R4#sh ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 204.12.1.4 YES NVRAM up up
FastEthernet1/0 139.1.48.4 YES NVRAM up up
Serial2/0 unassigned YES NVRAM administratively down down
Serial2/1 139.1.45.4 YES IPCP up up <<<<<<<<
Serial2/2 unassigned YES NVRAM administratively down down
Serial2/3 unassigned YES NVRAM administratively down down
Loopback0 150.1.4.4 YES NVRAM up up
Rack1R4#sh run int se 2/1
Building configuration...
Current configuration : 113 bytes
!
interface Serial2/1
ip address negotiated
ip rip advertise 3
encapsulation ppp
serial restart-delay 0
end
Rack1R1#debug ip dhcp server packet
Rack1R1#
*Aug 25 22:01:37.154: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d31.3339.2e31.2e34.352e.352d.5365.7269.616c.322f.31 through relay 139.1.45.5.
*Aug 25 22:01:37.154: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d31.3339.2e31.2e34.352e.352d.5365.7269.616c.322f.31 (139.1.45.4).
*Aug 25 22:01:37.158: DHCPD: unicasting BOOTREPLY for client ca01.0b00.0000 to relay 139.1.45.5.
*Aug 25 22:01:37.386: DHCPD: DHCPREQUEST received from client 0063.6973.636f.2d31.3339.2e31.2e34.352e.352d.5365.7269.616c.322f.31.
*Aug 25 22:01:37.386: DHCPD: Sending DHCPACK to client 0063.6973.636f.2d31.3339.2e31.2e34.352e.352d.5365.7269.616c.322f.31 (139.1.45.4).
Rack1R1#
*Aug 25 22:01:37.390: DHCPD: unicasting BOOTREPLY for client ca01.0b00.0000 to relay 139.1.45.5.
Rack1R1#sh ip dhc
Rack1R1#sh ip dhcp b
Rack1R1#sh ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type
Hardware address/
User name
139.1.45.4 0063.6973.636f.2d31. Aug 26 2007 10:01 PM Automatic
3339.2e31.2e34.352e.
352d.5365.7269.616c.
322f.31
Bit Gossip <bit.gossip@chello.nl> wrote:
the problem with this setup is that R1 receives the request sourced from
139.1.45.5 and so also it replies to this address; but as the link R4R5 is
still not up R1 has no route to 139.1.45.5 and so drops the packet.
*Mar 2 07:25:50.556: DHCPD: DHCPDISCOVER received from client
0063.6973.636f.2d31.3339.2e31.2e34.352e.352d.5365.7269.616c.302f.31 through
relay 139.1.45.5.
*Mar 2 07:25:50.556: DHCPD: Allocate an address without class information
(139.1.45.0)
*Mar 2 07:25:52.556: DHCPD: Sending DHCPOFFER to client
0063.6973.636f.2d31.3339.2e31.2e34.352e.352d.5365.7269.616c.302f.31
(139.1.45.4).
*Mar 2 07:25:52.556: DHCPD: unicasting BOOTREPLY for client 0014.6a0a.5c00
to relay 139.1.45.5.
A trivial solution is a static on R1 for 139.1.45.5 but this is probably not
accepted
The way I solved this is to nat on R1 139.1.45.5 -> 139.1.15.5. R1 then has
a route to 139.1.15.5 and so R5 can relay the offer to R4. This seems to
work:
On R1
*Mar 2 07:25:52.688: DHCPD: unicasting BOOTREPLY for client 0014.6a0a.5c00
to relay 139.1.45.5.
*Mar 2 07:25:52.688: NAT: o: udp (139.1.15.1, 67) -> (139.1.45.5, 67) [75]
*Mar 2 07:25:52.688: NAT: s=139.1.15.1, d=139.1.45.5->139.1.15.5 [75]
R1#show run int s0/0
interface Serial0/0
ip address 139.1.15.1 255.255.255.0
ip nat inside
encapsulation frame-relay
clock rate 128000
frame-relay map ip 139.1.15.5 105 broadcast
no frame-relay inverse-arp
!
interface Loopback0
ip address 150.1.1.1 255.255.255.255
ip nat outside
!
ip nat inside source static 139.1.15.5 139.1.45.5
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
R4(config)#int s0/1
R4(config-if)#no shut
<....>
*Mar 2 07:42:13.444: Se0/1 IPCP: Address 139.1.45.4 (0x03068B012D04)
*Mar 2 07:42:13.444: Se0/1 IPCP: O CONFREQ [ACKsent] id 3 len 10
*Mar 2 07:42:13.444: Se0/1 IPCP: Address 139.1.45.4 (0x03068B012D04)
*Mar 2 07:42:13.448: Se0/1 IPCP: I CONFACK [ACKsent] id 3 len 10
*Mar 2 07:42:13.448: Se0/1 IPCP: Address 139.1.45.4 (0x03068B012D04)
*Mar 2 07:42:13.448: Se0/1 IPCP: State is Open
*Mar 2 07:42:13.448: Se0/1 IPCP: Install negotiated IP interface address
139.1.45.4
*Mar 2 07:42:13.452: Se0/1 IPCP: Install route to 139.1.45.5
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Maybe the best way would be to convince R5, the relay agent, to source the
relied packets not from 139.1.45.5 which is the flapping interface, but from
another interface like lo0 which is stable. I couldn't figure out a way to
this though.......
Bit.
----- Original Message -----
From: "Keith Bizzell"
To: "ISolveSystems"
Cc: ; "Cisco certification"
Sent: Friday, August 24, 2007 1:28 PM
Subject: Re: peer default ip address dhcp
>I agree, and I can never get this section to work. I don't have a problem
> with the routing, either:
>
> Rack1R1#show ip route 139.1.45.0
> Routing entry for 139.1.45.0/24
> Known via "ospf 1",......
>
> When I bounce the interface for R4, here's what I get on R1:
>
> Rack1R1#
> *Aug 24 11:45:28.588: DHCPD: Adding binding to radix tree (139.1.45.4)
> *Aug 24 11:45:28.588: DHCPD: Adding binding to hash tree
> *Aug 24 11:45:28.588: DHCPD: assigned IP address 139.1.45.4 to client
> 0063.6973.....etc,etc.etc
>
> I keep getting this on R4, and I can't figure it out for the life of me:
>
> Rack1R4(config-if)#
> *Aug 24 11:45:29.092: Se0/1/0 IPCP: ID 7 didn't match 9, discarding packet
>
> This should be simple, but it's driving me nuts. I've verified my
> configuration against the solution guide about 50 times.
>
> On 8/23/07, ISolveSystems wrote:
>>
>> Yes, this works, but this doesn't meet the IE workbook requirement of
>> using
>> R1 as the DHCP server.....
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Sep 01 2007 - 11:32:13 ART