Cisco Network Proposal 3
By:Dylan Jurvelin
CMIT 350
Table of Contents
Introduction 3
Sacramento Site
Requirements 3
Current Problems & Location Specifics 3
Site Details and Supporting Charts 4
Proposed Technologies and Solutions 5
Sample Configuration VLAN Database (SacramentoSw1) 6
Configuring access mode and port security 6
Configuring Switchport Security (All Switches) 7
ROS Topology Configuration (Switch) 7
ROS Topology Configuration (Router) 8
Configuring IP Assignment (Router) 9
II. Los Angeles Site
Site Challenges 10
Site Solution and Technologies 11
Remote Device Configuration Storage (Router) 11
Configuring Remote Management of Switches (All Switches) 12
Configuring the Access Control List (ACL) (Router) 13
Configuring the Network Time Protocol (NTP) (Router) 14
III. WAN Requirements
Site Details and Challenges
Configuring PPP with CHAP Authentication (All Routers) 16
Adding Redundancy and Bandwidth (Sacramento and Springfield Routers) 17
Conclusion 19
References 20
Introduction
The local system team has asked myself to assist in providing solutions and implementing new protocols that meet the requirements needed at both sites in Sacramento and Los Angeles. To introduce and provide them with the new solutions that are needed to satisfy the requirements, my team will research and provide the best protocols and the best implementation protocols, as well as configurations that help in achieving the goals requested by the local systems team. This proposal will provide you with suggested solutions and well detailed reasoning behind the decision. Also, step-by-step configurations will be provided to show how the implementation will take place.
Sacramento Site – Current Problems & Location Specifics
Requirements
The faculty, students, and staff at the Sacramento site require a secured and reliable network that will allow users to complete their daily activities. To establish the network that meets the requirements at the Sacramento site, we will be implementing a network infrastructure technology that will increase efficiency and will provide interconnectivity between all the other remote locations.
When implementing more recent technologies, there is always a chance of complications that may come up. In this proposal, I will present the complications that have been noted by the network admin, as well as suggested solutions to correct the issues. Also, included with the suggested solutions, we will also provide prevention measures that can help in preventing any potential threats on the network. Additionally, my team and I will implement protocols that will provide overall usability of the network at the Sacramento site. The main purpose for this proposal is to provide assistance and maintain the well-being and overall security of the Sacramento’s site network while providing any authorized personnel a network that is secure and reliable to perform daily tasks.
B. Site Details and Challenges
The following are specific network devices that are located at the Sacramento site. At the Sacramento location, there are three components that are necessary to complete the Sacramento network. As stated in the Sacramento site requirements, they are requesting that a VLAN database for the three switches be put into place. Additionally, to prevent any unauthorized access from gaining access the network and allow only 2 mac addresses per port, we will be implementing port security on all three switches. Also, being implemented is routing on a stick (ROS) topology, which will fulfill the requirement that is needed for the multiple VLANS and the Inter-VLANS. Finally, IP addresses will be automatically assigned within the proper pools of IP addresses, Dynamic Host Control (DHP) will be implemented. According to the Sacramento site requirements, we have listed devices as well as the configurations that will be used during the implementation below.
One (1) Cisco 2800 Series router with the below available interface ports:
Cisco 2800 Series Integrated Services
Interfaces Ports Available
4 Fast Ethernet Interfaces
(Per Router)
2 Serial Interfaces
(Per Router)
fa0/0
s0/0/0
fa0/1
s0/0/1
fa1/0
fa1/1
The chart below shows that ports that are available on the 3 Cisco Catalyst 6500 Series
Cisco Catalyst 6500 Series
Ports Available
96 Total Gigabit Ethernet
Ports Per Switch
Module 1 = gi0/1 – gi0/24
Module 2 = gi1/1 – gi1/24
Module 3 = gi2/1 – gi2/24
Module 4 = gi3/1 – gi3/24
Below are the 4 VLAN’s that are currently located at the Sacramento Site
VLAN Name
Members
Number of Devices
Faculty
Faculty
5
Admin
Staff
14
Academic or Instructional
Students and Faculty
34
Server
IT Staff
7
.
Figure 1 Sacramento Site Topology
C. Proposed Solutions
The first step in fulfilling the requirements requested by the local system admin at the site is to create a VLAN database, which should be created on Sacramento_Sw1. As shown in the Sacramento topology, we are going to separate the location into four separate VLAN’s which will be named faculty, admin, server and instructional. The default settings that are currently assigned shows that all ports are allocated to VLAN 1.Additionally, we need to decide which switchport mode is required for the specific location. After examining the current topology for the site, it has been determined that configuring the ports as access ports will be adequent.
VLAN ID
# of Devices
IP Range
Subnet Mask
Default Gateway
ADMIN
14
10.50.0.64- 116
255.255.255.192
10.50.0.65
INSTRUCTIONAL
34
10.50.0.128 – 180
255.255.255.192
10.50.0.129
SERVER VLAN
7
10.50.0.192 -245
255.255.255.192
10.50.0.193
FACULTY VLAN
5
10.50.0.0 – 52
255.255.255.192
10.50.0.1
Sample Configuration VLAN Database (SacramentoSw1)
Below are commands that will be used when assigning names to the VLAN’s located at the Sacramento Site.
SacramentoSw1#conf t
SacramentoSw1(config)#vlan 2
SacramentoSw1(config-vlan)#name FacultyVLAN
SacramentoSw1(config-vlan)#vlan 3
SacramentoSw1(config-vlan)#name AdministrativeVLAN
SacramentoSw1(config-vlan)#vlan 4
SacramentoSw1(config-vlan)#name InstructionalVLAN
SacramentoSw1(config-vlan)#vlan 5
SacramentoSw1(config-vlan)#name ServerVLAN
SacramentoSw1(config-vlan)#CRTL+Z
SacramentoSw1#copy run start
Afterwards, we will implement port security. To allow specific numbers of source MAC addresses to enter any port on the devices, we will need to implement Port security protocols. Port security only allows authorized individuals to configure the switch ports separately as well [1]. By default, port security is disabled, so once its configured, we will also need to enable it. Port security is unique in the matter that it has the capabilities to remember the MAC addresses that are connected to the switchport. Additionally, it only allows those MAC address to enter the port [1]. Any unknown addresses trying to access the port will cause the port to be disabled. This process is enforced by the port security feature [1]. Below you will find a sample configuration for port security.
Configuring access mode and port security
SacramentoSw1>en
SacramentoSw1# conf t
SacramentoSw1 (config)#int gi0/1
SacramentoSw1 (config-if)#SwitchPort mode Access
SacramentoSw1 (config-if)#SwitchPort access VLAN 5
SacramentoSw1 (config-if)#no shutdown
SacramentoSw1 (config-if)# CRTL+Z
SacramentoSw1#copy run start
Finally, we need to implement a security measures protocol to address all ports that are not being utilized on the site’s switches. Typically, all ports that are not in use should be disabled until they are needed. The commands listed below will be used to provide security measures that meet the requirements.
Configuring Switchport Security (All Switches)
SacramentoSw2>ena
SacramentoSw2#conf t
SacramentoSw2(config)#int range gi0/1 – 24, gi1/1 – 24, gi2/1 – 12
SacramentoSw2(config-if-range)#switchport mode access
SacramentoSw2(config-if-range)#switchport port-security
SacramentoSw2(config-if-range)#switchport port-security maximum 2
SacramentoSw2(config-if-range)#switchport port-security violation shutdown
SacramentoSw2(config-if-range)#switchport port-security mac-address sticky
SacramentoSw2(config-if-range)#shut
SacramentoSw2(config-if-range)#no shut
Configurations to enable Port Security Active Ports Assigned to each VLAN at the Sacramento Site
SacramentoSw2(config-if-range)#int range gi2/13 -24, gi3/1 – 24
SacramentoSw2(config-if-range)#shut
SacramentoSw2(config-if-range)#CNTRL+Z
SacramentoSw2#copy run start
The site’s local system admin also requires a protocol that will support multiple VLANS. After viewing the ROS topology at the site, it has been decided that implementing configurations will ensure proper functionality and support for the several VLAN’s on site. ROS topology is also recommended at this site because of its capability to perform Inter-VLAN routing. Being that the sites are used for educational purposes, it is important that all the devices located on the site have the capabilities to interact with each other which would not be possible with the original configuration. The type of Inter-VLAN routing that will be implemented to forward traffic within the different routers on the network is Router on a Stick (ROS) [2].
ROS Topology Configuration Requirements:
ROS Topology Configuration (Switch)
To implement this routing, we will be using the configuration commands listed below.
SacramentoSw2>ena
SacramentoSw2#conf t
SacramentoSw2(config)#int fa0/24
SacramentoSw2(config-if)#switchport mode trunk
SacramentoSw2(config-if)#exit
SacrametoSW2(config)#exit
SacramentoSw2#copy running-config startup-config
ROS Topology Configuration (Router)
We must first create a sub-interface, second, IP addresses need to be assigned, and lastly
the frame tagging method needs to be defined.
Sacramento-R>ena
Sacramento-R#conf t
Sacramento-R(config)#int fa0/0
Sacramento-R(config-if)#no shut
Sacramento-R(config-if)#int fa0/0.2
Sacramento-R(config-subif)#ip address 10.50.0.0 255.255.255.192
Sacramento-R(config-subif)#encap dot1q 2
Sacramento-R(config-subif)#int fa0/0.3
Sacramento-R(config-subif)#ip address 10.50.0.64 255.255.255.192
Sacramento-R(config-subif)#encap dot1q 3
Sacramento-R(config-subif)#int fa0/0.4
Sacramento-R(config-subif)#ip address 10.50.0.128 255.255.255.192
Sacramento-R(config-subif)#encap dot1q 4
Sacramento-R(config-subif)#int fa0/0.5
Sacramento-R(config-subif)#ip address 10.50.0.192 255.255.255.192
Sacramento-R(config-subif)#encap dot1q 5
Sacramento-R(config-subif)#exit
Sacramento-R(config)#exit
Sacramento-R#copy running-config startup-config
The purpose for using Dynamic Host Configuration Protocol (DHCP) is to allow individual computers located on a network to extract their configurations from a server (the DHCP server) or servers, for example, DHCP is used when servers do not have all the data that is needed about the specific device, [3]. To minimize the workloads required when administering a large IP network, we will want to utilize DHCP. Below I have provided a sample configuration for DHCP.
Configuring IP Assignment (Router)
SacramentoR>ena
SacramentoR#config t
SacramentoR(config)#ip dhcp excluded-address 10.50.0.53 10.50.0.63
SacramentoR(config)#ip dhcp excluded-address 10.50.0.117 10.50.0.127
SacramentoR(config)#ip dhcp excluded-address 10.50.0.181 10.50.0.191
SacramentoR(config)#ip dhcp excluded-address 10.50.0.245 10.50.0.254
SacramentoR(config)#ip dhcp pool Faculty
SacramentoR(dhcp-config)#network 10.50.0.0 255.255.255.192
SacramentoR(dhcp-config)#default-router 10.255.255.253 255.255.255.252
SacramentoR(dhcp-config)#dns-server 10.255.255.253 255.255.255.252
SacramentoR(config)#ip dhcp pool Administrative
SacramentoR(dhcp-config)#network 10.50.0.64 255.255.255.192
SacramentoR(dhcp-config)#default-router 10.255.255.253 255.255.255.252
SacramentoR(dhcp-config)#dns-server 10.255.255.253 255.255.255.252
SacramentoR(config)#ip dhcp pool Instructional
SacramentoR(dhcp-config)#network 10.50.0.128 255.255.255.192
SacramentoR(dhcp-config)#default-router 10.255.255.253 255.255.255.252
SacramentoR(dhcp-config)#dns-server 10.255.255.253 255.255.255.252
SacramentoR(config)#ip dhcp pool Server
SacramentoR(dhcp-config)#network 10.50.0.192 255.255.255.192
SacramentoR(dhcp-config)#default-router 10.255.255.253 255.255.252
SacramentoR(dhcp-config)#dns-server 10.255.255.253 255.255.255.252
SacramentoR(dhcp-config)#exit
SacramentoR(config)#exit
SacramentoR#copy running-config startup-config
Los Angeles Site – Requirements
Another remote site within the xAcme location that will need to be available for faculty, students and staff to perform their daily duties is the Los Angeles site. The Los Angeles site requires specific infrastructure to be implemented to enhance the overall efficiency in performing any daily tasks. Also, they require a network that provides interconnectivity between all remote locations within the xAcme site. The Los Angeles site will need specific device configuration which will include configurations to provide proper remote storage, remote management of allswitches, ACL protocol implementation, and an NTP solution.
Site Details
According to the current topology of the Los Angeles site, a total of (1) Cisco 2800 series router, and (3) Cisco Catalyst 6500 series switches will need to be configured to fulfill the necessary requirements specified. The Cisco router has four (4) Fast ethernet Interfaces (fa), and two (2) Serial interfaces (s). Additionally, (1) TFTP/SFTP/NTP server has been assigned an IP address of 10.40.6.10/23. The site will need to be divided into 4 separate VLAN’s which will be labeled, faculty, academic, server, and administrative.
Assistance has been requested by the local admin team to implement proper solution in providing remote storage for device configuration, and providing an accurate Remote IOS storage protocol.Additionally, to allow for remote management and to increase efficiency and network performance, all switches will be configured with proper configurations. The chart below explains the existing VLAN configurations and intended uses.
VLAN Name
Members
Number of Devices
Faculty
Faculty
21
Administrative
Staff
44
Academic or Instructional
Students and Faculty
120
Server
IT Staff
21
Local admin are requesting that we implement a protocol to provide security for the networks access and restriction protocol to the network devices. The proposal shall include implementation on Access Control List’s (ACL) and the type of ACL to be implemented, the placement, and the site’s router configuration. When communicating with the devices at the Los Angeles location, only the Server VLAN shall be allowed to communicate remotely. Lastly, to ensure synchronization for all devices within the site, Network Time Protocol (NTP) solution is required to be implemented. NTP is necessary in providing an accurate logging of all records on the network and allows authentication protocols to be established.
Site Solution and Technologies
When deciding on any solution for remote storage to copy configuration files located on a network to a file server, there are many options that can be explored. These options include using File Transfer Protocol (FTP), Secure File Transfer Protocol (SFTP), Trivial File Transfer Protocol (TFTP), or Remote Copy Protocol (RCP) [4]. Due to the available equipment located at the site, and after reviewing the different mechanisms, it is being recommended to backup router configurations we must implement TFTP. The commands below will allow us to do so.
Remote Device Configuration Storage (Router)
LosAngeles-R>ena
LosAngeles-R#conf t
LosAngeles-R(config)#line con 0
LosAngeles-R(config-line)#password S#cur1ty
LosAngeles-R(config-line)#login
LosAngeles-R(config-line)#exit
LosAngeles-R(config)# copy run tftp: //10.40.6.10/LosAngelesRouter-config
Remote IOS Storage
In addition, to permit remote access to the various switches at the site as well as the management of those switches, there are many protocols which can be implemented. For example, Telnet, Cisco Discovery Protocol (CDP), Secure Shell (SH) and Internet Control Message Protocol (ICMP), are protocols that can be implemented to allow local system administrators to remotely access Cisco devices [5]. After reviewing the protocols associated with using SSH, it is suggested that SSH is the best remote access protocol for the site. SSH can be used with all types of network devices, and because it is a secure protocol that can encrypt sessions from SSH clients and SSH servers, it appears that this is the best option for the Los Angeles site [5][2].
Configuring Remote Management of Switches (All Switches)
The following commands will help in configuring all the switches
LosAngelesSw1>ena
LosAngelesSw1#conf t
LosAngelesSw1(config)#line vty 0 15
LosAngelesSw1(config-line)#login local
LosAngelesSw1(config-line)#exit
LosAngelesSw1(config)#username @dm1n password S3curePas$word
LosAngelesSw1(config)#ip domain-name xAcme.edu
LosAngelesSw1(config)#cypto key generate rsa
Access Control List (ACL)
The admin team has requested a protocol that will restrict and secure the network devices from unauthorized access. To fulfill this requirement, it is recommended that we configure and implement an Access Control List (ACL) to only allow the Server VLAN to remotely communicate with other Sacramento site devices. An access control list (ACL), is a list of permissions attached to an object that is used to access or restrict data flow on a network [6]. It is used to grant specific users or system processes to an object and includes what that user is permitted to do on that object. ACL’s come in various types and are typically used for a specific reason. There are two ACL’s when using a Cisco router, one type is known as a “standard ACL”, the other is an “extended ACL [6]. A “Standard” ACL the minimal packet filtering and allows you to prioritize traffic by the Source IP address only, whereas an extended ACL can use different filtering option such as (1) the source IP address, (2) the destination IP address, (3) the TCP/IP protocol, and (4) the TCP/IP protocol information [6]. To fulfill requirements requested by local admin, we will be implementing a standard ACL. The following commands will be used for configuration.
Configuring the Access Control List (ACL) (Router)
LosAngeles-R>ena
LosAngeles-R#conf t
Los-Angeles-R(config)#
Los-Angeles-R(config)#access-list 1 permit 10.40.6.0 0.0.255.255
Los-Angeles-R(config)#access-list 1 deny any any
Los-Angeles-R(config)#line vty 0 15
Los-Angeles-R(config-line)#access-class 1 in
Los-Angeles-R(config-line)#exit
Los-Angeles-R(config)#exit
Los-Angeles-R#copy running-config startup-config
Finally, the site local admin require a protocol that will allow them correct certain events if they receive system logs or other time-related events requiring timestamps for any devices on their network. To provide the admin with such capabilities, we will be implementing Network Time Protocol (NTP). Due to its fast connection and response times, NTP utilizes packets from User Data Protocol (UDP) to transfer data over the network [7]. Below is a sample configuration that will be used to configure NTP.
Configuring the Network Time Protocol (NTP) (Router)
LosAngeles-R>ena
LosAngeles-R#conf t
LosAngeles-R(config)#feature ntp
LosAngeles-R(config)#ntp server 10.40.6.10
LosAngeles-R(config)#exit
LosAngeles-R#copy running-config startup-config
xAcme WAN Requirements
A. Site Details and Challenges
Currently the WAN for the xACME educational facilities are serial-based and connected over leased lines that utilize the default protocol for a layer 2 connectivity. In addition, there are no authentication protocols in place at the present time although it is preferred that a security protocol be implemented. The local systems admin are requesting that an investigation be done on the available WAN protocols and include solutions that include authentication between devices. Included in the proposal will be device configurations which will be based off the current implementations, as well as any steps that are required in the recommended solution. According to the xAcme network topology, the Los Angeles site and the Boston site have been connected across a leased line, and they both remain as the entry point to its regional sites. Lately there has been a concern as to the load of traffic that each device has been handling. Due to the mentioned issues, the local systems admin have requested that the topology for the educational facilities be reviewed. Along with the review we are being asked to provide redundancy as well as solutions to reduce the bandwidth requirements that have been placed on both devices.
Site Solutions
Although there are many different WAN protocol options, only two of the options would be considered for use in this deployment. First option available for the required WAN solution is the High-Level Data Link Control (HDLC) Protocol [8]. Second option available is called Point to Point Protocol (PPP) [8]. HDLC Protocol is the default protocol on all Cisco interfaces and is used to connect point-to-point devices [8]. Despite the similarities between HDLC and PPP, there are features that one has over the other that will fulfill the needs of the facilities. PPP provides authentication which is supported with PAP and CHAP. Also, PAP is not limited just to Cisco devices, it relies on sub-protocols to function, [8]. After review of the two protocols and the requirements of the facility, implementing PPP with CHAP is required to fulfill the request of the local admin Implementing PPP versus HDLC will ensure that the proper authentication is used between all devices.
To address the bandwidth concerns and provide additional redundancy within the educational topology, recommendations include using additional leased line connections to connect the Sacramento and Springfield sites. The goal behind adding the additional leased line is to convert the current peer-to-peer topology to a ring WAN connection [9]. The ring is formed by each site connecting to two other sites. There are great advantages to using the ring topology versus the peer-to-peer topology. First, in case there is a problem with one cable, that will cause the network to slow down or cause major problems. Second, routers at all locations have the capability to change the direction of the traffic in case one route becomes flooded [9]. The ring WAN topology is the best choice when there are limited number of sites being connected, around four to five [9]. Below are commands that should be used with this configuration meeting the requirements.
Configuring PPP with CHAP Authentication (All Routers)
Boston-R>ena
Boston-R#conf t
Boston-R(config)#username WorchesterRouter password Auth@rized 0nly!3
Boston-R(config)#exit
Worchester-R>ena
Worchester-R#conf t
Worchester-R(config)#username BostonRouter password Auth@rized 0nly!3
Worchester-R(config)#exit
Boston-R>ena
Boston-R#conf t
Boston-R(config)#int s0/0/1
Boston-R(config-if)#encapsulation ppp
Boston-R(config-if)#exit
Boston-R(config)#exit
Worchester-R>ena
Worchester-R#conf t
Worchester-R(config)#int s0/0/1
Worchester-R(config-if)#encapsulation ppp
Worchester-R(config-if)#exit
Worchester-R(config)#exit
Boston-R>ena
Boston-R#conf t
Boston-R(config)#int s0/0/1
Boston-R(config-if)#no ppp pap sent-username WorchesterRouter
Boston-R(config-if)#ppp authentication chap
Boston-R(config-if)#exit
Boston-R(config)#exit
Boston-R#
Worchester-R>ena
Worchester-R#conf t
Worchester-R(config)#int s0/0/1
Worchester-R(config-if)#no ppp pap sent-username BostonRouter
Worchester-R(config-if)#ppp authentication chap
Worchester-R(config-if)#exit
Worchester-R(config)#exit
Worchester-R#debug ppp authentication
Worchester-R#conf t
Worchester-R(config)#int s0/0/1
Worchester-R(config-if)#shut
Worchester-R(config-if)#no shut
Worchester-R(config-if)#no shut
Worchester-R(config-if)#exit
Worchester-R(config)#exit
Worchester-R#sh int s0/0/1
Adding Redundancy and Bandwidth (Sacramento and Springfield Routers)
Sacramento-R>ena
Sacramento-R#conf t
Sacramento-R(config)#int s0/0/1
Sacramento-R(config-if)#ip address 165.128.63.5 255.255.255.252
Sacramento-R(config-if)#shut
Sacramento-R(config-if)#no shut
Sacramento-R(config-if)#exit
Sacramento-R(config)#exit
Sacramento-R#copy run start
Conclusion
In the above proposal which was created so that we could provide solutions for the Sacramento site and the Los Angeles site with a network that is reliable and provides security. We created VLAN databases and implemented port security, as well as switchport security for all switches. Also, we were requested to provide and implement a protocol that will provide support for many VLAN’s located on the network. To complete this task , we have implemented ROS topology to assist in forwarding all data traffic. We also were requested to provide a protocol to manage assigning of IP address. We concluded that implementing DHCP would be the best option to assist in handling this requirement. Following these requirements, we have included step-by-step commands to enforce these protocols.
Also, we were requested to provide resolutions and implement certain protocols and the Los Angeles site that could be used to transfer files, permit remote access to specific individuals, as well as restriction and provide security for the network. After reviewing the requirements and the request of the local system admin, we felt that implementing TFTP protocol for file transfer is the best option. Additionally, remote access into the network is a viable necessity that is need for the staff at xAcme. Implementation of a protocol that provides the features that is required for the Los Angeles location. We have also put in place ACL protocol to provide access security to the network by restricting some individuals and groups. Lastly, we have included NTP to provide system administrators the ability to synchronize time on the servers on the network.
The final requirement requested by the local system admin was to create a suitable WAN topology and implement a security protocol for the facilities. In doing so, the option that we chose to address these issues in the PPP with Chap protocol. PPP provides authentication that is required from one device to another.
Securing a network is a job that consists of many components and can involve several different people. Knowing the several options that are available and knowing how to implement them can be the key to a network running smooth. With these suggested protocols in this proposal, this can be accomplished.