Zain-Bng HLD-LLD Draft Ph1v0.1

BNG
High Level & Low Level

Design Document
Jan 2019
v 0.1 [DRAFT]
© Nokia 2019. All rights reserved.
About Nokia
Nokia is a global leader in the technologies that connect people and things. Powered by the
innovation of Bell Labs and Nokia Technologies, the company is at the forefront of creating and
licensing the technologies that are increasingly at the heart of our connected lives.
With state-of-the-art software, hardware and services for any type of network, Nokia is uniquely
positioned to help communication service providers, governments, and large enterprises deliver on
the promise of 5G, the Cloud and the Internet of Things.
http://www.nokia.com || http://networks.nokia.com
Table of contents
1. Document history ............................................................... 7
2. Introduction ........................................................................ 8
2.1 PURPOSE ............................................................................................. 8
2.2 SCOPE ................................................................................................. 8
2.3 Assumptions........................................................................................ 8
3. Solution overview ................................................................ 9

3.1 Solution description ............................................................................ 9
3.2 Software release ............................................................................... 10
4. 7750 Hardware introduction ............................................. 11

4.1 7750SR-12 Chassis overview ............................................................ 11
4.1.1 SFM5/CPM5 ................................................................................................ 13
4.1.2 IOM/IMM/MDA ............................................................................................ 13
4.1.3 Chassis Layout ............................................................................................ 16
5. Hardware configuration parameter................................... 18

5.1 Chassis mode .................................................................................... 18
5.2 Card configuration ............................................................................ 18
5.3 MDA configuration ............................................................................ 18
5.4 SW release ......................................................................................... 19
5.5 7750 service component .................................................................. 19
5.5.1 Customers or Clients .................................................................................. 19
5.5.2 Service distribution path............................................................................. 20
5.5.3 Services Access points ................................................................................ 20
6. Physical connectivity and data-link design ........................ 22

6.1 Physical Topology ............................................................................. 22
6.2 Physical configuration ....................................................................... 23
6.2.1 BNG-PE link ................................................................................................. 23
7. Network-side IP design ..................................................... 25

7.1 VLAN and IP Interface Design ............................................................ 25
7.1.1 System IP address ...................................................................................... 26
OM ID # 3 / 82
7.1.2 Global VPRN parameters ............................................................................. 26
7.1.3 Interfaces configuration ............................................................................. 27
7.2 IP Routing Design .............................................................................. 27
7.2.1 Static Routing ............................................................................................. 27
7.2.2 BGP on GRT................................................................................................. 28
7.2.3 BGP on HSI VPRN ........................................................................................ 30
7.2.4 SDP configuration ....................................................................................... 31
8. Enhanced Subscriber Management ................................... 33

8.1 Quality of Service (QoS) .................................................................... 33
8.1.1 Default scheduler ....................................................................................... 33
8.1.2 HSI QOS ...................................................................................................... 34
8.2 RADIUS Server Design ....................................................................... 35
8.2.1 General Guidelines ...................................................................................... 36
8.2.2 Authentication ............................................................................................ 37
8.2.3 Accounting .................................................................................................. 37
8.3 Subscriber Identification ................................................................... 38
8.3.1 Subscriber-ID .............................................................................................. 39
8.3.2 Session ID ................................................................................................... 39
8.3.3 Subscriber-profile (sub-profile) .................................................................. 40
8.3.4 SLA-profile (sub-profile) ............................................................................. 40
8.3.5 Subscriber identification policy .................................................................. 41
8.4 BNG Redundancy ............................................................................... 41
8.5 IPV4 address assignment and Management ..................................... 44
8.5.1 Address Management ................................................................................. 44
8.5.2 DHCP Server redundancy ............................................................................ 44
8.6 PPP Policy .......................................................................................... 48
8.7 SRRP (Subscriber Router Redundancy Protocol) ............................... 49
8.8 Multi-Chassis Synchronization (MCS) ................................................ 51
8.9 ESM Interfaces .................................................................................. 53
8.9.1 Redundant Interface ................................................................................... 53
8.9.2 Subscriber Interface ................................................................................... 53
8.9.3 Group Interface .......................................................................................... 54
8.10 SRRP-Aware Routing ......................................................................... 59
9. BNG Migration Strategy .................................................... 62

OM ID # 4 / 82
9.1 Migration Method Overview .............................................................. 62
9.2 Migration Execution ........................................................................... 62
10. Network management ...................................................... 66

10.1 Basic 7750SR System configuration ................................................. 66
10.1.1 Boot Options File (BOF) ............................................................................... 66
10.1.2 Synchronization and Redundancy ............................................................... 67
10.1.3 System Information .................................................................................... 68
10.1.4 SNMP .......................................................................................................... 68
10.1.5 System Time ............................................................................................... 70
10.2 Security Management ....................................................................... 71
10.2.1 User Security and Access Control ............................................................... 71
10.2.2 Password Management ............................................................................... 77
10.2.3 SSH / FTP .................................................................................................... 77
10.2.4 Event Logging ............................................................................................. 79
Table of Figures
Figure 1: Network Architecture ............................................................................................................ 9
Figure 2: 7750SR-12 Chassis Overview ............................................................................................. 12
Figure 3: SFM5-12+CPM5 ................................................................................................................... 13
Figure 4: IOM4-e-B ............................................................................................................................. 14
Figure 5: 1-port 100GE CFP2 MDA-e ................................................................................................. 14
Figure 6: 10-port 10GE SFP+ MDA-e .................................................................................................. 15
Figure 7: RIY-BNG Chassis Layout ...................................................................................................... 16
Figure 8: JED-BNG Chassis Layout ..................................................................................................... 17
Figure 9: DMM-BNG Chassis Layout ................................................................................................... 17
Figure 10: 7750 SR service components ........................................................................................... 19
Figure 11: SDP concept ...................................................................................................................... 20
Figure 12: SAP concept ...................................................................................................................... 21
Figure 13: physical topology .............................................................................................................. 22
Figure 14: Directly connected interfaces & static routing ................................................................ 28
Figure 15: BGP peering in GRT ........................................................................................................... 29
Figure 16: default scheduler .............................................................................................................. 34
Figure 17: Overall Redundancy Design-Phase 0 ................................................................................ 42
Figure 18: Overall BNG Redundancy Design-Phase 1 ........................................................................ 42
Figure 19: BNG Redundancy blocs ..................................................................................................... 43
Figure 20: DHCP Redundancy-Phase 0 .............................................................................................. 45
Figure 21: DHCP Redundancy-Phase 1 .............................................................................................. 46
Figure 22: SRRP failure detection ...................................................................................................... 51
Figure 23: Multi-Chassis Synchronization (MCS)................................................................................ 51
Figure 24: SRRP-Aware Routing ......................................................................................................... 59
Figure 25: BNG Service Migration-Step 0 ............................................................................................... 63
Figure 26: BNG Service Migration-Step 1 ................................................................................................ 64
Figure 27: BNG Service Migration-Step 2 ................................................................................................ 64
OM ID # 5 / 82
Figure 28: BNG Service Migration-Step 3 ............................................................................................... 65
List of Tables
Table 1: BNG session scaling .............................................................................................................. 10

Table 2: BNG-PE port allocation ......................................................................................................... 23
Table 3: System IPv4 Address Assignment ........................................................................................ 25
Table 4: VLAN and IPv4 Address Assignment ..................................................................................... 26
Table 5: QoS rates.............................................................................................................................. 34
Table 6: radius server ......................................................................................................................... 36
Table 7: VLAN repartition and redundancy-phase 0 .......................................................................... 54
Table 8: VLAN repartition and redundancy-phase 1 .......................................................................... 54
Table 9: BNG Migration Steps ............................................................................................................ 62
Table 10: syslog server ...................................................................................................................... 82
OM ID # 6 / 82
1. Document history
Ed Date Name Modification
EL KIHEL Document creation - First version

0.1 27-Jan-19
Mohammed
OM ID # 7 / 82
2. Introduction
2.1 PURPOSE
The purpose of the document is to provide High level and low level transcript for the introduction
of 7750 SR in Zain Network as BNG for PPPOE termination using ESM (Enhanced subscriber
Management feature).
Zain BNG deployment is planned in 4 phases as following:

- Phase 0: It has been agreed that Zain has sufficient existing 7750 SR-7 hardware to begin
the establishing of the BNG infrastructure immediately. total number of subscribers is
expected to reach 10k during phase 0.
- Phase 1: Following Zain growth perspective, phase 1 continues to leverage the existing
7750 SR-7 chassis. The 10GE interfaces are removed and replaced by 2x 2-port 100GE line
cards at each site, serving total of 100k subscribers.
- Phase 2: Will be hardware addition to accommodate 1Tbps throughput per site, and total
of 250k subscribers.
- Phase 3: Will be hardware addition to accommodate 2Tbps throughput per site, and total
of 500k subscribers.
This document is focusing on design requirements for Zain BNG in phase 1.
The primary intended audience is Zain Network Design, Network Operation, Engineering and
planning teams and the Nokia Engineering community assigned to this project.
2.2 SCOPE
The scope of this document is to provide a High-Level and Low-Level Design considerations to
ensure a successful, future-save capacity expansion on Nokia BNG by swapping the existing 7750
SR-7 chassis by the SR-12 along with optimizing the geo-redundancy according to Zain
requirement, including the explicit command line configuration commands (CLI).
2.3 Assumptions
It is assumed that readers of this document have some familiarity with the existing Zain network
deployment.
It is assumed that the readers of this document have some understanding of IP/MPLS and
PPP/PPPoE/RADIUS messaging from a functional perspective.
This design document is based on available information at time of writing.

Some information may be identified as needed to complete and will be marked within the
document as following (please search for these keywords in the document to identify missing
information):
[AP: Zain]: for information that needs to be provided from Zain team.
[AP: Nokia]: for information that needs to be provided from Nokia team.
© Nokia 2016. All rights reserved. BNG HLD/LLD 8 / 82

Confidential
3. Solution overview
3.1 Solution description
The high-speed Internet [HSI] services is implemented via 3 BNG nodes to subscribers connecting
through the FTTH residential and business users. The current equipement implementation consists
of three Nokia 7750 SR-7 routers located at different sites.
BNG routers will be interconnected to Zain Backbone network (IPBB) to reach both Access part and
Internet Gateway routers.
Following is the high level overview of the BNG connectivity within Zain Network deployed during
Phase 0. The same connectivity design will be used for Phase 1 (except the change from 10G lag to
100G).
Figure 1: Network Architecture
Within this document we will use the following naming convention:

- Riyadh = RIY
- Jeddah = JED
- Dammam = DMM
Phase 1 plans to swap the existing chassis from SR-7 to SR-12. The 10GE interfaces with the IPBB
are removed and replaced by 2x 2-port 100GE line cards at each site.
Along with the BNG SR-7 chassis swap, the geo-redundancy will be changed according to Zain
requirement. The new geo-redundancy plan besides the change will be reviewed in detail within
this document.

Confidential
3.2 Software release
Introducing 7750SR-12 into Zain will be deployed with 15.0 Release.
Release 15 SFM5
Users per group interface -

Users per IOM4-e-B -
User per System 256k
Table 1: BNG session scaling

Confidential
4. 7750 Hardware introduction
4.1 7750SR-12 Chassis overview
The 7750 SR-12 chassis is a fully redundant system with a total of Twelve (12) front access slots.
Two (2) slots are dedicated for redundant common equipment, where each holds one Switch Fabric
Module/Control Processor Module (SFM/CPM). The remaining 10 slots are used for Input/output
Module (IOM) base boards or Integrated Media Module (IMM).

Confidential
Figure 2: 7750SR-12 Chassis Overview
Key Description
1 Cable management system
2 Chassis slot numbers
3 MDA (installed)
4 Impedance panel
5 SF/CPM slots
6 MDA impedance panel
7 Rack-mounting brackets
8 Air vent
9 ESD plug

Confidential
4.1.1 SFM5/CPM5
The SFM5-12+CPM5 combination module is composed of two parts: an SFM5-12 that connects
directly to the backplane, and a pluggable CPM5 that is inserted in the SFM5-12. The 7450 ESS-12
and 7750 SR-12 can operate with a minimum of one SFM5-12+CPM5 combination module. Two
combination modules are required for redundancy. The combination module is supported in slot A
or slot B. Figure 3 shows the combination module.
Figure 3: SFM5-12+CPM5
The SFM5-12 performs the switching functions between all slots for the chassis. The
fabric modules are 1+1 redundant with an active-active load-sharing design. The
SFM5-12 is a full-height module that is modular in design and houses the pluggable
CPM5.
The SFM connects directly to the backplane and carries traffic between line modules.
The backplane provides high-speed access to the SFM, ISMs, IMMs, IOMs, and
MDAs.
The CPM5 is a pluggable module housed in the SFM5-12. The CPM5 provides the management,
security, and control plane processing for the system. Redundant CPMs operate in a hitless,
stateful, failover mode. Central processing and memory are intentionally separated from the
forwarding function on the interface modules to ensure system resiliency.
4.1.2 IOM/IMM/MDA
IOMs are optimized for flexibility in deploying a variety of mobile, multiservice and Ethernet-based
applications. Each IOM supports up to two pluggable MDAs and can also be used to house
Integrated Service Adapters.
MDAs are pluggable line modules that provide physical interface connectivity. MDAs are available in
a variety of interface and density configurations.
IMMs are line modules that provide integrated processing and physical interfaces on a single
board. IMMs support high-capacity Ethernet interfaces, including variants with integrated tunable
DWDM optics.
The following IOM/IMM/MDA cards are used within Zain network:
Card description mda-type

7750 SR IOM4-e-B L3HQ "iom3-xp“
MDA-e - 7750 SR 10-port 10GE SFP+ MDA-e "imm48-1gb-sfp“
MDA-e - 7750 SR 1-port 100GE CFP2 MDA-e "m2-10gb-xp-xfp"

Confidential
4.1.2.1 IOM4-e-B
Figure 4: IOM4-e-B
The IOM4-e is FP3-based cards that support up to two pluggable MDA-e modules. Each
pluggable MDA-e can provide up to 100 Gb/s (full-duplex) line rate throughput.
4.1.2.2 1-port 100GE CFP2 MDA-e
Figure 5: 1-port 100GE CFP2 MDA-e
Key Label Description

1 Status - Green (blinking): Initializing.
- Green: Operationally up, admin up.
- Amber: Operationally down, admin up.
- Unlit: Admin down, shut down
2 Power - Blue: On
- Off: No power
- Green (solid): Valid communications link is established at
100 000 Mb/s
- Amber (slow blinking): No CFP is installed
3 Lnk (Link) LED
- Amber (fast blinking): Indicates loopback
- Amber (solid): Optics are installed but no link is present
- Unlit: Disabled or shut down

Confidential
- Green (solid): Port is active and receiving or transmitting
data
Act (Activity) LED
- Amber (solid): Indicates an error condition
- Unlit: No activity
Laser Disabled - Amber (solid): Laser disabled

4
LED - Unlit: Laser on
5 CFP2 slot One 100-GB CFP2 slot
6 Model label ME1-100GB-CFP2
7 Captive screws Secure the MDA-e in place
4.1.2.3 10-port 10GE SFP+ MDA-e
Figure 6: 10-port 10GE SFP+ MDA-e
Key Label Description

1 Status Card status LED:
- Green (blinking): Initializing.
- Green (solid): Operationally up, admin up.
- Amber (solid): Operationally down, admin up.
- Unlit: Admin down, shut down
2 Power Power LED:
- Blue (solid): On
- Unlit: No power
- Green (solid): Valid communications link is established at
10 000 Mb/s
- Amber (slow blinking): No SFP is installed
Lnk (Link) LED - Amber (fast blinking): Indicates loopback
3
- Amber (solid): Optics are installed but no link is present
- Unlit: Disabled or shut down
- Green (solid): Port is active and receiving or transmitting
Act (Activity) LED data

Confidential
- Amber (solid): Indicates an error condition
- Unlit: No activity
4 SFP+ slots Ten 10-GB SFP+ slots, numbered 1 to 10
5 Model label ME10-10GB-SFP+
6 Captive screws Secure the MDA-e in place
4.1.3 Chassis Layout
Card repartition within Zain BNG nodes for project phase 1 is shown in the following chassis
layouts. Please note that only slots that have card type filled are used. Slots marked in grey are not
used.
4.1.3.1 RIY-BNG Chassis Layout
Figure 7: RIY-BNG Chassis Layout

Confidential
4.1.3.2 JED-BNG Chassis Layout
Figure 8: JED-BNG Chassis Layout
4.1.3.3 DMM-BNG Chassis Layout
Figure 9: DMM-BNG Chassis Layout

Confidential
5. Hardware configuration parameter
The following guidelines are followed to configure the 7750 SR IOMs and MDAs:
• Chassis slots must be pre-provisioned to accept specific line card types.
• Switch Fabric module must be provisioned to bring line cards up.
• Line cards (IOMs) must be pre-provisioned to accept specific Media Dependent Adapter
(MDA) types. If an IOM type is installed in a slot provisioned for a different type, the card
will not initialize.
• A card installed in an un-provisioned Slot remains administratively and operationally down
Until the Slot, IOM type, MDA Slot, and MDA type is specified.
5.1 Chassis mode

This command is used to control the set of features and scaling available based on the variants of
IOMs present in the node. As of release 15.0, the set of supported IOMs no longer requires this
differentiation using this command. The command still exists but the mode is fixed at chassis
mode d.
/configure system chassis-mode d
Note, no reboot is required; the scaling limits associated with chassis mode “d” will be available.
To show the operational chassis mode
/show chassis
5.2 Card configuration

Within Zain phase 1, the installed 7750SR nodes are of the type SR12 which means that possible
line cards positions are from slot ‘1’ until slot ‘10’. Following CLI commands will be used to
provision the Equipped IOM4-e-B cards in slots 1 and 2.
configure card 1 card-type "iom4-e-b"

configure card 2 card-type "iom4-e-b"
To show the status and information of the cards:
/show card [detail]

/show card <card-slot-id> [detail]
Within Zain design, two CPM5 cards are housed within the SFM5-12. There is no need to explicitly
configure these types of boards. They will be positioned in slot ‘A’ and slot ‘B’.
5.3 MDA configuration

Within Zain BNG nodes phase 1, the following MDA-e types are used:
- 10-port 10GE SFP+ MDA-e : “me10-10gb-sfp+ ”
- 1-port 100GE CFP2 MDA-e : “me1-100gb-cfp2 ”
Following CLI commands will be used to provision the equipped MDA in IOM slots:

Confidential
configure card 1 mda 1 mda-type " me1-100gb-cfp2"
configure card 1 mda 2 mda-type " me10-10gb-sfp+"
configure card 2 mda 1 mda-type " me1-100gb-cfp2"
configure card 2 mda 2 mda-type " me10-10gb-sfp+"
To show the status and information of the cards:
/show mda [detail]

/show mda <slot/mda> [detail]
5.4 SW release
The new 7750SR-12 into Zain network will be deployed with the 15.0 release (SROS 14.0.R10) for
phase 1.
To show the running SROS version:
/show version
5.5 7750 service component

The Nokia 7750 SR provides a service router concept, which enables ease of operations and
maintenance. The basic logical entities in the service model used to construct a service are:
1. Customers or Clients
2. Service Distribution Paths (SDPs) (for distributed services only)
3. Service Access Points (SAPs)
Figure 7 illustrates the relationships between the entities making up the service model.
Figure 10: 7750 SR service components
5.5.1 Customers or Clients
The terms customers, clients and subscribers are used synonymously. The most basic required
entity is the customer ID/client ID value, which is assigned when the customer account/client is
created. To provision a service, a customer ID/client ID must be associated with the service at the
time of service creation.

Confidential
5.5.2 Service distribution path
A Service Distribution Path (SDP) acts as a logical way to direct traffic from one 7750 SR to another
7750 SR through a unidirectional (one-way) service tunnel. The SDP terminates at the far-end
7750
SR which directs packets to the correct service egress SAPs on that device. A distributed service
Consists of a configuration with at least one SAP on a local node, one SAP on a remote node, and
an SDP binding the service to the service tunnel. An SDP can use MPLS (LDP or RSVP-TE) or GRE as
the transport tunneling technique. In Zain BNG design, LDP SDPs will be used for transport
between the redundant BNG 7750SR PEs.
Figure 11: SDP concept
An SDP has the following characteristics:

• An SDP is identified by a numerical identifier. Possible values of the SDP ID are 1 – 17407.
• An SDP is locally unique to a router. The same SDP ID can appear on other 7750 SRs.
• An SDP uses the system IP address to identify the far-end edge router.
• SDPs must be created first, before a distributed service can be configured.
• An SDP is not specific to any one service or any type of service. Once an SDP is created,
Services can be bound to that SDP. An SDP can also have more than one service type
associated with it.
• All services mapped to an SDP use the same transport encapsulation type defined for the
SDP(Either GRE or MPLS).
• An SDP is a management entity. Even though the SDP configuration and the services
carried
within are independent, they are related objects. Operations on the SDP affect all the
services associated with the SDP. For example, the operational and administrative state of
an SDP controls the state of services bound to the SDP.
• An SDP from the local device to a far-end 7750 SR requires a return path SDP from the far
end 7750 SR back to the local router. Each device must have an SDP defined for every
remote router to which it wants to provide service.
5.5.3 Services Access points
Each service type is configured with at least one Service Access Point (SAP). A SAP identifies the
customer interface point for a service on an Nokia 7750 SR. The SAP configuration requires that
Slot, MDA, and port information be specified. A SAP is a local entity to the 7750 SR and is Uniquely
identified by the following
• The physical Ethernet port, FR, ATM, POS port and channel

Confidential
• The encapsulation type
• The encapsulation identifier (ID)
Depending on the encapsulation, a physical port or channel can have more than one SAP
associated with it. Using dot1q encapsulation the 7750 SR can support multiple services for a
customer or services for multiple customers on an Ethernet port. SAPs can only be created on
ports or channels designated as “access” in the physical port configuration. SAPs cannot be
created on ports designated as core-facing “network” ports.
There are three encapsulation service options on Ethernet ports

• Null - Supports a single service on the port. For example, where a single customer with a
single service customer edge (CE) device is attached to the port. The encapsulation ID is
always 0 (zero).
• Dot1q - Supports multiple services for one customer or services for multiple customers
(Figure 8: Multiple SAPs per Port). For example, the port is connected to a multi-tenant unit
(MTU) device with multiple downstream customers. The encapsulation ID used to
distinguish an individual service is the VLAN ID in the IEEE 802.1Q header.
• Q-in-Q – the q-in-q encapsulation type adds an IEEE 802.1Q tag to the 802.1Q tagged
packets entering the network to expand the VLAN space by tagging tagged packets,
producing a double tagged frame.
Figure 12: SAP concept

Confidential
6. Physical connectivity and data-link
design
6.1 Physical Topology

The following diagram presents overall physical topology:
Figure 13: physical topology

VSS nodes are connected inline between BNGs and IPBB PEs, they are transparent from L2
perspective and are mainly used for mirroring traffic. So, in the next sections VSS will be
considered as physical links.
EOR switches are places between BNGs and IPBB PEs to ensure Active/Standby link usage between
connected PEs (One PE is active, and the other PE is standby). So, in the next section we will
consider each BNG directly connected to single PE on the IPBB.
The change regarding physical topology in phase 1 will be as follow:

- Introduction of 100G link between BNG-VSS-EOR-PE
- Removal of the 1G link from BNG since the OM will be migrated to the LAG interface.
To avoid the project delay by lack of 100G ports in the other devices (VSS, EOR), a temporary
physical topology based on multiple 10G links could be used.

Confidential
6.2 Physical configuration
6.2.1 BNG-PE link
The 100G links facing the IPBB (IP Backbone) PE will be deployed based on the following design
guidelines:
• Single-Mode Fiber
• Encapsulation: QinQ
• Mode: Hybrid
• Ethernet MTU: 9212 bytes.
• Down-on-internal-error: brings port operationally down in the event the systems has
detected internal max transmit errors.
• Ethernet port hold-time up: 5 seconds
The below ports will be allocated for the connectivity to IPBB routers:
SL# Point A ports port type Point B ports

(BNG) (IPBB-PE)
1 RIY-BNG 1/1/1 100G LR RIY-EOR x/x/x

2 RIY-BNG 2/1/1 100G LR RIY-EOR x/x/x
1 JED-BNG 1/1/1 100G LR JED-EOR x/x/x
2 JED-BNG 2/1/1 100G LR JED-EOR x/x/x
1 DMM-BNG 1/1/1 100G LR DMM-EOR x/x/x
2 DMM-BNG 2/1/1 100G LR DMM-EOR x/x/x
Table 2: BNG-PE port allocation
[AP: Zain] Please to share the ports on the IPBB-PE side.
Port Configuration Template
The following template is used to configure ports on BNG routers:
A:BNG>config>port# info
----------------------------------------------
ethernet
mode hybrid
encap-type qinq
down-on-internal-error
hold-time up 5
exit
no shutdown
----------------------------------------------
100G links between BNG router and EOR switch will be aggregated into LAG.
LACP is to be used in active mode on the LAG to allow member ports negotiation.
Following is LAG configuration on BNG. in this example ports 1/1/1 and 2/1/1 are members of the
LAG:
A:BNG>config>lag# info
----------------------------------------------

Confidential
mode hybrid
encap-type qinq
port 1/1/1
port 2/1/1
lacp active
no shutdown
----------------------------------------------

Confidential
7. Network-side IP design
Redundant 7750SR PE distributed systems provide PE chassis redundancy serving BNG for HSI
residential and business subscribers.
HSI BNG functionality will be enabled on the 7750SR in the context of independent BNG Internet
(HSI) VPRN in each site that spans the redundant distributed routers. The HSI VPRN will terminate
PPPoE session of the residential HSI subscribers and thel business HSI subscribers without private
VPRN.
Below are the design guidelines for the BNG HSI service on the 7750SR PEs.
Since hot swap will be performed, the IP Plan design will be preserved.
7.1 VLAN and IP Interface Design

Within Zain BNG implementation, different interfaces, IP addresses and VLANs will be required.
Details for each requirement are explained in the respective section of this document. The
following tables present summary of those required parameters.
The system interface practically the first L3 interface that we configure on a Nokia IP node. It is
associated with a network entity (such as a specific router or switch), not a specific interface. The
system interface is also referred to as the loopback address. The system interface is associated
during the configuration of the following entities:
- Termination point of service tunnels
- Hops when configuring MPLS paths and LSPs
- Addresses on a target router for BGP and LDP peering
The system interface is used to preserve connectivity (when routing re-convergence is possible)
when an interface fails or is removed. The system interface is used as the router identifier, and a
system interface must have an IP address with a 32-bit subnet mask.
router Name system IP /32
RIY-BNG 10.158.177.1/32
JED-BNG 10.158.177.2/32
DMM-BNG 10.158.177.3/32
Table 3: System IPv4 Address Assignment
Other interface parameters are provided in the following table. Details on different interface types
and usage will be described in respective section in this document.
BNG Router Interface purpose Interface name Address Context port:VLAN
inband management management 10.158.172.14/30 GRT – IES 50 1/1/1:670.0

system system 10.158.177.1/32 GRT system
direct interco to JED-BNG to-jed-bng 10.158.177.49/30 GRT lag-10:36.*
RIY BNG direct interco to DMM-BNG to-dmm-bng 10.158.177.41/30 GRT lag-10:38.*
connectivity to PE PE-HSI-900 10.158.181.202/30 VPRN 10 lag-10:900.0
Loopback for HSI VPRN Loopback0 10.158.172.18/32 VPRN 10 loopback

Confidential
Loopback for DelMar RIY
dhcp 10.158.173.36/32 VPRN 10 loopback
DHCP
Loopback for Dawiyat RIY
dhcp-daw-riy 10.158.177.8/32 VPRN 10 loopback
DHCP
Loopback for Dawiyat DMM
dhcp-daw-dmm 10.158.177.13/32 VPRN 10 loopback
DHCP
Redundant Interface to JED red-riy-jed 10.158.177.60/31 VPRN 10 spoke-sdp 102:100
Redundant Interface to
red-riy-dmm 10.158.177.38/31 VPRN 10 spoke-sdp 103:100
DMM
System system 10.158.177.2/32 GRT system
direct interco to RIY-BNG to-riy-bng 10.158.177.50/30 GRT lag-10:36.*
direct interco to DMM-BNG to-dmm-bng 10.158.177.45/30 GRT lag-10.37.*
Loopback for HIS VPRN Loopback0 10.158.172.26/32 VPRN 10 loopback
JED BNG Loopback for DelMar dhcp 10.158.172.37/32 VPRN 10 loopback
Looback for Dawiyat JED
dhcp-daw-jed 10.158.177.10/32 VPRN 10 loopback
DHCP
Loopback for Dawiyat RIY
dhcp-daw-riy 10.158.177.9/32 VPRN 10 loopback
DHCP
Redundant Interface to RIY red-jed-riy 10.158.177.61/31 VPRN 10 spoke-sdp 201:100
Redundanty interface to
red-jed-dmm 10.158.177.36/31 VPRN 10 spoke-sdp 203:100
DMM
System system 10.158.177.3/32 GRT system
direct interco to RIY-BNG to-riy-bng 10.158.172.42/30 GRT lag-10:38.*
direct interco to JED-BNG to-jed-bng 10.158.177.46/30 GRT lag-10:37.*
DMM BNG Loopback for HSI VPRN Loopback0 10.158.172.34/32 VPRN 10 loopback
Loopback for Dawiyat DMM
dhcp-daw-dmm 10.158.177.12/32 VPRN 10 loopback
DHCP
Loopback for Dawiyat JED
dhcp-daw-jed 10.158.177.11/32 VPRN 10 loopback
DHCP
Redundant Interface to RIY red-dmm-riy 10.158.172.38/32 VPRN 10 spoke-sdp 301:100
Redundant Interface to JED red-dmm-jed 10.158.177.37/31 VPRN 10 spoke-sdp 302:100
Table 4: VLAN and IPv4 Address Assignment
7.1.1 System IP address
A system IP address must be configured on the 7750SR node as the loopback address to identify
the node. It must be a /32 address. System address is used in routing protocols, MPLS, AAA, SDPs
and system management.
BFD will be enabled for fast node failure detection and re-convergence of the routing table.
configure
router
interface "system"
address 172.31.1.82/32
no shutdown
exit
7.1.2 Global VPRN parameters
The BNG HSI Internet VPRN on the 7750SR PEs will have:

Confidential
• VPRN id: 10
• Unique RD in the following format: <system IP-Address>:<AS#>
• no RT will be configured because this is local VPRN
• An autonomous system <64665>
configure
service
customer 1 create
exit
vprn 10 customer 1 create
description "HSI VPRN"
autonomous-system 64665
route-distinguisher <system-ip-address>:64665
no shutdown
exit all
7.1.3 Interfaces configuration
Interfaces are configured between all BNGs in GRT (Global Routing Table) to ensure direct L3
reachability between them.
This is not mandatory as L3 reachability could be ensured via interconnection with IPBB. But Zain
choice is to use IPBB as L2 transport and not involve it in GRT L3 interconnection between BNGs.
L3 interface configuration template is as follows:

A:BNG# configure router interface <interface-name> create
address <ip-address>/30
port lag-10:38.*
no shutdown
On HSI VPRN, BNGs are interconnected to IPBB over the 10GE LAG. and L3 interfaces are
configured according to Table 4 shown in the beginning of this section.
Following is an example of interface towards IPBB using LAG-10, VLAN 900, and IP address
10.158.181.202/30:
A:BNG# configure service vprn 10 interface "PE-HSI-900" create
address 10.158.181.202/30
sap lag-10:900.0 create
exit
----------------------------------------------
7.2 IP Routing Design

The following routing protocols will be enabled between the BNG and IPBB PE routers for
management purpose and for routing of subscriber’s subnets and Internet prefixes. For phase 1,
the same routing design will be kept.
7.2.1 Static Routing
Static routing will be used within GRT to ensure BNG reachability to other BNGs system addresses
through the directly connecting interfaces.

Confidential
Figure 14: Directly connected interfaces & static routing
The following example shows static routes on RIY-BNG to reach JED-BNG and DMM-BNG system
addresses:
configure router
static-route-entry 10.158.177.2/32
next-hop 10.158.177.58
no shutdown
exit
exit
static-route-entry 10.158.177.3/32
next-hop 10.158.177.42
no shutdown
exit
exit
7.2.2 BGP on GRT
On each BNG, 1GE link is used to interconnect with IPBB and is used to allow reachability to BNGs
to Zain Management systems.
For phase 1, the GE link will be removed since the reachability between BNG and Zain Management
Systems will be over the LAG interface. Hence, the 1G IMM card will not be re-inserted in the new
SR-12 chassis after BNG swap.

Confidential
Figure 15: BGP peering in GRT
BGP is used between BNGs GRT and IPBB PEs mainly for management purpose:
- BNGs will advertise their system addresses to IPBB. policy “export-to-bgp” will be used for
this.
- and IPBB will advertise default-route (0.0.0.0/0) to BNGs
- IPBB AS# is: 43766
- BNG AS# is: 64665
- “min-route-advertisement” of 1 second will be used to accelerate BGP convergence for
new updates
- “rapid-widhdrawal” will be used to accelerate convergence by immediately advertising any
updates containing withdrawn NLRIs.
The following template is showing BGP configuration on RIY-BNG:
# First configure policy to math BNG system address

configure router policy-options
begin
prefix-list "system"
prefix 10.158.177.1/32 exact #RIY-BNG system address
exit
policy-statement "export-to-bgp"
entry 10
from
protocol direct
prefix-list "system"
exit
action accept
exit
exit
exit
commit
exit all
#
# Then configure BGP and apply the policy to the group
configure router bgp

Confidential
rapid-withdrawal
group "PE"
family ipv4
export "export-to-bgp"
peer-as 43766
bfd-enable
neighbor 10.158.172.13
exit
exit
no shutdown
7.2.3 BGP on HSI VPRN
Within HSI VPRN eBGP peers with IPBB PE routers, and will be used for routing of the following
prefixes:
BNG will advertise the IPv4 subscribers as follows:

• SRRP state will be tracked and subscribers prefixes will be advertised according to SRRP
state:
o SRRP master will advertise subscribers prefixes using MED=10 (more preferable)
o SRRP standby will advertise subscribers prefixes using MED=1000 (less preferable)
BGP will be configured between BNGs and IPBB PEs as follows:

• Local AS#: 64665. PE AS# 43766
• Peering will be using directly connected interface IP addresses
• Minimum Route Advertisement Interval (MRAI): 1 seconds.
• Rapid Withdrawal
• BGP Address Family: IPv4
• MD5 Authentication
• Export routing policy will be created and applied under the BGP group in BGP instance:
o Advertises the IPv4 subscriber prefixes of the dynamic subscribers to the IGW
routers
• Since peering with IGW is External-BGP, MED will be used to control route advertisement
(for incoming traffic control): All master BNG advertised prefixes will have BGP MED
(metric) 10 while BGP MED 1000 will be used on backup BNG.
An example of policy and BGP configuration is given below.
Configure
router
policy-options
begin
# create prefix list matching all dhcp subnets that will be redundant
prefix-list "dhcp-redundant-subnets"
prefix 10.112.128.0/17 exact
prefix 10.113.128.0/17 exact
prefix 10.158.173.0/24 exact
prefix 10.158.177.128/25 exact
exit
policy-statement "export-bgp-vprn10"
entry 10
description "set MED 10 if SRRP master"
from
protocol direct
state srrp-master

Confidential
exit
to
protocol bgp
exit
action accept
metric set 10
exit
exit
entry 20
description "set MED 1000 if SRRP standby"
from
protocol direct
state srrp-non-master
exit
to
protocol bgp
exit
action accept
metric set 1000
exit
exit
entry 100
description "to advertise loopbacks of local DHCP servers"
from
protocol direct
prefix-list "dhcp-loopbacks"
exit
to
protocol bgp
exit
action accept
exit
exit
exit
commit
exit
/configure
service vprn 10
bgp
min-route-advertisement 1
rapid-withdrawal
group "PE"
family ipv4
export "export-bgp-vprn10"
peer-as 43766
bfd-enable
neighbor <peer-ip-address>
authentication-key <password>
exit
exit
exit
no shutdown
exit all
7.2.4 SDP configuration
SDP must be configured prior to creating Redundant Interface.

The following are the guidelines for designing and configuring SDPs on the BNG.

Confidential
One (1) SDP GRE-based will be used on the BNGs for transport tunneling between the adjacent
BNG. An SDP to a far-end (adjacent BNG) will utilize an LDP tunnel to that far-end. An SDP can have
more than one service type associated with it; T-LDP will be used to signal pseudowires between
BNG’s.
First, LDP needs to be enabled on the BNGs:

configure router ldp
Then SDPs are created toward other BNGs as follows:
configure service
sdp 102 create
description “to-jed-bng”
far-end 10.158.177.2
keep-alive
shutdown
exit
no shutdown
exit
sdp 103 create
description “to-jed-bng”
far-end 10.158.177.3
keep-alive
shutdown
exit
no shutdown
exit

Confidential
8. Enhanced Subscriber Management
Subscriber Management is the main BNG role, and it is the process of managing subscribers’
sessions from their first access attempt till their disconnection. Subscriber Management consists
of identifying and authenticating subscribers, parameters allocation (IP address, default-gateway,
DNS…), maintaining their sessions while they are connected, enforcing subscribers QoS, and other
enhanced features as will be described in this section.
The following subsections include detailed configuration required to enable Enhanced Subscriber
Management for PPPoE subscribers’ termination on the 7750SR PE.
8.1 Quality of Service (QoS)

QoS is used for SLA enforcement of the contracted upload/download bandwidth to which the user
has subscribed. Upload bandwidth is limited by the SAP-ingress QoS policy applied to the
subscriber whereas download bandwidth is limited by the SAP-egress QoS policy applied to the
subscriber. The SAP-ingress and SAP-egress QoS policies are associated to the subscriber using
the SLA-Profile. This subsection focuses on the design and configuration of the QoS policies.
by using the default QoS profile, all ingress traffic is treated as best effort (be) (mapped to FC be
and to low priority scheduler). For an egress SAP using the default QoS profile, all egress traffic will
use the same queue.
Since hot swap will be performed, the same QoS design of phase 0 will be used.
8.1.1 Default scheduler
While competing for bandwidth to the destination, each scheduler determines which queue will be
Serviced next. During congestion (packets existing on multiple queues), queues are serviced in the
following order:
1. Queues associated with the high-priority scheduler operating within their CIR.
2. Queues associated with the low-priority scheduler operating within their CIR.
3. All queues with traffic above CIR and within PIR will be serviced by a biased round robin.
The 7750SR QoS features are flexible and allow modifications to the forwarding class
characteristics and the CIR and PIR queue parameters. The only fundamental QoS mechanisms
enforced within the hardware are the association of the forwarding classes with the high priority or
low priority scheduler and the scheduling algorithm. Other parameters can be modified to
configure the appropriate QoS behavior.

Confidential
Figure 16: default scheduler
8.1.2 HSI QOS
In Zain, for each HSI subscriber, one egress queue and one ingress policer will be allocated;
Subscriber policers and queues are instantiated on the IOM/IMM on which the subscriber SAP
resides. All subscriber traffic will be mapped to Best Effort (BE) Forwarding Class (FC), i.e. default-
FC. When policers are used, the BE FC will be explicitly mapped to ‘policer 1’ created within the QoS
policy. By default, FCs that are not explicitly mapped to the policer will be mapped to the default
queue ‘queue 1’. This will unnecessarily instantiate one ingress default queue per subscriber (with
the corresponding hardware queues). To avoid instantiation of the default queue, all unused FCs
will also be mapped to ‘policer 1’.
For policers and queues, the Peak Information Rate (PIR) will be set according the user profiles as
the peak rate allowed for the user in the respective direction (upload or download).which profile
each subscriber will use is communicated by Radius server upon user authentication.
Zain subscribers may use the following profiles:

- Zain have a general rule to set Upload=Download/4
- The following values are fine-tuned and set according to speed test results conducted
from the field for different values.
QoS Download PIR Upload PIR
profile value value
20M 20480 5120
50M 52500 13000
75M 79300 19700
100M 105500 26200
500M 528000 132000
Table 5: QoS rates

Confidential
The default sla-profile and default sub-profile QoS configuration on the BNG is used as the base
configuration. (See section 8.3)
The ingress QoS policy configuration is given below. Configuration must be applied on all three
BNG routers.
configure
qos
sap-ingress 1000 create
description "Profile X Upload"
queue 1 create
exit
queue 11 multipoint create
exit
policer 1 create
rate <uplink-rate-in-kbps>
exit
fc "af" create
policer 1
exit
fc "be" create
policer 1
exit
fc "ef" create
policer 1
exit
fc "h1" create
policer 1
exit
fc "h2" create
policer 1
exit
fc "l1" create
policer 1
exit
fc "l2" create
policer 1
exit
fc "nc" create
policer 1
exit
egress QoS policy configuration is given below. Configuration must be applied on both BNG
routers in the same site.
configure
qos
sap-egress 3000 create
description "Profile X Download"
queue 1 create
rate <download-rate-in-kbps>
exit
fc be create
queue 1
exit all
8.2 RADIUS Server Design

RADIUS will be used for PPPoE subscribers Authentication, Authorization and Accounting (AAA). The
below design and configuration guidelines will be followed:

Confidential
8.2.1 General Guidelines
• Zain has two RADIUS servers, The IPv4 addresses of the servers are listed in Table 6.
• 7750SR allows to configure up to 16 RADIUS servers within RADIUS Server policy for
Authentication, Accounting.
• One of RADIUS servers are the primary while the other will be backup, BNG routers will be
Manually configured to use the backup RADIUS servers instead of primary just when
there is an issue in primary
• Communication between the BNG and the RADIUS servers will be through HSI VPRN
• RADIUS packets will use the loopback IPv4 address of the BNG inside HSI VPRN as a source
IPv4 address.
• Shared secret for Authentication, Accounting and CoA.
• The following UDP ports will be used for RADIUS communication:
- Authentication: 1812 (default)
- Accounting: 1813 (default)
- CoA: 3799 (default)
Radius server ip address Radius server name

(in HSI VPRN radius-server configuration)
10.157.106.196 AAA Riyadh

10.157.107.196 AAA Jeddah
Table 6: radius server
An example for the radius configuration commands to include in HSI VPRN will look like:
configure
service vprn 10
radius-server
server "JED-AAA" address 10.157.107.196 secret <secret> create
accept-coa
exit
server "RIY-AAA" address 10.157.106.196 secret <secret> create
accept-coa
exit
exit
exit all
#
/configure aaa
radius-server-policy "radius-auth-server-policy-1" create
servers
router 10
source-address <hsi-loopback-address>
server 1 name "RIY-AAA"
server 2 name "JED-AAA"
exit
exit

Confidential
8.2.2 Authentication
CHAP will be used for PPPoE subscriber’s authentication.
8.2.2.1 Access request message
The following RADIUS attributes will be used:

- nas-port “*8p”
- nas-identifier
- mac-address
And domain name of “sa.zain.com” will be appended to subscribers username for authentication.
configure
subscriber-mgmt
authentication-policy "auth-policy-1" create
ppp-user-name append "sa.zain.com"
accept-authorization-change
pppoe-access-method pap-chap
include-radius-attribute
nas-port "*8p"
nas-identifier
mac-address
exit
radius-server-policy "radius-auth-server-policy-1"
exit
8.2.2.2 Access Accept message
In the Access-Accept message, the BNG expects the default and standard attributes to be
Returned from RADIUS.
8.2.3 Accounting
In Zain Network session accounting will be sent periodically by BNGs to AAA server.
8.2.3.1 Accounting request start
In addition to the default and standard accounting RADIUS attributes, the below attributes will be
included in the RADIUS Accounting-Requests:
• calling-station-id mac
• framed-ip-addr
• mac-address
• nas-identifier
• nas-port "*8p"
• nas-port-id
• remote-id
• sla-profile
• sub-profile
• subscriber-id

Confidential
• user-name
configure
subscriber-mgmt
radius-accounting-policy "AAA-BILLING" create
no queue-instance-accounting
host-accounting interim-update
update-interval 10
include-radius-attribute
calling-station-id mac
framed-ip-addr
mac-address
nas-identifier
nas-port "*8p"
nas-port-id
remote-id
sla-profile
sub-profile
subscriber-id
user-name
std-acct-attributes
exit
session-id-format number
radius-server-policy "radius-auth-server-policy-1"
exit
exit
8.2.3.2 Accounting request on
An Accounting-On is sent in the following cases:

• When the system is powered on.
• After a system reboots.
• When the acct-on-off command is added to the radius-server-policy configuration.
• Administrator triggered via CLI: tools perform aaa acct-on
8.2.3.3 Accounting request off
An Accounting-Off is sent in the following cases:

• Before an administrator-initiated system reboot.
• When the acct-on-off command is removed from the radius-server-policy configuration.
• Administrator triggered via CLI: tools perform aaa acct-off.
8.3 Subscriber Identification

Within Nokia implementation of Enhanced Subscriber Management (ESM), to fully describe
and identify a PPPoE session we need at least a ‘subscriber-id’, a ‘subscriber-profile’, an
‘SLA-profile’ and IP-address information. Different ways are possible to retrieve this kind of
Information: RADIUS server interaction, local/remote DHCPv4-server (LDHCPv4 server) interaction,
Local User Database (LUDB) interaction or a combination of the above. The following subsections
will show how ESM related strings and parameters will be returned or generated within Zain BNG
design.

Confidential
8.3.1 Subscriber-ID
A subscriber host is a device identified by a unique combination of IP address and MAC address, it
can be an end-user device, such as a PC, VoIP phone or a set top box, or it can be the user’s
Residential Gateway (RGW) if the RGW is using Network Address Translation (NAT).
A subscriber (in the context of the 7750 SR) is a collection of subscriber hosts getting common
(overall) treatment. It is expected that this group of hosts originate from the same site and all
hosts
of a subscriber are reached by the same physical path (such as a DSL port). A subscriber is uniquely
identified by a subscriber identification string, aka ‘subscriber-id’
a unique subscriber-id will be generated by the 7750SR for each PPPoE and IPoE user. The
automatically generated subscriber ID will have the format for PPPoE: mac | session-id
Where:
mac is the MAC address of the RGW or subscriber host initiating the PPPoE session.
session-id is the PPPoE session ID.
An example of the configuration of the format of the auto-generated subscriber id is given below.
Configuration must be applied on both BNG routers in the same site.
configure
subscriber-mgmt
auto-sub-id-key
ppp-sub-id-key mac session-id
exit
exit all
8.3.2 Session ID
Every PPPoE session is identified by: session-ID and a peer MAC address (subscriber’s and BNG’s
MAC addresses). By default, all PPPoE sessions with different MAC address on a given SAP have
session-id 1.
There are though some CPE routers that do not check MAC address to identify if the Ethernet
frame is destined to them or not.
In an Access network that is behaving without MAC learning (HUB behavior), those CPEs may
receive messages that are not sent to them and will interact with them.
Special case is when those CPE routers receive PADT (session termination) message sent by BNG
to another subscriber. but those CPEs will overlook the MAC address and only check session ID
which is by default “1” and terminate their session.
To help those kind of CPEs differentiate PPPoE messages, there is a knob in SROS to enable BNG
assign different session-id values to different sessions even from different MAC addresses:
configure subscriber-mgmt
ppp-policy "ppp-policy-1" create
unique-sid-per-sap
exit

Confidential
Please note that the session ID range is 1 —.8191. so maximum of 8191 sessions will be allowed
per SAP when “unique-sid-per-sap” command is configured.
8.3.3 Subscriber-profile (sub-profile)
In general, a SUB-profile defines the overall subscriber bandwidth. It’s a template which contains
Hierarchical QoS (HQoS) and accounting settings which are applicable to all hosts belonging to the
Same subscriber. It will include:
• Ingress and egress scheduler policy HQoS.

• RADIUS accounting policy.
Within Zain BNG design default SUB-profiles for HSI, will be configured locally on the BNG and will
have the previously configured RADIUS accounting policy AAA-BILLING.
configure
subscriber-mgmt
sub-profile "DefSubProfile" create
radius-accounting
policy "AAA-BILLING" #previously create Accounting Policy
exit
exit
8.3.4 SLA-profile (sub-profile)
In general, an SLA-profile defines subscriber host/application specific QoS and filter/security

requirements. In other words, for supporting multiple service types (such as high
speed Internet (HSI), voice over IP (VoIP), video on demand (VoD) and Broadcast TV) for a single
subscriber, the hosts associated with a subscriber can be subdivided into multiple SLA profiles. An
SLA profile acts like a template and can be used by many subscribers at one time. Settings include:
• Egress and ingress QoS settings
• Egress and ingress IP filters
• Host limit
Within Zain BNG design SLA-profiles for HSI are configured locally on the BNG and the configured
SLA-profile will be associated to subscribers on RADIUS server. The profiles used on Zain BNG are:
• FTTH_20Mbps
• FTTH_50Mbps
• FTTH_75Mbps
• FTTH_100Mbps
• FTTH_500Mbps
• FTTH_
And those SLA profile will be configured to use the previously configured QoS parameters:
configure
subscriber-mgmt
sla-profile <sla-profile-name> create
ingress
qos <sap-ingress-qos>
exit
exit
egress
qos <sap-egress-qos>

Confidential
exit
exit
exit
exit
Note: The locally configured SLA-profile is referenced by a name that can be 32 characters.
8.3.5 Subscriber identification policy
One of the main applications of the subscriber identification policy is to create mapping entries for
SUB-profiles and SLA-profiles. Each entry maps a SUB-profile string received in Alc-Subsc-Prof-
Str
VSA or an SLA-profile string received in Alc-SLA-Prof-Str VSA to one subscriber profile or SLA
profile configured on BNG. This could be required if the received string and the name of the
referenced profile are different.
Within Zain BNG design:

- no string will be returned from Radius for Subscriber-profile
- RADIUS will return exact SLA-profile name as it is configured on BNG
So default subscriber identification policy will be used
configure
subscriber-mgmt
sub-ident-policy "sub-ident-all" create
sub-profile-map
use-direct-map-as-default
exit
sla-profile-map
use-direct-map-as-default
exit
exit
exit all
8.4 BNG Redundancy

There are 3 BNG nodes within Zain network (RIY, JED, and DMM). BNG redundancy can be ensured
by pair of BNGs, so we will have 3 pairs of BNGs (RIY-JED, JED-DMM, DMM-RIY) where members
nodes can ensure redundancy for each other. for each pair of BNGs, all access devices (GPON) will
have redundant L2 connectivity to both member BNGs.

Confidential
Figure 17: Overall Redundancy Design-Phase 0
during phase 1, the geo-redundancy design will be reviewed to reflect the Zain requirement.
Hence, the new pairs of BNGs will be (RIY-DMM, DMM-JED, JED-RIY). The overall redundancy
design for phase 1 is illustrated below:
Figure 18: Overall BNG Redundancy Design-Phase 1
When we will discuss redundancy in the following section, we will refer to single pair of BNGs. Same
approach will be applicable for other BNG pairs.

Confidential
Redundant BNGs will be handling subscribers PPPoE sessions statefully; each subscriber will be
connected to one BNG at a time (Master BNG) and in case connectivity is broken to that BNG, the
subscriber session will failover seamlessly to the other BNG (Backup BNG).
The concept of BNG Master/Backup will be related to SRRP instances, so that each BNG is Master
for a set of subscribers and Backup for others, ensuring session load balancing between all BNGs.
It is important to note that with stateful BNG mode, sessions are synchronized between both BNGs
subject to synchronization; each PPPoE session is instantiated on both BNGs, but only one is
assuming the communication with subscriber. So, each session is in fact represented with two
sessions. The impact of this is that maximum PPPoE sessions supported by both BNGs is not the
sum of maximum that each BNG can support, but the maximum sessions is the max of one BNG.
To ensure stateful BNG session redundancy, the following will be configured:
- MCS (multi-Chassis Synchronization) to synchronize DHCP, SRRP, and Subscribers

between both BNGs
- SRRP (Subscriber Router Redundancy Protocol) to provide virtual BNG gateway for
subscribers
- DHCP: Each BNG will have local-DHCP server servicing a different set of prefixes,
and backing up the other BNG prefixes.
- Routing of subscriber prefixes: Each BNG will advertise its local DHCP prefixes with
a BGP lower MED value and advertise remote DHCP prefixes with higher MED
value. So that downstream traffic is always transiting initial address repartition.
The diagram below summarizes the redundancy design blocks for a pair of BNGs:
Figure 19: BNG Redundancy blocs
Please note that to distinguish between Access part and Routing to IGW in the diagram above, the
connectivity between BNGs and IPBB is logically represented as separate interconnections and is
not representing real physical topology.

Confidential
8.5 IPV4 address assignment and Management
8.5.1 Address Management
Within Zain BNG design, HSI PPPoE will be assigned IPv4 addresses dynamically.
For dynamic IPv4 address assignment, redundant local DHCPv4 servers will be deployed on each
BNG routers for IPv4 address management, within the HSI VPRN instance serving the HSI IPv4
dynamic subscribers. Each local DHCPv4 server in each service context will be associated with IPv4
loopback interface.
In Zain design Framed-Pool attribute absence in the RADIUS access-accept, in that case the
“giaddr” field of the DHCP relay message is used to find a matching subnet within the locally
configured pools, once a pool has been selected, an address is allocated from any subnet within
the selected pool; “use-gi-address scope pool”.
8.5.2 DHCP Server redundancy
DHCP Redundancy is relying on configuring DHCP servers on two BNGs, using exact same Pools
and subnets, and synchronize between them (using MCS).
Within Zain network, and to ensure maximum flexibility, TWO DHCP servers will be created on each
BNG node: and each DHCP server will be redundant (and synchronized) on the different BNG.
(please refer to figure below).
During normal operation, the local DHCPv4 server on BNG will be active for all subnets and address
ranges that are configured with “failover LOCAL” and will be standby for all subnets and address
ranges configured with “failover REMOTE”.
When one BNG leases IPv4 address to PPPoE subscriber from a pool, DHCPv4 lease is synchronized
with adjacent BNG router. DHCPv4 lease is renewed to both local DHCPv4 servers if the PPPoE
session is up. Upon failure of the active DHCPv4 server (local-dhcp-server on the BNG), the
redundant DHCPv4 server will detect the failure of the active DHCPv4 server and will change its
state to PartnerDown after partner-down-delay. Upon entering the PARTNERDOWN state, the
management of ‘Remote’ pool addresses will be taken over immediately without waiting for
Maximum Client Lead Time (MCLT) safety timer to expire while in PARTNER-DOWN state.
Since the DHCP lease synchronization failure can be caused by the failure of the
intercommunication link (and not necessary the entire node), there is a possibility the redundant
DHCP servers become isolated in the network. In other words, they can serve DHCP clients but
they cannot synchronize the lease. This can lead to duplicate assignment of IP addresses, since the
servers have configured overlapping IP address ranges but they are not aware of each other’s
leases.
- partner-down-delay: The purpose of the partner-down-delay is to prevent the IP lease
duplication during the intercommunication link failure by not allowing new IP addresses to be
assigned from the remote IP address range. This timer is intended to provide enough time to
remedy the failed situation and to avoid duplication of IP addresses/prefixes during the failure.
During the partner-down-delay time, the prefix designated as remote will be eligible only for
renewals of the existing DHCP leases that have been synchronized by the peering node.

Confidential
- Maximum Client Lead time (MCLT) The purpose of the MCLT is when the local DHCP server
assigns a new IP lease to the client but it crashes before it sends a sync update to the partner
server. Because of the local DHCP server failure, the remote DHCP server is not aware of the IP
address/prefix that has been allocated on the local DHCP server. This condition creates the
possibility that the remote DHCP server allocates the same address/prefix to another client. This
would cause IP address/prefix duplication. MCLT is put in place to prevent this scenario by
preventing DHCP server from allocating addresses form “Remote” subnets until MCLT is expired
(assuming this is long time enough for all remote addresses to be released by subscriber). Then
when DHCP server start allocating addresses from “Remote” subnets, it is guaranteed there will be
no conflict.
- Startup-wait-time is the time the local DHCP server will wait after boot before start assuming
active DHCP role. This is to ensure enough time to MCS to synchronize before starting DHCP
operation.
Only after the sum of the partner-down-delay and the maximum-client-lead-time will the prefix
designated as remote be eligible for delegation of the new DHCP leases. When this occurs, we say
that the remote IP address range has been taken over.
Within Zain implementation, fast takeover is required in case one BNG crashes. So, partner-down-
delay sill be set to 10s (allowing for any underlaying protocol reconvergence in case connectivity
between BNGs experience some problems), and MCLT will be set to 0 (ignore-mclt-on-takeover).
The configuration applied for DHCP redundancy in phase 0 is as follow:
Figure 20: DHCP Redundancy-Phase 0
For phase 1, the DHCP redundancy configuration will follow the design below:

Confidential
Figure 21: DHCP Redundancy-Phase 1
The migration procedure of the geo-redundancy will be detailed in separated document.
First, Multi-Chassis Synchronization (MCS) for local DHCP server application must be enabled
before configuring DHCP server failover (redundancy), then local DHCPv4 server configuration can
be applied. In the configuration example, two pools are created POO. Each pool may be configured
with one or multiple subnets. Each subnet is configured with one or multiple address ranges.
Note that one address range can contain at most 16384 addresses.
Note also that the parameter ‘failover local’ is default and can only be shown using ‘info detail’.
The following example is from RIY-BNG for DHCP Redundancy configuration with both JED-BNG
and DMM-BNG.
A:RIY-BNG# configure
redundancy
multi-chassis
# configuration to peer with Jeddah
peer 10.158.177.2 create
...
sync
...
local-dhcp-server
...
no shutdown
exit
no shutdown
exit
# configuration to peer with Dammam
...
sync
...
local-dhcp-server
...
no shutdown
exit
no shutdown

Confidential
exit
exit all
A:RIY-BNG# configure
service vprn 10
dhcp
# create Local DHCP Server to be synchronized with DMM
local-dhcp-server "DHCP-DMM-RIY" create
use-gi-address scope pool
use-pool-from-client
# create Pool for Dawiyat subnets
pool "POOL-DAW-DMM-B" create
options
dns-server 79.170.51.61
lease-time days 1
lease-renew-time hrs 12
lease-rebind-time hrs 18
exit
subnet 10.113.128.0/17 create
options
default-router 10.113.128.1
exit
# note the failover remote, to indicate it is standby.
address-range 10.113.128.4 10.113.191.255 failover remote
address-range 10.113.192.0 10.113.255.255 failover remote
exit
exit
failover
peer 10.158.177.3 tag "dhcp-dmm-riy"
ignore-mclt-on-takeover
partner-down-delay sec 10
no shutdown
exit
no shutdown
exit
# create Local DHCP Server to be synchronized with JED
local-dhcp-server "DHCP-RIY-JED" create
use-gi-address scope pool
use-pool-from-client
pool "POOL-DAW-RIY-A" create
options
dns-server 79.170.51.61
lease-time days 1
lease-renew-time hrs 12
lease-rebind-time hrs 18
exit
subnet 10.112.128.0/17 create
options
default-router 10.112.128.1
exit
address-range 10.112.128.4 10.112.191.255
address-range 10.112.192.0 10.112.255.255
exit
exit
failover
peer 10.158.177.2 tag "dhcp-riy-jed"
ignore-mclt-on-takeover
partner-down-delay sec 10
no shutdown
exit
no shutdown
exit
exit
interface "dhcp-daw-riy" create
address 10.158.177.8/32
dhcp
no shutdown
exit
local-dhcp-server "DHCP-RIY-1-A"
loopback
exit
interface "dhcp-daw-dmm" create

Confidential
address 10.158.177.13/32
dhcp
no shutdown
exit
local-dhcp-server "DHCP-DMM-1-B"
loopback
exit
When local DHCP Server redundancy/synchronization is used, using address-range “failover local |
remote”, in conjunction with PPPoE in multi-chassis environment, both DHCP servers must be
referenced under the corresponding group-interface on each node.
subscriber-interface <sub-if>
group-interface <grp-if>
dhcp
server <local-dhcp-ip-address> <remote-dhcp-ip-address>
It is also necessary for the successful renewal of the IP address on the remote DHCP server, that
the remote DHCP server has a valid return path back to the gi-address of the forwarder of the
renewal request. (Please refer to section “8.9.2 Subscriber Interface” for details).
When new subscriber tries to connect (assuming it will get dynamic IP address), BNG that is SRRP
master (let’s assume it is BNG-1) will attempt getting IP address from its Local DHCP server
(because it is the first configured DHCP server). Local DHCP server will then provide address as
soon as it has free addresses from subnets that are “failover local”. When local DHCP server
addresses are all leased to subscribers, and a new subscriber tries to connect, BNG-1 will not find
any IP address locally to allocate and will then send request to DHCP server on BNG-2 (because it is
the second configured server) that will reply with address from its “failover local” subnets.
8.6 PPP Policy

PPP policy within the subscriber-management context contains PPPoE session parameters like
keepalive interval and authentication protocols. One PPP policy will be created and will configured
with the following:
• PPP authentication method: CHAP
• Maximum PPPoE sessions per MAC address: 1 (default)
• unique-sid-per-sap per-msap: By default, all PPPoE sessions with different MAC address on
a given SAP or MSAP have session-id 1. This command assigns a unique session ID to each
PPPoE session with different MAC addresses that is active on a single SAP. The maximum
session ID range is 1 —.8191.
• reject-disabled-ncp: forces an LCP Protocol Reject when receiving an IPv6CP Configure
Request message while IPv6 is not configured. By default, an IPv6CP Configure Request
message is silently ignored when IPv6 is not configured.
• PPP-Init-Delay: The command artificially delays the start of the PPP stack after the
discovery phase by 50ms allowing downstream devices that have difficulty with rapid PPP
replies from 7750 SR to update their internal state and to deliver the ppp packets in the
right order.
configure
subscriber-mgmt
ppp-policy "ppp-policy-1" create
keepalive 30 hold-up-multiplier 3 # default
no max-sessions-per-mac # default (means 1 session/MAC)
unique-sid-per-sap
ppp-initial-delay
exit all

Confidential
8.7 SRRP (Subscriber Router Redundancy Protocol)
SRRP is a modification to the existing VRRP protocol adapted to the ESM environment, where SRRP
is closely tied to the multi-chassis synchronization protocol used to synchronize information
between
redundant nodes (Active and Backup). An MCS peer must be configured and operational when
subscriber hosts have a redundant connection to two nodes. Subscriber hosts are identified by the
ingress SAP, the hosts IP and MAC addresses.
Once a host is identified on one node, the MCS peering is used to inform the other node that the
host exists and conveys the dynamic DHCP lease state information of the host (if applicable). MCS
creates a common association between the virtual ports (SAPs) shared by a subscriber. This
association is configured at the MCS peering level by defining a tag for a port and range of SAPs.
The same tag is defined on the other nodes peering context for another port (does not need to be
the same port- ID) with the same SAP range. In this manner, a subscriber host and QinQ tag sent
across the peering with the appropriate tag will be mapped to the redundant SAP on the other
node.
Once SRRP is active on the group IP interface, the SRRP instance will attempt to communicate
through in-band (over the group IP interfaces SAPs) and out-of-band (over the group IP interfaces
redundant IP interface) messages to a remote router. If the remote router is also running SRRP
with
the same SRRP instance ID, one router will enter a master state while the other router will enter a
backup state. For proper operation, each subscriber subnet associated with the SRRP instance
must have a GW address defined.
Within Zain BNG design, one SRRP policies (like VRRP policy) will be tracking the following:
• Presence of default route in HSI VRF table that is learned via static
Absence of this condition will cause SRRP priority decrement (decrement by 40). If SRRP priority
goes below standby SRRP priority, SRRP switchover will take place, gratuitous ARP will be sent from
the new master SRRP and consequently all PPPoE subscribers that are bound to this SRRP instance
will be switched to the newly promoted master BNG.
Please note the usage of “context” keyword when creating policy, this will identify HSI VPRN
service (that will be used for validating presence or not of default route).
configure
vrrp
policy 1 context 10
description "HSI-SRRP-Policy"
priority-event
route-unknown 0.0.0.0/0
priority 40 delta
exit
exit
exit
exit

Confidential
Zain BNG deployment is PPPoE only, in which there are multiple subnets under the subscriber
interface. In such case, if the switchover occurs, it will be sufficient to send a single Gratuitous ARP
on every VLAN to update the Layer 2 forwarding path in the access aggregation network. This
single gratuitous ARP will contain the IP address of the first GW address found under the
subscriber interface address. This is indicated by the following command under the SRRP: “one-
garp-per-sap”.
SRRP instance will be created for each Group-Interface using a chosen QinQ VLAN tags to
transport SRRP messages. This message path is assumed to use the same links as subscribers
traffic on L2 backhaul so that any L2 connectivity problem impacting subscribers’ access to BNG
will be also detected by SRRP.
The following configuration will be used:

configure
service
subscriber-interface "RMS-BNG1-HSI-sub-intf-1" create
group-interface "OLT-DAW-10G" create
sap a/b/c:x.y create # x.y are QinQ VLANs used for SRRP msgs.
exit
srrp x create
message-path a/b/c:x.y
policy 1
priority 120 # to make it master. default is 100
one-garp-per-sap
no shutdown
exit
Within Zain Network SRRP instances will be used according to the following principles:
- SRRP 12: between RIY-BNG and JED-BNG
▪ VLAN 35.4094 for messaging
▪ RIY is master, JED is standby
- SRRP 23: between JED-BNG and DMM-BNG
▪ JED is master, DMM is standby
- SRRP 31: between DMM-BNG and RIY-BNG
▪ DMM is master, RIY is standby
Please note: that per current design, it is assumed that IPBB aggregation network is ensuring
redundancy and resiliency within MPLS network (FRR, standby LSP) and VPLS services (STP or
similar feature). BNG is not aware of, and is not expected to detect, any failure occurring within
IPBB network. BNG failure detection is based on the failure of the directly attached ports.

Confidential
Figure 22: SRRP failure detection
8.8 Multi-Chassis Synchronization (MCS)

Subscriber Routed Redundancy Protocol (SRRP) is closely tied to the multi-chassis synchronization
protocol used to synchronize information between redundant nodes.
Figure 23: Multi-Chassis Synchronization (MCS)
The synchronization process provides the means to manage distributed database (the Multi-
Chassis Synchronization (MCS) database), which contains the dynamic state information created on
any of the nodes by any application using its services.
The individual entries in the MCS database are always paired by peering-relation, sync-tag and
application-id. At any time the given entry is related to the single redundant-pair objects (two SAPs
on two different nodes) and hence stored in a local MCS database of the respective nodes.
Internally, peering-relation and sync-tag are translated into a port and encapsulation value
identifying the object (SAP) that the given entry is associated with. The application-id then
identifies the application which created the entry on one of the nodes.
An MCS peer must be configured and operational when subscriber hosts have a redundant
connection to two nodes.

Confidential
Multi-Chassis Synchronization (MCS) for DHCP, SRRP, and PPPoE subscribers’ management must
be
enabled. Sync Tag for BNG backhaul PORT must be created to sync the ESM states on the
corresponding SAPs associated with this PORT.
Following is MCS configuration in RIY-BNG:

configure
redundancy
description "sync-with-JED-BNG"
sync
local-dhcp-server
srrp
sub-host-trk
sub-mgmt ipoe pppoe
port 1/1/1 sync-tag "port-1" create
port lag-10 create
range 35.4094-35.4094 sync-tag "DMM-RIY"
range 1111.*-1119.* sync-tag "DMM-RIY"
exit
exit
no shutdown
exit
no shutdown
exit
description "sync-with-DMM-BNG"
sync
local-dhcp-server
srrp
sub-mgmt ipoe pppoe
port lag-10 create
range 33.4094-33.4094 sync-tag "DMM-RIY"
exit
no shutdown
exit
no shutdown
exit
exit all
Each time the connection between the redundant pair nodes is (re)established the MCS database
will be re-synchronized. There are several levels of connectivity loss which may have different
effect on amount of data being lost. To prevent massive retransmissions when the
synchronization connection experiences loss or excessive delay, the MCS process implementation
will take provisions to ensure following:
- In the case of a reboot of one or both nodes or establishing the peering for the first time,
the full MCS database will be reconciled.
- In the case that the MCS communication is lost and then re-established but neither node
rebooted during the connection loss, only the information not synchronized during this time
will be reconciled (using sequence numbers helps identify information which was not
synchronized).
- In the case that MCS communication is lost because of excessive delay in ACK messages
but no information has been effectively lost, the MCS process indicates a loss of
synchronization but no reconciliation is performed.

Confidential
8.9 ESM Interfaces
Within Nokia implementation of Enhanced Subscriber Management (ESM), different interface types
are defined. Those interfaces types are detailed in the following sections.
8.9.1 Redundant Interface
In redundant BNG deployments where one BNG is acting as Master and the redundant BNG is
acting as Backup, the redundant-interface is used in the downstream direction. Traffic arriving on
the Network links on the Backup node is shunted over to the Master node over the redundant-
interface.
This is required to ensure consistent QoS and accounting functionality across the nodes (upstream
and downstream traffic on the access links for a subscriber must traverse the same BNG node). A
redundant interface is a Layer 3 spoke SDP-based interface (please refer to section 7.2.4 for SDP
details) that allows delivery of packets between the two nodes. The redundant interface can be
assigned /31 or /30 IP addresses.
An example of the redundant interface within the BNG HSI VPRN is given below. When using /30
addressing, remote peer address is required to be specified. When /31 IP addresses is used,
remote-ip keyword will not be required.
configure
service
redundant-interface "red-riy-dmm" create
address 10.158.177.38/31
spoke-sdp 103:100 create
no shutdown
exit
no shutdown
exit
exit
exit
8.9.2 Subscriber Interface
In Nokia ESM deployment, a subscriber interface allows subnet sharing between multiple group
interfaces (access nodes).
Within Zain BNG design, one subscriber interface will be created per HSI service instance. All
dynamic subscriber subnets will be defined under that subscriber interface (set of addresses from
all Local DHCP address-ranges). For a given pair of BNGs, On BNG1, the subscriber interface will be
assigned the second IPv4 address of the subscribers’ subnet. On BNG2, the subscriber interface
will be assigned the third IPv4 address of the subscribers’ subnet. The first IPv4 address of the
subscriber’s subnet will be the SRRP floating IP address.
In Zain design, state of different SRRP instances will be tracked under the subscriber interface and
hence, downstream routing (traffic from IGW to BNG) will be based on the associated SRRP state.
At any time, advertising the subscriber prefixes will be preferred from the current SRRP Master,
thereby allowing Downstream traffic to be routed towards the optimal path and minimizing the
usage of shunt (redundant) interface. This is done using routing policy applied towards the
subscriber-interface route.

Confidential
configure
service
vprn 10
subscriber-interface "BNG1-HSI-sub-intf-1" create
allow-unmatching-subnets
address 10.158.173.2/24 gw-ip-address 10.158.173.1 track-srrp 12
...
exit
exit
8.9.3 Group Interface
Within Nokia ESM deployment, a group interface allows multiple SAP’s on the same port to be
configured as part of a single interface.
For phase 0 implementation of Zain network, QinQ VLAN model is used. different Service VLAN per
GPON is assigned, but still User-VLAN is the same and not used for differentiation. Therefore, In
order to achieve a load balancing over the three redundant BNGs, the service VLANs are
distributed between them as following:
VLAN range Primary BNG Standby BNG

1110-1119, 1121-1124 RIY JED
2111-2114, 2411-2412 JED DMM
2311-2314, 2321-2324 DMM RIY
Table 7: VLAN repartition and redundancy-phase 0
Since the geo-redundancy will be changed in phase 1, the new VLANs distribution will be as follow:
VLAN range Primary BNG Standby BNG

1110-1119, 1121-1124 RIY JED
2111-2114, 2411-2412 JED DMM
2311-2314, 2321-2324 DMM RIY
Table 8: VLAN repartition and redundancy-phase 1
Group interfaces will be created with the following high-level design guidelines:
HSI VPRN Service:

• For each port (or LAG) connecting to Access/Aggregation L2 network, one Group interface
will be attached to all VLANs for which the BNG is primary, and another Group interface for
VLANs that the BNG is standby for.
• A different SRRP instance will be attached to each group interface
• Using of SRRP priority 120/100 to control Active/Standby.
• Anti-spoofing under group-interface will be used (and cannot be disabled).The default anti-
spoofing option is set to mac-sid, which means that the incoming traffic is checked against
the source MAC address and the session-ID.
Following is configuration example of RIY-BNG:

Configure

Confidential
service
vprn 10
group-interface "OLT-DAW-10G" create
dhcp
server 10.158.172.36 10.158.172.37
trusted
lease-populate 1000
client-applications ppp
gi-address 10.112.128.2
no shutdown
exit
authentication-policy "auth-policy-1"
oper-up-while-empty
sub-sla-mgmt
def-sub-id use-auto-id
def-sub-profile "DefSubProfile"
def-sla-profile "defaul"
sub-ident-policy "sub-ident-all"
multi-sub-sap 32767
no shutdown
exit
exit
sub-sla-mgmt
multi-sub-sap 32767
no shutdown
exit
exit
sub-sla-mgmt
multi-sub-sap 32767
no shutdown
exit
exit
sub-sla-mgmt
multi-sub-sap 32767
no shutdown
exit
exit
sub-sla-mgmt
multi-sub-sap 32767
no shutdown
exit
exit
sub-sla-mgmt

Confidential
multi-sub-sap 32767
no shutdown
exit
exit
sub-sla-mgmt
multi-sub-sap 32767
no shutdown
exit
exit
sub-sla-mgmt
multi-sub-sap 32767
no shutdown
exit
exit
sub-sla-mgmt
multi-sub-sap 32767
no shutdown
exit
exit
sub-sla-mgmt
multi-sub-sap 32767
no shutdown
exit
exit
sub-sla-mgmt
multi-sub-sap 32767
no shutdown
exit
exit
sub-sla-mgmt
multi-sub-sap 32767
no shutdown
exit
exit
sub-sla-mgmt

Confidential
multi-sub-sap 32767
no shutdown
exit
exit
sub-sla-mgmt
multi-sub-sap 32767
no shutdown
exit
exit
pppoe
policy "ppp-policy-1"
session-limit 32767
sap-session-limit 32767
no shutdown
exit
exit
group-interface "OLT-DAW-10G-DMM-RIY" create
srrp-enabled-routing
dhcp
server 10.158.177.13 10.158.177.12
trusted
lease-populate 32767
client-applications ppp
gi-address 10.113.128.3
no shutdown
exit
authentication-policy "auth-policy-1"
redundant-interface "red-riy-dmm"
sub-sla-mgmt
multi-sub-sap 32767
no shutdown
exit
exit
sub-sla-mgmt
multi-sub-sap 32767
no shutdown
exit
exit
sub-sla-mgmt
multi-sub-sap 32767
no shutdown
exit
exit

Confidential
sub-sla-mgmt
multi-sub-sap 32767
no shutdown
exit
exit
sub-sla-mgmt
multi-sub-sap 32767
no shutdown
exit
exit
sub-sla-mgmt
multi-sub-sap 32767
no shutdown
exit
exit
sub-sla-mgmt
multi-sub-sap 32767
no shutdown
exit
exit
sub-sla-mgmt
multi-sub-sap 32767
no shutdown
exit
exit
exit
srrp 31 create
message-path lag-10:33.4094
policy 10
no shutdown
exit
pppoe
policy "ppp-policy-1"
session-limit 32767
sap-session-limit 32767
no shutdown
exit
no shutdown
exit

Confidential
8.10 SRRP-Aware Routing
Optimal operation would call for the shunt traffic to be eliminated and at the same time, a high IP
route aggregation on the network side is achieved. The existence of the shunt traffic stems from
the fact that routing protocols, by default, advertise subscriber subnets into the network with no
awareness of the SRRP activity state (Master/Standby).
Within Zain network, SRRP-Aware routing will be implemented, allowing controlled and balanced
routing in steady situation.
In this scenario, we call BNG-1 and BNG-2 any pair of BNGs that are acting as SRRP Active/Standby
(RIY-JED, JED-DMM, DMM-RIY). Route Advertisement is based on the SRRP state:
Figure 24: SRRP-Aware Routing
- Route advertisement policy is configured on both BNG-1 and BNG-2. SRRP state is
monitored. BNG that is in SRRP master state, will advertise subscriber prefixes to the IGW.
- Requires that each Group-interface has its own dedicated DHCP subnets in order for
routing of those subnets to follow SRRP state. Which is fulfilled within Zain deployment.
To achieve that, the following policy is used to export routes into BGP within HSI VPRN:
Configure
router
policy-options
begin
# create prefix list matching all dhcp subnets that will be redundant
prefix 10.112.128.0/17 exact
prefix 10.113.128.0/17 exact
prefix 10.158.173.0/24 exact
prefix 10.158.177.128/25 exact
exit
policy-statement "export-bgp-vprn10"
entry 10
description "set MED 10 if SRRP master"
from
protocol direct
state srrp-master
exit
to
protocol bgp
exit
action accept
metric set 10
exit
exit

Confidential
entry 20
description "set MED 1000 if SRRP standby"
from
protocol direct
state srrp-non-master
exit
to
protocol bgp
exit
action accept
metric set 1000
exit
exit
entry 100
description "to advertise loopbacks of local DHCP servers"
from
protocol direct
prefix-list "dhcp-loopbacks"
exit
to
protocol bgp
exit
action accept
exit
exit
exit
commit
exit
/configure
service vprn 10
bgp
min-route-advertisement 1
rapid-withdrawal
group "PE"
family ipv4
export "export-bgp-vprn10"
peer-as 43766
bfd-enable
exit
exit
exit
no shutdown
exit all
And also to ensure the policy is updated upon SRRP events (switchover), SRRP tracking needs to be
configured on the Subscriber-interface:
configure
service
vprn 10
allow-unmatching-subnets
...
exit
exit

Confidential
Confidential
9. BNG Migration Strategy
The purpose of this chapter is to outline the methodology of migrating BNG services from 7750
SR-7 to SR-12 in Zain Network to achieve phase 1 capacity target.
9.1 Migration Method Overview

As per phase 0, the BNG implementation in Zain network is based on stateful redundancy: each
pair of BNG is ensuring backup for each other. This means that in case of master BNG failover, the
subscriber sessions will fail seamlessly to the backup one.
Based on the previous, the one-shoot hot swap procedure will be adopted to migrate the BNG
chassis from 7750 SR-7 to 7750 SR-12. The highlight of the migration method is illustrated in the
table below:
Step Activity Risk Management Plan

Install and commission new 7750 SR-12
Work in a maintenance
1 (rel. 15) in the same rack (assumption:
window
enough space & power are available)
Lay down and accept new cables Accept the optical
2 (assumption: only 1x 10GE cables & 1x Faulty optical jumpers jumpers before
1GE cable) migration
Copy/modify 7750 SR-7 (rel 15) to 7750 Standalone acceptance before
3 Wrong configuration
SR-12 (rel 15) migration
4 Standalone acceptance - -
Migration Night:
Offload the concerned BNG by
switching over the subscribers to the
Rollback procedure ready in
5 backup BNG Service interruption
case of service affecting
Move disconnect the SR-7 cables from
the VSS and connect the 7750 SR-12
cables
Table 9: BNG Migration Steps
9.2 Migration Execution

To illustrate the migration procedure, we will consider the following topology were, in steady state,
BNG-1 is active and BNG-2 is backup. The BNG-1 will be migrated.

Confidential
Figure 25: BNG Service Migration-Step 0
Considering the swap of BNG-1, we will switch all traffic to BNG-2. This switchover should be non-
service affecting since stateful redundancy is deployed. Upon BNG-1 failover, the following will
occur:
- existing subscribers are expected to:

o NOT restart PPPoE sessions
o Keep the same previously assigned IP addresses.
o Still have Internet reachability
- Newly subscribers (connecting after the failure):
o Will be able to establish PPPoE session with BNG-2 (if well authenticated)
o Will get IP address assigned from Riyadh IP pool (but assigned by BNG-2) and
granted the Internet access

Confidential
Once old BNG-1 is offloaded and subscribers are switched to BNG-2, the migration continues by
swapping the physical links between BNG and VSS from old to the new one. Two scenarios can be
used:
- In case the 100G ports are available on VSS/EOR, the links on new BNG-1 will be 100G.
- If the 100G ports are not ready on VSS/EOR, we will use a n*10G bundle between the new
BNG-1 and the VSS. The number of 10G links will be defined by Zain.
After laying the physical cables on the new device, connectivity test will be performed to confirm
the status of fiber and optical transceiver.

Confidential
After confirming the physical readiness and copying the modified configuration file to the new
BNG-1 (note that the LAG interface should be deactivated in the new BNG as well), we will perform
LAG restoration. Upon network convergence, the new BNG-1 will become active by handling the
existing and new subscriber will BNG-2 will keep synchronizing as backup.

Confidential
10. Network management
10.1 Basic 7750SR System configuration
10.1.1 Boot Options File (BOF)
The Nokia 7750 SR-Series routers do not contain a boot EEPROM. The boot loader code is
loaded from the boot.ldr file located on the Compact Flash (CF) card #3 on the CPM. The BOF file
(located on CF #3 as well) performs the following tasks:
1. Sets up the CPM Ethernet port (speed, duplex, auto).
2. Assigns the IP address for the CPM Ethernet port.
3. Creates static routes for the CPM Ethernet port.
4. Sets the console port speed.
5. Configures the Domain Name System (DNS) name and DNS servers.
6. Configures the primary, secondary, tertiary configuration source.
7. Configures the primary, secondary, and tertiary SROS image source.
8. Configures operational parameters.
The most basic BOF configuration should have the following:
• Active CPM Ethernet port address
• Primary SROS image location
• Primary configuration file location
Below are the guidelines for configuring the BOF parameters on the 7750SR:
• CPM Console Port Speed

The CPM console port baud rate is set to 115,200 bps (default). Other default console port
Parameters are listed below.
Baud Rate : 115200

Data Bits : 8
Parity : None
Stop Bits : 1
Flow Control : None
• Primary SROS Image Location

This is the primary local or remote directory where the 7750 SROS image files are located
(typically the cpm.tim, iom.tim, isa-aa.tim files). The primary location for the SROS images
files will be a directory on CF #3 of the 7750SR CPM, for example “cf3:\TiMOS-SR-
14.0.R10”.
• Primary Configuration Location
This is the directory and file name that specifies the primary location of the 7750SR
configuration.
The primary configuration will be stored in a file named <node-name>.cfg on CF #3 of the
7750SR CPM.
• CPM Ethernet Port Speed and Duplex
The CPM Ethernet port will be configured to operate at 100 Mbps full-duplex with auto-
negotiation disabled (default).
• Active CPM Ethernet Port Address
This address is assigned to the management Ethernet port on the active CPM (whether it is
in slot A or slot B). This is the OOB management IP address of the 7750SR. in Zain no OOB
management will be used so SNMP, SSH Traffic will use inband ip address .
• Standby CPM Ethernet Port Address

Confidential
This address is assigned to the management Ethernet port on the standby CPM (whether it is in
slot A or slot B). in Zain No IP address will be used management traffic uses this IP address.
• SNMP Index Persistency
System indexes (including interface indexes, LSP IDs, path IDs, services indexes, VRF indexes) can
be preserved between 7750SR reboots. This reduces the required resynchronizations of the
Network
Management System (typically the 5620SAM) with the affected network element after it has
rebooted. When system indexes persistency is enabled, system indexes are saved in a .ndx file in
the same location and with the same name of the 7750SR configuration file each time the “admin
save” command is issued (if storage space is available). During a subsequent boot, the index file is
read along with the configuration file and objects are initialized with their persistent indexes from
the index file.
Persistency will be disabled for both BNGs as 5620 SAM will not be present in Zain Network.
Below is a template for the BOF file configuration
/bof console-speed 115200 # default

/bof primary-image cf3:\TiMOS-SR-14.0.R10
/bof primary-config cf3:\RIY-BNG-config.cfg
/bof speed 100 # default
/bof duplex full # default
/bof persist off
/bof save
10.1.2 Synchronization and Redundancy
The 7750 SRs will be deployed with dual Switch Fabric/Control Processor Modules (SF/CPM) for 1:1
redundancy. Typically, the first CPM card installed in a 7750 chassis assumes the active role,
regardless of being inserted in Slot A or B, whilst a subsequent CPM installed in the same chassis
will assume the role of standby CPM.
Redundancy methods facilitate system synchronization between the active and standby CPM so
that
They maintain identical operating parameters. When an active CPM goes offline (due to reboot,
Removal , or failure), the standby CPM takes control without rebooting or initializing itself. In order
to effectively achieve this, it is clearly a requirement that the file systems on the active and
standby
CPMs are synchronized.
Synchronization between CPMs can be manual or automatic. Manual synchronization requires that
the “admin redundancy synchronization” command is entered and is the default mode of
synchronization.
With automatic synchronization, any save or delete file operations implemented on the active CPM
are mirrored onto the standby CPM. The level to which these file systems are synchronized is a
configurable option. When the ‘boot-env’ parameter is specified, the BOF (bof.cfg), boot loader
(boot.ldr), configuration file (.cfg), index persistency file (.ndx), and the image files (cpm.tim,
iom.tim, isa-aa.tim) are synchronized. When the ‘config’ parameter is specified, only the BOF
(bof.cfg), configuration files (.cfg), and index persistency file (.ndx) are synchronized. The ‘boot-
env’
option is recommended during initial installation and during upgrade, however, during normal
operation the ‘boot-env’ option is potentially sub-optimal because it will synchronize all files
(including images) after any save operation. Therefore, post install/upgrade, the ‘config’ option is
recommended.

Confidential
Automatic redundancy is not enabled by default. To configure automatic redundancy for ‘config’
or
‘boot-env’ mode, enter the following command:
/configure redundancy synchronize config | boot-env
To manually perform the synchronization between CPMs, use the command:
/admin redundancy synchronize config | boot-env
10.1.3 System Information
10.1.3.1 System Name
System name is the node’s fully-qualified domain name. The system name can be any ASCII
printable text string of up to 32 characters that represents SNMPv2 sysName object.
The following template is for RIY-BNG-1:
configure system name RIY-BNG-1
10.1.3.2 Location, Contact and coordinates
The location of a 7750SR, a contact and coordinates can be specified using the system
“location/contact/coordinates” configuration commands. All three entries can be up to 80
printable
seven-bit ASCII characters. If the location/contact/coordinates text string contains spaces,
doublequotes will be used to delimit the start and end of the string.
configure system
location <location>
contact <contact-name>
coordinates <coordinates>
exit
10.1.4 SNMP
The Simple Network Management Protocol (SNMP) is a requirement in order to effectively operate
and manage the IP/MPLS network infrastructure. For any SNMP requirements SNMPv3 should be
adopted for use given its inherent ability to support confidentiality and integrity. The use of
SNMPv3 serves to make the use of SNMP set packets less of a concern as
encryption/authentication can be used to verify that a valid use has sent the packet and that it has
not been tampered with in transit. Finally, the group-based administrative model allows different
users to access the same SNMP agent with varying access privileges.
The 7750 SR, 7210 SAS and 7705 SAR supports SNMPv1, SNMPv2c, and SNMPv3. Default
implementation of SNMP uses SNMPv3, which incorporates security model and security level
features. A security model is the authentication type for the group and the security level is the
permitted level of security within a security model. The combination of the security level and
security model determines which security mechanism handles an SNMP packet.

Confidential
According to the security features of the SNMPv3 used as a management protocol between the
5620 SAM and the 7750/7705 nodes. SNMPv3 will be used by the 5620 SAM for mediation of all
BNG nodes. The benefits of SNMPv3 mediation are:
• It provides additional security (encryption)
• It enables the SAM to manage security on the NE
• It protects the SAM from accidental introduction of a NE with a duplicate System Address
• It simplifies VPRN configuration, requiring only a single VPRN community string per node
(as opposed to 1 per service when using SNMPv2c)
To configure SNMP on the 7x50 nodes the following CLI command sequence is applied;
1 Configure the persistence in the bof. The change will take effect after rebooting the
node.
bof persist on
bof save
2 Enable SNMP
configure system snmp packet-size 9216

configure system snmp no shutdown
3 Configure SNMP v3 and v2c in the ‘configure>system>security>snmp’

context
i. New SNMP access groups are configured for SNMP v3
access group "nmsNoAuth" security-model usm security-level no-auth-no-privacy

read "iso" write "iso" notify "iso"
access group "snmpV3users" security-model usm security-level privacy read "iso"

write "iso" notify "iso"
access group "snmpV3users" security-model usm security-level privacy context

"vprn" prefix read "vprn-view" write "vprn-view" notify "iso"
Please note that, the SAM is likely to be used to create new SNMPv3 NE users. When the
SAM performs this operation it uses the group named “nmsPriv”. Therefore, this group
name should be configured.
access group "nmsPriv" security-model usm security-level privacy read "iso"
write "iso" notify "iso"
access group "nmsPriv" security-model usm security-level privacy context vprn

prefix read vprn-view write vprn-view notify iso community "private" rwa
version both
ii. New SNMP community is configured for SNMP vc2
community "CK9R1GOr93TBLck7htCIyogdvV0canoS" hash2 r version v2c

community "g4MfIt.Rhn09BlyVuLA54mqIiZc.qv5d" hash2 r version both
iii. MD5 key value is created on the 5620 SAM server by using the node “engine-id”
value as the parameter. The command to run on 5620 SAM CLI to produce MD5
key is not in the scope.
*A:7750_lab2# show system information

===============================================================================
System Information
===============================================================================
System Name : 7750_lab2

Confidential
System Type : 7750 SR-12
System Version : C-13.0.R7
. . .
SNMP Port : 161
SNMP Engine ID : 0000197f00000ca402a5d001
SNMP Engine Boots : 5
SNMP Max Message Size : 9216
SNMP Admin State : Enabled
SNMP Oper State : Enabled
SNMP Index Boot Status : Persistent
SNMP Sync State : OK
iv. A new SNMP user is created using the MD5 key
configure system security user snmpV3admin

access snmp
snmp authentication md5 <MD5-KEY> privacy des-key <MD5-KEY>
snmpgroup snmpV3users
exit all
configure system snmp no shutdown
10.1.4.1 Generating MD5 Key
The utility file which generates the key is located in the ‘~/bin’ directory on the SAM Server and the
SAM Client:
Solaris Server: /opt/5620sam/server/nms/bin/password2key.bash
Windows Client: C:\5620sam\server\nms\bin\nmsclient.bat password2key
Generate the key (UNIX example) using the syntax shown below:
./password2key.bash method password engineID
C:\5620sam\server\nms\bin\nmsclient.bat password2key <method> <password> enginID
Method – MD5 (or SHA)
Password – Password string
EngineID – SNMP Engine ID of the NE in hexadecimal form
Example
bash# password2key.bash md5 alcatel 0000197f00000003fa14bfa7
33cf8fc846cef41713568ec4db163e74
C:\5620sam\server\nms\bin\nmsclient.bat password2key md5 admin
0000197f00000003fa14bfa7
33cf8fc846cef41713568ec4db163e74
On the NE, these MD5 values can be used on the SNMP configuration as explained above.
10.1.5 System Time
10.1.5.1 NTP
NTP allows for the participating network nodes to keep time more accurately and more importantly
they can maintain time in a more synchronized fashion between all participating network nodes.
Within ZAIN design, accounting is performed towards RADIUS servers. On top, we need to have
both BNG nodes synchronized for the proper Multi-Chassis Synchronization for synchronizing
DHCP leases,SRRP and PPPoE subscriber management states.
For this purpose, a correct time synchronization mechanism must be present between all the
nodes in the network. Network Time Protocol (NTP) can be used for this purpose. NTP is a protocol

Confidential
designed to synchronize the clocks of computers of a network. NTP has a client/server relationship
in which time-stamping is achieved for one or more servers to a number of clients configured for
NTP. Optimally, one or more dedicated NTP servers with a stratum 1 clock source would be
deployed for this however it is not a stringent requirement.
Configuration template:
configure system time ntp server <ntp-server-address> version 3 prefer

configure system time ntp no shutdown
10.1.5.2 Time zone
Setting a time zone in 7750 SR OS allows for times to be displayed in the local time rather than in
UTC. The 7750 SR OS has both user-defined and system defined time zones.
A user-defined time zone has a user assigned name of up to four printable ASCII characters in
length and unique from the system-defined time zones. For user-defined time zones, the offset
from UTC (GMT) is configured as well as any summer time adjustment for the time zone.
configure system time zone <non-std-zone-name> [<hh[:mm]>]
Where:
non-std-zone-name is 5 chars max (e.g. PKT), and <hh [:mm]> is the offsite from UTC (e.g. +5)
configure system time zone KSA 3
10.2 Security Management

10.2.1 User Security and Access Control
Local authentication is enabled by default and uses user names and passwords to authenticate
login attempts. The user names and passwords are local to each router. Local authorization uses
user profiles and user access information after a user is authenticated.
The profiles and user access information specifies the actions the user can and cannot perform.
Local authorization is enabled by default and uses user profiles and user access information after
a user is authenticated. The profiles and user access information specifies the actions the user can
and cannot perform.
a. User Profiles
Profiles are used to deny or permit access to a hierarchical branch or specific commands. Profiles
are referenced in a user configuration. A maximum of sixteen user profiles can be defined. A user
can participate in up to eight profiles. Depending on the authorization requirements, passwords
are configured locally or on a RADIUS server.
Two user profiles are created by default. The “administrative” profile permits full administrative
access to the whole configuration and management command tree, including security. The
“default”
profile permits access to show commands (except showing configuration and security parameters)
and denies access to all configuration commands.

Confidential
/configure
system
security
profile "default"
default-action none
no li
entry 10
no description
match "exec"
action permit
exit
entry 20
no description
match "exit"
action permit
exit
entry 30
no description
match "help"
action permit
exit
entry 40
no description
match "logout"
action permit
exit
entry 50
no description
match "password"
action permit
exit
entry 60
no description
match "show config"
action deny
exit
entry 65
no description
match "show li"
action deny
exit
entry 70
no description
match "show"
action permit
exit
entry 80
no description
match "enable-admin"
action permit
exit
entry 100
no description
match "configure li"
action deny
exit
exit
profile "administrative"
default-action permit-all
no li
entry 10
no description
match "configure system security"
action permit
exit
entry 20
no description
match "show system security"

Confidential
action permit
exit
entry 30
no description
match "tools perform security"
action permit
exit
entry 100
no description
action deny
exit
entry 110
no description
match "show li"
action deny
exit
exit
If required, multiple user profiles can be created with different privileges and assigned to users
based on their roles and tasks. Below are few examples of user profiles that may be required:
• Power Users Profile
A profile that permits access to the whole configuration and management command tree except
security management, BOF/file-system management, and specific admin commands (like admin
reboot or admin redundancy force-switchover) but still permits access to safe admin commands
(like admin save or admin display-config).
• Service Provisioning Profile
A profile that provides full access to service configuration and verification commands but does not
provide access to card configuration, base routing protocols configuration, security configuration,
or
system administration commands.
• First-level Operations Profile
A profile that requires only access to show and simple troubleshooting commands (like ping,
traceroute, etc) but does not require access to any configuration commands.
The definitions of the profiles and their privileges depend on ZAIN requirements and organizational
divisions that require access to the 7750SRs. The profile mentioned above are just examples that
demonstrate the capability of using user profiles for access control.
Below is a configuration example of the three profiles mentioned above:
/configure
system
security
profile "power-users"
entry 10
match "admin reboot"
action deny
exit
entry 20
match "admin redundancy force-switchover"
action deny
exit
entry 30
match "bof"
action deny
exit
entry 40
match "file"
action deny
exit
entry 100

Confidential
action deny
exit
entry 110
match "show li"
action deny
exit
exit
exit all
/configure
system
security
profile "service-provisioning"
entry 10
match "admin"
action deny
exit
entry 20
match "bof"
action deny
exit
entry 30
match "file"
action deny
exit
entry 40
match "configure card"
action deny
exit
entry 50
match "configure router"
action deny
exit
entry 60
match "configure system"
action deny
exit
entry 100
action deny
exit
entry 110
match "show li"
action deny
exit
exit
exit all
/configure
system
security
profile "power-users"
entry 10
match "admin reboot"
action deny
exit
entry 20
match "admin redundancy force-switchover"
action deny

Confidential
exit
entry 30
match "bof"
action deny
exit
entry 40
match "file"
action deny
exit
entry 100
action deny
exit
entry 110
match "show li"
action deny
exit
exit
exit all
entry 110
/configure
system
security
profile "first-level-operations"
entry 10
match "exec"
action permit
exit
entry 20
match "exit"
action permit
exit
entry 30
match "help"
action permit
exit
entry 40
match "logout"
action permit
exit
entry 50
match "password"
action permit
exit
entry 60
match "show config"
action deny
exit
entry 65
match "show li"
action deny
exit
entry 70
match "show"
action permit
exit
entry 80
match "enable-admin"
action permit
exit
entry 100
action deny

Confidential
exit
entry 110
match "ping"
action permit
exit
entry 120
match "traceroute"
action permit
exit
exit
exit all
Alternatively, the “first-level-operations” profile can be created simply by copying the “default”
profile then adding the entries that permit ping and traceroute commands (entries 110 and 120 in
the example) as follows:
/configure system security copy profile default to first-level-operations

/configure system security profile first-level-operations entry 110 match “ping”
/configure system security profile first-level-operations entry 110 action permit
/configure system security profile first-level-operations entry 120 match “traceroute”
/configure system security profile first-level-operations entry 120 action permit
b. Users
User configuration defines access parameters for individual users. It defines the login name for
the user and associates the user to one or more (up to eight) user profiles. It also defines access
control parameters specific for the user.
The following are guidelines for user configuration:
• Each operator should use his/her own user credentials and not share it with other
operators.
• Each user can be granted CLI, FTP and/or SNMP access individually (CLI access methods
Includes console, Telnet and SSH). Users should be granted only the type of access they
require.
• Users should be associated with the profiles that permits them to perform only the task
they
are eligible to do.
• Care must be taken when granting access privileges and associating profiles to users. For
example a user who is associated with a profile that denies CLI access to the file-system
(file command) can gain un-authorized access to the file system via FTP if FTP access is
enabled in his/her user account.
• When configured, a user is assigned a temporary password that he/she must change once
logged-in for the first time.
• When users are granted file-system access (either via CLI or FTP), each user should be
restricted to his/her working home directory.
Below is an example for user “user2” configuration. The user is granted CLI and FTP access and is
permitted and denied commands as defined in the “service-provisioning” profile. “user2” is
restricted to his/her home directory “cf3:\user2” ( in this case when he/she connects to the
7750SR only via FTP since he/she is not permitted to use the file command from CLI)
/configure
system
security
user "user2"
password user2123
access console ftp
home-directory "cf3:\user2"
restricted-to-home
console

Confidential
new-password-at-login
no member "default"
member "service-provisioning"
exit
exit
exit all
10.2.2 Password Management
Password management parameters include the definition of password aging, the authentication
order and authentication methods, password length and complexity, as well as the number of
attempts a user can enter a wrong password before being locked out.
The following are options and guidelines for password management configuration:
• Password complexity requirements can be set to enforce users to use strong passwords.
Password complexity requirements can enforce the use of one or more of the following:
▪ Mixed case: that at least one upper and one lower case character must be present
in the password.
▪ Numeric: that at least one numeric character must be present in the password.
▪ Special character: that at least one special character must be present in the
password. Special characters include: ~!@#$%^&*()_+|{}:”<>?`-=\[];’,./.
• Minimum password length can be enforced.
• Password aging (expiry) can be set to a specific number of days.
• A threshold for unsuccessful login attempts allowed in a specified time frame can be set. If
the threshold is exceeded, the user is locked out for a configurable duration.
Below is an example for a strict password management policy where the password must include
mixed-case, numeric and special characters. The password must be at least 8 characters long and
will expire after 90 days. The user will be locked out for 15 minutes after 3 un-successful login
attempts within 5 minutes.
/configure
system
security
password
aging 90
minimum-length 8
attempts 3 time 5 lockout 15
complexity numeric mixed-case special-character
exit
exit all
10.2.3 SSH / FTP
10.2.3.1 Secure Shell (SSH)
The 7750 SR OS supports both SSH1 and SSH2. The 7750SR OS has a global SSH server process to
Support inbound SSH and SCP sessions initiated by external SSH or SCP client applications.
When SSH server is enabled, an SSH security key is generated. The key is only valid until either the

Confidential
node is restarted or the SSH server is stopped and restarted. After the SSH server is restarted
(after reboot or server stop and start), the client will need to accept the new host key sent by the
server and may need to delete the old host key from its known-host-keys database.
The 7750SR OS has the capability of preserving the SSH security keys across system reboots or
SSH Server restarts.
When the global SSH server process is disabled, no inbound SSH or SCP sessions will be accepted.
The global SSH server in the 7750SR OS is enabled by default and will accept connections from
Clients supporting SSH version 2 only. SSH security keys are not preserved by default between
system reboots and SSH server restarts.
Below is the default SSH configuration on the 7750SRs:
/configure system security ssh

no preserve-key # SSH keys are not preserved
no version # default is SSH2
no server-shutdown # SSH server is enabled by default
To enable SSH key preservation and to allow the SSH server to accept connections from clients
supporting either SSH1 or SSH2:
/configure system security ssh preserve-key

/configure system security ssh version 1-2
A user that requires CLI access to the 7750SR using SSH must have the keywords “access console”
under his/her local user account).
/configure
system security
user <user-name>
access console
console
member "administrative"
exit
10.2.3.2 File Transfer Protocol (FTP)
The 7750SR OS runs an FTP server that accepts inbound FTP connections from clients. The FTP
server is disabled by default.
To enable the FTP server on the 7750SR:
configure system security ftp-server
A user that requires access to the 7750SR using FTP must have the keywords “access ftp” under
his/her local user account. The default home directory for all users accessing the 7750SR using
FTP is the root directory of CF3 of the active SF/CPM, unless specified under the user account
configuration
configure system security user <user-name> access ftp
10.2.3.3 Login Control
Login control includes the ability to control the maximum number of inbound SSH/Telnet sessions,

Confidential
Configure a pre-login message.
The following are options and guidelines for login configuration:
• A maximum of 15 inbound Telnet and SSH connections can be established to the router. By
default only 5 inbound sessions are enabled.
• A pre-login message can be configured to be displayed prior to console, Telnet or SSH
login. The pre-login message string can be up to 900 characters.
The 7750SR refers to a login banner as the pre-login message. To apply a pre-login message,
The following command will be used (note that “\n” is the code for a new line).
Below is an example for login control configuration that increases the allowed inbound sessions to
15 and creates a pre-login message:
configure system login-control

telnet
inbound-max-sessions 15
exit
login-control# pre-login-message ""************************* WARNING
*************************\nAuthorised access only.\nDisconnect IMMEDIATELY if you
are not an authorised user!\n\n(individuals using this system without authority,\n
are subject to having all of their activities\n monitored and recorded by system
personnel)***********************************************************"************
***********************************************"
10.2.4 Event Logging
Event logging controls the generation, dissemination and recording of system events for
monitoring status and troubleshooting faults within the system. The 7750 SR groups events into
four major categories or event sources:
• Security — The security event source is all events that affect attempts to breach system
security such as failed login attempts, attempts to access MIB tables to which the user is
not granted access or attempts to enter a branch of the CLI to which access has not been
granted. Security events are generated by the SECURITY application.
• Change — The change activity event source is all events that directly affect the
configuration or operation of the node. Change events are generated by the USER
application.
• Debug — The debug event source is the debugging configuration that has been enabled
on
The system. Debug events are generated by the DEBUG application.
• Main — The main event source receives events from all other applications within the 7750
SR.
Events within the 7750 SR OS have the following characteristics:

• A time stamp in UTC or local time.
• The generating application.
• A unique event ID within the application.
• The VRF-ID.
• A subject identifying the affected object.
• A short text description.
Event control assigns the severity for each application event and whether the event should be
generated or suppressed. Severity levels are:
1. cleared
Confidential
2. indeterminate (info)
3. critical
4. major
5. minor
6. warning
One of the following log destinations can be associated with an event log:
• Console
The log message is sent to the system console
• Session
The log messages are temporarily directed to all active Telnet and SSH sessions for the duration of
the session.
• Memory Logs
An event log can send entries to a memory log destination. A memory log is a circular buffer. When
the log is full, the oldest entry in the log is replaced with the new entry. When a memory log is
created, the specific number of entries it can hold can be specified, otherwise it will assume a
default size.
• Log Files
Log entries can be directed to log files stored on the Compact Flash devices in the SF/CPMs.
• SNMP Trap Group
An event log can be configured to send events to SNMP trap receivers by specifying an SNMP trap
group destination. An SNMP trap group can have multiple trap targets. Each trap target can have
different operational parameters.
A trap destination has the following properties:
▪ The IP address of the trap receiver.
▪ The UDP port used to send the SNMP trap.
▪ SNMP version (v1, v2c, or v3) used to format the SNMP notification.
▪ SNMP community name for SNMPv1 and SNMPv2c receivers.
▪ Security name and level for SNMPv3 trap receivers.
• Syslog
An event log can be configured to send events to a syslog destination. Each Syslog destination has
the following properties:
▪ Syslog server IP address.
▪ The UDP port used to send the syslog message.
▪ The Syslog Facility Code (0 - 23) (default 23 - local 7).
▪ The Syslog Severity Threshold (0 - 7) - events exceeding the configured level will
be sent.
10.2.4.1 Default System Logs
Log 99 is a pre-configured memory-based log which logs events from the main event source
(notsecurity, debug, etc.). Log 99 exists by default. Log 99 is limited to 500 entries only.
The following example displays the log 99 configuration:
configure log
log-id 99
description "Default System Log"
no filter
time-format utc
from main

Confidential
to memory 500
no shutdown
exit
---<snip>---
Use the following CLI command to display the entries of log 99:
/show log log-id 99
Log 100 is a pre-configured memory-based log which logs events from the main event source (not
security, debug, etc.). In log 100, only events with severity level of major an above are logged. Log
100 exists by default. Log 100 is limited to 500 entries only.
The following example displays the log 100 configuration:
configure log
---<snip>---
filter 1001
default-action drop
description "Collect events for Serious Errors Log"
entry 10
action forward
description "Collect only events of major severity or higher"
match
no application
no number
severity gte major
no router
no subject
exit
exit
exit
---<snip>---
log-id 100
description "Default Serious Errors Log"
filter 1001
time-format utc
from main
to memory 500
no shutdown
exit
---<snip>--
Use the following CLI command to display the entries of log 100:
/show log log-id 100
10.2.4.2 SYSLOG
Events from Main, Security, and Change sources can be sent to a syslog server. The Syslog
destination that needs to be defined has the following properties:
• Syslog server IP address.

• Syslog uses UDP port 514.
• The default Syslog Facility Code (23 – local 7) is used.
• Events of severity level info and above are sent to the syslog destination.

Confidential
SYSLOG server defined:
Syslog IP address
Syslog 1 <syslog-ip-address>
Table 10: syslog server
Below is a configuration example for syslog:
/configure
log
syslog 1
description "Syslog 1"
address 172.31.10.19
no facility # default is local7
level info # default
no port # default is 514
exit
---<snip>---
log-id 1
description "Events Sent to Syslog"
no filter # default
time-format utc # default
from main security change
to syslog 1
no shutdown
exit
log-id 2
description "Events Sent to Syslog"
no filter # default
time-format utc # default
from main security change
to syslog 1
no shutdown
exit

Confidential

Zain-Bng HLD-LLD Draft Ph1v0.1

Uploaded by

Copyright:

Available Formats

Zain-Bng HLD-LLD Draft Ph1v0.1

Uploaded by

Document Information

Original Title

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

Zain-Bng HLD-LLD Draft Ph1v0.1

Uploaded by

Copyright:

Available Formats

What is Nokia's role in the telecommunications industry?

What is Nokia's role in the telecommunications industry?

What are the main components of the 7750 hardware?

What are the main components of the 7750 hardware?

BNG

High Level & Low Level

3. Solution overview ................................................................ 9

4. 7750 Hardware introduction ............................................. 11

5. Hardware configuration parameter................................... 18

6. Physical connectivity and data-link design ........................ 22

7. Network-side IP design ..................................................... 25

8. Enhanced Subscriber Management ................................... 33

9. BNG Migration Strategy .................................................... 62

10. Network management ...................................................... 66

Table 1: BNG session scaling .............................................................................................................. 10

Ed Date Name Modification

EL KIHEL Document creation - First version

Zain BNG deployment is planned in 4 phases as following:

This document is focusing on design requirements for Zain BNG in phase 1.

This design document is based on available information at time of writing.

© Nokia 2016. All rights reserved. BNG HLD/LLD 8 / 82

Figure 1: Network Architecture

Within this document we will use the following naming convention:

© Nokia 2016. All rights reserved. BNG HLD/LLD 9 / 82

Users per group interface -

© Nokia 2016. All rights reserved. BNG HLD/LLD 10 / 82

© Nokia 2016. All rights reserved. BNG HLD/LLD 11 / 82

1 Cable management system

2 Chassis slot numbers

6 MDA impedance panel

© Nokia 2016. All rights reserved. BNG HLD/LLD 12 / 82

Card description mda-type

© Nokia 2016. All rights reserved. BNG HLD/LLD 13 / 82

4.1.2.2 1-port 100GE CFP2 MDA-e

Figure 5: 1-port 100GE CFP2 MDA-e

Key Label Description

© Nokia 2016. All rights reserved. BNG HLD/LLD 14 / 82

Laser Disabled - Amber (solid): Laser disabled

4.1.2.3 10-port 10GE SFP+ MDA-e

Figure 6: 10-port 10GE SFP+ MDA-e

Key Label Description

© Nokia 2016. All rights reserved. BNG HLD/LLD 15 / 82

4.1.3 Chassis Layout

4.1.3.1 RIY-BNG Chassis Layout

Figure 7: RIY-BNG Chassis Layout

© Nokia 2016. All rights reserved. BNG HLD/LLD 16 / 82

Figure 8: JED-BNG Chassis Layout

4.1.3.3 DMM-BNG Chassis Layout

Figure 9: DMM-BNG Chassis Layout

© Nokia 2016. All rights reserved. BNG HLD/LLD 17 / 82

5.1 Chassis mode

/configure system chassis-mode d

5.2 Card configuration

configure card 1 card-type "iom4-e-b"

To show the status and information of the cards:

/show card [detail]

5.3 MDA configuration

© Nokia 2016. All rights reserved. BNG HLD/LLD 18 / 82

To show the status and information of the cards: