Guide: Configuring a Cisco router for BT Ultrafast Broadband (FTTP)

Disclaimer: In no event will I be liable for any loss or damage including without limitation, indirect or consequential loss or damage, or any loss or damage whatsoever arising from loss of data or profits arising out of, or in connection with, the use of this guide. Please ensure you read the full disclaimer before proceeding. By proceeding you confirm you have read and agree to these terms.

PLEASE READ BEFORE CONTINUING:

If you are a home user; Reconsider using Cisco as a manufacturer for your router. Caution should be taken when considering buying a second hand router. This is due to the new requirement for Cisco Smart licensing which makes it almost impossible to get the correct licenses and support applied to your router if you purchased it second hand.

This guide may be out of date and a new more accurate version is in the works. The last update was 21/01/2021.

As Infinity broadband (FTTC/Fibre to the Cabinet) has been common place for several years there are a number of documents out there to describe how to configure a Cisco router for this service. Ultrafast fibre broadband is a new product offered by BT and as such there isn’t a huge amount of information available as it relates to Cisco however BT have produced a SIN documents ( Suppliers’ Information Notes) to describe the FTTP product just as they have done for the FTTC product. As I moved to Ultrafast broadband when it was available and run a Cisco network at home I have attempted to work out how to configure a cisco router for this service and documented it for others.

If you’re confident with cisco configuration you may chose to skip to the configuration only guide here

The BT SINs discussed below can all be found here:
https://www.openreach.co.uk/orpg/home/helpandsupport/sins/sins.do

In order to make things simpler I will break each element into the following segments:

  • Step 1 – Choosing the right router
  • Step 2 – Understanding how FTTP is delivered
  • Step 3 – Intial configuration of the FTTP
  • Step 4 – Configuration of IPv6
  • Step 5 – Security hardening of the router
  • Step 6 – (Optional) BT TV and Multicast

Step 1 – Choosing the right router

For FTTC the most popular cisco VDSL routers were Cisco 880s and 890s. These are hybrid router/switch devices that aren’t quite a router and aren’t quite a layer 3 switch. The Cisco 880 series (e.g. Cisco C887VA) has a limited throughput capability and when certain features are enabled like NAT, Context Based Access Control (CBAC) or VPN tunnels the performance will restrict throughput to around 20-25mbit/s. The Cisco 890 series (e.g. Cisco C897VA) provide more capability however in the same scenario the throughout could be limited to around 130-140 mbit/s.

The speeds offered under BT ultrafast broadband range far exceed this and so throughput becomes an issue. In my opinion there are three possible solutions:

Solution 1: Offload the features which are most CPU intensive (NAT and CBAC) to another device (like a Pfsense firewall) and route all your traffic through it instead or use Pfsense in place of the router entirely.

Solution 2: Use a more capable dedicated Cisco router such as an ISR4000 since a VDSL interface is no longer required.

Solution 3: Use a Cisco 1100 Series ISR. These are the routers designed to replace the Cisco 897 which are now end of sale. I have gone for this option and will be using a Cisco ISR C1111-8P.

Step 2 – Understanding how FTTP is delivered

In order to provide FTTP a fiber must be run from your local fiber enabled cabinet to your home. Usually this involves the ‘removal’ of your current analogue phoneline. In many cases the analogue line will be used as a fish wire to pull the new fiber line into your premises.

The fibre will be terminated into an ONT (Optical Network Termination). This unit used to comprise of two elements. The ONT and the battery backup. It would appear that BT no longer provide the battery backup.

The fiber is terminated into the ONT and the ethernet cable to our router will come from this. It requires a standard plug socket. On my ONT enclosure there is a gap where the battery backup would have went. The ONT also has a BT Plug for a telephone however the normal BT Master socket / NTE5 is still in place and wired for use and so I don’t know if the ONT provides any usable phone connection for now. This also means that you could potentially revert back to FTTC.

The same PPPoE configuration is required for FTTP as was required for FTTC. The dialer interfaces are configured identically.

With FTTC traffic was sent in two ways; Data traffic was sent via vlan 101 and all other traffic (multicast etc) was sent untagged. This is particularly troublesome for BT TV which relies on the multicast traffic for its services. On the FTTC broadband it was recommended that the interface with the BT TV be bridged to the wan interface. In FTTP however all traffic is untagged which presents us a problem for IPTV. This is explored further in step 6. Although the SIN makes reference to a VLAN tag being allocated on a per customer basis; I saw no VLAN tags when a ran a wireshark capture of the WAN connection and so I can only assume the ONT strips these tags off before presenting to us.

The speed promises of Ultrafast can be a little confusing to understand as it will come with a “Guaranteed minimum speed” and a much faster maximum speed. I’m guessing that this is because in practice this is because we have a few different ‘levels’ of bandwidth available. BT SIN506 describes the various ‘levels’ and the behaviour that goes along with them. I suspect that the current consumer offerings from BT relate to one of these and the ‘guarantees’ are the prioritised rate plus the committed burst size:

Click here to go to BT SIN 506

The table under 2.1.6 of the above document shows various product specifications with a Peak rate (e.g. the advertised max rate for Ultrafast) and the prioritised rate (E.g. The minimum speed guarentee rate). To achive this the service will police to the commited information rate (prioritised) and burst up to the peak information rate. We don’t need to worry about this table as this is the shaping which is occuring from the provider to us.

For the traffic originating from our router (Upstream) the BT SIN has the following to say:

CPs can (optionally) prioritise upstream traffic from the CPE to the ONT by marking their traffic with IEEE 802.1p markings in a VLAN. The GEA-FTTP service supports four upstream queues that are served in strict priority orderCPs can (optionally) prioritise upstream traffic from the CPE to the ONT by marking their traffic with IEEE 802.1p markings in a VLAN. The GEA-FTTP service supports four upstream queues that are served in strict priority order

Source: BT SIN506 – Fibre to the Premises (FTTP) Generic Ethernet Access, Service and Interface Description

and here lies the problem with our ability to prioritise our upstream traffic. As the CoS marking is done on the VLAN tag and we know the ONT strips off the VLAN tag there is no mechanism for tagging the traffic as it leave our router. If the service was ordered by a Business there may be a mechanism by virtue of utilising the VLAN tagging.

As an optional step you migh consider shaping the upload of your router to try to avoid TCP Global synchronisation issues withyour FTTP service. I say this is optional because it’s extremely unlikely for you to cause issues unless you’re maxing our the upload speeds.

Step 3 – Intial configuration of the FTTP

The first step in our configuration will be to configure the PPPoE connection so we can authenticate with the providers network. To do this we create a dialer interface with the required parameters and apply it to our WAN interface. With BT connections in general the username and password are largely superficial. With Cisco however we must at least supply a username and password or the router won’t initiate the PPP session.
If you have a business connection the details below might work but using the supplied credentials is essential if you want to ensure you have the correct static IPs available. This configuration adjust the MTU values, Enables the CHAP authentication, requests an IP address and a default route.

interface Dialer0
  ip address negotiated
  encapsulation ppp
  ip tcp adjust-mss 1452
  dialer pool 0
  no cdp enable
  ppp mtu adaptive
  ppp authentication chap callin
  ppp chap hostname bthomehub@btbroadband.com
  ppp chap password DoesntMatter
  ppp ipcp dns request
  ppp ipcp route default
 

Now we want to apply the configuration to secure our device:

Now we need to apply nat overload (PAT) to allow internet access out. First we create an ACL to define the networks that require internet access and then we add the NAT rule and then apply NAT to the interfaces. The vlan is the subnet or subnets you want to provide internet access for.

ip access-list standard Internet-Permitted
  remark == Permit NAT for Internet Access ==
  permit  <network id> <Wildcard mask>

ip nat inside source list Internet-Permitted interface Dialer0 overload

interface Dialer0
    ip nat outside
interface vlan X
    ip nat inside 

The final step is to patch the BT ONT to your wan port and configure the port to use the dialer interface.

interface GigabitEthernet0/0/0
description WAN - FTTP Uplink
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
negotiation auto
no cdp enable
pppoe enable group global
pppoe-client dial-pool-number 1
no mop enabled

Before you patch the WAN interface you’ll want to complete steps 4 (optional) and step 5 to ensure that your device is properly secured.

Step 4 – Configuration of IPv6

BT provide a /56 subnet for IPv6. What this means is that we have 256 /64 subnets to allocate. The prefix that BT allocate is dynamic just like the IPv4 address and so could change on reboot. The method used to allocate IPv6 addresses to clients is called stateless DHCPv6. Once you have defined your subnet for a network utilising the prefix learned from BT clients use SLAAC to learn of the prefix using NDP and our router will reply with the prefix in a router advertisement. SLAAC requires a /64 in order to perform the autoconfiguration. The client then auto configures the host portion of the IP address. The final step is for DHCPv6 to be used to supply DNS servers to the IPv6 clients.

First we enable ipv6 unicast routing. We can also enable source-route which allows an ipv6 packet to define its route however this is just for diagnostics. We then set a default route for ipv6 to the dialer interace (this isn’t learned like the IPv4 route and define a DHCP pool to hand out the DNS servers for clients.

ipv6 source-route
ipv6 unicast-routing
ipv6 route ::/0 Dialer0
ipv6 dhcp pool IPv6
 dns-server 2001:4860:4860::8888
 dns-server 2001:4860:4860::8844

These two DNS servers are the IPv6 equivilent of Googles 8.8.8.8 and 4.4.4.4 so you can change these for whichever provider you prefer. We then we configure the dialer interface to enable ipv6, request a prefix from BT and configure an IPv6 address based on that prefix.

interface Dialer0
ipv6 address PREFIX-V6::1/64
ipv6 enable
ipv6 dhcp client pd PREFIX-V6 rapid-commit

Rapid commit here just makes the request a much shorter two step process. We then need to configure our VLANs to enable IPv6 and then advertise the prefix for users to autoconfigure. We also need to ensure DNS servers are handed to ipv6 clients.

interface vlan x
ipv6 address PREFIX-V6 ::<x>:0:0:0:1/64
ipv6 enable
ipv6 nd other-config-flag
ipv6 dhcp server IPv6

PREFIX-V6 tells the interface to use the prefix we learned from BT (the /56) as the base of the /64 address. Set the <x> element to any number between 1 and 255 (0 was used for our dialer interface) and this will define separate /64 subnets. The other config flag lets the clients know they can use DHCPv6 to receive additional configuration and the server command direct the clients to the DHCP pool we created above. Now we are done; The router will learn it’s ipv6 prefix from BT and each client will learn it’s /64 subnet via NDP and autoconfigure using SLAAC. They will also get their DNS servers from DHCPv6.

NOTE: IPv6 heavily relies on ICMP and so the security section will permit this.

Step 5 – Security hardening of the router

Cisco have included a feature called ‘Auto Secure’ for their routers for some time. The feature will ask a series of questions and recommend security configuration based on the answers. I always recommend this as a starting point. Auto secure should be run when all other configuration is done but the internet has yet to be patched in. You may be asked other questions such as whether or not SNMP is used but the output below shows a sample:

FTTP-ROUTER#auto secure
                 --- AutoSecure Configuration ---
 *** AutoSecure configuration enhances the security of
 the router, but it will not make it absolutely resistant
 to all security attacks ***
 AutoSecure will modify the configuration of your device.
 All configuration changes will be shown. For a detailed
 explanation of how the configuration changes enhance security
 and any possible side effects, please refer to Cisco.com for
 Autosecure documentation.
 At any prompt you may enter '?' for help.
 Use ctrl-c to abort this session at any prompt.
 Gathering information about the router for AutoSecure
 Is this router connected to internet? [no]: yes
 Enter the number of interfaces facing the internet [1]: 1
 Interface                  IP-Address      OK? Method Status                Protocol
 GigabitEthernet0/0         unassigned      YES NVRAM  up                    up
 GigabitEthernet0/1         unassigned      YES NVRAM  administratively down down
 GigabitEthernet0/2         unassigned      YES NVRAM  administratively down down
 GigabitEthernet0/3         unassigned      YES NVRAM  administratively down down
 Enter the interface name that is facing the internet: GigabitEthernet0/0
 Securing Management plane services…
 Disabling service finger
 Disabling service pad
 Disabling udp & tcp small servers
 Enabling service password encryption
 Enabling service tcp-keepalives-in
 Enabling service tcp-keepalives-out
 Disabling the cdp protocol
 Disabling the bootp server
 Disabling the http server
 Disabling the finger service
 Disabling source routing
 Disabling gratuitous arp
 Here is a sample Security Banner to be shown
 at every access to device. Modify it to suit your
 enterprise requirements.
 Authorized Access only
   This system is the property of So-&-So-Enterprise.
   UNAUTHORIZED ACCESS TO THIS DEVICE IS PROHIBITED.
   You must have explicit permission to access this
   device. All activities performed on this device
   are logged. Any violations of access policy will result
   in disciplinary action.
 Enter the security banner {Put the banner between
 k and k, where k is any character}:
 k BANNER k
 Enable secret is either not configured or
  is the same as the enable password
 Enter the new enable secret:
 Confirm the enable secret :
 Enter the new enable password:
 Confirm the enable password:
 Configuration of local user database
 Enter the username: username
 Enter the password:
 % Invalid Password length - must contain 6 to 25 characters. Password configuration failed
 Enter the password:
 Confirm the password:
 Configuring AAA local authentication
 Configuring console, Aux and vty lines for
 local authentication, exec-timeout, transport
 Securing device against Login Attacks
 Configure the following parameters
 Blocking Period when Login Attack detected: 360
 Maximum Login failures with the device: 5
 Maximum time period for crossing the failed login attempts: 30
 Configure SSH server? [yes]: yes
 Enter the domain-name: domain.name
 Configuring interface specific AutoSecure services
 Disabling the following ip services on all interfaces:
 no ip redirects
  no ip proxy-arp
  no ip unreachables
  no ip directed-broadcast
  no ip mask-reply
 Disabling mop on Ethernet interfaces
 Securing Forwarding plane services…
 Enabling unicast rpf on all interfaces connected
 to internet
 Configure CBAC Firewall feature? [yes/no]: yes
 This is the configuration generated:
 no service finger
 no service pad
 no service udp-small-servers
 no service tcp-small-servers
 service password-encryption
 service tcp-keepalives-in
 service tcp-keepalives-out
 no cdp run
 no ip bootp server
 no ip http server
 no ip finger
 no ip source-route
 no ip gratuitous-arps
 no ip identd
 banner motd ^C BANNER ^C
 security passwords min-length 6
 security authentication failure rate 10 log
 enable secret 5 $1$VXT6$geedAyQQ8K9M82NkM7Gfa/
 enable password 7 06160E325F1D5D4C
 username username password 7 095C4F1A0A5445415F
 aaa new-model
 aaa authentication login local_auth local
 line console 0
  login authentication local_auth
  exec-timeout 5 0
  transport output telnet
 line aux 0
  login authentication local_auth
  exec-timeout 10 0
  transport output telnet
 line vty 0 4
  login authentication local_auth
  transport input telnet
 line tty 1
  login authentication local_auth
  exec-timeout 15 0
 login block-for 360 attempts 5 within 30
 ip domain-name domain.name
 crypto key generate rsa general-keys modulus 1024
 ip ssh time-out 60
 ip ssh authentication-retries 2
 line vty 0 4
  transport input ssh telnet
 service timestamps debug datetime msec localtime show-timezone
 service timestamps log datetime msec localtime show-timezone
 logging facility local2
 logging trap debugging
 service sequence-numbers
 logging console critical
 logging buffered
 interface GigabitEthernet0/0
  no ip redirects
  no ip proxy-arp
  no ip unreachables
  no ip directed-broadcast
  no ip mask-reply
  no mop enabled
 interface GigabitEthernet0/1
  no ip redirects
  no ip proxy-arp
  no ip unreachables
  no ip directed-broadcast
  no ip mask-reply
  no mop enabled
 interface GigabitEthernet0/2
  no ip redirects
  no ip proxy-arp
  no ip unreachables
  no ip directed-broadcast
  no ip mask-reply
  no mop enabled
 interface GigabitEthernet0/3
  no ip redirects
  no ip proxy-arp
  no ip unreachables
  no ip directed-broadcast
  no ip mask-reply
  no mop enabled
 access-list 100 permit udp any any eq bootpc
 interface GigabitEthernet0/0
  ip verify unicast source reachable-via rx allow-default 100
 ip inspect audit-trail
 ip inspect dns-timeout 7
 ip inspect tcp idle-time 14400
 ip inspect udp idle-time 1800
 ip inspect name autosec_inspect ftp timeout 3600
 ip inspect name autosec_inspect http timeout 3600
 ip inspect name autosec_inspect rcmd timeout 3600
 ip inspect name autosec_inspect realaudio timeout 3600
 ip inspect name autosec_inspect smtp timeout 3600
 ip inspect name autosec_inspect tftp timeout 30
 ip inspect name autosec_inspect udp timeout 15
 ip inspect name autosec_inspect tcp timeout 3600
 ip access-list extended autosec_firewall_acl
  permit udp any any eq bootpc
  deny ip any any
 interface GigabitEthernet0/0
  ip inspect autosec_inspect out
  ip access-group autosec_firewall_acl in
 end

 Apply this configuration to running-config? [yes]:

The problem we will have with this with a modern cisco router is that in later IOS it will still try to apply the CBAC rules even though they’ve been depreciated or completely removed. Zone based firewalls should be used instead. It’s important to remember that zone based firewalls don’t apply to system traffic such as SSH, SNMP or NTP and so these needs locked down with ACLs. The following is a basic zone based setup to get you started. It’s worth noting that ICMP is used heavily for IPv6 and you may need to permit it.

ipv6 access-list ICMPv6-in
   permit icmp any any echo-reply
   permit icmp any any echo-request
   permit icmp any any no-route
   permit icmp any any packet-too-big
   permit icmp any any hop-limit
   permit icmp any any header
   permit icmp any any next-header
   permit icmp any any parameter-option
   permit icmp any any time-exceeded
   deny ipv6 any any
  
  ipv6 access-list ICMPv6-out
   permit icmp any any nd-na
   permit icmp any any nd-ns
   permit ipv6 any any
 
 class-map type inspect match-any ICMPv6-inbound
    match access-group name ICMPv6-in
   class-map type inspect match-any ICMPv6-outbound
    match access-group name ICMPv6-out
 
   class-map type inspect match-any IP-outbound
    match protocol udp
    match protocol tcp
 
   class-map type inspect match-any ICMPv4-outbound
    match protocol icmp
 
   policy-map type inspect ToInternet
    class type inspect IP-outbound
     inspect
    class type inspect ICMPv6-outbound
     pass
    class type inspect ICMPv4-outbound
     inspect
    class class-default
     drop
 
   policy-map type inspect FromInternet
    class type inspect ICMPv6-inbound
     pass
    class class-default
     drop
 
  zone security inside
  zone security outside
  zone-pair security inside-->outside source inside destination outside
   service-policy type inspect ToInternet
  zone-pair security outside-->inside source outside destination inside
   service-policy type inspect FromInternet

interface dialer 0
 zone-member outside

interface vlan x
 zone-member inside

This config creates two zones; Inside and outside. It allows access out to the internet and reflexive traffic back. Remember to add all your vlans to a zone as by default if two interfaces are in different zones but have no zone pairing their communications will not be permitted. ICMP is a major component of IPv6 and so this configuration permits icmp inbound for IPv6.

Once you’re confident in the security of the router i.e. you have this config completed, have NTP/SNMP/SSH secured with ACLS and your zones configured you can now patch the WAN interface and start using your FTTP broadband.

Step 6 – (Optional) BT TV and Multicast

This part is probably the most frustrating element to dealing with Cisco and the FTTP service. As far as I’m aware there is no way to have a Cisco router function correctly for multicast due to the nature of how BT TV / Youview is delivered. I have however found a very hacky workaround to at least get the BT TV to work.

Your BT TV / Youview set top box will send an IGMPv3 Join message in order to join a multicast stream for whatever IPTV channel you try to visit. The problem is that this IGMP Join message needs to be sent our the WAN interface on your router and not be encapsulated in PPPoE. The following section from a BT SIN explains the behavior

3.2.2.1 IGMP encapsulation
IGMP messages intended for the Openreach Multicast service must be sent as IGMP over IP.
IGMP messages sent as IGMPoPPPoE will be passed through transparently to the CP and will not be acted on by Openreach.
In the case of GEA-FTTP and GEA-FTTC with a white Openreach modem IGMP messages can be tagged with VLAN ID 0 (zero) by the CPE in order to set a preferred 802.1p value upstream. A VLAN tag with an ID of 0 will be removed by the ONT and white Openreach modem but the 802.1p value will be used to ensure the desired upstream scheulding of the IGMP messages on to the PON and VDSL line respectively.

BT SIN 503 – Generic Ethernet Access Multicast, Service & Interface Description

Unfortunately for us Cisco has no method available to forward an IGMP join received on a VLAN directly out a specified interface and therefore avoiding the PPPoE encapsulation. As a result it is not possible to configure a cisco router natively to deal with this setup. With FTTC the story is different because the data is encapsulated in VLAN 101. This allows us to bridge the VLAN with the IPTV with the WAN interface and to configure the PPPoE on the VLAN 101 encapsulated sub interface. With FTTP this isn’t an option as all frames are sent through untagged. As a result the only option available is to physically bridge your connection to the ONT with your routers WAN interface, the IPTV set top box and the interface where the set top box would connect to your switch normally. Hypothetically this bridging shouldn’t lead to any extra risk but just in case I’d suggest putting the IPTV VLAN in a separate security zone.


First we create a new security zone and permit it the same access we have given our inside policy. Creating a new zone ensures the IPTV box can’t communicate with our home network but can reach the internet.

zone security BTTV

zone-pair security BTTV-->outside source BTTV destination outside
service-policy type inspect ToInternet

zone-pair security outside-->BTTV source outside destination BTTV
service-policy type inspect FromInternet

Then we create VLAN for the IPTV box and an interface vlan. Create this as a /30 as you will only have the SVI and the IPTV box. We assign it to this security zone.

vlan 66
name BTTV
no shutdown

interface vlan 66
description BT Youview IPTV
ip address x.x.x.x 255.255.255.252
ip nat inside
zone-member security BTTV
no shutdown

As is stands the IPTV box is isolated but has internet access. It still has no ability to join the multi-cast streams. Now we need to connect up these devices to a dumb switch to bridge the WAN and IPTV box. By doing this the IGMP joins that our IPTV box tries to send out will be sent toward the WAN without being encapsulated in the PPPoE and therefore the Multicast channels will work.

NOTE: Some switches are smarter than others and this can be a problem. The switch i used and can confirm works is a Netgear GS305

1 The BT ONT
2 The WAN port of the ISR (Gi0/0/0 above)
3 The LAN port for the IPTV VLAN (Gi0/1/0 above)
4 The Youview IPTV box

In addition to the configuration the following settings are required on the youview box.

IP Address:      x.x.x.x
Subnet mask:     255.255.255.252
Gateway:         x.x.x.x
Primary DNS:     62.6.40.178   
Secondary DNS:   62.6.40.162

Where the IP address is the one configured for your IPTV VLAN and the DNS server is one of the BT DNS servers. I’ve chosen two of these but you can chose any two from the following list; It just needs to be a BT DNS server:

62.6.40.178
62.6.40.162 
194.72.9.38
194.72.9.34
194.72.0.98
194.72.0.114
194.74.65.68
194.74.65.69 

Final checks

For some reason the BT wholesale speed tester completely gets the speed for this service wrong. Try any other online speed testing website and ensure the speeds are as expected. If you want to see close to the full 330mbit you need to be directly connected to the LAN and be using the internet at an off peak time. That said I regularly see 220mbit during peak times through a Cisco switch and BT Powerline adapter.

If you want to test the IPv6 connectivity I recommend using https://ipv6-test.com/

This will show a number of metrics for your IPv6 connectivity. You should get the full 20/20 for this test. If ICMP shows as filtered you may have to permit ICMPv6 through your clients firewall (e.g. Windows Firewall).

 8,216 total views,  8 views today

17 thoughts to “Guide: Configuring a Cisco router for BT Ultrafast Broadband (FTTP)”

  1. Did you try configuring the connection without the use of the BT ONT?

    i.e. connecting the fibre directly to your cisco router?

    1. Hi Simon,

      No I did not try this however there are a few reasons why this would not work and if it did work you shouldn’t be doing it.

      Firstly the fibre going to the ONT is using a technology called GPON (Gigabit Passive Optical Network). This is a service provider technology which isn’t supported by any Cisco equipment except select service provider devices and SFPs so it wouldn’t work if it could be connected.

      Secondly the fibre is presented to the ONT as a single SC connector and the VLAN used for user traffic and service traffic is dynamically allocated with no way for us to know and configure our device for it.

      Lastly the ONT represents the demarcation point for the provider. The provider can run loopback tests to the ONT in the event of a fault and it is their property. As such you may find modifying this in any way is a breach of the terms of service and will exclude you from support should there be a fault. This is similar to how the current NTE5 you have for your phone or ADSL/VDSL is treated.

  2. Many thanks for this guide!! I’ve been struggling with getting a Cisco ISR 1100 configured successfully for IPv6 on FTTP for a while now, with BT being no help at all. Much appreciated!!

    1. No problem. It’s fully understandable that BT retail wouldn’t be able to support this since most ISPS only support their own devices. For Business BT do support this but as a managed service.

  3. Hi Kieran,

    How can I get the BT TV box and the Internet channels working with my Cisco 1900 series router I have setup the VLAN’s etc on both the router and cisco 2960 switch they are trucked and can ping etc so I know the routing is working OK, when I connect to the FTTP modem to the Cisco g0/0 port it gets an IP from the ISP and also hands out IP’s to the home users in terms of WIFI and PC’s etc i am using the BT hub 2 as an AP and getting an IP from the Cisco the BT power-line adaptors are getting IP’s also and the BT TV box gets an IP but the Internet subscription channels don’t work with error IPC6023 on the BT TV box any help would be appreciated as i’m pulling my hair out!!

    1. IPC6023 means that the IGMP joins sent from your BT Box (which request the multicast video stream) and are not be responded to. This is what I’m alluding to in my guide regarding the need to bridge the WAN interface and IPTV VLANs with a dumb switch. This allows the igmp joins sent by the BT Box to be sent out the WAN interface. Have you done anything to bridge these?

      Can you post your full sanitised config for both devices – I don’t need to make them public on this site.

      1. Hi Kieran,
        I’ve read through your post and all makes sense, I had been wondering how to configure this on my own Cisco box. One question I did have though is around the QoS part, and what issues this would cause if not in place. The reason for asking is that even with a) FTTC using a standard Openreach modem, or b) FTTP with standard BT Smart Hub, the router element seems to be presented with a standard RJ45 ethernet port so in those cases the router is not aware of the ‘real’ interface speed; why is it that FTTP requires the QoS to rate-limit the line when those other solutions work fine with presumably some throttling happening that the router is not aware of? FTTP doesn’t appear to be different in that regard, hence my question. Is it just simply better for the Cisco box to be aware of the drops because it can better manage the retransmissions rather than relying on the end client deice performing a resend, or is there a reason this is required for FTTP but not for FTTC or even standard VDSL (when using the Openreach modem)?

        Also, it has been suggested elsewhere on the internet that in your step 6 (BT IPTV Multicast) it might work if a new BDI interface (bridge domain interface) is created on the router, and then the BT IPTV VLAN and the external FTTP gigabit ethernet interface are simply bridged to that BDI, rather than using a separate physical bridging device (Netgear 305 in your case). I know you said that wouldn’t work, but there are a few other forums where people report working configurations using BT IPTV without using the VLAN 101 sub-interface but instead using ACLs and seemingly ‘bridge protocol ieee’ (although I’ve not yet got my head round how it is avoiding the PPP encapsulation, as you have said in your post). Do you believe there is a way to stop the multicast being PPP encapsulated, and if not then how is it possible for the other users to report success? (Note, the other users seem to be using FTTC rather than FTTP, nevertheless they are applying the PPP encapsulation to the main WAN interface and not the VLAN 101 sub-interface, so it appears to be the same as what you are trying to do in your case.) Thanks.

        1. The purpose of shaping ourselves is so we drop the traffic before transmitting so the PE doesn’t do it for us. This is more efficient this way and also allows to do WRED (E.g. random-detect) so we avoid a scenario like TCP Global Synchronisation. It’ll still work without it (hence FTTC working fine even when using the Openreach modem) but none of the BT Openreach documents mention they do random early drop so I thought it best to do this proactively.

          With regards the bridge interface; Unfortunately I’ve confirmed it doesn’t work. When there used to be a tagged vlan (101 for VDSL) you could use a BDI or BVI interface to bridge the IPTV Vlan and the main interface while allowing the PPPoE session to come up via the sub interface. I’ve tried every combination I can think of including using native vlans and vlan 1. On each occasion it prevented the PPPoE session being established and such there was no internet connectivity. With FTTP our connection isn’t vlan tagged as it is with FTTC. The BT home hub and other routers can simply forward IGMP Joins out the WAN interface but cisco doesn’t support anything which would do this and BT don’t support multicast routing.

          I don’t see any other solution other than this hacky one with a dumb switch working without changes to the delivery from BT or to the capabilities of a Cisco router from Cisco.

          1. Hi Kieron, thanks for the reply. That makes sense in terms of the first point and the fact that it’s better to have the Cisco knowing about the drops so it can handle it better. That’s what I thought, that it was more of a best practice rather than a mandatory part of the config (as I mentioned, this works fine on FTTC without the QoS).

            On the second point around IPTV, yes completely get what you are saying, and I’m not doubting your superior Cisco knowledge, but this guy seems to have reported success (https://community.bt.com/t5/Archive-Staging/Cisco-1812-router-configuration-to-support-multicast-IPTV/td-p/1358271). If I read his config correctly, the key may lie in the “ip igmp helper-address udl FastEthernet0” and “ip igmp proxy-service” parts of his config, and I’m not an expert on this at all but it looks like he is using the Unidirectional Link concept to ‘back door’ the outgoing multicast join requests out of FastEthernet0 without going via Dialler 1 (and thus avoiding the PPP encapsulation). Now, I have no evidence that the config works (on the comments on that forum) but it seems reasonable that it *could* work. I fully understand what you are saying about there being no VLAN 101 on FTTP where there is on FTTC, and I do suspect this guy is using FTTC rather than FTTP….but his config doesn’t;t include any reference to VLAN 101 at all or any 0.101 sub-interface for FastEthernet0, so it *sounds* from the way he is talking that the igmp commands may be working around the issue?

            What do you think? Are you still skeptical that this config actually works?

          2. I’ll try your suggestions with regards the igmp helper/udl and see if I can get some traction on it although I did try this initially with no success I believe my multicast knowledge is a bit better now.

            Update: I’ve reviewed their configuration but some of it doesn’t make sense. They’ve bridged the IPTV VLAN and their WAN interface and this is how the IGMP joins are being forwarded out the WAN interface and are being recieved back – The multicast config isn’t actually doing anything there. I did some packet captures and debugs there now and It would appear that there are no IGMP messages recieved on the WAN interface as far as Cisco is concerned and any attempt to add encapsulation or bridge interfaces on Gi0/0/0 results in PPP failing.

  4. Hi there. Thanks for the useful article, I’m now in the process of trying to get my new 1Gbps FTTP circuit connected with a Cisco 1921. Following your tips I’ve got things connected, but I can only get 130Mbps out of my 1Gbps connection. I get 970mbps when using the BT router, so I can only presume this is due to CoS settings – my Cisco 1921 doesn’t allow the “set-cos-transmit” argument in the CLI, but a few others :

    drop drop packet
    set-clp-transmit set atm clp and send it
    set-discard-class-transmit set discard-class and send it
    set-dscp-transmit set dscp and send it
    set-frde-transmit set FR DE and send it
    set-mpls-exp-imposition-transmit set exp at tag imposition and send it
    set-mpls-exp-topmost-transmit set exp on topmost label and send it
    set-prec-transmit rewrite packet precedence and send it
    set-qos-transmit set qos-group and send it
    transmit transmit packet

    I presume that this is because I’m using a 1921 vs an ASR? Are you aware on how I could overcome the above limitation? Thanks in advance! Dave

    1. Can you do a show process cpu history when you’re maxing it out? I suspect the 1921 doesn’t have the capabilitites to push 1 Gigabit. There’s a white paper here which might help you.

      If you have 1 gigabit then you can simply mark/transmit everything as cos 4

      1. Hi Kieran, I assume setting everything to cos 4 would only be advisable if the 1Gbps speed is in the ‘upstream’ direction, as then no QoS is required? Assuming it’s standard FTTP with 1 Gbps downstream and only 100Mbps or so upstream, then the QoS settings would presumably be best as per your post, but with the specific threshold values modified based on the values specified in the BT SIN document?

        If the assumption around it being asynchronous FTTP is correct, then I assume Dave H is referring to the fact he’s only pulling 130Mbps of speed downstream when downloading, which might be due to the amount of config on the router and the ‘power’ that the 1941 has available?

        @Dave H, might be worth clarifying the direction of the test, but if my comments/assumptions are correct then it may be that an ISR1100 would be better for this connection speed (or even an ISR4400).

        1. Thanks Rich. The assumptions in this guide regard the shaper are actually incorrect and the SIN referenced has been moved/superceded. Back when I originally made the guide i got the shaper direction wrong so correctly as you say the shaper should be the upload speed (50/100mb etc). I’m redoing this guide and replacing it with a more advanced version to include full IPv6 with multiple VLANS.

          The ISE4ks are much more capable but require a throughput license to actually achieve the greater speeds making the ISR1ks a much more cost effective option.

    2. Hi Dave,

      Just an update for you; After re-reading this guide to produce an updated version I realised that I had made an error with the shaper and got it in the direction wrong. A shaper shouldn’t be required at all unless multple clients are trying to max out the upload speed which is extremely unlikely at home.

      I’d advise removing the shaper aand testing again as not performing QoS may give you additional head-room. I do suspect you won’t get the full speed with the 1921 due to limitations in it’s processing capability.

  5. Hi Kieran,

    Great article, I wondered if you had any success with baby Jumbo’s on your FTTP / Cisco setup. I have recently upgraded from FTTC (Cisco 897) to FTTP (Cisco 1127X-P).

    On the FTTC I had baby Jumbo’s working a treat courtesy of https://community.bt.com/t5/Archive-Staging/Infinity-on-Cisco-Router/td-p/149185/page/2. I switched to FTTP and Initially used an EdgeRouter 4 which again I had jumbo frames working. So I know my FTTP connection supports it. This week I switched to a 1127X-P and modified the config from the 897. It connects and seems to be working fine but I can’t ping a non-fragmented 1972 packet . As before on the connected interface (this time GigabitEthernet0/0/0 as opposed to Ethernet0 / Ethernet0.101) I had set:

    mtu 1508
    pppoe-client ppp-max-payload 1500

    This time it does not seem to have trick. Just wondered if you had tried / had any success.

    1. I did try it just to see if would work (pretty much exactly as you have done) and it didn’t work. I don’t think it’s a big issue however since the route handles fragmentation fine when it occurs and i assume the path through the BT Network will have overhead and so even though your router won’t be fragmenting it – some other device will.

      I’d suggest your VDSL modem/some device in a VDSL delivery was doing the fragmentation for you.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.