Bitstream 3a DHCP manipulation
Hi all I posted a few weeks ago about MAC limits on Bitstream 3a connections. This is related to that. This is a UFF Bitstream 3a connection. I've discovered that a customer's only complaint with a Bitstream 3a connection from us is that DHCP doesn't work over this. I've obtained some pcaps from both ends and I can see the following changes occurring to a DHCP Request: 1) The transaction ID is changed 2) Option 82 is added. More specifically, sub-option 1 Agent Circuit ID is present and has a valid length. sub-option 2 Agent Remote ID is present, has a length of 0 and no content which wireshark doesn't seem to like much. I've had a brief read of RFC3046 and I can't really tell if its valid to have a sub-option with a length of 0 or not. https://tools.ietf.org/html/rfc3046#page-8 I never see any DHCP ACKs coming back from the customer's DHCP server. I've had a read of some of UFF's Bitstream3a docs and can't see any mention of DHCP. I can see in one of our initial requests we had to fill out we can choose to have DHCP Relay Agent Functionality but this seems to be related to Bitstream2 only and also this defaults to be disabled. I don't know what DHCP server the customer is using right now but I hope to find this out soon. Questions for anyone with more experience in this than myself: -Can changing the DHCP Request transaction ID cause issues? -Has anyone come across DHCP servers not liking option 82 being set, or not liking sub-option 2 having a 0 length? -Has anyone successfully used DHCP across a Bitstream3a connection? How about a UFF Bitstream3a connection? -Am I missing anything obvious? Obviously I might end up talking to UFF over this but I just want to see what others on the list know before doing so. Again, I don't really want to debate the wisdom of plugging two LANs in over a Bitstream3a connection. Cheers Dave
Hi Dave,
So this is with the DHCP server on the customer (UNI) end of the BS3?
I remember back a few years ago we hit some software bugs getting this
working in the lab, and given it's an uncommon scenario (there's one (i
think?) other provider using it atm) I wouldn't be surprised if there's
more.
Would you mind sharing a pcap/diag off list?
Thanks,
Jed.
Sent from a small screen.
On 3/04/2014 4:52 pm, "Dave Mill"
Hi all
I posted a few weeks ago about MAC limits on Bitstream 3a connections. This is related to that. This is a UFF Bitstream 3a connection.
I've discovered that a customer's only complaint with a Bitstream 3a connection from us is that DHCP doesn't work over this. I've obtained some pcaps from both ends and I can see the following changes occurring to a DHCP Request:
1) The transaction ID is changed 2) Option 82 is added. More specifically, sub-option 1 Agent Circuit ID is present and has a valid length. sub-option 2 Agent Remote ID is present, has a length of 0 and no content which wireshark doesn't seem to like much.
I've had a brief read of RFC3046 and I can't really tell if its valid to have a sub-option with a length of 0 or not.
https://tools.ietf.org/html/rfc3046#page-8
I never see any DHCP ACKs coming back from the customer's DHCP server.
I've had a read of some of UFF's Bitstream3a docs and can't see any mention of DHCP. I can see in one of our initial requests we had to fill out we can choose to have DHCP Relay Agent Functionality but this seems to be related to Bitstream2 only and also this defaults to be disabled.
I don't know what DHCP server the customer is using right now but I hope to find this out soon.
Questions for anyone with more experience in this than myself: -Can changing the DHCP Request transaction ID cause issues? -Has anyone come across DHCP servers not liking option 82 being set, or not liking sub-option 2 having a 0 length? -Has anyone successfully used DHCP across a Bitstream3a connection? How about a UFF Bitstream3a connection? -Am I missing anything obvious?
Obviously I might end up talking to UFF over this but I just want to see what others on the list know before doing so.
Again, I don't really want to debate the wisdom of plugging two LANs in over a Bitstream3a connection.
Cheers Dave
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
Hi Jed
No, in this situation the clients are at the UNI end. The dhcp server is
off a switch of ours very close to the UFB SP handover.
When I get back to work tomorrow I'd be happy to share a limited amount of
the pcap. Just have to be careful as we were capturing everything on a
particular interface. Would a filtered pcap just showing DHCP packets
suffice?
Cheers
Dave
On Thu, Apr 3, 2014 at 6:46 PM, Jed Laundry
Hi Dave,
So this is with the DHCP server on the customer (UNI) end of the BS3?
I remember back a few years ago we hit some software bugs getting this working in the lab, and given it's an uncommon scenario (there's one (i think?) other provider using it atm) I wouldn't be surprised if there's more.
Would you mind sharing a pcap/diag off list?
Thanks, Jed.
Sent from a small screen. On 3/04/2014 4:52 pm, "Dave Mill"
wrote: Hi all
I posted a few weeks ago about MAC limits on Bitstream 3a connections. This is related to that. This is a UFF Bitstream 3a connection.
I've discovered that a customer's only complaint with a Bitstream 3a connection from us is that DHCP doesn't work over this. I've obtained some pcaps from both ends and I can see the following changes occurring to a DHCP Request:
1) The transaction ID is changed 2) Option 82 is added. More specifically, sub-option 1 Agent Circuit ID is present and has a valid length. sub-option 2 Agent Remote ID is present, has a length of 0 and no content which wireshark doesn't seem to like much.
I've had a brief read of RFC3046 and I can't really tell if its valid to have a sub-option with a length of 0 or not.
https://tools.ietf.org/html/rfc3046#page-8
I never see any DHCP ACKs coming back from the customer's DHCP server.
I've had a read of some of UFF's Bitstream3a docs and can't see any mention of DHCP. I can see in one of our initial requests we had to fill out we can choose to have DHCP Relay Agent Functionality but this seems to be related to Bitstream2 only and also this defaults to be disabled.
I don't know what DHCP server the customer is using right now but I hope to find this out soon.
Questions for anyone with more experience in this than myself: -Can changing the DHCP Request transaction ID cause issues? -Has anyone come across DHCP servers not liking option 82 being set, or not liking sub-option 2 having a 0 length? -Has anyone successfully used DHCP across a Bitstream3a connection? How about a UFF Bitstream3a connection? -Am I missing anything obvious?
Obviously I might end up talking to UFF over this but I just want to see what others on the list know before doing so.
Again, I don't really want to debate the wisdom of plugging two LANs in over a Bitstream3a connection.
Cheers Dave
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
On Thu, Apr 3, 2014 at 4:52 PM, Dave Mill
I've obtained some pcaps from both ends and I can see the following changes occurring to a DHCP Request:
1) The transaction ID is changed 2) Option 82 is added. More specifically, sub-option 1 Agent Circuit ID is present and has a valid length. sub-option 2 Agent Remote ID is present, has a length of 0 and no content which wireshark doesn't seem to like much.
One would not expect an Ethernet service to be giving packets the bad touch.
On 3/04/2014, at 7:23 pm, Jonathan Brewer
wrote: On Thu, Apr 3, 2014 at 4:52 PM, Dave Mill
wrote: I've obtained some pcaps from both ends and I can see the following changes occurring to a DHCP Request: 1) The transaction ID is changed 2) Option 82 is added. More specifically, sub-option 1 Agent Circuit ID is present and has a valid length. sub-option 2 Agent Remote ID is present, has a length of 0 and no content which wireshark doesn't seem to like much.
One would not expect an Ethernet service to be giving packets the bad touch.
Agree. To me this seems all wrong. Alarm bells are going off.
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
https://tools.ietf.org/html/rfc3046
"
2.0 https://tools.ietf.org/html/rfc3046#section-2.0 Relay Agent
Information Option
The length N of the sub-options shall be the number of octets in only that
sub-option's value field. A sub-option length may be zero.
"
So you can have for example
Option 82 LEN 2 (sub options have total length 2 in total)
Suboption 2 LEN 0 (2 bytes) as above..
Or I may have read it all wrong..
From: jamie baddeley
On Thu, Apr 3, 2014 at 4:52 PM, Dave Mill
wrote: I've obtained some pcaps from both ends and I can see the following changes occurring to a DHCP Request:
1) The transaction ID is changed 2) Option 82 is added. More specifically, sub-option 1 Agent Circuit ID is present and has a valid length. sub-option 2 Agent Remote ID is present, has a length of 0 and no content which wireshark doesn't seem to like much.
One would not expect an Ethernet service to be giving packets the bad touch.
Agree. To me this seems all wrong. Alarm bells are going off.
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
On Thu, 3 Apr 2014 16:52:04 +1300, Dave Mill wrote:
I've obtained some pcaps from both ends and I can see the following changes occurring to a DHCP Request:
1) The transaction ID is changed 2) Option 82 is added. More specifically, sub-option 1 Agent Circuit ID is present and has a valid length. sub-option 2 Agent Remote ID is present, has a length of 0 and no content which wireshark doesn't seem to like much.
Do you know if the circuit was ordered with the "DHCP option"? -- Michael Fincham | Senior Network Engineer Solarix Networks Limited
Hi Michael
On Thu, Apr 3, 2014 at 11:19 PM, Michael Fincham
1) The transaction ID is changed 2) Option 82 is added. More specifically, sub-option 1 Agent Circuit ID is present and has a valid length. sub-option 2 Agent Remote ID is present, has a length of 0 and no content which wireshark doesn't seem to like much.
Do you know if the circuit was ordered with the "DHCP option"?
I've looked through the form with our service delivery team a week or so ago and could see no options relating to DHCP on the form for ordering. I can also see no option regarding DHCP for Bitstream3a in our on-boarding forms. In summary so far. Some replies on list don't believe this is normal behaviour for an ethernet service. Craig Whitmore believes that 0 is a valid length for sub-option 2 under DHCP option 82. I've had some useful replies off list offering to help to sort this out and suggesting/guessing what might be causing this. I'll follow up with these off-list emails today and try and work out what is going wrong here. Note, I'm not trying to 'name and shame' here. Just trying to work out if this is normal for BS3a and if it commonly causes issues. I'll update this list when I know more. Cheers Dave
For Chorus UFB:
We do not apply DHCP option 82 for Bitstream 3/3a.
If we did, it would make it difficult for you to differentiate DHCP request on different customer VLANs, as they would all get the same DHCP circuit and customer ID information.
Bitstream 3 and 3a are intended to be transparent services - so we don't mess with traffic on these.
Cheers,
Brent
From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Dave Mill
Sent: Friday, 4 April 2014 8:44 a.m.
To: Michael Fincham
Cc: nznog(a)list.waikato.ac.nz
Subject: Re: [nznog] Bitstream 3a DHCP manipulation
Hi Michael
On Thu, Apr 3, 2014 at 11:19 PM, Michael Fincham
1) The transaction ID is changed 2) Option 82 is added. More specifically, sub-option 1 Agent Circuit ID is present and has a valid length. sub-option 2 Agent Remote ID is present, has a length of 0 and no content which wireshark doesn't seem to like much. Do you know if the circuit was ordered with the "DHCP option"?
I've looked through the form with our service delivery team a week or so ago and could see no options relating to DHCP on the form for ordering. I can also see no option regarding DHCP for Bitstream3a in our on-boarding forms. In summary so far. Some replies on list don't believe this is normal behaviour for an ethernet service. Craig Whitmore believes that 0 is a valid length for sub-option 2 under DHCP option 82. I've had some useful replies off list offering to help to sort this out and suggesting/guessing what might be causing this. I'll follow up with these off-list emails today and try and work out what is going wrong here. Note, I'm not trying to 'name and shame' here. Just trying to work out if this is normal for BS3a and if it commonly causes issues. I'll update this list when I know more. Cheers Dave --------------------------------------------------------------------- This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. ---------------------------------------------------------------------
On Thu, Apr 3, 2014 at 11:19 PM, Michael Fincham
On Thu, 3 Apr 2014 16:52:04 +1300, Dave Mill wrote:
I've obtained some pcaps from both ends and I can see the following changes occurring to a DHCP Request:
1) The transaction ID is changed 2) Option 82 is added. More specifically, sub-option 1 Agent Circuit ID is present and has a valid length. sub-option 2 Agent Remote ID is present, has a length of 0 and no content which wireshark doesn't seem to like much.
Do you know if the circuit was ordered with the "DHCP option"?
Why should a layer 2 circuit need to have such an option? There's no mention of DHCP in: http://www.crownfibre.govt.nz/wp-content/uploads/2013/01/Chorus-UFB-Services...
On Fri, Apr 4, 2014 at 11:14 AM, Andy Linton
On Thu, Apr 3, 2014 at 11:19 PM, Michael Fincham
wrote: On Thu, 3 Apr 2014 16:52:04 +1300, Dave Mill wrote:
1) The transaction ID is changed 2) Option 82 is added. More specifically, sub-option 1 Agent Circuit ID
is
present and has a valid length. sub-option 2 Agent Remote ID is present, has a length of 0 and no content which wireshark doesn't seem to like much.
Do you know if the circuit was ordered with the "DHCP option"?
Why should a layer 2 circuit need to have such an option? There's no mention of DHCP in:
http://www.crownfibre.govt.nz/wp-content/uploads/2013/01/Chorus-UFB-Services...
Just as a quick update on this. It seems likely at this stage that this service has been mis-configured by the UFB provider. The DHCP option seems to commonly be used on Bitstream2 services. No one I've talked to can think of a good reason as to why this would ever be required on a Bitstream3 connection. I know providers that make good use of this on BS2. I'll update again when this is resolved. I'm confident I'm now getting to the bottom of this issue. Cheers Dave
Hi Dave
You are bang on here. UFF or any LFC should not do any mangling of DHCP (even option 82) on the Bitstream3x or 4 services, only Bitstream2 is allowed to touch the DHCP packets for Option 82.
All LFC's you have to ask to turn option 82 on for Bistream2, it's not the default.
From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Dave Mill
Sent: Friday, 4 April 2014 11:33 a.m.
To: Andy Linton
Cc: nznog(a)list.waikato.ac.nz
Subject: Re: [nznog] Bitstream 3a DHCP manipulation
On Fri, Apr 4, 2014 at 11:14 AM, Andy Linton
1) The transaction ID is changed 2) Option 82 is added. More specifically, sub-option 1 Agent Circuit ID is present and has a valid length. sub-option 2 Agent Remote ID is present, has a length of 0 and no content which wireshark doesn't seem to like much.
Do you know if the circuit was ordered with the "DHCP option"? Why should a layer 2 circuit need to have such an option? There's no mention of DHCP in: http://www.crownfibre.govt.nz/wp-content/uploads/2013/01/Chorus-UFB-Services... Just as a quick update on this. It seems likely at this stage that this service has been mis-configured by the UFB provider. The DHCP option seems to commonly be used on Bitstream2 services. No one I've talked to can think of a good reason as to why this would ever be required on a Bitstream3 connection. I know providers that make good use of this on BS2. I'll update again when this is resolved. I'm confident I'm now getting to the bottom of this issue. Cheers Dave ________________________________ Spamhttps://emailguard.orcon.net.nz/canit/b.php?i=09LJzGJyH&m=878a11316463&t=20140404&c=s Not spamhttps://emailguard.orcon.net.nz/canit/b.php?i=09LJzGJyH&m=878a11316463&t=20140404&c=n Forget previous votehttps://emailguard.orcon.net.nz/canit/b.php?i=09LJzGJyH&m=878a11316463&t=20140404&c=f
On Fri, Apr 4, 2014 at 11:32 AM, Dave Mill
Just as a quick update on this. It seems likely at this stage that this service has been mis-configured by the UFB provider. The DHCP option seems to commonly be used on Bitstream2 services. No one I've talked to can think of a good reason as to why this would ever be required on a Bitstream3 connection. I know providers that make good use of this on BS2.
I'll update again when this is resolved. I'm confident I'm now getting to the bottom of this issue.
On Friday the provider of this BS3a service found that Option 82 was being set incorrectly. This issue was fixed and the DHCP service started working for our customer. I've confirmed that since the change on Friday Option 82 is no longer present at the service provider handover end of the circuit. DHCP transaction IDs are still being modified. This does not seem to cause any issues at all. Thanks for all of the on and off list replies. Cheers Dave
participants (9)
-
Andy Linton
-
Brent Marquis
-
Craig Whitmore
-
Dave Mill
-
jamie baddeley
-
Jed Laundry
-
Jonathan Brewer
-
Michael Fincham
-
Simon Allard