From: Bit Gossip (bit.gossip@chello.nl)
Date: Fri Aug 24 2007 - 17:54:18 ART
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" <mkbcoolman@gmail.com>
To: "ISolveSystems" <support@isolvesystems.com>
Cc: <bdennis@internetworkexpert.com>; "Cisco certification"
<ccielab@groupstudy.com>
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 <support@isolvesystems.com> 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