[j-nsp] M7i DHCP Relay

[Chuck Anderson]

On Thu, Aug 12, 2010 at 02:17:14AM -0700, Kaj Niemi wrote:
> On 12/8/2010 12:01, "sthaug at nethelp.no" <sthaug at nethelp.no> wrote:
> 
> > We have tested these two commands, both in daily build versions of
> > JunOS and in 10.0S7.1 where it is implemented. These commands seem to
> > do the job, even if they don't solve all of our problems.
> 
> What other problems remain? Just curious ;-)
> 
> > I doubt you'll get unnumbered to work with helpers bootp - I believe
> > you need the infrastructure from dhcp-relay to work with unnumbered.
> 
> I tried with IRB + no-local-switching + relay-agent-option instead of
> unnumbered + bootp helper. On IRB DHCP requests are forwarded from CPE ->
> BRAS -> DHCP server but when the MX receives the offer from the DHCP server
> it goes all emo while parsing the Option 82 response and obviously doesn't
> forward it to the CPE.

I've just installed an MX960 with all bridge-domains and IRB to 
replace a "Layer 3 switch" core router in an enterprise campus LAN 
environment.  I was surprised at how broken basic stateless DHCP Relay 
functionality was and the hoops I had to jump through to get it to 
work at all in my LAN environment.

On JUNOS 10.2R1 with Trio cards (argh, R2 came out a day after I 
deployed!):

The BOOTP Helper (stateless DHCP Relay Agent functionality configured 
under forwarding-options helpers bootp) fails to forward DHCP Replies 
from the DHCP Server back to the DHCP Client unless the MX is 
configured with DHCP Option 82 support via the relay-agent-option 
statement.  Additionally, if you have an edge switch adding it's own 
DHCP Option 82 information (for example an EX4200 L2 edge switch), 
then this extra Option 82 added by the L2 edge switch interferes with 
the operation of the MX BOOTP Helper, causing it to also fail to 
forward DHCP Replies from the DHCP Server back to the DHCP Client, 
even if the MX960 is configured with the relay-agent-option statement.

There are two issues here:

1. MX shouldn't require Option 82 (relay-agent-option) in order to 
function as a stateless DHCP Relay Agent (BOOTP Helper), but it does.

2. MX shouldn't get confused and fail to function when the edge switch 
has added it's own DHCP Option 82 information to the packet.

So as a result of these issues, we've had to disable our EX4200 DHCP 
Option 82 support in order to get DHCP working at all, and because of 
this we can no longer track and log the locations of our DHCP clients.

This really really sucks.  So much so that I wouldn't be averse to 
setting up a Linux box with dhcrelay on it with all my VLANs trunked 
into it to replace the MX as DHCP Relay.

My question is, should I attempt to use the stateful DHCP Relay 
subscriber management feature?  Is it any better with respect to 
Option 82 handling?  I have shied away from this because I really 
didn't want to have a stateful DHCP Relay in the core and because of 
the rumors (confirmed earlier in this thread) that it interferes with 
unicast DHCP renewals on unrealted logical interfaces.