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