Router Installation and Configuration Manual/Configuring L2TP as LNS
From ImageStream Router Documentation
L2TP tunnels client PPP sessions from the telco's LAC (access concentrator) to the ISP's LNS. L2TP uses a IP/UDP tunnel on port 1701 to encapsulate the PPP frames and tunnel them over an IP network. L2TP can be tunneled across the internet if needed but most setups generally have the telco providing a dedicated GigE port or dedicated DS3/OC3 to each LNS cluster for carrying the L2TP sessions. Most of the larger setups use 3 LNS routers per cluster with each LNS carrying between 2,000 to 3,000 customers. These 8,000 to 9,000 customers will fully utilize the GigE port during peak times with each LNS sending about 350 Mbps toward the customers.
For load balancing and redundancy the LAC normally is configured with a list of LNS IPs. Often LACs in a certain region will be configured to send to a particular cluster of LNS IPs. The LAC will round-robin between the LNS routers automatically as new client PPP sessions are established. If an LNS goes down all PPP sessions on that LNS will terminate or eventually time out and re-establish on other active LNSs in the cluster. The LAC (Cisco does but Juniper doesn't) will cache the status of previous LNS connection attempts.
Client -> PPPoA DSL link -> Telco LAC -> L2TP tunnel -> ISP LNS (our box)
The client starts up a PPP session to the LAC (telco's access concentrator). PPP LCP is established. The client then authenticates by sending a username in the form of firstname.lastname@example.org. The LAC looks up ispdomain.com in its L2TP tunnel configuration to find the next LNS IP in the lsit. If an L2TP tunnel does not yet exist to the LNS the LAC will establish one. Our router will accept the tunnel request if the LAC's configuration (L2TP password/LAC name) matches our configuration. These L2TP tunnel settings are specified by the telco.
Once the L2TP tunnel is established the LAC sends the client's PPP authenticate request to the LNS. At this point we start up a PPP session and authenticate the user via RADIUS. Normal PPP negotiations continue from this point with IP address negotiation and such. The end result is the client now has a PPP session tunneled over an L2TP/IP/UDP tunnel from the telco's LAC to our LNS router.
The L2TP configuration is very simple:
! interface Loopback0 ip address 184.108.40.206 255.255.255.255 ! interface Tunnel0 description vlan1220 tunnel mode l2tp tunnel peer name default tunnel local name isnet tunnel key h18sJ98l tunnel virtual-template 1 ! interface Virtual-Template1 ip unnumbered Loopback0 peer default ip pool pool1 radius-server host 220.127.116.11 acct-port 1813 auth-port 1812 key password acct-interval 3600 radius-server host 18.104.22.168 acct-port 1813 auth-port 1812 key password acct-interval 3600 ppp authentication pap chap mtu 1500 ! ip local pool pool1 22.214.171.124 126.96.36.199 ip local pool pool1 188.8.131.52 184.108.40.206 ip local pool pool1 220.127.116.11 18.104.22.168 ip name-server 22.214.171.124 ip name-server 126.96.36.199
For this example the telco would specify our local name as gbnet and our password as h18sJ98l. The telco also specified the use of VLAN 1220 and our IP range of 10.15.0.2 - 10.15.0.6 for our LNS cluster. Our telco also specifies a 1600 byte MTU on the GigE port to avoid IP fragmentation of large frames being tunneled.
# L2TP sessions come in to us on VLAN 1220 via Ethernet1. Bell uses a 1600 byte MTU on their GigE # interfaces to avoid IP fragmentation overhead when tunneling large frames. interface Ethernet1 no ip address speed 1000 duplex full mtu 1600 ! interface Ethernet1.1220 mtu 1600 description vlan1220 3AGAS ip address 10.15.0.2 255.255.255.248 !