Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Example: Configuring the Broadband Edge as a Service Node Within Seamless MPLS Network Designs

This example details the steps required to configure broadband edge seamless MPLS with head-end termination for residential subscriber management deployment. Step-by-step instructions are provided for each device in the example configuration.

This section includes the following information:

Requirements

Table 1 lists the role of each device in the configuration example topology and includes the hardware used for each device. All MX Series devices in this example were tested with Juniper Networks Junos OS Release 13.3R3, which is considered the minimum software revision required.

Table 1: Device Hardware

Device

Hardware

R0 (primary BNG) serves as the primary MPLS pseudowire termination head-end provider edge and subscriber management platform for DHCP and PPPoE, and for the L2TP access concentrator (LAC).

Chassis: MX960

Routing Engine (RE) 0 - RE1: RE-S-1800x4

Flexible PIC Concentrator 0 (FPC0)-FPC7: Modular Port Concentrator (MPC) Type 2 3D EQ

R3 (backup BNG) becomes the primary BNG if the current primary BNG (R0) fails.

Chassis: MX960

RE0-RE1: RE-S-1800x4

FPC0-FPC7: MPC Type 2 3D EQ

R1 and R2 (access and aggregation routers) serve as Access Node (AN) and Metro pre-aggregation provider edge platforms for the MPLS pseudowire tunnel-based backhaul entry point.

Chassis: MX80/MX104

TFEB 0: Packet Forwarding Engine Processor

FPC 0-FPC 1: MPC BUILTIN

R4 serves as the core router.

Chassis: T640

RE0-RE1: RE-A-2000

FPC 0: E-FPC Type 3

FPC 1: E-FPC Type 1

FPC 2: E-FPC Type 2

SIB 0-SIB 4: SIB-I8-F16

R5 (L2TP Network Server [LNS]) serves as the L2TP tunnel and session termination point for broadband wholesale service.

Chassis: MX480

RE0: RE-S-2000

FR1: RE-S-2000

FPC 0-FPC 1: MPC Type 2 3D EQ

RADIUS server provides subscriber authentication and accounting.

FreeRADIUS version 2.1.5 on an Intel/Linux server

Overview

In this example, a specific traffic model is utilized, characterized as follows:

  • Pseudowire tunnels are LDP-signaled MPLS L2 circuits from access PE to BNG.

  • On the BNG core side, forwarding is based on MPLS transport within a single autonomous system using OSPF and OSPFv3 as the interior gateway protocols. Alternatively, ISIS could also be used.

  • Subscriber traffic is backhauled over MPLS pseudowires to the MX Series BNG configured for pseudowire head-end termination.

  • Each home has five subscriber sessions total: four subscribers (IP sessions) and one VLAN session.

    • DHCPv4 for VoIP service with 128,000 committed information rate (CIR) (strict priority)

    • DHCPv6 prefix delegation (PD) for VOD service with 20 million CIR (medium priority)

    • PPPoEv4 for Internet service (low priority)

    • PPPoEv6 Neighbor Discovery Router Advertisement (NDRA) for game service (low priority)

  • There are four priority queues per home.

  • GRE tunnels are used for Subscriber Secure Policy traffic forwarding.

  • The upstream and downstream traffic rates are each 50 Mbps per home.

  • The dedicated customer VLAN (C-VLAN) model is applied (each home has a unique VLAN). The VLANs are provisioned dynamically based on incoming subscriber traffic.

The following scaling parameters apply to this example configuration:

  • A total of 50,000 homes are configured; 10 percent of those (5000) have L2TP sessions.

  • There are 2048 pseudoservice (PS) interfaces (pseudowire tunnel anchor interfaces) on the BNG.

  • There are 25 homes assigned to each pseudowire tunnel.

  • There are 256 pseudowires per MPC (128 per Packet Forwarding Engine [PFE]).

  • There are 256 pseudowires per MPC for eight MPCs in a fully loaded MX960 chassis, equaling 2048 Layer 2 (L2) circuits per chassis (to support the 50,000 homes).

  • There is one BFD session for each L2 circuit.

  • One percent of the homes (500 homes) have Subscriber Secure Policy to forward mirrored subscriber traffic to a GRE tunnel.

Note:

The seamless MPLS with pseudowire head-end termination use case is valuable for both business and residential subscribers. In this tested example, only residential subscribers are included.

Network resiliency for this configuration example includes:

  • Graceful Routing Engine switchover (GRES) for Routing Engine failover

  • ISSU

  • Path protection (node down, interchassis failover)

  • Local protection (link down, intrachasses failover)

  • Flexible PIC Concentrator (FPC) failure

  • Routing down

  • L2 circuits down

MPLS fast reroute and Bidirectional Forwarding Detection (BFD) recovery methods are used.

Topology

Figure 1 illustrates the topology of this example configuration, including the MPLS and dual stack scope.

Figure 1: TopologyTopology

In this example, the access and aggregation provider edge (access PE) systems (R1 and R2) are directly connected and multihomed to the active and backup BNG systems. The purpose of the PE devices in this example is to emulate 1000 active MPLS pseudowires and another group of 1000 backup MPLS pseudowires toward the active and backup BNG systems.

The BNG device acts as the MPLS service node, terminating MPLS pseudowires and performing subscriber management functions. For PPP traffic, the BNG device supports LAC function forwarding to LNS over L2TP tunnels. For DHCP (IPoE) traffic, the BNG device terminates sessions directly.

The core router (R4) aggregates the two BNG systems (R0 and R3). The configuration for the core router in this example is basic, intended only to provide BNG MPLS pseudowire head-end termination, and support broadband subscriber termination.

The RADIUS server performs Point-to-Point (PPP) subscriber authentication, authorization, and accounting (AAA), and triggers the activation of service profile configuration parameters such as filters and class of service (CoS) parameters.

The LNS system (R5) is directly connected to the core routing system. It terminates the L2TP tunnel to provide high-speed interface wholesale service to retailer and ISP customers. The configuration used here is a basic example that demonstrates the BNG system’s ability to relay PPP traffic to the LNS system using the L2TP tunnel.

Configuration

The following sections present configuration information for the devices included in the example from left to right in the topology diagram. The sections include CLI quick configuration (for copy and paste), step-by-step instructions, and show command output that confirms the configuration.

Configuring the Access/Aggregation Router, R1

CLI Quick Configuration

Figure 2 highlights the access/aggregation routers (R1 and R2) in the context of the reference example topology.

Figure 2: Access/Aggregation Routers in the TopologyAccess/Aggregation Routers in the Topology

To quickly configure R1 as in this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure R1:

  1. Configure the interfaces.

    The loopback and BNG-facing interfaces have inet (IPv4) family addresses to enable OSPF and LDP.

    1. Configure the loopback interface.

      The PE system’s primary address is configured under a loopback interface.

    2. Configure the BNG-facing interfaces for both the primary and backup BNG devices.

      Two ports are connected to the primary BNG (BNG1), and two are connected to the backup BNG (BNG2). The configuration includes IPv4 (inet) and MPLS family addresses to support IP/MPLS network connectivity.

  2. Configure the access ports for MPLS pseudowire circuits.

    In this example, one PE device has five access ports emulating access node connections, which are used for MPLS pseudowire circuit interfaces. To configure multiple VLAN values, the vlan-id-range command is used. Each VLAN interface is associated with an MPLS pseudowire on a one-to-one mapping basis.

  3. Configure the MPLS pseudowire L2 circuit connections, including:

    • Ethernet encapsulation type and the ignore MTU mismatch option. These are required because the MPLS pseudowire service (PS) interface supports MPLS pseudowire type 5 mode (Ethernet encapsulation) at the BNG head-end.

    • The backup MPLS pseudowire, which is the backup neighbor and virtual circuit ID for failover to the backup BNG system in the event of MPLS pseudowire failure detection.

    • BFD for MPLS pseudowire reachability. MPLS pseudowire data plane failure detection uses the BFD protocol.

    The configuration for two ports is shown here. Repeat this step for all access-facing ports.

  4. Configure the routing protocols.

    OSPF is enabled for IPv4 routing; LDP is enabled for MPLS label exchange.

    1. Configure the router ID.

    2. Enable MPLS.

      Configure MPLS for all interfaces connected to the BNG-facing ports.

    3. Configure OSPF to support IPv4 routing.

      To simplify OSPF area configuration, you can often use the interface all option. In this example, however, the use of specific interface names ensures that only the relevant interfaces are included in OSPF.

    4. Enable LDP for MPLS label exchange.

      To support targeted LDP, configure LDP for the BNG-facing ports and loopback interface.

Results

From configuration mode, confirm your configuration by entering the following show commands:

  1. Confirm the loopback interface configuration.

  2. Confirm the BNG-facing interface configuration.

  3. Confirm the access port configuration for the MPLS pseudowire circuits.

  4. Confirm the backup MPLS pseudowire configuration.

  5. Confirm that MPLS is enabled on the interfaces.

  6. Confirm the OSPF configuration.

  7. Confirm the LDP configuration.

Configuring the Access/Aggregation Router, R2

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide for Junos OS.

To configure R2:

  1. Configure the interfaces.

    The loopback and BNG-facing interfaces have inet (IPv4) family addresses to enable OSPF and LDP.

    1. Configure the loopback interface.

      The PE system’s primary address is configured under a loopback interface.

    2. Configure the BNG-facing interfaces for both the primary and backup BNG devices.

      Two ports are connected to the primary BNG (BNG1), and two are connected to the backup BNG (BNG2). The configuration includes IPv4 (inet) and MPLS family addresses to support IP/MPLS network connectivity.

  2. Configure the access ports for MPLS pseudowire circuits.

    In this example, one PE device has five access ports emulating access node connections, which are used for MPLS pseudowire circuit interfaces. To configure multiple VLAN values, the vlan-id-range command is used. Each VLAN interface is associated with an MPLS pseudowire on a one-to-one mapping basis.

  3. Configure the MPLS pseudowire L2 circuit connections, including:

    • Ethernet encapsulation type and the ignore MTU mismatch option. These are required because the MPLS pseudowire service (PS) interface supports MPLS pseudowire type 5 mode (Ethernet encapsulation) at the BNG head-end.

    • The backup MPLS pseudowire, which is the backup neighbor and virtual circuit ID for failover to the backup BNG system in the event of MPLS pseudowire failure detection.

    • BFD for MPLS pseudowire reachability. MPLS pseudowire data plane failure detection uses the BFD protocol.

    The configuration for two ports is shown here. Repeat this step for all access-facing ports.

  4. Configure the routing protocols.

    OSPF is enabled for IPv4 routing; LDP is enabled for MPLS label exchange.

    1. Configure the router ID.

    2. Enable MPLS.

      Configure MPLS for all interfaces connected to the BNG-facing ports.

    3. Configure OSPF to support IPv4 routing.

      To simplify OSPF area configuration, you can often use the interface all option. In this example, however, the use of specific interface names ensures that only the relevant interfaces are included in OSPF.

    4. Enable LDP for MPLS label exchange.

      To support targeted LDP, configure LDP for the BNG-facing ports and loopback interface.

Results

From configuration mode, confirm your configuration by entering the following show commands:

  1. Confirm the loopback interface configuration.

  2. Confirm the BNG-facing interface configuration.

  3. Confirm the access port configuration for the MPLS pseudowire circuits.

  4. Confirm the MPLS pseudowire L2 circuit connections configuration.

  5. Confirm the MPLS configuration.

  6. Confirm the OSPF configuration.

  7. Confirm the LDP configuration.

Configuring BNG Router, R0

CLI Quick Configuration

Figure 3 highlights the BNG routers (R0 and R3) in the context of the reference example topology.

Figure 3: BNG Routers in the TopologyBNG Routers in the Topology

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide for Junos OS.

To configure the R0 BNG router:

  1. Enable dynamic profiles to use multiple versions.

    You can create new versions of dynamic profiles that are currently in use by subscribers. Any subscriber that logs in following a dynamic profile modification uses the latest version of the dynamic profile. Subscribers that are already active continue to use the older version of the dynamic profile until they log out or their session terminates.

    Note:

    You must enable or disable dynamic profile version creation before creating or using any dynamic profiles on the router. Enabling or disabling dynamic profile version creation after dynamic profiles are configured is not supported.

  2. Create the client profile interfaces.

  3. Configure the dynamic PPPoE client profile.

    To enable the router to create a dynamic PPPoE subscriber interface on a PPPoE underlying interface, define the attributes of the PPPoE logical interface in a dynamic profile, and then configure the underlying interface to use the dynamic profile.

  4. Configure the CoS forwarding classes and map them to queues.

  5. Configure the dynamic VLAN profiles.

    Create dynamic VLAN profiles, including defaults for predefined variables, dynamic physical interfaces, and CoS parameters.

    1. Configure defaults for the predefined variables.

    2. Configure the dynamic physical interfaces.

    3. Configure the router advertisement.

    4. Configure the CoS traffic control profiles.

    5. Configure the CoS scheduler maps.

    6. Configure the CoS schedulers.

  6. Create DHCP service profiles.

    1. Set the service profile variables.

    2. Create the dynamic interfaces for the DHCP service profiles and associate the filters.

  7. Create the PPPoE service profiles.

    1. Set the PPPoE service profile variables.

    2. Create the dynamic interfaces for the PPPoE service profiles and associate the filters.

  8. Configure DHCP.

    Unlike traditional broadband service configuration that is tied to physical interfaces such as gigabit Ethernet or aggregated Ethernet, this solution configuration relies on pseudowire interfaces and virtual Ethernet ports for broadband subscriber termination.

    All dynamically created VLANs over pseudowire interfaces in this solution configuration are allowed to process DHCP messages coming in through MPLS pseudowire subscriber tunnels and arriving at pseudowire anchor interfaces.

    1. Dual stack PPPoE sessions—enable DHCPv6 for PPPoE sessions.

    2. DHCPv4 sessions—configure the IPv4 local server group for pseudowire interfaces.

      Assign the group a password, a username prefix, and a dynamic profile. Associate pseudowire interfaces with the group. Two pseudowires are shown here. Repeat this step for all pseudowire interfaces.

    3. DHCPv6 sessions—configure the IPv6 local server group for pseudowire interfaces.

      Assign the group a password, a username prefix, and a dynamic profile. Associate pseudowire interfaces with the group. This enables DHCPv6 subscriber authentication using VLAN over pseudowire subscriber interfaces. Two pseudowires are shown here. Repeat this step for all pseudowire interfaces.

  9. Configure graceful switchover and device count.

    1. Configure the primary Routing Engine to switch over gracefully to the backup Routing Engine without interruption to packet forwarding.

    2. Configure the number of pseudowire logical devices available to the router.

    3. Delay removal of access routes and access-internal routes after graceful Routing Engine switchover, and establish a high threshold for resource monitoring.

    4. Enable configuration synchronization between Routing Engines.

  10. Configure the pseudowire tunnel services at the chassis level.

    Configure the amount of bandwidth for tunnel services and enable CoS queuing, scheduling, and shaping on flexible PIC concentrators 0 through 4 (4 is not used).

    One flexible PIC concentrator is shown. Repeat this step for all remaining flexible PIC concentrators.

  11. Attach an access profile to all DHCP and PPPoE subscribers.

    When a DHCP or PPPoE subscriber logs in, the specified access profile is instantiated and the services defined in the profile are applied to the subscriber.

  12. Configure a loopback interface, transit links, and logical tunnel interfaces.

    In the context of this solution configuration, transit links are Ethernet ports connecting the BNG device to an access/aggregation device. They are the access-facing interfaces; subscriber sessions (VLAN, PPPoE, DHCP) are not terminated or anchored on them. Logical tunnel (LT) interfaces serve as termination and anchor interfaces for the logical subscriber sessions. The LT interfaces are underlying interfaces for the pseudowire subscriber interface construct, as shown in Figure 4.

    Figure 4: Pseudowire Subscriber Interface Protocol StackPseudowire Subscriber Interface Protocol Stack
    1. Configure a loopack interface.

    2. Configure the transit links.

    3. Configure the LT interfaces that correspond to the transit links.

  13. Configure the pseudoservice interfaces and auto-sensed dynamic VLAN.

    Subscriber management supports the creation of subscriber interfaces over point-to-point MPLS pseudowires. The pseudowire subscriber interface capability enables service providers to extend an MPLS domain from the access-aggregation network to the service edge, where subscriber management is performed. Service providers can take advantage of MPLS capabilities such as failover, rerouting, and uniform MPLS label provisioning, while using a single pseudowire to service a large number of DHCP and PPPoE subscribers in the service network.

    The pseudowire is a tunnel that is either an MPLS-based L2 VPN or L2 circuit. The pseudowire tunnel transports Ethernet encapsulated traffic from an access node (for example, a DSLAM or other aggregation device) to the MX Series router that hosts the subscriber management services. The termination of the pseudowire tunnel on the MX Series router is similar to a physical Ethernet termination, and is the point at which subscriber management functions are performed. A service provider can configure multiple pseudowires on a per-DSLAM basis and then provision support for a large number of subscribers on a specific pseudowire.

    At the access node end of the pseudowire, the subscriber traffic can be groomed into the pseudowire in a variety of ways, limited only by the number and types of interfaces that can be stacked on the pseudowire. Specify an anchor point, which identifies the logical tunnel interface that terminates the pseudowire tunnel at the access node.

    1. Configure the PS interfaces and VLAN authentication.

      One pseudowire is shown. Repeat this step for all remaining pseudowires.

    2. Configure the routing options.

  14. Configure the L2 circuit connections.

    Configuration for one pseudoservices interface (ps0.0) is shown. Repeat this step for ps1.0 through ps2047.0.

  15. Configure the routing protocols.

    This configuration example utilizes MPLS, OSPF, OSPFv3, and LDP on the BNG routers.

    1. Configure MPLS.

    2. Configure OSPF and OSPFv3.

    3. Configure LDP.

  16. Configure the routing policy.

  17. Configure the firewall filters.

    1. Configure the input, output, and RPF DHCP filters for IPv4.

    2. Configure the input, output, and RPF DHCP filters for IPv6.

  18. Configure access to the RADIUS server and DNS.

  19. Configure the access profiles for RADIUS authentication and accounting.

  20. Configure the IPv4 and IPv6 address assignment pools.

    1. Configure the IPv4 address pools.

    2. Configure the IPv6 address pools.

    3. Configure address protection.

  21. Configure tunnel profiles.

    1. Configure the attributes of a tunnel profile.

    2. Configure the domain maps for the tunnel profile.

      The BNG LAC component uses domain maps to initiate L2TP sessions without RADIUS interaction. Optionally, RADIUS can be used for PPP authentication and to dynamically provide L2TP tunnel attributes such as tunnel destination.

Results

From configuration mode, confirm your configuration by entering the following show commands:

  1. Confirm the dynamic profile version creation configuration.

  2. Confirm the client profile interface configuration.

  3. Confirm the dynamic PPPoE client profile configuration.

  4. Confirm the CoS forwarding class queue configuration.

  5. Confirm the dynamic VLAN profile configuration.

  6. Confirm the DHCP service profile configuration.

  7. Confirm the PPPoE service profile configuration.

  8. Confirm the DHCP local server configuration.

  9. Confirm the graceful switchover and device count configuration.

  10. Confirm the pseudowire tunnel service configuration.

  11. Confirm the loopback interface, transit link, and logical tunnel interface configuration.

  12. Confirm the PS interface and VLAN authentication configuration.

  13. Confirm the L2 circuit connections.

  14. Confirm the routing protocol configuration.

  15. Confirm the policy statement configuration.

  16. Confirm the firewall settings configuration.

  17. Confirm the RADIUS server and DNS access configuration.

  18. Confirm the access profile configuration.

  19. Confirm the address assignment pool configuration.

  20. Confirm the tunnel profile configuration.

Configuring BNG Router, R3

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide for Junos OS.

To configure the R3 BNG router:

  1. Enable dynamic profiles to use multiple versions.

    You can create new versions of dynamic profiles that are currently in use by subscribers. Any subscriber that logs in following a dynamic profile modification uses the latest version of the dynamic profile. Subscribers that are already active continue to use the older version of the dynamic profile until they log out or their session terminates.

    Note:

    You must enable or disable dynamic profile version creation before creating or using any dynamic profiles on the router. Enabling or disabling dynamic profile version creation after dynamic profiles are configured is not supported.

  2. Create the client profile interfaces.

  3. Configure the dynamic PPPoE client profile.

    To enable the router to create a dynamic PPPoE subscriber interface on a PPPoE underlying interface, define the attributes of the PPPoE logical interface in a dynamic profile, and then configure the underlying interface to use the dynamic profile.

  4. Configure the CoS forwarding classes and map them to queues.

  5. Configure the dynamic VLAN profiles.

    Create dynamic VLAN profiles, including defaults for predefined variables, dynamic physical interfaces, and CoS parameters.

    1. Configure defaults for the predefined variables.

    2. Configure the dynamic physical interfaces.

    3. Configure router advertisement.

    4. Configure the CoS traffic control profiles.

    5. Configure the CoS scheduler maps.

    6. Configure the CoS schedulers.

  6. Create DHCP service profiles.

    1. Set the service profile variables.

    2. Create the dynamic interfaces for the DHCP service profiles and associate the filters.

  7. Create the PPPoE service profiles.

    1. Set the PPPoE service profile variables.

    2. Create the dynamic interfaces for the PPPoE service profiles and associate the filters.

  8. Configure DHCP.

    Unlike traditional broadband service configuration that is tied to physical interfaces such as gigabit Ethernet or aggregated Ethernet, this solution configuration relies on pseudowire interfaces and virtual Ethernet ports for broadband subscriber termination.

    All dynamically created VLANs over pseudowire interfaces in this solution configuration are allowed to process DHCP messages coming in through MPLS pseudowire subscriber tunnels and arriving at pseudowire anchor interfaces.

    1. Dual stack PPPoE sessions—enable DHCPv6 for PPPoE sessions.

    2. DHCPv4 sessions—configure the IPv4 local server group for pseudowire interfaces.

      Assign the group a password, a username prefix, and a dynamic profile. Associate pseudowire interfaces with the group. Two pseudowires are shown here. Repeat this step for all pseudowire interfaces.

    3. DHCPv6 sessions—configure the IPv6 local server group for pseudowire interfaces.

      Assign the group a password, a username prefix, and a dynamic profile. Associate pseudowire interfaces with the group. This enables DHCPv6 subscriber authentication using VLAN over pseudowire subscriber interfaces. Two pseudowires are shown here. Repeat this step for all pseudowire interfaces.

  9. Configure graceful switchover and device count.

    1. Configure the primary Routing Engine to switch over gracefully to the backup Routing Engine without interruption to packet forwarding.

    2. Configure the number of pseudowire logical devices available to the router.

    3. Delay removal of access routes and access-internal routes after graceful Routing Engine switchover, and establish a high threshold for resource monitoring.

    4. Enable configuration synchronization between Routing Engines.

  10. Configure the pseudowire tunnel services at the chassis level.

    Configure the amount of bandwidth for tunnel services on flexible PIC concentrators 0 through 3.

    One flexible PIC concentrator is shown. Repeat this step for all remaining flexible PIC concentrators.

  11. Attach an access profile to all DHCP subscribers.

    When a DHCP subscriber logs in, the specified access profile is instantiated and the services defined in the profile are applied to the subscriber.

  12. Configure the transit links and logical tunnel interfaces.

    1. Configure a loopack interface.

    2. Configure the transit links.

    3. Configure the LT interfaces that correspond to the transit links.

  13. Configure the PS interfaces and VLAN authentication.

    Subscriber management supports the creation of subscriber interfaces over point-to-point MPLS pseudowires. The pseudowire subscriber interface capability enables service providers to extend an MPLS domain from the access-aggregation network to the service edge, where subscriber management is performed. Service providers can take advantage of MPLS capabilities such as failover, rerouting, and uniform MPLS label provisioning, while using a single pseudowire to service a large number of DHCP and PPPoE subscribers in the service network.

    The pseudowire is a tunnel that is either an MPLS-based L2 VPN or L2 circuit. The pseudowire tunnel transports Ethernet encapsulated traffic from an access node (for example, a DSLAM or other aggregation device) to the MX Series router that hosts the subscriber management services. The termination of the pseudowire tunnel on the MX Series router is similar to a physical Ethernet termination, and is the point at which subscriber management functions are performed. A service provider can configure multiple pseudowires on a per-DSLAM basis and then provision support for a large number of subscribers on a specific pseudowire.

    At the access node end of the pseudowire, the subscriber traffic can be groomed into the pseudowire in a variety of ways, limited only by the number and types of interfaces that can be stacked on the pseudowire. Specify an anchor point, which identifies the logical tunnel interface that terminates the pseudowire tunnel at the access node.

    1. Configure the PS interfaces and VLAN authentication.

      One pseudowire is shown. Repeat this step for all remaining pseudowires.

    2. Configure the routing options.

  14. Configure the L2 circuit connections.

    Configuration for one pseudoservices interface (ps0.0) is shown. Repeat this step for ps1.0 through ps2047.0.

  15. Configure the routing protocols.

    This configuration example utilizes MPLS, OSPF, OSPFv3, and LDP on the BNG routers.

    1. Configure MPLS.

    2. Configure OSPF and OSPFv3.

    3. Configure LDP.

  16. Configure the routing policy.

  17. Configure the firewall filters.

    1. Configure the input, output, and RPF DHCP filters for IPv4.

    2. Configure the input, output, and RPF DHCP filters for IPv6.

  18. Configure the RADIUS server and DNS access.

  19. Configure the access profiles for RADIUS authentication and accounting.

  20. Configure the IPv4 and IPv6 address assignment pools.

    1. Configure the IPv4 address pools.

    2. Configure the IPv6 address pools.

    3. Configure address protection.

Results

From configuration mode, confirm your configuration by entering the following show commands:

  1. Confirm the dynamic profile version creation configuration.

  2. Confirm the client profile interface configuration.

  3. Confirm the dynamic PPPoE client profile configuration.

  4. Confirm the CoS forwarding class queue configuration.

  5. Confirm the dynamic VLAN profile configuration.

  6. Confirm the DHCP service profile configuration.

  7. Confirm the PPPoE service profile configuration.

  8. Confirm the DHCP local server configuration.

  9. Confirm the graceful switchover and device count configuration.

  10. Confirm the pseudowire tunnel service configuration.

  11. Confirm the transit link and logical tunnel interface configuration.

  12. Confirm the PS interface and VLAN authentication configuration.

  13. Confirm the L2 circuit connections.

  14. Confirm the routing protocol configuration.

  15. Confirm the policy statement configuration.

  16. Confirm the firewall settings configuration.

  17. Confirm the RADIUS server and DNS access configuration.

  18. Confirm the access profile configuration.

  19. Confirm the address assignment pool configuration.

Configuring the Core Router, R4

CLI Quick Configuration

Figure 5 highlights the core router (R4) in the context of the reference example topology.

Figure 5: LNS Device in the TopologyLNS Device in the Topology

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide for Junos OS.

To configure Device R4:

  1. Configure the interfaces.

    The loopback and BNG-facing interfaces support both IPv4 (inet) and IPv6 (inet6) address families for a dual stack routing environment. The LNS-facing interfaces do not include IPv6 family addressing because IPv6 traffic is overlaid over the L2TP tunnel that has only IPv4 source and destination.

    1. Configure the loopback interface.

    2. Configure BNG-facing interfaces for both the active and backup BNG devices.

      The configured ports for each BNG device pass traffic between the core network and the active BNG device.

  2. Configure the routing protocols.

    OSPF is enabled to support IPv4 routing; OSPFv3 is enabled to support IPv6 routing.

    1. Configure the router ID.

    2. Configure OSPF for IPv4 routing.

    3. Configure OSPFv6 for IPv6 routing.

    4. Configure MPLS for all interfaces connected to BNG-facing and LNS-facing ports.

      IPv6 MPLS tunneling allows IPv6 routes to be resolved over an MPLS network by converting LDP and RSVP routes stored in the inet.3 routing table to IPv4-mapped IPv6 addresses, and then copying them into the inet6.3 routing table. The inet6.3 routing table can be used to resolve next hops for both inet6 and inet6-vpn routes.

    5. Enable MPLS LDP signaling.

      Configure LDP for BNG-facing and access PE-facing ports. Enabling LDP on the loopback interface is necessary for end-to-end MPLS L2 circuit service.

Results

From configuration mode, confirm your configuration by entering the following show commands:

  1. Confirm the interface configuration.

  2. Confirm the routing protocol configuration.

Configuring the LNS Router, R5

CLI Quick Configuration

Figure 6 highlights the LNS device (R5) in the context of the reference example topology.

Figure 6: LNS Device in the TopologyLNS Device in the Topology

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the ../../../../../../.

To configure Device R5:

  1. Configure the interfaces.

    The loopback and retailer and ISP-facing interfaces support both IPv4 (inet) and IPv6 (inet6) address families for a dual stack routing environment. The core-facing interfaces do not include IPv6 family addressing because IPv6 traffic is overlaid over the L2TP tunnel that has only IPv4 source and destination.

    1. Configure the LNS system’s primary address under a loopback interface.

    2. Configure the core-facing interfaces.

      The two configured ports pass traffic between the LNS device and the core networks.

    3. Configure the retailer and ISP-facing interfaces.

      The two configured ports pass traffic between the LNS, and retailer and ISP networks.

  2. Configure the routing protocols.

    OSPF is enabled to support IPv4 routing; OSPFv3 is enabled to support IPv6 routing.

    1. Configure the router ID.

    2. Configure OSPF for IPv4 routing.

    3. Configure OSPFv3 for IPv6 routing.

    4. Enable MPLS .

      Configure MPLS for all core-facing interfaces.

    5. Enable LDP.

  3. Configure the LNS components.

    L2TP traffic is processed using the inline service capability of the general network interface module rather than a dedicated service module. Line modules, therefore, process both L2TP and non-L2TP traffic.

    1. Enable inline services.

      Configure the bandwidth assigned for the inline service of the module.

    2. Configure the dynamic profile.

      Configure the dynamic profile required for dynamic configuration of L2TP session interface characteristics.

    3. Configure the access group profile.

      Configure the characteristics of the PPP protocol running over the L2TP tunnel.

    4. Configure the L2TP client profile.

      Configure the L2TP client (LAC) characteristics, which are used to configure PPP link layer characteristics.

    5. Configure the RADIUS server access.

    6. Configure the authorization, authentication, and accounting (AAA) profile.

      Configure an access profile for incoming L2TP AAA calls.

    7. Configure global L2TP services.

      Configure an L2TP tunnel group profile that contains the L2TP gateway’s local address configuration and refers to other previously configured profiles for L2 and L3 network characteristics.

    8. Configure the address pools.

      The local inet address pool is used for subscriber end devices (CPE, desktop, and so on) to obtain IPv4 addresses using PPP IPCP negotiation. The local inet6 address pool is used for subscriber end devices to obtain IPv6 prefixes using DHCPv6.

  4. Configure DHCPv6.

    Enable DHCPv6 message processing on the L2TP session interface (si-0/0/0 interface). PPP provides interface ID (link local address) exchange for IPv6 support, but it does not provide global routable IPv6 prefixes. DHCPv6 protocol is employed for IPv6 prefix allocation.

  5. Secure a policy for traffic mirroring.

    Configure a RADIUS protocol-based per-subscriber traffic mirror so that an external authority can enable traffic mirroring on a specific subscriber session.

    1. Enable inline tunnel services.

    2. Enable inet (IPv4) and inet6 (IPv6) address families.

    3. Enable the RADIUS flow-tap service.

      For information about flow-tap, see Flow-Tap Architecture.

Results

  1. Confirm the interface configuration.

  2. Confirm the routing protocol configuration.

  3. Confirm the inline service configuration.

  4. Confirm the dynamic profile configuration.

  5. Confirm the access group profile configuration.

  6. Confirm the L2TP client profile configuration.

  7. Confirm the RADIUS server configuration.

  8. Confirm the AAA profile configuration.

  9. Confirm the global L2TP services configuration.

  10. Confirm the IPv4 and IPv6 address pool configuration.

  11. Confirm the DHCPv6 configuration.

  12. Confirm the inline tunnel services configuration for traffic mirroring.

  13. Confirm that inet and inet6 address families are enabled.

  14. Confirm that the RADIUS flow-tap service is enabled.

Configuring the User Profile for the RADIUS Server

Step-by-Step Procedure

Figure 7 highlights the RADIUS server in the context of the reference example topology.

Figure 7: RADIUS Server in the Topology RADIUS Server in the Topology

To configure the user profile for the RADIUS server:

  1. Include the following service activation RADIUS attributes in the user profile configuration:

Verification

The following sections show how to verify that the configuration is working properly. Within each group, verification steps are listed for the devices from left to right in the example topology.

Verify Route Summary Information

Purpose

Confirm that destinations and routes are functional:

  • On R1, confirm inet, MPLS, and L2 circuit destinations and routes on router ID 101.0.0.1.

  • On R2, confirm inet, inet6, MPLS, and L2 circuit destinations and routes on router ID 102.0.0.1.

  • On R0, confirm inet, inet6, MPLS, and L2 circuit destinations and routes on router ID 100.0.0.1.

  • On R4, confirm inet, inet6, and MPLS destinations and routes on router ID 104.0.0.1.

  • On R5, confirm inet, inet6, and MPLS destinations and routes on router ID 105.0.0.1.

Action

On each device, run the show route summary command from operational mode.

Meaning

Destinations and routes are functional.

Verify the Loopback and Physical Ports

Purpose

On each device, test connections to the loopback and physical ports.

Action

On each device, run the show interfaces command from operational mode for each port to confirm the interfaces are Up. Then run the ping command to verify communication with each interface.

Meaning

Loopback and physical port interfaces are functional and communicating.

Verify OSPF and OSPF3 Functionality

Purpose

On each device, display OSPF and OSPF3 (when applicable) interface, neighbor, and route information to ensure all entities are functioning correctly.

Action

On each device, run the show ospf interface, show ospf neighbor, and show route protocol ospf | match /32 commands from operational mode.

On each device with OSPF3 configuration, also run the show ospf3 interface, show ospf3 neighbor, and show route table inet6.0 | match /128 commands.

Meaning

OSPF and OSPF3 interfaces, neighbors, and routes are functioning properly.

Verify LDP Functionality

Purpose

On each device, display LDP interface and neighbor information to confirm the entities are functioning correctly.

Action

On each device, run the show ldp interface and show ldp neighbor commands from operational mode.

Meaning

LDP interfaces and neighbors are operational.

Verify MPLS Interfaces

Purpose

On each device, display MPLS interface information to confirm the interfaces are Up.

Action

On each device, run the show mpls interface command from operational mode.

Meaning

MPLS interfaces are operational.

Verify Circuit Cross-Connect (CCC) Interfaces and L2 Circuits on R1, R2, and R0

Purpose

Display L2 circuit and BFD session information to confirm the interfaces and sessions are functioning properly.

Action

On R1, R2, and R0, run the show interfaces terse | match ccc | count, show l2circuit connections summary, show l2circuit connections interface ge-1/0/2.1, show bfd session summary, and show bfd session detail commands from operational mode. The output of the show bfd session detail command is truncated in this example.

Meaning

CCC and L2 circuit interfaces are operational.

Verify Logical Tunnel (LT) Interfaces on R0 and R3

Purpose

Display logical tunnel interfaces to ensure they are Up.

Action

On R0 and R3 (from operational mode), run the show interfaces terse | match lt command to confirm the LT interfaces are Up. Then run the show interfaces terse command for each individual interface to display more detailed information. One interface for each device is shown here. Repeat for additional interfaces as needed.

Meaning

LT interfaces are all confirmed to be Up.

Verify Pseudoservice (PS) Interfaces on R0 and R3

Purpose

Display pseudoservice interfaces to ensure they are Up.

Action

On R0 and R3, run the show interfaces ps0 terse command from operational mode to confirm the PS interfaces are Up.

Meaning

PS interfaces are up and running.

Verify DHCPv4 Over Dynamic VLAN Interfaces on R0

Purpose

Display DHCPv4 subscriber and other DHCPv4 over dynamic VLAN information to ensure the interfaces are functioning.

Action

From operational mode, run the show subscribers, show dhcp server binding, show subscribers detail, show route protocol access-internal, show firewall, show class-of-service traffic-control-profile, and show class-of-service scheduler-hierarchy interface ps0.1073741855 commands.

Meaning

DHCPv4 over dynamic VLAN interfaces are operational.

Verify DHCPv6-PD Over Dynamic VLAN Interfaces on R0

Purpose

Display DHCPv6-PD subscriber and other DHCPv6-PD over dynamic VLAN information to ensure the interfaces are functioning.

Action

From operational mode, run the show subscribers, show dhcpv6 server binding, show subscribers detail, show route table inet6.0 protocol access, show firewall, show class-of-service traffic-control-profile, and show class-of-service scheduler-hierarchy interface ps0.1073741856 commands.

Meaning

DHCPv6-PD over dynamic VLAN interfaces are operational.

Verify PPPoE Over Dynamic VLAN Interfaces on R0

Purpose

Display PPPoE subscriber and other PPPoE over dynamic VLAN information to ensure the interfaces are functioning.

Action

From operational mode, run the show subscribers, show subscriber summary, show subscribers detail, show pppoe interfaces, show route protocol access-internal, show firewall, show class-of-service traffic-control-profile, and show class-of-service scheduler-hierarchy interface ps0.1073741859 commands.

Meaning

PPPoE over dynamic VLAN interfaces are operational.

Verify DHCP-PD Over PPPoE Over Dynamic VLAN Interfaces on R0

Purpose

Display PPPoE subscriber, DHCPv6 server binding, and inet6 route table information to ensure the interfaces are functioning.

Action

From operational mode, run the show subscribers, show subscriber summary, show dhcpv6 server binding, show subscribers detail, and show route table inet6.0 protocol access commands.

Meaning

DHCPv6-PD over PPPoE over dynamic VLAN interfaces are operational.

Verify LAC PPP over Dynamic Interfaces on R0

Purpose

Display subscriber, network access AAA, and L2TP services information to ensure the interfaces are functioning.

Action

From operational mode, run the show subscribers, show subscriber summary, show subscribers detail, show network-access aaa subscribers, show network-access aaa subscribers session-id 67, show network-access aaa subscribers session-id 67 detail, show network-access aaa subscribers session-id 68, show network-access aaa subscribers session-id 68 detail, show services l2tp summary, show services l2tp destination, show services l2tp tunnel, show services l2tp session, show services l2tp destination extensive, show services l2tp tunnel extensive, and show services l2tp session extensive commands.

Meaning

LAC PPP over dynamic VLAN interfaces are operational.

Verify the AAA Access and RADIUS Server Configuration and Statistics on R0

Purpose

Display RADIUS server, domain map, and AAA information to ensure that AAA and RADIUS are functioning as expected.

Action

From operational mode, run the show network-access aaa accounting, show network-access aaa radius-servers detail, show network-access domain-map statistics, show network-access aaa statistics authentication, show network-access aaa statistics authentication detail, show network-access aaa statistics accounting, show network-access aaa statistics accounting detail, show network-access requests statistics, show network-access requests pending, show network-access aaa statistics pending-accounting-stops detail, and show network-access aaa statistics radius commands.

Meaning

AAA and RADIUS server functions are correct.

Verify That on R3, No L2 Circuits Are Up and No BFD Sessions Are Running

Purpose

Display L2 circuit and BFD session information to confirm nothing is running on the backup BNG (R3).

Action

From operational mode, run the show interfaces terse | match ccc | count, show l2circuit connections summary, show l2circuit connections interface ps0.0, show bfd session summary, and show bfd session detail commands.

Meaning

No L2 circuits or BFD sessions are running on the backup BNG.

Verify L2TP Functionality on R5

Purpose

Display subscriber, network access AAA, and L2TP services information to ensure the interfaces are functioning.

Action

From operational mode, run the show subscribers, show subscriber summary, show subscribers detail, show network-access aaa subscribers, show network-access aaa subscribers session-id 9, show network-access aaa subscribers session-id 9 detail, show route protocol access internal, show firewall, show services l2tp summary, show services l2tp destination, show services l2tp tunnel, show services l2tp session, show services l2tp destination extensive, show services l2tp tunnel extensive, and show services l2tp session extensive commands.

Meaning

L2TP LAC PPP over dynamic VLAN interfaces are operational.

Verify Dynamic VLAN Authentication and Accounting on the RADIUS Server

Purpose

Determine whether or not RADIUS messages sent by the BNG arrive at the RADIUS server and are accepted.

Action

Review the RADIUS server debug log messages to confirm whether RADIUS messages arrive and are processed. If a subscriber username and password match the user profile on the RADIUS server, the RADIUS server should return an access-accept message response back to the BNG system. If the RADIUS server returns an access-reject message, check the username and password configuration on both the RADIUS server and the BNG DHCP local server, and check the PPPoE client’s username and password.

The following debug log messages are related to straight dynamic VLAN authentication and accounting requests.

The following debug log messages are related to DHCPv4 over dynamic VLAN authentication and accounting requests.

The following debug log messages are related to DHCPv6 over dynamic VLAN authentication and accounting requests.

The following debug log messages are related to PPPoE over dynamic VLAN authentication and accounting requests.

The following debug log messages are related to LAC PPP over dynamic VLAN interface requests.

Meaning

Dynamic VLAN authentication and accounting functionality is confirmed.

Troubleshooting

This troubleshooting section focuses on pseudowire head-end termination and subscriber management on the BNG platform. To troubleshoot these functions, see the following sections.

Note:

For information on using traceoptions, see Junos OS Tracing and Logging Operations.

MPLS L2 Circuit Pseudowire

Problem

MPLS L2 circuit pseudowires are not being established.

Solution

  1. On the BNG device, investigate each network layer’s operational status and error count. Start by ensuring that the operational status is Up for both Layer 1 (L1) and L2, and that the error count is not increasing.

  2. If the interface is a PS interface, check the status of the anchor interface as well.

  3. Next, check the IP connectivity of the directly connected interface.

  4. Determine whether the IGP is stable, without any route flapping. The OSPF neighbor state should be Full and the age of the OSPF database and route table should increase consistently without resetting to be zero. The IP connectivity to the neighbor router’s loopback interface should be intact.

  5. Next, check the BFD session status for MPLS L2 circuit pseudowires.

  6. Examine the MPLS pseudowire datapath.

  7. Finally, verify that the MPLS L2 circuit status is Up. If it is not, consult the connection status code legend provided in the show command output for the reason.

Subscriber Sessions

Problem

Subscriber sessions are not being established.

Solution

  1. First, check the AAA status. Start by using the test aaa command to ascertain the authentication and address assignment operational status.

  2. Check the RADIUS server’s operational status and statistics.

  3. Monitor incoming and outgoing subscriber protocol control traffic via the PS interface. Start by checking the subscriber access protocol negotiation status.

  4. To monitor L2 header information, use the monitor traffic command with the layer2 option.