Re: [j-nsp] M7i DHCP Relay
This is supposedly fixed in PR/523902 which is resolved in 10.2R2 10.3R1 10.1R3 10.0R4 10.4R1. It includes two hidden commands which should allow the forwarding of DHCP traffic on interfaces that are not configured for DHCP (when using dhcp-relay or dhcp-local-server). I haven't had the time to test it out yet. 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. On another note, does anyone have unnumbered and helpers bootp working on MX? All I can coax out of them is request from 0.0.0.0 if ge-1/0/3.2070 no useful gateway address in fud log with maximum logging, show helper statistics claiming the reason being Due to no valid local address: and incrementing drop counters. There's a ticket open on that, too. I doubt you'll get unnumbered to work with helpers bootp - I believe you need the infrastructure from dhcp-relay to work with unnumbered. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] M7i DHCP Relay
On Thu, Aug 12, 2010 at 02:17:14AM -0700, Kaj Niemi wrote: On 12/8/2010 12:01, sth...@nethelp.no sth...@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. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] M7i DHCP Relay
On 12/8/2010 15:33, Chuck Anderson c...@wpi.edu wrote: 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. On IRB, I *think* it must have relay-agent-option because it seems like it wants to write the interface name in the Option 82 packet no matter what and if the helper is stateless by itself it must somehow be able to figure out where (what interface) to return the packet to... With stateful dhcp relay that isn't an issue. I think it does count licensing wise (1 address = 1 subscriber license)? Kaj ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] M7i DHCP Relay
On Thu, Aug 12, 2010 at 06:20:38AM -0700, Kaj Niemi wrote: On 12/8/2010 15:33, Chuck Anderson c...@wpi.edu wrote: 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. On IRB, I *think* it must have relay-agent-option because it seems like it wants to write the interface name in the Option 82 packet no matter what and if the helper is stateless by itself it must somehow be able to figure out where (what interface) to return the packet to... Yes, that is what it does. However, my old Layer 3 switch had no such need to maintain the state in Option 82. It just relayed via the GIADDR which is already in every BOOTP/DHCP packet... Why can't the MX lookup the GIADDR in the DHCP packet and send the response out the interface that is assigned the GIADDR's IP address? Every other router or switch I've seen does this and has been doing this for decades. BOOTP/DHCP isn't exactly a new protocol to have to know how to get right. With stateful dhcp relay that isn't an issue. I think it does count licensing wise (1 address = 1 subscriber license)? Hopefully not, or Juniper may be supplying free subscriber licenses for us. We shouldn't have to pay for a working DHCP Relay Agent. If Juniper is serious about the Enterprise market, they need to fix some things. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] M7i DHCP Relay
Hi, This is supposedly fixed in PR/523902 which is resolved in 10.2R2 10.3R1 10.1R3 10.0R4 10.4R1. It includes two hidden commands which should allow the forwarding of DHCP traffic on interfaces that are not configured for DHCP (when using dhcp-relay or dhcp-local-server). I haven't had the time to test it out yet. On another note, does anyone have unnumbered and helpers bootp working on MX? All I can coax out of them is request from 0.0.0.0 if ge-1/0/3.2070 no useful gateway address in fud log with maximum logging, show helper statistics claiming the reason being Due to no valid local address: and incrementing drop counters. There's a ticket open on that, too. Kaj On 18/3/2010 21:26, sth...@nethelp.no sth...@nethelp.no wrote: Yes. This is a serious bug which basically makes M/MX routers unusable if you want to have DHCP relay agent functionality *on the router* at the same time as you have other DHCP unicast traffic (for instance generated by a Cisco CPE with ip helper, or a client sending its renewal request directly to the DHCP server) passing *through* the router. I find it absolutely incredible that Juniper with its ERX history has managed to botch the M/MX DHCP functionality this badly. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] M7i DHCP Relay
I am trying to get DHCP relay working using either [forwarding-options dhcp-relay] or [forwarding-options helpers bootp] on an M7i w/IQ2 ethernet running 9.6R1.13. I have several double-tagged and single tagged vlans on interface ge-0/0/3 and am wanting to do relay on several double-tagged units that are unnumbered to lo0.0. The bootp helper doesn't seem to forward/relay any requests if the interface is unnumbered - it works fine if the interface has an IP. DHCP-relay seems to effect all of the units on ge-0/0/3 even though I only specify a certain unit to operate on. Yes. This is a serious bug which basically makes M/MX routers unusable if you want to have DHCP relay agent functionality *on the router* at the same time as you have other DHCP unicast traffic (for instance generated by a Cisco CPE with ip helper, or a client sending its renewal request directly to the DHCP server) passing *through* the router. I find it absolutely incredible that Juniper with its ERX history has managed to botch the M/MX DHCP functionality this badly. Verified with 9.5R4.3 and 10.0R2.10. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
