In the IT infrastructure, you have some documentary for management, planning as well as inventory for IT audit. these documents are usefull for handing over or taking over from this person to another person. and also keep monitoring well on your system day by day, and support upgrading your system in future as well.
So today I would like to introduce 03 index of document which you often have in our IT system, those are:
A. Network Design Document
B. Infrastructure Desing Document
C. Telecom Design Document
D. IT System Document (update later)
E. Database Admin Document (update later)
In my opinion, how to write the documentary for entire IT system, it is not easy for begginer and you don't know where is starting point. Today I want to share some my experience to how you write these documents at my company. I just want to show some tips which I spent a lot time to do it. I hope it is usefull for you.
First thing, you remember that all of these document information maybe you don't know them details and exactly, so you don't worry, at least you can immage that what it is, for example such as Telecom system or IP PBX system, you need to realiaze what ACD is, that is automatic call distribution system, and you understand that their operation is based on two tables, those are incomming call table and outgoing call table, and that's all.
Second thing, if you are good at technology, you manage and control your system well, but you don't know how to wirte a summary of document for your undercontrol system. I think that first job is you need to define one table of contents of that document. Maybe having a little difficulty for you to write it, so I shared it on the internet on my own blog, you can refer to these for index of these document. I hope you get a little information.
So next I want to mention to last thing, now you completed to design a layout of document. next step you need to input all information on it. It is not easy for you if you are begginer. I think we have 02 important points at here. First point, you need to use some utilized function in a document such as table, graph and charts, in my document I use a lot of tables to input all information. and second point that is when you write somethings, it will has two aspects those are logical and physical feature. For example as logical network diagram and physical network diagram.
Now I finish at here, I hope it useful for some person or begginer to write these document. you can handle your system well if you have a good document. thank you for your time to read it.
P/S: my english is not good. maybe have some misstakes when I write it.
A. Network Design Document
Table of Contents
CHAPTER 1. MANAGEMENT SUMMARY.
1.1 How this document is organized.
1.2 Conventions.
CHAPTER 2. NETWORK OVERVIEW FOR SUPPORT.
2.1 Primary Data Center network (PDC)
2.2 Disaster Data Center network (DRC)
2.3 Branches network (BO)
2.4 External connections (POS)
CHAPTER 3. LOGICAL NETWORK DESIGN.
3.1 Logical Network Module.
3.1.1 Core Module:
3.1.2 Access Module:
3.1.3... Infrastructure Module
3.1.4... Management Module
3.1.5 Internet Module
3.1.6 DMZ module
3.1.7 WAN Module
3.1.8 Voice Module
3.2 VLAN Topology.
3.3 IP Addressing Range.
3.3.1 End User IP Subnets
3.3.2 Voice IP Subnet
3.3.3 Server IP Subnet
3.3.4... Equipment IP Subnet
3.3.5... DMZ1 and DMZ2 IP Subnets
3.3.6... Meeting room IP Subnets
3.3.7... Management IP Subnets
3.3.8... Internet Access IP Subnets
3.3.9... Switch’s Management IP Subnets
3.4 DNS Name/Device Host Name.
3.5 EtherChannel:
3.6 Per-VLAN Spanning Tree (PVST)
3.7 Host Standby Routing Protocol
3.8 IP Routing.
3.8.1... Default Routing and Static Routing
3.8.2 RIP routing
3.8.3 OSPF routing
3.9 Generic Routing Encapsulation (GRE) Tunnel
3.10 IP SLAs Operations - Reliable Static Routing Backup Using Object Tracking.
3.11 Logical Network Diagram.
Chapter 4. Physical Network Design.
4.1 Cabling and Rack/Floor/Building Infrastructure.
4.2 Device Names and Locations:
4.3 Device Hardware Configuration:
4.3.1... Cisco Router VNPDC-IET2821R-1
4.3.2... Cisco Router VNHQ-IAT3845R-1
4.3.3... Cisco Switch VNHQ-CD4506-1A
4.3.4... Cisco Switch VNHQ-CD4506-2B
4.3.5... Cisco Switch VNHQ-DMZ1-2960-1
4.3.6... Cisco Switch VNHQ-DMZ2-2960-1
4.3.7... Cisco Blade Switch VNHQ-BSA3020-0
4.3.8... Cisco Blade Switch VNHQ-BSA3020-1
4.3.9... Cisco Blade Switch VNHQ-BSA3020-2
4.3.10. Cisco Blade Switch VNHQ-BSA3020-3
4.3.11. Cisco Blade Switch VNHQ-BSA3020-4
4.3.12. Cisco Blade Switch VNHQ-BSA3020-5
4.3.13. Cisco VNHQ-UA3560-01F2
4.3.14. Cisco VNHQ-UA3560-01F3
4.3.15. Cisco VNHQ-UA3560-01F4
4.3.16. Cisco VNHQ-UA3560-01F8
4.3.17. Cisco VNHQ-UA3560-01M
4.3.18. Cisco VNHQ-UA2950-01Meeting
4.3.19. Cisco VNHQ-UA2960-CamAccDoor
4.3.20. Cisco VNHQ-UA3560-02F2 64
4.3.21. Cisco VNHQ-UA3560-02F3 65
4.3.22. Cisco VNHQ-UA3560-02F4 65
4.3.23. Cisco VNHQ-UA2960-02F8 65
4.3.24. Cisco VNHQ-UA2960-02M 65
4.3.25. Cisco Router VNEASY-IET2801R-1
4.3.26. Cisco Router VNHQ-IAT3845R-1
4.3.27. VNDRC-CD3750-1C
4.4 Device Port Connections.
4.4.1... Cisco Router VNPDC-IET2821R-1
4.4.2... Cisco Router VNHQ-IAT3845R-1
4.4.3... Cisco Switch VNHQ-CD4506-1A
4.4.4... Cisco Switch VNHQ-CD4506-2B
4.4.5... Cisco Switch VNHQ-DMZ1-2960-1
4.4.6... Cisco Switch VNHQ-DMZ2-2960-1
4.4.7... Cisco Blade Switch VNHQ-BSA3020-0 72
4.4.8... Cisco Blade Switch VNHQ-BSA3020-1 72
4.4.9... Cisco Blade Switch VNHQ-BSA3020-2 73
4.4.10. Cisco Blade Switch VNHQ-BSA3020-3 73
4.4.11. Cisco Blade Switch VNHQ-BSA3020-4 74
4.4.12. Cisco Blade Switch VNHQ-BSA3020-5 74
4.4.13. Cisco VNHQ-UA3560-01F2 74
4.4.14. Cisco VNHQ-UA3560-02F2 74
4.4.15. Cisco VNHQ-UA3560-01F3 75
4.4.16. Cisco VNHQ-UA3560-02F3 75
4.4.17. Cisco VNHQ-UA3560-01F4 75
4.4.18. Cisco VNHQ-UA3560-02F4 75
4.4.19. Cisco VNHQ-UA3560-01F8 75
4.4.20. Cisco VNHQ-UA2960-02F8 75
4.4.21. Cisco VNHQ-UA3560-01M 76
4.4.22. Cisco VNHQ-UA2960-02M 76
4.4.23. Cisco VNHQ-UA2950-01Meeting 76
4.4.24. Cisco VNHQ-UA2960-01CamAcc 76
4.4.25. Cisco Router VNEASY-IET2801R-1 76
4.4.26. Cisco Router VNEASY-IAT3845R-1 77
4.4.27. Cisco VNDRC-CD3750-1C 77
4.4.28. Cisco VNEASY-CD3750-2 78
4.4.29. Cisco VNEASY-ASA5505-1 78
4.4.30. Cisco Router VNHN-2821R-1 78
4.4.31. Cisco Router VNHN-IAT878R-1 79
4.4.32. Cisco VNHN-PIX506-1 79
Chapter 5. Network Device Configuration Parameters. 80
5.1 Common Configuration Settings. 80
5.1.1 Cisco IOS Switches 80
5.1.2 Cisco IOS Router 82
5.2 Individual Configuration Settings. 83
5.2.1... Cisco Catalyst VNHQ-CD45061-1A 83
5.2.2... Cisco Catalyst VNHQ-CD45061-2B 103
5.2.3... Cisco Catalyst VNDRC-CD3750-1C 125
Chapter 6. CheckPoint UTM-1 Firewall Device Configuration Parameters. 126
6.1 VPN/Firewall Topology Diagram.. 126
6.1.1 Overview Diagram 126
6.2 Checkpoint Firewall configuration. 130
6.2.1... Configuration parameters 130
6.2.2 NAT configuration 141
6.2.3... Routing configuration 143
Chapter 7. VPN Site-to-Site over Internet Configuration Parameters. 145
7.1 VPN/Firewall Topology Diagram.. 145
7.1.1 Overview Diagram: 145
7.1.2... Network Connections: 145
7.2 Configuration Parameters on VPN Cisco/CheckPoint Devices. 145
7.2.1... Cisco ASA Firewall configuration (VNEASY-ASA5505-1) 145
7.2.2... Cisco PIX Firewall configuration (VNHN-PIX506-1) 147
7.2.3... Checkpoint UTM-1 Firewall configuration 148
Chapter 8. Network Management. 149
8.1 Network Management System.. 149
8.1.1 NagVis: 149
8.1.2 Cacti: 149
8.2 IP Connectivity Table. 150
8.3 IP Address Parameters. 151
B. Infrastructure Desing Document
Table of Contents
Chapter 1. Management Summary. 4
1.1 How this document is organized. 4
1.2 Conventions. 4
Chapter 2. HC Viet Nam Data Center Infastructure Overview for Support. 5
2.1 Storage Area Network Overview.. 5
2.1.1 SAN Infastructure Overview. 5
2.1.2 Primary SAN network (PDC) 6
2.1.3 Disaster SAN network (DRC) 8
2.2 Data Center Room Overview.. 8
2.2.1 InfraStruXure Data Center Solution. 8
2.2.2 VESDA Xtralis Early Warning Safety and Security Solution. 10
Chapter 3. Logical Storage Area Network Architecture. 12
3.1 HP StorageWorks SAN Topology. 12
3.2 HP StorageWorks SAN Components at HC Viet Nam.. 14
3.2.1 SAN Switches. 14
3.2.2 Storage devices – HP EVA4400. 14
3.2.3 Blade System/Servers and HBAs. 15
3.2.4 Cabling and cable connectors. 15
3.2.5 SAN management applications. 15
3.3 IP Addressing Range. 16
3.4 DNS Name/Device Host Name. 16
3.4.1 SAN Switch Devices: 16
3.4.2 SAN Storage Server: 16
3.4.3 HP BladeSystem C7000 Enclosures. 16
3.4.4 Other HP Servers. 17
3.4.5 Virtual Servers on VMWare. 17
3.4.6 HP Tape Drivers. 19
3.5 HP StorageWorks Replication Solution. 19
3.6 SAN Diagram.. 20
Chapter 4. Physical Storage Area Network Architecture. 21
4.1 Cabling and Rack/Floor/Building Infrastructure. 21
4.2 Device Names and Locations. 22
4.3 Device Hardware Configuration. 22
4.3.1 HP BladeSystem C7000 BackOffice. 22
4.3.2 HP BladeSystem C7000 Homer 23
4.3.3 EVA4400 BackOffice ID1. 24
4.3.4 HP EVA4400 DRC ID3. 26
4.3.5 HP EVA 4400 HOMER ID2. 28
4.3.6 HP MSA P2000 G3. 28
4.3.7 HP StorageWork 4/32B Full SAN Switch - fscw22 (PDC) 29
4.3.8 HP StorageWork 4/32B Full SAN Switch - fscw23 (PDC) 29
4.3.9 HP StorageWork 4/32B Full SAN Switch - SW8 (DRC) 30
4.3.10 HP StorageWork 4/32B Full SAN Switch - SW9 (DRC) 30
4.3.11 HP Brocade 4Gb SAN Switch - SW20 (BlaceSystem C7000 BO) 31
4.3.12 HP Brocade 4Gb SAN Switch - SW21 (BlaceSystem C7000 BO) 31
4.4 Device Port Connections. 32
4.4.1 HP BladeSystem C7000 Enclosure BackOffice. 32
4.4.2 HP BladeSystem C7000 Enclosure HOMER. 35
4.4.3 EVA 4400 BackOffice ID1. 35
4.4.4 EVA 4400 DRC ID3. 36
4.4.5 EVA 4400 Homer ID2. 36
4.4.6 HP MSA P2000 G3. 36
4.4.7 HP SAN Switch fscw22 – PDC. 37
4.4.8 HP SAN Switch fscw23 – PDC. 37
4.4.9 HP SAN Switch sw8 – DRC. 37
4.4.10 HP SAN Switch sw9 – DRC. 37
Chapter 5. Storage Area Network Device Configuration Parameters. 38
5.1 SAN Switch Configuration Parameters. 38
5.1.1 HP StoreWorks 4/32B Full SAN Switch configuration (fscw23 – PDC) 38
5.1.2 HP StorageWorks 4/32B Full SAN Switch configuration (fscw22 – PDC) 42
5.1.3 HP StorageWorks 4/32B Full SAN Switch configuration – SW8 (DRC) 46
5.1.4 HP StorageWorks 4/32B Full SAN Switch configuration - SW9 (DRC) 46
5.1.5 HP Brocade 4G SAN Switch configuration - SW20 (BladeSystem C7000 BO) 47
5.1.6 HP Brocade 4G SAN Switch configuration - SW21 (BladeSystem C7000 BO) 48
5.1.7 HP 4GB VC-FC Switch 01 configuration on HOMER Blade Enclosure. 48
5.1.8 HP 4GB VC-FC Switch 02 configuration on HOMER Blade Enclosure. 48
5.2 HP Virtual Connect Ethernet on BackOffice Blade Enclosure. 48
5.2.1 Port Mapping – Interconnect Bay 1 (Cisco Catalyst Blade Switch 3020) 48
5.2.2 Port Mapping – Interconnect Bay 2 (Cisco Catalyst Blade Switch 3020) 49
5.2.3 Port Mapping – Interconnect Bay 5 (Cisco Catalyst Blade Switch 3020) 50
5.2.4 Port Mapping – Interconnect Bay 6 (Cisco Catalyst Blade Switch 3020) 50
5.2.5 Port Mapping – Interconnect Bay 7 (Cisco Catalyst Blade Switch 3020) 50
5.2.6 Port Mapping – Interconnect Bay 8 (Cisco Catalyst Blade Switch 3020) 51
5.3 HP Virtual Connect Ethernet on HOMER Blade Enclosure. 51
5.3.1 Port Mapping – Interconnect Bay 1 (HP 1/10GB VC-Enet Module) 51
5.3.2 Port Mapping – Interconnect Bay 2 (HP 1/10GB VC-Enet Module) 52
5.4 Storage Server Configuration Parameters. 52
5.4.1 EVA 4400 BackOffice ID1. 52
5.4.2 EVA 4400 DRC ID3. 65
5.4.3 EVA 4400 HOMER ID2. 75
5.4.4 MSA P2000 G3. 76
5.5 HP Servers. 78
5.5.1 VNHQESX01 on Enclosure BackOffice (Bay 1) 78
5.5.2 VNHQESX02 on Enclosure BackOffice (Bay 2) 79
5.5.3 VNHQMAS03 on Enclosure BackOffice (Bay 6) 80
5.5.4 VHPVM01 on Enclosure BackOffice (Bay 8) 80
5.5.5 VNHQPWS02 on Enclosure BackOffice (Bay 9) 81
5.5.6 VNHQPAP02 on Enclosure BackOffice (Bay 10) 82
5.5.7 VNHQESX03 on Enclosure BackOffice (Bay 11) 82
5.5.8 VNHQESX04 on Enclosure BackOffice (Bay 12) 83
5.5.9 VNHQMAS01 on Enclosure BackOffice (Bay 13) 84
5.5.10 VNHQESX05 on Enclosure BackOffice (Bay 14) 85
5.5.11 VNHQESX06 at DRC. 85
5.5.12 VNHQESX07 at DRC. 86
5.6 MSL4048 Tape Library. 87
Chapter 6. Storage Area Network Management. 90
6.1 Storage Area Management 90
6.2 ILO IP Address Table. 90
6.3 IP Address Parameters. 90
Chapter 7. Data Center Solution at HC Viet Nam.. 91
7.1 InfraStruXure Data Center Solution. 91
7.1.1 APC Rack System – NetShelter SX Enclosure. 91
7.1.2 Power System.. 94
7.1.3 NetBotz security and environmental monitoring. 107
7.1.4 Cooling System.. 114
7.1.5 Management and Service. 119
7.2 VESDA Xtralis Early Warning Safety and Security Solution. 120
7.2.1 VESDA System.. 120
7.2.2 FM200 Fire Protection System
C. Telecom Design Document
Table of content
Chapter 1. Management summary. 6
1.1 How this document is organized. 6
1.2 Conventions. 6
Chapter 2. Telecom System Overview.. 7
2.1 Telecom System Diagram.. 7
2.2 Aastra MX-ONE IP-PBX Overview. 8
2.3 Solidus eCare Overview. 11
2.4 RedBOX - Recording System.. 18
2.5 2N StarGate GSM Gateway. 20
2.6 SMS System.. 23
2.7 Incoming Call and Outgoing Call Routing. 24
Chapter 3. Logical Telecom System Network. 25
3.1 Topology. 25
3.2 IP Subnets. 25
3.3 IP Addressing. 25
3.4 Logical Overview Diagram.. 26
Chapter 4. Physical Telecom System Architecture. 27
4.1 Cabling and Rack/Floor/Building Infrastructure. 27
4.2 Device/Card Names and Locations. 28
4.3 Device/Card/Board Hardware Configuration. 28
4.3.1 Aastra MX-ONE PBX. 28
4.3.2 Ericsson BP250-Beta. 29
4.3.3 Ericsson BP250-HaNoi 29
4.3.4 MX-ONE Telephony server (TSE) 30
4.3.5 VNHQCCS01 server 30
4.3.6 VNHQIT66 server 30
4.3.7 VNHQRBR01 server 31
4.3.8 VNHQSQL01 server 31
4.4 Device/Card/Board Port Connections. 31
4.4.1 MX- ONE Media Gateway. 31
4.4.2 MX-ONE Telephony server (TSE) 32
4.4.3 VNHQCCS01 server 32
4.4.4 VNHQIT66 server 33
4.4.5 VNHQRBR01 server 33
4.4.6 VNHQSQL01 server 33
4.4.7 Ericsson BP250-Beta. 33
4.4.8 Ericsson BP250-HaNoi 33
Chapter 5. Site Information. 35
5.1 Site Address Information. 35
5.2 Site Characteristics. 36
5.3 Links to PSTN/PBX. 36
Chapter 6. Telephony Aastra MX-ONE IP-PBX Configuration Parameters. 40
6.1 Links to PSTN/PBX. 40
6.2 Numbering Plan, Dial Plan. 40
6.3 Phone and Customer 43
6.3.1 Phone Button Templates. 43
6.3.2 Common Service Profiles. 43
6.3.3 Extension Directory. 43
6.3.4 Directory Number Profile. 49
6.3.5 Key System Directory Data. 50
6.3.6 Key System Category Print 52
6.3.7 IP Extension Data. 54
6.3.8 Extension Category Fields. 59
6.3.9 Extension Directory Data. 59
6.3.10 Call List Information. 59
6.4 List Routes and Trunks. 60
6.4.1 List Routes. 60
6.4.2 List Trunks. 60
6.4.3 Number Conversion Data. 61
6.4.4 External Destination Route Data. 61
6.4.5 Route Category Data. 62
6.4.6 Route Day and Night Number Data. 63
6.5 Least Cost Routing – LCR. 63
6.6 Pickup Group. 63
6.7 Hunt Group. 64
6.8 ACD parameters. 64
6.9 Common Category. 65
6.10 Operator Group configuration. 65
6.11 MX-ONE PBX’s License information. 65
6.12 H323 Gateway. 67
6.13 GSM Gateway configuration. 67
6.13.1 System Parameters. 67
6.13.2 ISDN Parameters. 68
6.13.3 GSM Basic Parameters. 68
6.13.4 GSM Group Assignment 68
6.13.5 GSM Outgoing Groups. 70
6.13.6 GSM Incoming Groups. 71
6.13.7 Prefix List 71
6.13.8 Least Cost Routing Table. 72
Chapter 7. Solidus ECare Configuration Parameters. 73
7.1 Contact Center System Properties. 73
7.2 Skilled Users. 75
7.3 Service Access. 78
7.4 Service Groups. 82
7.5 Agent Groups. 91
7.6 Call Qualification Codes. 91
7.7 Play Messages. 92
7.8 Call Campaigns. 92
7.9 IVR – Interactive Voice Response. 93
Chapter 8. RedBox Configuration Parameters. 94
8.1 Network Settings. 94
8.2 Licensing the recorder 94
8.3 Configuring recording. 94
8.4 Configuring channel labels. 97
8.5 Groups. 97
8.6 Misc Settings. 98
8.7 Calls Store (Callstore) 98
8.8 Database Details. 98
Chapter 9. SMS System Configuration Parameters. 100
9.1 SMS Autosender Parameters. 100
9.2 SMS Template Files. 100
9.3 Monitor and Report 101
Chapter 10. Telecom System Management 102
10.1 Telecom System Management 102
10.2 IP Address/Connectivity Table. 102
10.3 Call Accounting System
Nowaday, a lot enterprises are implemeting a Data Center which it is centralized by all servvice , they are deploying a lot of services inside a Data Center, one of some services that is Call Center (Contact Center) using on technology of Voice over IP. In order to always make sure for voice traffic we need to apply QoS on whole enterprise's network, this article will mention this issue.
Quality of Service (QoS) is being deployed by most VoIP service providers today in order for such enterprises to efficiently use its bandwidth in an integrated network. These service providers expect their respective clients to implement QoS on their LAN in order to maximize the bandwidth resources at their disposal and ensure a flawless and high quality VoIP for its use. With the necessary equipment in the LAN, the network administrator with the required knowledge in QoS design and implementation can configure the various routers and switches to give priority to voice in the LAN.
This is focuses on the implementation of Quality of Service (QoS) in a LAN that extends over an IP/MPLS (WAN) network. QoS was configured on all the switches in a particular network in order for priority to be given to the Voice packets going through this network. The aim is to show that although QoS is not so important in a LAN within a Region, it becomes important when that LAN extends to other Regions over an IP/MPLS network.
Quality of Service (QoS) is the ability of a networking equipment to differentiate among different classes of traffic and to give each class different priority over the network when there is congestion in the network based on the traffic significance. QoS is not something that will be configured on a router or switch, rather it is a term that refers to a wide variety of mechanism used to influence traffic patterns on a network. It gives network administrators the ability to give some traffic more priority over others.
Models of QoS:
The purpose of QoS usage is to make sure that minimum bandwidth is guaranteed for identified traffic, jitter and latency is being controlled and packet loss is improved. This can be carried out using several means either QoS congestion management, congestion avoidance or policing and traffic shaping. The means chosen depends largely on the goal of the network administrator.
QoS can be divided into three different models:
- The Best Effort model. (a default mode)
- Integrated Services (IntServ)
- Differentiated Services (DiffServ)
A default model that comes with all networking devices is the Best Effort model. It does not require any QoS configuration.
DiffServ provides the need for simple and coarse methods of putting traffic into classes, called Class of Service (COS). It does not specify that a specific protocol should be used for providing QoS but specifies an architectural framework for carrying out its function. DiffServ carries out its major function through a small, well-defined set of building blocks from which different aggregates of behaviours can be built. The packet Type of Service (TOS) byte in the IP header is marked in order for the packets to be divided into different classes which forms the aggregate behaviours[5]. Differentiated Services Code Point (DSCP) is a 6-bit bit pattern in the IPv4 TOS Octet or the IPv6 traffic class Octet [5]. DSCP supports up to 64 aggregates or classes and all classification and QoS in the DiffServ model revolves around the DSCP.
QoS for Voice:
Voice packets have minimal needs for delay. Voice packets are delay sensitive and a little delay in the transmitting of voice packets can cause so much discomfort to a user.
In the case of VoIP, the major factors that will affect its quality are packet loss and packet delay.
Lost packets: Usually when data is being sent over an IP network some packets can be lost. Using TCP protocol, the lost packet can be resent but in the case of VoIP, it does use UDP. So any packet lost cannot be retransmitted.
Delay Packet (Latency): Packet delay is the time it takes a packet to reach the receiving end of an endpoint after it has been transmitted from the source. This is called end-to-end delay. It consists of two components: fixed network delay and variable delay. Packet delay can cause degradation of voice quality due to the end-to-end voice latency or packet loss if the delay is variable. The end-to-end voice latency must not be longer than 250ms because it will make the conversation sound like two parties talking on a CB radio. If latency must be taken care of, then we have to know the main causes of latency. They are: codecs, queuing, waiting for packets being transmitted, serialization, jitter buffer and others.
In spite of the fact that voice will be transferred via network, the network between data centres and contact centres must support following minimal requirements:
+ Packet loss less than 1%
+ Network latency less than 50 ms
+ Jitter less than 20 ms
In the case of VoIP, the major factors that will affect its quality are packet loss and packet delay.
Lost packets: Usually when data is being sent over an IP network some packets can be lost. Using TCP protocol, the lost packet can be resent but in the case of VoIP, it does use UDP. So any packet lost cannot be retransmitted.
Delay Packet (Latency): Packet delay is the time it takes a packet to reach the receiving end of an endpoint after it has been transmitted from the source. This is called end-to-end delay. It consists of two components: fixed network delay and variable delay. Packet delay can cause degradation of voice quality due to the end-to-end voice latency or packet loss if the delay is variable. The end-to-end voice latency must not be longer than 250ms because it will make the conversation sound like two parties talking on a CB radio. If latency must be taken care of, then we have to know the main causes of latency. They are: codecs, queuing, waiting for packets being transmitted, serialization, jitter buffer and others.
In spite of the fact that voice will be transferred via network, the network between data centres and contact centres must support following minimal requirements:
+ Packet loss less than 1%
+ Network latency less than 50 ms
+ Jitter less than 20 ms
QoS can be used to prevent a voice packet from waiting on other packets before it is transmitted. QoS makes the voice to be sent out of queues faster than other packets in the queue and by giving more bandwidth to voice, it helps to mitigate against serialization delay.
In essence, QoS for the voice packets reduces latency, uses bandwidth well and delivers voice packets fast. Using Low Latency Queuing (LLQ) or Priority Queuing-Weighted Fair Queuing (PQ-WFQ) commands to give priority to voice is the preferred method of configuring QoS.
QoS Implementation
QoS implementation, as was earlier mentioned, can be a simple or complex task depending on several factors like the QoS features offered by the networking devices, the traffic types and pattern in the network and level of control that need to be exercised over incoming and outgoing traffic. The network engineer cannot even be able to exercise so much control over the network traffic beyond the QoS features in the networking devices.
The DiffServ model allows network traffic to be broken down into small flows for appropriate marking. This small flow is called a class. Thus, the network recognises traffic as a class instead of the network receiving specific QoS request from an application. The devices along the path of the flow are able to recognise the flow because these flows are marked. So the marked flow is given appropriate treatment by the various devices on the network.
When the packet has been properly marked and identified by the router or switch, it is given special treatment called Per Hop Behaviour (PHB) by these devices. PHB identifies how the packets are treated at each hop. There are three standardized PHB currently in use:
a. Default PHB: This uses best-effort forwarding to forward packets
b. Expedited Forwarding (EF): It guarantees that each DiffServ node gives low-delay, low-jitter and low-loss to any packet marked with EF. It is used majorly for Real-time Transport Protocol (RTP) applications, like voice and video.
c. Assured Forwarding (AF): It gives lower level functions compared with EF. It is used mostly for mission-critical applications or any application that are not too sensitive to delay but want assurance that the packets will be delivered by the network.
There are several tools used in implementing QoS. These are some tools used in QoS implementation:
1. Congestion Management:
Queuing is meant to accommodate temporary congestion on an interface of a network device by storing the excess packets until there is enough bandwidth to forward the packets. Sometimes some packets are dropped when the queue depth is full. Congestion management allows the administrator to control congestion by determining how and when the queue depth is full. There are several ways this can be done. These are some ways congestion management can be implemented:
a. Priority Queuing (PQ): This allows the administrator to give priority to certain traffic while allowing other to be dropped when the queue depths are full.
b. Custom Queuing (CQ): This allows the administrator to reserve queue space in the router or switch buffer for all traffic types.
c. Weighted Fair Queuing (WFQ): This allows the sharing of bandwidth with prioritization given to some traffic.
d. Class-based Weighted Fair Queuing (CBWFQ): This extends the functionality of WFQ to provide support for user-defined classed.
e. Low Latency Queuing (LLQ): This is a combination of CBWFQ and PQ. It is able to give traffic that requires low-delay the required bandwidth it needs while also giving data the needed bandwidth. It solves the starvation problem associated with PQ.
a. Priority Queuing (PQ): This allows the administrator to give priority to certain traffic while allowing other to be dropped when the queue depths are full.
b. Custom Queuing (CQ): This allows the administrator to reserve queue space in the router or switch buffer for all traffic types.
c. Weighted Fair Queuing (WFQ): This allows the sharing of bandwidth with prioritization given to some traffic.
d. Class-based Weighted Fair Queuing (CBWFQ): This extends the functionality of WFQ to provide support for user-defined classed.
e. Low Latency Queuing (LLQ): This is a combination of CBWFQ and PQ. It is able to give traffic that requires low-delay the required bandwidth it needs while also giving data the needed bandwidth. It solves the starvation problem associated with PQ.
2. Traffic shaping and traffic Policing:
Traffic shaping and policing are mechanisms used to control the rate of traffic. The main difference between them depends on the terms of implementation. While traffic policing drops excess traffic or remarks the traffic in order to control traffic flow within a specific rate limit without introducing any delay to traffic, traffic shaping retains excess traffic in a queue and then schedules such traffic for later transmission over an increment of time.
Since the traffic in this particular network was divided into two classes: the voice and others by the network administrator, it is important that LLQ and traffic policing is used to implement the various configurations in the different switches. How then is QoS implemented in a network? It starts with preparation.
Preparing to Implement the QoS model:
a. Identifying types of traffic and their requirement. (the traffic required can be identified, the range of ports that are to be configured, to know the business importance of all traffic in a network)
b. Dividing traffics into classes. (The identified traffic is divided into two classes: Voice and Others. The Voice class is given low latency while Others will be configured with guaranteed delivery.)
c. Defining QoS policies for each class. (Defining the QoS policy involves one or more of the following activities: setting a minimum bandwidth guarantee, setting a maximum bandwidth limit, assigning a priority to each class and using QoS technology to manage congestion.)
QoS needs to be designed and implemented considering the entire network. This includes defining trust points, and determining which policies to enforce at each device within the network. Developing the trust model, guides policy implementations for each device.
While design principles are common, QoS implementation varies between fixed-configuration switches and the modular switching platforms
This section discusses the internal switching architecture and the differentiated QoS structure on a per-hop-basis.
The devices (routers, switches) within the internal network are managed by the system administrator, and hence are classified as trusted devices. Access-layer switches communicate with devices that are beyond the network boundary and within the internal network domain. QoS trust boundary at the access-layer communicates with various devices that could be deployed in different trust models (Trusted, Conditional-Trusted, or Un-Trusted). This section discusses the QoS policies for the traffic that traverses access-switch QoS trust boundary. The QoS function is unidirectional; it provides flexibility to set different QoS polices for traffic entering the network versus traffic that is exiting the network.
The access-switch provides the entry point to the network for end devices. The access-switch must decide whether to accept the QoS markings from each endpoint, or whether to change them. This is determined by the QoS policies, and the trust model with which the endpoint is deployed.
End devices are classified into one of three different trust models; each with it's own unique security and QoS policies to access the network:
• Untrusted—An unmanaged device that does not pass through the network security policies. For example, student-owned PC or network printer. Packets with 802.1p or DSCP marking set by untrusted endpoints are reset to default by the access-layer switch at the edge. Otherwise, it is possible for an unsecured user to take away network bandwidth that may impact network availability and security for other users.
• Trusted—Devices that passes through network access security policies and are managed by network administrator. For example, secure PC or IP endpoints (i.e., servers, cameras, DMP, wireless access points, VoIP/video conferencing gateways, etc). Even when these devices are network administrator maintained and secured, QoS policies must still be enforced to classify traffic and assign it to the appropriate queue to provide bandwidth assurance and proper treatment during network congestion.
• Conditionally-Trusted—A single physical connection with one trusted endpoint and a indirect untrusted endpoint must be deployed as conditionally-trusted model. The trusted endpoints are still managed by the network administrator, but it is possible that the untrusted user behind the endpoint may or may not be secure. For example, Cisco Unified IP Phone + PC. These deployment scenarios require hybrid QoS policy that intelligently distinguishes and applies different QoS policy to the trusted and untrusted endpoints that are connected to the same port.
Deploying Ingress QoS
The ingress QoS policy at the access-switches needs to be established, since this is the trust boundary, where traffic enters the network. The following ingress QoS techniques are applied to provide appropriate service treatment and prevent network congestion:
• Trust—After classifying the endpoint the trust settings must be explicitly set by a network administrator. By default, Catalyst switches set each port in untrusted mode when QoS is enabled.
• Classification—IETF standard has defined a set of application classes and provides recommended DSCP settings. This classification determines the priority the traffic will receive in the network. Using the IETF standard, simplifies the classification process and improves application and network performance.
• Policing—To prevent network congestion, the access-layer switch limits the amount of inbound traffic up to its maximum setting. Additional policing can be applied for known applications, to ensure the bandwidth of an egress queue is not completely consumed by one application.
• Marking—Based on trust model, classification, and policer settings the QoS marking is set at the edge before approved traffic enters through the access-layer switching fabric. Marking traffic with the appropriate DSCP value is important to ensure traffic is mapped to the appropriate internal queue, and treated with the appropriate priority.
• Queueing—To provide differentiated services internally in the Catalyst switching fabric, all approved traffic is queued into priority or non-priority ingress queue. Ingress queueing architecture assures real-time applications, like VoIP traffic, are given appropriate priority (eg transmitted before data traffic).
Deploying Egress QoS
The QoS implementation for egress traffic toward the network edge on access-layer switches is much simpler than the ingress traffic QoS. The egress QoS implementation provides optimal queueing policies for each class and sets the drop thresholds to prevent network congestion and application performance impact. Cisco Catalyst switches support four hardware queues which are assigned the following policies:
• Real-time queue (to support a RFC 3246 EF PHB service)
• Guaranteed bandwidth queue (to support RFC 2597 AF PHB services)
• Default queue (to support a RFC 2474 DF service)
• Bandwidth constrained queue (to support a RFC 3662 scavenger service)
As a best practice, each physical or logical link must diversify bandwidth assignment to map with hardware queues:
• Real-time queue should not exceed 33% of the link's bandwidth.
• Default queue should be at least 25% of the link's bandwidth.
• Bulk/scavenger queue should not exceed 5% of the link's bandwidth.
Given these minimum queuing requirements and bandwidth allocation recommendations, the following application classes can be mapped to the respective queues:
• Realtime Queue—Voice, broadcast video, and realtime interactive may be mapped to the realtime queue (per RFC 4594).
• Guaranteed Queue—Network/internetwork control, signaling, network management, multimedia conferencing, multimedia streaming, and transactional data can be mapped to the guaranteed bandwidth queue. Congestion avoidance mechanisms (i.e., selective dropping tools), such as WRED, can be enabled on this class. If configurable drop thresholds are supported on the platform, these may be enabled to provide intra-queue QoS to these application classes, in the respective order they are listed (such that control plane protocols receive the highest level of QoS within a given queue).
• Scavenger/Bulk Queue—Bulk data and scavenger traffic can be mapped to the bandwidth-constrained queue and congestion avoidance mechanisms can be enabled on this class. If configurable drop thresholds are supported on the platform, these may be enabled to provide inter-queue QoS to drop scavenger traffic ahead of bulk data.
• Default Queue—Best effort traffic can be mapped to the default queue; congestion avoidance mechanisms can be enabled on this class.
Deploying Network Core QoS
All connections between internal network devices that are deployed within the network domain boundary are classified as trusted devices and follow the same QoS best practices recommended in the previous section. Ingress and egress core QoS policies are simpler than those applied at the network edge,
--- update soon ---
Cisco IP SLAs is a part of Cisco IOS software that allows Cisco customers to analyze IP service levels for IP applications and services by using active traffic monitoring—the generation of traffic in a continuous, reliable, and predictable manner—for measuring network performance. With Cisco IOS IP SLAs, service provider customers can measure and provide service level agreements, and enterprise customers can verify service levels, verify outsourced service level agreements, and understand network performance.
Read More ...
Purpose
This article provide information about the monitoring system in a company, define guide lines, rules and standard framework for daily operating work. All IT systems and devices should follow this document for applying a common monitoring standard for IT environment.Scope
This article will provide information about:
- Opsview - the nagios-based monitoring system is currenlty implemented
in several company almost.
- The monitogin operating model of Opsview
- Standard framework for daily monitoring
- Alert/Notification handling guidelines
This document will be updated regularly based on new requirements and
also needs for optimizing the monitoring system.
Target audiences
This document is useful for IT Operation Team's member, including:- Helpdesk Team
- System and Database Team
- Network and Infrastructure Team
About Opsview (Nagios based monitoring system)
Nagios
Nagios® Core™ is an Open Source system and network monitoring
application. It watches hosts and services that you specify, alerting you when
things go bad and when they get better.
Nagios Core was originally designed to run under Linux, although it should work
under most other unices as well.
Some of the many features of Nagios Core include:
- Monitoring of network services (SMTP, POP3, HTTP, NNTP, PING, etc.)
- Monitoring of host resources (processor load, disk usage, etc.)
- Simple plugin design that allows users to easily develop their own service checks
- Parallelized service checks
- Ability to define network host hierarchy using "parent" hosts, allowing detection of and distinction between hosts that are down and those that are unreachable
- Contact notifications when service or host problems occur and get resolved (via email, pager, or user-defined method)
- Ability to define event handlers to be run during service or host events for proactive problem resolution
- Automatic log file rotation
- Support for implementing redundant monitoring hosts
- Optional web interface for viewing current network status, notification and problem history, log file, etc.
Opsview
Opsview is a enterprise-grade monitoring system for physical, virtual IT
infrastructure. Opsview sponsors a free, open-source
software version - Opsview Core. It sells Opsview Pro to SMBs and Opsview
Enterprise to larger organisations under a proprietary
license.
Opsview is built with the following technologies:
- Nagios Core: Provides the core set of monitoring and alerting capabilities in Opsview. Sometimes referred to as Opsview's monitoring engine.
- Perl: The primary programming language used for Opsview
- Catalyst: A MVC Web application framework used for building the web application
- ExtJS: a JavaScript library used for building the dashboard in Opsview Pro and Opsview Enterprise
- MySQL: A relational database used for configuration, runtime and data warehouse databases
- Net-SNMP: Provides SNMP support
- RRDtool: Provides lightweight graphing
Opsview runs on Linux with official
support for the following distributions: CentOS, Debian, Red Hat Enterprise
Linux, SUSE and Ubuntu. It
also runs on Solaris 10.
Currently, Opsview system in PPF VF using the opensource version 3.3.2.
It's a old version but the last one that keeps all the enterprise features that
we need. In later on version, Opsview removes some important features and add
them into the Professional and Enterprise version which need commercial license.
For better overview of Opsview in company, please read OpsviewMonitoring.
Opsview Manual
Please read OpsviewUserManual.Monitoring operating design
Monitoring servers contains a group of 2 Opsview hosts running on Nagios core version 3.3.2- Master monitoring server - located in LAN
- Slave monitoring sever - located in DMZ
Monitoring objects
We use many service checks to check status of system include hardware, software and services are running... The monitoring objects are listed below:| Server | - Load of CPU - Memory use (RAM, page file) - Raid Array Status - Drive utilisation on Windows or partition utilisation on Linux - Status of server |
| Switch /Router | - Status of interfaces - CPU load - Memory utilisation - Status of devices |
| Storage System | - Status of controller - Write latency - Read latency - I/O performance |
| UPS | - Temperature - Battery life time - Battery capacity - Output voltage, frequency... |
| Printer | - Status of printer |
| Security Camera | - Status of camera |
| Data Center | - Humidity - Temperature of RACKs |
| Line Internet | - Fiber, ADSL, Leased line, VTN, Tunnel... |
| Services | - Mail, Web, Proxy, Dns, Active Directory, Database... |
Production, UAT and Testing Environments
Production Environments
System priority table (by critical level)
Users of Monitoring system
Monitoring operators
Monitoring administrators
Business users/owners
Third parties/Suppliers
To monitor or not to monitor
SLA for Production Environment
SLA for Testing Environment
SLA for UAT Environment
Life cycle of a host, service and monitoring
Working hours and non-working hours
Escalation and contact points
Threshhold and notification settings
- For internal services
+ Disk space
+ ...
- For public services
- For hosts
+ Internal host
+ Public host
Email notifcation settings
SMS notification settings
Monitor a generic Windows machine \
Monitor a Windows Cluster
Monitor HP Dataprotector Cell Manager Server
Monitor a Windows-based Java Application Server
Monitor a MS SQL Server
Monitor a IIS Web Application Server
Monitor a Windows File Server
Monitor a Windows Domain Controller
Monitor a Microsoft Exchange Server
Monitor a Microsoft ISA Server
Monitor a Windows-based Symantec SEPM Server
Monitor a Microsoft Windows Update Server
Monitor a Linux/Unix machine Monitor DHCP/DNS Server
Monitor Internet DNS Server
Monitor Mail Gateway Server
Monitor Squid Proxy Server
Monitor Pound SSL Reversed Proxy Server
Monitor Varnish Reversed Proxy Server
Monitor Linux-based Java Application Server
Monitor Linux-based Web Server
Monitor Zimbra Server
Monitor Linux-based Oracle Database Server
Monitor a network printer
Monitor a router/switch
Monitor a leased-line connectivity
Monitor a internal service (Active Directory, OWA, HTTP, SSH, etc.)
Monitor Active Directory Service
Monitor Exchange Publishing Service (OWA, ActiveSync, Outlook Anywhere, Exchange Web Service)
Monitor a public service (HTTP, SMTP, DNS, etc)
Standard alert handling process SMS notification settings
Monitor a generic Windows machine \
Monitor a Windows Cluster
Monitor HP Dataprotector Cell Manager Server
Monitor a Windows-based Java Application Server
Monitor a MS SQL Server
Monitor a IIS Web Application Server
Monitor a Windows File Server
Monitor a Windows Domain Controller
Monitor a Microsoft Exchange Server
Monitor a Microsoft ISA Server
Monitor a Windows-based Symantec SEPM Server
Monitor a Microsoft Windows Update Server
Monitor a Linux/Unix machine Monitor DHCP/DNS Server
Monitor Internet DNS Server
Monitor Mail Gateway Server
Monitor Squid Proxy Server
Monitor Pound SSL Reversed Proxy Server
Monitor Varnish Reversed Proxy Server
Monitor Linux-based Java Application Server
Monitor Linux-based Web Server
Monitor Zimbra Server
Monitor Linux-based Oracle Database Server
Monitor a network printer
Monitor a router/switch
Monitor a leased-line connectivity
Monitor a internal service (Active Directory, OWA, HTTP, SSH, etc.)
Monitor Active Directory Service
Monitor Exchange Publishing Service (OWA, ActiveSync, Outlook Anywhere, Exchange Web Service)
Monitor a public service (HTTP, SMTP, DNS, etc)
Get to understand the dependencies between hosts and services
Services notification handling
Steps/questions need to be examed before starting of resolution
Steps/questions need to be examed after resolution deployed Volume related notification (disk space, database table space, RAM, swap, bandwidth, etc.)
Performance related notification (CPU utilization, Disk I/O, ping latency, service's reponse time, etc.)
Up/down or ok/error related notication (interface up/down, line
reachable, raid status, AD replication, windows service, linux service etc.).
Communication and health check only - with or withoud performance data
Line up/down handling
Public service of PPF up/down handling (HTTP, HTTPS)
Public service of ISP (not PPF) up/down handling (external DNS resolving,
ISP's outage)
Internal service up/down handling (HTTP, HTTPS)
Host up/down handling
Zone up/down handling
Data center up/down handling
Read More ...
Nowadays, more and more enterprises are
demanding for virtual private networks (VPNs) to connect their branches across the
public network.
In case your branches use a static IP addresses assigned by ISP (or branches of an enterprise usually use dynamically
assigned IP addresses), so you can still depoy this DVPN solution, it allow to bring a lot of benefits in environment DRC site and PDC site for creasing a intranet from them to braches. So that in this article I will only write about this solution in a enterprises architecture in environment DRC and PDC, your branches will connect to both DRC site and PDC site for redundance. When VPN communication at PDC is failed, banrches will switch to DRC.
DVPN collects, maintains, an distributes dynamic
public addresses through the VPN Address Management (VAM) protocol, making VPN establishment
available between enterprise branches that use dynamic addresses to access the
public network.
In DVPN, a collection of nodes connected to
the public network form a VPN. From the perspective of DVPN, the public network
is the link layer of the VPN, and the tunnels which are used as the virtual channels
between subnets of an intranet constitute the network layer. Branch devices
dynamically access the public network. DVPN can get the public IP addresses of
the peers through VAM to set up secure internal tunnels conveniently.
When a DVPN device forwards a packet from a
user subnet to another, it performs these operations:
1) Obtaining the next hop on the private network through a routing
protocol.
2) Inquiring the public network address of the next hop through the VAM
protocol.
3) Encapsulating the packet, using the public address as the
destination address of the tunnel.
4) Sending the packet down the tunnel to the destination.
The following key roles are involved in
DVPN:
DVPN node
A DVPN node is a device at an end of a DVPN
tunnel. It can be a networking device or a host. A DVPN node takes part in
tunnel setup and must implement VAM client. VAM client are your bracnhes will connect to DRC site and PDCsite by two vpn tunnel 1 and 2
VAM server
A VAM server receives registration
information from DVPN nodes and manages and maintains information about DVPN clients.
Currently, a VAM server is usually a high performance routing device with VAM server
enabled. You can set this VAM server on DRC's router and PDC's router. on PDC site has a primary VAM server, and on DRC site has a secondary VAM server.
VAM client
A VAM client registers its private address,
public address, and VAM ID with the VAM server and obtains information about
other VAM clients from the VAM server. The VAM client function must be
implemented on DVPN nodes. Unless otherwise noted, the term “VAN client” in
this document refers to a Hub or a Spoke.
VAM client are your bracnhes will connect to DRC site and PDCsite by two vpn tunnel 1 and 2
VAM client are your bracnhes will connect to DRC site and PDCsite by two vpn tunnel 1 and 2
Hub
A Hub is a type of VAM client. As a central
device of a VPN, it is the exchange center of routing information. A Hub in a
Hub-Spoke network is also a data forwarding center. in DRC and PDC environment, you have two Hub, Hub#1 at DRC site and Hub#2 at PDC site.
Spoke
A Spoke is a type of VAM client. Usually
acting as the gateway of a branch office, a Spoke does not forward data
received from other DVPN nodes.
AAA server
An Authentication, Authorization, and
Accounting (AAA) server is used for user authentication and accounting. with this architecture of DVPN at here I not use function of Authorization, and
Accounting (AAA) server, on router allow you to support authenticaiton base on username and password., still make security for only VAM clients (your branches) which is authenticated will is connected to VAM servers successfully.
Operation of DVPN
DVPN employs the client/server model.
Operating at the application layer of the TCP/IP protocol stack, DVPN uses UDP
as its transport layer protocol.
A DVPN consists of one server and multiple
clients. The public address of the server in a DVPN must be static. The private
address of a client needs to be statically assigned, while the public address
of a client can be manually configured or dynamically assigned. All the private
addresses of the nodes composing a DVPN must belong to the same network segment.
Each client registers the mapping of its
private address and public address with the server. After a client registers its
address mapping with the server, other clients can get the public address of
this client from the server. This is for DVPN tunnel establishment between
clients. Each client uses the VAM protocol to communicate with the server and
uses the DVPN tunneling protocol to establish, maintain, and remove tunnels to other
clients. Whenever there is a change in the topology, the server will be
notified automatically.
Networking Structures of DVPN
DVPN supports two typical networking
structures, full mesh and Hub-Spoke.
+ Full mesh DVPN: In a full mesh
DVPN, Spokes can communicate with each other directly by establishing tunnels
between them, and the Hub is mainly used as the routing information exchange
center. As shown in Figure 1-1, after the Spokes (the clients) register
with the VAM server and get the Hub information in the VPN domain, they establish
permanent tunnels with the Hub. Any two Spokes can establish a tunnel directly
between them, which is dynamic and will be aged out if no data exchange occurs
on it during the specified period of time (the idle timeout for the Spoke-Spoke
tunnel).
+ Hub-Spoke DVPN. In a Hub-Spoke DVPN,
no tunnel can be established between two Spokes, and data between them has to
be forwarded through the Hub. That is, the Hub is used as both the routing
information exchange center and the data forwarding center. As shown in Figure1-2, each Spoke establishes a permanent tunnel
with the Hub, and data between Spokes is forwarded through the Hub.
In this solution, I will deploy Hub-Spoke DVPN with two Hub 01 (PDC) and Hub 02 (DRC), and all Spoke will be connected to these two hubs.
Implementation of DVPN
DVPN works in three phases: connection initialization,
registration, and tunnel establishment. The following is a brief description of
the phases.
Refer to more document:
HP Dynamic Virtual Private Network (DVPN)
Cisco Dynamic Multipoint VPN (DMVPN) Design Guide