13.7 DHCP Proxy - issues with GNS3?

I wasn't able to get the solution to work as shown in the solution guide.  Debugs on the DHCP server showed that it was receiving the request and that it was unicasting the DHCPOFFER to R3, but R3 never received the offer.  However, when I added "ip helper-address 155.1.146.6" to the serial interface, then it all worked.  I was using 3725 routers with 12.4(15)T10.  Anybody get this to work as shown in the SG using GNS3?

Comments

  • Hi

    I believe this is an issue with GNS. My Solution in Dynamips is not working if i use exact same solution provided by SG.

    We need to understand that the Volume-1 Solution has been written keeping in mind the real Routers, while dynamips/GNS can have some bugs and can behave anomalously.

    As far as solution is concerned to make this work, I used the command "ip dhcp relay information option" which as per Cisco doc, automatically adds the circuit identifier suboption and the remote ID suboption to the DHCP relay agent information option (also called option 82). This made the solution working however Task 13.8 asks the DHCP information option to use as a separate Task. 

    "ip helper-address" is one of the ways of using a DHCP Relay agent. So if you use this command, then there is no need for a DHCP Relay agent command to use, i.e. "ip address-pool dhcp-proxy-client" & "ip dhcp-server 155.1.146.6".

    Hope this helps.

    Regards,

     

    Muhammad

  • I don't think it's just a dynamips issue, I have real hardware that closely matches the INE hadware, and I am unable to get this solution to work. Maybe it's an IOS version problem, I'm running c1841-adventerprisek9-mz.124-24.T3.bin on R4 - R6, and c2600-adventerprisek9-mz.124-19.bin on R1- R3.

     

    Has anyone been able to get this to work as per the solution guide?

     

    Jason

  • I am using the real gears, I could not able to make it to work as per SG.

    I also tried to put the "ip helper address" on R3's s1/3 but it is still not working.

    It seems R3 could not pass the leased ip address to R2 and kept retrying as shown below:

    Mar  2 12:06:12.973: DHCP: SDiscover attempt # 2 for entry:
    *Mar  2 12:06:12.973: Temp IP addr: 0.0.0.0  for peer on Interface: Serial1/3
    *Mar  2 12:06:12.973: Temp  sub net mask: 0.0.0.0
    *Mar  2 12:06:12.973:    DHCP Lease server: 0.0.0.0, state: 1 Selecting
    *Mar  2 12:06:12.973:    DHCP transaction id: 1FB7
    *Mar  2 12:06:12.973:    Lease: 0 secs,  Renewal: 0 secs,  Rebind: 0 secs
    *Mar  2 12:06:12.977:    Next timer fires after: 00:00:04
    *Mar  2 12:06:12.977:    Retry count: 2   Client-ID: cisco-155.1.23.3-Serial1/3
    *Mar  2 12:06:12.977:    Client-ID hex dump: 636973636F2D3135352E312E32332E33
    *Mar  2 12:06:12.977:                        2D53657269616C312F33
    Rack1R3(config-if)#
    *Mar  2 12:06:12.981:    Hostname: Rack1R3
    *Mar  2 12:06:12.981: DHCP: SDiscover: sending 292 byte length DHCP packet
    *Mar  2 12:06:12.981: DHCP: SDiscover 292 bytes
    *Mar  2 12:06:12.981:             B'cast on FastEthernet0/0 interface from 155.1.23.3

     

    INE staff, please take a look and advise.

    Thanks

  • Exactly the same issue, real lab.

    Also noticed;

    *Jan  4 20:41:37.096: DHCP: XID did NOT MATCH in dhcpc_for_us()

     

  • i faced the same problem ...but when i did shut and unshut  again on my R2 router ( GNS) i got 10.1.23.1 address...which i excluded i thought might be it got offered eralier...so i removed eveything and tried again ..this time exclusion first the POOL i created

     

    but same result 10.1.23.1 to R2 i don't under stand why is this happening ..but yaa i was able to make it work ..and one more thins i think wee ned to do "peer neighbour-route" bcoz i was getting  the address as /32 so i am unable ping R3 so i did peer neighbour route- i  got the reachibility..

     

    here is  few debugs...

     

    DHCP: SDiscover attempt # 2 for entry:
    *Mar  1 00:09:47.559: Temp IP addr: 0.0.0.0  for peer on Interface: Serial1/2
    *Mar  1 00:09:47.563: Temp  sub net mask: 0.0.0.0
    *Mar  1 00:09:47.563:    DHCP Lease server: 0.0.0.0, state: 3 Selecting
    *Mar  1 00:09:47.567:    DHCP transaction id: EF
    *Mar  1 00:09:47.567:    Lease: 0 secs,  Renewal: 0 secs,  Rebind: 0 secs
    *Mar  1 00:09:47.571:    Next timer fires after: 00:00:04
    *Mar  1 00:09:47.575:    Retry count: 2   Client-ID: cisco-10.1.23.3-Serial1/2
    *Mar  1 00:09:47.575:    Client-ID hex dump: 636973636F2D31302E312E32332E332D
    *Mar  1 00:09:47.575:                        53657269616C312F32

     

    f-----recived packet from R4 ( i  made R4 as my server )

     

    DHCP: Scan: Rebind time: 75600
    *Mar  1 00:10:43.839: DHCP: Scan: Subnet Address Option: 255.255.255.0
    *Mar  1 00:10:43.839: DHCP: rcvd pkt source: 10.1.146.4,  destination:  10.1.23.3
    *Mar  1 00:10:43.839:    UDP  sport: 43,  dport: 43,  length: 308
    *Mar  1 00:10:43.839:    DHCP op: 2, htype: 1, hlen: 6, hops: 0

     

    recived the offer message


    *Mar  1 00:10:43.839: DHCP Offer Message   Offered Address: 10.1.23.1
    *Mar  1 00:10:43.839: DHCP: Lease Seconds: 86400    Renewal secs:  43200    Rebind secs:   75600
    *Mar  1 00:10:43.839: DHCP: Server ID Option: 10.1.146.4
    *Mar  1 00:10:43.843: DHCP: offer received from 10.1.146.4

     

    finallyproxy client pooling allocating the address :))

     


    *Mar  1 00:10:43.903: DHCP Ack Message
    *Mar  1 00:10:43.903: DHCP: Lease Seconds: 86400    Renewal secs:  43200    Rebind secs:   75600
    *Mar  1 00:10:43.907: DHCP: Server ID Option: 10.1.146.4
    *Mar  1 00:10:43.911: DHCP Proxy Client Pooling: ***Allocated IP address: 10.1.23.1

     

     

     

  • this is not dynamips issue.

    it is caused by the command in 13.6 "no peer neighbor-route".

    dont know why INE folks added this command there.

  • jsnmngwn, I am getting the same issue as you just described. I have exactly same topology and hardware as per INE. This doesn't seem to be an dynamips only issue.

  • Hi...

    I'm using real gear too, and got exactly the same error as described above. It has nothing to do with "no peer neighbor-route" though, but it is an issue with the way R3 acts as a DHCP client on behalf of R2. When I take a "shut" and "no shut" on R2's serial s0/0/1 interface, I see from the "debug dhcp det" output on R3 that it sends several DISCOVERY message up to R6. R6 again sees these messages and sends a reply to each DISCOVERY message.

    When R3 sends a DHCP Discovery message, it assigns an ID to each single request from R2 (XID). This is to prevent duplicate IP assignments to pending requests from clients. When R3 gets the "DHCP OFFER" packets from R6, it is unable to match the XID with any of the pending requests R3 has on behalf of R2 but one. That's why you will receive the "DHCP: offer received in bad state: Purging" message and several "DHCP: XID did NOT MATCH in dhcpc_for_us()" messages. One XID will match though; "DHCP: XID MATCH in dhcpc_for_us()", but somehow R3 is not able to send that down to R2 for some reason. (maybe because it got confused with all the XID's etc).

    Try this to solve the problem:

    R6
    -----
    Rack1R6#clear ip dhcp binding *
    Rack1R6#delete flash:dhcp_binding

    R3
    -----
    Rack1R3(config)#ip dhcp-server query lease retries 1
    Rack1R3(config)#ip dhcp-server query lease timeout 10

    R2
    -----
    Rack1R2(config-if)#shut
    Rack1R2(config-if)#no shut


    By doing this, you will force R3 to only send 1 DHCP Discovery message and wait up to 10 seconds before it times out. It worked for me!!!! Yeahhh.....

  • Anyone can clarify this? rbrathen workaround didn't work for me - I'm still unable to have R2 get any IP:

     

    Apr 25 05:25:00.919:    Hostname: Rack1R3
    Apr 25 05:25:00.919: DHCP: new entry. add to queue, interface Serial1/3
    Apr 25 05:25:00.919: DHCP: SDiscover attempt # 1 for entry:
    Apr 25 05:25:00.919: Temp IP addr: 0.0.0.0  for peer on Interface: Serial1/3
    Apr 25 05:25:00.919: Temp  sub net mask: 0.0.0.0
    Apr 25 05:25:00.923:    DHCP Lease server: 0.0.0.0, state: 1 Selecting
    Apr 25 05:25:00.923:    DHCP transaction id: 1BD2
    Apr 25 05:25:00.923:    Lease: 0 secs,  Renewal: 0 secs,  Rebind: 0 secs
    Apr 25 05:25:00.923:    Next timer fires after: 00:00:04
    Apr 25 05:25:00.923:    Retry count: 1   Client-ID: cisco-155.1.23.3-Serial1/3
    Apr 25 05:25:00.923:    Client-ID hex dump: 636973636F2D3135352E312E32332E33
    Apr 25 05:25:00.927:                        2D53657269616C312F33

     

    R6 keeps sending BOOTREPLIES to R3 but R2 can't manage to get an IP:

     

    Apr 25 05:30:38.591: DHCPD: Sending notification of DISCOVER:
    Apr 25 05:30:38.591:   DHCPD: htype 1 chaddr 0011.2027.a080
    Apr 25 05:30:38.591:   DHCPD: remote id 020a00009b01920600000092
    Apr 25 05:30:38.591:   DHCPD: circuit id 00000000
    Apr 25 05:30:38.595: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d31.3535.2e31.2e32.332e.332d.5365.7269.616c.312f.33 through relay 155.1.23.3.
    Apr 25 05:30:38.595: DHCPD: Seeing if there is an internally specified pool class:
    Apr 25 05:30:38.595:   DHCPD: htype 1 chaddr 0011.2027.a080
    Apr 25 05:30:38.595:   DHCPD: remote id 020a00009b01920600000092
    Apr 25 05:30:38.595:   DHCPD: circuit id 00000000
    Apr 25 05:30:38.595: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d31.3535.2e31.2e32.332e.332d.5365.7269.616c.312f.33 (155.1.23.2).
    Apr 25 05:30:38.595: DHCPD: unicasting BOOTREPLY for client 0011.2027.a080 to relay 155.1.23.3

    Rack1R6#sh deb
    DHCP server packet debugging is on.
    DHCP server event debugging is on.

    the following output confirms R6 has a binding for R2, however those username looks strange to me:

    Rack1R6#sh ip dhcp bin
    Bindings from all pools not associated with VRF:
    IP address          Client-ID/              Lease expiration        Type
                        Hardware address/
                        User name
    155.1.23.2          0063.6973.636f.2d31.    Apr 25 2011 05:43 AM    Automatic
                        3535.2e31.2e32.332e.
                        332d.5365.7269.616c.
                        312f.33

     

    Did someone managed to get this task working?

  • Not working at all here too :-()

  • I got this to work, using GNS3.

    *Mar  1 01:27:24.435: DHCP: rcvd pkt source: 155.1.146.6,  destination:  155.1.23.3
    *Mar  1 01:27:24.439:    UDP  sport: 43,  dport: 43,  length: 308
    *Mar  1 01:27:24.439:    DHCP op: 2, htype: 1, hlen: 6, hops: 0
    *Mar  1 01:27:24.443:    DHCP server identifier: 155.1.146.6
    *Mar  1 01:27:24.443:         xid: 671, secs: 0, flags: 0
    *Mar  1 01:27:24.443:         client: 0.0.0.0, your: 155.1.23.2
    *Mar  1 01:27:24.447:         srvr:   0.0.0.0, gw: 155.1.23.3
    *Mar  1 01:27:24.451:         options block length: 60

    Sometimes flapping the interface is necessary before being assigned an address.

  • Can somebody please post the full config for a working solution to this task?

     

     

  • I was re-doing this task today and I've got a working solution to the problem (for version 5.019 of the workbook). My solution doesn't require any static routing, so it's more likely to be accepted under lab exam conditions. It's also the only one I've managed to get working, despite all of the alternatives offered in the above posts.

     

    The key was to keep 155.1.23.0 /24 advertised while the link was down. The solution was a Loopback with the ip address 155.1.23.3/24 configured on R3 and configuring the interface connecting to R2 with 'ip unnumbered' referencing the Loopback. Hence, the network is always advertised even when the serial interface is down.

    Router 2 also requires the 'no validate-update-source' command under router rip if you want to maintain routing, as per the previous task 13.6 on R1.

     

    Here's the full config:

     

    Rack1R2
    !
    interface Serial0/0/1
     description LINK TO R3
     ip address negotiated
     encapsulation ppp
     no peer neighbor-route
     exit
    !
    router rip
     no validate-update-source
    end
    !


    Rack1R3
    !
    ip address-pool dhcp-proxy-client
    ip dhcp-server 155.1.146.6
    !
    interface Serial0/1/1
     description LINK TO R2
     ip unnumbered Loopback23
     encapsulation ppp
     no peer neighbor-route
     peer default ip address dhcp
     exit
    !
    interface Loopback23
     description KEEP NET_23 ADVERTISED WHEN LINK TO R2 IS DOWN
     ip address 155.1.23.3 255.255.255.0
    end
    !

     
    Rack1R6
    !
    ip dhcp excluded-address 155.1.23.1
    ip dhcp excluded-address 155.1.23.3 155.1.23.255
    !
    ip dhcp pool NETWORK-23
       network 155.1.23.0 255.255.255.0
    end
    !
     

     

  • Looks like a great solution. Always good to have different solutions to a specific problem. Thanks for sharing.

    Good luck!

  • Great work David.Kelsen.!  That was the fix.

  • the problem is actualy the routing from R6 back to R3... R6 points to R1 with the static /24 route..

    Rack1R6#sh ip cef 155.1.23.3


    155.1.23.0/24

      nexthop 155.1.146.1 FastEthernet0/0.146


    so.. where does R1 point to..



    Rack1R1#sh ip cef 155.1.23.3

    155.1.23.0/24, version 890, epoch 0, cached adjacency 155.1.0.3

    0 packets, 0 bytes

      via 155.1.13.3, 0 dependencies, recursive

        next hop 155.1.0.3, Serial0/0:0 via 155.1.13.0/24

        valid cached adjacency



    okay.. out the frame relay..



    Rack1R1#sh frame-relay map | inc 155.1.0.3

    Serial0/0:0 (up): ip 155.1.0.3 dlci 105(0x69,0x1890), static,

    Rack1R1#




    To R5....so it gets the packet inn from R1.. witch is going to 155.1.23.3.. where does it point that ?



    Rack1R5#sh ip cef 155.1.23.3

    0.0.0.0/0

      no route

    Rack1R5#



    so.. lets ping from R6.. and debug on R5



    Rack1R6#ping 155.1.23.3


    Type escape sequence to abort.

    Sending 5, 100-byte ICMP Echos to 155.1.23.3, timeout is 2 seconds:

    U.U.U

    Success rate is 0 percent (0/5)

    Rack1R6#




    R5


    *Jan 19 11:27:34.008: IP: s=155.1.146.6 (Serial0/0/0:0), d=155.1.23.3, len 100, input feature, MCI Check(64), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

    *Jan 19 11:27:34.008: IP: s=155.1.146.6 (Serial0/0/0:0), d=155.1.23.3, len 100, unroutable

    *Jan 19 11:27:34.008: ICMP: dst (155.1.23.3) host unreachable sent to 155.1.146.6

    *Jan 19 11:27:34.008: IP: s=155.1.0.5 (local), d=155.1.146.6 (Serial0/0/0:0), len 56, sending

    *Jan 19 11:27:34.008: IP: s=155.1.0.5 (local), d=155.1.146.6 (Serial0/0/0:0), len 56, sending full packet



    ...


    but.. what happens if we enable  peer neighbor-route between R3 and R1.. so R1 gets next hop out Serial0/1..



    Rack1R1(config)#int ser0/1

    Rack1R1(config-if)#peer neighbor-route

    Rack1R1(config-if)#shu

    Rack1R1(config-if)#shutdown


    *Jan 13 14:17:56.414: %LINK-5-CHANGED: Interface Serial0/1, changed state to administratively down

    *Jan 13 14:17:57.415: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to down

    Rack1R1(config-if)#no shutdown



    lets look at R1 cef table again..





    Rack1R1#sh ip cef 155.1.23.3

    155.1.23.0/24, version 890, epoch 0, cached adjacency to Serial0/1

    0 packets, 0 bytes

      via 155.1.13.3, 0 dependencies, recursive

        next hop 155.1.13.3, Serial0/1 via 155.1.13.3/32

        valid cached adjacency

    Rack1R1#



    Great! looks better :)


    and lets try the DHCP proxy again..


    Rack1R2(config-if)#no shutdown



    *Jan 13 14:52:01.052: Se0/1 IPCP: O CONFREQ [Closed] id 1 len 10

    *Jan 13 14:52:01.052: Se0/1 IPCP:    Address 0.0.0.0 (0x030600000000)

    *Jan 13 14:52:01.052: Se0/1 CDPCP: O CONFREQ [Closed] id 1 len 4

    *Jan 13 14:52:01.052: Se0/1 PPP: Process pending ncp packets

    *Jan 13 14:52:01.052: Se0/1 CDPCP: I CONFREQ [REQsent] id 1 len 4

    *Jan 13 14:52:01.056: Se0/1 CDPCP: O CONFACK [REQsent] id 1 len 4

    *Jan 13 14:52:01.056: Se0/1 IPCP: I CONFREQ [REQsent] id 1 len 10

    *Jan 13 14:52:01.056: Se0/1 IPCP:    Address 155.1.23.3 (0x03069B011703)

    *Jan 13 14:52:01.056: Se0/1 IPCP: O CONFACK [REQsent] id 1 len 10

    *Jan 13 14:52:01.056: Se0/1 IPCP:    Address 155.1.23.3 (0x03069B011703)

    *Jan 13 14:52:01.060: Se0/1 CDPCP: I CONFACK [ACKsent] id 1 len 4

    *Jan 13 14:52:01.060: Se0/1 CDPCP: State is Open

    *Jan 13 14:52:02.048: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up-if)#

    Rack1R2(config-if)#

    *Jan 13 14:52:02.468: Se0/1 IPCP: I CONFNAK [ACKsent] id 1 len 10

    *Jan 13 14:52:02.468: Se0/1 IPCP:    Address 155.1.23.2 (0x03069B011702)

    *Jan 13 14:52:02.468: Se0/1 IPCP: O CONFREQ [ACKsent] id 2 len 10

    *Jan 13 14:52:02.468: Se0/1 IPCP:    Address 155.1.23.2 (0x03069B011702)

    *Jan 13 14:52:02.476: Se0/1 IPCP: I CONFACK [ACKsent] id 2 len 10

    *Jan 13 14:52:02.476: Se0/1 IPCP:    Address 155.1.23.2 (0x03069B011702)

    *Jan 13 14:52:02.476: Se0/1 IPCP: State is Open

    *Jan 13 14:52:02.476: Se0/1 IPCP: Install negotiated IP interface address 155.1.23.2

    Rack1R2(config-if)#





    better :) so the problem was that R6 got the request.. but the reply didnt get back to R3...

  •  rbrathen's solution worked great for me.

Sign In or Register to comment.