Personal tools
You are here: Home Networking Cisco IOS Cisco 800 configuration for EUBA PPPoE with ISP Snap Internet

Cisco 800 configuration for EUBA PPPoE with ISP Snap Internet

A Cisco 877 configuration (IOS v15.1) for SNAP internet with PPPoE over a Telecom Wholesale EUBA circuit.

These are my notes on the first part of a journey to get an EUBA (Enhanced Unbundled Bitstream Access) connection running with COS (Class of Service) support and IPv6. Upon starting I had a rough set of milestones which included:

  1. getting the circuit provisioned from BUBA to EUBA
  2. move from EUBA PPPoATM 0/100 PVC compatibility to EUBA native 0/110 PVC
  3. mark EUBA traffic with COS
  4. move to native IPv6 with the ISP
  5. get a prefix from the ISP and renumber
  6. decommision the SixXS IPv6 tunnel

It will be very clear when I am 'done', as decommisioning the SixXS tunnel is a very obvious last step.

The the milestones/objectives the following pre-requisites need to be met:

Objective Pre-requisite
1. IPv4 over native EUBA EUBA provisioned
2. IPv4 with QOS
EUBA-40, EUBA-90, EUBA-180 or something that is more than EUBA-0, and a router that can do 802.1p COS marking
3. IPv6 over EUBA
Get the ISP to engage

Reprovision as EUBA

SNAP internet is provisioning customers on EUBA-0. Getting this step completed was painless. Given the compatibility 0/100 PVC on EUBA, this required no change at the CPE end.

The  DSL is supplied by Telecom Wholesale. From a feature perspective, whether it is an ADSL2+ or a VDSL service it is approximately the same (except for the speed).

What I have found out is that I can only get a EUBA-0 circuit (i.e. not a EUBA-180 circuit). It has been explained to me by Snap that this is due to limitations in the implementation of the Snap Core network, and the Telecom Wholesale backhaul.

EUBA 0/110 PVC

EUBA presents a 802.1q Ethernet service to the customer. The ISP can then choose what to provision on top of that. Two obvious choices are:

  • RFC-1483 bridging
  • PPPoE

Snap Internet have chosen to use PPPoE. This means authentication can be done with PPP, and their accounting of traffic is simplified.

The PPPoE Cisco configuration is very similar to the PPPoATM configuration - details below.

Conclusion: Getting EUBA PPPoE running is straight forward and possible.

QOS and COS Marking

So that VoIP traffic is prioritised, the EUBA network supports a small fix prioritised bandwidth. Telecom Wholesale only lets you choose from 1 of 4 pre-determined bandwidths (0bps, 40kbps, 90kbps, 180kbps).

Given the limitation in the backhaul/ISP parts of the network, this work was unable to be completed. Traffic with 802.1p COS marking of anything other than 0 was lost (tested in real time with a SIP call - all outgoing voice RTP traffic was lost with non-zero COS).

At the CPE end, the QOS has three components in scope (layer 2 LAN QOS is out of scope):

  • IP DiffServ marking of VoIP traffic with DSCP EF (expedited forwarding) by the VoIP server (Asterisk)
  • DSL priority queing of VoIP traffic marked with DSCP EF
  • DSL 802.1p COS marking of traffic with DSCP EF

The first two items are already in place, and it is the extending of this infrastructure into the DSL backhaul/ISP networks. What is not clear is what criteria must be met for traffic from the internet to be classified in the prioritised bandwidth by the ISP.

Conclusion: Too early to get this done.


When a native IPv6 service over DSL is requested from Snap, they say no (but offer a tunnel solution). The EUBA PPP session will not negotiate IPV6CP.

Conclusion: Too early - world IPv6 day might make a wooshing sound.


The following EUBA constrains need to be met:
Constraint Value
0/110 (Note: EUBA also supports 0/100 for PPPoATM compatibility)
Framing Ethernet
Up to 1600 bytes
COS 0 - best effort
6 - fixed allocation based on plan
1-5,7 - discarded

Snaps implementation of EUBA over the Telecom Wholesale service is:

Encapsulation PPPoE
Authentication PPP authentication (same as BUBA)
0 - all other values discarded (as of April 2011)

Thus to migrate from a BUBA PPPoATM configuration to a EUBA PPPoE configuration, the number of changes is very minimal. It is important to note that Snap has not gone with a pure RFC-1483 design, thus the use of a Cisco RBE (routed bridge encapsulation) configuration is not suitable.

The following Cisco configuration directives are used for each of the requirements:

Constraint How to configure
VPI/VCI 0/110
This can be done directly on the ATM interface, or on a sub-interface
pvc euba 0/110
Use the PPPoE client, which requires a dialer interface.
interface ATM0.110 point-to-point
  pvc euba 0/110
    pppoe-client dial-pool-number 1
This sets the encapsulation to 802.1q, with a default VLAN id of 10 for all traffic.
interface ATM0.110 point-to-point
  pvc euba 0/110
    bridge-dot1q encap 10

MTU 1492
The MTU is set to 1492 on the dialer interface, and TCP MSS clamping is done of the VLAN interface
interface Dialer0
  mtu 1492
interface vlan 1
  ip tcp adjust-mss 1452
COS Set the 802.1p COS based on DSCP on the ATM sub interface. WARNING: This is tested as working yet, as the network doesn't support it.
class-map match-any voice
  match dscp ef

policy-map CosMarkingPolicy
  class voice
    ! Note: Telecom Wholesale use COS 6 (not 5) for voice.
    set cos-inner 6

interface ATM0.110 point-to-point
  pvc euba 0/110
    service-policy output CosMarkingPolicy
The following is the main guts of the configuration (firewall, IPS, etc removed for clarity):
dialer-list 1 protocol ip permit

interface ATM0.110 point-to-point
  description EUBA 0/110 PVC to ISP
  pvc euba 0/110
    tx-ring-limit 3
    bridge-dot1q encap 10
    pppoe-client dial-pool-number 1

interface Dialer0
  description PPPoE to ISP
  mtu 1492  
  ip address negotiated previous
  ip nat outside
  no ip directed-broadcast
  no ip mroute-cache
  ip virtual-reassembly
  no ipv6 enable
  encapsulation ppp
  dialer pool 1
  dialer-group 1
  no cdp enable
  ppp ipcp accept-address
  ppp ipcp route default
  ppp ipcp dns request
  ppp ipcp wins reject
  ppp pap sent-username password 0 big-long-password



The Snap PPPoE MTU is less than 1500bytes. Although this is reasonably standard, it is an area that needs to be considered otherwise traffic will be dropped.

When asked Snap Internet said:

The reason it is limited to 1492 MTU is that because of our extensive customer base we have VLANs set up through our core devices this means we have to reduce the total MTU size so that our devices can actually forward the frames. VLAN header is 4 bytes and we are using QinQ so that is the 8 bytes you are talking about. MTU is irrelevant for TCP connections anyway as TCP window size works it out automatically. Yes it does support up to 1600 bytes but standard core network infrastructure for ISPs does not. This is just a fail safe to make sure it works.

The 1600byte MTU supported by the Telcom Wholesale EUBA network gives enough headroom over a 1500byte MTU to allow encapsulation of traffic inside VLANs, tunnels, etc.

1500bytes Snap Core network
- 8bytes QinQ
= 1492bytes
PPPoE customer MTU
- 20bytes IPv4 header
- 20bytes TCP header
= 1452bytes
or 1440bytes
IPv4 TCP MSS filling ATM cells [optional]

This means the Dialer interface must have an MTU of 1492bytes or less, and the Vlan interface must have an IPv4 TCP MSS adjustment to 1452bytes or less.


The COS has to be marked on the ATM interface. Using the 'set cos' policy class-map directive doesn't seem to work, and the 'set inner-cos' directive is required.

Using set cos generates the following error:

Process 'set' action associated with class-map voice failed: Set cos supported only with IEEE 802.1Q/ISL interfaces


  • Native EUBA with PPPoE works ok, but the MTU goes down from 1500 to 1492
  • Too early for 802.1p COS
  • Too early for native IPv6 over DSL
  • The Cisco 877 router really really struggles with ADSL2+ bandwidth.






ATM ping

Use an ATM end to end ping to verify the PVC is provisioned and operational

#ping atm interface atm 0.110 0 110

Type escape sequence to abort.
Sending 5, 53-byte end-to-end OAM echoes, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/11/16 ms

Sample IPv4 PPP negotiation

 padi timer expired
Sending PADI: vc=0/110
PPPoE 0: I PADO  R:0090.1aa3.5e48 L:0022.9098.e85b 0/110  vlan 10 ATM0.110
 PPPOE: we've got our pado and the pado timer went off
OUT PADR from PPPoE Session
PPPoE 6748: I PADS  R:0090.1aa3.5e48 L:0022.9098.e85b 0/110  vlan 10 ATM0.110
IN PADS from PPPoE Session
%DIALER-6-BIND: Interface Vi2 bound to profile Di1
PPPoE: Virtual Access interface obtained.
PPPoE : encap string prepared
[0]PPPoE 6748: data path set to PPPoE Client
%LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up
Vi2 PPP: Sending cstate UP notification
Vi2 PPP: Processing CstateUp message
PPP: Alloc Context [84EE8410]
ppp10 PPP: Phase is ESTABLISHING
Vi2 PPP: Using dialer call direction
Vi2 PPP: Treating connection as a callout
Vi2 PPP: Session handle[E400000A] Session id[10]
Vi2 LCP: Event[OPEN] State[Initial to Starting]
Vi2 PPP: No remote authentication for call-out
Vi2 LCP: O CONFREQ [Starting] id 1 len 10
Vi2 LCP:    MagicNumber 0x2DB77ED2 (0x05062DB77ED2)
Vi2 LCP: Event[UP] State[Starting to REQsent]
Vi2 LCP: I CONFREQ [REQsent] id 133 len 14
Vi2 LCP:    AuthProto PAP (0x0304C023)
Vi2 LCP:    MagicNumber 0x31D127D8 (0x050631D127D8)
Vi2 LCP: O CONFACK [REQsent] id 133 len 14
Vi2 LCP:    AuthProto PAP (0x0304C023)
Vi2 LCP:    MagicNumber 0x31D127D8 (0x050631D127D8)
Vi2 LCP: Event[Receive ConfReq+] State[REQsent to ACKsent]
Vi2 LCP: I CONFACK [ACKsent] id 1 len 10
Vi2 LCP:    MagicNumber 0x2DB77ED2 (0x05062DB77ED2)
Vi2 LCP: Event[Receive ConfAck] State[ACKsent to Open]
Vi2 PPP: Phase is AUTHENTICATING, by the peer
Vi2 PAP: Using hostname from interface PAP
Vi2 PAP: Using password from interface PAP
Vi2 PAP: O AUTH-REQ id 1 len 42 from ""
Vi2 LCP: State is Open
Vi2 PAP: I AUTH-ACK id 1 len 5
Vi2 PPP: Phase is FORWARDING, Attempting Forward
Vi2 PPP: Phase is ESTABLISHING, Finish LCP
Vi2 PPP: Phase is UP
Vi2 IPCP: Protocol configured, start CP. state[Initial]
Vi2 IPCP: Event[OPEN] State[Initial to Starting]
Vi2 IPCP: O CONFREQ [Starting] id 1 len 22
Vi2 IPCP:    Address (0x030600000000)
Vi2 IPCP:    PrimaryDNS (0x810600000000)
Vi2 IPCP:    SecondaryDNS (0x830600000000)
Vi2 IPCP: Event[UP] State[Starting to REQsent]
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up
Vi2 IPCP: I CONFNAK [REQsent] id 1 len 22
Vi2 IPCP:    Address (0x03067BFF28BE)
Vi2 IPCP:    PrimaryDNS (0x8106CA256501)
Vi2 IPCP:    SecondaryDNS (0x8306CA256502)
Vi2 IPCP: O CONFREQ [REQsent] id 2 len 22
Vi2 IPCP:    Address (0x03067BFF28BE)
Vi2 IPCP:    PrimaryDNS (0x8106CA256501)
Vi2 IPCP:    SecondaryDNS (0x8306CA256502)
Vi2 IPCP: Event[Receive ConfNak/Rej] State[REQsent to REQsent]
Vi2 IPCP: I CONFACK [REQsent] id 2 len 22
Vi2 IPCP:    Address (0x03067BFF28BE)
Vi2 IPCP:    PrimaryDNS (0x8106CA256501)
Vi2 IPCP:    SecondaryDNS (0x8306CA256502)
Vi2 IPCP: Event[Receive ConfAck] State[REQsent to ACKrcvd]
Vi2 IPCP: I CONFREQ [ACKrcvd] id 159 len 10
Vi2 IPCP:    Address (0x03066F451044)
Vi2 IPCP: Accept the peer address
Vi2 IPCP: O CONFACK [ACKrcvd] id 159 len 10
Vi2 IPCP:    Address (0x03066F451044)
Vi2 IPCP: Event[Receive ConfReq+] State[ACKrcvd to Open]
Vi2 IPCP: State is Open
Di1 IPCP: Install negotiated IP interface address
PPPoE : ipfib_encapstr  prepared
Di1 IPCP: Install default route thru
Di1 Added to neighbor route AVL tree: topoid 0, address
Di1 IPCP: Install route to
PPPoE : ipfib_encapstr  prepared

Sample RBE configuration

The following Cisco RBE configuration is not used, as Snap uses PPPoE. It is prvided for reference only.

interface ATM0
  description EUBA DSL
  no ip address

interface ATM0.110 point-to-point
  description EUBA PVC to Snap
  ip address dhcp
  atm route-bridged ip
  atm route-bridged ipv6
  ipv6 address dhcp
  ipv6 address autoconfig
  ipv6 enable
  ipv6 verify unicast reverse-path
  ipv6 dhcp client pd snap-prefix rapid-commit
  pvc euba 0/110
    encapsulation aal5snap
    bridge-dot1q encap 10


Document Actions