CCNP TSHOOT - v7 - Ch09 POLONA V0.4

Chapter 9:
Troubleshooting
Case Study:
Bank of POLONA
CCNP TSHOOT: Maintaining and Troubleshooting IP Networks
TSHOOT v7 Chapter 9
2007 2016, Cisco Systems, Inc. All rights reserved.
Cisco Public
Chapter 9 Objectives
Bank of POLONA Trouble Ticket 1
Troubleshooting Redistribution
Troubleshooting VRRP with Interface Tracking
FHRP Tracking Options
Troubleshooting IP SLA

Troubleshooting EIGRP Summarization
Troubleshooting RIPng
Troubleshooting Access Control Lists
Chapter 9
Cisco Public
Chapter 9 Objectives
Troubleshooting GRE Tunnels
OSPF Summarization Tips and Commands
Troubleshooting AAA

Troubleshooting OSPF for IPv6
Troubleshooting the Dysfunctional Totally Stubby Branch Areas
OSPF Stub Areas
Chapter 9
Cisco Public
Troubleshooting
Case Study:
Bank of POLONA
Chapter 9
Cisco Public
Troubleshooting Case Study: Bank of POLONA Scenario
Chapter 9
Cisco Public
Bank of POLONA
Trouble Ticket 1
Chapter 9
Cisco Public
Trouble Ticket 1
Newly-acquired branch, Branch 3, is running EIGRP, while the
other two branches are running OSPF.
Issue Notification:
User on PC3 on branch 3, cannot access the server SRV2.
If R1s uplink to HQ fails, then traffic from PC0 goes to R1 then
R2, instead of going directly to R2.
HSRP was considered, but VRRP is to be installed, to avoid the
sub-optimal traffic path.
Since connection SRV2 was not reliable, an SLA was configured
on HQ to test connectivity to SRV2.
However, the SLA test is not starting.
Chapter 9
Cisco Public
Trouble Ticket 1 Process Summary - Issue #1

Action
Commands
Telnet from HQ to BR3 router.
telnet 192.168.3.101
Ping SRV2 from BR3 using

Br3s LAN interface (where
PC3 lives.)
Ping 192.168.2.200 source

192.168.3.101
Ping HQ
Ping 192.168.2.200
SRV2
Check BR3S routing table
Show ip route eigrp
Check protocols on BR3
Show ip protocols
Check neighbours on BR3
Show ip eigrp neighbors
Check HQ router
Show ip protocols
Redistribute ospf 1
Resolve
Router eigrp 100

Redistribute ospf 1 metric
1500 100 255 1 1500
Verify
Ping 192.168.2.200 source

192.168.3.101
Result
Conclusions
Successful
IPSec-GRE tunnel WAN link

between HQ & Br3 is OK
Fail
Successful
Problem verified
IPSec-GRE tunnel WAN link

between HQ & BR2 is OK. So
problem may be in internal network.
Use Follow-the-Path:
No HQ or BR networks learned by
EIGRP
OK
HQ is a neighbour
OSPF 1 not being
redistributed into
EIGRP.
OSPF routes in BR3
table
Successful
EIGRP active on BR3 link &

adjacency with BR3.
Command does not include seed
metrics required.
Connectivity restored.
Problem solved
Chapter 9
Cisco Public
When prefixes are not distributing from one process to another,
you must first check whether the redistribute command is
referencing the correct routing process with the appropriate
process number.
You must also check that routes are not filtered by any
misconfigured distribute list or route map.
Redistribution from one process to another requires that you
provide a seed metric for the redistributed routes.
OSPF has a default seed metric of 20
EIGRP and RIPv2 do not have a default metric by default.
You can set up a default metric for these protocols, or you can
assign unique metric values on the redistribution command line.
Note: Prefixes are redistributed from one process into another only
as long as they are present in the IP routing/forwarding table.
Chapter 9
Cisco Public
Protocol-specific facts relate to redistribution:
EIGRP
EIGRP does not automatically have a default metric for any redistributed routes.
If the default metric or a manual metric is not specified, EIGRP assumes a metric of 0
and does not advertise the redistributed routes.
EIGRP will not autosummarize external routes unless a connected or internal EIGRP
route exists in the routing table from the same major network of the external routes.
If an EIGRP stub router needs to redistribute routes, it has to be explicitly configured to
do so using the eigrp stub redistributed command.
OSPF
Use the parameter subnets to distinguish classful and classless behavior.
When any protocol is redistributed into OSPF, if the networks that are being redistributed
are subnets, you must define the subnets keyword under the OSPF configuration.
If the subnets keyword is not added, OSPF will ignore all the subnetted routes when
generating the external link-state advertisement (LSA).
The situation could also arise when connected or static routes are being redistributed into
OSPF.
Chapter 9
Cisco Public
10
Protocol-specific facts relate to redistribution:
BGP
When redistributing Interior Gateway Protocol (IGP), static and

connected routes into Border Gateway Protocol (BGP), it is important
to carefully filter the redistributed routes so that invalid/private
networks do not sneak into the BGP table and be announced to
external BGP neighbors.
Chapter 9
Cisco Public
11
Trouble Ticket 1 Issue #2

Issue Notification:
If R1s uplink to HQ fails, then traffic from PC0 goes to R1 then R2,
instead of going directly to R2.
HSRP was considered, but VRRP is to be installed, to avoid the
sub-optimal traffic path.
Chapter 9
Cisco Public
12

Action
Commands
Result
Conclusions
Traceroute from PC0 to

Internet test address
tracert 209.165.201.45
Correct path
Path follows R1 to HQ routers
Shut down R1s Eth 0/1

interface (uplink to HQ)
tracert 209.165.201.45
Path: R1 R2 HQ
Get VRRP information on R1
Show vrrp
VRRP group1 config on E

0/0 & R1 is Master router,
priority = 110.
OK so far.
Check tracking
Show track
No object tracking for

VRRP gp 1.
No objects being tracked
Get VRRP information on R2
Show vrrp
VRRP group1 config on E

0/0 & R2 is Backup router,
priority = 100.
But no object tracking for
VRRP gp 1.
No object tracking => no way of

triggering a change in the priority
if R1 goes down.
Create a track object on R1

for Eth 0/1 on line protocol
track 1 interface ethernet 0/1

line-protocol
Config R1s VRRP gp 1 to

decrement priority by 20
Int eth 0/0

vrrp 1 track 1 decrement 20
Test:
Shut down R1s E0/1
interface & see VRRP info
Int eth 0/1

Shutdown
Show vrrp
Verify
tracert 209.165.201.45
Problem verified
Track object 1 state

down;
R1 priority = 90
R2 priority = 100
so R2 is Master
Correct path
Problem solved
Chapter 9
Cisco Public
13
R1
R2
Sub-optimal path for traffic

from PC0 when R1s uplink
is down.
HQ
Chapter 9
Cisco Public
14
Chapter 9
Cisco Public
15
Chapter 9
Cisco Public
16

HSRP interface tracking allows you to specify another
interface on the router for the HSRP process to monitor so
that you can alter the HSRP priority for a given group.
If the specified interfaces line protocol goes down, the
HSRP priority of this router is reduced, allowing another
HSRP router with a higher priority to become active (if it has
preemption enabled).
When multiple tracked interfaces are down, the priority is reduced by
a cumulative amount
If you explicitly set the decrement value, 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, the value is decreased
by 10 for each interface that goes down.
To configure HSRP interface tracking, use:

standby [ group ] track interface [ priority ] command
Chapter 9
Cisco Public
17

You can track either the interface line protocol state or the
interface IP routing state.
When you track the IP routing state, three conditions are
required for the object to be up:
1. IP routing must be enabled and active on the interface.
2. The interface line-protocol state must be up.
3. The interface IP address must be known.
Object tracking of IP SLA operations allows clients (such as

HSRP, GLBP, and VRRP) to track the output from IP SLA
objects and use this information to trigger an action (such
as decrementing priority).
Chapter 9
Cisco Public
18
FHRP Tracking Verification

show track [object-number [brief] | interface [brief] | ip
route [brief] | resolution | timers]
The following parameters are optional:
brief: Displays a single line of information related to the preceding
argument or keyword
interface: Displays tracked interface objects
ip route: Displays tracked IP route objects
resolution: Displays resolution of tracked parameters
timers: Displays polling interval timers
Chapter 9
Cisco Public
19

Since connection SRV2 was not reliable, an SLA was configured
on HQ to test connectivity to SRV2.
However, the SLA test is not starting.
Chapter 9
Cisco Public
20
To implement Cisco IOS IP SLAs, you need to perform the
following tasks:
1.Enable the Cisco IOS IP SLAs responder, if needed.
2.Configure the required Cisco IOS IP SLAs operation type.
3.Configure any options available for the specified Cisco IOS
IP SLAs operation type.
4.Configure threshold conditions, if required.
5.Schedule the operation to run, and then let the operation
run for a period of time to gather statistics.
Chapter 9
Cisco Public
21
IP SLA Verification Commands

Commonly used IP SLA show and debug commands
include the following:
show ip sla application (Number of configured & active SLAs)
show ip sla configuration (Configured SLAs)
show ip sla statistics (Time-to-Live setting)
show ip sla statistics [aggregated] (SLA operation started or not)
Chapter 9
Cisco Public
22
IP SLA Troubleshoot
Issue #3
An IP SLA test was
configured on HQ to
gauge the reachability
of SRV2 at all times,
but the SLA has not
begun.
Chapter 9
Cisco Public
23
IP SLA Troubleshoot
Issue #3
Hypothesis:
There was no schedule
configured for the IP
SLA test.
Chapter 9
Cisco Public
24
IP SLA Troubleshoot Example Issue #3

Solution:
The schedule is configured for the IP SLA test.
Test:
show ip sla application Shows 1 configured SLA and 1 active entry
show ip sla statistics Shows latest start time for the IP SLA and its
operation Time-To-Live as Forever.
Chapter 9
Cisco Public
25
Bank of
POLONA Trouble
Ticket 2
Chapter 9
Cisco Public
26
Trouble Ticket 2
other two branches are running OSPF.
Issue Notification:
BR3 is configured to summarise its networks (172.16.x.x) and
advertise only the summary route to HQ, but HQs routing table still
shows all the individual routes.
PC0 does not have Internet access via IPv6.
All Branch 3 devices have lost IPv6 Internet access.
Chapter 9
Cisco Public
27

EIGRPs summarization feature is available in the form of automated
summarization (limited to classful summaries) at network boundaries;
EIGRP summarization can also be performed manually in classless or
classful format.
Conventional (autonomous system number) EIGRP configuration method:
Classful auto-summary is enabled by default, to disable use the no auto-summary
A manual summary is advertised only if at least one of its proper subnets is present in the
IP routing table.
The metric of the summary is taken from the subnet with the smallest metric value.
The EIGRP summary-address is applied within interface configuration mode,

via: ip summary-address eigrp <ASN> <network> <mask>
When configuring EIGRP named configuration:
the summary address is applied to the af-interface interface section within an
address family inside the EIGRP process.
To check whether auto-summarization is active and which networks are
included in the EIGRP process, use the show ip protocols | section
eigrp command.
Chapter 9
Cisco Public
28
Troubleshooting EIGRP Summarization Issue #1

We search BR3 for
the key phrase:
summary-address
No summary-address
command on BR3s
tunnel interface to HQ.
But there is one on the
Eth 0/0 interface.
We verify that BR3 is connected to
HQ via the tunnel interface:
Show ip eigrp neighbors.
(confirmed)
So we move config to tunnel
Chapter 9
interface
.
Cisco Public
29
A word of caution:
Before moving the auto-summary command line, check to see which type
of EIGRP configuration has been implemented:
Conventional (autonomous system number) EIGRP configuration method
or:
EIGRP Named configuration
The conventional method uses the interface mode for configuring the
auto-summary address.
The Named convention has the summary address applied to the
af-interface interface section within an address family inside the
EIGRP process.
Check with show run | section eigrp <ASN>
Chapter 9
Cisco Public
30

PC0 does not have Internet access via IPv6.
Chapter 9
Cisco Public
31

Action
Commands
Result
Ping from PC0 to IPv6

Ping
2001:DB8:D1A5:C92D::1
UUUUU
Check PC0s Eth 0/1

interface (uplink to HQ): IPv6
address & Def GW?
Show ipv6 interface brief
2001:DB8:C0A8::64/64
DG:FE80::1
Ping from PC0 to IPv6

Default Gateway address
Ping FE80::1
!!!! successful
Follow-the-Path approach:
Check R1 & R2:
Conclusions
Internet not reachable.

Problem verified.
PC0 has an ipV6 address and a
Default Gateway
OK so far.
No L1 or L2 problems.
R1 & R2 should be receiving
Default route from HQ via RIPng
Ping from R1 & R2 to IPv6

Ping
2001:DB8:D1A5:C92D::1
Next step at HQ router:

Ping to IPv6 Internet test
address
Ping
2001:DB8:D1A5:C92D::1
Check protocols:
Show ipv6 protocols | section

RIP
RIPng is active on
relevant interfaces.
So far so good
Check RIPngs config:
Show ipv6 rip ccnp
HQ is not generating
default routes
No default RIPng route

advertisement from HQ to R1 &
R2.
Resolve: add redistribute a

def route cmd to HQ
HQ: int eth 0/1 (& eth 0/2)

Ipv6 rip ccnp defaultinformation originate
Verify:
Show ipv6 route
Chapter 9
No valid route to
destination.
!!!! successful
Correct path
R ::/0 [120/2]
via FE80::10, Ethernet
0/1
No exact route or default route to

destination for either R1 or R2.
HQ router also shows a static
default route to Internet.
HQ will advertise default route to

R1 & R2
Problem solved
Cisco Public
32
RIPng is a distance vector routing protocol, using hop count
as a metric. It uses native IPv6 packets for routing updates
exchange and a well-known multicast address (FF02::9).
User Datagram Protocol (UDP) is the transport protocol and
uses port number 521.
Before starting to troubleshoot IPv6 routing issues, make
sure that IPv6 routing is enabled on the device and that
interfaces are configured with IPv6 addresses.
Chapter 9
Cisco Public
33
If RIPng routes do not appear in the IPv6 routing table:
Check that RIPng is enabled on the interface.
RIPng with the same process ID must be explicitly enabled on each

interface that participates in the process.
Check that interface is operational (up).

Check whether the network missing the route is more than 15
hops away
RIPng has the maximal radius of 15 hops and networks with more hops
are considered unreachable.
Check whether the default route is propagated via RIPng.
Note that routing updates for non-default-route networks can be

suppressed if the command ipv6 rip name default-route
only command was used to configure default route announcement.
Check whether IPv6 access control lists (ACLs) are blocking the
RIPng traffic.
FF02::9 IPv6 multicast address and UDP port 521 must be permitted in
the ACL
Chapter 9
Cisco Public
34
If the default route is not announced, check that the default
route announcement is configured on the router.
A RIPng default route announcement must be configured on the
interface out of which it is to be announced.
(config-ig)# ipv6 rip process-id default-information originate
If RIPng is not load balancing, check the RIPng

configuration for the maximum-path command configured
value:
Configuring maximum-path to 1 turns off load balancing.
Also, check that there are multiple routes to the destination received
via RIPng and that they have the same metric.
RIPng load balances over equal-cost paths only.
Chapter 9
Cisco Public
35
RIPng Verification Commands

The following are some useful troubleshooting commands
related to RIPng:
show ipv6 route [rip]: This command displays the RIPng
entries of the IPv6 routing table.
show ipv6 rip [ name ] [database]: This command
displays information about the current IPv6 RIPng process.
show ipv6 protocols | section rip: This command
displays the basic RIPng information.
debug ipv6 rip: This debug command displays debugging
messages for RIPng routing transactions.
Chapter 9
Cisco Public
36

All Branch 3 devices have lost IPv6 Internet connectivity.
Chapter 9
Cisco Public
37

Action
Commands
Result
Conclusions
Telnet from HQ to BR3 using IPv6
Telnet 2001:DB8:C0A8:340::1
success
OK so far.
No L1 or L2 problems.
Ping from BR3 to IPv6 Internet test

address from Eth 0/1 as source
Ping 2001:DB8:D1A5:C92D::1
source Eth 0/1
.. Fail
Problem verified
Ping from BR3 to IPv6 Internet test

address not from Eth 0/1 as source
Ping 2001:DB8:D1A5:C92D::1
.. Fail
Problem verified extends further than

BR3s LAN.
Gather info:
Check BR3s IPv6 routing table:
Show ipv6 route
S ::/0 [1/0]
via FE80::1, Ethernet 0/0
1 path to Internet via static default route

FE80::1 next hop out of Eth 0/0
Check interface Eth 0/0
Show ipv6 interface brief
Eth 0/0 up up
No exact route or default route to

destination for either R1 or R2.
Check next hop:
Ping FE80::1
Dig deeper by examining packet

traffic
Terminal monitor
Debug ipv6 packet
Ping FE80::1
Output interface: Ethernet 0/0
See slide Example 9-29
Next-hop resolution to MAC address fails

due to an ACL (called from_Internet)
discarding incoming packets.
Check where ACL is applied and its

contents
Show running-config | include

interface|traffic-filter
Interface Ethernet 0/0

Ipv6 traffic-filter from_Internet
in
ACL applied in inbound direction, so

Internet traffic is to be permitted by this
ACL.
Check ACL contents
Show ipv6 access-list
Explicit deny all statement is dropping the

Neighbour Advertisement (NA) packets.
Resolve alternatives:
1. Remove the explicit deny
statement
No sequence 220
2. Add two permit icmp statements before the explicit deny statement
.. Fail
Something else is stopping the ping, so

dig deeper
Problem solved
See slide Example 9-31/2
Chapter 9
Cisco Public
38
Chapter 9
Cisco Public
39
Explicit deny all

statement is dropping the
Neighbor Advertisement
(NA) packets. (IPv6)
The Neighbor Advertisement (NA) packets are sent by BR3s neighbour, HQ, in
response to BR3s Neighbor Solicitation (NS) messages.
NA and NS messages perform IPv6-to-MAC address resolution, similar to ARP
Request and ARP Reply messages in IPv4
Chapter 9
Cisco Public
40
Chapter 9
Cisco Public
41

When troubleshooting relates to access control lists, consider
the following items:
Determine whether the ACL exists.
Determine where the ACL is applied.
Determine the direction the ACL is applied
inbound versus outbound
Read and analyze each access-list statement;
be aware of the wildcard mask implications and common mistakes.
Pay special attention to the order of ACL statements:
specific statements must precede general statements.
To collect counters for denied traffic, you need to configure

explicit deny statements with the log option.
Chapter 9
Cisco Public
42

If traffic is not explicitly permitted, it is denied.
The last ACL statement is an implicit deny all.
IPv6 ACLs permit ICMPv6 NS and NA messages

unless an explicit deny statement is configured.
The log keyword on an ACL statement instructs the router to log

a message to the system log whenever a specific access list
entry is matched.
The logged event includes details of the packet that matched the access
list entry.
A non-existing ACL permits all traffic, but an empty ACL denies all
traffic. In IPv6, the empty ACL permits all traffic; however, if you
add a comment to an empty IPv6 ACL, it will deny all traffic.
IPv4 ACLs are applied to interfaces by using the ip accessgroup command, but IPv6 ACLs are applied to interfaces by
using the ipv6 traffic-filter command.
Chapter 9
Cisco Public
43
Access Control Lists Verification

Use the following IOS commands to gather information about
configured ACLs:
show access-list: Displays all configured access lists
(IPv4 and IPv6) and their contents
show ip access-list: Displays all configured IPv4 access
lists and their contents, including the hit counts for each
statement
show ipv6 access-list: Displays all configured IPv6
access lists and their contents, including the hit counts for
each statement
Chapter 9
Cisco Public
44
Access Control Lists Verification

To determine where the ACLs are applied and in which direction they are
applied, usethe following commands:
show running-config | include line|access-class: Displays access
lines (vty, console) and the access-lists configured to control traffic to
the line.
show running-config | include interface|access-group: Displays all
the lines form the show running-config commands output, if they
include the word interface or the word access-group .
show ip interface interface-type interface-number : Displays interface
and IPv4 access lists applied to it. (A maximum of one ACL can be
applied in each direction.)
show running-config | include interface|traffic-filter
show ipv6 interface interface-type interface-number : Displays
interface and IPv6 access-list(s) applied to it. (A maximum of one ACL
can be applied in each direction.)
show running-config | include [ ACL-number | ACL-name |]:
Displays other applications of the access list, such as in NAT
configuration lines.
Chapter 9
Cisco Public
45
Bank of POLONA
Trouble Ticket 3
Chapter 9
Cisco Public
46
Trouble Ticket 3
other two branches are running OSPF. The plan is to reconfigure
EIGRP soon.
Issue Notification:
Branch 1 has lost connectivity to the Headquarters site. PC1 user
reports that pings to PC0 fail. PC1 could reach PC0 before the
upgrades.
After the routing protocol at BR3 was migrated to OSPF Area 3, it
was necessary to summarise Branch 3s networks (172.16.0.0/16)
to the R1 & R2 routers at the headquarters site.
However the R1 router is still receiving the individual subnets at
Branch 3.
The branch 1 router (BR1) must authenticate remote login
requests (Telnet) using the local authentication method.
However, telnetting into BR1 shows a request for only a password
and not a username.
Chapter 9
Cisco Public
47

Branch 1 has lost connectivity to the Headquarters site. PC1
user reports that pings to PC0 fail. PC1 could reach PC0 before
the upgrades.
Chapter 9
Cisco Public
48

Action
Commands
Result
UUUUU
Conclusions
Ping PC1 from PC0 since

cannot access PC1
Ping 192.168.1.100
This problem began after the

OSPF config, so take Divideand Conquer approach. begin
at L3: At HQ router for path to
192.168.1.100
Show ip route 192.168.1.100
More info: OSPF neighbors?
Show ip ospf neighbor
BR1 not listed as neighbor
Are interfaces up?
Check interfaces on HQ
Show ip interface brief
Tunnel 1 has no ip address
Get an ip address
Give Tunnel1 an ip address at

HQ
Interface tunnel 1
Ip address 192.168.11.2
255.255.255.0
Tunnel 1 is up
Now test
Test other end of tunnel 1
Ping 192.168.11.1
Check neighbours:
Still no BR1 as neighbour!
Check OSPF config on HQ
Check OSPF config on HQ

regarding tunnel
Show ip OSPF interface tunnel

1
See Example 9-38
More is needed
Propose a 2nd hypothesis:

Add OPSF network statement
on HQ
Network 192.168.11.0 0.0.0.255

area 1
See Example 9-39
Check for neighbours
Verify:
See Example 9-39
OK now. Problem solved
Network not in table
!!!! successful
PC1 not reachable.

Problem verified.
Why is there no communication?
HQ router should now show OSPF

neighbour
Chapter 9
Cisco Public
49
Chapter 9
Cisco Public
50
Chapter 9
Cisco Public
51

To configure a GRE tunnel, use the IOS command:
interface Tunnel tunnel-id .
tunnel source ipaddress or interface
tunnel destination ip-address .
tunnel mode gre ip command specifies the tunnel mode/type, but
GRE is the default tunnel mode anyway.
Advantages of GRE tunnels include the following:

Can be used to transport (tunnel) IP and non-IP, unicast,
multicast, and broadcast packets
Can be used as a workaround for networks that contain
protocols with limited hop counts
Can be used to connect discontinuous subnetworks
Can be used to build VPNs across WAN links
Chapter 9
Cisco Public
52

Common GRE problems include the following:
GRE source IP address is not reachable by remote host: Check
whether the correct source IP address or interface is applied to the
tunnel. You can also check routing in the backbone between the
endpoint hosts.
GRE destination IP address is not reachable by local host: Check
whether the correct destination was configured, and also check
whether hosts are reachable between them.
Recursive routing: This could happen if the best route to the tunnel
destination is through the tunnel itself! This will cause the tunnel
interface to keep flapping. In extreme cases, your router may crash
and reload.
GRE traffic denied by an ACL: IP protocol number 47 identifies GRE.
When using GRE, this protocol must be allowed by the access lists.
Further fragmentation due to the added GRE header: The
maximum transmission unit (MTU) is 1500 bytes. The GRE header is
24 bytes, which effectively decreases the MTU to 1476 bytes. Packets
larger than 1476 bytes will get fragmented, and this can result in
processing delays and high CPU usage.
Chapter 9
Cisco Public
53
GRE Tunnels Verification

Useful GRE troubleshooting commands include the following:
show interfaces Tunnel tunnel-id : Displays the interface
status, tunnel IP address, tunnel mode (should be GRE/IP
for GRE tunnels), tunnel source and destination, and some
other tunnel parameters
show ip interface Tunnel tunnel-id : Displays the IP
parameters on the tunnel interface
debug tunnel: Enables you to get tunnel debugging
information and see events related to the tunnel
Chapter 9
Cisco Public
54

There are two types of OSPF route summarization:
Interarea route summarization
Interarea route summarization is done on ABRs, and it applies to routes
from a particular connected area.
This has no effect on the external routes injected into OSPF through
redistribution.
Summarization could be configured between any two areas, but it is
better to summarize in the direction of the backbone.
Use area area-id range ip-address mask command, where areaid is the
area containing networks to be summarized
External route summarization

This type of summarization is done on the OSPF Autonomous System
Boundary Router (ASBR).
The ASBR is the actual router where redistribution of another process into
OSPF is performed.
The summary-address ip-address mask is used on the ASBR router to
accomplish external route summarization.
Chapter 9
Cisco Public
55

OSPF summarization commands include the following:
show ip route on the OSPF routers to check whether there are
individual routes or summarized routes in the routing table.
When checking the routing table on the routers that perform

summarization, you should see summary routes pointing to the Null0
interface. This route is created automatically to prevent suboptimal routing
or routing loops.
show ip ospf command on the ABR router to verify which area

ranges are configured for summarization.
show ip ospf summary-address to check which external
routes are summarized on the ASBR
show ip ospf database summary command. You will be able
to see all summary LSAs (type 3) with summary network
address, mask, metric, and some other parameters.
show ip ospf database external to check Type 5 (or external)
LSAs. You will see all external LSAs, with their network address,
mask, metric and some other parameters.
Chapter 9
Cisco Public
56
Troubleshooting AAA
TACACS+ is a Cisco proprietary protocol that runs over TCP port
49, and RADIUS is an IETF standard that runs over UDP port
1812 (or 1645) for authentication and UDP port 1813 (or 1646)
for accounting.
It is a common and best practice to use a centralized AAA server
as the primary authentication method and use the local
authentication as the backup, in cases that the AAA server is
either down or unreachable.
To enable AAA services on Cisco routers, use the aaa newmodel command.
Next, you can configure your preferred AAA methods using the
aaa authentication , aaa authorization , and aaa accounting
commands with appropriate parameters.
Chapter 9
Cisco Public
57
Troubleshooting AAA
Common problems encountered while using centralized
authentication with TACACS+ and RADIUS servers include the
following:
Server failure or server not accessible
To prevent locking yourself out of the device when the AAA server is not
accessible, use the local authentication method as the backup method for
authentication. You can define up to four methods for authentication.
Mismatched pre-shared key

TACACS+ and RADIUS both require a pre-shared key to be configured
between the network device and the AAA server. If the keys on the AAA
server and the client (network device) do not match, authentication will
not be performed.
User credentials are rejected by the server

You can inspect the server log to verify whether a user was correctly
authenticated/authorized or whether the user was rejected because of a
bad username or password.
Chapter 9
Cisco Public
58
Bank of POLONA
Trouble Ticket 4
Chapter 9
Cisco Public
59

OSPFv3 operates in a similar way as OSPFv2. There are a few differences,
though, as follows:
Protocol processing per link, not per subnet
Multiple IP subnets can be configured on a single link between two routers. OSPFv3
neighbors can establish adjacency even if they do not share a common IPv6 subnet.
OSPFv3s router ID is a number with a dotted-decimal format
An IPv6 address cannot be used as a router ID. If IPv6 is the only protocol enabled on a
router, the router ID must be manually specified; otherwise, the OSPFv3 process will not
start.
Support for multiple instances per link
Multiple instances of OSPFv3 can be used on a single link. Instances are distinguished
based on the instance ID (recorded in OSPFv3 packet header).
Use of link-local address
An OSPFv3 router uses its link-local address as the source of its Hello packets. The
next-hop addresses for the OSPFv3 routes in the IPv6 routing table are also link-local.
Different multicast addresses
The multicast address FF00::5 is used to address all OSPFv3 routers, and the multicast
address FF00::6 is used to address all OSPFv3 designated routers.
IPsec is used for authentication
There is no OSPF-specific authentication; IPsec is used to authenticate OSPF packets.
Chapter 9
Cisco Public
60
OSPF for IPv6 Configuration anf Verification

To create an OSPFv3 process, use the global configuration mode
command ipv6 router
ospf process-id .
If you do not specify the router ID manually, the highest IP address (loopback is
preferred) of the router is used as the router ID, and if the router has no IPv4
address, the OSPFv3 process will not start. You can manually configure the router
ID by using the command router-id router-id from within router configuration
mode.
To activate OSPFv3 on a specific interface, use the command ipv6

ospf process-id area area from within interface configuration mode.
Use the show ipv6 ospf process-id command to display the global
OSPFv3 settings such as router ID, timers, areas configured on the
router, and so on.
To display the OSPFv3 neighbors of a router, use the command show
ipv6 ospf neighbor.
The output is similar to the neighbor table displayed for OSPFv2; it displays
neighbor ID, priority, state, dead time, interface ID, and the interface that is used to
establish adjacency.
Chapter 9
Cisco Public
61
OSPF for IPv6 Configuration anf Verification

To display the list of interfaces where OSPFv3 is enabled,
use the command show ipv6 ospf interface .
The output not only lists all interfaces where OSPFv3 is enabled, but
also reveals which area is configured on the interface, the router ID,
and the OSPF network type and timers on each interface.
To display the OSPFv3 database, use the command show

ipv6 ospf database .
To display details on a specific LSA, use the show ipv6 ospf
database lsa-type adv-router router-id command.
To see the OSPFv3 Hello packets, use the command debug ipv6
ospf hello , and to see all OSPF packets, use the command debug
ipv6 ospf packet .
Chapter 9
Cisco Public
62
OSPF Stub Areas

OSPF allows certain areas to be configured as stub areas.
When an area is configured as a stub area, external routes are
filtered on the ABR.
Instead, a default route is propagated into the area by the ABR. To
configure an area as a stub area, all routers in the area must have the
area area-id stub command configured under the router OSPF
configuration mode.
A stub area can be converted to a totally stubby area.

In addition to external routes, interarea routes are prevented by the ABR
from penetrating into the totally stubby area.
To configure a stub area as totally stubby, use the area area-id stub nosummary command on the ABR and area area-id stub on all other
routers within that area.
When troubleshooting the stub feature on a router, the show ip

ospf process-id command is very helpful.
If stub is configured for the specific areas, you will see the It is a stub
area note within that area section. When a totally stubby area is
configured, you will see the It is a stub area, no summary LSA in this
area note in the Area section.
Chapter 9
Cisco Public
63
OSPF Stub Areas (Cont.)

The show ip ospf database command enables you to see the
OSPF database on your router.
If the stub area is configured, there should be no LSA Type 5s and Type
7s within that area, but you will see an additional LSA Type 3 with the ID
0.0.0.0.
This is the default route injected by the ABR. Other summary LSAs can
also be seen in the database.
When the area is configured as a totally stubby area, only one summary
LSA can be seen: the LSA with the ID 0.0.0.0, which is the default route
injected by the ABR.
To observe your routers OSPF Hello message exchange, use

the debug ip ospf hello command. If adjacent routers in the
same area do not agree on the OSPF area type, a message
similar to OSPF: Hello from 192.168.23.2 with mismatched
Stub/Transit area option bit will appear. If you see this message,
check the stub configuration on both adjacent routers.
Chapter 9
Cisco Public
64
Chapter 9 Summary
Chapter 9
Cisco Public
65
Chapter 9 Summary
Troubleshooting AAA
Troubleshooting the Dysfunctional Totally Stubby Branch
Areas
OSPF Stub Areas
Chapter 9
Cisco Public
66
Chapter 9 Labs
Lab 9-1 Network-Mirror
Lab 9-2 In Synch
Chapter 9
Cisco Public
67
Chapter 9
Cisco Public
68
Acknowledgment
Some of the texts and images are from Troubleshooting and Maintaining Cisco
IP Networks (TSHOOT) Foundation Learning Guide by Amir Ranjbar
(158720455X)
Copyright 2015 2016 Cisco Systems, Inc.
Special Thanks to Bruno Silva
Chapter 9
Cisco Public
69

CCNP TSHOOT - v7 - Ch09 POLONA V0.4

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CCNP TSHOOT - v7 - Ch09 POLONA V0.4

Hochgeladen von

Copyright:

Verfügbare Formate

Chapter 9:

Bank of POLONA Trouble Ticket 2

Bank of POLONA Trouble Ticket 4

Troubleshooting Case Study: Bank of POLONA Scenario

Trouble Ticket 1 Process Summary - Issue #1

Telnet from HQ to BR3 router.

Ping SRV2 from BR3 using

Ping 192.168.2.200 source

Check BR3S routing table

Show ip route eigrp

Check protocols on BR3

Check neighbours on BR3

Show ip eigrp neighbors

Router eigrp 100

Ping 192.168.2.200 source

IPSec-GRE tunnel WAN link

IPSec-GRE tunnel WAN link

EIGRP active on BR3 link &

When redistributing Interior Gateway Protocol (IGP), static and

Trouble Ticket 1 Issue #2

Trouble Ticket 1 Process Summary - Issue #2

Traceroute from PC0 to

Path follows R1 to HQ routers

Shut down R1s Eth 0/1

Get VRRP information on R1

VRRP group1 config on E

No object tracking for

No objects being tracked

Get VRRP information on R2

VRRP group1 config on E

No object tracking => no way of

Create a track object on R1

track 1 interface ethernet 0/1

Config R1s VRRP gp 1 to

Int eth 0/0

Int eth 0/1

Track object 1 state

Troubleshooting VRRP with Interface Tracking

Sub-optimal path for traffic

Troubleshooting VRRP with Interface Tracking

Troubleshooting VRRP with Interface Tracking

FHRP Tracking Options

To configure HSRP interface tracking, use:

FHRP Tracking Options

Object tracking of IP SLA operations allows clients (such as

FHRP Tracking Verification

Trouble Ticket 1 Issue #3

IP SLA Verification Commands

IP SLA Troubleshoot Example Issue #3

Troubleshooting EIGRP Summarization

The EIGRP summary-address is applied within interface configuration mode,

Troubleshooting EIGRP Summarization Issue #1

2007 2016, Cisco Systems, Inc. All rights reserved.

Trouble Ticket 2 Issue #2

Trouble Ticket 2 Process Summary - Issue #2

Ping from PC0 to IPv6

Check PC0s Eth 0/1

Show ipv6 interface brief

Ping from PC0 to IPv6

Internet not reachable.

Ping from R1 & R2 to IPv6

Next step at HQ router:

Show ipv6 protocols | section