Alcatel Lucent SRC Triple Play Lab Guide Download v2.2

Alcatel-Lucent Internal Use only -- Do not Distribute
Alcatel-Lucent Triple Play Services Lab Guide

Version 2.2
March 2010
Alcatel-Lucent Triple Play Services Lab Guide v2.2 1/106

All rights reserved © 2010 Alcatel-Lucent
Table of Contents
TRIPLE PLAY LAB TOPOLOGY ........................................................................................ 3
LAB 1 LAB INFRASTRUCTURE ........................................................................................ 4
LAB 2 CONFIGURING BRIDGED CO COMPONENTS................................................................. 6

LAB 3 TRIPLE PLAY MULTICAST ON BRIDGED CO................................................................10
LAB 4 CONFIGURING ROUTED CO COMPONENTS ................................................................15
LAB 5 TRIPLE PLAY SECURITY ON A BRIDGED CO ARCHITECTURE ...........................................18
LAB 6 VRRP CORE REDUNDANCY WITH BRIDGED CO............................................................23
LAB 7 SRRP CORE REDUNDANCY ON ROUTED CO ...............................................................26
LAB 8 ESM ON BRIDGED CO ..........................................................................................30
LAB 9 ESM ON ROUTED CO...........................................................................................42
LAB 10 MANAGED SAP ON ROUTED CO ............................................................................49
APPENDIX A REMOTE ACCESS PC AND APPLICATION FAMILIARIZATION.....................................52
APPENDIX B SETTING UP A PPPOE SESSION FROM A WINDOWS PC ..........................................63
APPENDIX C MULTICAST VPLS REGISTRATION (MVR) ...........................................................80
APPENDIX D CONFIGURING A LOCAL DHCP SERVER.............................................................81
LAB SOLUTIONS ........................................................................................................83

Triple Play Lab Topology

Pod1 Pod2 R10 (BSAN2)
R9 (BSAN1)
R5 (BSA1) R6 (BSA2)
R1 (BSR1) R2 (BSR2)
RADIUS
Video Server
Server R3 (BSR3) R4 (BSR4)
R7 (BSA3) R8 (BSA4)
R12 (BSAN4)
R11 (BSAN4)
Pod3 Pod4

Lab 1 Lab Infrastructure
Objective
The focus of Lab 1 is to create the Lab topology that will be used in this course. OSPF will be used for
the IGP and RSVP will be used to signal the MPLS LSPs..
Configuration

Use the diagram given by the instructor that reflects the physical topology of the lab setup.
1. Name the routers in your pod.

2. Configure the IOMs and MDAs.
3. Configure the required ports.
4. Create the necessary interfaces (including the interface facing the VLC video server on R1).
5. Install OSPF on all BSR and BSA interfaces.
6. Create SDPs between the BSAs and BSRs using RSVP signaled loose path LSPs for the transport
tunnels.
Verification
1. Verify that the ports, OSPF adjacencies, LSPs, and SDPs are operationally up.

Lab 1 Command list
configure system name <name>
configure card <iom-slot> card-type <card-type>
configure card <iom-slot> mda <mda-slot> mda-type <mda-type>
configure port <iom/mda/port> [no] shutdown
configure router interface <name> port <port>
configure router interface <name> address <address>

configure ospf area 0 interface <interface>
configure service sdp <sdp-id> mpls create
configure service sdp <sdp-id> far-end <IP-address>
show port
show router interface
show router route-table
show router ospf interface
show router mpls lsp
show router mpls lsp path detail
show service id <service-id> base
show service id <service-id> sdp detail
Notes

Lab 2 Configuring Bridged CO Components
Objective
The focus of this lab is to use a “Bridged CO” triple play solution. This lab will focus on unicast traffic.
Each pod has a BSAN that is simulated with a Service Router that uses a VPLS to connect each PC to the
BSA with correct SAP encapsulation. The PC will simulate a Residential Gateway (RG) in the Home
Network.
In order to route traffic from the RGs, IES services have to be configured on the BSRs. A unicast VPLS

on the BSA is single homed to an IES interface on the BSR. Although an infrastructure (SDP & LSPS) for
redundancy does exist it will not be used until Lab 6 – VRRP Core Redundancy with Bridged CO.
BSR1 will install a Local DHCP Server and distribute it into OSPF to provide the IP address allocation for
all pods.
Configuration
Use the diagram given by the instructor that reflects the physical topology of the lab setup for all
service names and IP addresses not specifically mentioned in the steps below:
1. On BSR1 only, a local DHCP Server has been configured as shown below. All BSRs in the pod will
relay DHCP messages to this DHCP server which is responsible for IP address allocation for all pods.
Verify that subnet pools are defined for all pods. For example, Pod1 has the subnet of
192.168.215.0/24, specify a default router of 192.168.215.2 which belongs to BSR1. This default
router will need to be changed in the VRRP lab. Bind the DHCP server to a loopback interface with
an address of 10.99.99.1/32
router
dhcp
local-dhcp-server "srcDhcpServer" create
use-gi-address
pool "srcDhcpPool1" create
subnet 192.168.215.0/24 create
options
default-router 192.168.215.2
exit
address-range 192.168.215.5 192.168.215.10
exit
options
exit
address-range 192.168.219.5 192.168.219.10
exit
options
exit
address-range 192.168.223.5 192.168.223.10
exit
options
exit
address-range 192.168.227.5 192.168.227.10
exit
exit
no shutdown
exit

interface "localDhcpLoop1"
address 10.99.99.1/32
loopback
local-dhcp-server "srcDhcpServer"
exit
ospf
traffic-engineering
area 0.0.0.0
exit
exit
exit

2. Verify that two local VPLS services have been pre-configured on each BSAN. The first VPLS is used
to provide the correct encapsulation for the first PC in each pod. It has a service id of 100 and a
VLAN encapsulation of 100 towards the BSA. The second VPLS is used to provide the correct
encapsulation for the second PC in each pod. It has a service id of 200 and a VLAN encapsulation of
200 towards the BSA.
3. On each BSA, create a VPLS to handle unicast traffic. The VPLS should have two SAPs for the two
PCs in each pod and a spoke SDP towards the BSR. Use the supplement given by the instructor to
determine the service names and IP addresses to use.
4. On each BSR, create an IES interfaces to terminate the spoke SDP coming from the BSA. Make sure
the VC-ids and service MTUs match on the IES and VPLS.
5. Include the IES interfaces into the IGP as passive.
6. Create a DHCP relay in the IES interface configuration. Use a gi-address the same as the IES
interface IP address. The DHCP server will use this gi-address for subnet-matching. Use an IP
address of 10.99.99.1 for the DHCP server.
ies 214 customer 1 create

interface "toUC10" create
address 192.168.215.2/24
dhcp
server 10.99.99.1
gi-address 192.168.215.2
no shutdown
exit
ip-mtu 1500
spoke-sdp 215:10 create
exit
exit
no shutdown
exit
Verification
1. Verify that all services, SDP bindings, and SAPs are operationally up on the BSAN, BSA, and BSR of
each pod.
2. On each BSR, verify that the IES interfaces are in the OSPF routing table.
3. Initiate a DHCP request by releasing and then renewing the Windows PC lab connection. The PCs
have two network interface cards, one connected to the BSAN and one connected to the mgmt
network. Be careful not to release the mgmt NIC otherwise access to the PC may be lost!
4. Debug the DHCP requests on the BSR using “debug router ip dhcp”. What kinds of packets appear?

5. Ensure that the following ping command from the following sources to the destinations work
6. Ping from the first PC in each pod to the IP address of the respective IES interface.
7. Ping from the second PC in each pod to the IP address of the respective IES interface.
8. Ping between IES interfaces.
9. Ping between PC1 and PC2 of your pod.
a. On BSR1, use the command “show router dhcp local-dhcp-server srcDhcpServer leases”
to view the lease information on the local DHCP server as each pod releases and
renews their IP addresses.

b. Verify the FDB on the VPLS on each of the nodes. How many entries exist in the tables
and why?
Lab 2 command list

configure port <iom/mda/port> ethernet mode access
configure port <iom/mda/port> ethernet encap-type dot1q
configure service vpls <service-id> customer <customer-id> create
configure service vpls <service-id> sap <sap-id> create
configure service vpls <service-id> spoke-sdp <sdp-id:vc-id> create
configure service vpls <service-id> [no] shutdown
configure service ies <service-id> customer <customer-id> create
configure service ies <service-id> interface <name> create
configure service ies <service-id> interface <name> address <IP—address>
configure service ies <service-id> interface <name> spoke-sdp <sdp-id> create
configure service ies <service-id> interface <name> ip-mtu <mtu-value> create
configure service ies <service-id> interface <name> dhcp server <IP-address>
configure service ies <service-id> interface <name> dhcp [no] shutdown
configure service ies <service-id> [no] shutdown
show service service-using
show service id <service-id> all
show service id <service-id> fdb detail
show service id <service-id> sdp detail
debug router ip dhcp
show router dhcp statistics
show router dhcp local-dhcp-server <name> leases
show router ospf interface
Notes


Lab 3 Triple Play Multicast on Bridged CO
Objective
The focus of this lab is to configure multicast traffic on the Bridged CO Architecture used in Lab 2. The
SRs that are simulating a BSAN in the network will use an MVR VPLS (see Appendix B) to deliver and
receive multicast traffic to the BSAs on a separate VLAN.
Configuration

1. On the BSAN create a new VPLS that is an MVR VPLS. This MVR VPLS will output and receive all
multicast traffic to the BSA on a sap with VLAN encapsulation of 400. Unicast traffic will not enter
this VPLS.
vpls 400 customer 1 create

description "multicast VPLS"
stp
shutdown
exit
igmp-snooping
mvr
no shutdown
exit
no shutdown
exit
sap 1/1/3:400 create
description "to BSA1 Multicast
VPLS"
igmp-snooping
mrouter-port
exit
exit
no shutdown
exit
2. On the BSAN, point the existing VPLS that was used for unicast traffic toward the MVR VPLS. This
will cause all multicast traffic to be filtered to the MVR VPLS and vice versa. Do this for both
unicast VPLS (VPLS 100 and VPLS 200) on each BSAN.

description "unicast vpls for PC1"
stp
shutdown
exit
exit
sap 1/1/1 create
igmp-snooping
send-queries
mvr
from-vpls 400
exit
exit
exit
no shutdown
exit

3. On the BSA create the multicast VPLS with a spoke SDP to the IES interface on the BSR that will be
created in the next step. There should also be a spoke SDP to the other connected BSA to form a
multicast distribution ring.

description "Bridged CO Multicast VPLS"
stp
shutdown
exit
description "multicast SAP towards BSAN"

exit
exit
exit
no shutdown
exit
4. Create a new interface in the BSR IES with an IP address from the diagram and a terminating spoke
SDP towards the BSA.

address 192.168.215.2/24
dhcp
server 10.99.99.1
gi-address 192.168.215.2
no shutdown
exit
ip-mtu 1500
exit
exit
interface "toMC100" create
address 192.168.100.214/24
ip-mtu 1500
exit
exit
no shutdown
exit
5. Add this interface to your IGP, IGMP (this is the first hop from the receivers perspective – an IGMP
Querier will be elected between the two BSRs) and PIM (a PIM DR will be elected on this subnet).
6. On BSR1, create a routed interface towards the VLC server and add this interface to PIM. BSR1 will
provide the video server for all BSRs and will also be the PIM Rendezvous Point.
7. On all BSRs, add all core interfaces and system interfaces into PIM. Select a static RP for
239.0.0.0/8, preferably the system address of the router connected to the multicast source (BSR1).
8. On the video server, enable a VLC source stream towards 239.1.1.1 (add a static route to the PCs
own interface on the Windows machine) and let the receivers listen to this address (using VLC).
Verification
1. Ensure that all the services (IES and VPLS) are up on the BSR and BSA nodes. Use the “show
service service-using” command on the respective nodes to verify that the services are up. If any
of the services are not operational, use the command:

a. show service id <svc-id> base
2. Verify that the RP is up and set to the address of BSR 1 node. The command “show router pim rp”
can be used to verify the RP status.
3. On BSA 1 and BSA 2, Verify that the Access PC has registered its multicast groups with the VPLS.
a. show service id <service-id> mfib
4. What port is the router port? Make sure the PIM DR receives the joins by using the mrouter-port
feature.

a. config service vpls 100 spoke- sdp <sdp-id:svc-id> igmp_snooping mrouter-port
5. On the BSR 1 and BSR 2, execute the following commands and verify their output:
a. show router pim interface
b. show router pim group detail
c. show router igmp interface
d. show router igmp group
6. Verify that the traffic is received on the PCs. Troubleshoot the IGMP, the IGMP Snooping and the
PIM technologies if the PCs are not receiving the video stream.
7. On the BSR nodes, execute a “show router igmp interface” to verify which interface is the IGMP
Querier.
8. What is the advantage of having an IGMP Querier? What are the responsibilities of the IGMP
Querier?
9. On the BSR nodes, execute a “show router pim interface” to verify which interface is the DR.
10. What is the advantage of having the PIM DR? What are the responsibilities of the PIM DR?
11. Execute a “show router pim group” on both BSRs. What kinds of MDTs are available?

Lab 3 command list
configure service vpls <service-id> igmp-snooping [no] shutdown
configure service vpls <service-id> igmp-snooping mvr [no] shutdown
configure service vpls <service-id> spoke-sdp <sdp-id:vc-id>
configure service vpls <service-id> sap <sap-id> igmp-snooping send-queries mvr from-vpls <service-id>
configure service ies <service-id> interface <name> address <IP-address>
configure service ies interface <name> spoke-sdp <sdp-id> create

configure router igmp interface <name>
configure router pim interface <name>
configure router pim rp static address <IP-address> group-prefix <group-prefix>
configure service vpls <service-id> spoke-sdp <sdp-id:svc-id> igmp_snooping mrouter-port
show service id <service-id> mfib
show router igmp group
show router pim goup
show router pim interface
show service id <service-id> igmp-snooping port-db sap <sap-id>
show service id <service-id> igmp-snooping mvr
Notes


Lab 4 Configuring Routed CO Components
Objective
The focus of this lab is on the Routed CO architecture where a BSA is not used for aggregation. In a
Routed CO architecture the BSAN is connected directly to the BSR. In this lab the Bridged CO setup
from the previous lab exercises will be converted to a Routed CO setup by adding an e-pipe on the BSA
to transparently connect the BSAN and BSR together. It is important to change as little configuration as
possible, as subsequent labs will switch between the Bridged CO and Routed CO setup.

Configuration
1. Configure an e-pipe on the BSA to transparently connect the BSAN and BSR together, simulating a
Routed CO solution. On the BSA, remove the SAPs from the unicast VPLS. The multicast VPLS can
be deleted as it is no longer required. Add a default SAP to the e-pipe. The interface facing the BSR
will need to be changed to an access port. Change as little configuration on the BSA as possible as a
Bridged CO configuration will be required in subsequent labs:
epipe 500 customer 1 create

sap 1/1/3:* create
exit
sap 1/1/1 create
exit
no shutdown
exit
no shutdown
exit
2. Make sure the chassis mode of the BSR is b or higher:

a. configure system chassis-mode b
3. On the BSR IES Service, add a subscriber-interface toRoutedCo<x >, where x is the number of your
unicast interface (for example toUC10, x = 10). On the unicast interface remove only the IP
address and gi-address configuration since this configuration will be required in subsequent labs
that use a Bridged CO architecture. Add the IP address to the subscriber interface and add a group
interface with SAPs for the PCs. The multicast interface is no longer required and can be removed.
4. Create an unnumbered group interface in this context with the DHCP relay pointing to the existing
DHCP server. Make the interface trusted.
subscriber-interface "toRoutedCo10" create
address 192.168.215.2/24
group-interface "toBSAN1" create
dhcp
server 10.99.99.1
trusted
gi-address 192.168.215.2
no shutdown
exit
description "sap for PC1"
exit
exit
exit
exit
exit
5. Put the subscriber interface into the IGP.

Verification
1. On the PCs initiate a new DHCP request. Ping the other PCs. Is the traffic going directly over the
VPLS or does it pass the BSR?
2. Execute a “show service id <service-id> subscriber-hosts detail”. This will list all the active
subscribers.
3. Check the detailed information on the BSR (“info detail”) for the Routed CO IES. Ensure that
“local-proxy-arp” is enabled by default and ensure that under each sap “antispoof ip-mac” is
enabled by default. Why?

4. Execute a “show router route-table” on the BSR nodes and ensure that the subscriber IP address is
listed as a ‘/32’ network.
5. On the BSR, verify the ARP table with the command “show router arp”.
Lab 4 command list

configure service vpls sap <sap-id> split-horizon-group <name> create
configure service vpls split-horizon-group <name> create
configure service vpls sap <sap-id> split-horizon-group <name> create
configure service ies <ies> subscriber-interface <name> group-interface <name>
configure service ies <ies> subscriber-interface <name> group-interface <name> dhcp
configure service ies <ies> subscriber-interface <name> group-interface <name> dhcp trusted
configure service ies <ies> subscriber-interface <name> group-interface <name> dhcp gi-address <IP-address>
configure service ies <ies> subscriber-interface <name> group-interface <name> dhcp lease-populate <leases>
configure service ies <ies> subscriber-interface <name> group-interface <name> dhcp server <IP-address>
configure service ies <ies> subscriber-interface <name> group-interface <name> sap <sap-id>
Notes


Lab 5 Triple Play Security on a Bridged CO Architecture
Objective
The objective of this lab is to use DHCP to implement security on a Bridged CO architecture. This lab
requires switching back to the Bridged CO configuration.
Exercise 5.1: Anti Spoofing Filter

Objective
Anti-spoofing tables can be constructed to prevent a malicious subscriber from using an IP address not
provided by the ISP. Anti-spoof is explicitly configured on the individual SAPs that require anti-
spoofing. In this lab the anti-spoof table is built dynamically using DHCP messages which requires which
requires DHCP snooping and DHCP lease state table construction to be enabled.
Configuration
1. In this lab, anti-spoof filters are built from DHCP lease state tables for valid RG customers,
simulated by two PCs per pod. This ensures that only traffic from the PC matching the IP-mac
combination of the anti-spoof filter is allowed into the corresponding VPLS. The spoofing PC will
attempt to send its traffic with an IP address not obtained from the ISP. This traffic will be
dropped.
2. The first step is to revert back to the Bridged CO configuration. On the BSA, remove the SAPs from
the e-pipe. Add the correct SAP back to the unicast VPLS, change the port facing the BSR back to a
network port and add it to the appropriate interface. Add the Unicast IES interface back into OSPF.
Again keep as much Routed CO configuration in tact as possible as Routed CO will be used again in
subsequent labs.

description "Bridged CO Unicast VPLS"
stp
shutdown
exit
exit
exit
exit
exit
no shutdown
exit
3. On the BSR, remove the gi-address from the group-interface and remove the IP address from the
subscriber-interface. If there are active DHCP leases for the PCs, either release the IP addresses
on the PCs or use the command “clear service id 214 dhcp lease-state”. The SAPs need to be
removed from the group interface. Also convert the port facing the BSA to a network port and add
it to the appropriate interface.

address 192.168.215.2/24
dhcp
server 10.99.99.1
gi-address 192.168.215.2
no shutdown
exit
ip-mtu 1500
exit
exit
4. Verify that both PC’s can get an IP address via DHCP and that all PCs can ping all other PCs.
5. Execute a “show router arp” on the BSRs to see the MAC-IP combinations.

6. Manually change the IP address of the second PC in each pod to another (unused) IP address on the
same subnet (using the IP address of the other PC will create a Windows IP conflict). The objective
is to show that a different IP address then obtained through DHCP can be used to send traffic
representing a security issue called spoofing.
7. Are the pings between PCs possible? Has the ARP entry changed on the BSR to another IP address
for the MAC address of the PC in question? Has spoofing been performed?
8. After this test, change the PC back to its original state (DHCP in stead of manual Static) and
initiate a new DHCP request.
9. Build the anti-spoofing tables from the DHCP lease state. Initiate a new DHCP request for each PC
(why?). Perform the spoofing test (change one of the PCs to an address different from the DHCP
address). Does the ping work now? Where do you apply these commands?
a. dhcp lease-populate
b. dhcp snoop
c. antispoof ip-mac
Verification
1. Verify that the anti-spoof filter is now built, use the command to display the contents of the anti-
spoof table. Verify that there are two entries per VPLS (two PCs)
a. show service id 10 subscriber-hosts
2. Observe the dependency between the anti-spoof filter and DHCP snooping, i.e. shut down DHCP on
any SAP and observe the DHCP lease state table.
3. Restore the DHCP configuration on the PCs.
4. Verify that the anti-spoof table is constructed after DHCP messaging and that traffic from the valid
RG is now accepted.
Notes

Exercise 5.2: Residential Split Horizon Groups and Proxy ARP
Objective
Up to now; all subscribers were able to communicate with each other and discover each other’s MAC
addresses in their broadcast domain. This exercise examines the advantages of using split horizon
groups to block subscriber to subscriber communication, and then uses the local proxy ARP feature on
the router to control subscriber to subscriber communication
Configuration
1. Configure both SAPs on the unicast VPLS to be in a residential split horizon group. For this the SAPS
have to be removed and reconfigured as part of the newly created residential split horizon group.
2. Initiate a new DHCP request.
Verification
1. Ensure that all PCs can ping the gateway address and their IES interface gateway addresses and
vice versa.
2. Can you ping the other PC in your pod now?
3. Configure local-proxy-arp on the unicast IES interfaces of each BSR.
4. Can you ping the other PC in your pod now? Why can they ping each other now?
5. Execute an “arp –a” command on your PC. What is the MAC address and IP address of the other PC
in your pod?
6. Clear the BSR ARP cache. Can you ping the PC from the IES interface? Why is this possible?
Shouldn’t the residential split horizon group SAPs block the downstream broadcast packets (such as
ARP)?

Notes

Exercise 5.3: ARP Reply Agent
Objective
When configuring a SAP for residential split horizon, the ARP Reply Agent feature is automatically
enabled. The feature allows the IES to ping the home RGs provided a DHCP lease state and anti-spoof
tables are constructed for the RGs on the BSA. By enabling ARP-reply agent on the SAPs, downstream
ARPs from the RGs are answered by the VPLS that contains the appropriate residential SAPS. The
exercise investigates the behavior of this feature.
Configuration
1. The last step of the previous lab indicated that the downstream ARP requests initiated from the IES
interfaces towards the PCs are answered by the ARP Reply Agent, which is by default enabled on
residential split horizon group SAPs.
2. Now disable arp-reply agent on the SAPs and clear the BSR ARP cache.
Verification
1. Initiate a ping to a PC. Does the ping work now? Why not?

Lab 5 command list
Configure service vpls <service-id> split-horizon-group <name> residential-group create
Configure service vpls <service-id> sap <sap-id> split-horizon-group <name> create
Configure service ies <service-id> interface <name> local-proxy-arp
Configure service vpls <service-id> sap <sap-id> host ip <IP-address> mac <MAC-address>
Configure service vpls <service-id> sap <sap-id> anti-spoof ip-mac
Configure service vpls <service-id> sap <sap-id> dhcp lease-populate

Configure service vpls <service-id> spoke-sdp <spoke-id > dhcp snoop
Configure service vpls <service-id> sap <sap-id> dhcp snoop
Configure service ies <service-id> interface <name> dhcp lease-populate <leases>
Configure servies ies <service-id> sap <sap-id>
show router arp
show service fdb-mac
clear router arp all
show service id <service-id> subscriber-hosts
Notes

Lab 6 VRRP Core Redundancy with Bridged CO
Objective
To construct redundancy between the BSR IES interfaces for the BSA unicast aggregation VPLS. This will
ensure that only one physical gateway IES is ever used for all the home RG traffic. The RG default
router address will be the logical VRRP address. In case of a gateway failure, the backup gateway IES
will take over. The home RG will be oblivious to the change. The local DHCP Server will need to be
changed to provide the new logical VRRP address as the default gateway to the home network.

Configuration
1. Before starting this lab, make sure to activate the redundant SDP bindings between the BSAs and
the BSRs. Each BSA needs to be dual homed to two BSRs. Use the lab supplement given by the
instructor as reference.
2. On the BSR, create a non-owner VRRP instance for each BSAs unicast VPLS. Create a VRRP master
and slave using different priority values. Set the priority so that BSAx will use BSRx as the master
when both BSRs are available. Enable ping-reply and telnet-reply on the VRRP instances. For the
VRRP logical (backup) IP address, use the existing IP address on the IES interface with a “1” for the
last octet.

address 192.168.215.2/24
vrrp 10
backup 192.168.215.1
priority 254
ping-reply
telnet-reply
exit
3. Configure a VRRP policy 999 on both the BSR pod nodes making sure the slave will become master
after the port between the BSRs went down.
vrrp
policy 999
priority-event
port-down 1/1/2
priority 1 explicit
exit
exit
exit
4. Apply this policy to the master IES interface.

5. On the local DHCP Server on BSR1, change the default-router to the VRRP logical address for all
pods.
Verification
1. From each PC, release and renew the IP address. Make sure the default gateway is the new VRRP
logical IP address (VRRP backup) and ensure the default gateway is reachable using ping.
2. Execute the following commands and observe the output
a. show router vrrp instance <vrrp-id> interface <interface>

b. show vrrp policy
3. Shut down the IES interface on the router that is the VRRP master.
4. Verify that the VRRP instance on the other router is now the VRRP master. Use the command
below.
a. show router vrrp instance
5. Bring up the IES interface that is currently the backup. Verify that this interface becomes the
master after it comes up.
6. Verify that the defined VRRP policy (policy 999) is applied to the correct interfaces.

7. Shut down the port between the BSRs to activate the VRRP policy. Verify that the VRRP policy
takes effect and the current VRRP master is no longer the master. Verify that the priority in use for
the previous master is now value <X>.
8. Enable the port between the BSRs.
Lab 6 command list

Configure service ies <service-id> interface <name> vrrp <vrrp-id>
Configure service ies interface <name> vrrp <vrrp-id> priority <priority value>
Configure service ies interface <name> vrrp <vrrp-id> backup <IP-address>
Configure vrrp policy <policy-id>
Configure vrrp policy <policy_id> priority-event port-down <iom/mda/port> priority <value> explicit
Configure service ies interface <name> vrrp <vrrp-id> policy <policy-id>
show router vrrp instance
show router vrrp instance <vrrp-id> interface <interface-name>
Notes


Lab 7 SRRP Core Redundancy on Routed CO
Objective
The objective of this lab is to construct redundancy for a Routed CO architecture between the
subscriber interfaces. A BSAN device is dual homed to two subscriber interfaces on the BSRs. Using
SRRP, only one BSR will be the master and receive and send traffic to the BSAN device. In case of a
failure in the path to the master BSR, the redundant BSR will transition from standby to master and
receive/transmit traffic. The home RG will be oblivious to the change.

Pre-Configuration
1. SRRP requires MCS to be configured between the BSR pair. MCS allows subscriber information to be
synchronized between the master and the standby such that in the event of a failover, the standby
BSR can resume the function of the master. Applications that can be synchronized between the
master and standby include IGMP, local DHCP server and SRRP.
2. In this lab, each pair of BSRs (BSR1 and BSR2) will dual home into both BSAN 1 via BSA1 and BSAN2
via BSA2. Similarly BSR3 and BSR4 will dual home into BSAN3 via BSA3 and BSAN4 via BSA4.
3. Separate subscriber interface pairs will be configured on the BSRs to serve their respective BSANs.
For eg: BSR1 and BSR2 will have one subscriber interface each connected to BSAN1 and will have
another subscriber interface each connected to BSAN2 (four in total).
4. The BSAs in this lab are simple layer 2 bridges. Remove any L3 interfaces between BSA1, BSA2 and
BSR1 and BSR2. Re-configure those ports as access ports. Repeat for BSR3/4 and BSA3/4.
5. Configure a simple VPLS on each BSA with 3 SAPS (the first to the connected BSAN devices, the
second and third to each of the BSRs).
6. Configure a redundant subscriber interface on the redundant BSR dual homing into the BSAN. For
BSAN1, a subscriber interface will be created on BSR2 with ingress port of 1/1/6 (Check the
topology). Similarly for BSAN4 a subscriber interface will be created on BSR3 with ingress port of
1/1/6. Observe the following configuration:
subscriber-interface "toRoutedCo10_2" create

address 192.168.215.3/24
group-interface "toBSAN1_2" create
dhcp
server 10.99.99.1
trusted
gi-address 192.168.215.3
no shutdown
exit
exit
exit
exit
exit
no shutdown
SRRP Configuration
Configuring MCS
1. For SRRP to effectively work, MCS must be configured between BSR1 and BSR2 and between BSR3
and BSR4. Observe the following configuration on BSR1

A:TPSv20_BSR1>config>redundancy>multi-chassis# info
----------------------------------------------
peer 10.10.10.218 create
sync
srrp
sub-mgmt
port 1/1/1 create
range 0-1000 sync-tag "SRRP10"
exit
port 1/1/4 create
exit
no shutdown
exit

no shutdown
exit
----------------------------------------------
2. Port 1/1/1 on BSR 1 (10.10.10.214) is the ingress access port receiving traffic from BSAN1 and is
used to synchronize information to peer BSR2 (10.10.10.218). Notice the use of sync-tag to identify
the application that is being synchronized (in this case SRRP instance 10 between BSR1 and BSR2)
3. Port 1/1/4 on BSR1 is the ingress access port receiving traffic from BSAN2 and is used to
synchronize information to peer BSR2. Again sync-tag SRRP20 indicates that the application that is
being synchronized.
Configure SRRP Instance

1. Create an SRRP instance (SRRP 10) on BSR 1 and BSR2 for BSAN 1.
2. Attach a gw-ip address for each of the subnets defined in the subscriber interface. This is the SRRP
gw ip address. Home devices will use this as their default gateway address
3. Configure a SAP with VLAN ID of 1 for SRRP messaging. This VLAN will be dedicated for SRRP
messaging between PEs
4. Configure the respective priority to establish a master PE

address 192.168.215.3/24 gw-ip-address 192.168.215.254
group-interface "toBSAN1_2" create
dhcp
server 10.99.99.1
trusted
gi-address 192.168.215.3
no shutdown
exit
sap 1/1/1:1 create
description "SRRP 10 Messaging"
exit
exit
exit
srrp 10 create
message-path 1/1/1:1
priority 110
no shutdown
exit
exit
exit

Redundant Interface
5. A redundant interface is an optional configuration between the two subscriber interfaces and is
used by SRRP. The single biggest advantage of having this interface is to guarantee that the master
PE is the only one that is receiving and transmitting traffic
6. Configure a redundant interface between BSR1 and BSR2 in the respective IES instances
7. You may need to configure an SDP between BSR1 and BSR2
8. Specify the address and a spoke sdp in the redundant interface configuration
9. You can use the same redundant interface for both SRRP instances i.e. in different group interfaces

redundant-interface "toBSR2_10" create
address 172.31.0.0/31
exit
exit
dhcp
server 10.99.99.1
trusted
gi-address 192.168.215.2
no shutdown
exit
redundant-interface "toBSR2_10"
Verification
1. Verify that the multi-chassis synchronization is working. What is the MCS state?
a. show redundancy multi-chassis all
b. show redundancy multi-chassis sync peer <peer ip address>
2. Verify that the SRRP instance on both PE BSRs indicate the master and backup. Verify that on the
backup IES/BSR, the master priority is indicated in the show output
a. show srrp <instance> detail
3. Verify that the redundant interface is shown in the above output. Observe the state of the backup
IES/BSR. What does the state indicate?
4. On any group interface on any BSR, remove the redundant interface. Verify the SRRP instance that
governs the particular group interface on both the master and the backup. Is there a difference in
the state on the backup BSR? What does this indicate?
5. Obtain IP addresses on the PCs by issuing a DHCP request. Once the IP addresses are obtained.
Verify that the DHCP lease states are maintained across both BSRs for that particular SRRP
instance. What does the MCS standby field indicate
a. show service id <svc id> dhcp lease-state
6. On R5, disable the SAP towards BSR1 on the local VPLS. On R6, disable the SAP towards BSR2. On
R7 disable the SAP towards BSR3 and on R8 disable the SAP towards BSR4. Note: All BSRs here must
be the master BSR towards their routed CO instances. This will break communication between the
SRRP instances. Execute the above show command again on both BSRs. What do you observe?
Ensure that the client PC can still ping the gateway. Why are both BSRs SRRP masters?
a. show service id <svc id> dhcp lease-state

Lab 7 command list
Configure service ies <service-id> subscriber-interface <name> address <ip-addr> gw-ip-address <ip-address>
Configure service ies <service-id> subscriber-interface <name> group-interface <name>
Configure service ies <service-id> subscriber-interface <name> group-interface <name> sap <sap-id>
Configure service ies <service-id> subscriber-interface <name> group-interface <name> srrp <srrp-id>
Configure service ies <service-id> subscriber-interface <name> group-interface <name> srrp <srrp-id> messge-
path <sap-id>

Configure service ies <service-id> subscriber-interface <name> group-interface <name> srrp <srrp-id> priority
<priority value>
Configure service ies <service-id> subscriber-interface <name> group-interface <name> srrp <srrp-id> priority
policy <vrrp-policy-id>
Configure service ies <service-id> subscriber-interface <name> group-interface <name> redundant-interface
<interface>
show redundancy multi-chassis all
show redundancy multi-chassis sync peer <peer ip address>
show srrp <instance> detail
show service id <svc id> dhcp lease-state
Notes

Lab 8 ESM on Bridged CO
Objective
In this exercise a SAP per service model is used on a Bridged CO architecture. Since a 1-1 relationship
does not exist between SAP’s and subscribers, ESM is required for subscriber separation. In this
example each pod will use two PCs to simulate two subscriber hosts of the same subscriber as well and
then two distinct subscribers by modifying Option 82 and port information on the VPLS of the edge
devices.

In the first part of this Lab, a Python script will be used to parse the DHCP ACK option 82 information
to return the subscriber-identity, sub-profile, and sla-profile. In the second part of this Lab, we will
use a RADIUS server instead of a Python script to provide the subscriber-identity, sub-profile, and sla-
profile. In both parts of this lab, the DHCP server is used to return IP addressing information to be
allocated to the end users.
Exercise 8.1: Using Python for ESM Attributes
Configuration
1. Convert the lab setup from aRouted CO to Bridged CO. In a addition to the usual steps required to
change from Bridged CO to Routed CO, remove all SRRP and MCS configuration.
2. Since a VLAN per service model is in use, configure the BSA unicast VPLS with three SAPs for voice,
video, and data. Use VLAN 100 for VoIP, VLAN 200 for video, and VLAN 300 for data. Make sure
the DHCP lease populate value is set to accommodate a larger number then before since now each
SAP will have traffic from many end users (recall that the previous labs had a one to one
relationship between SAPs and subscribers):
sap 1/1/3:100 split-horizon-group "RSHG" create
description "VoIP SAP"
dhcp
snoop
lease-populate 100
no shutdown
exit
anti-spoof ip-mac
exit
description "Video SAP"
dhcp
snoop
lease-populate 100
no shutdown
exit
anti-spoof ip-mac
exit
description "Data SAP"
dhcp
snoop
lease-populate 100
no shutdown
exit
anti-spoof ip-mac
exit

3. To enable ESM, DHCP Option 82 must be inserted. This is normally done by the BSAN which is
simulated by a service router in our lab. Recall that the Option 82 information is composed of two
parts, the Circuit-Id and the Remote-Id. On the SR, the Circuit-Id is a fixed value that cannot be
modified (either it is inserted or not) and it is based on the SAP and service-id the DHCP Discover
and DHCP Offer messages are received on. The Remote-Id can be configured with any value. The
Circuit-ID will be used by the Python script on the BSA to identify the subscriber and the Remote-ID
will be used by this script to identify the SLA and subscriber profile. View the Python script on the
BSA (file type cf3:\SRCDEV_3P.py). On the BSAN configure a VPLS for each subscriber with the
correct encapsulation towards the BSA and Option 82 information such that PC1 will belong to a
subscriber and act as a premium VoIP subscriber-host and PC2 will act as a premium VoD subscriber
host for a different subscriber.

description "vpls for PC1"
stp
shutdown
exit
exit
sap 1/1/1 create
dhcp
option
action replace
circuit-id
remote-id string "002001"
exit
no shutdown
exit
exit
no shutdown
exit
stp
shutdown
exit
exit
sap 1/1/2 create
dhcp
option
action replace
circuit-id
exit
no shutdown
exit
exit
no shutdown
4. On the BSA, create an upstream and downstream scheduler with a rate of 512 (these may be pre-
configured on your BSA).
qos
scheduler-policy "Downstream Policy" create
tier 1
scheduler "Downstream" create
rate 512
exit
exit
exit
scheduler-policy "Upstream Policy" create
tier 1
scheduler "Upstream" create
rate 512
exit

exit
exit
exit
5. Create a SAP ingress policy and SAP egress policy for each of the three service types.
qos
sap-ingress 100 create
description "VOIP upstream"
queue 1 create
parent "Upstream" cir-level 8
rate 128 cir 128
exit
default-fc "ef"

exit
description "Video Upstream"
queue 1 create
rate 128 cir 128
exit
default-fc "h1"
exit
description "Data Upstream"
queue 1 create
parent "Upstream"
rate 256
exit
exit
sap-egress 100 create

description "VOIP downstream"
queue 1 create
parent "Downstream" cir-level 8
rate 128 cir 128
exit
fc ef create
queue 1
exit
exit
description "Video Downstream"
queue 1 create
rate 4000 cir 4000
exit
fc h1 create
queue 1
exit
exit
description "Data Downstream"
queue 1 create
parent "Downstream"
rate 2000
exit
fc be create
queue 1
exit
exit
6. Create a basic SLA profile with a host limit of 100.
subscriber-mgmt
sla-profile "Basic_DATA" create
host-limit 100
ingress
qos 300

exit
exit
egress
qos 300
exit
exit
exit
sla-profile "Basic_VIDEO" create
host-limit 100
ingress
qos 200
exit
exit
egress

qos 200
exit
exit
exit
sla-profile "Basic_VOIP" create
host-limit 100
ingress
qos 100
exit
exit
egress
qos 100
exit
exit
exit
sla-profile "Prem_Data" create
host-limit 50
ingress
qos 300
queue 1
rate 1024
exit
exit
exit
egress
qos 300
queue 1
rate 10000
exit
exit
exit
exit
sla-profile "Prem_VOIP" create
host-limit 50
ingress
qos 100
queue 1
rate 192 cir 192
exit
exit
exit
egress
qos 100
queue 1
rate 192 cir 192
exit
exit
exit
exit
sla-profile "Prem_Video" create
host-limit 50
ingress
qos 200
exit
exit
egress
qos 200

queue 1
rate 800 cir 8000
exit
exit
exit
exit
7. Create a basic subscriber profile using the predefined upstream and downstream schedulers. Also
create a premium subscriber profile overwriting the rate of the schedulers.
subscriber-mgmt
sub-profile "Basic_SCHED" create

ingress-scheduler-policy "Upstream Policy"
exit
egress-scheduler-policy "Downstream Policy"
exit
sla-profile-map
entry key "data" sla-profile "Basic_DATA"
entry key "video" sla-profile "Basic_VIDEO"
entry key "voip" sla-profile "Basic_VOIP"
exit
exit
sub-profile "Prem_SCHED" create
scheduler "Upstream" rate 1024
exit
egress-scheduler-policy "Downstream Policy”
scheduler "Downstream" rate 10000
exit
sla-profile-map
entry key "data" sla-profile "Prem_Data"
entry key "video" sla-profile "Prem_Video"
entry key "voip" sla-profile "Prem_VOIP"
exit
exit
8. Create the subscriber identity policy with an SLA and subscriber profile map that maps the numbers
retrieved from the Python script to the strings “basic” and “premium” used in the configuration of
the BSR. Also install the Python script.
subscriber-mgmt
sub-ident-policy "SRCdev" create
sub-profile-map
entry key "basic" sub-profile "Basic_SCHED"
entry key "premium" sub-profile "Prem_SCHED"
exit
primary
script-url "cf3:\SRCDEV_3P.py"
no shutdown
exit
exit
exit
9. Finally apply sub-ident-policy to the VPLS SAPs of the BSA. Add a basic sub-profile and basic sla-
profile as the SAP defaults.

dhcp
snoop
lease-populate 100
no shutdown
exit
anti-spoof ip-mac
sub-sla-mgmt
def-sub-profile "Basic_SCHED"

def-sla-profile "Basic_VOIP"
sub-ident-policy "SRCdev"
multi-sub-sap 100
no shutdown
exit
exit
dhcp
snoop
lease-populate 100
no shutdown
exit
anti-spoof ip-mac

sub-sla-mgmt
def-sla-profile "Basic_VIDEO"
multi-sub-sap 100
no shutdown
exit
exit
dhcp
snoop
lease-populate 100
no shutdown
exit
anti-spoof ip-mac
sub-sla-mgmt
def-sla-profile "Basic_DATA"
multi-sub-sap 100
no shutdown
exit
exit
10. Configure the IES interface as trusted so that DHCP packets with Option 82 info will not be dropped
(note the VRRP config from lab 6 is shown below however it is not required to make this lab work).

address 192.168.215.2/24
dhcp
server 10.99.99.1
trusted
gi-address 192.168.215.2
no shutdown
exit
ip-mtu 1500
vrrp 10
backup 192.168.215.1
priority 254
policy 999
ping-reply
telnet-reply
exit
local-proxy-arp
exit
exit
Verification
1. Verify the script is valid on the BSA.

a. show subscriber-mgmt sub-ident-policy <policy_name> script primary
b. If a shutdown is done on the script does the above command still work?
c. How is this command different from file type cf3:\SRCDEV_3P.py ?
2. On the BSA, turn on DHCP debug events.
a. debug router ip dhcp ( remember to create a debug log)
b. debug subscriber-mgmt sub-ident-policy “ESM_Policy_1” script-all-info
c. debug subscriber-mgmt authentication
3. On the PCs, initiate new DHCP requests. Analyze the debug outcome. What is the exact format of

the Option 82 Circuit-Id and Remote-Id that is being inserted by the BSAN? This information will be
needed to to configure the RADIUS server in Exercise 5.2.
4. Verify the subscriber hosts, queues, sub profiles and sla profiles on the BSR.
b. show service subscriber-using
c. show service active-subscribers
d. show service active-subscribers detail
e. show service id <service-id> subscriber-hosts
f. show qos scheduler-hierarchy subscriber <sub>
g. show pools access-ingress <port>
h. show service id <service-id> dhcp lease-state detail
5. Experiment with changing the encapsulations and Option 82 parameters on the BSAN. If you set the
option 82 information so that the script cannot return values what happens? If the default ESM
attributes on the SAP are removed what happens?
6. In this lab setup, how could you make the BSA associate PC1 and PC2 with the same subscriber-id
i.e. two subscriber hosts belonging to the same subscriber.
7. Experiment with changing the encapsulations and Option 82 parameters on the BSAN. If the option
82 information is changed so that the script cannot return values what happens? If you remove the
default ESM attributes on the SAP what happens?
8. Restore the initial Option 82 configurations so that PC1 will belong to a subscriber and act as a
premium VoIP subscriber-host and PC2 will act as a premium VoD subscriber host for a different
subscriber.
Notes

Exercise 8.2: Using RADIUS for ESM Attributes Alcatel-Lucent Internal Use only -- Do not Distribute
In this exercise, the Python script being used to return ESM attributes is replaced with a RADIUS server.
The instructor will set the /etc/raddb/clients.conf and /etc/raddb/users files on the RADIUS server
and stop and re-start the RADIUS server as required.
Configuration
1. Configure a RADIUS policy on the BSA. Make sure the user-name format sent to the RADIUS server is
circuit-id. Also make sure to include the remote-id in the RADIUS access request messages as it is
required to provide the correct ESM strings. Make sure to specify the management router as the

RADIUS server in the lab setup is access through the outband management port (it is also possible
to access the RADIUS server through an inband port). Use a password and secret of src
subscriber-mgmt
authentication-policy "knock-knock" create
description "RADIUS Policy"
password "src"
radius-authentication-server
router "management"
server 1 address 192.168.183.89 secret "src"
exit
user-name-format circuit-id
include-radius-attribute

circuit-id
remote-id
exit
exit
2. Bind the authentication policy to the SAP. Keep the existing sub-ident-policy and default sub-sla-
mgmt parameters. Disable the python script to ensure we are getting the subscriber parameters
from RADIUS.

dhcp
snoop
lease-populate 100
no shutdown
exit
authentication-policy “knock-knock”
anti-spoof ip-mac
sub-sla-mgmt
multi-sub-sap 100
no shutdown
exit
exit
dhcp
snoop
lease-populate 100
no shutdown
exit
anti-spoof ip-mac
sub-sla-mgmt
multi-sub-sap 100
no shutdown
exit
exit
dhcp
snoop
lease-populate 100
no shutdown
exit
anti-spoof ip-mac
sub-sla-mgmt

multi-sub-sap 100
no shutdown
exit
exit
3. The complete sub-profile and sla-profile names have been configured in RADIUS rather then
returning key values as we did with the Python script. Therefore configure use-direct-map-as-
default in both the sub-profile-map and sla-profile-map.

sub-profile-map
use-direct-map-as-default
exit
sla-profile-map
exit
Verification
1. On the BSA, turn on DHCP and RADIUS debug events.

2. debug router ip dhcp ( remember to create a debug log)
3. debug subscriber-mgmt sub-ident-policy “SRCdev” script-all-info
4. debug subscriber-mgmt authentication policy knock-knock
5. debug radius detail
6. On the PCs, initiate new DHCP requests. Analyze the debug outcome.
b. show service subscriber-using
c. show service active-subscribers
d. show service id <service-id> subscriber-hosts
e. show qos scheduler-hierarchy subscriber <sub>
f. show pools access-ingress <port>
g. show service id <service-id> dhcp lease-state detail
8. Are the subscriber-id’s the same as Exercise 5.1? Why ?
9. What steps are required to change PC1 to use the basic package?

Lab 8 command list
configure service vpls <vpls> sap <sap-id> split-horizon-group <name> dhcp option
configure service vpls <vpls> sap <sap-id> split-horizon-group <name> dhcp option replace circuit-ID
configure service vpls <vpls> sap <sap-id> split-horizon-group <name> dhcp option replace remote-ID <string>
configure qos scheduler-policy <policy> create
configure qos scheduler-policy <policy> tier <tier> scheduler <name> rate <rate>
configure qos sap-ingress <policy> create

configure qos sap-ingress <policy> queue <x> rate <pir> cir <cir>
configure qos sap-ingress <policy> parent <scheduler>
configure qos sap-egress <policy> create
configure qos sap-egress <policy> queue <x> rate <pir> cir <cir>
configure qos sap-egress <policy> parent <scheduler>
configure qos sap-ingress <policy> fc <fc> create
configure qos sap-ingress <policy> fc <fc> queue <queue>
configure qos sap-ingress <policy> ip-criteria entry <entry> match protocol <protocol>
configure qos sap-ingress <policy> ip-criteria entry <entry> action <action>
configure subscr-mgmt sla-profile <name> create
configure subscr-mgmt sla-profile <name> host-limit <X>
configure subscr-mgmt sla-profile <name> ingress qos <policy>
configure subscr-mgmt sla-profile <name> egress qos <policy>
configure subscr-mgmt sub-profile <name> create
configure subscr-mgmt sub-profile <name> ingress-scheduler-policy <name>
configure subscr-mgmt sub-profile <name> egress-scheduler-policy <name>
configure subscr-mgmt sub-ident-policy <name> create
configure subscr-mgmt sub-ident-policy <name> sub-profile-map entry <key> sla-profile <profile>
configure subscr-mgmt sub-ident-policy <name> sla-profile-map entry <key> sla-profile <profile>
configure subscr-mgmt sub-ident-policy <name> primary script-url <URL>
configure subscr-mgmt sub-ident-policy <name> primary [no] shutdown
configure service ies <ies> sap <sap-id> sub-sla-mgmt sub-ident-policy <policy_name>
configure service ies <ies> sap <sap-id> sub-sla-mgmt multi-sub-sap <X>
Notes


Lab 9 ESM on Routed CO
Objective
The objective of this lab is to use Enhanced Subscriber Management on a Routed CO architecture that
uses a SAP per Subscriber model with PPPoE clients. As in the previous lab RADIUS will be used to
provide the required ESM attributes. Since PPPoE clients are used the pod PCs will need to be
configured as described in “Annex B – Setting Up a PPPoE Session on a Windows PC”. The RADIUS server

will provide the authentication of PPPoE PAP/CHAP sessions, ESM attributes, and the IP address for the
subscriber.
Configuration
1. Convert the setup back to a Routed CO architecture which will be used for the remaining labs.
2. In this lab, a SAP per Subscriber model is being used with PPPoE clients using PAP/CHAP
authentication. The PAP/CHAP username is enough for the RADIUS server to uniquely identify each
subscriber and provide the correct ESM attributes. The BSAN still needs to provide the correct VLAN
encapsulation to be used by the BSR. Use a VLAN tag of 100 for PC1 and 200 for PC2. Since we are
using PPPoE clients, DHCP option 82 information no longer needs to be inserted by the BSAN.

stp
shutdown
exit
exit
sap 1/1/1 create
exit
no shutdown
exit
stp
shutdown
exit
exit
sap 1/1/2 create
exit
no shutdown
exit
3. On the BSR create an upstream and downstream Scheduler with a rate of 512 (these may be pre-
provisioned).
qos
scheduler-policy "Downstream_1" create
tier 1
rate 512
exit
exit
exit
scheduler-policy "Upstream_1" create
tier 1

rate 512
exit
exit
exit
exit
4. On the BSR, create a SAP ingress policy with 3 queues (one for each stream) that are each
equivalent children of the Upstream parent. Use an IP-criteria Policy to put the correct streams in
the correct queues. Note that the qos policies may be pre-provisioned.
qos

description "Basic Profile"
queue 1 create
parent "Upstream"
exit
queue 2 create
parent "Upstream"
exit
queue 3 create
parent "Upstream"
exit
fc “be” create
queue 1
exit
fc "l2" create
queue 2
exit
fc "h2" create
queue 3
exit
ip-criteria
entry 10 create
match protocol icmp
exit
action fc "be"
exit
entry 20 create
match protocol tcp
exit
action fc “l2”
exit
entry 30 create
match protocol udp
dst-port eq 1234
exit
action fc "h2" priority low
exit
exit
exit
exit
5. Create a SAP egress policy with 3 queues (1 per traffic stream) that are equivalent children of the
downstream scheduler. Note that the QoS policies may be pre-provisioned.
qos
queue 1 create
parent “Downstream”
exit
queue 2 create
exit
queue 3 create
exit
fc be create

queue 1
exit
fc l2 create
queue 2
exit
fc h2 create
queue 3
exit
exit
exit
6. Create a basic SLA profile using the SAP ingress and egress policies .

subscriber-mgmt
sla-profile "Basic" create
host-limit 1
ingress
qos 100
exit
exit
egress
qos 100
exit
exit
exit
exit
7. Create a premium SLA profile using the SAP ingress and egress policies.
subscriber-mgmt
sla-profile "Prem" create
host-limit 1
ingress
qos 100
queue 1
rate 1024
exit
queue 2
rate 1024
exit
queue 3
rate 1024
exit
exit
exit
egress
qos 100
queue 1
rate 1024
exit
queue 2
rate 1024
exit
queue 3
rate 1024
exit
exit
exit
exit
8. Create a basic subscriber profile using the predefined upstream and downstream schedulers. Also
create a premium subscriber profile overwriting the rate of the schedulers to 8Mbps.
subscriber-mgmt

ingress-scheduler-policy "Upstream_1"
exit
egress-scheduler-policy "Downstream_1"
exit
exit
ingress-scheduler-policy "Upstream_1"
exit
egress-scheduler-policy "Downstream_1"
exit
exit

exit
9. Create the subscriber identification policy. As in the previous ESM lab, the RADIUS server is
configured with sub-profile and sla-profile names rather then key values so use the keyword “use-
direct-map-as-default”.
subscriber-mgmt
sub-ident-policy "SRCDEV" create
sub-profile-map
exit
sla-profile-map
exit
10. Since the RADIUS server is being used an authentication policy needs to be configured as in the
previous lab. In addition, since the BSR needs to relay PPPoE PAP/CHAP authentication parameters
towards the BSR, the command pppoe-access-method pap-chap has to be configured.
subscriber-mgmt
password "src"
router "management"
server 1 address 192.168.183.89 secret "src"
exit
pppoe-access-method pap-chap
11. Configure the IES used on the BSR for the Routed CO model. Apply the authentication policy to the
group interface and the subscriber identification policy to each SAP. Also enable pppoe on the
group interface with a session limit of 100.

address 192.168.215.1/24
dhcp
server 10.99.99.1
trusted
lease-populate 100
gi-address 192.168.215.1
no shutdown
exit
authentication-policy "knock-knock"
sub-sla-mgmt
sub-ident-policy "SRCDEV"
multi-sub-sap 100

no shutdown
exit
exit
sub-sla-mgmt
multi-sub-sap 100
no shutdown
exit
exit
pppoe
session-limit 100
sap-session-limit 100

no shutdown
exit
exit
exit
no shutdown
exit
12. If not already done , use the “Appendix B – Setting up a PPPoE Session from a Windows PC” to
setup the PCs in each pod to act as PPPoE clients. For the PPPoE username password use
subX@domain1 / subX, where X is the last octet of the management IP address of your PC. For
example PC 192.168.183.80 would be configured to use sub80@domain1 / sub80. This is important
as it will have to match the RADIUS entries in the RADIUS users file.
Verification
1. On the PCs, use the SRC ISP connection start a PPPoE session
2. Verify the subscriber hosts, queues, subscriber profiles and sla profiles on the BSR.
a. show service id 1 pppoe session
b. show service id 1 pppoe summary
c. show service id 1 pppoe statistics
d. show service id 1 pppoe session detail
e. show service active-subscribers
f. show service active-subscribers detail
g. show service active-subscribers hierarchy
3. If the PCs were switched back to DHCP clients, would there be a need to do Option 82 insertion for
Circuit-Id on the BSAN? For Remote-Id?

Lab 9 command list
configure qos scheduler-policy <policy> create

configure subscr-mgmt sub-ident-policy <name> primary [no] shutdown
configure service ies <ies> sap <sap-id> sub-sla-mgmt sub-ident-policy <policy_name>
configure service ies <ies> sap <sap-id> sub-sla-mgmt multi-sub-sap <X>
Notes


Lab 10 Managed SAP on Routed CO
Objective
In the previous Lab ESM was done on a Routed CO with a SAP per subscriber model. However the SAPs
were provisioned manually. In this Lab we will reuse the configuration of the previous lab but use a
managed SAP model. Managed SAP is a feature on the SR to that will automatically provision SAPs. The
RADIUS server will provide the same ESM attributes (sub-identity, sub-profile, sla-profile) as it provided
in the previous lab, additionally it will also provide three managed SAP attributes required on Routed
CO (msap-policy, msap-service-id, msap-groupInterface). The RADIUS server will also provide the IP

addressing for the subscribers.
Configuration
1. Remove the provisioned saps for both PCs

2. Create a capture VPLS that accepts pppoe or dhcp as triggering traffic. The authentication policy
that was configured on the provisioned SAP in the last lab needs to be configured on the capture
SAP.

description "Routed CO Capture VPLS"
stp
shutdown
exit
sap 1/1/1:* capture-sap create
trigger-packet dhcp pppoe
exit
no shutdown
exit
3. Create a managed SAP policy with default SAP parameters and the Subscriber Identity policy to be
used. Note the managed SAP policy name is returned by RADIUS and contains information that is
configured directly on the SAP in the provisioned SAP model. Note that the default subscriber-id
string is used to signal that RADIUS did not return one.
subscriber-mgmt
msap-policy "routedCoMsapPolicy" create
sub-sla-mgmt
def-sub-id string "noRadiusSubId"
def-sla-profile "Basic"
exit
Verification
1. Initiate a PPPoE session on both PCs

a. show service id 1 pppoe session
b. show service id 1 pppoe summary

c. show service id 1 pppoe statistics
d. show service id 1 pppoe session detail
e. show service active-subscribers
f. show service active-subscribers hierarchy
3. How is a managed SAP represented in the show commands?
Lab 10 command list

Configure subscr-mgmt sub-ident-policy <name> primary [no] shutdown
Configure service ies <ies> sap <sap-id> sub-sla-mgmt sub-ident-policy <policy_name>
Configure service ies <ies> sap <sap-id> sub-sla-mgmt multi-sub-sap <X>
Notes


Appendix A Remote Access PC and Application
Familiarization
Objective:
Verify the operation of the subscriber PCs and familiarize yourself with their configuration.

Alcatel Intranet
BSA 1
1
Access 1 Pod2-PC1
BSA 2
2
Pod2-PC2
Figure A-1: Remote PC detail
Exercise 1: Remote Desktop Connection

Familiarize yourself with the remote PCs details, connected as shown in Figure 1-2 Remote PC detail.
Connect to your assigned remote PC using Windows Remote Desktop. A shortcut for this should exist on
the desktop of the lab PC. If not, click on Start - All Programs - Accessories – Communications - Remote
Desktop Connection. A Remote Desktop Connection dialog should appear as shown in Figure 1-3
When prompted for the Computer, type in either the remote connection IP address or domain name of
the remote PC that has been assigned to you, found in Table 1-4.

Figure A-2: Remote Desktop connection
Remote PC Username Password

Name: Pod__-PC1 Address: ___________________
Name: Pod__-PC2 Address: ___________________
Table A-1: Remote PC connection parameters
Click on Connect. You will be connected to the remote PC and prompted to log in.
The logon credentials will be supplied by the instructor. A username and password will be required.
Once you have entered them, you should be connected to the remote PCs desktop.
Verify the IP addresses of the both remote PC ‘Inside Lab’ Ethernet interface is as shown in Table 1-5,
PC IP addresses.
Ping the default gateway address from the command prompt of the PC to verify connectivity.

Exercise 2: Remote Desktop Applications
Application Name Function

Ethereal Capturing, displaying and analyzing network traffic
Video LAN Client (VLC) Multicast source and receiver application
Windows command prompt utilities Generating traffic, statistics, troubleshooting and verification commands
Table A-2: PC applications

Start the Protocol Analyzer, Ethereal by clicking Start - All Programs - Ethereal - Ethereal. In the menu
bar of Ethereal, click on Capture - Interfaces. A dialog similar to the following will appear:
Figure A-3: Ethereal capture interfaces
Capture some Lab traffic by clicking on the ‘Prepare’ button for the adapter bound to the IP address of
the Lab network connection interface. In the resulting dialog box, check the ‘Update list of packets in
real time’ and ‘Automatic Scrolling in live capture’ checkboxes under ‘Display Options’, as shown in
Figure 1-5. Click on ‘Start’ to begin the packet capture. There will be a minimal amount of traffic at
his time. Close the capture and the application once you are comfortable with the operation of
Ethereal. It is not required to save the captured packets.

Figure A-4: Ethereal capture options

Exercise 3a: VLC as a video source
You should be connected to the remote desktop before proceeding.

Start the Video Application, VLC by clicking Start - All Programs – Video LAN – VLC media Player The
application should launch and appear similar to Figure 1-6. VLC is a single tool that functions as a
source and receiver of multicast and unicast video. It will be used in several of the later labs.

Figure A-5: Video LAN Client (VLC)
To select a file to stream, click on File – Open File. Click on Browse and select the file to stream as
shown below. If you are not sure of the file to use, consult with the instructor.
Figure A-6: Video LAN Client (VLC) file selection dialog
Select the Stream/Save check box, and then click on Settings.

To stream the file via unicast, select the UDP check box and enter a unicast destination address as
shown in Figure 1-9. Click OK to return to the previous screen. Click OK from the Open dialog to start
the stream to the destination specified.

Figure A-7: Video LAN Client (VLC) unicast streaming

To stream the file via multicast, select the RTP check box and enter a multicast address as shown in
Figure 1-9. Click OK to return to the previous screen. Click OK from the Open dialog to start the stream
to the multicast group specified.

Figure A-8: Video LAN Client (VLC) multicast streaming

Exercise 3b: VLC as a video receiver
To receive a unicast stream, click on File – Open Network Stream. Select the Network tab and the
UDP/RTP radio button as shown below in Figure 1-10.

Figure A-9: Video LAN Client (VLC) as unicast receiver

To receive a multicast stream, click on File – Open Network Stream. Select the Network tab and the
UDP/RTP Multicast radio button as shown below in Figure 1-11. Enter a multicast address and click OK.
The application has now joined the specified multicast group.

Figure A-10: Video LAN Client (VLC) as multicast Receiver
Close the VLC application when completed.

Exercise 4: Windows Utilities
Open a Windows command prompt on any remote P.C.

Issue the following Windows commands and familiarize yourself with their usage and parameters. The
commands shown are examples only. Use the ‘/?’ parameter to explore all available command line
options.
Windows Command Function

ping 239.8.7.6 –n 1 Generates icmp echo packets to the specified multicast group address. This
enables the device to be a source of Multicast traffic. The –n option specifies
the number of packets to be generated.
mrinfo 192.168.1.1 Queries the device at the specified address for its multicast router capabilities.
netsh interface ip show joins Queries Windows for any multicast groups joined by interfaces of the local
system. (Windows 2003 and higher only)
netstat -e –s | more Displays Ethernet interface packet counters and statistics, for all protocols,
sorted by protocol, for the local system.
netstat -e –s –p <protocol> | more Displays Ethernet interface packet counters and statistics, for the specified
protocol, for the local system.
ipconfig /all Displays all device MAC address and IP address parameters
Table A-4: Windows command line utilities
Log off from the remote PC Windows session once you are familiar with the operation of the commands
shown above.


Appendix B Setting up a PPPoE Session from a Windows PC
Initially no PPPoE Adapter:

Go to Network Connections and then Create a New Connection:






For each PC, use a username password that SubXYZ, where XYZ is the last octet of the PC management
IP address. So for a PC with management IP address 138.120.199.99 use sub99. This is important
because the usernames need to be pre-configured in the RADIUS server.


After you finish making the New Connection, click on the SRC ISP Network Connection ICON to and
adjust the properties:




Make sure not to use the PPPoE Connection as a Default Network otherwise will lose management
access (may have to change this if we do traffic passing labs with PPPoE, otherwise may have to add
static route manually for either management IP address or for lab traffic that is generated. If you do
not do this the PC will bring up the PPPoE session however you will lose access. Kill the pppoe session
with the command “clear service id x pppoe session all”



When the Lab Service Routers and the RADIUS Server are setup appropriately, hit the connect button:

If the connection was successful, you will see a PPP adapter with an IP address:

Appendix C Multicast VPLS Registration (MVR)
In the triple play reference architecture, the DSLAM takes care of the multicast replication. Therefore
from each of the BSA a single VLAN for all multicast traffic is sent to the DSLAM where the traffic will
be replicated using IGMP snooping and proxy behavior. In the lab the BSA will create a separate MVR
that will replicate the Multicast traffic towards the SAPs in the Unicast VPLS.
General MVR behavior

Notes
IGMP snooping in maintained by the MVR VPLS.

User VPLS SAPS have the IGMP feature turned on for
Registering to the MVR VPLS.
Sending queries to the receiver segments.
User VPLS SAPS maintain their normal behavior.
The replication is performed by the MVR VPLS by maintaining a snooping database. The Multicast traffic
entering the MVR VPLS is only sent to the SAPS that have registered with the MVR.

Appendix D Configuring a Local DHCP Server
The Alcatel-Lucent Service Router can act as a Local DHCP Server. This DHCP Server expects to have a
relay in front of it which either inserts a GI address or an Option 82 field so that that DHCP Server can
decide which subnet to allocate an IP address from. You can configure multiple pools with different
subnets on the DHCP Server. In this Lab Guide the Alcatel-Lucent SR Local DHCP Server will be used
with an IES Interface acting as Relay to insert a GI address for pool matching. The DHCP Server can
exist on the same SR as the IES Interface doing the DHCP Relay or another SR. Below is an example
configuration that should be configured on at least one of the nodes in the Lab Topology. IP
reachability is required to all BSRs, therefore make sure to distribute the DHCP Server Interface into

OSPF.
1. Configure the Local DHCP Server

*A:BSR1>config>router>dhcp>server# info
----------------------------------------------
use-gi-address
options
exit
address-range 139.120.121.5 139.120.121.10
exit
options
exit
address-range 140.120.121.5 140.120.121.10
exit
options
exit
address-range 192.168.227.5 192.168.227.10
exit
exit
no shutdown
2. Bind the Local DHCP Server to an Interface, preferably a loopback interface that will always be up
*A:BSR1>config>router# interface localDhcpLoop1
*A:BSR1>config>router>if# info
----------------------------------------------
address 10.99.99.1/32
loopback
local-dhcp-server "srcDhcpServer"
----------------------------------------------
*A:BSR1>config>router>if#
3. Distribute the Interface into OSPF so other BSRs can reach it

*A:BSR1>config>router>ospf>area# info
----------------------------------------------
interface "system"
exit
exit
----------------------------------------------
*A:BSR1>config>router>ospf>area#
4. The following command may be required at some points in the lab to clear the leases from the
local DHCP server:

a. clear router dhcp local-dhcp-server srcDhcpServer leases

Lab Solutions
The sample solutions shown are for the BSA 2 and BSR 2 router. Other solutions are possible.
Lab 1 Solution
Lab 1 BSR1 Configuration
#--------------------------------------------------
echo "IP Configuration"
#--------------------------------------------------
interface "system"

address 10.10.10.214/32
exit
interface "toBSA1"
address 10.214.215.214/24
port 1/1/2
exit
interface "toBSR2"
address 10.214.218.214/24
port 1/1/3
exit
#--------------------------------------------------
echo "OSPFv2 Configuration"
#--------------------------------------------------
ospf
traffic-engineering
area 0.0.0.0
interface "system"
exit
interface "toBSR2"
interface-type point-to-point
exit
interface "toBSA1"
exit
exit
exit
#--------------------------------------------------
#--------------------------------------------------
echo "MPLS Configuration"
#--------------------------------------------------
mpls
interface "system"
exit
interface "toBSA1"
exit
path "loose"
no shutdown
exit
lsp "toBSA1"
to 10.10.10.215
primary "loose"
exit
no shutdown
exit
no shutdown
exit
#--------------------------------------------------
echo "RSVP Configuration"
#--------------------------------------------------
rsvp
interface "system"
exit
interface "toBSA1"
exit
no shutdown
exit
#--------------------------------------------------

#--------------------------------------------------
echo "Service Configuration"
#--------------------------------------------------
service
customer 1 create
description "Default customer"
exit
sdp 215 mpls create
far-end 10.10.10.215
lsp "toBSA1"
keep-alive
shutdown
exit
no shutdown

exit
exit
#--------------------------------------------------
Lab 1 BSA1 Configuration
#--------------------------------------------------
echo "Router (Network Side) Configuration"
#--------------------------------------------------
router
interface "system"
address 10.10.10.215/32
exit
interface "toBSR1"
address 10.214.215.215/24
port 1/1/2
exit
interface "toBSR2"
address 10.215.218.215/24
port 1/1/4
exit
#--------------------------------------------------
#--------------------------------------------------
ospf
traffic-engineering
area 0.0.0.0
interface "system"
exit
interface "toBSR2"
exit
interface "toBSR1"
exit
exit
exit
#--------------------------------------------------
#--------------------------------------------------
echo "MPLS Configuration"
#--------------------------------------------------
mpls
interface "system"
exit
interface "toBSR2"
exit
interface "toBSR1"
exit
path "loose"
no shutdown
exit
lsp "toBSR2"
to 10.10.10.218
primary "loose"
exit
no shutdown

exit
lsp "toBSR1"
to 10.10.10.214
primary "loose"
exit
no shutdown
exit
no shutdown
exit
#--------------------------------------------------
echo "RSVP Configuration"
#--------------------------------------------------
rsvp
interface "system"

exit
interface "toBSR2"
exit
interface "toBSR1"
exit
no shutdown
exit
#--------------------------------------------------
#--------------------------------------------------
#--------------------------------------------------
service
customer 1 create
exit
sdp 214 mpls create
far-end 10.10.10.214
lsp "toBSR1"
keep-alive
shutdown
exit
no shutdown
exit
sdp 218 mpls create
far-end 10.10.10.218
lsp "toBSR2"
keep-alive
shutdown
exit
no shutdown
exit
exit
#--------------------------------------------------
Lab 2 Solution
Lab 2 BSR1
#--------------------------------------------------
echo "Router (Network Side) Configuration"
#--------------------------------------------------
router
dhcp
local-dhcp-server "aminDhcpServer" create
exit
exit
address 10.99.99.1/32
loopback
local-dhcp-server "aminDhcpServer"
exit
interface "system"
address 10.10.10.214/32
exit

interface "toBSA1"
address 10.214.215.214/24
port 1/1/2
exit
interface "toBSR2"
address 10.214.218.214/24
port 1/1/3
exit
#--------------------------------------------------
#--------------------------------------------------
#--------------------------------------------------
ospf
traffic-engineering

area 0.0.0.0
interface "system"
exit
exit
interface "toBSR2"
exit
interface "toBSA1"
exit
exit
exit
#--------------------------------------------------
#--------------------------------------------------
#--------------------------------------------------
service
customer 1 create
exit
sdp 215 mpls create
far-end 10.10.10.215
lsp "toBSA1"
keep-alive
shutdown
exit
no shutdown
exit
address 192.168.215.2/24
dhcp
server 10.99.99.1
gi-address 192.168.215.2
no shutdown
exit
ip-mtu 1500
exit
exit
no shutdown
exit
exit
#--------------------------------------------------
#--------------------------------------------------
echo "Local DHCP Server (Base Router) Configuration"
#--------------------------------------------------
router
dhcp
local-dhcp-server "srcDhcpServer" create
use-gi-address
options

exit
address-range 192.168.215.5 192.168.215.10
exit
options
exit
address-range 192.168.219.5 192.168.219.10
exit
options
exit

address-range 192.168.223.5 192.168.223.10
exit
options
exit
address-range 192.168.227.5 192.168.227.10
exit
exit
no shutdown
exit
exit
exit
----------------------------------------------
#--------------------------------------------------
#--------------------------------------------------
service
interface "ToUC10" create
address 192.168.215.3/24
dhcp
server 192.168.20.1
no shutdown
exit
ip-mtu 1500
exit
exit
interface "ToUC20" create
address 192.168.219.3/24
dhcp
server 192.168.20.1
no shutdown
exit
ip-mtu 1500
exit
exit
no shutdown
exit
#--------------------------------------------------
echo "Router (Service Side) Configuration"
#--------------------------------------------------
router
#--------------------------------------------------
#--------------------------------------------------
ospf
area 0.0.0.0
interface "ToUC10"
exit
interface "ToUC20"

exit
exit
exit
----------------------------------------------
Lab 2 Review Question Answers
1. The packets that appear are: DHCP DISCOVER, OFFER, REQUEST and ACK.
1. There should be three entries. Two for the PC’s and one for the IES interface (chassis MAC).

Lab 3 Solution
Lab 3 BSAN1 Configuration

#--------------------------------------------------
#--------------------------------------------------
service
customer 1 create
exit
stp
shutdown
exit
exit
sap 1/1/1 create
igmp-snooping
send-queries
mvr
from-vpls 400
exit
exit
exit
no shutdown
exit

description "multicast VPLS"
stp
shutdown
exit
igmp-snooping
mvr
no shutdown
exit
no shutdown
exit
description "to BSA1 Multicast VPLS"
igmp-snooping
mrouter-port
exit
exit
no shutdown
exit
exit
#--------------------------------------------------

#--------------------------------------------------

#--------------------------------------------------
service
customer 1 create
exit
stp
shutdown
exit
exit
exit

exit
exit
no shutdown
exit
description "Bridged CO Multicat VPLS"
stp
shutdown
exit
description "multicast SAP towards BSAN"
exit
exit
no shutdown
exit
exit
#--------------------------------------------------
#--------------------------------------------------
echo "IGMP Configuration"
#--------------------------------------------------
igmp
interface "toMC100"
exit
exit
#--------------------------------------------------
echo "PIM Configuration"
#--------------------------------------------------
pim
interface "system"
exit
interface "toMC100"
exit
interface "toVideoServer"
exit
rp
static
address 10.10.10.214
group-prefix 239.0.0.0/8
exit
exit
bsr-candidate
shutdown
exit
rp-candidate
shutdown
exit
exit
exit
#--------------------------------------------------

#--------------------------------------------------
#--------------------------------------------------
ospf
traffic-engineering
area 0.0.0.0
interface "system"
exit
exit
interface "toBSR2"
exit
interface "toBSA1"

exit
interface "toVideoServer"
passive
exit
interface "toUC10"
passive
exit
interface "toMC100"
passive
exit
exit
exit
#--------------------------------------------------
#--------------------------------------------------
#--------------------------------------------------
service
customer 1 create
exit
address 192.168.215.2/24
dhcp
server 10.99.99.1
gi-address 192.168.215.2
no shutdown
exit
ip-mtu 1500
exit
exit
interface "toMC100" create
address 192.168.100.214/24
ip-mtu 1500
exit
exit
no shutdown
exit
exit
#--------------------------------------------------
1. The router port is the port that has a (*,*) entry in the IGMP Snooping database.
2. Using an IGMP Querier reduces the number of Queries sent out on a LAN. The IGMP Querier is
responsible for the Queries to be sent out.
3. Using a PIM DR makes sure only one router connected to a LAN will issue the PIM Join messages,
making sure only one path per LAN is created in stead of many. The PIM DR is responsible for
the PIM Joins to be sent to the RP or the Source.

10. There should be two kind of MDTs available, the Shared Path Tree (*,G) and the Source Path
Tree (S,G) depending on the router’s position in the network.
Lab 4 Solution
Lab 4 BSAN Configuration

#--------------------------------------------------
#--------------------------------------------------
description "unicast VPLS for PC1"
stp

shutdown
exit
exit
sap 1/1/3 create
exit
no shutdown
exit
stp
shutdown
exit
exit
sap 1/1/4 create
exit
no shutdown
exit
exit
#--------------------------------------------------
Lab 4 BSA Configuration

#--------------------------------------------------
#--------------------------------------------------
sap 1/1/1:* create
exit
sap 1/1/2 create
exit
no shutdown
exit
#--------------------------------------------------
Lab 4 BSR Configuration (note Interface toUC10 is not used in this Routed CO Lab)
#--------------------------------------------------
#--------------------------------------------------
dhcp
server 10.99.99.1
no shutdown
exit
ip-mtu 1500
exit
exit
address 192.168.215.2/24
arp-populate
dhcp
server 10.99.99.1
trusted

gi-address 192.168.215.2
no shutdown
exit
exit
exit
exit
exit
no shutdown
exit
#--------------------------------------------------

1. The traffic will pass the BSR since the BSAN uses separate VPLS for each PC. A real BSAN device
would act as a similar way as direct user to user communication is always blocked.
3. The Local Proxy Arp feature on the Routed CO IES Subscriber interface will reply as a proxy on
the ARP Requests. The Anti Spoofing cannot be disabled since this table is used by the Routed
CO to find the path to which SAP a certain IP address belongs. In Bridged CO, the FDB of the
VPLS would take care of this. The DHCP lease state table contains also this information, but
this table is kept on the CPM (Control Plane). The Anti Spoof Tables are kept on the IOM (Data
Plane).
Lab 5 Solution

split-horizon-group "RSHG" residential-group create
exit
stp
shutdown
exit
no arp-reply-agent
dhcp
snoop
lease-populate 1
no shutdown
exit
anti-spoof ip-mac
exit
no arp-reply-agent
dhcp
snoop
lease-populate 1
no shutdown
exit
anti-spoof ip-mac
exit
dhcp
snoop
exit
exit
exit


address 192.168.215.2/24
dhcp
server 10.99.99.1
gi-address 192.168.215.2
no shutdown
exit
ip-mtu 1500
local-proxy-arp
exit
exit

Where are the features configured?
DHCP Snooping must be installed on the BSA SAPs and Spoke SDPs
DHCP Lease Populate must be installed on the BSA SAPs and BSR IES Interfaces.
Anti Spoof must be installed on the BSA SAPs.
Local Proxy Arp must be installed on the IES Interfaces
Residential Split Horizon groups must be installed on the VPLS and SAPs in that VPLS.
Arp Reply Agent must be enabled on the BSA SAPs and is enabled by default on Residential Split
Horizon Group SAPs.
What are the features responsibilities?
DHCP Snooping enables a VPLS SAP or Spoke SDP to read the DHCP messages passing through a
Layer 2 domain. Normally DHCP messages are only read by Layer 3 and higher.
DHCP Lease Populate creates the DHCP lease state tables, which are necessary for the Anti
Spoofing tables (and other features).
Anti Spoofing creates a table that links the SAP with the IP/MAC addresses given by the DHCP lease
state table.
Local Proxy Arp makes sure the IES Interface or VRRP interface answers the ARP request from the
PCs requesting the MAC addresses of other PCs in that LAN.
Residential Split Horizon groups bind SAPs in a VPLS together and block direct traffic between
them.
ARP Reply Agent answers the downstream ARP requests initiated from the BSR towards the PCs
instead of forwarding the ARP Request towards the PC.
Lab 6 Solution

description "unicast vpls"
exit
stp
shutdown
exit
no arp-reply-agent
dhcp
snoop
lease-populate 1
no shutdown
exit
anti-spoof ip-mac
exit

no arp-reply-agent
dhcp
snoop
lease-populate 1
no shutdown
exit
anti-spoof ip-mac
exit
dhcp
snoop
exit
exit

dhcp
snoop
exit
exit
no shutdown
exit
vrrp
policy 999
priority-event
port-down 1/1/2
priority 1 explicit
exit
exit
exit
exit

address 192.168.215.2/24
dhcp
server 10.99.99.1
gi-address 192.168.215.2
no shutdown
exit
ip-mtu 1500
vrrp 10
backup 192.168.215.1
priority 254
policy 999
ping-reply
telnet-reply
exit
local-proxy-arp
exit
exit
address 192.168.219.2/24
dhcp
server 10.99.99.1
gi-address 192.168.219.2
no shutdown
exit
ip-mtu 1500
vrrp 20
backup 192.168.219.1
priority 10
ping-reply
telnet-reply
exit
local-proxy-arp

exit
exit
Lab 7 Solution
Lab 7 BSAN1

stp
shutdown
exit
sap 1/1/1 create
description "SAP for PC1"
exit
description "provide encap for PC1"
exit
no shutdown
exit
stp
shutdown
exit
sap 1/1/2 create
exit
exit
no shutdown
exit
Lab 7 BSA1
stp
shutdown
exit
sap 1/1/1 create
description "sap to BSR1"
exit
sap 1/1/3:* create
description "sap to BSAN1"
exit
sap 1/1/6 create
description "sap to BSR2"
exit
no shutdown
exit

address 172.31.0.0/31
exit
exit
dhcp
gi-address 192.168.215.2

exit
dhcp
server 10.99.99.1
trusted
lease-populate 100
no shutdown
exit
sap 1/1/1:1 create
exit

exit
exit
srrp 10 create
description "higher priority wins so make BSR1 the master"
priority 110
no shutdown
exit
exit
exit
no shutdown
exit
redundancy
multi-chassis
sync
srrp
sub-mgmt
port 1/1/1 create
exit
no shutdown
exit
no shutdown
exit
exit
exit

address 172.31.0.1/31
exit
exit
dhcp
gi-address 192.168.215.3
exit
dhcp
server 10.99.99.1
trusted
lease-populate 100
no shutdown
exit
sap 1/1/6:1 create
exit

exit
exit
srrp 10 create
priority 25
no shutdown
exit
exit
exit
no shutdown
exit

redundancy
multi-chassis
sync
srrp
sub-mgmt
port 1/1/6 create
exit
no shutdown
exit
no shutdown
exit
exit
exit

3. The backup BSR state is indicated as backupShunt if a redundant interface is configured.
4. If a redundant interface is not configured the state is indicated as backupRouting.
5. On the backup BSR, the MCS Stdby column indicates “yes”. This is only the case when it is in
backupShunt state ( instead of backupRouting state).
6. Both BSRs are SRRP masters because communication has been interrupted so they both assume
the master role. In this case since both BSRs are SRRP masters the MCS Stdby column is blank
on both BSRs
Lab 8 Solution
Lab 8.1 BSAN1

stp
shutdown
exit
sap 1/1/1 create
dhcp
option
action replace
circuit-id
exit
no shutdown
exit
exit
exit
no shutdown
exit

stp
shutdown
exit
sap 1/1/2 create
dhcp
option
action replace
circuit-id
exit
no shutdown
exit

exit
exit
no shutdown
exit
Lab 8.1 BSA1

exit
stp
shutdown
exit
dhcp
snoop
lease-populate 100
no shutdown
exit
anti-spoof ip-mac
sub-sla-mgmt
multi-sub-sap 100
no shutdown
exit
exit
dhcp
snoop
lease-populate 100
no shutdown
exit
anti-spoof ip-mac
sub-sla-mgmt
multi-sub-sap 100
no shutdown
exit
exit
dhcp
snoop
lease-populate 100
no shutdown
exit
anti-spoof ip-mac

sub-sla-mgmt
multi-sub-sap 100
no shutdown
exit
exit
dhcp
snoop
exit
exit

dhcp
snoop
exit
exit
no shutdown
exit
qos
scheduler-policy "Downstream Policy" create
tier 1
rate 512
exit
exit
exit
scheduler-policy "Upstream Policy" create
tier 1
rate 512
exit
exit
exit
exit
qos
description "VOIP upstream"
queue 1 create
rate 128 cir 128
exit
queue 11 multipoint create
exit
default-fc "ef"
exit
description "Video Upstream"
queue 1 create
rate 128 cir 128
exit
exit
default-fc "h1"
exit
description "Data Upstream"
queue 1 create
parent "Upstream"
rate 256
exit
exit
exit
description "VOIP downstream"
queue 1 create

rate 128 cir 128
exit
fc ef create
queue 1
exit
exit
description "Video Downstream"
queue 1 create
rate 4000 cir 4000
exit
fc h1 create

queue 1
exit
exit
description "Data Downstream"
queue 1 create
parent "Downstream"
rate 2000
exit
fc be create
queue 1
exit
exit
exit
subscriber-mgmt
sla-profile "Basic_DATA" create
host-limit 100
ingress
qos 300
exit
exit
egress
qos 300
exit
exit
exit
sla-profile "Basic_VIDEO" create
host-limit 100
ingress
qos 200
exit
exit
egress
qos 200
exit
exit
exit
sla-profile "Basic_VOIP" create
host-limit 100
ingress
qos 100
exit
exit
egress
qos 100
exit
exit
exit
sla-profile "Prem_Data" create
host-limit 50
ingress
qos 300
queue 1
rate 1024
exit
exit

exit
egress
qos 300
queue 1
rate 10000
exit
exit
exit
exit
sla-profile "Prem_VOIP" create
host-limit 50
ingress
qos 100
queue 1

rate 192 cir 192
exit
exit
exit
egress
qos 100
queue 1
rate 192 cir 192
exit
exit
exit
exit
sla-profile "Prem_Video" create
host-limit 50
ingress
qos 200
exit
exit
egress
qos 200
queue 1
rate 800 cir 8000
exit
exit
exit
exit
exit
exit
sla-profile-map
entry key "data" sla-profile "Basic_DATA"
entry key "video" sla-profile "Basic_VIDEO"
entry key "voip" sla-profile "Basic_VOIP"
exit
exit
exit
exit
sla-profile-map
entry key "data" sla-profile "Prem_Data"
entry key "video" sla-profile "Prem_Video"
entry key "voip" sla-profile "Prem_VOIP"
exit
exit
sub-profile-map
exit
primary

no shutdown
exit
exit
exit
Lab 8.1 BSR1 Configuration

address 192.168.215.2/24
dhcp
server 10.99.99.1

trusted
gi-address 192.168.215.2
no shutdown
exit
ip-mtu 1500
vrrp 10
backup 192.168.215.1
priority 254
policy 999
ping-reply
telnet-reply
exit
local-proxy-arp
exit
exit
Lab 8.2 BSAN1

- same as Lab 8.1
Lab 8.2 BSA1

- all SLA and QoS profiles are the same as Lab 8.1

exit
stp
shutdown
exit
dhcp
snoop
lease-populate 100
no shutdown
exit
anti-spoof ip-mac
sub-sla-mgmt
multi-sub-sap 100
no shutdown
exit
exit
dhcp
snoop
lease-populate 100
no shutdown
exit

anti-spoof ip-mac
sub-sla-mgmt
multi-sub-sap 100
no shutdown
exit
exit
dhcp
snoop

lease-populate 100
no shutdown
exit
anti-spoof ip-mac
sub-sla-mgmt
multi-sub-sap 100
no shutdown
exit
exit
dhcp
snoop
exit
exit
dhcp
snoop
exit
exit
no shutdown
exit
subscriber-mgmt
password "QIbMUnDKWUzEyR9iryzXIfHvxHvn9NHR" hash2
router "management"
server 1 address 192.168.183.89 secret "WaeD9WV82akVUOYo0VImlk" hash2
exit
user-name-format circuit-id
include-radius-attribute
circuit-id
remote-id
exit
exit

sub-profile-map
exit
sla-profile-map
exit
primary
exit
exit

Lab 8.2 BSR1
- same as Lab 8.1
Review Question Answers

Lab 9 Solution
Lab 9 BSAN1

stp
shutdown
exit
sap 1/1/1 create
exit
exit
no shutdown
exit
stp
shutdown
exit
sap 1/1/2 create
dhcp
no shutdown
exit
exit
exit
no shutdown
exit

sap 1/1/1 create
exit
sap 1/1/3:* create
exit
no shutdown
exit

address 192.168.215.1/24
dhcp
server 10.99.99.1

trusted
lease-populate 100
gi-address 192.168.215.1
no shutdown
exit
sub-sla-mgmt
multi-sub-sap 100
no shutdown
exit
exit

sub-sla-mgmt
multi-sub-sap 100
no shutdown
exit
exit
pppoe
session-limit 100
no shutdown
exit
exit
exit
no shutdown
exit
Lab 10 Solution
Lab 10 BSAN1 Configuration

stp
shutdown
exit
sap 1/1/1 create
exit
exit
no shutdown
exit
stp
shutdown
exit
sap 1/1/2 create
exit
exit
no shutdown
exit

sap 1/1/1 create
exit
sap 1/1/3:* create
exit
no shutdown
exit

description "Routed CO Capture VPLS"
stp
shutdown
exit
sap 1/1/1:* capture-sap create
trigger-packet dhcp pppoe
exit
no shutdown
exit

address 192.168.215.1/24
dhcp
server 10.99.99.1
trusted
lease-populate 100
gi-address 192.168.215.1
no shutdown
exit
pppoe
session-limit 100
no shutdown
exit
exit
exit
no shutdown
exit

password "QIbMUnDKWUzEyR9iryzXIfHvxHvn9NHR" hash2
router "management"
server 1 address 192.168.183.89 secret "WaeD9WV82akVUOYo0VImlk" hash2
exit
pppoe-access-method pap-chap
exit
msap-policy "routedCoMsapPolicy" create

sub-sla-mgmt
def-sub-id string "noRadiusSubId"
def-sla-profile "Basic"
exit
exit


Alcatel Lucent SRC Triple Play Lab Guide Download v2.2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Alcatel Lucent SRC Triple Play Lab Guide Download v2.2

Uploaded by

Copyright:

Available Formats

Alcatel-Lucent Internal Use only -- Do not Distribute

Alcatel-Lucent Triple Play Services Lab Guide

Alcatel-Lucent Triple Play Services Lab Guide v2.2 1/106

LAB 1 LAB INFRASTRUCTURE ........................................................................................ 4

LAB 2 CONFIGURING BRIDGED CO COMPONENTS................................................................. 6

Alcatel-Lucent Internal Use only -- Do not Distribute

LAB 4 CONFIGURING ROUTED CO COMPONENTS ................................................................15

LAB 5 TRIPLE PLAY SECURITY ON A BRIDGED CO ARCHITECTURE ...........................................18

LAB 6 VRRP CORE REDUNDANCY WITH BRIDGED CO............................................................23

LAB 7 SRRP CORE REDUNDANCY ON ROUTED CO ...............................................................26

LAB 8 ESM ON BRIDGED CO ..........................................................................................30

LAB 9 ESM ON ROUTED CO...........................................................................................42

LAB 10 MANAGED SAP ON ROUTED CO ............................................................................49

APPENDIX A REMOTE ACCESS PC AND APPLICATION FAMILIARIZATION.....................................52

APPENDIX B SETTING UP A PPPOE SESSION FROM A WINDOWS PC ..........................................63

APPENDIX C MULTICAST VPLS REGISTRATION (MVR) ...........................................................80

APPENDIX D CONFIGURING A LOCAL DHCP SERVER.............................................................81

LAB SOLUTIONS ........................................................................................................83

Alcatel-Lucent Triple Play Services Lab Guide v2.2 2/106

Alcatel-Lucent Internal Use only -- Do not Distribute

Alcatel-Lucent Triple Play Services Lab Guide v2.2 3/106

Alcatel-Lucent Internal Use only -- Do not Distribute

1. Name the routers in your pod.

Alcatel-Lucent Triple Play Services Lab Guide v2.2 4/106

Alcatel-Lucent Internal Use only -- Do not Distribute

Alcatel-Lucent Triple Play Services Lab Guide v2.2 5/106

Alcatel-Lucent Internal Use only -- Do not Distribute

Alcatel-Lucent Triple Play Services Lab Guide v2.2 6/106

Alcatel-Lucent Internal Use only -- Do not Distribute

ies 214 customer 1 create

Alcatel-Lucent Triple Play Services Lab Guide v2.2 7/106

Alcatel-Lucent Internal Use only -- Do not Distribute

Lab 2 command list

Alcatel-Lucent Triple Play Services Lab Guide v2.2 8/106

Alcatel-Lucent Triple Play Services Lab Guide v2.2 9/106

Alcatel-Lucent Internal Use only -- Do not Distribute

vpls 400 customer 1 create

vpls 100 customer 1 create

Alcatel-Lucent Triple Play Services Lab Guide v2.2 10/106

vpls 400 customer 1 create

Alcatel-Lucent Internal Use only -- Do not Distribute

ies 214 customer 1 create

Alcatel-Lucent Triple Play Services Lab Guide v2.2 11/106

Alcatel-Lucent Internal Use only -- Do not Distribute

Alcatel-Lucent Triple Play Services Lab Guide v2.2 12/106

Alcatel-Lucent Internal Use only -- Do not Distribute

Alcatel-Lucent Triple Play Services Lab Guide v2.2 13/106

Alcatel-Lucent Triple Play Services Lab Guide v2.2 14/106

Alcatel-Lucent Internal Use only -- Do not Distribute

epipe 500 customer 1 create

2. Make sure the chassis mode of the BSR is b or higher:

5. Put the subscriber interface into the IGP.

Alcatel-Lucent Triple Play Services Lab Guide v2.2 15/106

Alcatel-Lucent Internal Use only -- Do not Distribute

Lab 4 command list

Alcatel-Lucent Triple Play Services Lab Guide v2.2 16/106

Alcatel-Lucent Triple Play Services Lab Guide v2.2 17/106

Exercise 5.1: Anti Spoofing Filter

Alcatel-Lucent Internal Use only -- Do not Distribute

vpls 10 customer 1 create

Alcatel-Lucent Triple Play Services Lab Guide v2.2 18/106

Alcatel-Lucent Internal Use only -- Do not Distribute

Alcatel-Lucent Triple Play Services Lab Guide v2.2 19/106

Alcatel-Lucent Triple Play Services Lab Guide v2.2 20/106