On 14 September 2015 at 13:34, Alistair C <uk...@imf2000.org> wrote: > On 14 September 2015 at 12:43, James Bensley <jwbens...@gmail.com> wrote: >> >> On 14 September 2015 at 12:08, Alistair C <uk...@imf2000.org> wrote: >> >> > Do you currently have any customers utilising centralised DHCP and relay >> > for >> > their LAN side, on FTTC? >> >> >> Yes.
> Interesting, are you using DHCP, PPPoE, Static, or a mixture for the WAN > side for these sites? We typically use static for the WAN connection from our CPE back to Exchange PE device. We did test DHCP, it worked, but we prefer static. > I'm having a dig through my email archives to see if I still have the > original test results but essentially we have to tunnel the DHCP requests, > in order to correctly relay and receive a properly formed response, for our > customers. > > I just mentioned this to a colleague and there may have been a few instances > where we did not apply the workaround, yet the relay seemed to function > correctly. Perhaps a difference between the different DSLAM manufacturers > though this seems unlikely. Funny you should say that... I always suspected something dodgy about the Openreach set up and I still believe that, see below, I wonder if these exchanges (well street-cab-DSLAMs really) used different model DSLAMs, maybe a different firmware version or configuration, where there a couple of duff deployments that slipped through the net? > We have been and are able to demonstrate, time and again that if the request > is not tunneled to our PE, the end user LAN side equipment will not obtain a > valid lease, from their central DHCP servers. Something we do not need to do > with our EAD or EFM connected sites which have an identical configuration. > > Would be interesting to hear if other operators echo this or if indeed it > seems to be just an oddity with our particular setup. A common deployment is that we are using static IPs between CPE and exchange device, then the customer is running DHCP relay (it's configured on our CPE LAN interface) back to a central DHCP server somewhere else in their WAN. We've had some issues with this not working at a handful of exchanges and they were the only NGA sites we had at those exchanges so we had nothing to compare against. We have NGA cable links at hundreds of exchanges but for this handful (spread out, we couldn't find any commonality between them) of end sites at this handful of exchanges, our CPE was forwarding the DHCP request over the FTTC link and the customer's central DHCP server was never receiving it. (or I think maybe it received it but it was mangled somehow?). At sites where it does work, we can see that BT are intercepting the DHCP request even though it leaves our CPE with a VLAN tag on it push on by the CPE (so it arrives at our exchange device double-tagged), and inserting the sync speed (as they should do, per the SIN document, although it doesn't say if they will only do it for untagged, tagged or both kinds of traffic). I moved on to another project at that time so another engineer began investing. I've had a dig through the records, we obviously spoke to Openreach about this. They declined any issue at any of the exchanges, we also asked if they could disable the DHCP inspection feature but they said it was a [VDSL] DSLAM wide setting and would affect all CPs, so they couldn't. It seems we have tried replacing the CPE, and different firmware versions (even though the first set up is working at hundreds of other exchanges and thousands of sites). The records show that since this was chewing up delivery time and since we are an LLU provider we have rolled out EFM to these handful of sites instead and cancelled the NGAs due to the issue not being resolved. Cheers, James.
