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@list.waikato.ac.nz [mailto:nznog-bounces@list.waikato.ac.nz]
On Behalf Of Dave Mill
Sent: Friday, 4 April 2014 11:33 a.m.
To: Andy Linton
Cc: nznog@list.waikato.ac.nz
Subject: Re: [nznog] Bitstream 3a DHCP manipulation
On Fri, Apr 4, 2014 at 11:14 AM, Andy Linton <asjl@lpnz.org> wrote:
On Thu, Apr 3, 2014 at 11:19 PM, Michael Fincham <michael@unleash.co.nz> 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:
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