Router – DHCP relay on Juniper MX

dhcpjuniperjuniper-junosjuniper-mxrouter

Hi I got a problem with bootp relay on a juniper router(s).
I got helpers bootp interface configured with:
irb.10
broadcast
server 10.20.1.10
server 10.20.1.11

theres several irb insterfaces in the configuration with the same settings.

If I start another DHCP server with the IP 10.20.1.14 it will get DHCP DISCOVERY too and sending offers and some ACK. I thought these setting would only send DHCP request to the servers listed.
So I tried with removing the broadcast line on all interfaces but then the real DHCP server only ACK some requests, so some request wasnt coming to the DHCP server.

I have tried finding the documentation for the broadcast setting but I could find any that explains it in detail.

I also tried with dhcp-relay settings but that doesnt work att all probably because that I cant specifiy the irb interfaces in the group interface option.

Does anyone know why the DHCP server with an IP that isnt specified in the server option gets DISCOVERY messages, i think this is because the broadcast option.

And how can I configure dhcp-relay to work, I tried with group interface xe-0/0/3 (the physical interface to the switch thats connected to the acces switch)

Best Answer

DHCP/BootP is Broadcast Traffic by definition.

The DHCP Relay / IP Helper configuration can only be used to forward request from hosts NOT on the same physical network as the DHCP Servers to the DHCP Servers (at least in the Router).

If you configure a DHCP Relay on a switch the DHCP relay agent can in some instances be smart enough to, if they have an SVI to associate the MAC to IP for the DHCP server, direct the broadcast message even in the same segment, so that only the DHCP Servers configured in the Relay receive the DHCP request.

Otherwise any time you send a DHCP hello request it will be answered by any DHCP server in the same segment.

Options you might consider if you need these DHCP servers to be doing separate things:

Segregate the DHCP Serving interfaces onto their own network segment and configure DHCP Relay for them appropriately.

Move only the DHCP server you don;t want to answer locally in the network segment to a separate network segment (either it's own with it's own relay or a vlan where local clients should receive it's reply.)

Set up separate DHCP ranges on several VLAN interfaces on each server so that each sever only responds to the appropriate local network (And do away with DHCP relay on the router)

Note that IRB on the other hand simpley allows the device to bridge local connections at Layer 2 instead of routing them at Layer 3, so any Devices in 10.20.1.x could be bridged directly as applicable (ie this doesn't really have anything to do with DHCP per-se, except as it allows the local broadcasts to flood both vlans rather limiting the usefulness of having separate segments)

Essentially the IRB is a second IP address in each VLAN / Net Segment, that the switch will forward all packets destined for the other vlan segment through to allow both to communicate with each other by bridging (the switch makes a direct connection between the devices and no routing needs to take place).

Long Story Short (too Late)

I'm fairly sure that the broadcast command allows the broadcasts in one vlan to flood the other and vice verse, so if the DHCP server is set up in one it will get requests from both. (Which I believe fits exactly the behavior of the issue that you are trying to describe above.)

As such, what I believe you need to do is:

Set up your IRB to have 1 IP in each subnet.
Not to use the broadcast switch.
Set up your DHCP relay ONLY for the vlan which DOES NOT have the DHCP server on it.

This should send a directed message to the DHCP server as a unicast message via the relay, which will then match your IRB, so this will happen as a bridging action.

Related Solutions

SRX DHCP client compatibility with HP Procurve DHCP Relay

I opened a case with HP concerning this issue. After escalating past the useless Level 1 tech, the Level 2 tech very alertly spotted something that I had not.

The SRX is sending its DHCPDISCOVER packet with a TTL of 1. The Procurve's apparently will decrement the TTL and use the resulting TTL in the relay'ed packet to the DHCP server. In this case, the decrement leaves the TTL at 0 meaning the packet gets dropped on the floor.

This is actually in spec for DHCP/BOOTP relay, though clearly it causes reduced interoperability. I have asked HPNetworking to treat this as a bug/RFE and change the behavior. No immediate response to that request in the case.

The SRX sending the DHCPDISCOVER with a TTL of 1 is also probably within spec, but, again, a choice of reduced interoperability, so I plan to open a case with JTAC on the same basis.

I'll add more info on the response of Juniper and HP as it becomes available.

Incidentally, I have tested the relay behavior of a Cisco 4506 (firmware version not immediately available), and a Brocade/Foundry FastIron Edge X (7.2 or 7.3 firmware, I believe, don't have immediate access to confirm) and they both handle relaying the request with TTL 1 without issue.

UPDATE There is a way to change the TTL value that the SRX uses on its DHCP requests, but its not from within the JunOS cli...its done from the underlying Unix OS.

root@% sysctl -w net.inet.ip.mcast_ttl=64

I have opened an RFE with HP to make their relaying function more resilient, but not response from them yet on if/when that will be worked on.

DHCP packets – aren’t they always supposed to be broadcasted

DHCP packets - aren't they always supposed to be broadcasted?

No, DHCP offers can be sent as unicast or broadcast. The layer-3 address doesn't really matter if it is unicast or broadcast because the frame is being delivered on the LAN by the layer-2 address.

From RFC 2321, Dynamic Host Configuration Protocol (emphasis mine):

In the case of a client using DHCP for initial configuration (before the client's TCP/IP software has been completely configured), DHCP requires creative use of the client's TCP/IP software and liberal interpretation of RFC 1122. The TCP/IP software SHOULD accept and forward to the IP layer any IP packets delivered to the client's hardware address before the IP address is configured; DHCP servers and BOOTP relay agents may not be able to deliver DHCP messages to clients that cannot accept hardware unicast datagrams before the TCP/IP software is configured.

To work around some clients that cannot accept IP unicast datagrams before the TCP/IP software is configured as discussed in the previous paragraph, DHCP uses the 'flags' field [21]. The leftmost bit is defined as the BROADCAST (B) flag. The semantics of this flag are discussed in section 4.1 of this document. The remaining bits of the flags field are reserved for future use. They MUST be set to zero by clients and ignored by servers and relay agents. Figure 2 gives the format of the 'flags' field.
                              1 1 1 1 1 1
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |B|             MBZ             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          B:  BROADCAST flag
          MBZ:  MUST BE ZERO (reserved for future use)
          Figure 2:  Format of the 'flags' field

Best Answer

Related Solutions

SRX DHCP client compatibility with HP Procurve DHCP Relay

DHCP packets – aren’t they always supposed to be broadcasted

Related Topic