Cisco 800 configuration for EUBA PPPoE with ISP Snap Internet

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:

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.

IPv6

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.

EUBA PPPoE

Snaps implementation of EUBA over the Telecom Wholesale service is:

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:

pvc euba 0/110

interface ATM0.110 point-to-point
  pvc euba 0/110
    pppoe-client dial-pool-number 1

interface ATM0.110 point-to-point
  pvc euba 0/110
    bridge-dot1q encap 10

interface Dialer0
  mtu 1492
interface vlan 1
  ip tcp adjust-mss 1452

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

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
  exit-vc
exit


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 username@snap.net.nz password 0 big-long-password
exit

MTU

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.

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.

COS

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

Conclusions

• 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.
  

Links

General

• SNAP VDSL trial writeup (Nick MacKechnie)
• IFM Cookbook samples
• QOS Intro
• PPPoE
• World Exchange Sample IPv6 877 config
  

Cisco

• PPP over Ethernet Client

• Transporting VLAN Tags Over DSL Links

• 802.1P CoS Bit Set for PPP and PPPoE Control Frames
• Michael Lin - QOS Presentation
• TCP MSS Adjustment
• Zone-Based Policy Firewall, Technical Discussion
• Zone Firewall TCP reassembly size
• Zone Based Firewall (ZBFW) Troubleshooting Command List

• Cisco Integrated Firewall Solutions

• Cisco IOS Firewall Performance Guidelines for Cisco Integrated Services Routers

CPE

• http://www.getipv6.info/index.php/Broadband_CPE#DSL

Appendices

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 "username@snap.net.nz"
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 0.0.0.0 (0x030600000000)
Vi2 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Vi2 IPCP:    SecondaryDNS 0.0.0.0 (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 123.255.40.190 (0x03067BFF28BE)
Vi2 IPCP:    PrimaryDNS 202.37.101.1 (0x8106CA256501)
Vi2 IPCP:    SecondaryDNS 202.37.101.2 (0x8306CA256502)
Vi2 IPCP: O CONFREQ [REQsent] id 2 len 22
Vi2 IPCP:    Address 123.255.40.190 (0x03067BFF28BE)
Vi2 IPCP:    PrimaryDNS 202.37.101.1 (0x8106CA256501)
Vi2 IPCP:    SecondaryDNS 202.37.101.2 (0x8306CA256502)
Vi2 IPCP: Event[Receive ConfNak/Rej] State[REQsent to REQsent]
Vi2 IPCP: I CONFACK [REQsent] id 2 len 22
Vi2 IPCP:    Address 123.255.40.190 (0x03067BFF28BE)
Vi2 IPCP:    PrimaryDNS 202.37.101.1 (0x8106CA256501)
Vi2 IPCP:    SecondaryDNS 202.37.101.2 (0x8306CA256502)
Vi2 IPCP: Event[Receive ConfAck] State[REQsent to ACKrcvd]
Vi2 IPCP: I CONFREQ [ACKrcvd] id 159 len 10
Vi2 IPCP:    Address 111.69.16.68 (0x03066F451044)
Vi2 IPCP: Accept the peer address 111.69.16.68
Vi2 IPCP: O CONFACK [ACKrcvd] id 159 len 10
Vi2 IPCP:    Address 111.69.16.68 (0x03066F451044)
Vi2 IPCP: Event[Receive ConfReq+] State[ACKrcvd to Open]
Vi2 IPCP: State is Open
Di1 IPCP: Install negotiated IP interface address 123.255.40.190
PPPoE : ipfib_encapstr  prepared
Di1 IPCP: Install default route thru 111.69.16.68
Di1 Added to neighbor route AVL tree: topoid 0, address 111.69.16.68
Di1 IPCP: Install route to 111.69.16.68
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