The good news is that this is an exciting new service that should appeal to business customers. It combines the simplicity, high reliability and performance of national Ethernet services with the low cost and lead time of Fibre To The Cabinet (FTTC) services used for broadband. This offers the best of both worlds.
With the Ethernet services we can offer what was traditionally called a leased line connecting a customer to us with low latency and low, or zero, contention (sharing). The service has low target fix times for faults and is very reliable and flexible. We can connect people to two separate data centres at the same time for extra reliability, and provide dual router functioning (VRRP) for zero packet loss router maintenance on our network. This is normally provided as a fibre direct to the premises with accompanying cost and lead time (and digging up of the road in many cases).
FTTC on the other hand is quick and cheap to install and has lower running costs. FTTC is widely used for broadband, but normally makes use of the shared broadband back-haul infrastructure. This is more costly for high data usage, and suffers from outages for maintenance on BRASs and LNSs and so on.
By combining the two we can offer high quality Internet access using Ethernet back-haul but at a sensible price for a truely all you can eat service. This is still too much for most home users, but ideal for any business needing a proper Internet connection. BT even offer a 7 hour target fix time, 24/7, on these services.
The not so good news - the roll out for this is happening over the rest of this year - being an extra step once an exchange has Ethernet services and your line has FTTC available.
The bad news is that our first customer does not yet work - this is not really a detraction from such a great service as it will be fixed soon I am sure. It is just that we are the first. If only BT had taken up our offer to trial the service before launch!
Basically, from what we can work out, there is some typical source filtering that you would expect on a shared LAN end user access system (like a cable modem). Basically, for a shared LAN, you want to filter what customers can send so that they cannot spoof neighbours IPs and the like. To do this you make kit that only allows DHCP and PPPoE packets initially, and then any IP packets that match what was allocated by DHCP, and nothing else. It seems that this is what we have.
Interestingly one BT brochure on GEA/FTTC says it supports DHCP and PPPoE (which it does). An odd claim to make if it is in fact transparent, though both DHCP and PPPoE get extra data added for circuit ID and line speed, which is nice. However, the formal spec from BT plc (t/a Openreach) states very clearly that it is layer 2 (Ethernet) transparent except for a small list of low level frames like pause frames and LACP (sort of layer 1.5). The spec from BT plc (t/a BT Wholesale) also claims to be transparent. It is clear it should just work.
What we are seeing is ARPs and ARP replies not getting to us from the customer unless using the IP of a DHCP allocation. We see no routed IP packets, i.e. from other IP addresses either. This is exactly what you would expect on a shared LAN cable service.
So far, with a 7 hour fix time target, BT have taken 4 days. This is not good. Sadly, once they get to 13 hours they stop paying compensation (which is appalling, if you ask me). So now they have no incentive, apart from our constant nagging, to actually fix the fault. Ho hum.
Presumably this would also work (eventually) over an FTTP line?
ReplyDeleteI find it strange that many other ISPs will do ADSL FTTC but not FTTP, then you have strange conversations "Isn't FTTC fast enough for you? ", "Yes but we can ONLY get FTTP, FTTC isn't available" "Sorry, can't do that." Thankfully, I have a sensible ISP.
Yes, available now on FTTP where the two services meet (nowhere yet). As soon as the roll out hits FTTP areas we are happy to do this - more so than on broadband to be honest.
DeleteIt sounds horribly probable that BT have simply not tested enough - they've checked that the DHCP and PPPoE startup packets get the extra information added, but failed to check that the results of DHCP inspection don't cause port filtering.
ReplyDeleteI know BT use two different manufacturers of kit - I wonder if one defaults to filtering based on DHCP, and the other doesn't, and BT simply didn't test both sets of kit in full?
either way, once they realise what is causing the blocking, I wonder what sort of change control process they will have to go through to unbreak it for this type of circuit?
ReplyDeleteWell, not impressed with timescales, but am impressed someone in BT understood enough to log in to their router and packet time while our customer did packet dumps. They even sent us the dumps!
ReplyDelete