DESIGN AND IMPLEMENTATION OF TACACS+
ON A SCALABLE ENTERPRISE BASED IP NETWORK
A Project
Presented to the faculty of the Department of Computer Science
California State University, Sacramento
Submitted in partial satisfaction of
the requirements for the degree of
MASTER OF SCIENCE
in
Computer Science
by
Aejazuddin Farooqui
FALL
2012
DESIGN AND IMPLEMENTATION OF TACACS+
ON A SCALABLE ENTERPRISE BASED IP NETWORK
A Project
by
Aejazuddin Farooqui
Approved by:
__________________________________, Committee Chair
Dr. Jinsong Ouyang
__________________________________, Second Reader
Dr. Chung-E Wang
____________________________
Date
ii
Student: Aejazuddin Farooqui
I certify that this student has met the requirements for format contained in the University
format manual, and that this project is suitable for shelving in the Library and credit is to
be awarded for the project.
__________________________, Graduate Coordinator
Dr. Nichrouz Faroughi
Department of Computer Science
iii
___________________
Date
Abstract
of
DESIGN AND IMPLEMENTATION OF TACACS+
ON A SCALABLE ENTERPRISE BASED IP NETWORK
by
Aejazuddin Farooqui
As corporate offices are geographically distributed, securing and managing networks has
always been increasingly challenging. These offices have both highly confidential
mission and business critical data forwarding between different sites and requires high
degree of network security from all possible aspects. As more sites converge, careful
design and planning must occur to assure that the quality, reliability and security of
network is not affected.
This project proposes a scalable TACACS+ architecture that can be implemented by
Universities, Enterprises and Internet Service Providers. The proposed architecture
facilitates easy integration of network domains and centralized manageability to provide
Authentication, Authorization and Accounting (AAA) services to establish network
connectivity to multivendor network elements. It also resolves two identified major
issues. One, long end-to-end round trip network user authentication delay and second,
lack of centralized manageability leading to unauthorized user-access regardless of job
function.
iv
These two issues are addressed in two project phases. The first phase involves creating a
prototype of an enterprise based end-to-end IP network. This prototype is designed and
deployed with two sites represented as regional sites in different Autonomous Systems
(AS). The second phase involves deployment of a centralized TACACS+ environment.
The proposed project is implemented using Cisco networking appliance. With the
successful implementation of these phases, a secure and centralized TACACS+ model
was deployed with one single point to provide global administration. To compare
network performance analysis during different time periods, a pre-production ACS server
is deployed in a regional GAR site in Penang to provide AAA services. The average
performance during peak time is improved by 87.1% and the average performance during
off peak time is improved by 89.2%. Secondly, the average hop count for devices in
Penang, where the AAA server is actually integrated, is improved by 75%. And the
average hop count for devices in other sub-regions is improved by ~50%. Finally, with a
hierarchal IP network design the end-to-end back and forth authentication request and
response messages are specific to dedicated slaves in dedicated regional domains, hence
reducing immense noise on network core layer.
_______________________, Committee Chair
Dr. Jinsong Ouyang
_______________________
Date
v
ACKNOWLEDGEMENTS
I would like to thank my supervisors Prof. Dr. Jinsong Ouyang and Prof. Dr. Martin
Nicholes, for allowing me to work on this project in the office laboratory. I would like to
thank my second reader Prof. Dr. Chung-E Wang for willing to review my project. I
would like to thank my colleagues Jeff Lee and Brent Anderson for providing the
resources I needed in the lab to accomplish this project. More importantly, I am indebted
by the encouragement and inspiration that Prof. Ouyang and Prof Nicholes have provided
to me. I learnt a lot of theoretical and practical concepts during this project. It not only
enhanced my knowledge in network security, but also in terms of project scoping, project
execution, demonstration of results, documentation, and successful project fulfillment.
Once again, I would like to thank Prof. Ouyang and Prof. Nicholes for all the help and
motivation and would like to share with them the credit of fulfillment of this project.
I would also like to thank Prof. Dr. Cui Zhang for providing valuable information through
Research Methodology on preparing for Master Project and Thesis especially how to
recognize plagiarism.
Last, but not the least, I would like to thanks my wife Uzma for providing me all support
since the beginning of my master’s course.
My best regards to all the people mentioned above. Further information on topics covered
in this project can be obtained from Cisco Systems documentation website
http://www.cisco.com/univercd.
vi
TABLE OF CONTENTS
Page
Acknowledgements ............................................................................................................ vi
List of Tables ...................................................................................................................... x
List of Figures ................................................................................................................... xii
Chapter
1. INTRODUCTION .......................................................................................................... 1
1.1
Access Control System ....................................................................................... 2
1.2
What Is TACACS+? ........................................................................................... 3
1.2.1
Authentication ................................................................................................. 3
1.2.2
Authorization .................................................................................................. 4
1.2.3
Accounting ...................................................................................................... 4
1.3
Scope Of The Project .......................................................................................... 5
2. PROTOTYPE OF AN ENTERPRISE BASED IP NETWORK.................................... 6
2.1
Hierarchical Network Design ............................................................................. 6
2.2
IP Addressing ...................................................................................................... 7
2.3
Hardware & IOS ............................................................................................... 10
2.4
Implementation Of Distribution Layer At Site1 ............................................... 10
2.5
Implementation Of Access Layer At Site1 ....................................................... 16
2.6
Implementation Of Core Layer At Site1 ........................................................... 23
2.7
Configuring EIGRP .......................................................................................... 31
vii
2.8
Implementation Of Core Layer at Site2 ............................................................ 42
2.9
Integration Of Site1 and Site2 Using WAN Links ........................................... 43
3. DEPLOYMENT OF CENTRALIZED TACACS+ ENVIRONMENT ....................... 55
3.1
Installing Master And Slave TACACS+ Servers ............................................. 58
3.2
Building Master Server And Replicating To Slave Server ............................... 59
3.2.1
Creating Network Device Groups ................................................................. 60
3.2.2
Creating User Groups ................................................................................... 62
3.2.3
Creating Users ............................................................................................... 62
3.2.4
Replicating Database .................................................................................... 63
3.2.5
Master Setup ................................................................................................. 63
3.2.6
Slave Setup.................................................................................................... 64
3.2.7
Configuring Site1 and Site2 Network Devices With TACACS+ ................. 66
3.2.8
Testing For PASSED Authorization To Network Devices........................... 69
3.2.9
Testing For FAILED Authorization To Network Devices ........................... 73
3.2.10 Round Trip Delay For Site1 Primary TACACS+ Server ............................. 75
3.2.11 Round Trip Delay For Site1 Secondary TACACS+ Server ......................... 76
4. PRE-PRODUCTION DEPLOYMENT AND NETWORK PERFORMANCE
ANALYSIS .................................................................................................................. 77
4.1
Analysis Of Round-Trip-Delay At Different Time Periods For A AAA Server
Outside Region: ................................................................................................ 78
4.1.1
Analysis Of RTD During Morning Hours .................................................... 79
viii
4.1.2
Analysis Of RTD During Peak Hours .......................................................... 80
4.1.3
Analysis Of RTD During Afternoon Hours .................................................. 82
4.1.4
Analysis Of RTD During Off Hours ............................................................. 83
4.1.5
Analysis Of Average RTD During Different Time Periods ......................... 84
4.2
Analysis Of Hop Count At Different Time Periods For A AAA Server Outside
Region: ............................................................................................................. 85
4.3
Deploying Regional Pre-Production AAA Servers .......................................... 86
4.4
Analysis Of Round-Trip-Delay At Different Time Periods For A AAA Server
Within A Region: ............................................................................................. 87
4.4.1
Analysis Of RTD During Morning Hours .................................................... 87
4.4.2
Analysis Of RTD During Peak Hours .......................................................... 88
4.4.3
Analysis Of RTD During Afternoon Hours .................................................. 90
4.4.4
Analysis Of RTD During Off-Peak Hours.................................................... 91
4.4.5
Analysis Of Average RTD During Different Time Periods ......................... 92
4.5
Analysis Of Hop Count At Different Time Periods For A AAA Server In The
Same Region: ................................................................................................... 94
4.6
Improvement In Network Performance ............................................................ 95
5. CONCLUSION ............................................................................................................ 99
Acronyms ........................................................................................................................ 100
References ....................................................................................................................... 101
ix
LIST OF TABLES
Tables
Page
2-1
Subnetted Block Of 172.16.0.0/12 ....................................................................... 8
2-2
Subnetted Block Of 192.168.0.0/16 ..................................................................... 9
2-3
Hardware And IOS/Software Version ............................................................... 10
2-4
Management Connectivity At Distribution Layer ............................................. 11
2-5
Configuring Management VLAN On NMS ...................................................... 12
2-6
Configuring Access Layer Network Element .................................................... 18
4-1
Average Morning Hour Stats For A AAA Server Outside A Region ................ 79
4-2
Average Peak Hour Stats For A AAA Server Outside A Region ...................... 81
4-3
Average Afternoon Hour Stats For A AAA Server Outside A Region ............. 82
4-4
Average Off Peak Stats For A AAA Server Outside A Region ........................ 83
4-5
Average Stats For A AAA Server Outside A Region ........................................ 84
4-6
Average Hop Count For A AAA Server Outside A Region .............................. 85
4-7
Average Morning Hour Stats For A AAA Server Within A Region ................. 87
4-8
Average Peak Hour Stats For A AAA Server Within A Region ....................... 89
4-9
Average Afternoon Hour Stats For A AAA Server Within A Region .............. 90
4-10
Average Off Peak Stats For A AAA Server Within A Region .......................... 91
4-11
Average Stats For a AAA Server Within A Region .......................................... 92
4-12
Average Hop Count For A AAA Server Within A Region ............................... 94
4-13
Average Performance Improvement in RTD ..................................................... 95
x
4-14
Average Hop Count Improvement ..................................................................... 97
xi
LIST OF FIGURES
Figures
Page
1-1
A Simple AAA Scenario ...................................................................................... 2
2-1
Hierarchical Network Design .............................................................................. 6
2-2
LAB Prototype integrated with WAN Connectivity between Two Sites ............ 7
2-3
Management VLAN Connectivity ..................................................................... 11
2-4
Layer1 - Connectivity ........................................................................................ 17
2-5
Segregation of Management and Client VLANs ............................................... 18
2-6
Integration of Distribution and Core Layer ....................................................... 24
2-7
Core VLAN’s ..................................................................................................... 25
2-8
Discovering Routes ............................................................................................ 33
2-9
Site2 Core VLAN .............................................................................................. 42
2-10
WAN Connectivity between Site1 and Site2 ..................................................... 44
2-11
Redistribution of EIGRP into BGP and BGP into EIGRP at Site1 ................... 51
3-1
Server VLAN 30 at Site1 ................................................................................... 56
3-2
ACS Web Interface ............................................................................................ 59
3-3
Centralized Administration and One Way Replication ..................................... 60
3-4
NDG of AAA Servers ........................................................................................ 61
3-5
Lab NDGs with LAN &WAN Subnets ............................................................. 61
3-6
Site1 IP Range.................................................................................................... 61
3-7
User Groups ....................................................................................................... 62
xii
3-8
NAS Restrictions ............................................................................................... 62
3-9
Group Level Settings ......................................................................................... 63
3-10
Replicating Components from Master Server.................................................... 63
3-11
Replication Servers from Master ....................................................................... 64
3-12
Replicating Components Receiving from Master Server .................................. 64
3-13
Inbound Replication Master Server ................................................................... 64
3-14
Outbound Database Replication from Master Server ........................................ 65
3-15
Inbound Database Replication on Slave Server ................................................. 66
3-16
Communication between Client and TACACS+ Server ................................... 68
3-17
Authentication Logs of User AJ ........................................................................ 73
3-18
Failed Authentication Logs of User AJ ............................................................. 75
4-1
Average RTD During Morning Hours ............................................................... 80
4-2
Average RTD During Peak Hours ..................................................................... 81
4-3
Average RTD During Afternoon Hours ............................................................ 82
4-4
Average RTD During Off Hours ....................................................................... 83
4-5
Average RTD At Different Time Periods .......................................................... 84
4-6
Periodic Representation Of Hop Count From Different Regions ...................... 85
4-7
Average RTD During Morning Hours ............................................................... 88
4-8
Average RTD During Peak Hours ..................................................................... 89
4-9
Average RTD During Afternoon Hours ............................................................ 91
4-10
Average RTD During Off-Peak Hours .............................................................. 92
xiii
4-11
Average RTD At Different Time Periods .......................................................... 93
4-12
Periodic Hop Count To A TACACS+ Server In the Same Region ................... 94
4-13
Average Performance Improvement in RTD ..................................................... 96
4-14
Average Hop Count Improvement ..................................................................... 97
xiv
1
CHAPTER 1. INTRODUCTION
Securing and managing networks has always been increasingly challenging in corporate
offices. As network grows, with mergers and acquisitions or new site deployment, it
becomes more challenging to converge and secure these decentralized networks. These
offices have both highly confidential mission and business critical data forwarding
between different sites and requires high degree of network security from all possible
aspects.
One of the ways to secure a network is to limit network access services to the authorized
users based on their business need. Equally as challenging is closely monitoring what
services are being used and their frequency of use. Network elements such as Routers and
Switches usually use Access Control Lists (ACL) to filter the source and destination IP
addresses coming in and out of the configured device interfaces. These restrictions are
applied and are limited to a device and not an individual! For example, if a device is
configured to allow traffic from host 10.1.1.1 to access a web server say WS1, then
anyone who is sitting on the host 10.1.1.1 will automatically have access to WS1.
To prevent this, a more secure and flexible filtering method would be to provide access to
specific authorized users. That means users with a dedicated username and password are
only authorized to access the service or login to a network device. One solution would be
to create a user database on every network element to restrict access to. However, this
would become administrative overhead to update user profiles, and, very hard and
laborious to manage in corporate offices where there are thousands of network elements.
2
What ideally required is a centralized Access Control System to administer and manage
user database.
1.1
Access Control System
Access Control System (ACS) is a scalable, high-performance Remote Access Dial in
User Services (RADIUS) and Terminal Access Controller Access Control System
(TACACS+) security server. As ACS acts as a centralized control point for managing
enterprise network users, administrators and network infrastructure resources, it provides
identity-based network-access control solution for intelligent information networks [1]. It
supports a broad variety of multivendor network access devices also known as AAA
clients, including wired and wireless LAN switches and access points, edge and core
routers, Voice over IP (VoIP), Firewall, etc.
Figure 1-1 [1] shows a simple AAA scenario where an ACS is functioning as an AAA
server for network access devices.
Figure 1-1 A Simple AAA Scenario
The Network Access Device (NAD) functions as an AAA client from the ACS
perspective, to direct all end-user host access requests to ACS, via the TACACS+ or
RADIUS protocols.
3
The NAD serves as the network gatekeeper, and sends an access request to ACS on
behalf of the user. ACS verifies the username, password and possibly other data by using
its internal database or one of the configured external identity directories. ACS ultimately
responds to the NAD with an access denied or an access-accept message with a set of
authorization attributes.
1.2
What Is TACACS+?
Terminal Access Controller Access Control System (TACACS) is a connection oriented
Access Control Protocol (ACP) that provides authorization for network administrative
operations on the network infrastructure itself. It provides separate control of each
service: Authentication, Authorization and Accounting [1]. It is a client/server method
that stores specific rights for users by associating attribute-value pair for each user. The
AAA authorization daemon on a network device such as router or a switch communicates
with the TACACS+ server to determine the correct authorization for different option,
such as EXEC and network access.
1.2.1
Authentication
Authentication provides a method for handling user identification, login and password
dialog, challenge and response, messaging and encryption. Authentication identifies users
prior to access to a network and network services [2]. The authentication facility provides
the ability to conduct an arbitrary dialog with the user. For example, after a login and
password are provided, to challenge a number of questions, like mother’s maiden name
or service type, etc. In addition, the TACACS+ authentication service supports sending
4
messages to user screens. For example, a message could notify user that their password
must be changed because of the corporate password aging policy of 90 days.
1.2.2
Authorization
Authorization determines what a user is allowed to do. ACS can send user profile policies
to AAA clients to determine which network services the user can access. Different users
and groups can be authorization to give different levels of service. For example, level one
user might not have the same access privileges as a level two user. You can also
differentiate by levels of security, access times, and services. ACS access restrictions
feature can be set to permit or deny logins based on time-of-day and day-of-week. For
example, a group of users can be created for temporary accounts that can disable on
specified dates.
Users can also be restricted to a service or combination of services such as PPP, ARAP or
EXEC. After a user selects a service, Layer 2 and Layer 3 protocols can be restricted,
such as IP and IPX, and individual access lists can be applied. Access lists on a per-user
or per-group basis can restrict users from reaching parts of the network where critical
information is stored or prevent them from using certain services, such as File Transfer
Protocol (FTP) or Simple Network Management Protocol (SNMP).
1.2.3
Accounting
AAA clients use the accounting functions that the RADIUS and TACACS+ protocols
provide to communicate relevant data for each user session to the AAA server for
recording. ACS writes accounting records to a comma-separated value (CSV) log file or
5
ODBC database. These logs can be imported into popular database and spreadsheet
applications for billing, security audits, and report generation.
Network managers can use the accounting facility to track user activity for a security
audit or to provide information for user billing. Accounting records include user
identities, start and stop times, executed commands (such as PPP), number of packets,
and number of bytes.
1.3
Scope Of The Project
The project is divided into two phases. The first phase involves creating a prototype of an
enterprise based end-to-end IP network. This prototype is designed and deployed with
two sites represented as regional sites in different Autonomous Systems (AS) and
interconnected via WAN links.
The second phase involves deployment of a centralized TACACS+ environment using
Cisco Secure ACS application. In this phase the TACACS+ design consists of a
centralized ‘Master’ server and dedicated regional Primary and Secondary ‘Slave’ servers
for providing AAA services.
Chapter two and three describers in details about the implementation of the above two
phases with working configuration and test cases. Finally, chapter four describes about
pre-production deployment and network performance analysis of deploying regional ACS
servers.
6
CHAPTER 2. PROTOTYPE OF AN ENTERPRISE BASED IP NETWORK
In order to deploy and test TACACS+ architecture, a prototype of an enterprise based IP
network is deployed as phase1. In this phase, two site networks are built and configured
with different autonomous systems to represent them as different sites.
2.1
Hierarchical Network Design
Each site is designed in a hierarchical model to enable network design in layers. And
each layer can be focused on specific functions, thereby enabling the design engineer to
choose the right systems and features for the layer. There are many other advantages of
implementing a hierarchical design, such as easy to scale the network, easy to understand
and troubleshoot the network, can maintain consistent design at different sites, etc.
Core A
CoreB
EIGRP/
OSPF/
RIP
CORE Layer
L3
L3
DS1
DIST Layer
DS2
VLAN 30
VLAN 30
L3
L3
VLAN 10
VLAN 10
VLAN 20
VLAN 20
TACACS (AAA)
Master
TACACS (AAA)
Slave
AS1
ACCESS Layer
L2
AS2
L2
AS3
L2
Client 1
AS4
L2
Client 2
Figure 2-1 Hierarchical Network Design
Figure 2-1 shows an example of a hierarchical network design that was implemented as
one of the project sites. The design consists of a backbone (core) layer, which provides
7
optimal transport between sites. The distribution layer, which provides policy based
connectivity, route summarization or aggregation and the access-layer, which provides
work group or user access to the network [3].
To maintain consistency Site2 was designed similar to Site1 in hierarchical layers. And to
simplify the end-to-end architecture and connectivity, the two sites were connected via
point-to-point WAN links. Figure2-2 shows the point-to-point connectivity between Core
routers of Site1 and Site2.
Figure 2-2 LAB Prototype integrated with WAN Connectivity between Two Sites
2.2
IP Addressing
Effective IP address management plays a very important role in designing large scale
networks especially when networks are geographically distributed. Use of effective IP
8
addressing helps to perform route summarization at distribution layer there by reducing
traffic on core, secondly easy management by allocating dedicated address space to
dedicated site, and subnetting within each site.
Two private address spaces 172.16.0.0/12 and 192.168.0.0/16, as specified in RFC 1918,
were used to implement a hierarchical design and keep the internal and external routes
distinctive. The address block 172.16.0.0/12 is used to implement WAN and the address
block 192.168.0.0/16 is used to implement LAN design. The tables 2-1 shows the two
major blocks represented in bit format.
Table 2-1 Subnetted Block Of 172.16.0.0/12
Major Block
172.16.0.0/12
172.16.0.0
172.16.0.1
…
172.16.0.255
172.16.1.0
172.16.1.0
172.16.1.4
172.16.1.8
172.16.1.12
172.16.1.16
…
…
172.16.1.255
…
…
172.16.255.255
172.17.0.0
…
Major Block
172.16.0.0/12
…
…
172.31.255.255
Binary Representation of 2nd, 3rd and
4th Octet
172.0001 0000.0000 0000.0000 0000
172.0001 0000.0000 0000.0000 0001
172.0001 0000.0000 0000.1111 1111
172.0001 0000.0000 0001.0000 0000
172.0001 0000.0000 0001.0000 0000
172.0001 0000.0000 0001.0000 0100
172.0001 0000.0000 0001.0000 1000
172.0001 0000.0000 0001.0000 1100
172.0001 0000.0000 0001.0001 0000
Subnet Mask
255.255.255.0
255.255.255.252
255.255.255.252
255.255.255.252
255.255.255.252
255.255.255.252
172.0001 0000.0000 0001.1111 1111
172.0001 0000.1111 1111.1111 1111
172.0001 0001.0000 0000.0000 0000
Binary Representation of 2nd, 3rd and
4th Octet
172.0001 1111.1111 1111.1111 1111
Subnet Mask
9
Table 2-2 Subnetted Block Of 192.168.0.0/16
Major Block
192.168.0.0/16
192.168.0.0
192.168.1.0/24
192.168.1.1
192.168.1.2
…
…
192.168.1.255
Binary Representation of 2nd, 3rd and
4th Octet
192.1010 1000.0000 0000.0000 0000
192.1010 1000.0000 0001.0000 0000
192.1010 1000.0000 0001.0000 0001
192.1010 1000.0000 0001.0000 0010
192.168.2.0/24
192.168.3.0/24
192.168.4.0/24
192.168.5.0/24
…
…
…
192.168.250.0/24
192.168.250.0/27
192.168.250.32/2
7
192.168.250.64/2
7
192.168.250.96/2
7
192.168.250.128/
27
…
…
192.168.250.224/
27
192.168.251.0/24
…
192.168.255.0/24
192.168.255.1
…
192.168.255.255
192.1010 1000.0000 0010.0000 0000
192.1010 1000.0000 0011.0000 0000
192.1010 1000.0000 0100.0000 0000
192.1010 1000.0000 0101.0000 0000
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
192.1010 1000.1111 1010.0000 0000
192.1010 1000.1111 1010.0000 0000
192.1010 1000.1111 1010.0010 0000
255.255.255.0
255.255.255.224
255.255.255.224
192.1010 1000.1111 1010.0100 0000
255.255.255.224
192.1010 1000.1111 1010.0110 0000
255.255.255.224
192.1010 1000.1111 1010.1000 0000
255.255.255.224
192.1010 1000.1111 1010.1110 0000
255.255.255.224
192.1010 1000.1111 1011.0000 0000
255.255.255.0
192.1010 1000.1111 1111.0000 0000
192.1010 1000.1111 1111.0000 0001
255.255.255.0
Subnet Mask
255.255.255.0
192.1010 1000.0000 0001.1111 1111
192.1010 1000.1111 1111.1111 1111
10
The table2-2 shows the subnetted block of 192.168.0.0/16 which was reserved for LAN
development. Several /24 subnets were reserved for Client and Management VLAN’s. A
dedicated 192.168.250.0/24 subnet was further subnetted to /27 subnets to establish
EIGRP connectivity between the distribution layer and the core layer among different
sites. As a /27 subnet can host up to 30 IP’s it can scale the site distribution layer to
connect 30 distribution layer 3 switches or routers.
2.3
Hardware & IOS
Several devices and IOS’s were used at different layers of the hierarchical design and the
Cisco 3640 routers were upgraded from 11.2 IOS version to 12.2 IOS version to allow
advance CLI features. The following table 2-3 shows the hardware and IOS version used
to implement the prototype.
Table 2-3 Hardware And IOS/Software Version
Hardware
Catalyst 6500 Sup 720
Cisco 3640
Cisco 2950
HP G3 Server
2.4
IOS Version
12.2(33)SXH5
12.2(27)
12.1(22)
Win 2003 Server
Cisco Secure ACS 4.2
Implementation Of Distribution Layer At Site1
The distribution layer is the demarcation point between the access and core layer and help
to define and differentiate the core. In a site or campus design, the distribution layer can
include several functions such as address or area aggregation, workgroup access,
broadcast/multicast domain definitions, VLAN routing, and security [3].
11
A pair of redundant, Catalyst 6509 Layer3, switches are integrated as distribution layer
switches. As shown in Figure2-3, these switches are configured with an IP address from
a dedicated management VLAN 50 to provide management connectivity.
Figure 2-3 Management VLAN Connectivity
A dedicated Network Management Switch (NMS) is configured to provide separate
management connectivity for all devices in a campus LAN. The links are configured as
access links and no other VLAN is allowed except the management VLAN 50.
The Tables 2-4 and 2-5 shows the configuration of the Distribution and the NMS
switches. A subnet 192.168.1.0/24 is reserved to provide management connectivity.
Table 2-4 Management Connectivity At Distribution Layer
Distribution Switch 1
!
vlan 50
name AJ_Lab_Mgmt_Vlan
!
Distribution Switch2
!
vlan 50
name AJ_Lab_Mgmt_Vlan
!
12
interface Vlan50
description AJ_Lab_Mgmt_Vlan
ip address 192.168.1.3 255.255.255.0
no ip redirects
standby 50 ip 192.168.1.1
standby 50 timers 1 3
standby 50 priority 10
standby 50 preempt
!
interface GigabitEthernet2/2
description NMS_Port0/1
no ip address
switchport
switchport access vlan 50
switchport mode access
end
interface Vlan50
description AJ_Lab_Mgmt_Vlan
ip address 192.168.1.2 255.255.255.0
no ip redirects
standby 50 ip 192.168.1.1
standby 50 timers 1 3
standby 50 priority 15
standby 50 preempt
!
interface GigabitEthernet7/2
description NMS_Port0/2
no ip address
switchport
switchport access vlan 50
switchport mode access
end
Table 2-5 Configuring Management VLAN On NMS
Network Management Switch
!
vlan 50
name AJ_Lab_Mgmt_Vlan
!
interface Vlan50
ip address 192.168.1.5 255.255.255.0
no ip route-cache
!
interface GigabitEthernet0/1
switchport access vlan 50
switchport mode access
!
interface GigabitEthernet0/2
switchport access vlan 50
switchport mode access
end
Test: Connectivity Test from NMS to DS1 and DS2
Result: 100%Ping Success Rate to the interfaces on DS1 and DS2.
NMS#ping 192.168.1.2
Type escape sequence to abort.
13
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/203/1012 ms
NMS#ping 192.168.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/200/1000 ms
NMS#
To provide 100% network uptime for any given VLAN, HSRP is implementing and a
Virtual IP 192.168.1.1 is configured as a sharing IP between the two distribution
switches. For each VLAN, distribution switch is either Active or Standby depending on
the priority. A priority value of 25 is configured as Active and a priority value of 10 is
configured as Standby. A group ID 50 is assigned to VLAN50 and the members of this
virtual group continuously exchange status messages. This way one device assumes the
routing responsibility of other, should it go out of communication.
An ether-channel, P01, as show in Figure 2-3 is configured between the two distribution
pair to serve as either a trunk to exchange VTP information or to serve as a high
availability link. The following configuration is applied to configure the Ether-Channel
and HSRP on distribution layer switches:
Distribution Switch 1
!
interface Vlan50
standby 50 ip 192.168.1.1
standby 50 timers 1 3
standby 50 priority 10
standby 50 preempt
!
!
interface Port-channel1
switchport
Distribution Switch2
!
interface Vlan50
standby 50 ip 192.168.1.1
standby 50 timers 1 3
standby 50 priority 25
standby 50 preempt
!
!
interface Port-channel1
switchport
14
switchport trunk encapsulation dot1q
switchport trunk native vlan 999
switchport trunk allowed vlan 2-9,1149,51-99,101-199,201-998,1000-4094
switchport mode trunk
storm-control broadcast level 0.50
end
!
interface GigabitEthernet2/3
description Back-To-Back Link DS2_6/3
channel-group 1 mode desirable
!
switchport trunk encapsulation dot1q
switchport trunk native vlan 999
switchport trunk allowed vlan 2-9,1149,51-99,101-199,201-998,1000-4094
switchport mode trunk
storm-control broadcast level 0.50
end
!
interface GigabitEthernet6/3
description Back-To-Back Link DS1_2/3
channel-group 1 mode desirable
!
Test: Ether-Channel Check on DS1 and DS2
Result: The output shows an Ether-Channel also called as Port-Channel P01 is created
with a Group ID 1 and the port 2/3 in DS1 and port 6/3 in DS2 are in port-channel 1.
DS1#sh etherchannel summary
Flags: D - down
P - in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use
f - failed to allocate aggregator
u - unsuitable for bundling
Number of channel-groups in use: 1
Number of aggregators:
1
Group Port-channel Protocol Ports
------+-------------+-----------+----------------------------------------------1
Po1(SU)
PAgP
Gi2/3(P)
DS1#
DS2#sh etherchannel summary
Flags: D - down
P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use
N - not in use, no aggregation
f - failed to allocate aggregator
M - not in use, no aggregation due to minimum links not met
15
m - not in use, port not aggregated due to minimum links not met
u - unsuitable for bundling
d - default port
w - waiting to be aggregated
Number of channel-groups in use: 1
Number of aggregators:
1
Group Port-channel Protocol Ports
------+-------------+-----------+----------------------------------------------1
Po1(SU)
PAgP
Gi6/3(P)
Test: Active & Standby test for HSRP at DS1 and DS2
Result: 100% ping result from NMS to Virtual IP 192.168.1.1 configured on DS1 and
DS2. Secondly, DS1 should be standby and DS2 as Active for VLAN 50.
NMS#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/12 ms
DS1#sh standby br
P indicates configured to preempt.
|
Interface Grp Prio P State Active addr Standby addr Group addr
Vl50
50 10 P Standby 192.168.1.2 local
192.168.1.1
DS1#
DS2#sh standby br
P indicates configured to preempt.
|
Interface Grp Prio P State Active
Standby
Virtual IP
Vl50
50 25 P Active local
192.168.1.3 192.168.1.1
DS2#
Test: HSRP Failover - Shutdown interface vlan 50 on DS2
Result: DS1 should become active and the Virtual IP should be reachable.
16
Distribution Switch 2
DS2(config)#int vlan 50
DS2(config-if)#shut
DS2(config-if)#
10w2d: %HSRP-5-STATECHANGE:
Vlan50 Grp 50 state Active -> Init
Distribution Switch 1
10w2d: %STANDBY-6STATECHANGE: Vlan50 Group 50 state
Standby -> Active
As interface VLAN 50 is shut on DS2, a message a generated on DS2 and DS1 about the
change of state. Observe the State change from Standby to Active on DS1.
DS1#sh stan br
P indicates configured to preempt.
|
Interface Grp Prio P State Active addr Standby addr Group addr
Vl50
50 10 P Active local
unknown
192.168.1.1
DS1#
DS2#sh standby br
P indicates configured to preempt.
|
Interface Grp Prio P State Active
Standby
Virtual IP
Vl50
50 25 P Init unknown
unknown
192.168.1.1
DS2#
Ping the Virtual IP interface which is active on DS1 from NMS.
Result: 100% Ping Success Rage.
NMS#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
NMS#
2.5
Implementation Of Access Layer At Site1
Access Layer is the layer where clients are connected or where local users are allowed
into the network. A Cisco 2950 switch is installed and commissioned as an Access Layer
switch. As shown in Figure 2-4, two fibre Gigabit Ethernet links one to each Distribution
17
Layer Switch are connected and configured as Trunks and a Fast Ethernet connection to
NMS for Network Management Access to the switch.
G6/3
G2/3
G2/2
G7/1
G2/1
G7/2
Distribution-Switch 2
6509
Distribution-Switch 1
6509
G0/1
G0/2
TRUNK
TRUNK
Fa0/5
G0/1
NMS
2950
G0/2
Fa0/5
NMS Connectivity
AS1
2950
Figure 2-4 Layer1 - Connectivity
An unused IP from the management subnet 192.168.1.0/24 is used to configure the access
switch for management connectivity. A client Vlan10 is created and a subnet
192.168.3.0/24 is allocated for this Vlan. Layer 3 interfaces for Vlan10 are created on
DS1 and DS2 with the first IP address 192.168.3.1 configured as Virtual IP. This virtual
IP will act as default gateway to the clients. As shown in Figure 2-5, to segregates the
management and the client traffic, the VLAN 10 is allowed through the uplink trunks to
the distribution layer switches and the management VLAN 50 is allowed through the FE
link to NMS.
18
P01
P01
G7/1
G2/2
G2/1
Distribution-Switch 1
6509
Managment VLAN50
Access VLAN10
G7/2
Distribution-Switch 2
6509
192.168.1.0/24
192.168.3.0/24
Client Traffic
NMS
2950
Management Traffic
Access-Switch 1
2950
Client
A
Client
B
Figure 2-5 Segregation of Management and Client VLANs
The table 2-6 shows the configuration and the connectivity to the Access Layer switch.
Table 2-6 Configuring Access Layer Network Element
!
vlan 10
name AJ_Lab_Client_Vlan10
!
vlan 50
name AJ_Lab_Mgmt_Vlan
!
vlan 999
name AJ_Lab_Native_Vlan
!
interface Vlan50
description Management Connectivity
19
ip address 192.168.1.4 255.255.255.0
no ip route-cache
!
interface FastEthernet0/5
description NMS _Fa0/5
switchport access vlan 50
switchport mode access
no ip address
!
interface GigabitEthernet0/1
description DS1_G2/1
switchport trunk native vlan 999
switchport trunk allowed vlan 10
switchport mode trunk
no ip address
!
interface GigabitEthernet0/2
description DS2_G7/1
switchport trunk native vlan 999
switchport trunk allowed vlan 10
switchport mode trunk
no ip address
!
!
interface FastEthernet0/10
description Client A
switchport access vlan 10
switchport mode access
no ip address
!
ip default-gateway 192.168.1.1
!
Configuring the interface Fa0/5 on NMS connected to the AS1.
!
interface FastEthernet0/5
switchport access vlan 50
switchport mode access
!
20
Configuring the VLAN’s and the Layer 3 interfaces on DS1 and DS2 and allowing the
VLAN 10 through the trunk facing AS1.
Distribution Switch 1
!
vlan 10
name AJ_Lab_Client_Vlan10
!
!
interface Vlan10
description Client VLAN
ip address 192.168.3.3 255.255.255.0
no ip redirects
standby 10 ip 192.168.3.1
standby 10 timers 1 3
standby 10 priority 25
standby 10 preempt
!
!
interface GigabitEthernet2/1
description connected to AS1_G0/1
no ip address
switchport
switchport trunk encapsulation dot1q
switchport trunk native vlan 999
switchport trunk allowed vlan 10
switchport mode trunk
end
Distribution Switch 2
!
vlan 10
name AJ_Lab_Client_Vlan10
!
!
interface Vlan10
description Client VLAN
ip address 192.168.3.2 255.255.255.0
no ip redirects
standby 10 ip 192.168.3.1
standby 10 timers 1 3
standby 10 priority 15
standby 10 preempt
!
!
interface GigabitEthernet7/1
description connected to AS1_G0/2
no ip address
switchport
switchport trunk encapsulation dot1q
switchport trunk native vlan 999
switchport trunk allowed vlan 10
switchport mode trunk
end
By the end of the above configuration the access switch should be able to ping the NMS
gateway 192.168.1.1 which is a Virtual IP on VLAN 50 and it should also be able to ping
the client gateway 192.168.3.1 which is a Virtual IP on VLAN 10.
Test: Ensure that the physical interfaces G0/1, G0/2 and Fa0/5 on AS1 connected to
Distribution Switches and the Management Switch are UP.
Result: All interfaces should be UP.
SW2#sh ip int br | i up
Vlan50
192.168.1.4
YES NVRAM up
up
21
FastEthernet0/5
GigabitEthernet0/1
GigabitEthernet0/2
SW2#
unassigned
YES unset up
unassigned
YES unset up
unassigned
YES unset up
up
up
up
Test: Ensure that Layer 3 interfaces for Management VLAN is reachable
Result: The success rate should be 100%
SW2#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
SW2#
Test: Ensure that Layer 3 interfaces for Client VLAN is reachable
Result: The success rate should be 100%
SW2#ping 192.168.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/8 ms
SW2#
Test: Ensure that DS1 is in Active State and DS2 in Standby State for VLAN 10
Result: VLAN 10 should be Active on DS1 and Standby on DS2
DS1#sh stan br
P indicates configured to preempt.
|
Interface Grp Prio P State Active addr Standby addr Group addr
Vl10
10 25 P Active local
192.168.3.2 192.168.3.1
Vl50
50 10 P Standby 192.168.1.2 local
192.168.1.1
DS1#
DS2#sh stan br
P indicates configured to preempt.
|
22
Interface Grp Prio P State Active
Standby
Vl10
10 15 P Standby 192.168.3.3 local
Vl50
50 25 P Active local
192.168.1.3
DS2#
Virtual IP
192.168.3.1
192.168.1.1
Test: Shutdown the interface VLAN 10 on DS1 and ensure that HSRP failover works for
Client VLAN 10.
Result: The ping success rate to virtual IP should be 100% and DS2 should be Active
HSRP gateway.
DS1(config)#int vlan 10
DS1(config-if)#shut
DS2#
10w2d: %HSRP-5-STATECHANGE:
Vlan10 Grp 10 state Standby -> Active
10w2d: %STANDBY-6STATECHANGE: Vlan10 Group 10 state
Active -> Init
DS2#sh stan br
P indicates configured to preempt.
|
Interface Grp Prio P State Active
Standby
Vl10
10 15 P Active local
unknown
Vl50
50 25 P Active local
192.168.1.3
DS2#
Virtual IP
192.168.3.1
192.168.1.1
Ping result from AS1 to Virtual IP 192.168.3.1
SW2#ping 192.168.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/8 ms
SW2#
Connect a client to one of the ports on AS1. Ensure that the default gateway is reachable
from the client.
23
C:\Users\aj>ipconfig
Connection-specific DNS Suffix . :
IPv4 Address. . . . . . . . . . . : 192.168.3.10
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.3.1
C:\Users\aj>ping 192.168.3.1
Pinging 192.168.3.1 with 32 bytes of data:
Reply from 192.168.3.1: bytes=32 time<1ms TTL=255
Reply from 192.168.3.1: bytes=32 time<1ms TTL=255
Reply from 192.168.3.1: bytes=32 time<1ms TTL=255
Reply from 192.168.3.1: bytes=32 time<1ms TTL=255
Ping statistics for 192.168.3.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\Users\aj>
With the successful integration of access switch and also connectivity of clients to the
layer 3 interface or gateway, the access layer can be extended by any number of access
layer switches from the distribution layer.
2.6
Implementation Of Core Layer At Site1
The core layer is a high-speed switching backbone and should be designed to switch
packets as fast as possible [3]. The figure 2-6 shows the layer1 lab core design
connectivity which comprises of two Cisco 3640 routers integrated at each site. It also
includes two layer 3 switches as core switches to integrate distribution layer with the core
layer. Two VLAN, VLAN 100 and VLAN 200 with /27 subnets are used to provide
redundant connections between distribution and core layer. Figure 2-7 shows the layer2
connectivity of LAN100 and VLAN200. A dynamic routing protocol EIGRP is used as
24
the routing protocol as it provides fast convergence with minimum network traffic and
scales effectively in a well-designed network.
Fa1/0
Fa1/0.1 .2
Fa1/0.2 .68
Fa1/0
Fa1/0.1 .3
Fa1/0.2 .69
Lo=192.168.5.1
.34
Fa2/0
Lo=192.168.5.2
Fa2/0 .35
Core B
3640
Core A
3640
G0/4
G0/3
G0/2
G0/1
Core-SW1
3560
EIGRP
AS 10
Fa0/3
Fa0/4
G0/1
G0/2
Core-SW2
3550
Access
G1/2
G1/1 .4
Lo=192.168.5.3
.36
Distribution-Switch 1
6509
G6/2
.5
G6/1 .37
Lo=192.168.5.4
Distribution-Switch 2
6509
Figure 2-6 Integration of Distribution and Core Layer
Redundant fibre up links from the distribution layers switches are connected to the core
switches. The core switch, Core-SW1, allow traffic for VLAN 100 with a subnet
192.168.250.0/27 and the core switch, Core-SW2, allows traffic for VLAN 200 with a
subnet 192.168.250.32/27. Layer 3 interfaces for these VLAN’s are created at the core
routers A and B. A subnet 192.168.5.0/24 is reserved for loopback interfaces to allow
devices to participate in the EIGRP process.
25
Fa1/0
Fa1/0.1 .2
Fa1/0.2 .68
Lo=192.168.5.2
Lo=192.168.5.1
Fa2/0
Fa1/0
Fa1/0.1 .3
Fa1/0.2 .69
.34
Core A
3640
Fa2/0
.35
Core B
3640
Access VLAN200 192.168.250.32/27
Access VLAN100 192.168.250.0/27
G1/1
.4
G1/2
.36
Lo=192.168.5.3
G6/2 .5
G6/1
.37
Lo=192.168.5.4
Distribution-Switch 1
6509
Distribution-Switch 2
6509
Figure 2-7 Core VLAN’s
The implementation of the core layer is initiated with the integration of the core switches.
The Gigabit Ethernet links facing the distribution layer switches are configured as access
links to avoid VLANs exchanging over the link and being forwarded to core. The core
switches are configured as below:
Core-SW1
!
vlan 100
name AJ_Lab_Core_Vlan_A
!
interface GigabitEthernet0/1
description Distribution-SW1_G1/1
switchport access vlan 100
switchport mode access
!
interface GigabitEthernet0/2
Core-SW2
!
vlan 200
name AJ_Lab_Core_Vlan_B
!
interface GigabitEthernet0/1
description Distribution-SW1_G1/2
switchport access vlan 200
switchport mode access
!
interface GigabitEthernet0/2
26
description Distribution-SW2_G6/2
switchport access vlan 100
switchport mode access
!
interface GigabitEthernet0/3
description Core-A_Fa1/0.1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 30,100
switchport mode trunk
!
interface GigabitEthernet0/4
description Core-B_Fa1/0.1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 30,100
switchport mode trunk
!
description Distribution-SW2_G6/1
switchport access vlan 200
switchport mode access
!
interface FastEthernet0/3
description Core-A_Fa2/0
switchport access vlan 200
switchport mode access
no ip address
!
interface FastEthernet0/4
description Core-B_Fa2/0
switchport access vlan 200
switchport mode access
no ip address
!
Now that the core switches and their interfaces are configured the next step is to
configure the core routers and the layer 3 interfaces on them. The core routers are
configured as:
Core Router A
!
interface Loopback0
ip address 192.168.5.1 255.255.255.255
!
!
interface FastEthernet1/0.1
encapsulation dot1Q 100
ip address 192.168.250.2
255.255.255.224
!
interface FastEthernet1/0.2
encapsulation dot1Q 30
ip address 192.168.250.68
255.255.255.224
!
interface FastEthernet2/0
ip address 192.168.250.34
255.255.255.224
duplex auto
speed auto
Core Router B
!
interface Loopback0
ip address 192.168.5.2 255.255.255.255
!
!
interface FastEthernet1/0.1
encapsulation dot1Q 100
ip address 192.168.250.3
255.255.255.224
!
interface FastEthernet1/0.2
encapsulation dot1Q 30
ip address 192.168.250.69
255.255.255.224
!
interface FastEthernet2/0
ip address 192.168.250.35
255.255.255.224
duplex auto
speed auto
27
!
!
Perform check to ensure that the link between the core switches and the core routers is
established.
Core-SW1#sh ip int br
Interface
IP-Address
OK? Method Status
Protocol
Vlan1
unassigned
YES unset administratively down down
Vlan100
192.168.250.1 YES manual up
up
GigabitEthernet0/3 unassigned
YES unset up
up
GigabitEthernet0/4 unassigned
YES unset up
up
Core-SW2#sh ip int br
Interface
IP-Address
OK? Method Status
Protocol
Vlan1
unassigned
YES NVRAM administratively down down
Vlan200
192.168.250.33 YES manual up
up
FastEthernet0/3
unassigned
YES unset up
up
FastEthernet0/4
unassigned
YES unset up
up
Core-R1#sh ip int br
Interface
IP-Address
OK? Method Status
Protocol
FastEthernet1/0
unassigned
YES NVRAM up
up
FastEthernet1/0.1
192.168.250.2 YES NVRAM up
up
FastEthernet1/0.2
192.168.250.68 YES NVRAM up
up
FastEthernet2/0
192.168.250.34 YES NVRAM up
up
FastEthernet3/0
172.16.1.1
YES NVRAM administratively down down
Loopback0
192.168.5.1 YES NVRAM up
up
Core-R1#
Core-R2#sh ip int br
Interface
IP-Address
OK? Method Status
Protocol
FastEthernet1/0
unassigned
YES NVRAM up
up
FastEthernet1/0.1
192.168.250.3 YES NVRAM up
up
FastEthernet1/0.2
192.168.250.69 YES NVRAM up
up
FastEthernet2/0
192.168.250.35 YES NVRAM up
up
Loopback0
192.168.5.2 YES NVRAM up
up
Core-R2#
Ensure that the default gateway is reachable from the core switches.
Core-SW1#ping 192.168.250.2
Type escape sequence to abort.
28
Sending 5, 100-byte ICMP Echos to 192.168.250.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/9 ms
Core-SW1#ping 192.168.250.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/203/1006 ms
Core-SW1#
Core-SW2#ping 192.168.250.34
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.34, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Core-SW2#ping 192.168.250.35
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.35, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/200/1000 ms
Core-SW2#
Ensure that the neighbor relationship is established between the core switches and the
core routers.
Core-SW1#sh cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID
Local Intrfce
Holdtme Capability Platform Port ID
Core-R1
Gig 0/3
145
R
3640
Fas 1/0
Core-R2
Gig 0/4
121
R
3640
Fas 1/0
Core-SW1#
ore-SW2#sh cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID
Core-R1
Core-R2
Core-SW2#
Local Intrfce Holdtme Capability Platform Port ID
Fas 0/3
161
R
3640
Fas 2/0
Fas 0/4
137
R
3640
Fas 2/0
29
Configure the distribution layer3 switches to integrate with core. Redundant uplinks from
each distribution pair is configured one in each core VLANs 100 and 200.
Distribution – Switch 1
!
vlan 100
name AJ_Lab_Core_Vlan_A
!
vlan 200
name AJ_Lab_Core_Vlan_B
!
interface Vlan100
ip address 192.168.250.4
255.255.255.224
!
interface Vlan200
ip address 192.168.250.36
255.255.255.224
!
interface Loopback0
ip address 192.168.5.3 255.255.255.255
!
interface GigabitEthernet1/1
no ip address
switchport
switchport access vlan 100
switchport mode access
!
interface GigabitEthernet1/2
no ip address
switchport
switchport access vlan 200
switchport mode access
!
Distribution – Switch 2
!
vlan 100
name AJ_Lab_Core_Vlan_A
!
vlan 200
name AJ_Lab_Core_Vlan_B
!
interface Vlan100
ip address 192.168.250.5
255.255.255.224
!
interface Vlan200
ip address 192.168.250.37
255.255.255.224
!
interface Loopback0
ip address 192.168.5.4 255.255.255.255
!
interface GigabitEthernet6/1
switchport
switchport access vlan 200
switchport mode access
storm-control broadcast level 0.50
!
interface GigabitEthernet6/2
switchport
switchport access vlan 100
switchport mode access
storm-control broadcast level 0.50
!
Once the distribution layer switches are advertised in core VLANs, the core and
distribution layer should establish reachability. Ping check is performed between
distribution pair and the core to ensure reachability.
Ping checks for core interfaces in VLAN 100 from DS1 and DS2:
30
DS1#ping 192.168.250.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
DS1#
DS1#ping 192.168.250.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
DS1#
DS2#ping 192.168.250.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
DS2#ping 192.168.250.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
DS2#
Ping checks for core interfaces in VLAN 200 from DS1 and DS2:
DS1#ping 192.168.250.34
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.34, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
DS1#
DS1#ping 192.168.250.35
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.35, timeout is 2 seconds:
!!!!!
31
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
DS1#
DS2#ping 192.168.250.34
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.34, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
DS2#ping 192.168.250.35
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.35, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
DS2#
The above test ensures that the connectivity is established between the core and the
distribution layer and that the distribution layer has redundant connections to the core.
However, the end-to-end reachability from access layer to core is not yet established.
To establish end-to-end connectivity, the next step is to advertise the access VLAN into
core. This can be done via static or dynamic routing.
In an enterprise LAN environment, as there are hundreds of access VLAN’s, static routes
is not a scalable solution to implement. It will be laborious and hard to manage hundreds
of static routes. The feasible solution would be to configure a dynamic routing protocol.
2.7
Configuring EIGRP
Enhanced Interior Gateway Routing Protocol (EIGRP) is a dynamic routing protocol
developed by Cisco. EIGRP scales effectively in a well-designed network and provides
extremely quick convergence times with minimal network traffic [4].
An EIGRP process is identified by an autonomous system (AS) number so that routers
with the same AS numbers will exchange routing information with each other, resulting
32
in a routing domain. As the network prototype is implemented with two sites A and B,
these sites are assigned with unique AS numbers 10 and 20. Within the EIGRP process,
only the dedicated networks are advertised. Like any other routing protocol, EIGRP uses
route metric (Bandwidth, Delay, Reliability, Load and MTU) to select the best route form
a group of possible routes. The route metrics configured are Bandwidth= 100000, Delay
= 100, Reliability=255, Load=1 and MTU=1500.
The core and the distribution routers of Site1 are configured as follows:
Core-R1#sh run | b eigrp
router eigrp 10
network 192.168.5.1 0.0.0.0
network 192.168.250.0 0.0.0.31
network 192.168.250.32 0.0.0.31
network 192.168.250.64 0.0.0.31
default-metric 100000 100 255 1 1500
no auto-summary
DS1#sh run | b eigrp
router eigrp 10
passive-interface default
no passive-interface Vlan100
no passive-interface Vlan200
network 192.168.1.0
network 192.168.3.0
network 192.168.5.3 0.0.0.0
network 192.168.250.0 0.0.0.31
network 192.168.250.32 0.0.0.31
network 192.168.250.64 0.0.0.31
no auto-summary
eigrp log-neighbor-changes
!
Core-R2#sh run | b eigrp
router eigrp 10
network 192.168.5.2 0.0.0.0
network 192.168.250.0 0.0.0.31
network 192.168.250.32 0.0.0.31
network 192.168.250.64 0.0.0.31
default-metric 100000 100 255 1 1500
no auto-summary
!
DS2#sh run | b eigrp
router eigrp 10
passive-interface default
no passive-interface Vlan100
no passive-interface Vlan200
network 192.168.1.0
network 192.168.3.0
network 192.168.5.4 0.0.0.0
network 192.168.250.0 0.0.0.31
network 192.168.250.32 0.0.0.31
network 192.168.250.64 0.0.0.31
no auto-summary
eigrp log-neighbor-changes
When the devices are configured and the networks are advertised in the EIGRP process,
as a part of neighbor discovery process, the EIGRP routers sent hello packets to their
33
connected networks using multicast address 224.0.0.10.
The figure 2-8 shows the
convergence process between two EIGRP routers [5].
Figure 2-8 Discovering Routes
The following messages were captured on DS1 during the neighbor discovery process.
DS1 becomes adjacent with Core1, Core2 and DS2 via VLAN100 through subnet
192.168.250.0/27 and also via VLAN 200 through subnet 192.168.250.32/27.
10w4d: %DUAL-5-NBRCHANGE: IP-EIGRP 10: Neighbor 192.168.250.2 (Vlan100)
is up: new adjacency
10w4d: %DUAL-5-NBRCHANGE: IP-EIGRP 10: Neighbor 192.168.250.35
(Vlan200) is up: new adjacency
10w4d: %DUAL-5-NBRCHANGE: IP-EIGRP 10: Neighbor 192.168.250.3 (Vlan100)
is up: new adjacency
10w4d: %DUAL-5-NBRCHANGE: IP-EIGRP 10: Neighbor 192.168.250.5 (Vlan100)
is up: new adjacency
10w4d: %DUAL-5-NBRCHANGE: IP-EIGRP 10: Neighbor 192.168.250.37
(Vlan200) is up: new adjacency
10w4d: %DUAL-5-NBRCHANGE: IP-EIGRP 10: Neighbor 192.168.250.34
34
(Vlan200) is up: new adjacency
Once a neighbor is discovered via the hello packet, a neighbor table is created which
keeps the state information of the adjacent neighbors. When newly discovered neighbors
are learned, the address and the interface of the neighbors are recorded. The following
table gives the neighbor table of Core1, Core2, DS1 and DS2.
Core-R1#sh ip eigrp neighbors
IP-EIGRP neighbors for process 10
H Address
Interface Hold Uptime SRTT RTO Q Seq Type
(sec)
(ms)
Cnt Num
6 192.168.250.35
Fa2/0
14 17:23:52 4 200 0 80
4 192.168.250.37
Fa2/0
13 17:23:52 3 200 0 28
1 192.168.250.36
Fa2/0
10 17:23:54 1 200 0 24
2 192.168.250.5
Fa1/0.1
11 17:59:56 1 200 0 29
0 192.168.250.4
Fa1/0.1
12 18:00:50 1 200 0 23
5 192.168.250.3
Fa1/0.1
11 3d00h
1 200 0 79
Core-R1#
Core-R2#sh ip eigrp neighbors
IP-EIGRP neighbors for process 10
H Address
Interface Hold Uptime SRTT RTO Q Seq Type
(sec)
(ms)
Cnt Num
2 192.168.250.34
Fa2/0
13 17:24:22 1568 5000 0 695
6 192.168.250.37
Fa2/0
10 18:00:26 4 200 0 28
4 192.168.250.5
Fa1/0.1
14 18:00:26 2 200 0 29
1 192.168.250.36
Fa2/0
13 18:01:20 4 200 0 24
0 192.168.250.4
Fa1/0.1
10 18:01:20 1 200 0 23
5 192.168.250.2
Fa1/0.1
12 3d00h
37 222 0 696
Core-R2#
DS1#sh ip eigrp nei
IP-EIGRP neighbors for process 10
H Address
Interface Hold Uptime SRTT RTO Q Seq Type
(sec)
(ms)
Cnt Num
0 192.168.250.34
Vl200
10 17:14:21 57 342 0 695
5 192.168.250.37
Vl200
13 17:50:25 3 200 0 28
4 192.168.250.5
Vl100
14 17:50:25 2 200 0 29
3 192.168.250.3
Vl100
12 17:51:19 490 2940 0 79
2 192.168.250.35
Vl200
14 17:51:20 868 5000 0 80
1 192.168.250.2
Vl100
12 17:51:20 316 1896 0 696
DS1#
DS2#sh ip eigrp neighbors
35
IP-EIGRP neighbors for process 10
H Address
Interface
Hold Uptime SRTT RTO Q Seq
(sec)
(ms)
Cnt Num
1 192.168.250.34
Vl200
13 17:24:56 1053 5000 0 695
5 192.168.250.2
Vl100
12 18:00:58 1 200 0 696
4 192.168.250.35
Vl200
14 18:00:58 1 200 0 80
3 192.168.250.3
Vl100
11 18:00:58 1 200 0 79
2 192.168.250.4
Vl100
11 18:00:59 224 1344 0 23
0 192.168.250.36
Vl200
13 18:01:00 454 2724 0 24
DS2#
Once the EIGPR neighbor table is created, the routers send an update containing all of the
routes that they know about to the neighbor. This information is stored in the topology
table. The following table shows the topology table of the EIGRP routers.
Core-R1#sh ip eigrp topology
IP-EIGRP Topology Table for AS(10)/ID(192.168.5.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 192.168.250.128/27, 1 successors, FD is 51200, tag is 200
via Redistributed (51200/0)
P 192.168.5.4/32, 2 successors, FD is 156160
via 192.168.250.37 (156160/128256), FastEthernet2/0
via 192.168.250.5 (156160/128256), FastEthernet1/0.1
P 192.168.1.0/24, 4 successors, FD is 28416
via 192.168.250.37 (28416/2816), FastEthernet2/0
via 192.168.250.5 (28416/2816), FastEthernet1/0.1
via 192.168.250.4 (28416/2816), FastEthernet1/0.1
via 192.168.250.36 (28416/2816), FastEthernet2/0
P 192.168.3.0/24, 4 successors, FD is 28416
via 192.168.250.37 (28416/2816), FastEthernet2/0
via 192.168.250.5 (28416/2816), FastEthernet1/0.1
via 192.168.250.4 (28416/2816), FastEthernet1/0.1
via 192.168.250.36 (28416/2816), FastEthernet2/0
P 192.168.5.1/32, 1 successors, FD is 128256
via Connected, Loopback0
P 192.168.5.3/32, 2 successors, FD is 156160
via 192.168.250.36 (156160/128256), FastEthernet2/0
via 192.168.250.4 (156160/128256), FastEthernet1/0.1
36
P 192.168.5.2/32, 3 successors, FD is 156160
via 192.168.250.35 (156160/128256), FastEthernet2/0
via 192.168.250.69 (156160/128256), FastEthernet1/0.2
via 192.168.250.3 (156160/128256), FastEthernet1/0.1
P 192.168.250.0/27, 1 successors, FD is 28160
via Connected, FastEthernet1/0.1
via 192.168.250.37 (28416/2816), FastEthernet2/0
via 192.168.250.36 (28416/2816), FastEthernet2/0
P 192.168.250.32/27, 1 successors, FD is 28160
via Connected, FastEthernet2/0
via 192.168.250.4 (28416/2816), FastEthernet1/0.1
via 192.168.250.5 (28416/2816), FastEthernet1/0.1
P 172.16.1.8/30, 3 successors, FD is 53760
via 192.168.250.35 (53760/51200), FastEthernet2/0
via 192.168.250.3 (53760/51200), FastEthernet1/0.1
via 192.168.250.69 (53760/51200), FastEthernet1/0.2
P 172.16.1.4/30, 1 successors, FD is 51200
via Redistributed (51200/0)
P 192.168.250.64/27, 1 successors, FD is 28160
via Connected, FastEthernet1/0.2
P 192.168.250.96/27, 1 successors, FD is 51200, tag is 200
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
via Redistributed (51200/0)
Core-R1#
Core-R2#sh ip eigrp topology
IP-EIGRP Topology Table for AS(10)/ID(192.168.5.2)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 192.168.250.128/27, 3 successors, FD is 53760, tag is 200
via 192.168.250.34 (53760/51200), FastEthernet2/0
via 192.168.250.2 (53760/51200), FastEthernet1/0.1
via 192.168.250.68 (53760/51200), FastEthernet1/0.2
P 192.168.5.4/32, 2 successors, FD is 156160
via 192.168.250.37 (156160/128256), FastEthernet2/0
via 192.168.250.5 (156160/128256), FastEthernet1/0.1
P 192.168.1.0/24, 4 successors, FD is 28416
via 192.168.250.37 (28416/2816), FastEthernet2/0
via 192.168.250.36 (28416/2816), FastEthernet2/0
via 192.168.250.4 (28416/2816), FastEthernet1/0.1
37
via 192.168.250.5 (28416/2816), FastEthernet1/0.1
P 192.168.3.0/24, 4 successors, FD is 28416
via 192.168.250.37 (28416/2816), FastEthernet2/0
via 192.168.250.36 (28416/2816), FastEthernet2/0
via 192.168.250.4 (28416/2816), FastEthernet1/0.1
via 192.168.250.5 (28416/2816), FastEthernet1/0.1
P 192.168.5.1/32, 3 successors, FD is 156160
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
via 192.168.250.34 (156160/128256), FastEthernet2/0
via 192.168.250.2 (156160/128256), FastEthernet1/0.1
via 192.168.250.68 (156160/128256), FastEthernet1/0.2
P 192.168.5.3/32, 2 successors, FD is 156160
via 192.168.250.36 (156160/128256), FastEthernet2/0
via 192.168.250.4 (156160/128256), FastEthernet1/0.1
P 192.168.5.2/32, 1 successors, FD is 128256
via Connected, Loopback0
P 192.168.250.0/27, 1 successors, FD is 28160
via Connected, FastEthernet1/0.1
via 192.168.250.37 (28416/2816), FastEthernet2/0
via 192.168.250.36 (28416/2816), FastEthernet2/0
P 192.168.250.32/27, 1 successors, FD is 28160
via Connected, FastEthernet2/0
via 192.168.250.5 (28416/2816), FastEthernet1/0.1
via 192.168.250.4 (28416/2816), FastEthernet1/0.1
P 172.16.1.8/30, 1 successors, FD is 51200
via Redistributed (51200/0)
P 172.16.1.4/30, 3 successors, FD is 53760
via 192.168.250.34 (53760/51200), FastEthernet2/0
via 192.168.250.2 (53760/51200), FastEthernet1/0.1
via 192.168.250.68 (53760/51200), FastEthernet1/0.2
P 192.168.250.64/27, 1 successors, FD is 28160
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
via Connected, FastEthernet1/0.2
P 192.168.250.96/27, 3 successors, FD is 53760, tag is 200
via 192.168.250.34 (53760/51200), FastEthernet2/0
via 192.168.250.2 (53760/51200), FastEthernet1/0.1
via 192.168.250.68 (53760/51200), FastEthernet1/0.2
Core-R2#
38
DS1#sh ip eigrp topology
IP-EIGRP Topology Table for AS(10)/ID(192.168.5.3)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 192.168.250.128/27, 2 successors, FD is 51456, tag is 200
via 192.168.250.2 (51456/51200), Vlan100
via 192.168.250.34 (51456/51200), Vlan200
P 192.168.5.4/32, 2 successors, FD is 130816
via 192.168.250.37 (130816/128256), Vlan200
via 192.168.250.5 (130816/128256), Vlan100
P 192.168.1.0/24, 1 successors, FD is 2816
via Connected, Vlan50
P 192.168.3.0/24, 1 successors, FD is 2816
via Connected, Vlan10
P 192.168.5.1/32, 2 successors, FD is 130816
via 192.168.250.2 (130816/128256), Vlan100
via 192.168.250.34 (130816/128256), Vlan200
P 192.168.5.3/32, 1 successors, FD is 128256
via Connected, Loopback0
P 192.168.5.2/32, 2 successors, FD is 130816
via 192.168.250.35 (130816/128256), Vlan200
via 192.168.250.3 (130816/128256), Vlan100
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 192.168.250.0/27, 1 successors, FD is 2816
via Connected, Vlan100
P 192.168.250.32/27, 1 successors, FD is 2816
via Connected, Vlan200
P 172.16.1.8/30, 2 successors, FD is 51456
via 192.168.250.35 (51456/51200), Vlan200
via 192.168.250.3 (51456/51200), Vlan100
P 172.16.1.4/30, 2 successors, FD is 51456
via 192.168.250.2 (51456/51200), Vlan100
via 192.168.250.34 (51456/51200), Vlan200
P 192.168.250.64/27, 4 successors, FD is 28416
via 192.168.250.34 (28416/28160), Vlan200
via 192.168.250.2 (28416/28160), Vlan100
via 192.168.250.3 (28416/28160), Vlan100
via 192.168.250.35 (28416/28160), Vlan200
P 192.168.250.96/27, 2 successors, FD is 51456, tag is 200
39
via 192.168.250.2 (51456/51200), Vlan100
via 192.168.250.34 (51456/51200), Vlan200
DS1#
DS2#sh ip eigrp topology
IP-EIGRP Topology Table for AS(10)/ID(192.168.5.4)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 192.168.250.128/27, 2 successors, FD is 51456, tag is 200
via 192.168.250.2 (51456/51200), Vlan100
via 192.168.250.34 (51456/51200), Vlan200
P 192.168.5.4/32, 1 successors, FD is 128256
via Connected, Loopback0
P 192.168.1.0/24, 1 successors, FD is 2816
via Connected, Vlan50
P 192.168.3.0/24, 1 successors, FD is 2816
via Connected, Vlan10
P 192.168.5.1/32, 2 successors, FD is 130816
via 192.168.250.2 (130816/128256), Vlan100
via 192.168.250.34 (130816/128256), Vlan200
P 192.168.5.3/32, 2 successors, FD is 130816
via 192.168.250.4 (130816/128256), Vlan100
via 192.168.250.36 (130816/128256), Vlan200
P 192.168.5.2/32, 2 successors, FD is 130816
via 192.168.250.3 (130816/128256), Vlan100
via 192.168.250.35 (130816/128256), Vlan200
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 192.168.250.0/27, 1 successors, FD is 2816
via Connected, Vlan100
P 192.168.250.32/27, 1 successors, FD is 2816
via Connected, Vlan200
P 172.16.1.8/30, 2 successors, FD is 51456
via 192.168.250.3 (51456/51200), Vlan100
via 192.168.250.35 (51456/51200), Vlan200
P 172.16.1.4/30, 2 successors, FD is 51456
via 192.168.250.2 (51456/51200), Vlan100
via 192.168.250.34 (51456/51200), Vlan200
P 192.168.250.64/27, 4 successors, FD is 28416
via 192.168.250.2 (28416/28160), Vlan100
via 192.168.250.3 (28416/28160), Vlan100
40
via 192.168.250.34 (28416/28160), Vlan200
via 192.168.250.35 (28416/28160), Vlan200
P 192.168.250.96/27, 2 successors, FD is 51456, tag is 200
via 192.168.250.2 (51456/51200), Vlan100
via 192.168.250.34 (51456/51200), Vlan200
DS2#
After the EIGRP routers get fully converged and the routing information is exchanged,
the access layer devices should now be able to reach the core layer devices. The
following table provides the routing table of one the core routers. The access layer routes
192.168.1.0 and 192.168.3.0 are shown in the routing table of Core-R1 that are learnt
from EIGRP neighbors and distribution switches 1 and 2 through VLAN’s 100 and 200.
Core-R1#sh ip ro
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
172.16.0.0/30 is subnetted, 2 subnets
D EX 172.16.1.8 [170/53760] via 192.168.250.69, 21:48:15, FastEthernet1/0.2
[170/53760] via 192.168.250.3, 21:48:15, FastEthernet1/0.1
[170/53760] via 192.168.250.35, 21:48:15, FastEthernet2/0
C
172.16.1.4 is directly connected, Serial0/2
192.168.250.0/27 is subnetted, 5 subnets
B
192.168.250.128 [20/0] via 172.16.1.6, 7w0d
C
192.168.250.0 is directly connected, FastEthernet1/0.1
C
192.168.250.32 is directly connected, FastEthernet2/0
C
192.168.250.64 is directly connected, FastEthernet1/0.2
B
192.168.250.96 [20/0] via 172.16.1.6, 7w0d
192.168.5.0/32 is subnetted, 4 subnets
D
192.168.5.4 [90/156160] via 192.168.250.5, 21:48:14, FastEthernet1/0.1
[90/156160] via 192.168.250.37, 21:48:14, FastEthernet2/0
C
192.168.5.1 is directly connected, Loopback0
D
192.168.5.3 [90/156160] via 192.168.250.4, 21:48:19, FastEthernet1/0.1
41
[90/156160] via 192.168.250.36, 21:48:19, FastEthernet2/0
D
192.168.5.2
[90/156160] via 192.168.250.69, 21:48:19, FastEthernet1/0.2
[90/156160] via 192.168.250.3, 21:48:19, FastEthernet1/0.1
[90/156160] via 192.168.250.35, 21:48:19, FastEthernet2/0
D 192.168.1.0/24 [90/28416] via 192.168.250.4, 21:48:17, FastEthernet1/0.1
[90/28416] via 192.168.250.5, 21:48:17, FastEthernet1/0.1
[90/28416] via 192.168.250.36, 21:48:17, FastEthernet2/0
[90/28416] via 192.168.250.37, 21:48:17, FastEthernet2/0
D 192.168.3.0/24 [90/28416] via 192.168.250.4, 21:48:17, FastEthernet1/0.1
[90/28416] via 192.168.250.5, 21:48:17, FastEthernet1/0.1
[90/28416] via 192.168.250.36, 21:48:19, FastEthernet2/0
[90/28416] via 192.168.250.37, 21:48:19, FastEthernet2/0
Core-R1#
A ping test is performed from access layer switch to the core routers to ensure end-to-end
connectivity.
Ping to core router interfaces in VLAN 100
SW2#ping 192.168.250.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/12 ms
SW2#
SW2#ping 192.168.250.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
SW2#
Ping to core router interfaces in VLAN 200
SW2#ping 192.168.250.34
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.34, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/8 ms
42
SW2#ping 192.168.250.35
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.35, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/8 ms
SW2#
2.8
Implementation Of Core Layer at Site2
To maintain consistency Site2 was designed similar to Site1 in hierarchical layers. The
core layer comprises of two routers and a core switch to connect the LAN distribution
layer. A VLAN 300 with subnet 192.168.250.96/27 is configured as a core VLAN for
Site2. Figure 2.9 shows the layer2 connectivity of the core devices.
Fa2/0
Fa2/0.1 .98
Lo=192.168.5.6
Lo=192.168.5.5
Fa2/0
Fa2/0.1 .99
Site2-Core B
3640
Site2-Core A
3640
Access VLAN200 192.168.250.32/27
Figure 2-9 Site2 Core VLAN
EIGRP is enabled between these two core routers and the core subnet is advertised in a
site specific EIGRP process 20. The following output is captured from the core routers
displaying the EIGRP neighbor relationship.
R5#sh ip eigrp nei
IP-EIGRP neighbors for process 20
H Address
Interface Hold Uptime SRTT RTO Q Seq Type
(sec)
(ms)
Cnt Num
0 192.168.250.99
Fa2/0.1
14 4w2d
1 200 0 57
43
R5#
R2#sh ip eigrp nei
IP-EIGRP neighbors for process 20
H Address
Interface Hold Uptime SRTT RTO Q Seq Type
(sec)
(ms)
Cnt Num
0 192.168.250.98
Fa2/0.1
11 4w2d
1 200 0 55
R2#
The site 2 was implemented with the scope of deploying TACACS+ servers at the core
layer switch. Hence, the VLAN 200 with /27 subnet will be open for future integration of
distribution layer through EIGRP process 20.
With the successful implementation of Site1 and Site2, a hierarchal network design is
maintained with a future scope of deploying and extending the entire sites. As the goal of
the project is to deploy a centralized TACACS+ environment by deploying a centralized
Master and regional Slave servers, the two regional sites, 1 and 2, need to be integrated
with WAN infrastructure.
2.9
Integration Of Site1 and Site2 Using WAN Links
In order to keep a simple WAN design, point-to-point serial links between core routers
were integrated. /30 subnets were used from the major 172.16.0.0/12 block which is
reserved for WAN infrastructure design. A BGP AS 100 is allocated to Site 1 and a BGP
AS 200 is allocated to Site2. The figure 2-10 shows the WAN design of the prototype. In
order to achieve end-to-end connectivity between two different sites mutual redistribution
of BGP and EIGRP between the sites is created.
44
SITE 1
SITE 2
Site1 – Core1
Site2 – Core1
S0/2
Lo=192.168.5.1
Fa3/0
172.16.1.4/30
S0/2
.6
.5
Fa3/0
.1
BGP 100
172.16.1.12/30
.2
Fa3/0 .14
S0/2
Lo=192.168.5.2
.13
BGP 200
172.16.1.0/30
Fa3/0
Lo=192.168.5.5
.9
Site1 – Core2
172.16.1.8/30
S0/2
.10
Lo=192.168.5.6
Site2 – Core2
Figure 2-10 WAN Connectivity between Site1 and Site2
A Fast Ethernet high availability core links between the site1 routers and also between
the site2 routers are established. WAN links between the core routers are configured as
follows.
A /30 subnet 172.16.1.4/30 is used for the link between Site1-Core1 and Site2-Core1 and
a /30 subnet 172.16.1.0/30 is used for the high availability link between site1 routers.
Site1-Core1
!
interface Serial0/2
ip address 172.16.1.5 255.255.255.252
no shut
!
!
interface FastEthernet3/0
ip address 172.16.1.1 255.255.255.252
duplex auto
speed auto
!
Site2-Core1
!
interface Serial0/2
ip address 172.16.1.6 255.255.255.252
no shut
!
45
The interfaces should be UP and the neighbors should be discovered. The following
output provides the interface status of Site1-Core1 and Site2-Core1.
Site1-Core1#sh ip int br | i up
Serial0/2
172.16.1.5
YES NVRAM up
FastEthernet1/0
unassigned
YES NVRAM up
FastEthernet1/0.1
192.168.250.2 YES NVRAM up
FastEthernet1/0.2
192.168.250.68 YES NVRAM up
FastEthernet2/0
192.168.250.34 YES NVRAM up
FastEthernet3/0
172.16.1.1
YES NVRAM up
Loopback0
192.168.5.1 YES NVRAM up
Site1-Core1#
up
up
up
up
up
up
up
Site1-Core1#sh cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID
Local Intrfce
Core-SW2
Fas 2/0
Core-SW1
Fas 1/0
Site2-Core1
Ser 0/2
Site1-Core2
Fas 3/0
Site1-Core1#
Holdtme Capability Platform Port ID
174
SI
WS-C3550-2Fas 0/3
135
SI
WS-C3560G-Gig 0/3
141
R
3640
Ser 0/2
141
R
3640
Fas 3/0
Site2-Core1#sh ip int br | i up
Serial0/2
172.16.1.6
YES NVRAM up
FastEthernet2/0
unassigned
YES NVRAM up
FastEthernet2/0.1
192.168.250.98 YES NVRAM up
FastEthernet2/0.2
192.168.250.130 YES NVRAM up
FastEthernet3/0
172.16.1.13 YES NVRAM up
Loopback0
192.168.5.5 YES NVRAM up
Site2-Core1#
up
up
up
up
up
up
Site2-Core1#sh cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID
Local Intrfce
Site2-Core-SW1 Fas 2/0
Site1-Core1
Ser 0/2
Site2-Core1#
Holdtme Capability Platform Port ID
123
SI
WS-C3560G-Gig 0/1
148
R
3640
Ser 0/2
46
Ping the far end interfaces to ensure the devices are reachable.
Site1-Core1#ping 172.16.1.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
Site1-Core1#
Site2-Core1#ping 172.16.1.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Site2-Core1#
Similarly the link between Site1-Core2 and Site2-Core2 is established using the subnet
172.16.1.8/30. The following configuration is applied on the routers.
Site1-Core2
!
interface Serial0/2
ip address 172.16.1.9 255.255.255.252
!
interface FastEthernet3/0
ip address 172.16.1.2 255.255.255.252
duplex auto
speed auto
!
Site2-Core2
!
interface Serial0/2
ip address 172.16.1.10 255.255.255.252
!
interface FastEthernet3/0
ip address 172.16.1.14 255.255.255.252
duplex auto
speed auto
!
The interfaces should be UP and the neighbors should be discovered. The following
output provides the interface status of Site1-Core2 and Site2-Core2.
Site1-Core2#sh ip int br | i up
Serial0/2
172.16.1.9
YES NVRAM up
FastEthernet1/0
unassigned
YES NVRAM up
FastEthernet1/0.1
192.168.250.3 YES NVRAM up
FastEthernet1/0.2
192.168.250.69 YES NVRAM up
FastEthernet2/0
192.168.250.35 YES NVRAM up
FastEthernet3/0
172.16.1.2
YES NVRAM up
up
up
up
up
up
up
47
Loopback0
Site1-Core2#
192.168.5.2
YES NVRAM up
up
Site1-Core2#sh cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID
Core-SW2
Core-SW1
Site2-Core2
Site1-Core2
Local Intrfce
Fas 2/0
Fas 1/0
Ser 0/2
Fas 3/0
Holdtme Capability Platform Port ID
139
SI
WS-C3550-2Fas 0/4
161
SI
WS-C3560G-Gig 0/4
171
R
3640
Ser 0/2
141
R
3640
Fas 3/0
Site1-Core2#
Site2-Core2#sh ip int br | i up
Serial0/2
172.16.1.10 YES NVRAM up
FastEthernet2/0
unassigned
YES NVRAM up
FastEthernet2/0.1
192.168.250.99 YES NVRAM up
FastEthernet2/0.2
192.168.250.131 YES NVRAM up
FastEthernet3/0
172.16.1.14 YES NVRAM up
Loopback0
192.168.5.6 YES NVRAM up
Site2-Core2#
up
up
up
up
up
up
Ping the far end interfaces to ensure the devices are reachable.
Site1-Core2#ping 172.16.1.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
Site1-Core2#
Site2-Core2#ping 172.16.1.9
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
Site2-Core2#
48
The above test ensures that the serial links between the two regional sites are established.
BGP can be configured on the core routers by advertising the WAN subnets. The
following BGP configuration is applied on the core routers.
Site1-Core1
!
router bgp 100
no synchronization
bgp log-neighbor-changes
network 172.16.1.0 mask
255.255.255.252
network 172.16.1.4 mask
255.255.255.252
neighbor 172.16.1.2 remote-as 100
neighbor 172.16.1.6 remote-as 200
no auto-summary
!
Site1-Core2
!
router bgp 100
no synchronization
bgp log-neighbor-changes
network 172.16.1.0 mask
255.255.255.252
network 172.16.1.8 mask
255.255.255.252
neighbor 172.16.1.1 remote-as 100
neighbor 172.16.1.10 remote-as 200
no auto-summary
!
Site2-Core1
!
router bgp 200
no synchronization
bgp log-neighbor-changes
network 172.16.1.4 mask
255.255.255.252
network 172.16.1.12 mask
255.255.255.252
neighbor 172.16.1.5 remote-as 100
neighbor 172.16.1.14 remote-as 200
no auto-summary
!
Site2-Core2
!
router bgp 200
no synchronization
bgp log-neighbor-changes
network 172.16.1.8 mask
255.255.255.252
network 172.16.1.12 mask
255.255.255.252
neighbor 172.16.1.9 remote-as 100
neighbor 172.16.1.13 remote-as 200
no auto-summary
!
The following check ensures that the BGP neighbors are established showing their
respective autonomous system.
Site1-Core1#sh ip bgp sum
BGP router identifier 192.168.5.1, local AS number 100
BGP table version is 297, main routing table version 297
13 network entries using 1261 bytes of memory
13 path entries using 468 bytes of memory
6 BGP path attribute entries using 360 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
49
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 2113 total bytes of memory
BGP activity 65/52 prefixes, 288/275 paths, scan interval 60 secs
Neighbor
V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.16.1.2
4 100 63161 63200
0 0 0 1w0d 2
172.16.1.6
4 200 108736 108809
297 0 0 10w5d
2
Site1-Core1#
Site2-Core1#sh ip bgp sum
BGP router identifier 192.168.5.5, local AS number 200
BGP table version is 150, main routing table version 150
12 network entries using 1164 bytes of memory
17 path entries using 612 bytes of memory
8 BGP path attribute entries using 480 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 2280 total bytes of memory
BGP activity 39/27 prefixes, 129/112 paths, scan interval 60 secs
Neighbor
V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.16.1.5
4 100 108817 108742
150 0 0 10w5d
5
172.16.1.14 4 200 108841 108824
150 0 0 10w5d
5
Site2-Core1#
Site1-Core2#sh ip bgp sum
BGP router identifier 192.168.5.2, local AS number 100
BGP table version is 55, main routing table version 55
13 network entries using 1261 bytes of memory
15 path entries using 540 bytes of memory
6 BGP path attribute entries using 360 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 2185 total bytes of memory
BGP activity 17/4 prefixes, 21/6 paths, scan interval 60 secs
Neighbor
V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.16.1.1
4 100
0
0
0 0 0 never 2
172.16.1.10 4 200 5287 5300
55 0 0 3d16h
2
Site1-Core2#
Site2-Core2#sh ip bgp sum
BGP router identifier 192.168.5.6, local AS number 200
BGP table version is 163, main routing table version 163
50
12 network entries using 1164 bytes of memory
27 path entries using 972 bytes of memory
10 BGP path attribute entries using 600 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 2760 total bytes of memory
BGP activity 33/21 prefixes, 121/94 paths, scan interval 60 secs
Neighbor
V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.16.1.9
4 100 68408 68341
163 0 0 3d16h
5
172.16.1.13 4 200 108758 108781
163 0 0 10w5d
10
Site2-Core2#
The serial WAN links between Site1 and Site2 are established and the BGP neighbors are
discovered between the sites. However, to establish end-to-end connectivity between the
two sites mutual redistribution need to be created between EIGRP and BGP on each site.
Figure 2-11 shows an example of redistribution at Site1. In order to avoid routing loops
an access-list of only the permitted subnets is created and distributed out of the serial
interfaces facing the WAN.
51
Redistribution
BGP
Into EIGRP
Site1 – Core1
S0/2
Lo=192.168.5.1
.5
.1
Fa3/0
BGP 100
EIGRP 10
172.16.1.0/30
Fa3/0
.2
S0/2
Lo=192.168.5.2
.9
Site1 – Core2
Redistribution
EIGRP
Into
BGP
Figure 2-11 Redistribution of EIGRP into BGP and BGP into EIGRP at Site1
The following configuration is applied on Site1 and Site2 core routers to create mutual
redistribution.
Mutual Redistribution on Site1 Core Routers:
Site1-Core1
!
access-list 1 permit 192.168.250.0
0.0.0.31
access-list 1 permit 192.168.250.32
0.0.0.31
access-list 1 permit 192.168.250.64
0.0.0.31
access-list 1 permit 192.168.1.0 0.0.0.255
access-list 1 permit 192.168.3.0 0.0.0.255
!
router eigrp 10
Site1-Core2
!
access-list 1 permit 192.168.250.0
0.0.0.31
access-list 1 permit 192.168.250.32
0.0.0.31
access-list 1 permit 192.168.250.64
0.0.0.31
access-list 1 permit 192.168.1.0 0.0.0.255
access-list 1 permit 192.168.3.0 0.0.0.255
!
52
redistribute bgp 100
!
router bgp 100
redistribute eigrp 10
neighbor 172.16.1.6 distribute-list 1 out
!
router eigrp 10
redistribute bgp 100
!
router bgp 100
redistribute eigrp 10
neighbor 172.16.1.10 distribute-list 1 out
!
Mutual Redistribution on Site2 core routers:
Site2-Core1
!
access-list 1 permit 192.168.250.96
0.0.0.31
access-list 1 permit 192.168.250.128
0.0.0.31
!
!
router eigrp 20
redistribute bgp 200
!
router bgp 200
redistribute eigrp 20
neighbor 172.16.1.5 distribute-list 1 out
!
Site2-Core2
!
access-list 1 permit 192.168.250.96
0.0.0.31
access-list 1 permit 192.168.250.128
0.0.0.31
!
!
router eigrp 20
redistribute bgp 200
!
router bgp 200
redistribute eigrp 20
neighbor 172.16.1.9 distribute-list 1 out
!
With mutual redistribution, the Site1 LAN devices will learn routes of Site2 LAN
devices, and vice versa, as external EIGRP routes. The following output from the
distribution layer switches shows the route 192.168.250.96/27 of Site2 core VLAN 300
via VLAN100 and VLAN 200 as a result of redistribution. It also shows the BGP routes
as External EIGRP due to redistribution.
DS1#sh ip ro
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
53
Gateway of last resort is not set
172.16.0.0/30 is subnetted, 2 subnets
D EX 172.16.1.8 [170/51456] via 192.168.250.3, 1d11h, Vlan100
[170/51456] via 192.168.250.35, 1d11h, Vlan200
D EX 172.16.1.4 [170/51456] via 192.168.250.2, 1d10h, Vlan100
[170/51456] via 192.168.250.34, 1d10h, Vlan200
192.168.250.0/27 is subnetted, 5 subnets
D EX 192.168.250.128 [170/51456] via 192.168.250.2, 1d10h, Vlan100
[170/51456] via 192.168.250.34, 1d10h, Vlan200
C
192.168.250.0 is directly connected, Vlan100
C
192.168.250.32 is directly connected, Vlan200
D
192.168.250.64 [90/28416] via 192.168.250.3, 1d10h, Vlan100
[90/28416] via 192.168.250.2, 1d10h, Vlan100
[90/28416] via 192.168.250.35, 1d10h, Vlan200
[90/28416] via 192.168.250.34, 1d10h, Vlan200
D EX 192.168.250.96 [170/51456] via 192.168.250.2, 1d10h, Vlan100
[170/51456] via 192.168.250.34, 1d10h, Vlan200
192.168.5.0/32 is subnetted, 4 subnets
DS2#sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
172.16.0.0/30 is subnetted, 2 subnets
D EX 172.16.1.4 [170/51456] via 192.168.250.34, 1d10h, Vlan200
[170/51456] via 192.168.250.2, 1d10h, Vlan100
D EX 172.16.1.8 [170/51456] via 192.168.250.35, 1d11h, Vlan200
[170/51456] via 192.168.250.3, 1d11h, Vlan100
192.168.250.0/27 is subnetted, 5 subnets
C
192.168.250.0 is directly connected, Vlan100
C
192.168.250.32 is directly connected, Vlan200
D
192.168.250.64 [90/28416] via 192.168.250.35, 1d10h, Vlan200
[90/28416] via 192.168.250.34, 1d10h, Vlan200
[90/28416] via 192.168.250.3, 1d10h, Vlan100
[90/28416] via 192.168.250.2, 1d10h, Vlan100
54
D EX
192.168.250.96 [170/51456] via 192.168.250.34, 1d10h, Vlan200
[170/51456] via 192.168.250.2, 1d10h, Vlan100
D EX 192.168.250.128 [170/51456] via 192.168.250.34, 1d10h, Vlan200
[170/51456] via 192.168.250.2, 1d10h, Vlan100
192.168.5.0/32 is subnetted, 4 subnets
D
192.168.5.2 [90/130816] via 192.168.250.35, 1d11h, Vlan200
[90/130816] via 192.168.250.3, 1d11h, Vlan100
D
192.168.5.3 [90/130816] via 192.168.250.36, 1d11h, Vlan200
[90/130816] via 192.168.250.4, 1d11h, Vlan100
D
192.168.5.1 [90/130816] via 192.168.250.34, 1d10h, Vlan200
[90/130816] via 192.168.250.2, 1d10h, Vlan100
C
192.168.5.4 is directly connected, Loopback0
C 192.168.1.0/24 is directly connected, Vlan50
C 192.168.3.0/24 is directly connected, Vlan10
DS2#
Similarly the core devices of Site2 learnt routers of Site1 via redistribution. Perform a
ping check from the access-layer switch in Site1 to the core subnet in Site2 to ensure endto-end connectivity is established.
Access-Switch#ping 192.168.250.99
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.99, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/12 ms
SW2#
Site2-Core2#ping 192.168.1.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/24 ms
Site2-Core2#
The ping shows 100% success rate of end-to-end reachability between the two sites.
55
CHAPTER 3. DEPLOYMENT OF CENTRALIZED TACACS+ ENVIRONMENT
The second phase of the project is to deploy a centralized TACACS+ environment to
provide AAA services to establish network connectivity to the network elements. In order
to deploy TACACS+, a Cisco Secure ACS appliance is built over Win2003 server. A
centralized dedicated master server is built along with dedicated primary and secondly
slaves in each site.
At each site a specific VLAN called as Server-VLAN with a /27 subnet is configured. In
order to provide quick authentication and also to reduce the communication time between
the TACACS+ servers itself, the VLAN’s are connected to core layer switches. With a
future scope of deploying more critical applications the server VLANs are configured
with /27 subnets. A VLAN 30 with subnet 192.168.250.64/27 is configured at site1 and a
VLAN 40 with subnet 192.168.250.128/27 is configured at site2. Both these VLAN are
advertised in EIGRP process and are automatically advertised to the remote sites as a
result of redistribution.
56
Fa1/0
Fa1/0.1 .2
Fa1/0.2 .68
Lo=192.168.5.1
Site1-Core 1
3640
Lo=192.168.5.2
Site1-Core 2
3640
Fa1/0
Fa1/0.1 .3
Fa1/0.2 .69
VLAN 30 192.168.250.64/27
Eth 3
.70
MASTER
Eth0
.71
SLAVE - 1
Figure 3-1 Server VLAN 30 at Site1
Figure 3-1 shows the layer 2 connectivity of server VLAN 30. The layer 3 interfaces of
the server VLAN is configured at site1 core routers. As there is only one physical
interface on core routers in site 1, router-on-a-stick is implemented where two logical
sub-interfaces are created on one physical interface Fa1/0. Sub-interface fa1/0.1 is
configured with core VLAN 100 and the second sub-interface fa1/0.2 is configured with
server VLAN 30. Similarly, router-on-a-stick is implemented on Core B of Site1.
The master and slave servers are configured with one of the IP addresses within the
server VLAN. IP address 192.168.250.70 is assigned to master server and IP address
192.168.250.71 is assigned to the first slave server. The core routers are configured as
below:
Site1-Core1
!
interface FastEthernet1/0.1
Site1-Core2
!
interface FastEthernet1/0.1
57
encapsulation dot1Q 100
ip address 192.168.250.2
255.255.255.224
!
interface FastEthernet1/0.2
encapsulation dot1Q 30
ip address 192.168.250.68
255.255.255.224
!
encapsulation dot1Q 100
ip address 192.168.250.3
255.255.255.224
!
interface FastEthernet1/0.2
encapsulation dot1Q 30
ip address 192.168.250.69
255.255.255.224
!
A trunk is configured between the two core switches to exchange the server VLAN 30.
The core switches are configured as allow VLAN 30.
Core-SW1
!
interface GigabitEthernet0/3
description connected to site1-core1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 30,100
switchport mode trunk
!
interface GigabitEthernet0/4
description connected to site1-core2
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 30,100
switchport mode trunk
!
interface GigabitEthernet0/5
description connected to Master Server
switchport access vlan 30
switchport mode access
!
interface GigabitEthernet0/24
description connected to core-sw2
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 30
switchport mode trunk
!
Core-SW2
!
!
interface FastEthernet0/5
description connected to Slave Server 1
switchport access vlan 30
switchport mode access
!
interface FastEthernet0/24
description connected to core-sw1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 30
switchport mode trunk
!
The layer3 interface should be reachable from the core-switches. The following ping
ensures the connectivity to the layer 3 interfaces.
58
Core-SW1#ping 192.168.250.68
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.68, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/203/1007 ms
Core-SW1#
Core-SW1#ping 192.168.250.69
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.69, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/203/1007 ms
Core-SW1#
Core-SW2#ping 192.168.250.68
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.68, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/202/1000 ms
Core-SW2#ping 192.168.250.69
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.69, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/201/1000 ms
Core-SW2#
3.1
Installing Master And Slave TACACS+ Servers
A Win 2003 server is built as a prerequisite to install TACACS+ using the Cisco Secure
ACS 4.2 appliance. Certain application features such as disabling security services,
installing Java are performed as prerequisite. The installation guide can be found at the
Cisco online documentation [6].
Once the installation is complete, the ACS web interface can be accessed with the URL
http://127.0.0.1:2002 as shown in figure 3-2.
59
Figure 3-2 ACS Web Interface
Several System configuration settings such as Logging, DB Backup and Restore,
Database Replication are configured as per the requirement such as the DB is set to
backup once a day; keeping all passed authorization logs for last 180 days, etc.
3.2
Building Master Server And Replicating To Slave Server
An ACS server, Server2, is configured as a master server to provide centralized
administration. All user level privileges such as enable or read-only right to network
devices or groups are performed at the master server. Every time the database is updated
it is replicated to the slave servers. The master server can be administered to replicate DB
at any number of times to over write the slaves and the slaves are used to provide AAA
services to the network users.
60
TACACS (AAA)
Master
(Centralized)
ONE WAY
REPLICATION
TACACS Slave1
Access
Request
NE1
TACACS Slave2
Access
Request
Access
Response
Site1
NE2
NE1
Access
Response
Site2
NE2
Figure 3-3 Centralized Administration and One Way Replication
As shown in figure 3-3, with limited number of servers available in prototype
deployment, the TACACS+ environment is designed in such a way that a master and a
slave are deployed in site1 and a second slave server is deployed in site2. Slave1 will act
as the primary server for site1 network devices and as secondary or backup for site2
network devices. Similarly, Slave2 will act as the primary server for site2 network
devices and as a secondary for site1 network devices.
3.2.1
Creating Network Device Groups
The figure 3-4 shows a Network Device Group (NDG) of AAA servers. All the slaves
including master server are added in a common group and each slave server is provided
with a common secret key of the AAA server. For correct operation the key must be
61
identical on the remote AAA server and ACS. If the shared secret does not match, ACS
discards all packets from the remote AAA server.
Figure 3-4 NDG of AAA Servers
A Network Device Group (NDG) is created for each LAN site and an NDG for WAN
access.
Figure 3-5 Lab NDGs with LAN &WAN Subnets
Each group has subnets associated to each site. For example in figure 3-6, site 1 has two
IP ranges which are specific to site1 only.
Figure 3-6 Site1 IP Range
62
3.2.2
Creating User Groups
A user group is nothing but a group with settings common to the users associated to that
group. Two user groups Site1_Users and Site2_Users are created as show in figure 3-7.
Figure 3-7 User Groups
Each user group is configured with setting permitted to the respective NDG’s. For
example in figure 3-8, site1_users group is set to allow all the site1 subnets associated to
that group so that all the users associated to that group will only have access to Site1
subnets. Similarly, settings such as enable privileges, aging policies are set to each group.
Figure 3-8 NAS Restrictions
3.2.3
Creating Users
Two usernames AJ and Bob are created and assigned to the user group Site1_Users and
Site2_Users respectively. The user AJ will inherit the group’s settings and Bob will
63
inherit the group settings of site2. A password ‘testpass1’ is assigned to AJ with enable
pass as ‘ena123’ and a password ‘testpass2’ is assigned to Bob. Using these credentials
AJ and Bob can be able to login to any device in Site1 and Site2 respectively. Figure 3-9
shows an example of user name ‘aj’ assigned to the user group Site1_Users.
Figure 3-9 Group Level Settings
3.2.4
Replicating Database
Now that the server 2 is designed with NDGs, Users and User Groups, server2 can be
prepared as master server for replicating the slave servers 1 and 2.
3.2.5
Master Setup
Under the database replication setup in system configuration, the replication components
are set to “send” to the receiving slaves.
Figure 3-10 Replicating Components from Master Server
The replicating partners are the slave servers.
64
Figure 3-11 Replication Servers from Master
3.2.6
Slave Setup
Under the slave servers the replicating components are set to “receive” from the master.
Figure 3-12 Replicating Components Receiving from Master Server
And the inbound replication is accepted from the master server.
Figure 3-13 Inbound Replication Master Server
Once both master and slave AAA servers are configured the ‘replicate now’ is pushed.
The complete master database along with all setting will be pushed to the slave servers.
The following logs are captured while the database is being replicated to the slaves.
65
Figure 3-14 Outbound Database Replication from Master Server
From the log capture in figure 3-14 it can be observed that once the outbound replication
cycle is started and each component is replicated to the slave servers fmops-svr1 and
fmops-svr3. And simultaneously, the inbound replication cycle started on the slave
server. Figure 3-15 shows an inbound database replication from the master server.
66
Figure 3-15 Inbound Database Replication on Slave Server
The database replication can be schedule to any number of times and every time a change
is made on the master server it gets replicated to the slaves by overwriting the old
database. The next step is to configure the network devices and ensure that authentication
and authorization are working and that all the administrative logs are being captured on
the slave servers.
3.2.7
Configuring Site1 and Site2 Network Devices With TACACS+
The following tacacs+ configuration is applied on the network devices.
!
aaa new-model
!
aaa authentication login default group tacacs+ line
aaa authentication enable default group tacacs+ enable
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 1 default stop-only group tacacs+
aaa accounting commands 15 default stop-only group tacacs+
aaa accounting system default start-stop group tacacs+
67
aaa session-id common
tacacs-server host 192.168.250.70
tacacs-server host 192.168.250.132
tacacs-server timeout 30
tacacs-server directed-request
tacacs-server key secretkey
!
When the configuration is applied on any device, the “aaa new-model” turns on
TACACS+ and the “aaa authentication” line says the default way for users to log in is by
checking with the group of tacacs+ servers (any TACACS+ servers defined with the
"tacacs-server" command). If that fails to respond, the line or enable password can then
be used as fallbacks. The accounting commands creates logs into ACS such as who is
currently logged into ACS, what commands are executed, etc.
In the above configuration the first server in the config will act as the primary server, in
this case 192.168.250.70 and the second server in the config will act as the secondary
server, in this case 192.168.250.132.
The exact same TACACS+ configuration is applied on Site2 network device except that
the primary tacacs server is configured as 192.168.250.132 and the secondary server is
chosen as 192.168.250.70.
tacacs-server host 192.168.250.132
tacacs-server host 192.168.250.70
With the above configuration is applied on a device and a telnet or ssh request is sent,
username and password is prompted. Based on the user input user access is either
authorized or denied.
Figure 3-15 [7] shows a communication between a Client and a
TACACS+ Server and the communication involves seven different types of messages.
68
Figure 3-16 Communication between Client and TACACS+ Server
TACACS+ Devices the packet or message definations as follows [8]:

Authentication START (It describes the type of authentication to be performed,
and may contain the username and some authentication data. The START packet
is only ever sent as the first message in a TACACS+ authentication session.).

Authentication REPLY (It indicates whether the authentication is finished, or
whether it should continue. If the REPLY indicates that authentication should
continue, then it will also indicate what new information is requested.).

Authentication CONTINUE (It is sent from the NAS to the server following the
receipt of a REPLY packet and possibly contains requested information.).
69

Authorization REQUEST (It contains a fixed set of fields that describe the
authenticity of the user or process, and a variable set of arguments that describes
the services and options for which authorization is requested.).

Authorization RESPONSE (It contains a variable set of response arguments
(attribute-value pairs) which can restrict or modify the client actions.).

Accounting REQUEST (It conveys information used to provide accounting for a
service provided to a user.).

Accounting REPLY (It is used to indicate that the accounting function on the
server has completed and securely committed the record.).
3.2.8
Testing For PASSED Authorization To Network Devices
The config is applied on one of the distribution layer switches DS2 and the following
debugging messages are captured when an access request is sent.
Debug tacacs is enabled on DS2. For each command tacacs debugging messages are
captured on DS2. A telnet request is initiated from DS1 with the management IP address
of DS2.
DS1#telnet 192.168.1.2
Trying 192.168.1.2 ... Open
AJ-LAB-Test-Bed
Please do not delete any configuration
Please do not pull any cables
Contact AJ - 377-5198
Username:
Observed that an authentication request is started using the primary server
192.168.250.70 and an authentication response status of GET_USER is initiated.
70
12w1d: TPLUS: Queuing AAA Authentication request 52 for processing
12w1d: TPLUS: processing authentication start request id 52
12w1d: TPLUS: Authentication start packet created for 52()
12w1d: TPLUS: Using server 192.168.250.70
12w1d: TPLUS(00000034)/0/NB_WAIT/479328E8: Started 30 sec timeout
12w1d: TPLUS(00000034)/0/NB_WAIT: socket event 2
12w1d: TPLUS(00000034)/0/NB_WAIT: wrote entire 35 bytes request
12w1d: TPLUS(00000034)/0/READ: socket event 1
12w1d: TPLUS(00000034)/0/READ: Would block while reading
12w1d: TPLUS(00000034)/0/READ: socket event 1
12w1d: TPLUS(00000034)/0/READ: read entire 12 header bytes (expect 16 bytes
data)
12w1d: TPLUS(00000034)/0/READ: socket event 1
12w1d: TPLUS(00000034)/0/READ: read entire 28 bytes response
12w1d: TPLUS(00000034)/0/479328E8: Processing the reply packet
12w1d: TPLUS: Received authen response status GET_USER (7)
Username ‘AJ’ is entered on the username prompt.
Username: aj
A GET_PASSWORD response is initiated.
Password:
The user AJ’s password ‘testpass1’ is then entered. The authentication request for the
given password is being processed.
12w1d: TPLUS: Queuing AAA Authentication request 53 for processing
12w1d: TPLUS: processing authentication continue request id 53
12w1d: TPLUS: Authentication continue packet generated for 53
12w1d: TPLUS(00000035)/0/WRITE/468E2D30: Started 30 sec timeout
12w1d: TPLUS(00000035)/0/WRITE: wrote entire 19 bytes request
12w1d: TPLUS(00000035)/0/READ: socket event 1
12w1d: TPLUS(00000035)/0/READ: read entire 12 header bytes (expect 16 bytes
data)
12w1d: TPLUS(00000035)/0/READ: socket event 1
12w1d: TPLUS(00000035)/0/READ: read entire 28 bytes response
12w1d: TPLUS(00000035)/0/468E2D30: Processing the reply packet
12w1d: TPLUS: Received authen response status GET_PASSWORD (8)
71
Once the authentication response is PASS the user is authorized and AAA accounting
request is processed.
12w1d: TPLUS: Queuing AAA Authentication request 53 for processing
12w1d: TPLUS: processing authentication continue request id 53
12w1d: TPLUS: Authentication continue packet generated for 53
12w1d: TPLUS(00000035)/0/WRITE/477DECD8: Started 30 sec timeout
12w1d: TPLUS(00000035)/0/WRITE: wrote entire 26 bytes request
12w1d: TPLUS(00000035)/0/READ: socket event 1
12w1d: TPLUS(00000035)/0/READ: read entire 12 header bytes (expect 6 bytes data)
12w1d: TPLUS(00000035)/0/READ: socket event 1
12w1d: TPLUS(00000035)/0/READ: read entire 18 bytes response
12w1d: TPLUS(00000035)/0/477DECD8: Processing the reply packet
12w1d: TPLUS: Received authen response status PASS (2)
12w1d: TPLUS: Queuing AAA Accounting request 53 for processing
12w1d: TPLUS: processing accounting request id 53
12w1d: TPLUS: Sending AV task_id=11
12w1d: TPLUS: Sending AV timezone=UTC
12w1d: TPLUS: Sending AV service=shell
12w1d: TPLUS: Accounting request created for 53(aj)
12w1d: TPLUS: using previously set server 192.168.250.71 from group tacacs+
12w1d: TPLUS(00000035)/0/NB_WAIT/468E2D30: Started 30 sec timeout
12w1d: TPLUS(00000035)/0/NB_WAIT: socket event 2
12w1d: TPLUS(00000035)/0/NB_WAIT: wrote entire 76 bytes request
12w1d: TPLUS(00000035)/0/READ: socket event 1
12w1d: TPLUS(00000035)/0/READ: Would block while reading
12w1d: TPLUS(00000035)/0/READ: socket event 1
12w1d: TPLUS(00000035)/0/READ: read entire 12 header bytes (expect 5 bytes data)
12w1d: TPLUS(00000035)/0/READ: socket event 1
12w1d: TPLUS(00000035)/0/READ: read entire 17 bytes response
12w1d: TPLUS(00000035)/0/468E2D30: Processing the reply packet
12w1d: TPLUS: Received accounting response with status PASS
When the user gets into the enable mode a GETPASS authentication status request is
initiated.
DS1>enable
12w1d: TAC+: send AUTHEN/START packet ver=192 id=2847203026
12w1d: TAC+: Using default tacacs server-group "tacacs+" list.
12w1d: TAC+: Opening TCP/IP to 192.168.250.71/49 timeout=30
72
12w1d: TAC+: Opened TCP/IP handle 0x522D4EC8 to 192.168.250.70/49
12w1d: TAC+: 192.168.250.71 (2847203026) AUTHEN/START/LOGIN/ASCII
queued
12w1d: TAC+: (2847203026) AUTHEN/START/LOGIN/ASCII processed
12w1d: TAC+: ver=192 id=2847203026 received AUTHEN status = GETPASS
The user enters the password an AUTHEN/CONT packet is sent to the AAA server for
the password to be processed. Finally when the user exits from the device the TCP/IP
Connection is closed with the TACACS+ Server.
12w1d: TAC+: send AUTHEN/CONT packet id=2847203026
12w1d: TAC+: 192.168.250.71 (2847203026) AUTHEN/CONT queued
12w1d: TAC+: (2847203026) AUTHEN/CONT processed
12w1d: TAC+: ver=192 id=2847203026 received AUTHEN status = PASS
12w1d: TAC+: Closing TCP/IP 0x522D4EC8 connection to 192.168.250.70/49
Following are the ‘aaa authentication’ debug messages from successful telnet to exec
mode on the device. Observe that the user ‘aj’ is permitted with full enable privileges 15.
12w1d: AAA/BIND(00000031): Bind i/f
12w1d: AAA/AUTHEN/LOGIN (00000031): Pick method list 'default'
12w1d: AAA/AUTHEN/LOGIN (00000031): Pick method list 'default'
12w1d: AAA: parse name=tty1 idb type=-1 tty=-1
12w1d: AAA: name=tty1 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=1
channel=0
12w1d: AAA/MEMORY: create_user (0x522C4140) user='aj' ruser='NULL' ds0=0
port='tty1' rem_addr='192.168.1.3' authen_type=ASCII service=ENABLE priv=15
initial_task_id='0', vrf= (id=0)
12w1d: AAA/AUTHEN/START (828036695): port='tty1' list='' action=LOGIN
service=ENABLE
12w1d: AAA/AUTHEN/START (828036695): using "default" list
12w1d: AAA/AUTHEN/START (828036695): Method=tacacs+ (tacacs+)
12w1d: TAC+: send AUTHEN/START packet ver=192 id=828036695
12w1d: TAC+: ver=192 id=828036695 received AUTHEN status = GETPASS
12w1d: AAA/AUTHEN (828036695): status = GETPASS
12w1d: AAA/AUTHEN/CONT (828036695): continue_login (user='aj')
12w1d: AAA/AUTHEN (828036695): status = GETPASS
12w1d: AAA/AUTHEN (828036695): Method=tacacs+ (tacacs+)
12w1d: TAC+: send AUTHEN/CONT packet id=828036695
12w1d: TAC+: ver=192 id=828036695 received AUTHEN status = PASS
12w1d: AAA/AUTHEN (828036695): status = PASS
73
12w1d: AAA/MEMORY: free_user (0x522C4140) user='aj' ruser='NULL' port='tty1'
rem_addr='192.168.1.3' authen_type=ASCII service=ENABLE priv=15
Now that the user ‘aj’ is permitted into the device, any command that is executed is
logged into the ACS server.
Figure 3-17 Authentication Logs of User AJ
From the above logs in figure 3-16, it can be observed that all the commands executed by
the user AJ are captured.
3.2.9
Testing For FAILED Authorization To Network Devices
Using the same credentials of user AJ, a device in Site2 is sent a telnet request to
establish connectivity. Since user AJ is configured in ACS to be authorized only to Site1
devices, the authorization should fail. A site2 core switch is sent a telnet request from
Site1 distribution layer switch. The following TACACS debug authentication messages
are captured on the core switch in site2 and the telnet authorization fails for user AJ.
When a telnet request is sent from DS2, the core device Site2-Core-SW1 prompts for
username.
DS2#telnet 192.168.250.97
Trying 192.168.250.97 ... Open
74
User Access Verification
Username:
Debug message on Site2-Core-SW1
Site2-Core-SW1#
13w6d: AAA: parse name=tty1 idb type=-1 tty=-1
13w6d: AAA: name=tty1 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=1
channel=0
13w6d: AAA/MEMORY: create_user (0x2036098) user='NULL' ruser='NULL' ds0=0
port='tty1' rem_addr='192.168.250.5' authen_type=ASCII service=LOGIN priv=1
initial_task_id='0', vrf= (id=0)
13w6d: AAA/AUTHEN/START (2523915680): port='tty1' list='' action=LOGIN
service=LOGIN
13w6d: AAA/AUTHEN/START (2523915680): using "default" list
13w6d: AAA/AUTHEN/START (2523915680): Method=tacacs+ (tacacs+)
13w6d: TAC+: send AUTHEN/START packet ver=192 id=2523915680
13w6d: TAC+: ver=192 id=2523915680 received AUTHEN status = GETUSER
13w6d: AAA/AUTHEN (2523915680): status = GETUSER
13w6d: AAA/AUTHEN/CONT (2523915680): continue_login (user='(undef)')
13w6d: AAA/AUTHEN (2523915680): status = GETUSER
When the username: AJ is entered, a GETPASS response is initiated.
Username: aj
Password:
GETPASS message initiated on Site2-Core-SW1
13w6d: AAA/AUTHEN (2523915680): Method=tacacs+ (tacacs+)
13w6d: TAC+: send AUTHEN/CONT packet id=2523915680
13w6d: TAC+: ver=192 id=2523915680 received AUTHEN status = GETPASS
13w6d: AAA/AUTHEN (2523915680): status = GETPASS
13w6d: AAA/AUTHEN/CONT (2523915680): continue_login (user='aj')
13w6d: AAA/AUTHEN (2523915680): status = GETPASS
When the user enters the password, the authentication is failed.
Username: aj
Password:
75
% Authentication failed.
Fail authentication message on Site2-Core-SW1
13w6d: AAA/AUTHEN (2523915680): Method=tacacs+ (tacacs+)
13w6d: TAC+: send AUTHEN/CONT packet id=2523915680
13w6d: TAC+: ver=192 id=2523915680 received AUTHEN status = FAIL
13w6d: AAA/AUTHEN (2523915680): status = FAIL
The following failed attempt logs in figure 3-17 are captured on the Site2 ACS server. It
displaces the time the user AJ tried to connect to an unauthorized device in AJ_Site2
group.
Figure 3-18 Failed Authentication Logs of User AJ
From both the above test’s it proves that a user can only be able to established
connectivity to network devices which he is authorized to. Hence the user AJ can only be
authorized to devices in Site1 and not authorized to devices in Site2.
3.2.10 Round Trip Delay For Site1 Primary TACACS+ Server
Perform a ping to the primary TACACS server from DS2 to observe the round-trip-delay.
DS2#ping 192.168.250.70
Type escape sequence to abort.
76
Sending 5, 100-byte ICMP Echos to 192.168.250.70, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
DS2#
The minimum round trip delay for Site1 devices for the primary TACACS Server is 1 ms.
And the maximum round trip delay is 2 ms.
3.2.11 Round Trip Delay For Site1 Secondary TACACS+ Server
Perform a ping to the secondary TACACS server from DS2 to observe the round-tripdelay.
DS2#ping 192.168.250.132
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.132, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
DS2#
The minimum round trip delay for Site1 devices for the secondary TACACS Server is 4
ms. And the maximum round trip delay is 8 ms.
It can be concluded from the above tests that the maximum time taken by site1 network
devices to communication to the primary AAA server within the same region over a
secondary AAA server in different region is 4 times faster. Secondly, pointing network
devices to primary AAA server within the same region encompasses the AAA
communication messages within the region itself. Hence the network noise is limited to
the region.
77
CHAPTER 4. PRE-PRODUCTION DEPLOYMENT AND NETWORK PERFORMANCE
ANALYSIS
This chapter describes the comparison test results and performance analysis of production
devices communicating to a primary AAA server in a different region compared to preproduction deployment of AAA servers within a region.
As enterprise networks are geographically distributed, the effect of round-trip
authentication delay can be measured more significantly when devices from one region
are pointing to a primary server in another region. To demonstrate this, two sites one in
Penang and the other in Shanghai are considered as regional GAR sites for acceptance
testing and three different regional devices from Penang, China and Bangalore are used
as sub-regional GAR sites to demonstrate statistical analysis of data and performance
improvement.
The devices in GAR region were initially pointing to a primary server in a European
region GER. Both these regions are integrated with WAN and ISP network. Hence to
communicate a device from GAR to a AAA server in GER requires several network
hops. For example, the following round-trip delay is recorded to reach a server in GER.A
trace route is done from a device in Penang to the primary TACACS server in GER. A
total of 12 hops were captured end to end with a minimum round trip delay of 220ms.
Device-PG#traceroute 10.x.x.x
Type escape sequence to abort.
Tracing the route to aaa-ger-server.ger.corp.xyz.com (10..x.x.x)
1 device-v901.gar.xyz.com (10.x.x.x) 0 msec 0 msec 0 msec
2 core-v250.gar.xyz.com (132.x.x.x) 0 msec
core-v251.gar.xyz.com (132.x.x.x) 4 msec 0 msec
78
3 devicea-tengig2-1.wan.xyz.com (10.x.x.x) 0 msec
deviceb-tengig2-2.wan.xyz.com (10.x.x.x) 0 msec
devicec-tengig2-1.wan.xyz.com (10.x.x.x) 4 msec
4 coreroutera-tengig2-5.wan.xyz.com (10.x.x.x) 0 msec 0 msec
corerouterb-tengig2-6.wan.xyz.com (10.x.x.x) 0 msec
5 regcorerouter-tengig2-1.wan.xyz.com (10.x.x.x) 8 msec 4 msec 20 msec
6 regcorerouter-gigabitethernet0-0-0.wan.xyz.com (10.x.x.x) 4 msec 8 msec
regcorerouter-gigabitethernet0-1-0.wan.xyz.com (10.x.x.x) 4 msec
7 corerouter-tunnel1109.wan.xyz.com (10.x.x.x) 228 msec
corerouter-tunnel1109.wan.xyz.com (10.x.x.x) 224 msec
corerouter-tunnel1109.wan.xyz.com (10.x.x.x) 212 msec
8 corerouter-gigabitethernet0-0-6.wan.xyz.com (10.x.x.x) 228 msec
dc-routera-470.ger.xyz.com (143.x.x.x) 224 msec 228 msec
9 dc1-routera02-471.ger.xyz.com (143.x.x.x) 240 msec 232 msec 252 msec
10 dc1-corerouter.ger.xyz.com (10.x.x.x) 244 msec
dc2-corerouter.ger.xyz.com (10.x.x.x) 220 msec
dc3-corerouter.ger.xyz.com (143.x.x.x) 220 msec
11 dc3e-corerouter.ger.xyz.com (10.x.x.x) 228 msec
10.x.x.x 216 msec
dc3e-corerouter2.ger.xyz.com (10.x.x.x) 228 msec
12 aaa-server.ger.corp.xyz.com (10.x.x.x) 216 msec
10.x.x.x 224 msec
aaa-server.ger.corp.xyz.com (10.x.x.x) 216 msec
Device-PG#
A ping is executed to observe the minimum round trip network delay of 220 ms.
Device-PG#ping 10.x.x.x
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.x.x.x, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 220/224/232 ms
Device_PG#exit
4.1
Analysis Of Round-Trip-Delay At Different Time Periods For A AAA Server
Outside Region:
Three GAR sub-regional sites namely Penang, China and Bangalore are used to analyze
the RTD to communicate a AAA server in a GER regional site. Three different devices
from the same sub region were used to get an average Round-Trip-Delay. The RTD
79
analysis is done at four different period’s viz. morning hours, peak hours, afternoon hours
and off hours.
4.1.1
Analysis Of RTD During Morning Hours
The following table provides the stats captured during the morning hours.
Table 4-1 Average Morning Hour Stats For A AAA Server Outside A Region
Morning_Hours
MIN
MAX
AVG
Device1_PG
239
267
248
Device2_PG
237
265
244
Device3_PG
231
248
237
Avg_PG
236
260
243
Device1_BGA
249
299
264
Device2_BGA
235
255
247
Device3_BGA
233
384
285
Avg_BGA
239
313
265
Device1_CHN
223
324
255
Device2_CHN
222
270
236
Device3_CHN
224
249
233
Avg_CHN
223
281
241
Avg_GAR_Morning_RTD
233
285
250
The following graph displays the averages RTD for the stats captured during morning
hours and a total average of 250ms for all GAR devices is analyzed to reach a server in
an outside region.
80
Average RTD For All GAR Devices To Reach
TACACS+ Server Outside the GAR Region
During Morning Hours
330
320
310
300
Time
290
in
MilliSeconds(ms)280
270
Avg_BGA, 265
260
Avg_GAR_Morning
_RTD, 250
Avg_PG, 243
Avg_CHN, 241
250
240
230
220
MIN
MAX
AVG
Figure 4-1 Average RTD During Morning Hours
4.1.2
Analysis Of RTD During Peak Hours
The following table provides the stats captured during the peak hours.
81
Table 4-2 Average Peak Hour Stats For A AAA Server Outside A Region
Peak_Hours
Device1_PG
Device2_PG
Device3_PG
Avg_PG
Device1_BGA
Device2_BGA
Device3_BGA
Avg_BGA
Device1_CHN
Device2_CHN
Device3_CHN
Avg_CHN
Avg_GAR_Peak_RTD
MIN
MAX
228
228
227
228
235
237
235
236
224
235
239
233
232
AVG
231
240
274
248
680
657
716
684
256
340
241
279
404
232
235
242
236
374
433
463
423
243
265
240
249
303
And the following graph displays the averages RTD for the stats captured during peak
hours and a total average of 250ms for all GAR devices is analyzed to reach the same
server in the outside region.
Average RTD For All GAR Devices To Reach TACACS+
Server Outside the GAR Region During Morning Hours
330
320
310
300
Time
290
in
280
MilliSeconds(ms)
270
260
250
240
230
220
Avg_BGA, 265
Avg_GAR_Morning
_RTD, 250
Avg_PG, 243
Avg_CHN, 241
MIN
MAX
AVG
Figure 4-2 Average RTD During Peak Hours
82
4.1.3
Analysis Of RTD During Afternoon Hours
The following table provides the stats captured during the afternoon hours.
Table 4-3 Average Afternoon Hour Stats For A AAA Server Outside A Region
Afternoon_Hours
MIN
MAX
AVG
Device1_PG
212
220
214
Device2_PG
215
215
215
Device3_PG
214
217
215
Avg_PG
214
217
215
Device1_BGA
224
224
224
Device2_BGA
224
226
228
Device3_BGA
228
231
232
Avg_BGA
225
227
228
Device1_CHN
212
214
220
Device2_CHN
215
216
215
Device3_CHN
215
218
215
Avg_CHN
214
216
217
Avg_GAR_Afternoon_RTD
218
220
220
And the following graph displays the averages RTD for the stats captured during
afternoon hours and a total average of 220ms for all GAR devices is analyzed to reach the
same server in the outside region.
Average RTD For All GAR Devices To Reach TACACS+
Server Outside the GAR Region During Afternoon Hours
230
Avg_BGA, 228
225
Time
in
220
MilliSeconds(ms)
Avg_GAR_Afterno
on_RTD, 220
Avg_CHN, 217
Avg_PG, 215
215
210
MIN
MAX
AVG
Figure 4-3 Average RTD During Afternoon Hours
83
4.1.4
Analysis Of RTD During Off Hours
The following table provides the stats captured during the off peak hours.
Table 4-4 Average Off Peak Stats For A AAA Server Outside A Region
Off Peak Hours
Device1_PG
Device2_PG
Device3_PG
Avg_PG
Device1_BGA
Device2_BGA
Device3_BGA
Avg_BGA
Device1_CHN
Device2_CHN
Device3_CHN
Avg_CHN
Avg_GAR_Off Peak_RTD
MIN
MAX
156
156
155
156
177
178
153
169
127
128
128
128
151
AVG
160
157
224
180
178
203
232
204
182
128
130
147
177
157
156
173
162
177
184
174
178
140
128
129
132
158
And the following graph displays the averages RTD for the stats captured during off peak
hours and a total average of 158ms for all GAR devices is analyzed to reach the same
server in the outside region.
Average RTD For All GAR Devices To Reach TACACS+
Server Outside the GAR Region During Off Hours
220
195
Avg_BGA, 178
Time 170
in
MilliSeconds(MS)
145
Avg_PG, 162
Avg_GAR_Off
Peak_RTD, 158
Avg_CHN, 132
120
MIN
MAX
AVG
Figure 4-4 Average RTD During Off Hours
84
4.1.5
Analysis Of Average RTD During Different Time Periods
The following table provides the average stats of the different time period analysis
performed above.
Table 4-5 Average Stats For A AAA Server Outside A Region
Average RTD
Avg_Morning_RTD
Avg_Peak_RTD
Avg_Afternoon_RTD
Avg_OffHours_RTD
MIN
MAX
233
232
218
151
AVG
285
404
220
177
250
303
220
158
A graph representation is show below displaying the averages of all time periods.
Average RTD For All GAR Devices To Reach TACACS+
Server Outside the GAR Region At Different Time Periods
425
375
325
Avg_Peak_RTD,
303
Avg_Morning_RTD
, 250
Avg_Afternoon_RT
D, 220
Avg_OffHours_RT
D, 158
Time
275
in
MilliSeconds(MS)
225
175
125
MIN
MAX
AVG
Figure 4-5 Average RTD At Different Time Periods
It is observed that the Average RTD during the peak time and the morning time is almost
the same which is greater than 250ms. One of the reasons is that even though the
networks in both GAR and GER regions are geographically distributed they are busy
during that period. It can also be observed that the RTD is low during afternoon and
85
during off hours. Finally, it can be observed that the average round trip delay is above
219ms while trying to reach a AAA server configured in different region during
afternoon hours or above 250ms when trying to reach a server during peak hours.
4.2
Analysis Of Hop Count At Different Time Periods For A AAA Server Outside
Region:
Trace route was performed from the sub-regional GAR devices in Penang, China and
Bangalore to the AAA server in the outside region. The trace was performed at different
time periods during morning, afternoon, peak and off hours.
Table 4-6 Average Hop Count For A AAA Server Outside A Region
Avg_Hop_Count
Device_PG
Device_BGA
Device_CHN
Morning Afternoon Peak
12
12
12
9
9
9
13
13
13
Off
Hours
12
9
13
Periodic Hops Count To A TACACS+ Server
Outside GAR Region
14
Device_CHN, 13
Device_PG, 12
12
10
Device_BGA, 9
No Of Hops 8
6
4
2
0
Morning
Afternoon
Peak
Off Hours
Figure 4-6 Periodic Representation Of Hop Count From Different Regions
86
From the above graph, it was observed that the number of hops were constant from all the
devices in different region. The lowest number of hops was 9 observed from devices in
Bangalore and the highest no of hops were observed from China with a hop count of 13.
4.3
Deploying Regional Pre-Production AAA Servers
Two AAA servers are integrated in Penang and Shanghai as GAR regional servers. All
devices in China are pointed to the Shanghai AAA server as primary server and
configured with backup server in Penang. Similarly, the rest of the GAR regional devices
are pointed to the Penang server as the primary server and Shanghai server as the
secondary.
As an example, the following round-trip delay is recorded to reach the server within the
region. A trace route is done from a device in Penang and a total of 4 hops were captured
with a minimum round trip delay of maximum 4ms.
Device-PG1#traceroute 198.x.x.x
Type escape sequence to abort.
Tracing the route to aaa-server.pg.corp.xyz.com (198.x.x.x)
1 dist-sw-v901.pg.corp.xyz.com (10.x.x.x) 0 msec 0 msec 4 msec
2 core-router1- v251.pg.corp.xyz.com (132.x.x.x) 0 msec 0 msec
core-router2-v250.pg.corp.xyz.com (132.x.x.x) 0 msec
3 rtap-tengig2-2.wan.pg.corp.com (10.x.x.x) 0 msec
rtbp-tengig2-2.wan.pg.corp.com (10.x.x.x) 0 msec 0 msec
4 aaa-server.pg.corp.xyz.com (198.x.x.x) 0 msec 0 msec 0 msec
Device-PG1#
A ping is performed to get the round trip delay to the AAA server with a maximum RTD
of 4ms.
Device-PG#ping 198.x.x.x
87
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 198.x.x.x, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Device-PG#exit
4.4
Analysis Of Round-Trip-Delay At Different Time Periods For A AAA Server
Within A Region:
The same devices from the three sub-regions Penang, China and Bangalore were used to
analyze the RTD to communicate the AAA server integrated in the GAR region. The
Round-Trip-Delay was captured at four different time periods viz. morning hours, peak
hours, afternoon hours and off hours.
4.4.1
Analysis Of RTD During Morning Hours
The following table provides the stats captured during the morning hours.
Table 4-7 Average Morning Hour Stats For A AAA Server Within A Region
Morning_Hours
MIN
Device1_PG
Device2_PG
Device3_PG
Avg_PG
Device1_BGA
Device2_BGA
Device3_BGA
Avg_BGA
Device1_CHN
Device2_CHN
Device3_CHN
Avg_CHN
Avg_GAR_Morning_RTD
MAX
3
4
3
9
27
28
28
28
26
28
28
27
21
AVG
13
4
4
7
37
29
28
31
27
32
30
30
23
5
4
3
4
29
28
28
28
26
29
28
28
20
88
The following graph displays the averages RTD for the stats captured during morning
hours and a total average of 20ms for all GAR devices is analyzed to reach a server
within the same region.
RTD To Reach TACACS+ Server In The Same Region
During Morning Hours
35
30
Avg_BGA, 28
Avg_CHN, 28
25
Time
in
MilliSeconds(MS)
Avg_GAR_Mornin
g_RTD, 20
20
15
10
5
Avg_PG, 4
0
MIN
MAX
AVG
Figure 4-7 Average RTD During Morning Hours
4.4.2
Analysis Of RTD During Peak Hours
The following table provides the stats captured during the peak hours.
89
Table 4-8 Average Peak Hour Stats For A AAA Server Within A Region
Peak_Hours
Device1_PG
Device2_PG
Device3_PG
Avg_PG
Device1_BGA
Device2_BGA
Device3_BGA
Avg_BGA
Device1_CHN
Device2_CHN
Device3_CHN
Avg_CHN
Avg_GAR_Peak_RTD
MIN
MAX
3
3
4
3
27
27
29
28
27
28
28
28
20
AVG
44
48
52
48
115
283
104
167
41
29
34
35
83
13
15
16
15
76
91
48
72
30
28
29
29
39
The following graph displays the averages RTD for the stats captured during peak hours
and a total average of 40ms for all GAR devices is analyzed to reach a server within the
same region.
RTD To Reach TACACS+ Server In The Same Region
During Peak Hours
180
160
140
120
Time
in
100
MilliSeconds(MS)
80
Avg_BGA, 72
60
Avg_GAR_Peak_R
TD, 39
Avg_CHN, 29
Avg_PG, 15
40
20
0
MIN
MAX
AVG
Figure 4-8 Average RTD During Peak Hours
90
4.4.3
Analysis Of RTD During Afternoon Hours
The following table provides the stats captured during the afternoon hours.
Table 4-9 Average Afternoon Hour Stats For A AAA Server Within A Region
MIN
Afternoon_Hours
Device1_PG
Device2_PG
Device3_PG
Avg_PG
Device1_BGA
Device2_BGA
Device3_BGA
Avg_BGA
Device1_CHN
Device2_CHN
Device3_CHN
Avg_CHN
Avg_GAR_Afternoon_RTD
MAX
AVG
3
4
3
4
3
4
5
4
4
3
27
26
27
27
23
24
24
24
18
4
28
28
30
29
24
24
24
24
19
4
27
27
28
27
23
28
24
25
19
The following graph displays the averages RTD for the stats captured during afternoon
hours and a total average of 19ms for all GAR devices is analyzed to reach a server
within the same region.
91
RTD To Reach TACACS+ Server In The Same Region During
Afternoon Hours
35
30
Avg_BGA, 27
25
Avg_CHN, 25
Time
20
in
MilliSeconds(ms)
15
Avg_GAR_Afterno
on_RTD, 19
10
5
Avg_PG, 4
0
MIN
MAX
AVG
Figure 4-9 Average RTD During Afternoon Hours
4.4.4
Analysis Of RTD During Off-Peak Hours
The following table provides the stats captured during the off peak hours.
Table 4-10 Average Off Peak Stats For A AAA Server Within A Region
Off Peak
Device1_PG
Device2_PG
Device3_PG
Avg_PG
Device1_BGA
Device2_BGA
Device3_BGA
Avg_BGA
Device1_CHN
Device2_CHN
Device3_CHN
Avg_CHN
Avg_GAR_Off Peak_RTD
MIN
MAX
1
1
1
1
25
25
24
25
23
24
24
24
17
AVG
1
1
4
2
28
27
28
28
23
32
24
26
19
4
1
2
2
26
26
24
25
23
25
24
24
17
92
The following graph displays the averages RTD for the stats captured during off peak
hours and a total average of 17ms for all GAR devices is analyzed to reach a server
within the same region.
RTD To Reach TACACS+ Server In The Same Region During
Off Peak Hours
30
Avg_BGA, 25
25
Avg_CHN, 24
20
Avg_GAR_Off
Peak_RTD, 17
Time
15
in
MilliSeconds(MS)
10
5
Avg_PG, 2
0
MIN
MAX
AVG
Figure 4-10 Average RTD During Off-Peak Hours
4.4.5
Analysis Of Average RTD During Different Time Periods
The following table provides the average stats of the different time period analysis
performed above.
Table 4-11 Average Stats For a AAA Server Within A Region
Average RTD
Avg_Morning_RTD
Avg_Peak_RTD
Avg_Offpeak_RTD
Avg_ Afternoon_RTD
MIN
19
19
16
18
MAX
26
67
17
19
AVG
20
40
18
18
93
A graph representation is show below displaying the averages of all time periods.
Average RTD For All GAR Devices To Reach TACACS+ Server
In The Same Region
90
80
70
60
Time
50
in
MilliSeconds(MS) 40
Avg_Peak_RTD, 39
30
Avg_Morning_RTD,
20
20
Avg_Afternoon_RT
D, 19
Avg_Off Peak_RTD,
17
10
0
MIN
MAX
AVG
Figure 4-11 Average RTD At Different Time Periods
It is observed that the Average RTD during the off-peak time and the afternoon time is
18ms which is the lowest RTD. One of the main reasons is that the devices are within the
same geographical location. Moreover, it can be observed that the average round trip
delay is above 40ms while trying to reach AAA server configured in the same region
during peak hours.
94
4.5
Analysis Of Hop Count At Different Time Periods For A AAA Server In The
Same Region:
Trace route was performed from the sub-regional GAR devices in Penang, China and
Bangalore to the AAA server integrated in the same GAR region. The trace was
performed at different time periods during morning, afternoon, peak and off-peak hours.
Table 4-12 Average Hop Count For A AAA Server Within A Region
Avg_Hop_Count Morning Afternoon Peak
4
6
5
Device_PG
Device_BGA
Device_CHN
4
6
5
Off
Hours
4
4
6
6
5
5
Periodic Hops Count To A TACACS+ Server In The
Same Region
14
Device_CHN, 13
Device_PG, 12
12
10
Device_BGA, 9
No Of Hops 8
6
4
2
0
Morning
Afternoon
Peak
Off Hours
Figure 4-12 Periodic Hop Count To A TACACS+ Server In the Same Region
From the above analysis, it was observed that the number of hops were constant from all
the devices in different sub-region to reach a AAA server within the same region. The
95
lowest number of hops was 4 observed from devices in Penang where the AAA server is
actually integrated and the highest no of hops were observed from Bangalore with a hop
count of 6.
4.6
Improvement In Network Performance
The improvement in network performance is measured in both end-to-end Round-TripDelay and Hop Count.
Firstly, the network performance gain is measured by the decrease in average RTD of
having a AAA server outside the region compared to having a server within a region. The
following table shows the summary of the Average RTD at different time periods for
devices in GAR (Penang, China and Bangalore), communicating to a AAA server outside
the region and to a server inside the region.
Table 4-13 Average Performance Improvement in RTD
Average Performance
Improvement
Avg_Morning_RTD
Avg_Peak_RTD
Avg_Afternoon_RTD
Avg_OffHours_RTD
Outside
Region
250
303
220
158
Inside
Region
20
39
19
17
The following graph shows statistical representation of the performance improvement in
RTD.
96
Average Performance Improvement in RTD
350
300
250
Time
200
in
MilliSeconds(MS) 150
100
50
0
Outside
Inside Region
Avg_Morning_RTD
250
20
Avg_Peak_RTD
303
39
Avg_Afternoon_RTD
220
19
Avg_OffHours_RTD
158
17
Figure 4-13 Average Performance Improvement in RTD
It can be observed that a significant drop in average RTD is achieved. The Average RTP
of 303ms at peak time is reduced to 39ms by having a dedicated server for the GAR
devices. Similarly, the Average RTD of 158ms during Off peak time is dropped to 17ms.
It can be concluded that the average performance gain during peak time is
improved by 87.1% and the average performance gain during off peak time is
improved by 89.2%.
Secondly, the performance improvement is also measured by the number of hops reduced
from reaching a server outside the region compared to reaching a server inside the same
region.
97
The following table shows the summary of the Average Hop Count at different time
periods for devices in GAR (Penang, China and Bangalore), communicating to a AAA
server outside the region and to a server inside the region.
Table 4-14 Average Hop Count Improvement
Avg_Hop_Count
Device_PG
Device_BGA
Device_CHN
Outside
Region
Inside
Region
12
9
13
4
5
6
The following graph shows statistical representation of the performance improvement in
Hop Count.
Average Hop Count Improvement
14
12
10
8
Hop Count
6
4
2
0
Outside Region
Inside Region
Device_PG
12
4
Device_BGA
9
5
Device_CHN
13
6
Figure 4-14 Average Hop Count Improvement
It can be observed that a significant drop in average hop count is achieved. The Average
hop count of 12 for devices in Penang communicating with server outside the region is
98
reduced to 4 by communicating to server within the same region. Similarly, the devices in
Bangalore and China sub-regional sites are reduce to 5 and 6 hops respectively.
It can be concluded that the average hop count for devices in PG, where the AAA
server is actually integrated, is improved by 75%. And the average hop count for
devices in sub-regions, Bangalore and China, is improved by ~50%.
99
CHAPTER 5. CONCLUSION
TACACS+ provides an additional layer of security to network devices by enabling AAA
services to network users. It allows access to network services to be regulated on a more
granular basis. Network users connecting to any network device can be authenticated and
authorized against the user database with a custom policy applied. This policy not just
controls what devices a user is authorized to access but also controls what services on a
particular device that a user can access. These administrative policies can be managed by
deploying a centralized TACACS+ architecture with a dedicated master server acting as a
centralized point for global administration and replicating the database to dedicated
region primary and secondary slave servers for authentication, authorization and
accounting.
By deploying these regional slave servers it is analyzed that average performance gain
during peak time is improved by 87.1% and the average performance gain during offpeak time is improved by 89.2%. Secondly, the average hop count for devices in Penang,
where the AAA server is actually integrated, is improved by 75%. And the average hop
count for devices in sub-regions, Bangalore and China, is improved by ~50%. Finally, by
deploying a hierarchal network design, the TACACS+ back and forth request and
response AAA messages encompasses with a dedicated region. Hence the network noise
is limited to a region there by reducing immense noise on core layer.
The analysis done in this project can be extended by virtualize these AAA server and
analyzing the stress testing to provide an additional layer of security and thereby reducing
hardware cost.
100
ACRONMYS
Acronym
Definition
AAA
ACL
ACP
ACS
AS
BGP
CSV
DS
EIGRP
FTP
GAR
GER
HSRP
IOS
IP
LAN
MTU
NAD
NDG
NMS
PPP
RADIUS
RTD
SNMP
TACACS
TCP
VLAN
VTP
WAN
Authentication, Authorization and Accounting
Access Control List
Access Control Protocol
Access Control System
Autonomous System
Border Gateway Protocol
Comma Separated Value
Distribution Switch
Enhanced-Interior Gateway Routing Protocol
File Transfer Protocol
Greater Asian Region
Greater European Region
Host Standby Routing Protocol
Internet Operating System
Internet Protocol
Local Area Network
Maximum Transmission Unit
Network Access Device
Network Device Group
Network Management System
Point to Point Protocol
Remote Access Dial in User Services
Round Trip Delay
Simple Network Management Protocol
Terminal Access Controller Access Control System
Transmission Control Protocol
Virtual LAN
Virtual Trunking Protocol
Wide Area Network
101
REFERENCES
[1]
User Guide for Cisco Secure ACS for Windows 4.0
http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_serve
r_for_windows/4.0/user/guide/o.html#wp82226
[2]
Building Cisco Multilayer Switched Networks, by Richard Froom, Balaji
Sivasubramanian and Erum Frahim (isbn: 1587051508)
[3]
Network Design and Case Studies
ciscopress.com (isbn: 1578701678)
[4]
Enhanced Interior Gateway Routing Protocol
http://www.cisco.com/en/US/products/ps6630/products_ios_protocol_option_ho
me.html
[5]
Deploying IGRP/E-IGRP- Session 2208
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/ps6
630/prod_presentation0900aecd80310f03.pdf
[6]
Cisco Secure ACS 4.2 – Installation Guide
http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_serve
r_for_windows/4.2/installation/guide/windows/install.html
[7]
TACACS & RADIUS Comparisons
http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a0080094e9
9.shtml
[8]
TACACS+ Concepts
http://www.xperiencetech.com/online/tacacs.htm