On 03/04/2013 04:54 PM, Alan DeKok wrote:
The point of asking for debug output is to see what the server is doing.
I'm not sure what the rest of your message means. The server defaults to copying the giaddr from the request to the reply. This is so that the reply can use the giaddr as the destination IP. If you use Perl to update the giaddr to something else... then the reply will be sent there.
I have to do that, this is cable IP network that i am talking about. Real life example. I am using Cisco CMTS and his primary interface IP as cable-helper/relay IP. This is by desing. I am sorry for my bad english but i will try to explain, please bare with me... This is CM/CPE bundle interface: interface Bundle1.150 vrf forwarding vrf_name ip address public_ip 255.255.255.240 secondary ip address private_ip 255.255.192.0 no ip unreachables no cable arp cable source-verify dhcp cable helper-address radius_ip end As you can see CMTS will relay all requests from CM's and CPE's over primary interface address (private_ip/255.255.192.0) radius will get all requests from that IP. all offers need to go back to that same ip, no matter what giaddr is sent to client. *i have it already working that way with another dhcp server, in production.** **also, couple of commercial products that i was testing had exactly the same logic implemented, all offers were sent to relay ip, no matter what was set as giaddr.* Let us say that i have two pools for CPE devices, imaginary: 200.200.200.0/28 200.200.100.0/28 In that case i will have two lines in bundle interface setup: ip address 200.200.200.1 255.255.255.240 secondary ip address 200.200.100.1 255.255.255.240 secondary and this is relay_ip (primary ip address of bundle interface) ip address 10.10.10.1 255.255.192.0 If dhcp finds free address from first pool (200.200.200.10/28) offer will be somethink like this: giaddr: 200.200.200.1 yiadd: 200.200.200.10 OPTION: 1 ( 4) Subnet mask 255.255.255.240 ... *but offer still needs to be sent to 10.10.10.1*, where requests came from in the first place. I didn't break anything, i have to do it that way. As far as dhcp server goes, it would be logical for him to return the offer to relay ip. relay will forward it to a client and client will get correct data. If offer goes to any other address Cisco ASA will drop that packet because it doesn't have it in initiated/established chains... Next time CPE tries to renew/release address request will come from 10.10.10.1 again... That is why i said that relay_ip shouldn't be replaced with giaddr. FR i am using is 2.2.0, latest stable version. i will try to send debug info tomorrow AM CET...