<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 03/04/2013 04:54 PM, Alan DeKok
wrote: </div>
<blockquote cite="mid:5134C3CE.5000002@deployingradius.com"
type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
I have to do that, this is cable IP network that i am talking about.
Real life example.<br>
I am using Cisco CMTS and his primary interface IP as
cable-helper/relay IP.<br>
<br>
This is by desing.<br>
I am sorry for my bad english but i will try to explain, please
bare with me...<br>
<br>
This is CM/CPE bundle interface:<br>
<br>
interface Bundle1.150<br>
vrf forwarding vrf_name<br>
ip address public_ip 255.255.255.240 secondary<br>
ip address private_ip 255.255.192.0<br>
no ip unreachables<br>
no cable arp<br>
cable source-verify dhcp<br>
cable helper-address radius_ip<br>
end<br>
<br>
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)<br>
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.<br>
<br>
<b>i have it already working that way with another dhcp server, in
production.</b><b><br>
</b><b>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.</b><br>
<br>
Let us say that i have two pools for CPE devices, imaginary:<br>
200.200.200.0/28<br>
200.200.100.0/28<br>
<br>
In that case i will have two lines in bundle interface setup:<br>
ip address 200.200.200.1 255.255.255.240 secondary<br>
ip address 200.200.100.1 255.255.255.240 secondary<br>
<br>
and this is relay_ip (primary ip address of bundle interface)<br>
ip address 10.10.10.1 255.255.192.0<br>
<br>
If dhcp finds free address from first pool (200.200.200.10/28) offer
will be somethink like this:<br>
<br>
giaddr: 200.200.200.1<br>
yiadd: 200.200.200.10<br>
OPTION: 1 ( 4) Subnet mask 255.255.255.240<br>
...<br>
<br>
<b>but offer still needs to be sent to 10.10.10.1</b>, where
requests came from in the first place.<br>
<br>
I didn't break anything, i have to do it that way.<br>
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.<br>
If offer goes to any other address Cisco ASA will drop that packet
because it doesn't have it in initiated/established chains...<br>
<br>
Next time CPE tries to renew/release address request will come from
10.10.10.1 again...<br>
<br>
That is why i said that relay_ip shouldn't be replaced with giaddr.<br>
<br>
FR i am using is 2.2.0, latest stable version.<br>
<br>
i will try to send debug info tomorrow AM CET...<br>
</body>
</html>