NU 402: Industry Practice Course
End Semester Report
Internship Period: 04-01-2018 to 07-07-2018
INTERN DETAILS UNIVERISTY DETAILS
K SACHIN REDDY Faculty Mentor: Mr. Jetendra Joshi
U101114FEC210 Off-Campus Faculty Mentor: Mr.BR Murthy
B. Tech 14-18, ECE Date of Submission: 4th July, 2018
ORGANIZATION DETAILS
IP Organization: INFRA-IT SOLUTIONS
Mentor: B CHANDRA MOHAN ( CEO )
ACKNOWLEDGEMENT
I am grateful for being given the internship opportunity with Infra It Solutions where I got a chance to learn new skills and overall professional career development. I am grateful for meeting experienced professionals with great work ethics and I learnt a lot from them.
I would like to take this opportunity to express my soulful gratitude to Mr. Chandra Mohan for mentoring me and enlightening me with your knowledge throughout my internship period; Ms. Lakshmi for providing me a great support and means to achieve deliverables in our project despite of all difficulties; and Mr. Rajesh for being available anytime for clearing non-technical issues and for giving a great work experience in the organization. I would also like to heart fully thank Mr. Jetendra Joshi for constantly motivating me throughout my project to seek the best of it and preparing me to face industry standard problems. I would also like to thank my fellow interns for providing me peer support.
I leverage this opportunity as a huge milestone in my professional career as an engineer. I hope to make use of my skills and knowledge gained all this time for greater good and my upcoming career. Hoping to encounter more of such career-altering work opportunities.
Sincerely,
K SACHIN REDDY
DECLARATION BY STUDENT
I, K SACHIN REDDY, hereby declare that I have successfully completed my six-month internship at Infra It Solutions, starting from 8th January 2018 till 7th July 2018 as part my bachelor’s degree. This report has solely been written by me and no academic credit has been received from any other organization claiming the report.
I have completed my work to the fullest and the contents of this report are novel to the best of my knowledge.
K SACHIN REDDY
U101114FEC210
B. Tech14-18, ECE
NIIT University
ABSTRACT
This report concerns my internship with Infra It Solutions starting from 8th January 2018 till 7thJuly 2018 at Hyderabad, as a mandatory course of Industry Practice as a part of my Bachelor’s degree in ECE at NIIT University, Neemrana. In this final report, I have discussed details of the project and my participation in other company’s projects which I have handled during the six months duration of my internship program.
This report includes a table of contents to give an overview of the topics discussed, followed by a brief introduction to the project taken in internship and few details about the organization. It includes an in-depth explanation of the projects, the tools used to facilitate completion of the same, the challenges faced and gained skills.
As per the record, my officially allotted project got completed a month earlier than the deadline which has CISCO Technical team are involved. In this project the site survey and the technical part was handled by me, under the guidance of my mentor who is a CEO Of my Company. Later as my project was done and they offered me a job position, I was included in the company’s Technical and sales team and I worked on product deliverables of the company.
In this projects, I worked mainly focusing on different CISCO Devices which includes router, switches, Access Points and firewall. These Devices were Configured as per the client requirements. I also worked with State government as the project head for APCRDA Andhra Pradesh.
Note: The project details which I have taken over in the last month as part of company’s product development are kept confidential. The codes and the hardware details for the whole project are also kept confident.
TABLE OF CONTENTS
Topic
PART A: TECHNICAL
1. Introduction
Company background
Objective of Projects
Summary of Work
2. Projects Details
I. Primary Project
Literature Review
Modes of charging
Requirements
Block Diagrams
Global standards
Software architecture
Routers
EIGRP
Switches
HSRP
Programming
Peripheral Descriptions
Prototype Implementation
Results
Tools and Technologies
Challenges
Future Scope
II. Project Aftermath
3. Conclusion
4. References
PART B: NON – TECHNICAL
Certificate
PART A: Technical
1. INTRODUCTION
This report contains a detailed description of my six-month internship carried out as compulsory component of my Bachelor’s degree in ECE. The internship was completed with the organization INFRA-IT SOLUTIONS. Since my interest lies in networking, most of my work, during the internship, was concentrated on the various domains of the same.
There were several factors influencing my decision to take this internship opportunity. The primary factor was a deep interest in Networking ,Routing, Switching , Security and its related technologies. Along with my interest, a company’s performance and reputation is also important. As infra-It Solutions is an CISCO Partner which works in the domain of IT Networking, I found a great potential in the company and wide opportunities too. So, this was my ideal choice of the start of my career as an intern.
1.1 Company Background:
Infra-it Solutions is an CISCO Tier 2 partner delivering futuristic technology for building IT Networking. It is founded in 2009 by Chandra Mohan.
Three main areas of work going on in the company are:
Flexibility: the company use to new organization structure .so the company employees are individual work do freedom. The employees work do end any time and go to home.
Motivational: A group the works do end go home. So other group work is fast. So he is going to home. The employees performance is improvement of salary, promotion etc.
Authority: the company is made many products. So the company made product 1. So product 1 groups different. Product 1 any massages go to individual department. Product 1 groups any decision do them self
Scope / Idea: the company deviated the product different groups. The group made the product new idea. The product made new technology.
Environmental: the company in the work employees any cast. The employees do work in deviated. Employees are into the company happy for every people.
1.2 Project Objectives:
Literature review on Bharat charger standards–
Detailed literature survey into the Bharat standards for development of DC electrical charger product. How to achieve them and the required hardware that need to incorporated to the product and also software support for the embedded systems.
Generate requirement for all the necessary digital systems inside the off-board charger –
Once the literature is gathered, make recommendations for necessary requirements of digital systems which are going to drive the off-board charger.
Generate an architecture of digital sub systems and flow of information amongst different parts of the charger –
Designing hardware as well as software architectures for off-board charger and its sub systems included. Also architectures and flow diagrams for the internal and external communications that need to be carried out according to Bharat standards.
Build the prototype charger digital electronics and test along with the power module–
Building the final prototype adhering to the standards reviewed and incorporating every feature possible with the use of decided hardware resources. Finally, integrating the digital module with the power circuit module to make it a whole charger product.
1.3 Work Summary:
Deliverables I gave as an intern in the company are:
Literature Survey.
Project Documentation.
Creation of architecture diagrams, flow diagrams and charts for the project.
Knowledge Transfer sessions with the team mates.
Presentations and Demonstrations.
Comparisons and recommendations of hardware for the project.
Also published a research paper for an IEEE conference going to be held in October.
2. PROJECT DETAILS
2.1 Primary Project:
Project title: Design and implementation of CISCO Networking Devices.
2.1.1 Literature Review on CISCO Networking Devices:
Worldwide Technology Leader which helps in the Planning of the perfect structure for the Networking Devices. Deals with the different Networking Devices which includes Switches , Router, IP phones , Firewall and Server.
Below mentioned the Chart of the Different network Communication Devices.
Study on Working of Router and Switches:
Routers
Routers are the Networking Devices which helps in Routing. These sends Data Packets. ISP is terminated in the Router in some sites. And for this it routes and Controls the Traffic for the Network to work in controlled flow.
There are types of Routers based on the Usage and the Speed.
Edge Routers:-
? Enterprises experiencing explosive network traffic as mobility, cloud networking, and video and collaboration usage increase: Cisco ASRs consolidate these various traffic streams and apply traffic management and redundancy properties to them to maintain consistent performance among enterprise sites and cloud locations.
? Network service providers needing to deliver high-performance services, such as DCI and branch-office server aggregation, to business customers: Service providers can also use the multiservice routers to deploy hosted and managed services to business and multimedia services to residential customers.
This series are ASR1000 and ASR900.
ASR1000:
Cisco ASR 1000 Series Aggregation Services Routers aggregate multiple WAN connections and network services including encryption and traffic management, and forward them across WAN connections at line speeds from 2.5 to 200 Gbps. The routers contain both hardware and software redundancy in an industry-leading high-availability design.
Below Mentioned are the Chassis Based ASR Edge Router which are the Core for the Networking System.
ASR900:
Cisco ASR 900 Series Aggregation Services Routers are full-featured, modular aggregation platforms. They’re designed for the cost-effective delivery of converged mobile, residential, and business services. You get redundancy, a shallow depth, low power consumption, and high service scale in routers packed with useful features and optimized for small aggregation and remote point-of-presence (POP) applications.
These Core Routers also has the IPSec VPN for the Security Protocol to enable.
Industrial Level (Core Routers):
Easily and rapidly deployable
Highly available, highly secure communications
Reliable operations
Designed for machine-to-machine (M2M) communication and for mobile vehicle communication in harsh environmental conditions
Designed to withstand hostile environments, tolerating a wide temperature range
These industrialized routers deliver enterprise-class features — including highly secure data, voice, and video communications — to stationary and mobile network nodes across wired and wireless links. They can deliver enterprise-grade, wire line-like functionality, such as:
Dynamic Multipoint VPN (DMVPN)
Quality of service (QoS) for cellular
Multi-Virtual Route Forwarding (VRF) for cellular
Cisco I Ox for the 809 and 829 routers, delivering edge application execution across IoT networks
Small Business Routers:
These Routers are Used for small scale offices where they have less number of user. These Routers uses Serial Cards named as EHWIC for the ISP WAN connection.
Configuration of CISCO Devices:
I configured different CISCO devices started with the Initial Configuration. Those configurations depend on the Requirements of the client. Based on those requirements and the network infrastructure we design and install the devices.
Minimum Requirements:
Infrastructure
Network Design
Network Connectivity
Software Used:
We use Putty and HyperTerminal for the configuration of the devices.
Connectivity:
The Connectivity from the device to system will be through straight cable called CONSOLE cable. From the device it is connected through console and the DB9 serial converter.
Some devices we will be using GUI mode for the configuration. Basic switches in the CISCO uses GUI which opens with its default IP address.
The Configuration will be different for the different CISCO devices.
ROUTERS:
Basic Requirements:
WAN IP address
LAN IP address
NATING IP ( if needed)
Username
Password
Based on these requirements we will be configuring the Router.
SWITCHES:
Basic Requirements:
How many VLAN needed
VLAN IP addresses
Interface to which VLAN should be added
Port Access
IP PHONES:
Basic Requirements:
Static IP or Dynamic IP
This IP Phone Configuration depends on the switches VLAN as they through the IP from Particular given Interface.
Sketch an outline of how the Network is connected in between different Devices:
Basic Network Connectivity starts from ISP till the PC. This network connectivity depends on the number of user and the infrastructure of the site.
This connectivity may differ for different infrastructure.
Compilation of acquired literature and ready to work on field:
After all this configuration knowledge and the network diagram we went on site to work.
In that new site they had given the head map for which we need to design the network requirements and suggest the devices which helps in their connectivity.
Here are the example head maps of an organization.
We designed network Infrastructure for this client. And completed the configuration with all the necessary requirements.
Working on Firewall and Installation:
This is the Head among all the Network Devices. The study and installation of the Firewall takes time as it is the core for the Network. Many securities policies are written in this Firewall.
Access rules are created for the NATING of the network for particular website of the organization.
This protects the internal server from the data destruction by the virus attacked form the ISP.
Failover design for the ASA firewall.
2.1.10 CISCO MERAKI
Cisco Meraki is the first Networking Technology in the Cloud Based Configuring and Managing Platform. This Meraki Technology includes all the networking devices.
Wireless Access Points
Switches
Security Appliances
Security Cameras
First thing which guide all this configuration and monitoring part is their Dashboard Interface.
This is the Basic Dashboard which will be provided by the CISCO Meraki.
We can add all the devices including security appliances , Wireless Access Points etc.. The Monitoring is Pretty Accurate that we can have the Detailed Information about the each and every devices connected to the Meraki devices.
These Dashboard is not only the Network Monitoring Software but also address the following
Inventory and Devices which allows administrator for the to manage the devices regardless of the physical location.
Monitoring and Reporting is the Industry- leading application visibility which helps in the Network Monitoring Tool.
Licensing which is the security based which helps in giving access of the dashboard to the single person in the industry. He will be having all the Read and Write access for the devices present.
Organisations and Networks which is the best part of these Dashboard that you can monitor different location at one Dashboard.
Templates and Configuration System is user friendly.
Wireless Access Points:
Meraki is the World First Technology with Cloud Based AP. where the Configuration made Simple.
The Devices Connected to these Access Points will be monitored in the Dashboard . We can also monitor the data usage , Sites Visited etc…
Security Cameras:
These are Cloud based Indoor and Outdoor Cameras which are easy to deploy and configure.
The Monitoring of these can be done within the frames which are necessary.
2.1.11 Network Programming:
CCNA Programming:
Programming Language:
CCNA Programming is described more on the CLI Mode which is the lively nature of the code.
Overviews with Career Information. Cisco is a manufacturer of computer networking equipment that offers particular designations to information technology (IT) professionals. One of these designations is the CCNA, or Cisco Certified Network Associate.
2.1.12 Peripheral Descriptions:
ROUTER SWITCH FIREWALL
Description: Computing Device which forward the data between the Computer Systems. Computing Device which connect the different Networking Devices for the Communication to establish. Network Security Device that Monitors and Controls the Traffic based on the Predetermined Security rules.
Speed: Varies with Different Models Depends on the Throughput of the Router Varies with Different Models.
Table 13. Comparison of different networking peripherals
CISCO ROUTERS:
Router:
Routers are the Networking Devices which helps in Routing. These sends Data Packets. ISP is terminated in the Router in some sites. And for this it routes and Controls the Traffic for the Network to work in controlled flow.
There are types of Routers based on the Usage and the Speed.
Routing in between the different routers is done with the help of different routing Protocols.
1.EIGRP
2. STATIC ROUTING
3.OSPF
4.RIP
5.BGP
5.1 EGP
5.2 IGP
Figure 13. EIGRP
Introduction
Enhanced Interior Gateway Routing Protocol (EIGRP) is an interior gateway protocol suited for many different topologies and media. In a well designed network, EIGRP scales well and provides extremely quick convergence times with minimal network traffic.
EIGRP Theory of Operation
Some of the many advantages of EIGRP are:
very low usage of network resources during normal operation; only hello packets are transmitted on a stable network
when a change occurs, only routing table changes are propagated, not the entire routing table; this reduces the load the routing protocol itself places on the network
rapid convergence times for changes in the network topology (in some situations convergence can be almost instantaneous)
EIGRP is an enhanced distance vector protocol, relying on the Diffused Update Algorithm (DUAL) to calculate the shortest path to a destination within a network.
Major Revisions of the Protocol
There are two major revisions of EIGRP, versions 0 and 1. Cisco IOS versions earlier than 10.3(11), 11.0(8), and 11.1(3) run the earlier version of EIGRP; some explanations in this paper may not apply to that earlier version. We highly recommend using the later version of EIGRP, as it includes many performance and stability enhancements.
Basic Theory
A typical distance vector protocol saves the following information when computing the best path to a destination: the distance (total metric or distance, such as hop count) and the vector (the next hop). For instance, all the routers in the network in Figure 1 are running Routing Information Protocol (RIP). Router Two chooses the path to Network A by examining the hop count through each available path.
Since the path through Router Three is three hops, and the path through Router One is two hops, Router Two chooses the path through One and discards the information it learned through Three. If the path between Router One and Network A goes down, Router Two loses all connectivity with this destination until it times out the route of its routing table (three update periods, or 90 seconds), and Router Three re-advertises the route (which occurs every 30 seconds in RIP). Not including any hold-down time, it will take between 90 and 120 seconds for Router Two to switch the path from Router One to Router Three.
EIGRP, instead of counting on full periodic updates to re-converge, builds a topology table from each of its neighbor’s advertisements (rather than discarding the data), and converges by either looking for a likely loop-free route in the topology table, or, if it knows of no other route, by querying its neighbors. Router Two saves the information it received from both Routers One and Three. It chooses the path through One as its best path (the successor) and the path through Three as a loop-free path (a feasible successor). When the path through Router One becomes unavailable, Router Two examines its topology table and, finding a feasible successor, begins using the path through Three immediately.
From this brief explanation, it is apparent that EIGRP must provide:
a system where it sends only the updates needed at a given time; this is accomplished through neighbor discovery and maintenance
a way of determining which paths a router has learned are loop-free
a process to clear bad routes from the topology tables of all routers on the network
a process for querying neighbors to find paths to lost destinations
We will cover each of these requirements in turn.
Neighbor Discovery and Maintenance
To distribute routing information throughout a network, EIGRP uses non-periodic incremental routing updates. That is, EIGRP only sends routing updates about paths that have changed when those paths change.
The basic problem with sending only routing updates is that you may not know when a path through a neighboring router is no longer available. You can not time out routes, expecting to receive a new routing table from your neighbors. EIGRP relies on neighbor relationships to reliably propagate routing table changes throughout the network; two routers become neighbors when they see each other’s hello packets on a common network.
EIGRP sends hello packets every 5 seconds on high bandwidth links and every 60 seconds on low bandwidth multipoint links.
5-second hello:
broadcast media, such as Ethernet, Token Ring, and FDDI
point-to-point serial links, such as PPP or HDLC leased circuits, Frame Relay point-to-point subinterfaces, and ATM point-to-point subinterface
high bandwidth (greater than T1) multipoint circuits, such as ISDN PRI and Frame Relay
60-second hello:
multipoint circuits T1 bandwidth or slower, such as Frame Relay multipoint interfaces, ATM multipoint interfaces, ATM switched virtual circuits, and ISDN BRIs
The rate at which EIGRP sends hello packets is called the hello interval, and you can adjust it per interface with the command. The hold time is the amount of time that a router will consider a neighbor alive without receiving a hello packet. The hold time is typically three times the hello interval, by default, 15 seconds and 180 seconds. You can adjust the hold time with the ip hold-time eigrp command.
Note that if you change the hello interval, the hold time is not automatically adjusted to account for this change – you must manually adjust the hold time to reflect the configured hello interval.
It is possible for two routers to become EIGRP neighbors even though the hello and hold timers do not match. The hold time is included in the hello packets so each neighbor should stay alive even though the hello interval and hold timers do not match.
While there is no direct way of determining what the hello interval is on a router, you can infer it from the output of show ip eigrp neighbors on the neighboring router.
If you have the output of a show ip eigrp neighbors command from your Cisco device, you can use Cisco CLI Analyzer (registered customers only) to display potential issues and fixes. To use Cisco
The value in the Hold column of the command output should never exceed the hold time, and should never be less than the hold time minus the hello interval (unless, of course, you are losing hello packets). If the Hold column usually ranges between 10 and 15 seconds, the hello interval is 5 seconds and the hold time is 15 seconds. If the Hold column usually has a wider range – between 120 and 180 seconds – the hello interval is 60 seconds and the hold time is 180 seconds. If the numbers do not seem to fit one of the default timer settings, check the interface in question on the neighboring router – the hello and hold timers may have been configured manually.
Note:
EIGRP does not build peer relationships over secondary addresses. All EIGRP traffic is sourced from the primary address of the interface.
When configuring EIGRP over a multi-access Frame Relay network (point-to-multipoint, and so on), configure the broadcast keyword in the frame-relay map statements. Without the broadcast keyword the adjacencies would not establish between two EIGRP routers. Refer to Configuring and Troubleshooting Frame Relay for more information.
There are no limitations on the number of neighbors that EIGRP can support. The actual number of supported neighbors depends on the capability of the device, such as:
memory capacity
processing power
amount of exchanged information, such as the number of routes sent
topology complexity
network stability
Building the Topology Table
Now that these routers are talking to each other, what are they talking about? Their topology tables, of course! EIGRP, unlike RIP and IGRP, does not rely on the routing (or forwarding) table in the router to hold all of the information it needs to operate. Instead, it builds a second table, the topology table, from which it installs routes in the routing table.
Note: As of Cisco IOS versions 12.0T and 12.1, RIP maintains its own database from which it installs routes into the routing table.
To see the basic format of the topology table on a router running EIGRP, issue the show ip eigrp topology command. The topology table contains the information needed to build a set of distances and vectors to each reachable network, including:
lowest bandwidth on the path to this destination as reported by the upstream neighbor
total delay
path reliability
path loading
minimum path maximum transmission unit (MTU)
feasible distance
reported distance
route source (external routes are marked)
Feasible and reported distance are discussed later in this section.
If you have the output of a show ip eigrp topology command from your Cisco device, you can use Cisco CLI Analyzer (registered customers only) to display potential issues and fixes. To use Cisco CLI Analyzer, you must have JavaScript enabled.
EIGRP Metrics
EIGRP uses the minimum bandwidth on the path to a destination network and the total delay to compute routing metrics. Although you can configure other metrics, we do not recommend it, as it can cause routing loops in your network. The bandwidth and delay metrics are determined from values configured on the interfaces of routers in the path to the destination network.
For instance, in Figure 2 below, Router One is computing the best path to Network A.
It starts with the two advertisements for this network: one through Router Four, with a minimum bandwidth of 56 and a total delay of 2200; and the other through Router Three, with a minimum bandwidth of 128 and a delay of 1200. Router One chooses the path with the lowest metric.
Let us compute the metrics. EIGRP calculates the total metric by scaling the bandwidth and delay metrics. EIGRP uses the following formula to scale the bandwidth:
So to reach Network A, Router One chooses the route through Router Three.
Note the bandwidth and delay values we used are those configured on the interface through which the router reaches its next hop to the destination network. For example, Router Two advertised Network A with the delay configured on its Ethernet interface; Router Four added the delay configured on its Ethernet, and Router One added the delay configured on its serial.
Feasible Distance, Reported Distance, and Feasible Successor
Feasible distance is the best metric along a path to a destination network, including the metric to the neighbor advertising that path. Reported distance is the total metric along a path to a destination network as advertised by an upstream neighbor. A feasible successor is a path whose reported distance is less than the feasible distance (current best path). Figure 3 illustrates this process:
Router One sees that it has two routes to Network A: one through Router Three and another through Router Four.
The route through Router Four has a cost of 46277376 and a reported distance of 307200.
The route through Router Three has a cost of 20307200 and a reported distance of 307200.
Note that in each case EIGRP calculates the reported distance from the router advertising the route to the network. In other words, the reported distance from Router Four is the metric to get to Network A from Router Four, and the reported distance from Router Three is the metric to get to Network A from Router Three. EIGRP chooses the route through Router Three as the best path, and uses the metric through Router Three as the feasible distance. Since the reported distance to this network through Router Four is less than the feasible distance, Router One considers the path through Router Four a feasible successor.
When the link between Routers One and Three goes down, Router One examines each path it knows to Network A and finds that it has a feasible successor through Router Four. Router One uses this route, using the metric through Router Four as the new feasible distance. The network converges instantly, and updates to downstream neighbors are the only traffic from the routing protocol.
Let us look at a more complex scenario, shown in Figure 4.
There are two routes to Network A from Router One: one through Router Two with a metric of 46789376 and another through Router Four with a metric of 20307200. Router One chooses the lower of these two metrics as its route to Network A, and this metric becomes the feasible distance. Next, let us look at the path through Router Two to see if it qualifies as a feasible successor. The reported distance from Router Two is 46277376, which is higher than the feasible distance – so this path is not a feasible successor. If you were to look in the topology table of Router One at this point (using show ip eigrp topology), you would only see one entry for Network A – through Router Four. (In reality there are two entries in the topology table at Router One, but only one will be a feasible successor, so the other will not be displayed in show ip eigrp topology; you can see the routes that are not feasible successors using show ip eigrp topology all-links ).
Let us suppose that the link between Router One and Router Four goes down. Router One sees that it has lost its only route to Network A, and queries each of its neighbors (in this case, only Router Two) to see if they have a route to Network A. Since Router Two does have a route to Network A, it responds to the query. Since Router One no longer has the better route through Router Four, it accepts this route through Router Two to Network A.
Deciding if a Path is Loop-Free
How does EIGRP use the concepts of feasible distance, reported distance, and feasible successor to determine if a path is valid, and not a loop? In Figure 4a, Router Three examines routes to Network A. Since split horizon is disabled (for example, if these are multipoint Frame Relay interfaces), Router Three shows three routes to Network A: through Router Four, through Router Two (path is two, one, three, four), and through Router One (path is one, two, three, four).
If Router Three accepts all of these routes, it results in a routing loop. Router Three thinks it can get to Network A through Router Two, but the path through Router Two passes through Router Three to get to Network A. If the connection between Router Four and Router Three goes down, Router Three believes it can get to Network A through one of the other paths, but because of the rules for determining feasible successors, it will never use these paths as alternates. Let us look at the metrics to see why:
total metric to Network A through Router Four: 20281600
total metric to Network A through Router Two: 47019776
total metric to Network A through Router One: 47019776
Since the path through Router Four has the best metric, Router Three installs this route in the forwarding table and uses 20281600 as its feasible distance to Network A. Router Three then computes the reported distance to Network A through Routers Two and One: 47019776 for the path through Router Two, and 47019776 for the path through Router One. Because both of these metrics are greater than the feasible distance, Router Three does not install either route as a feasible successor for Network A.
Suppose that the link between Routers Three and Four goes down. Router Three queries each of its neighbors for an alternative route to Network A. Router Two receives the query and, because the query is from its successor, searches each of the other entries in its topology table to see if there is a feasible successor. The only other entry in the topology table is from Router One, with a reported distance equal to the last known best metric through Router Three. Because the reported distance through Router One is not less than the last known feasible distance, Router Two marks the route as unreachable and queries each of its neighbors – in this case, only Router One – for a path to Network A.
Router Three also sends a query for Network A to Router One. Router One examines its topology table and finds that the only other path to Network A is through Router Two with a reported distance equal to the last known feasible distance through Router Three. Once again, since the reported distance through Router Two is not less than the last known feasible distance, this route is not a feasible successor. Router One marks the route as unreachable and queries its only other neighbor, Router Two, for a path to Network A.
This is the first level of queries. Router Three has queried each of its neighbors in an attempt to find a route to Network A. In turn, Routers One and Two have marked the route unreachable, and queried each of their remaining neighbors in an attempt to find a path to Network A. When Router Two receives the Router One query, it examines its topology table and notes that the destination is marked as unreachable. Router Two replies to Router One that Network A is unreachable. When Router One receives the Router Two query, it also sends back a reply that Network A is unreachable. Now Routers One and Two have both concluded that Network A is unreachable, and they reply to the original Router Three query. The network has converged, and all routes return to the passive state.
Split Horizon and Poison Reverse
In the previous example, we assumed that split horizon was not in effect to show how EIGRP uses the feasible distance and the reported distance to determine if a route is likely to be a loop. In some circumstances, however, EIGRP uses split horizon to prevent routing loops as well. Before dealing with the details of how EIGRP uses split horizon, let us review what split horizon is and how it works. The split horizon rule states:
Never advertise a route out of the interface through which you learned it.
For instance, in Figure 4a, if Router One is connected to Routers Two and Three through a single multipoint interface (such as Frame Relay), and Router One learned about Network A from Router Two, it will not advertise the route to Network A back out the same interface to Router Three. Router One assumes that Router Three would learn about Network A directly from Router Two.
Poison reverse is another way of avoiding routing loops. Its rule states:
Once you learn of a route through an interface, advertise it as unreachable back through that same interface.
Let us say the routers in Figure 4a have poison reverse enabled. When Router One learns about Network A from Router Two, it advertises Network A as unreachable through its link to Routers Two and Three. Router Three, if it shows any path to Network A through Router One, removes that path because of the unreachable advertisement. EIGRP combines these two rules to help prevent routing loops.
EIGRP uses split horizon or advertises a route as unreachable when:
two routers are in startup mode (exchanging topology tables for the first time)
advertising a topology table change
sending a query
Let us examine each of these situations.
Startup Mode
When two routers first become neighbors, they exchange topology tables during startup mode. For each table entry a router receives during startup mode, it advertises the same entry back to its new neighbor with a maximum metric (poison route).
Topology Table Change
In Figure 5, Router One uses variance to balance the traffic destined to Network A between the two serial links – the 56k link between Routers Two and Four, and the 128k link between Routers Three and Four (see the “Load Balancing” section for a discussion of variance).
Router Two sees the path through Router Three as a feasible successor. If the link between Routers Two and Four goes down, Router Two simply re-converges on the path through Router Three. Since the split horizon rule states that you should never advertise a route out the interface through which you learned about it, Router Two would not normally send an update. However, this leaves Router One with an invalid topology table entry. When a router changes its topology table in such a way that the interface through which the router reaches a network changes, it turns off split horizon and poison reverses the old route out all interfaces. In this case, Router Two turns off split horizon for this route, and advertises Network A as unreachable. Router One hears this advertisement and flushes its route to Network A through Router Two from its routing table.
Queries
Queries result in a split horizon only when a router receives a query or update from the successor it is using for the destination in the query. Let us take a look at the network in Figure 6.
Router Three receives a query concerning 10.1.2.0/24 (which it reaches through Router One) from Router Four. If Three does not have a successor for this destination because a link flap or other temporary network condition, it sends a query to each of its neighbors; in this case, Routers One, Two, and Four. If, however, Router Three receives a query or update (such as a metric change) from Router One for the destination 10.1.2.0/24, it does not send a query back to Router One, because Router One is its successor to this network. Instead, it only sends queries to Routers Two and Four.
Stuck In Active Routes
In some circumstances, it takes a very long time for a query to be answered. So long, in fact, that the router that issued the query gives up and clears its connection to the router that is not answering, effectively restarting the neighbor session. This is known as a stuck in active (SIA) route. The most basic SIA routes occur when it simply takes too long for a query to reach the other end of the network and for a reply to travel back. For instance, in Figure 7, Router One is recording a large number of SIA routes from Router Two.
After some investigation, the problem is narrowed down to the delay over the satellite link between Routers Two and Three. There are two possible solutions to this type of problem. The first is to increase the amount of time the router waits after sending a query before declaring the route SIA. This setting can be changed using the timers active-time command.
The better solution, however, is to redesign the network to reduce the range of queries (so very few queries pass over the satellite link). Query range is covered in the “Query Range” section. Query range in itself, however, is not a common reason for reported SIA routes. More often, some router on the network can not answer a query for one of the following reasons:
the router is too busy to answer the query (generally due to high CPU utilization)
the router is having memory problems, and cannot allocate the memory to process the query or build the reply packet
the circuit between the two routers is not good – enough packets are getting through to keep the neighbor relationship up, but some queries or replies are getting lost between the routers
unidirectional links (a link on which traffic can only flow in one direction because of a failure)
Troubleshooting SIA Routes
Troubleshooting SIA routes is generally a three-step process:
Find the routes that are consistently being reported as SIA.
Find the router that is consistently failing to answer queries for these routes.
Find the reason that router is not receiving or answering queries.
The first step should be fairly easy. If you are logging console messages, a quick perusal of the log indicates which routes are most frequently marked SIA. The second step is more difficult. The command to gather this information is show ip eigrp topology active:
Any neighbors that show an R have yet to reply (the active timer shows how long the route has been active). Note that these neighbors may not show up in the Remaining replies section; they may appear among the other RDBs. Pay particular attention to routes that have outstanding replies and have been active for some time, generally two to three minutes. Run this command several times and you begin to see which neighbors are not responding to queries (or which interfaces seem to have a lot of unanswered queries). Examine this neighbor to see if it is consistently waiting for replies from any of its neighbors. Repeat this process until you find the router that is consistently not answering queries. You can look for problems on the link to this neighbor, memory or CPU utilization, or other problems with this neighbor.
If you run into a situation where it seems that the query range is the problem, it is always best to reduce the query range rather than increasing the SIA timer.
Redistribution
This section examines different scenarios involving redistribution. Please note that the examples below show the minimum required to configure redistribution. Redistribution can potentially cause problems, such as below-optimal routing, routing loops, or slow convergence. To avoid these problems, please see “Avoiding Problems Due to Redistribution” in Redistributing Routing Protocols.
Router Three is advertising the network 10.1.2.0/24 to Router Two through autonomous system 1000; Router Two is redistributing this route into autonomous system 2000 and advertising it to Router One.
Note: The routes from EIGRP 1000 are tagged 1000 before redistributing them to EIGRP 2000. When routes from EIGRP 2000 are redistributed back to EIGRP 1000, the routes with 1000 tags are denied to ensure a loop-free topology. For more information on redistribution among routing protocols, please see Redistributing Routing Protocols.
On Router One, we see:
External protocol is EIGRP, external metric is 46251776
Administrator tag is 1000 (0x000003E8)
Notice that although the link between Routers One and Two has a bandwidth of 1.544Mb, the minimum bandwidth shown in this topology table entry is 56k. This means that EIGRP preserves all metrics when redistributing between two EIGRP autonomous systems.
Note the metrics for these two routes are the same after being scaled from IGRP to EIGRP (see the “Metrics section):
12001 x 256 = 3072256
where 12001, an IGRP metric, is through Router One; and 3072256, an EIGRP metric, is through Router Four.
Router Two prefers the EIGRP external route with the same metric (after scaling) and a higher administrative distance. This is true whenever automatic redistribution occurs between EIGRP and IGRP within the same autonomous system. The router always prefers the path with the lowest cost metric and ignores the administrative distance.
Redistribution To and From Other Protocols
Redistribution between EIGRP and other protocols – RIP and OSPF, for example – works in the same way as all redistribution. It is always best to use the default metric when redistributing between protocols. You should be aware of the following two issues when redistributing between EIGRP and other protocols:
Routes redistributed into EIGRP are not always summarized – see the “Summarization” section for an explanation.
External EIGRP routes have an administrative distance of 170.
Redistribution of Static Routes to Interfaces
When you install a static route to an interface, and configure a network statement using router eigrp, which includes the static route, EIGRP redistributes this route as if it were a directly connected interface. Let us look at the network in Figure 12.
Summarization
There are two forms of summarization in EIGRP: auto-summaries and manual summaries.
Auto-Summarization
EIGRP performs an auto-summarization each time it crosses a border between two different major networks. For example, in Figure 13, Router Two advertises only the 10.0.0.0/8 network to Router One, because the interface Router Two uses to reach Router One is in a different major network.
There are some caveats when dealing with the summarization of external routes that are covered later in the “Auto-Summarization of External Routes” section.
We can expect the following to happen regarding network 192.168.3.0/24 (far right side):
Router One has two paths to 192.168.3.0/24:
through Router Two with a distance of 46533485 and a reported distance of 20307200
through Router Three with a distance of 20563200 and a reported distance of 20307200
Router One chooses the path through Router Three and keeps the path through Router Two as a feasible successor
Routers Two and Three show one path to 192.168.3.0/24 through Router Four
Suppose that 192.168.3.0/24 fails. What activity can we expect to see on this network? Figures 16a through 16h illustrate the process.
Router Five marks 192.168.3.0/24 as unreachable, and queries Router Four:
Router Four, upon receiving a query from its successor, attempts to find a new feasible successor to this network. It does not find one, so it marks 192.168.3.0/24 as unreachable and query Routers Two and Three:
Routers Two and Three, in turn, see that they have lost their only feasible route to 192.168.3.0/24, and mark it as unreachable; they both send queries to Router One:
For simplicity, let us assume that Router One receives the query from Router Three first, and marks the route as unreachable. Router One then receives the query from Router Two. Although another order is possible, they will all have the same final result.
Router One replies to both queries with unreachables; Router One is now passive for 192.168.3.0/24:
Routers Two and Three reply to the query from Router Four; Routers Two and Three are now passive for 192.168.3.0/24:
Router Five, upon receiving the reply from Router Four, removes network 192.168.3.0/24 from its routing table; Router Five is now passive for network 192.168.3.0/24. Router Five sends updates back to Router Four so the route is removed from the topology and routing tables of the remaining routers.
It is important to understand that although there may be other query paths or processing orders, all routers in the network process a query for network 192.168.3.0/24 when that link goes down. Some routers may end up processing more than one query (Router One in this example). In fact, if the queries were to reach the routers in a different order, some would end up processing three or four queries. This is a good example of an unbounded query in an EIGRP network.
How Summarization Points Affect the Query Range
Now let us look at the paths to 10.1.1.0/24 in the same network:
Router Two has a topology table entry for the 10.1.1.0/24 network with a cost of 46251885 through Router One.
Router Three has a topology table entry for the 10.1.1.0/24 network with a cost of 20281600 through Router One.
Router Four has a topology table entry for the 10.0.0.0/8 network (because Routers Two and Three are autosummarizing to the major network boundary) through Router Three with a metric of 20307200 (the reported distance through Router Two is higher than the total metric through Router Three, so the path through Router Two is not a feasible successor).
If 10.1.1.0/24 goes down, Router One marks it as unreachable, and then queries each of its neighbors (Routers Two and Three) for a new path to that network:
Router Two, on receiving the query from Router One, marks the route as unreachable (because the query is from its successor) and then queries Routers Four and Three:
Router Three, when it receives the query from Router One, marks the destination as unreachable and queries Routers Two and Four:
Router Four, when it receives the queries from Routers Two and Three, replies that 10.1.1.0/24 is unreachable (note that Router Four has no knowledge of the subnet in question, since it only has the 10.0.0.0/8 route):
Routers Two and Three reply to each other that 10.1.1.0/24 is unreachable:
Since Routers Two and Three now have no outstanding queries, they both reply to Router One that 10.1.1.0/24 is unreachable:
The query, in this case, is bounded by the autosummarization at Routers Two and Three. Router Five does not participate in the query process, and is not involved in the re-convergence of the network. Queries can also be bound by manual summarization, autonomous system borders, and distribution lists.
How Autonomous System Boundaries Affect the Query Range
If a router is redistributing routes between two EIGRP autonomous systems, it replies to the query within the normal processing rules and launches a new query into the other autonomous system. For example, if the link to the network attached to Router Three goes down, Router Three marks the route unreachable and queries Router Two for a new path:
Router Two replies that this network is unreachable and launches a query into autonomous system 200 toward Router One. Once Router Three receives the reply to its original query, it removes the route from its table. Router Three is now passive for this network:
Router One replies to Router Two, and the route goes passive:
While the original query did not propagate throughout the network (it was bound by the autonomous system border), the original query leaks into the second autonomous system in the form of a new query. This technique may help to prevent stuck in active (SIA) problems in a network by limiting the number of routers a query must pass through before being answered, but it does not solve the overall problem that each router must process the query. In fact, this method of bounding a query may worsen the problem by preventing the auto-summarization of routes that would otherwise be summarized (external routes are not summarized unless there is an external component in that major network).
How Distribution Lists Affect the Query Range
Rather than block the propagation of a query, distribution lists in EIGRP mark any query reply as unreachable. Let us use Figure 19 as an example.
In the figure above:
Router Three has a distribute-list applied against its serial interfaces that only permits it to advertise Network B.
Routers One and Two do not know that Network A is reachable through Router Three (Router Three is not used as a transit point between Routers One and Two).
Router Three uses Router One as its preferred path to Network A, and does not use Router Two as a feasible successor.
When Router One loses its connection to Network A, it marks the route as unreachable and sends a query to Router Three. Router Three does not advertise a path to Network A because of the distribution list on its serial ports.
Router Three marks the route as unreachable, then queries Router Two:
Router Two examines its topology table and finds that it has a valid connection to Network A. Note the query was not affected by the distribution list in Router Three:
Router Two replies that Network A is reachable; Router Three now has a valid route:
Router Three builds the reply to the query from Router One, but the distribution list causes Router Three to send a reply that Network A is unreachable, even though Router Three has a valid route to Network A:
Pacing Packets
Some routing protocols consume all of the available bandwidth on a low bandwidth link while they are converging (adapting to a change in the network). EIGRP avoids this congestion by pacing the speed at which packets are transmitted on a network, thereby using only a portion of the available bandwidth. The default configuration for EIGRP is to use up to 50 percent of the available bandwidth, but this can be changed with the following command:
This allows a packet (or groups of packets) of at least 512 bytes to be transmitted on this link before EIGRP sends its packet. The pacing timer determines when the packet is sent, and is typically expressed in milliseconds. The pacing time for the packet in the above example is 0.1463 seconds. There is a field in show ip eigrp interface that displays the pacing timer, as shown below:
router# show ip eigrp interface
IP-EIGRP interfaces for process 2
The time displayed is the pacing interval for the maximum transmission unit (MTU), the largest packet that can be sent over the interface.
Default Routing
There are two ways to inject a default route into EIGRP: redistribute a static route or summarize to 0.0.0.0/0. Use the first method when you want to draw all traffic to unknown destinations to a default route at the core of the network. This method is effective for advertising connections to the Internet. For example:
The static route that is redistributed into EIGRP does not have to be to network 0.0.0.0. If you use another network, you must use the ip default-network command to mark the network as a default network. Refer to Configuring a Gateway of Last Resort for further information.
Summarizing to a default route is effective only when you want to provide remote sites with a default route. Since summaries are configured per interface, you do not need to worry about using distribute-lists or other mechanisms to prevent the default route from being propagated toward the core of your network. Note that a summary to 0.0.0.0/0 overrides a default route learned from any other routing protocol. The only way to configure a default route on a router using this method is to configure a static route to 0.0.0.0/0. (Beginning in Cisco IOS Software 12.0(4)T, you can also configure an administrative distance on the end of the ip summary-address eigrp command, so the local summary does not override the 0.0.0.0/0 route).
Load Balancing
EIGRP puts up to four routes of equal cost in the routing table, which the router then load-balances. The type of load balancing (per packet or per destination) depends on the type of switching being done in the router. EIGRP, however, can also load-balance over unequal cost links.
Note: Using max-paths, you can configure EIGRP to use up to six routes of equal cost.
Let us say there are four paths to a given destination, and the metrics for these paths are:
The router sends the first three packets over path 1, the next three packets over path 2, the next two packets over path 3, and the next packet over path 4. The router then restarts by sending the next three packets over path 1, and so on.
Note: Even with variance configured, EIGRP will not send traffic over an unequal cost path if the reported distance is greater than the feasible distance for that particular route. Refer to the “Feasible Distance, Reported Distance, and Feasible Successors” section for more information.
Using the Metrics
When you initially configure EIGRP, remember these two basic rules if you are attempting to influence EIGRP metrics:
The bandwidth should always be set to the real bandwidth of the interface; multipoint serial links and other mismatched media speed situations are the exceptions to this rule.
The delay should always be used to influence EIGRP routing decisions.
Because EIGRP uses the interface bandwidth to determine the rate at which to send packets, it is important that these be set correctly. If it is necessary to influence the path EIGRP chooses, always use delay to do so.
At lower bandwidths, the bandwidth has more influence over the total metric; at higher bandwidths, the delay has more influence over the total metric.
Using Administrative Tags in Redistribution
External administrative tags are useful for breaking redistribution routing loops between EIGRP and other protocols. By tagging the route when it is redistributed into EIGRP, you can block redistribution from EIGRP into the external protocol. It is not possible to modify the administrative distance for a default gateway that was learned from an external route because, in EIGRP, the modification of the administrative distance only applies for internal routes. In order to raise the metric, use a route-map with prefix-list; do not change the administrative distance. A basic example of configuring these tags follows, but this example does not show the entire configuration used for breaking redistribution loops.
Note that 172.19.1.0/24 is missing.
Understanding EIGRP Command Output
show ip eigrp traffic
This command is used to display information about EIGRP named configurations and EIGRP autonomous-system (AS) configurations. The output of this command shows the information that has been exchanged between the neighboring EIGRP router. An explanation of each output field follows the table.
Configuration Explanations
Hellos sent/received shows the number of hello packets sent and received (sent -1927/received – 1930).
Updates sent/received displays the number of update packets sent and received (sent-20/received-39).
Queries sent/received means the number of query packets sent and received (sent-10/received-18).
Replies sent/received shows the number of reply packets sent and received (sent-18/received-16).
Acks sent/received stands for the number of acknowledgment packets sent and received (sent-66/received-41).
SIA-Queries sent/received means number of stuck in active query packets sent and received (sent-0/received-0).
SIA-Replies sent/received displays the number of stuck in active reply packets sent and received (sent-0/received-0).
Hello Process ID is the hello process identifier (270).
PDM Process ID stands for protocol-dependant module IOS process identifier (251).
Socket Queue displays the IP to EIGRP Hello Process socket queue counters (current-0/max-2000/highest-1/drops-0).
Input Queue shows the EIGRP Hello Process to EIGRP PDM socket queue counters (current-0/max-2000/highest-1/drops-0).
show ip eigrp topology
This command only displays feasible successors. To display all entries in the topology table, use the show ip eigrp topology all-links command. An explanation of each output field follows the table.
Configuration Explanations
A means active. This could also show a P, meaning passive.
10.2.4.0/24 is the destination or mask.
0 successors shows how many successors (or paths) are available for this destination; if successors is capitalized, the route is in transition.
FD is 512640000 shows the feasible distance, which is the best metric to reach this destination or the best metric known when the route went active.
tag is 0x0 can be set and/or filtered using route maps with the set tag and match tag commands.
Q means a query is pending. This field can also be: U, for update pending; or R, for reply pending.
1 replies shows the number of outstanding replies.
active 00:00:01 shows how long this route has been active.
query origin: Local origin shows this route originated the query. This field can also be: Multiple origins, meaning that multiple neighbors have sent queries on this destination, but not the successor; or Successor origin, meaning the successor originated the query.
via 10.1.2.2 shows that we learned of this route from a neighbor whose IP address is 10.1.2.2. This field can also be: Connected, if the network is directly connected to this router; Redistributed, if this route is being redistributed into EIGRP on this router; or Summary, if this is a summary route generated on this router.
(Infinity/Infinity) shows the metric to reach this path through this neighbor in the first field, and the reported distance through this neighbor in the second field.
r shows that we have queried this neighbor and are waiting for a reply.
Q is the send flag for this route, meaning there is a query pending. This field can also be: U, meaning there is an update pending; or R, meaning there is a reply pending.
Serial1 is the interface through which this neighbor is reachable.
Via 10.1.1.2 shows the neighbor from which we are waiting for a reply.
r shows that we have queried this neighbor about the route and have not yet received a reply.
Serial0 is the interface through which this neighbor is reachable.
Via 10.1.2.2 (512640000/128256), Serial1 shows we are using this route (indicates which path the next path/destination will take when there are multiple routes of equal cost).
show ip eigrp topology <network>
This command displays all entries in the topology table for this destination, not just feasible successors. An explanation of each output field follows the table.
Configuration Explanations
State is Passive means the network is in passive state, or, in other words, we are not looking for a path to this network. Routes are almost always in a passive state in stable networks.
Query origin flag is 1 If this route is active, this field provides information on who originated the query.
0: This route is active but no query has been originated for it (we are searching for a feasible successor locally).
1: This router originated the query for this route (or the route is passive).
2: Multiple diffusing computations for this query. This router has received more than one query for this route from more than one source.
3: The router that we learned the path to this network from is querying for another route.
4: Multiple query sources for this route, including the router through which we learned this route. Similar to 2, but it also means there is a query origin string which describes the queries outstanding for this path.
2 Successor(s) means there are two feasible paths to this network.
FD is 307200 shows the best current metric to this network. If the route is active, this indicates the metric of the path we were previously using to route packets to this network.
Routing Descriptor Blocks Each of the following entries describes one path to the network.
10.1.1.2 (Ethernet1) is the next hop to the network and the interface that next hop is reached through.
from 10.1.2.2 is the source of this path information.
Send flag is:
0x0: If there are packets that need to be sent in relation to this entry, this indicates the type of packet.
0x1: This router has received a query for this network, and needs to send a unicast reply.
0x2: This route is active, and a multicast query should be sent.
0x3: This route has changed, and a multicast update should be sent.
Composite metric is (307200/281600) shows the total calculated costs to the network. The first number in the parentheses is the total cost to the network through this path, including the cost to the next hop. The second number in the parentheses is the reported distance, or, in other words, the cost the next hop router uses.
Route is Internal means this route was originated within this EIGRP autonomous system (AS). If the route was redistributed into this EIGRP AS, this field would indicate that the route is External.
Vector metric shows the individual metrics used by EIGRP to calculate the cost to a network. EIGRP does not propagate total cost information throughout the network; the vector metrics are propagated, and each router computes the cost and reported distance individually.
Minimum bandwidth is 10000 Kbit shows the lowest bandwidth on the path to this network.
Total delay is 2000 microseconds shows the sum of the delays on the path to this network.
Reliability is 0/255 shows a reliability factor. This number is calculated dynamically, but is not used by default in metric calculations.
Load is 1/255 indicates the amount of load the link is carrying. This number is calculated dynamically, and is not used by default when EIGRP calculates the cost to use this path.
Minimum MTU is 1500 This field is not used in metric calculations.
Hop count is 2 This is not used in metric calculations, but does limit the maximum size of an EIGRP AS. The maximum number of hops that EIGRP will accept is 100 by default, although the maximum can be configured to 220 with metric maximum hops.
If the route is external, the following information is included. An explanation of each output field follows the table.
to the EIGRP AS.
External AS shows the Autonomous System this route came from (if there is one).
External Protocol shows the protocol this route came from (if there is one).
external metric shows the internal metric in the external protocol.
Administrator Tag can be set and/or filtered using route maps with the set tag and match tag commands.
show ip eigrp topology active | pending | zero-successors
Same output format as show ip eigrp topology , but it also shows some portion of the topology table.
show ip eigrp topology all-links
Same output format as show ip eigrp topology , but it also shows all links in the topology table, rather than just feasible successors.
SWITCHING:
IntroductionThis document describes the features and functionality of Hot Standby Router Protocol (HSRP).
PrerequisitesRequirementsThere are no specific requirements for this document.
Components UsedThis document is not restricted to specific software and hardware versions.
ConventionsFor more information on document conventions, refer to Cisco Technical Tips Conventions.
HSRP Background and OperationsOne way to achieve near-100 percent network uptime is to use HSRP, which provides network redundancy for IP networks, ensuring that user traffic immediately and transparently recovers from first hop failures in network edge devices or access circuits.
By sharing an IP address and a MAC (Layer 2) address, two or more routers can act as a single “virtual” router. The members of the virtual router group continually exchange status messages. This way, one router can assume the routing responsibility of another, should it go out of commission for either planned or unplanned reasons. Hosts continue to forward IP packets to a consistent IP and MAC address, and the changeover of devices doing the routing is transparent.
Dynamic Router Discovery MechanismsBelow are descriptions of dynamic router discovery mechanisms that are available to hosts. Many of these mechanisms don’t provide the network resiliency required by network administrators. This may be because the protocol wasn’t initially intended to provide network resiliency or because it isn’t feasible for every host on a network to be running the protocol. In addition to what is listed below, it is important to note that many hosts only allow you to configure a default-gateway.
Proxy Address Resolution ProtocolSome IP hosts use proxy Address Resolution Protocol (ARP) to select a router. When a host runs proxy ARP, it sends an ARP request for the IP address of the remote host it wants to contact. A router, Router A, on the network replies on behalf of the remote host and provides its own MAC address. With proxy ARP, the host behaves as if the remote host were connected to the same segment of the network. If Router A fails, the host continues to send packets destined for the remote host to the MAC address of Router A even though those packets have nowhere to go and are lost. You can either wait for ARP to acquire the MAC address of another router, Router B, on the local segment by sending another ARP request, or reboot the host to force it to send an ARP request. In either case, for a significant period of time, the host can’t communicate with the remote host, even though the routing protocol has converged, and Router B is prepared to transfer packets that would otherwise go through Router A.
Dynamic Routing ProtocolSome IP hosts run (or snoop) a dynamic routing protocol such as the Routing Information Protocol (RIP) or Open Shortes Path First (OSPF) to discover routers. The drawback of using RIP is that it is slow to adapt to changes in the topology. Running a dynamic routing protocol on every host may not be feasible for a number of reasons, including administrative overhead, processing overhead, security issues, or lack of a protocol implementation for some platforms.
ICMP Router Discovery ProtocolSome newer IP hosts use ICMP Router Discovery Protocol (IRDP) (RFC 1256 ) to find a new router when a route becomes unavailable. A host that runs IRDP listens for hello multicast messages from its configured router and uses an alternate router when it no longer receives those hello messages. The default timer values of IRDP mean that it’s not suitable for detection of failure of the first hop. The default advertisement rate is once every 7 to 10 minutes, and the default lifetime is 30 minutes.
Dynamic Host Configuration ProtocolDynamic Host Configuration Protocol (DHCP) (RFC 1531 ) provides a mechanism for passing configuration information to hosts on a TCP/IP network. A host that runs a DHCP client requests configuration information from a DHCP server when it boots onto the network. This configuration information typically comprises an IP address and a default gateway. There is no mechanism for switching to an alternative router if the default gateway fails.
HSRP OperationA large class of legacy host implementations that don’t support dynamic discovery are capable of configuring a default router. Running a dynamic router discovery mechanism on every host may not be feasible for a number of reasons, including administrative overhead, processing overhead, security issues, or lack of a protocol implementation for some platforms. HSRP provides failover services to these hosts.
Using HSRP, a set of routers works in concert to present the illusion of a single virtual router to the hosts on the LAN. This set is known as an HSRP group or a standby group. A single router elected from the group is responsible for forwarding the packets that hosts send to the virtual router. This router is known as the Active router. Another router is elected as the Standby router. In the event that the Active router fails, the Standby assumes the packet-forwarding duties of the Active router. Although an arbitrary number of routers may run HSRP, only the Active router forwards the packets sent to the virtual router.
To minimize network traffic, only the Active and Standby routers send periodic HSRP messages once the protocol has completed the election process. If the Active router fails, the Standby router takes over as the Active router. If the Standby router fails or becomes the Active router, then another router is elected as the Standby router.
On a particular LAN, multiple hot standby groups may coexist and overlap. Each standby group emulates a single virtual router. The individual routers may participate in multiple groups. In this case, the router maintains separate state and timers for each group.
Each standby group has a single, well-known MAC address, as well as an IP address.
HSRP AddressingIn most cases when you configure routers to be part of an HSRP group, they listen for the HSRP MAC address for that group as well as their own burned-in MAC address. The exception is routers whose Ethernet controllers only recognize a single MAC address (for example, the Lance controller on the Cisco 2500 and Cisco 4500 routers). These routers use the HSRP MAC address when they are the Active router, and their burned-in address when they are not.
HSRP uses the following MAC address on all media except Token Ring:
Token Ring interfaces use functional addresses for the HSRP MAC address. Functional addresses are the only general multicast mechanism available. There are a limited number of Token Ring functional addresses available and many of them are reserved for other functions. You can use the following three addresses with HSRP:
Note: When HSRP runs in a multiple-ring source-route bridging (SRB) environment and the HSRP routers reside on different rings, using the functional addresses can cause Routing Information Field (RIF) confusion. For example, in an SRB environment, it is possible that an HSRP standby router resides on a different ring than the active router. When this standby router becomes active, stations on the same ring as the old active router need a new RIF in order to send packets to the new active router. However, since the standby (new active) router is using the same functional address as the previous active router the stations are not aware that they must send explorers for a new RIF. For this reason, the use-bia command was introduced.
Cisco IOS Release and HSRP Functionality MatrixThis document shows which HSRP features are supported in which Cisco IOS® Software releases. Click on a feature to see a detailed description. An interim release number indicates in which release a feature first appeared, or a release where the functionality of that feature changed.
Feature 10.0 10.2 10.3 11.0 11.1 11.2 11.3 12.0 12.0T 12.1 12.1T
PreemptionX X X X X X X X X X X
Multiple Groups (MHSRP)— — X X X X X X X X X
Ethernet 802.10 SDE— — — — X X X X X X X
Interface Tracking— — — — X X X X X X X
Use BIA— — — — 8.0 X X X X X X
Preempt Delay— — — — — X X 6.1 X X X
Ethernet LANE— — — — — X X X X X X
Token Ring LANE— — — — — — X X X X X
ISL— — — — — — X X X X X
Syslog Support— — — — — — X X X X X
MAC Refresh Interval— — — — — — — 1.0 X X X
SNMP MIB— — — — — — — — 3.0 X X
MHSRP and Use BIA— — — — — — — — 3.4 X X
IP Redundancy— — — — — — — — 3.4 X X
BVI— — — — — — — — 6.2 X X
802.1Q— — — — — — — — 8.1 X X
Enhanced HSRP Debugging— — — — — — — — — 0.2 X
HSRP ICMP Redirects— — — — — — — — — — 3
HSRP MPLS VPNs— — — — — — — — — — 3
HSRP FeaturesPreemptionThe HSRP preemption feature enables the router with highest priority to immediately become the Active router. Priority is determined first by the priority value that you configure, and then by the IP address. In each case a higher value is of greater priority.
When a higher priority router preempts a lower priority router, it sends a coup message. When a lower priority active router receives a coup message or hello message from a higher priority active router, it changes to the speak state and sends a resign message.
Preempt DelayThe preempt delay feature allows preemption to be delayed for a configurable time period, allowing the router to populate its routing table before becoming the active router.
Before Cisco IOS Software release 12.0(9), the delay started when the router reloaded. In Cisco IOS release 12.0(9) the delay starts when preemption is first attempted.
To configure HSRP priority and preemption, use the standby group priority number preempt delay minimum seconds sync secondscommand.
Refer to the HSRP Documentation for more information on configuring HSRP.
Interface TrackingInterface tracking allows you to specify another interface on the router for the HSRP process to monitor in order to alter the HSRP priority for a given group.
If the specified interface’s line protocol goes down, the HSRP priority of this router is reduced, allowing another HSRP router with higher priority can become active (if it has preemption enabled).
To configure HSRP interface tracking, use the standby group track interface priority command.
When multiple tracked interfaces are down, the priority is reduced by a cumulative amount. If you explicitly set the decrement value, then the value is decreased by that amount if that interface is down, and decrements are cumulative. If you do not set an explicit decrement value, then the value is decreased by 10 for each interface that goes down, and decrements are cumulative.
The following example uses the following configuration, with the default decrement value of 10.
Note: When an HSRP group number is not specified, the default group number is group 0.
The HSRP behavior with this configuration is:
0 interfaces down = no decrease (priority is 110)
1 interface down = decrease by 10 (priority becomes100)
2 interfaces down = decrease by 10 (priority becomes 90)
The above HSRP behavior is true even if the decrement values are configured explicitly as below.
Before Cisco IOS release 12.1, if you start a router with a down interface, HSRP interface tracking regards the interface as up.
This defect has Cisco bug ID CSCdp32289 (registered customers only) .
Use Burned-In AddressThe use burned-in address (BIA) feature allows HSRP groups to use an interface’s burned-in MAC address instead of an HSRP MAC address. Use BIA was first implemented in Cisco IOS release 11.1(8). To configure HSRP to use the BIA, use the standby use-bia scope interface command.
The use-bia command was implemented to overcome the limitations of using a functional address for the HSRP MAC address on Token Ring interfaces.
Note: When HSRP runs in a multiple-ring source-routed bridging environment and the HSRP routers reside on different rings, using the functional addresses can cause Routing Information Field (RIF) confusion. For this reason, the use-bia command was introduced.
The use-bia feature also enables the use of DECnet, Xerox Network Systems (XNS), and HSRP on the same router by allowing the DECnet MAC address (the BIA) to be used as the HSRP MAC address. The use-bia command is also useful in networking situations where a device’s BIA has been configured in other devices on the LAN.
However, the use-bia command has several disadvantages:
When a router becomes active, the virtual IP address is moved to a different MAC address. The newly active router sends a gratuitous ARP response, but not all host implementations handle the gratuitous ARP correctly.
Proxy ARP breaks when use-bia is configured. A atandby router cannot cover for the lost proxy ARP database of a failed router.
Prior to Cisco IOS release 12.0(3.4)T, only one HSRP group is allowed if use-bia is configured.
When you configure the use-bia command on a subinterface, it actually shows up on the main interface and is applied to all subinterfaces. In Cisco IOS release 12.0(6.2) and later, the use-bia command is extended with the optional scope interface keywords to allow it to be applied to a single subinterface.
This defect has Cisco bug ID CSCdm25468 (registered customers only) .
Multiple HSRP GroupsThe multiple HSRP (MHSRP) groups feature was added in Cisco IOS release 10.3. This feature further enables redundancy and load-sharing within networks, and allows redundant routers to be more fully utilized. While a router is actively forwarding traffic for one HSRP group, it can be in standby or in the listen state for another group.
As of Cisco IOS release 12.0(3.4)T, you can use the use-bia command with multiple HSRP groups enabled.
Refer to Load Sharing with HSRP to configure HSRP in order to take advantage of multiple paths.
Configurable MAC AddressNormally you use HSRP to help end stations locate the first hop gateway for IP routing. The end stations are configured with a default gateway. However, HSRP can provide first hop redundancy for other protocols. Some protocols, such as Advanced Peer-to-Peer Networking (APPN), use the MAC address to identify the first hop for routing purposes.
In this case, it is often necessary to be able to specify the virtual MAC address using the standby mac-address command. The virtual IP address is unimportant for these protocols. The actual syntax of the command is standby group mac-address mac-address.
Note: You cannot use this command on a Token Ring interface.
Syslog SupportSupport for syslog messaging for HSRP information was added in Cisco IOS release 11.3. This feature allows for more efficient logging and tracking of the current active and standby routers on syslog servers.
HSRP DebuggingBefore Cisco IOS release 12.1, the HSRP debugging command was relatively simple. To enable HSRP debugging, you would simply use the debug standby command, which enabled output of HSRP state and packet information for all standby groups on all interfaces.
A debug condition was added in Cisco IOS release 12.0(2.1) that allows the output from the standby debug command to be filtered based upon interface and group number. The command utilizes the debug condition paradigm introduced in Cisco IOS release 12.0, as follows: debug condition standby interface group . The interface you specify must be a valid interface capable of supporting HSRP. The group can be any group (0 – 255).
You can set debug conditions for groups that do not exist, which allows you to capture debug information during the initialization of a new group.
You must enable standby debug order for any debug output to be produced. If you don’t configure any standby debug conditions, then debug output is produced for all groups on all interfaces. If you configure at least one standby debug condition, then standby debug output is filtered according to all standby debug conditions.
Enhanced HSRP DebuggingBefore Cisco IOS release 12.1(0.2), HSRP debugging was of limited use because information was lost in the noise from periodic hello messages. Thus the enhanced debugging feature was added in Cisco IOS 12.1(0.2).
The following table explains the command options for enhanced debugging.
Command Description
debug standbyDisplays all HSRP errors, events, and packets.
debug standby terseDisplays all HSRP errors, events, and packets, except hello and advertisement packets.
debug standby errorsDisplays HSRP errors.
debug standby events all | terse | icmp | protocol | redundancy | track detail Displays HSRP events.
debug standby packets all | terse | advertise | coup | hello | resign detail Displays HSRP packets.
You can filter the debug output using interface and HSRP group conditional debugging. To enable interface conditional debugging, use the debug condition interface interface command. To enable HSRP conditional debugging, use the debug condition standby interface group command.
An interface debug condition applies only when you have set no standby debug conditions. HSRP debugging is further enhanced in Cisco IOS software release 12.1(1.3), based on the improvements that were made to the HSRP state table.
This defect has Cisco bug ID CSCdp57811 (registered customers only) .
These enhancements display the HSRP state table events. In the output below the a/, b/, c/, and so on, refer to the events of the HSRP finite state machine, which are documented in RFC 2281 .
AuthenticationThe HSRP authentication feature consists of a shared clear-text key contained within the HSRP packets. This feature prevents the lower priority router from learning the standby IP address and standby timer values from the higher priority router.
To configure the HSRP authentication string, use the standby authentication string command.
IP RedundancyHSRP provides stateless redundancy for IP routing. HSRP by itself is limited to maintaining its own state. It assumes that each router builds and maintains its own routing tables independently of other routers. The IP redundancy feature provides a mechanism that allows HSRP to provide a service to client applications so that they can implement statefull failover.
IP redundancy does not provide a mechanism for peer applications to exchange state information. This is left to the applications themselves, and is essential if the applications are to provide statefull failover.
IP redundancy is currently (as of January 2000) implemented only for Mobile IP Home Agents. Following is a sample configuration:
Note: As of Cisco IOS release 12.1(3)T, the keyword redundancy is accepted in addition to the keyword standby. The standby keyword will be phased out in a later Cisco IOS release. The correct command will then be ip mobile home-agent redundancy hsrp-group1.
Future uses of IP Redundancy may include:
NAT – Need to provide redundant gateways.
IPSEC – Need to synchronize state information in order to operate when HSRP is in use.
DHCP Server – DHCP servers implemented in various routers.
NBAR, CBAC – Need to mirror firewall states for asymmetric routing.
GPRS – Needs a way to track TCP state.
PIX
SNMP Management Information BaseSNMP Management Information Base (MIB) support was added to Cisco IOS release 12.0(3.0)T. There are two relevant MIBs for HSRP:
ciscoMgmt 106: The MIB module for managing HSRP
ciscoMgmt 107: The extension MIB module for managing HSRP
Prior to Cisco IOS release 12.0(6.1)T, a walk of the extended HSRP MIB when a Bridge Group Virtual Interface (BVI) is present causes the router to crash.
This defect has Cisco bug ID CSCdm61257 (registered customers only) .
HSRP Support for Multiprotocol Label Switching Virtual Private NetworksHSRP support for Multiprotocol Label Switching Virtual Private Networks (MPLS VPNs) was added in Cisco IOS release 12.1(3)T.
HSRP on an MPLS VPN interface is useful when you have an Ethernet connected between two Provider Edges (PEs) and you have either of the following:
A Customer Edge (CE) with a default route to the HSRP virtual IP address.
One or more hosts with the HSRP virtual IP address configured as the default gateway.
The network diagram below shows two PEs with HSRP running between their VPN routing/forwarding (VRF) interfaces. We configured the CE with the HSRP virtual IP address as its default route. And we configured HSRP to track the interfaces connecting the PEs to the rest of the provider network. For example, if interface E1 of PE1 fails, the HSRP priority will be reduced such that PE2 takes over forwarding packets to the virtual IP/MAC address.
These are the configurations:
HSRP Support for ICMP RedirectsHSRP is based on the concept that the HSRP peer routers protecting a subnet can provide access to all other subnets that comprise the network. Therefore, it is irrelevant which router becomes the active HSRP router, as all routers had routes to every subnet.
HSRP makes use of a special virtual IP address and virtual MAC address, which are logically attached to the HSRP active router. ICMP redirects are automatically disabled on an interface when using HSRP on that interface. IOS 12.1(3)T onwards, ICMP Redirects feature enables ICMP redirects on interfaces configured with HSRP. Refer to HSRP Support for ICMP Redirects for more details. This is done to prevent hosts from being redirected away from the HSRP virtual IP address. It is possible that the two (or more) routers on a subnet don’t have identical connectivity to the rest of the network. That is, for a particular destination IP address, one or the other of the routers may have a much better path to that address, or may even be the only router attached to that address.
The ICMP protocol allows a router to redirect an endstation to send packets for a particular destination to another router on the same subnet, if the first router knows that the other router has a better path to that particular destination. As was the case for default gateways, if the router to which an endstation has been redirected for a particular destination fails, then the endstation’s packets to that destination were not delivered. In standard HSRP, this is exactly what happens. For this reason, we recommend disabling ICMP redirects if HSRP is turned on.
Extending the relationship between ICMP redirects and HSRP provides a solution to this problem, allowing you to take advantage of the benefits of both HSRP and ICMP redirects. Two (or more) HSRP groups are run on each subnet, with at least as many HSRP groups configured as there are routers participating. The priorities are configured so that each of the routers is master of at least one HSRP group. When one router determines to redirect an endstation to a different router for a specific destination, then instead of redirecting the endstation to that other router’s IP address, it finds an HSRP group that is being mastered by that router, and redirects the endstation to the corresponding virtual IP address. If that target router then fails, HSRP ensures that another router takes over its job and, perhaps, redirects the endstation to yet another, again virtual, router.
HSRP Interface and Media SupportThis section explains which interfaces and media HSRP supports, and possible caveats when running HSRP over these media.
Since Cisco IOS Software release 10.0, HSRP functionality has been available on Ethernet, Token Ring and Fiber Distributed Data Interface (FDDI). Fast Ethernet and ATM interfaces are also supported by HSRP.
Virtual LANs (VLANs) allow logical network topologies to overlay the physical switched infrastructure such that any arbitrary collection of LAN ports can be combined into an autonomous user group or community of interest. HSRP VLAN support was added in Cisco IOS release 11.1 for IEEE 802.10 Secure Data Exchange (SDE), and in Cisco IOS release 11.3 for Cisco Inter-Switch Link (ISL).
EthernetSeveral Ethernet (Lance and QUICC) controllers in low-end products can only have a single unicast MAC address in their address filter. On these platforms only a single HSRP group is permitted, and the interface address is changed to the HSRP virtual MAC address when the group becomes Active. If you are using HSRP on routers with multiple interfaces of this type, you should configure each interface with a different HSRP group number.
Note: The Cisco 7200 router also uses the Lance Ethernet controller, but it supports MHSRP in software.
Cisco recommends that you have no more than twenty-four HSRP Ethernet Interface Processors (EIPs) due to the time it takes to update the address filters for HSRP. Having more than twenty-four HSRP EIPs can cause instability and excessive CPU load.
This defect has Cisco bug ID CSCdj29595 (registered customers only) .
If you have more than twenty-four EIPs, try replacing the EIPs with Versatile Interface Processors (VIPs) and Ethernet port adapters. VIPs have been approved for up to eighty HSRP groups. You can also reduce the number of HSRP groups, and increase the HSRP hello and hold time.
Token RingOne limitation of running HSRP on a Token Ring interface is that you cannot reprogram the address filter on the Token Ring chipset the same way you can on Ethernet, FDDI or ATM emulation. Token Ring uses functional addresses, of which there are only a small number available that do not conflict with other uses of the functional address space.
When running HSRP in a source-route bridging (SRB) environment, the use of functional addresses can cause RIF confusion. See the HSRP Addressing section for more information. Also, try configuring the use-bia command.
802.1QCisco recommends using Cisco IOS software release 12.0(8.1)T or later for HSRP over 802.1Q.
ISLHSRP over ISL is available in Cisco IOS releases 11.2(6)F, 11.3, 12.X. It is recommended to use release 12.0(7) or later in order to avoid the issue described in Cisco bug ID CSCdm68811 (registered customers only) .
FDDIA FDDI port adapter strips frames from the ring if it sees one of its own MAC addresses in the MAC source. If a network event causes both routers to go active, then both routers send HSRP hello packets with the same virtual MAC address. Each router mistakenly strips the other router’s hello packet from the network, and both stay active.
This defect has Cisco bug ID CSCdj30049 (registered customers only) .
The solution to this problem in Cisco IOS release 11.2(11.1) is for HSRP routers in an FDDI environment to use their own unique burned-in MAC address to exchange messages and run the HSRP protocol. To ensure that learning bridges and switches cache the correct port entry for the virtual MAC address, the active router also sends periodic refresh messages using the HSRP MAC address.
Note: The Cisco 4500 router’s hardware content-addressable memory (CAM) on an FDDI interface may not be populated correctly after a reload if you have configured multiple RIP networks and HSRP groups. The only workaround at this time is to clear the interfaces to restore the CAM. This defect has Cisco bug ID CSCdm93122 (registered customers only) .
MAC RefreshHSRP routers in an FDDI environment use their own unique burned-in MAC address to exchange messages and run the HSRP protocol. To ensure that learning bridges and switches cache the correct port entry for the virtual MAC address the active router also sends periodic refresh messages using the HSRP MAC address. This defect has Cisco bug ID CSCdj30049 (registered customers only) .
If you do not have a switch or learning bridge on your network, you can disable the sending of refresh packets as shown below:
Bridge Group Virtual InterfaceHSRP support for Bridge Group Virtual Interfaces (BVIs) was added in Cisco IOS release 12.0(6.2)T.
SubinterfacesHSRP groups on subinterfaces must have a group number unique among all other groups on all subinterfaces on the same main interface. This is because subinterfaces do not receive a unique SNMP interface index. If you had two groups with the number N on different subinterfaces, then in the MIB, group N on sub-interface 1 and group N on sub-interface 2 would appear to be the same group.
2.1.13 Hardware Prototype Implementation:
SFP/CAT6
Modem
Core Switch
Internet Service Provider
Rouer/Firewall
CAT 6
SFP
Access Switch
CAT6/SFP
Distribution Switch
Distribution Switch
Distribution Switch
Devices
Figure 17. Algorithm
Figure 17. Connection Diagram
Figure 18. Hardware Setup
2.1.14 Results:
Figure 19. Sender Output
Figure 20. Receiver Output
2.1.15 Tools and Technologies:
The project implementation required literature review of a lot of the tools, projects and services used. They are listed as follows:
CISCO PACKET TRACER: Packet Tracer is a Cross platform network simulation tool allows to create network topologies. allowing users to add and remove simulated network devices as they see fit. The software is mainly focused towards Certified Cisco Network Associate Academy students as an educational tool for helping them learn fundamental CCNA concepts
PuTTY: Open Source Terminal Emulator and network file transfer. Which is connected through Serial Port. It Includes SSH, Telnet and Rlogin.
2.1.16Challenges:
While working on sites we faced many Internet service issues so that we are not able to ping to the network and gateway. This is the major issue we faced in every location and we took as a challenge .
2.1.17 Future Scope:
Maintaining of the data center with all the required devices and network is the major problem facing in today’s generation.
For this many organizations are working to the fullest to incorporate more advanced technologies, better solutions than fuel alternative to prove themselves and gain consumer base.
So, our project has a great scope in creating large network platform in order to maintain the data center of the organization.
2.2 Project Aftermath:
Brief details will be given in this regard as this was asked to keep confidential by company officials as these are the patented products which are going to be released in the market.
Access Point:
I have done Configuration and Implementing SSID for the Organization.
Firewall:
I Have done the configuration of writing access rules and permit list for the access of the only particular of the organization.
Router:
I have done Routing for the different computing devices using the routing Protocols and the configured based on the locations.
3. CONCLUSION:
The overall experience of internship program at INFRA-IT SOLUTIONS has been filled with learning all the time and exposed me to a whole new corporate work environment that I hadn’t been in before. This gave me an opportunity for building my professional network. Working on projects, whether alone or in a team, helped me fulfill some short-term goals and achieving deliverables as well as the company. Working in such a productive environment helped boost my confidence and helped me realize how to become an asset for the company.
I learned a lot about new tools and technologies by venturing into new domains as part of my project. I successfully completed my project as per partial fulfillment i.e. my part in the project.
The courses done in the university that came in handy during the internship were:
Fundamentals of Electronics.
C programming and Data Structures.
Communication Network.
Analog Electronics.
In conclusion, I would like to say that I have succeeded in the task I took and learnt a lot from this experience and that this will definitely help me build my career ahead.
4. REFERENCES
https://en.wikipedia.org/wiki/PuTTY
https://www.cisco.com/c/en/us/support/docs/ip/hot-standby-router-protocol-hsrp/9234-hsrpguidetoc.html#intro
https://en.wikipedia.org/wiki/Packet_Tracer
https://www.cisco.com/
On site images
PART B: Non-Technical
Key Learnings:
Apart from developing technical skills during this internship, I also had a chance to improve my soft skills and learned to build a network in an organization. I improved a lot in presentation and demonstration skills. I learned there may be numerous solutions to a problem, never conclude a solution listen to peers may be a better solution comes up. Key learning to say is most important thing than doing the work is presenting the work to others, if they misinterpret things your work can never make it to the top. Meeting deadlines is another key aspect to be taken care of, one need to adhere to timelines where I got to learn how to efficiently manage time.
Extra Activities:
We played Football once every two weeks organized by our company, where we found opportunity to interact with other teams and build a strong bond among the office peers.
Overall, I had a soothing and enriching experience working at Infra It Solutions.
