SRX

Hi,

I'm attempting to use an SRX300 to front my FiOS home Internet connection.

FiOS is very particular about the DHCP request from the CPE and essentially option 61 is supposed to look like 0x01 (hardware type Ethernet) plus the MAC address.

The legacy DHCP subsystem correctly sets this with the following command:

set interfaces ge-0/0/0 unit 0 family inet dhcp client-identifier hexadecimal 01aabbccddeeff

The above properly generates the option 61 client-id and Verizon will happily respond with a DHCP lease.

The equivalent JDHCP configuration is supposed to be:

set interfaces ge-0/0/0 unit 0 family inet dhcp-client client-identifier user-id hexadecimal 01aabbccddeeff

Unfortunately the JDHCP client is prefixing the data with the interface name (ie ge-0/0/0.0) no matter what hex or ASCII value is supplied. This is causing Verizon to ignore the DHCPDISCOVER because it doesn't recognize the option 61 field created by JDHCP. This is confirmed behavior in the following JunOS versions I've tried:

* 15.1X49-D45

* 15.1X49-D75.5
* 15.1X49-D100.6

Is there any way to make JDHCP behave like the legacy DHCP client for option 61? I've attached screenshots of the highlighted option 61 fields in Wireshark for two DHCPDISCOVER packets from ge-0/0/0.0 on my SRX300 - one with the legacy DHCP client, the other with JDHCP.

Thanks.

Hello, John!

I saw your post on Juniper NSP and was quite curious whether you ever saw resolution offline. I guess not. Quite an interesting ask you've got. I'll admit, this one piqued my interest so I decided to lab it up. It just so happens I have a SRX300 to play with.

I reviewed your screenshots (thanks, they're a huge help). I have good news and bad news. First, the bad news. I can most definitely replicate your issue. In my lab I'm running the following.

root@FIOS_Quantum_Gateway# run show version
Hostname: FIOS_Quantum_Gateway
Model: srx300
Junos: 15.1X49-D60.7
JUNOS Software Release [15.1X49-D60.7]

Now, the good news. I used the following config, and my PCAP looks very close to what you asked for.

root@FIOS_Quantum_Gateway# show interfaces ge-0/0/0
description "DHCP Client";
mac 48:d5:36:34:35:97;
unit 0 {
    description 01aabbccddeeff;
    family inet {
        dhcp-client {
            client-identifier {
                use-interface-description logical;
            }
        }
    }
}

[edit]
root@FIOS_Quantum_Gateway#

Here's the PCAP screenshot for your review.

A bit of a "hack" for sure.. What do you think? Does it meet your needs?

Hi Raymond,

Thanks for taking the time to lab up and respond. Much appreciated!

Unfortunately what I'm after is the option 61 field looking like it does in the dhcpd.jpg but using JDHCP and not the legacy DHCP subsystem - if you look you can see that Wireshark correctly parses the 0x01 value and translates it to hardware type Ethernet, then it parses the client MAC address.

In the JDHCP screenshot, you can see that Wireshark just sees the length and nothing else.

If you look inside the payload (in the dhcpd.jpg screenshot) you can see the following value:

=..H]645.

While in the JDHCP screenshot it looks like:

=.=.:ge-0/0/0.0:.H]645.

Essentially I do not want this prefix at all. This is what's causing Verizon to ignore the DHCPDISCOVER. Why JDHCP takes it upon itself to use this prefix is beyond me and it would be nice to turn it off.

EDIT: I see that since you've set the prefix to the interface description (which is blank the hex value) that the interface name prefix goes away - but, as you can see, Wireshark still does not correctly parse it, so I doubt Verizon would take it either.

I've been struggling with JTAC over this for the last week, with NO understanding or solution.

Once the Australian NBN access nw fully rolls out, there will be thousands of orphaned SRXen

and a lot of angry customers who will abandon Juniper CPE (and maybe the bigger boxes too).

I'm beginning to suspect Juniper has a death wish.

Hi @luddite - sorry to hear about this.

How far up the chain has the case been escalated?

I am glad to know that I'm not the only one that's finding this behavior to be undesirable. I wonder if they've based JDHCP off of some open source server or if they've completely recreated it in-house.

@luddite I'm all for pitchforks when due. Seeing as this is repeatable behavior, I'll be more than happy to put in a JTAC and escalate as well. Feel free to PM me your JTAC case so I can request the information be reviewed.

That said, the RFC perhaps has a different opinion on the handling of client identifiers. Though I agree it'd be nice to have the option to disable the interface being included in the client identifier message, it seems Juniper is within the guidelines. As a matter of fact, according to the RFC we shouldn't be using the client id contents more than a unique id. Regarding the second bolded sentence, it's possible Juniper is using the interface as a way to ensure it complies to uniqueness requirements. Only they know on that one.

 DHCP defines a new 'client identifier' option that is used to pass an
   explicit client identifier to a DHCP server.  This change eliminates
   the overloading of the 'chaddr' field in BOOTP messages, where
   'chaddr' is used both as a hardware address for transmission of BOOTP
   reply messages and as a client identifier.  The 'client identifier'
   is an opaque key, not to be interpreted by the server; for example,
   the 'client identifier' may contain a hardware address, identical to
   the contents of the 'chaddr' field, or it may contain another type of
   identifier, such as a DNS name.  The 'client identifier' chosen by a
   DHCP client MUST be unique to that client within the subnet to which
   the client is attached. If the client uses a 'client identifier' in
   one message, it MUST use that same identifier in all subsequent
   messages, to ensure that all servers correctly identify the client.

Source: https://www.ietf.org/rfc/rfc2131.txt

I'll keep testing in the lab and let you know if I come up with something solid.

@jjensen Are you willing to try a few configs for me and see how Verizon responds? I've got the format closer to the original seen in your stream, removing the ge-0/0/0 again. Personally test 3 and 4 are the closest in my opinion. Also, did you ever happen to capture the conversation when using the actual Verizon modem? I'd be curious of its format as well.

Test 1

root@FIOS_Quantum_Gateway# show interfaces ge-0/0/0 | display set
set interfaces ge-0/0/0 mac 48:5d:36:34:35:97
set interfaces ge-0/0/0 unit 0 description FIOS_Quantum_Gateway
set interfaces ge-0/0/0 unit 0 family inet dhcp client-identifier user-id hexadecimal 01485d36343597
set interfaces ge-0/0/0 unit 0 family inet dhcp client-identifier use-interface-description logical
set interfaces ge-0/0/0 unit 0 family inet dhcp retransmission-attempt 6
set interfaces ge-0/0/0 unit 0 family inet dhcp retransmission-interval 4
set interfaces ge-0/0/0 unit 0 family inet dhcp update-server
set interfaces ge-0/0/0 unit 0 family inet dhcp vendor-id FiOS-G1100:dslforum.org

[edit]
root@FIOS_Quantum_Gateway#

Result

Test 2

root@FIOS_Quantum_Gateway# show interfaces ge-0/0/0 | display set
set interfaces ge-0/0/0 mac 48:5d:36:34:35:97
set interfaces ge-0/0/0 unit 0 description "H]645"
set interfaces ge-0/0/0 unit 0 family inet dhcp client-identifier use-interface-description logical
set interfaces ge-0/0/0 unit 0 family inet dhcp retransmission-attempt 6
set interfaces ge-0/0/0 unit 0 family inet dhcp retransmission-interval 4
set interfaces ge-0/0/0 unit 0 family inet dhcp update-server
set interfaces ge-0/0/0 unit 0 family inet dhcp vendor-id FiOS-G1100:dslforum.org

[edit]
root@FIOS_Quantum_Gateway#

Result

Test 3

root@FIOS_Quantum_Gateway# show interfaces ge-0/0/0 | display set
set interfaces ge-0/0/0 mac 48:5d:36:34:35:97
set interfaces ge-0/0/0 unit 0 description "H]645 FIOS_Quantum_Gateway"
set interfaces ge-0/0/0 unit 0 family inet dhcp client-identifier use-interface-description logical
set interfaces ge-0/0/0 unit 0 family inet dhcp retransmission-attempt 6
set interfaces ge-0/0/0 unit 0 family inet dhcp retransmission-interval 4
set interfaces ge-0/0/0 unit 0 family inet dhcp update-server
set interfaces ge-0/0/0 unit 0 family inet dhcp vendor-id FiOS-G1100:dslforum.org

[edit]
root@FIOS_Quantum_Gateway#

Result

Test 4

root@FIOS_Quantum_Gateway# show interfaces ge-0/0/0 | display set
set interfaces ge-0/0/0 mac 48:5d:36:34:35:97
set interfaces ge-0/0/0 unit 0 description .
set interfaces ge-0/0/0 unit 0 family inet dhcp client-identifier use-interface-description logical
set interfaces ge-0/0/0 unit 0 family inet dhcp retransmission-attempt 6
set interfaces ge-0/0/0 unit 0 family inet dhcp retransmission-interval 4
set interfaces ge-0/0/0 unit 0 family inet dhcp update-server
set interfaces ge-0/0/0 unit 0 family inet dhcp vendor-id FiOS-G1100:dslforum.org

[edit]
root@FIOS_Quantum_Gateway#

Hey Raymond,

While I can understand wanting to duplicate what's seen in the stream, I'm as close as you can get to 100% certain that setting the interface description to the ASCII representation of the byte string ("=..H]645.") seen in the Wireshark dissection and trying to pass that as an option 61 string just isn't going to work.

I have a pair of EX2200-C's at home that I can use to route the connection from the ONT into a VLAN in order to do some mirroring, but it's late and I'm not feeling up to it at the moment.

I did have the SRX connected to the ONT (FiOS doesn't really have a "modem" as the underlying transport is GPON/BPON) - the only thing I was able to note is that with the JDHCP config, the box would not obtain a DHCP lease. When I on-the-fly converted the box back to legacy DHCP while it was still connected, it obtained the lease in a snap.

 EDIT: and sure, Juniper is within the RFC bounds, but it's not clear why the decision was made to mangle the option 61 in the way they did compared to the original legacy DHCP client-id, which worked just fine

EDIT2: this KB article says that the two commands should be functionally equivalent and they're obviously not. 🙂

Just in-case anyone wants to know,

the underlying reasons for all this are well described in

RFC 3046  DHCP Relay Agent Information Option https://tools.ietf.org/html/rfc3046

The galling thing is that it's an MX at the other end of the wire.

Hey @luddite - any updates from JTAC on this problem/your case?

I'm thinking about submitting my own case and also referencing yours (a couple SRX300's I got for work have their own support contracts with them). EDIT: just kidding, these don't have service contracts attached to them, only warranty RMA. **bleep**.

Thanks,

-JJ

Hi All,

Was there any update on this? We're having the same issue with Australian NBN, DHCP, We are on SRX 300 with firmware 15.1X49-D130

Thanks!

hello,

We have the same problem here.

We have found a workaround not ideal but...

We call the ISP and we ask for the ip assign to the device. After, in the Internet interface, we configure a static ip and we activate the configuration. After, we remove the ip and change the configuration to DHCP and active the configuration.

After that, the internet work on the unit. The SRX seen to save the ip somehow.

Same here,  SRX 300 with firmware 15.1X49-D130.

I really hope that this will be fixed as soon as possible. There is no known device, at least to me (including TPLink and ZTE, all known and unknown devices) that is not able to tackle with client-identifier functionalities.

There are a couple of Telco/ISP's which relies on that functionality.

However, D140 has been released few days ago, do someone have tested it how does it behaves it this usecase ?

Was this ever solved?  I just got NBN HFC and have been tearing my hair out for hours trying to work out why my SRX220 will not get a DHCP address from the modem, while any other laptop/non-Juniper device works fine.  Frustrating for something trivial that non-enterprise devices will handle without issue.  Temporarily using a VeloCloud and it also handles it fine.

@synackray Pitchforks are not necessary, just enough noise so that

marketing/sales realize this is an issue.

It's just gone to L2 at JTAC.

Yes, the RFCs suggest client-id should be opaque,
but the real world usage in the non-enterprise is nearly alway

01 then MAC.

If we add into the mix an ISP/Telco DHCP server matching

options 82 and 61 (circuit-id/client-id) as a means of mapping

fixed/static address, we have slightly fragile process.

The introduction of JDHCP esp. dhcpv6-client PD was such a mess

that some of us are rather grumpy with Juniper.

There were/are the same sort of snafus with dhcp-local-server esp.

on EXs when dealing with wireless APs, most of which have not been fixed.

This actively lost Juniper business (to Fortinet) so I'm unhappy to see the SRX

CPE devices go the same way.

Too much complaining from a grumpy old SysEng,

Peter Cherny, luddite@luddite.com.au

I agree it does not parse the same in Wireshark. What does your dhcpd process look like in UDP stream format? Here's mine.

Just a heads up, I upgraded my SRX to the latest 17 code and replicated the same behavior.

root@FIOS_Quantum_Gateway# show version
## Last changed: 2017-09-05 10:52:36 UTC
version 17.3R1.10;

root@FIOS_Quantum_Gateway# show interfaces ge-0/0/0
description "DHCP Client";
mac 48:d5:36:34:35:97;
unit 0 {
    description 01aabbccddeeff;
    family inet {
        dhcp {
            client-identifier {
                use-interface-description logical;
            }
            vendor-id FiOS-G1100:dslforum.org;
        }
    }
}

[edit]
root@FIOS_Quantum_Gateway#

Hey Raymond.

Sure. See attached screenshot. I'm using the legacy DHCP subsystem. Here's my interface config:

set interfaces ge-0/0/0 mac 48:5d:36:34:35:97
set interfaces ge-0/0/0 unit 0 family inet dhcp client-identifier hexadecimal 01485d36343597
set interfaces ge-0/0/0 unit 0 family inet dhcp retransmission-attempt 6
set interfaces ge-0/0/0 unit 0 family inet dhcp retransmission-interval 4
set interfaces ge-0/0/0 unit 0 family inet dhcp update-server
set interfaces ge-0/0/0 unit 0 family inet dhcp vendor-id FiOS-G1100:dslforum.org