> On Jul 29, 2017, at 8:43 AM, Nathan Lannine <[email protected]> wrote:
> 
>>> The issue is the 4500 stamps the relay agent IP in the DISCOVER as
>>> being the incoming interface IP where the DISCOVER was received,
> 
> Yeah, that's expected and required behavior.  I sort of assumed, as
> Mr. Mayer indicated, that the "global" option would still set the
> giaddr to the receiving vrf gateway address, but set the source to
> some address in the global table.

It does indeed work as you expect, and the server tries to send the OFFER to 
the giaddr, which is not reachable from the global table because the giaddr is 
in a (different) VRF.

> It never occurred to me that a dhcp server would not support this behavior.

Perhaps there is a DHCP server setting to send OFFER/ACK/etc to the source IP 
of the received packet instead, and just use the giaddr to signal the server 
which subnet to allocate an IP from...

> We accomplish this with intervrf routing and leave out the "global"
> option, which keeps the discovers/requests in the vrf and sourced from
> the vrf gateway address.

Today, we do this using ISC DHCP with multiple interfaces, and each interface 
is in whatever VRF (or global) it is required to be in, in order to provide 
reachability from the server back to the client.  It’s all fine and good.  We 
are looking to move to a commercial appliance, but unfortunately these 
appliance don’t support multiple interfaces, so I’m faced with either buying 
one appliance per VRF, or finding a way to collapse multiple relays all 
existing in different VRFs into one.  I’m having success finding the hooks to 
do this on some platforms (ME3600), but not others (4500).

> _______________________________________________
> cisco-nsp mailing list  [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list  [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to