This example explains how to achieve additional equal-load-balancing for downlink traffic for dynamic L2TP sessions across multiple links with:
Note
-
This option is helpful when LNS cannot perform L2TP session ID based hashing (such as enhanced-hash-key > family inet > l2tp-tunnel-session-identifier ) for load-balancing sessions across multiple links between a single LNS & LAC node.
-
The configuration in this example is for an MX-LAC node. But LNS needs to be configured to accept L2TP tunnel requests from multiple LAC loopback IP addresses.
-
For multiple links between a single LAC & LNS pair, this solution will equally load balance uplink and downlink traffic between LAC and LNS.
-
The LNS tunnel information is provided via AAA RADIUS attributes, so RADIUS user examples are also included.
We can achieve the requirement outlined above with multiple loopback IP addresses configured under lo0 unit 0 family inet, and by using AAA attributes to set L2TP tunnel source IP addresses that are different from the lo0.0 IP addresses.
Steps:
-
Configure multiple IP addresses under lo0.0 and make one address as the primary and preferred address.
-
Using the Tunnel-Client-Endpoint attribute, set L2TP tunnel endpoints as different lo0.0 IP addresses with the same Tunnel-Preference value as in the RADIUS user example below. In both the L2TP tunnels, the destination remote IP address will be the same as shown in the RADIUS user example that follows.
-
Thus the L2TP tunnel will be formed in a shared/round-robin manner between multiple loopback IP addresses but with the same remote L2TP destination (LNS) IP address. This will change the source/destination IP address in the L2TP tunnel and allow better downlink traffic load balancing.
Topology
|--(ge-0/0/0)<----> RADIUS Server(192.168.40.26)
IPv4 PPPoE subs.<---->([vlan 3320]ge-0/0/2) MX (ge-0/0/1)<----> LNS Server1(10.1.100.21)
|--(ge-0/0/3)<------>|
The RADIUS Server (@192.168.40.26) is reachable via the global routing instance inet.0 table.
Configuration
Dynamic L2TP session (LNS tunnel information via AAA attributes) with static default LNS tunnel at BRAS (LAC) node:
services {
l2tp {
destination-equal-load-balancing; ## Enables equal load balance of L2TP sessions between LNSs
failover-within-preference; ## Enables failover between same preference LNSs
destination;
access-line-information;
}
}
forwarding-options {
load-balance {
indexed-load-balance;
}
enhanced-hash-key {
family inet {
incoming-interface-index; ## Includes incoming interface index into hash key
l2tp-tunnel-session-identifier; ## Includes L2TP tunnel and session ID into hash key
}
}
}
access {
profile ACCESS-FTTH { ## Access-profile name
accounting-order radius;
authentication-order radius;
radius {
authentication-server 192.168.40.26;
options {
accounting-session-id-format description;
client-authentication-algorithm direct;
}
}
radius-server {
192.168.40.26 {
port 1812; ## RADIUS Authentication port number
accounting-port 1813; ## RADIUS accounting port number
dynamic-request-port 3799; ## RADIUS CoA/dynamic-request port number
secret "$ABC123"; ## SECRET-DATA
source-address 192.168.40.6; ## Source IP address to be used for RADIUS messages
}
}
}
domain { ## Map domain-id with access-profile, pool, dynamic-profile
map default { ## Default domain map; matches all/no domain-id
access-profile ACCESS-FTTH;
dynamic-profile PPPoE;
}
delimiter "@"; ## Delimiter character to identify start of domain-id
}
}
dynamic-profiles {
PPPoE {
routing-instances { ## Enables PPPoE/LAC subscribers inside VRF
“$junos-routing-instance” {
interface “$junos-interface-name” {
any;
}
}
}
interfaces {
pp0 {
unit “$junos-interface-unit” {
actual-transit-statistics;
ppp-options {
chap;
pap;
mtu 1492; ## PPP mtu to be set during authentication
}
pppoe-options {
underlying-interface “$junos-underlying-interface”;
server; ## Enables to accept PPPoE/LAC connection
}
family inet {
unnumbered-address “$junos-loopback-interface”;
}
}
}
}
}
}
interfaces {
lo0 {
unit 0 {
family inet {
address 10.1.100.1/32 {
primary;
preferred;
}
address 10.1.100.2/32;
address 10.1.100.3/32;
address 10.1.100.4/32;
....
}
}
}
ge-0/0/2 {
hierarchical-scheduler maximum-hierarchy-levels 2;
flexible-vlan-tagging;
unit 3320 { ## Static unit no. for static VLAN subscriber int.
encapsulation ppp-over-ether;
vlan-id 3320; ## Single stack(dot1q) static VLAN ID for incoming PPPoE
pppoe-underlying-options {
dynamic-profile PPPoE;
}
}
}
}
RADIUS User Example for Dynamic L2TP Tunnel
User example for equal load-balancing of downlink traffic (with same Tunnel-Preference value for equal load-balance)
client21@domain Auth-Type := Local, User-Password := "pass”
Service-Type = Framed-User,
Framed-Protocol = PPP,
Tunnel-Type:1 = L2TP,
Tunnel-Medium-Type:1 = IP,
Tunnel-Server-Endpoint:1 = "10.1.100.21",
Tunnel-Password:1 = "pass1234",
Tunnel-Client-Auth-ID:1 = "lac_1",
Tunnel-Server-Auth-ID:1 = "lns",
Tunnel-Preference:1 = 100,
Tunnel-Client-Endpoint:1 = "10.1.100.1",
Tunnel-Type:2 += L2TP,
Tunnel-Medium-Type:2 += IP,
Tunnel-Server-Endpoint:2 += "10.1.100.21",
Tunnel-Password:2 += "pass1234",
Tunnel-Client-Auth-ID:2 += "lac_1",
Tunnel-Server-Auth-ID:2 += "lns",
Tunnel-Preference:2 += 100,
Tunnel-Client-Endpoint:2 += "10.1.100.2"
client23@domain Auth-Type := Local, User-Password := "pass”
Service-Type = Framed-User,
Framed-Protocol = PPP,
Tunnel-Type:1 = L2TP,
Tunnel-Medium-Type:1 = IP,
Tunnel-Server-Endpoint:1 = "10.1.100.21",
Tunnel-Password:1 = "pass1234",
Tunnel-Client-Auth-ID:1 = "lac_1",
Tunnel-Server-Auth-ID:1 = "lns",
Tunnel-Preference:1 = 100,
Tunnel-Client-Endpoint:1 = "10.1.100.1",
Tunnel-Type:2 += L2TP,
Tunnel-Medium-Type:2 += IP,
Tunnel-Server-Endpoint:2 += "10.1.100.21",
Tunnel-Password:2 += "pass1234",
Tunnel-Client-Auth-ID:2 += "lac_1",
Tunnel-Server-Auth-ID:2 += "lns",
Tunnel-Preference:2 += 100,
Tunnel-Client-Endpoint:2 += "10.1.100.2"