Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Previous chapters in this book have addressed a wide array of networking technologies.
Because many of these technologies can be found in the typical enterprise network, a successful
troubleshooter of large enterprise networks needs a broad understanding of each
of these technologies. In addition, a troubleshooter needs to understand how these technologies
interoperate and impact one another. In some cases the troubleshooter might not
have the depth of knowledge required in a specific technology. In such a situation, the
troubleshooter should know how to obtain the required knowledge or identify who can
provide the required expertise.
This section categorizes major networking troubleshooting areas based on the layers of
the OSI model. Fundamental requirements for enterprise network troubleshooting are presented.
Finally, this chapter reviews each of the trouble tickets presented in this book.
Specifically, the symptoms of each trouble ticket are presented, along with the troubleshooting
commands used and the suggested solution to the underlying issue or issues.
Troubleshooting Complex Networks
Complex enterprise networks are composed of multiple technologies that might reside at
various layers of the OSI model. Knowing which technologies correspond to which OSI
layers can help a troubleshooter better understand how issues with one technology can
impact other technologies.
Table 14-4 identifies the OSI layer (or layers) that correspond to a variety of network
technologies.
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
464 CCNP TSHOOT 642-832 Official Certification Guide
The following list identifies important prerequisites for troubleshooters to possess before
they troubleshoot a complex enterprise network.
■ A high-level understanding of multiple network technologies that might be encountered
and access to specialized knowledge as needed
■ An understanding of how network technologies impact one another
■ An understanding of the architectural planes of a router (for example, the data plane
and control plane) and the functions of each plane
■ A familiarity with troubleshooting tools (for example, appropriate Cisco IOS commands
and packet capture software)
■ Previously collected baseline information, against which newly collected data can be
compared
Case Study Review
Because troubleshooting large enterprise networks requires knowledge of multiple network
technologies, this chapter concludes by reviewing each of the previously presented
trouble tickets, highlighting the reported symptom(s), troubleshooting commands used
to diagnose the issue, and presenting the underlying issue along with the implemented
solution.
Trouble Ticket #1 Review
Trouble ticket #1 is presented in Chapter 4, “Basic Cisco Catalyst Switch Troubleshooting.”
Symptom: Users were experiencing latency when attempting to reach a remote network.
Troubleshooting commands used:
■ show spanning-tree vlan vlan-id
■ show spanning-tree summary
■ show spanning-tree summaryinterface interface-id detail
Issue: Spanning Tree Protocol (STP) was not configured on two switches, resulting in a
Layer 2 topological loop that caused MAC address table corruption and a high CPU utilization
on the Cisco Catalyst switches.
Resolution: STP was properly configured on the switches, eliminating the CPU utilization
and MAC address table corruption issues.
Trouble Ticket #2 Review
Trouble ticket #2 is presented in Chapter 5, “Advanced Cisco Catalyst Switch Troubleshooting.”
Symptom: Hot Standby Routing Protocol (HSRP) was not working properly. Specifically,
an inappropriate router was the active HSRP router.
Key
Topic
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
Chapter 14: Large Enterprise Network Troubleshooting 465
Troubleshooting commands used:
■ show standby brief
■ debug standby
■ ping ip-address
Issue: The preempt feature was not enabled on the router that should be acting as the active
HSRP router. Therefore, after that router rebooted, it did not regain its active status.
Resolution: The preempt feature was enabled on the router that should have been acting as
the active HSRP router, resulting in that router regaining its active status.
Trouble Ticket #3 Review
Trouble ticket #3 is presented in Chapter 6, “Introduction to Troubleshooting Routing
Protocols.”
Symptom: A router configured for EIGRP was not load balancing appropriately.
Troubleshooting commands used:
■ show ip route
■ show ip eigrp topology
■ show run | begin router
Issue: The paths across which the router should have load-balanced had different costs.
Resolution: EIGRP’s variance feature was configured to enable load balancing across unequal
cost paths.
Trouble Ticket #4 Review
Trouble ticket #4 is presented in Chapter 7, “OSPF and Route Redistribution Troubleshooting.”
Symptom: Routers in a multiarea OSPF topology did not have full reachability to all
networks.
Troubleshooting commands used:
■ show run | begin router
■ show ip ospf neighbor
■ show ip route
■ show ip ospf
■ show ip ospf interface interface-id
■ show ip ospf virtual-links
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
466 CCNP TSHOOT 642-832 Official Certification Guide
Issue #1: A virtual link configuration was incorrect. Specifically, the transit area (that is,
the area between area 0 and the area that is not physically adjacent to area 0) configured in
the area number virtual-link command was incorrect.
Resolution #1: The virtual link configuration was corrected by specifying the appropriate
transit area in the area number virtual-link command.
Issue #2: One of the routers had nondefault Hello and Dead timers configured for a subinterface.
These parameters did not match the parameters at the far end of the Frame Relay
link, preventing an OSPF adjacency from forming over that link.
Resolution #2: The OSPF Hello and Dead timers were returned to their default settings,
after which an OSPF adjacency formed between the routers at each end of the Frame Relay
link.
Issues #3 and #4: Two of the routers had interfaces configured with incorrect OSPF network
types.
Resolution #3 and #4: The interfaces with the incorrect OSPF network types were configured
to use their default OSPF network types, after which OSPF adjacencies formed
between the routers at each end of the links.
Trouble Ticket #5 Review
Trouble ticket #5 is presented in Chapter 7.
Symptom: Two companies merged, and they used different routing protocols (that is,
OSPF and EIGRP). Route redistribution was not correctly performing mutual route redistribution
between these two autonomous systems.
Troubleshooting commands used:
■ show ip route
■ show run | begin router
Issue #1: The EIGRP routing process configured on the router performing the redistribution
lacked a default metric that would be assigned to routes being redistributed in the
EIGRP routing process.
Resolution #1: The default-metric 1500 100 255 1 1500 command was issued in router
configuration mode for the EIGRP routing process. This made redistributed routes appear
to have a bandwidth of 1500, a delay of 100, a reliability of 255, a load of 1, and an MTU
of 1500.
Issue #2: The OSPF routing process configured on the router performing the redistribution
lacked the subnets parameter at the end of the redistribute command. The subnets
parameter is required to allow nonclassful networks to be redistributed into OSPF.
Resolution #2: The existing redistribute command in router configuration mode for the
OSPF routing process was replaced with the redistribute eigrp 100 metric 64 subnets
command, which instructed OSPF to redistribute routes from EIGRP AS 100 with a metric
of 64 and to redistribute nonclassful networks (that is, subnets).
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
Chapter 14: Large Enterprise Network Troubleshooting 467
Trouble Ticket #6 Review
Trouble ticket #6 is presented in Chapter 8, “Troubleshooting BGP and Router Performance
Issues.”
Symptom: An enterprise is dual homed to the Internet using two service providers. The
dual homing is configured using BGP. However, BGP selected the slower of the two links
going out to the Internet.
Troubleshooting commands used:
■ show ip route
■ show run | begin router
■ show ip bgp summary
■ show ip bgp
Issue: The enterprise router was pointing to the service provider reachable over the slower
link, because the router of that service provider had the lowest BGP router ID.
Resolution: The enterprise router was configured to assign local preference attributes to
routes being advertised by the service provider routers. BGP prefers higher local preference
values. Higher local preferences were applied to routes being advertised by the service
provider reachable over the higher-speed link. Therefore, outbound traffic used the
optimal path.
To influence inbound path selection (that is, traffic coming in from the Internet), the enterprise
router was configured to prepend multiple instances of its AS on route advertisements
sent over the slower-speed link. This caused the service provider routers to prefer
the higher-speed link when sending traffic into the enterprise, because it appeared to require
fewer AS hops.
Trouble Ticket #7 Review
Trouble ticket #7 is presented in Chapter 9, “Security Troubleshooting.”
Symptom: The enable secret password for a router was forgotten. Also, a Telnet session to
one of the routers in the topology timed out after only 1 second. Finally, an ACL was not
preventing Telnet sessions as expected.
Troubleshooting command used:
■ show running-config
Issue #1: The administrator forgot the enable secret password for a router. Therefore, the
administrator was not able to access the privileged mode of the router.
Resolution #1: Password recovery was performed, which involved rebooting the router,
entering ROMMON configuration mode, changing the configuration register to ignore
the startup configuration, and rebooting the router. Privileged mode could then be
entered, because the router booted up without a startup configuration. The startup
configuration was copied to the running configuration, and the enable secret password
was changed. Interfaces in the shutdown state were administratively brought up, and the
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
468 CCNP TSHOOT 642-832 Official Certification Guide
configuration register was changed to use the startup configuration upon a reboot. Finally,
the router was rebooted, and the router booted up using the startup configuration,
which had the newly configured enable secret password.
Issue #2: The exec-timeout parameter for the VTY lines of a router was configured to 0
1, which meant that a Telnet session would time out after only 1 second.
Resolution #2: The exec-timeout parameter for the VTY lines of the router was reconfigured
to 0 0, meaning that a Telnet session would never time out. However, the challenge
was to perform this reconfiguration without timing out in the process. The solution was to
repeatedly tap the down arrow on the keyboard (which did not enter characters in the CLI
but still reset the idle timer of the VTY line) with one hand while typing the reconfiguration
commands with the other hand.
Issue #3: An ACL was applied in the outbound direction on an interface, when it should
have been applied in the inbound direction on the interface.
Resolution #3: The ip access-group command that applied the ACL in the incorrect direction
was removed and replaced with an appropriate ip access-group command.
Trouble Ticket #8 Review
Trouble ticket #8 is presented in Chapter 10, “IP Services Troubleshooting.”
Symptom: NAT was partially working on a router; however, only two NAT translations
could simultaneously be set up. Additionally, NAT translations failed.
Troubleshooting commands used:
■ show ip nat translations
■ debug ip nat
■ ping ip-address
Issue: The ip nat translation max-entries 2 command was preventing more than two simultaneous
NAT translations.
Resolution: The ip nat translation max-entries 2 command was removed, which allowed
additional NAT translations to be created.
Trouble Ticket #9 Review
Trouble ticket #9 is presented in Chapter 11, “IP Communications Troubleshooting.”
Symptom: A Cisco IP Phone was failing to register with a Cisco Unified Communications
Manager Express (UCME) router.
Troubleshooting command used:
■ show running-config
Issue: The DHCP server configured on one of the routers in the topology was misconfigured.
Specifically, the network command in DHCP configuration mode for the DHCP
pool of the IP phones specified an incorrect IP address space.
Resolution: The incorrect network command in DHCP configuration mode was removed
and replaced with a network command that specified the appropriate address space.
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
Chapter 14: Large Enterprise Network Troubleshooting 469
Trouble Ticket #10 Review
Trouble ticket #10 is presented in Chapter 11.
Symptom: Voice calls placed across a Frame Relay WAN link were suffering from poor
voice quality if the call originated from an analog phone, whereas calls that originated
from a Cisco IP Phone did not experience quality issues.
Troubleshooting commands used:
■ show class-map
■ show running-config
Issue: A Cisco IP Phone automatically marks voice packets with a DSCP value of Expedited
Forwarding (EF). However, by default, calls originated from an analog phone are not
marked with a DSCP value of EF.
Resolution: The AutoQoS VoIP feature was configured on a router, which caused voice
traffic to be recognized (using NBAR) and marked with a DSCP value of EF.
Trouble Ticket #11 Review
Trouble ticket #11 is presented in Chapter 12, “IPv6 Troubleshooting.”
Symptom: Routers in a topology were configured with IPv6 addressing, and OSPFv3 was
chosen as the routing protocol. However, some of the OSPFv3 routers were not forming
appropriate adjacencies.
Troubleshooting commands used:
■ show running-config
■ show ipv6 route
■ show ipv6 ospf interface interface-id
■ show ipv6 ospf neighbor
Issue #1: The HELLO timer on an interface on one of the routers was set to a nondefault
value, whereas the other end of the link was configured for its default HELLO timer value.
This prevented an adjacency from forming between these two routers.
Resolution #1: The router interface with a nondefault HELLO timer was configured to use the
default HELLO timer value, after which an adjacency was formed between these two routers.
Issue #2: The OSPF network type on the subinterface of a router was set to point-to-multipoint,
whereas the other end of the link was a default OSPF network type of point-to-point.
Resolution #2: The router subinterface with a nondefault OSPF network type was configured
to use the default network type of point-to-point, after which an adjacency was
formed between the routers at each end of the link.
Issue #3: Subinterfaces at opposite sides of a link had different MTU values. Specifically,
one subinterface had a default MTU of 1500 bytes, whereas the other subinterface had a
nondefault MTU of 1400 bytes.
Resolution #3: The subinterface with the nondefault MTU of 1400 bytes was reconfigured
to have a default MTU of 1500 bytes, after which an adjacency formed between the
routers at each end of the link.
No comments:
Post a Comment