Maintenance Tools

Saving credentials:
config) ip ftp username [name]
config) ip ftp password [pass]
config) ip http client username [name]
config) ip http client password [pass]

Automatic archive config:

config) archive
archive) path [ftp|http|https|tftp]:[ip] !!! destination.
archive) write-memory !!! to have a new archive created whenever memory is written. optional.
archive) time-period [x] !!! frequency.
archive) maximum [#] !!! if stored locally, oldest file will be overwritten at max.
sh archive !!! shows next file name, max configured, list of files.
archive !!! manually create a new archive.

A copy command will merge files, not always producing the expected results. configure replace will
overwrite.
config) configure replace [archive|flash|ftp|http|https|nvram|system|tftp|xmodem]:[ip]/name
total number of passes: [#] !!! # of changes made.

Ping: Checks Layers 1, 2, and 3. Sends ICMP echo messages to a specific destination. For every echo
received from the destination, a ! is displayed. A Destination host unreachable indicates a PC can
reach its DG but the DG doesnt know about the dest. network. A TTL expired in transit message
indicates the device can reach the DG, but there is probably a loop in the network.
sizenumber of bytes per datagram (default of 100 in ios).
repeat

number to send.

timeout

number of seconds to wait for a reply (default of 2, 0 to test load).

source

specifies source of datagrams.

df-bit

do not fragment bit, use to test mtu size. router drops instead of fragmenting, shows m reply.

sweep

range of sizes: use to determine mtu across a link, set a min, max, and interval to test each.

u destination unreachable.

& ttl exceeded.

q source quench (destination busy).

? unknown packet type.

m cant fragment (may be due to df-bit).

Traceroute: Verify connectivity as well as the path a packet takes through the network. Repeated IPs =
loop. Can source.
* probe timed out.

h host unreachable.

a administratively prohibited (acl).

n network unreachable.

q source quench (destination busy).

p protocol unreachable.

i user interrupted.

t timeout.

u port unreachable.

? unknown packet type.

Telnet: For troubleshooting Layers 4 and 7. Alternate ports can be specified besides Telnet (23).
telnet [ip] (port #) (source [ip])

Filtering Output: Use the | character followed by a command to filter, can be multiple, no spaces
around a second |, use ( ) to include a space. Case sensitive!
include

only lines including text.

exclude

all lines besides ones matching text.

begin

start at line matching text.

section

shows entire section matching text.

begins with text.

redirect [protocol://[ip]/[filename.txt]] !!! sends to a file on a remote device.

tee [protocol://[ip]/[filename.txt]] !!! will be both displayed onscreen and saved to a file.

Pelirrojoo 12/14

append [protocol://[ip]/[filename.txt]] !!! adds to end of a file, does not overwrite.

longer-prefixes

!!! not a | filter. combine with an ip/mask (w/o mask is classful); shows all subnets.

Commands for hardware troubleshooting:

sh proc cpu !!! 5 sec, 1 min, 5 min cpu interval stats. listing of running processes and their respective utilization statistics.
sh memory !!! displays summary info about processor and i/o memory, followed by a more comprehensive report of memory
utilization.
sh interfaces !!! shows layer1/2 interface status, load info, error statistics, in/output drops and errors.
clear counters !!! will clear stats for above.
sh controllers !!! displays stats about an interface, info varies for different interface types.
sh platform !!! detailed info about a router/switch hardware platform.

Build a diagram:
sh ip interface brief !!! local ports status, ips, and if enabled.
sh cdp neighbors !!! neighboring cisco devices with cdp. local/remote interfaces, model #.
sh cdp neighbors detail !!! shows management ips and ios version.
show version !!! shows local model number and interface types.

NetFlow: Can distinguish between different traffic flows. A flow is a series of packets, all of which have
shared header information such as source/destination IPs, protocols, port numbers, and TOS info.
NetFlow can keep track of the number of packets and bytes observed in each flow; stored in a flow
cache. Flow information is removed from a flow cache if the flow is terminated, times out, or fills to
capacity. Rather than using a standalone implementation, you can export the entries in a routers flow
cache to a NetFlow collector, which is a software application running on a server in your network, used
for analysis.
if) ip flow [ingress | egress] !!! select interfaces to collect data on.
config) ip flow-export destination [ip] [port #] !!! identify netflow collector. match port #.
config) ip flow-export version [#] !!! match collector software.
config) ip flow-export source [int] !!! to identify the interface the netflow info will export from.
sh ip cache flow !!! summary of flow info, types of packets/sec, source interface/ip and dest interface/ip.

Embedded Event Manager (EEM): Enables you to create your own event definitions and specify custom
responses to those events. For example, triggered by an event such as a syslog message, SNMP trap,
issuing an IOS command, etc. Can take actions such as sending SNMP traps, write log messages, execute
an IOS command, capture output of a show command, send an email, or execute a Tcl script.
config) event manager applet [name]
applet) event [application/cli/snmp/etc] (occurs) (pattern) (period) (skip [yes|no]) (sync [yes|no])
applet) action [name] [cli/mail/policy/publish-event/reload/snmp-trap/syslog]

Switch Performance
Port Errors: Excessive frames dropped, TCP slow start, small window sizes, packet drops, cabling issues,
etc.
sh interfaces !!! detailed info, includes errors, rates, queues, runts, etc.
sh interfaces (fx/x) counters (errors) !!! shows # of in and out packets. (errors) shows errors.

Duplex Mismatch: Both ends should be left to auto-negotiate. Auto MDIX (Medium-Dependent Interface
Crossover) will detect if a port needs a crossover or straight-through cable. Requires both ends to have
auto speed/duplex (defaults to half). Largest indicators are high FCS-Err (full-duplex end) and
Late-Col (half-duplex end) counters. Check with sh int counters errors.
High CPU: CPU load is usually low, even under high utilization thanks to the TCAM. The TCAM maintains
forwarding logic at the data plane; the CPU is rarely used to forward traffic. Verify with sh proc cpu,
second number in 5 sec utilization is interrupt processing. Common causes are routing
updates, debug commands, and SNMP polls. If high CPU is due to interrupts, check the TCAM utilization,
otherwise determine what processes are using a high percentage and investigate. STP may be a cause; a
failure could lead to a loop and a broadcast storm. High CPU may also be a symptom of another issue.
sh processes cpu !!! shows time intervals of utilization as well as each process individually.

Pelirrojoo 12/14

TCAM: L3 info. If the TCAM is full or does not have the info needed to forward traffic, the traffic is punted
to the CPU, which has limited forwarding capacity. Common punt causes are: routing protocols, STP (and
other protocols) sending multicast/broadcasts, admin connections (Telnet/SSH), packets not using a
feature supported in hardware (GRE tunnels), or a full TCAM (most likely). Some switches allow you to
adjust memory allocation among other features through SDM templates.
sh platform tcam utilization !!! shows tcam max and usage.
sh sdm prefer (?) !!! shows current template and max values. (?) to list options.
config) sdm prefer (?) (option) !!! (?) to list options. (option) to apply. requires reboot!

Router Performance
High CPU: Normal behavior includes high CPU spikes, but if it remains high, performance may be
impacted. May cause routers to not send routing protocol messages to neighbors, causing adjacencies to
fail and some networks to become unreachable.
sh proc cpu (history) !!! (history) gives graph over 1 min/hour and 3 days. indicates if spike or ongoing.

ARP Input: Sends ARP requests. One cause may be a default route pointing out an Ethernet interface (ip
route 0.0.0.0 0.0.0.0 f0/0); this should be avoided because ARP requests have to be sent for every
destination IP, in every packet that is received by the router. The better method is to specify the nexthop IP (not the exit interface) with static routes because this will only use a single ARP request for the
gateways MAC.
sh ip arp !!! arp cache. incomplete state may mean malicious scan of a subnet or a route pointing out int.
sh proc cpu | in ARP Input !!! to check the process utilization.

IP Background: Handles an interface changing states. Up/down or IP changing. Repeated state changes
(i.e. flapping due to bad cabling) may cause this process to spike CPU.
Net Background: Interfaces have buffers, called queues. If an interface needs to store a packet in a
buffer but its queues are full, the router can pull from the global buffer that it maintains. Throttles,
ignored, and overrun parameters incrementing on an interface may be caused by the Net
Background process, causing high CPU. A common cause is a speed mismatch.
sh int !!! throttles/overruns/ignored counters may mean net background process is reallocating buffer space.

TCP Timer: This process runs for each TCP router connection. Many connections can cause high CPU,
whether they are established (successful completion of 3-way handshake) or embryonic (3-way
handshake is only 2/3 completed, waiting on ACK from client, may be due to connectivity issues or
malicious intent {DoS Attack}).
sh tcp statistics !!! # of tcp segments router sends/receives, including initiated, accepted, established, and closed. a high #
indicates why tcp timer process is high. high embryonic may mean dos attack.

Excessive Memory Utilization:

Memory Leak: Processes allocate a block of memory when started. Once finished, the process should
return all allocated memory to the routers pool. If all allocated memory is not returned, there is a leak.
May be the result of a bug in the IOS.
sh memory allocating-process totals !!! shows total available memory of router, used, free, lowest, etc.
sh process memory !!! to see memory utilization per process.

Buffer Leak: Similar to a memory leak; when a process does not return a buffer to the router when the
process has finished using the buffer. An interface with an input queue above its max capacity is
considered a wedged interface. See with sh int. sh buffers can also help diagnose. Compare totals to
# of free. If few are free, that indicates a buffer leak.
Memory-Allocation Failure: Produces MALLOCFAIL message when a process attempts to allocate a
block of memory and fails to do so. Commonly caused by a security issue such as a virus or worm
infesting the network. May also be caused by an IOS bug.
Excessive BGP Memory Use: BGP runs multiple processes and can consume a significant amount of
memory. sh processes memory | in BGP will show those processes memory use. Consider filtering out
unneeded BGP routes, upgrading the routers memory, or running BGP on a different platform that has
more memory. sh diag lists specific line cards and identifies which is running low on memory.
Packet Switching Modes:
Pelirrojoo 12/14

Process Switching: Router removes L2 header, examines L3 address, and makes a forwarding decision
for every packet. L2 header is rewritten (source/dest. MACs, new FCS calculated), then forwarded out
the appropriate interface. CPU is directly involved.
Fast Switching: Aka Route Caching. Fast cache maintained in data plane; contains info about how traffic
from different flows (streams of packets) should be forwarded. First packet is process-switched by the
CPU (Routing Processor, software). Once that decision is made, the decision is stored in fast cache.
Subsequent packets of the same flow are forwarded by the switching engine (hardware) based on the
fast cached decision, instead of making a new decision for every packet. Reduces CPU utilization.
Enable by disabling CEF with no ip route-cache cef.
sh ip int (fx/x) !!! shows if fast switching or cef is enabled (flow switching = netflow).
sh ip cache !!! shows contents of route cache if fast switching is enabled.

CEF: Topology based. Maintains FIB and Adjacency tables for more efficient table lookups. Tables are
populated with info gleaned from the routers IP routing table and ARP cache. Does not require first
packet of a data flow to be process-switched. Entire flow can be forwarded at the data plane. Enabled
by default. If off, enable globally with ip cef or per interface with ip route-cache cef. Can perform either
per packet or per destination (default) load balancing.
Forward Information Base (FIB): L3 forwarding info normally found in the IP routing table (destination
networks, masks, next-hop IPs), in addition to multicast routes and directly connected hosts.
Adjacency Table: L2 next-hop info; frame header info required by the router to properly form frames
(egress interface and next-hop MAC, discovered via ARP). The IB references entries in the adjacency
table when performing a route lookup.
If traffic is observed not conforming to info in the IP routing table, remember that the table is maintained
by the routers control plane and is used to build the tables at the data plane. CEF operates in the
data plane and uses the FIB.
sh proc cpu | in IP Input !!! may be high if cpu of router is used to process-switch traffic (cef off).
config) ip routing !!! must be enabled for cef to function.
sh ip cef !!! disp fib contents. prefix, next-hop, and int. receive = process locally, attached = connected.
sh ip cef [ip] (mask) !!! fib info, what the outgoing interface and next-hop are. (mask) for subnet.
sh ip cef exact-route [source ip] [dest ip] !!! outgoing int and next-hop for packet from source to dest.
sh ip cef adj [egress fx/x] [next-hop ip] detail !!! displays destinations reachable via int and ip.
sh adjacency detail !!! shows cef info used to construct frame headers needed to reach the next-hop ip.
sh ip arp !!! shows arp cache (learned/configured macs/ips/ints). stored in the control plane.
clear arp-cache !!! to clear the arp cache.
sh frame-relay map !!! shows frame relay int, dlci, pvc, and next-hop ip.
sh ip nhrp !!! displays next-hop resolution protocol used with dmvpns.

L2 Trunks, VTP, and VLANs

Trunks: Two encapsulation types, 802.1Q (Standard), and Inter-Switch Link (ISL, Cisco proprietary). Not all
switches support both.
Encapsulation Mismatch: To form a trunk, both ends must be using the same encapsulation type. If a
switch supports both, it will use DTP to negotiate the encapsulation method, ISL is preferred if both
support it. sh int trunk will show the operational encapsulation. sh int [fx/x] switchport will show the
Administrative and Operational trunking encapsulations. Use switchport nonegotiate to disable DTP.
Incompatible Trunking Modes: Issue sh int [fx/x] switchport and look for Administrative and
Operational modes. Default varies. Limited connectivity is possible between an access port and a
trunk port if the access port matches the native VLAN.
access

permanent non-trunking, even if dtp messages are received.

trunk

manually configured to be a trunk.

dynamic desirable

actively seeks to become a trunk through dtp negotiation. if other end agrees, trunk is formed, if not,
remains access.

dynamic auto

passively waits for dtp messages to arrive to form a trunk. if received, trunk is formed, if not, remains
access and listens for dtp messages.

Pelirrojoo 12/14

VTP Domain Name Mismatch: VTP domain names must match for DTP to dynamically form a trunk.
They are case sensitive.
Native VLAN Mismatch: Only happen with 802.1Q trunks. VLAN 1 is native by default. Carries untagged
traffic across a trunk. Must match on both ends, if not, traffic from one VLAN may leak into another.
May also cause STP issues. CDP will inform you of a mismatch. sh interfaces trunk will show the native
VLAN of the trunk on the local end; check both ends.
Allowed VLANs: By default, trunks forward traffic for all VLANs. It is possible to change this by allowing
only specific VLANs manually with the switchport trunk allowed vlan (add|remove|except|all|none)
[VLAN] interface command, or dynamically with VTP Pruning (vtp pruning global command). show
interface (fx/x) [switchport | trunk] will show the allowed VLANs, or view the running config. If traffic is
not flowing across a trunk, make sure the VLAN is allowed and not pruned!
VTP:
Domain Name Mismatch: Switches sharing VLAN info between one another using VTP need to have
matching VTP domain names. They are case sensitive. Use sh vtp status to see the current domain
name.
Version Mismatch: Three versions: 1, 2, and 3. Default is 1, if using it, all switches need to be running 1.
2 and 3 are inter-compatible. Use sh vtp status to show the current VTP version and capable versions.
Mode Mismatch: Four modes: server, client, transparent, and off. To use the VLAN info contained in VTP
messages, a switch must be a server or a client. Transparent mode will ignore the information but still
forward it on. Of is the same as Transparent, but will not forward (Only exists in version 3). Use sh vtp
status to see the Operating Mode.
Password Mismatch: If used, passwords must match. sh vtp password to see pass. sh vtp status to see
MD5 hash. Case sensitive!
Higher Revision Number: Advertisements with a higher revision number will overwrite the database on
switches with a lower number. Reset by toggling the domain name or changing the mode to
transparent. Make sure to reset the revision number when adding a switch!
debug sw-vlan vtp [ events | packets | pruning ] !!! to debug vtp.

VLANs:
Incorrect IP Addressing: Make sure static host, SVIs, router interfaces, and default gateways have
correct IPs. Addresses may have typos which put the device within the wrong network or they may
have the wrong default gateway.
Missing VLAN: A VLAN must be created on a switch for the switch to pass traffic over a trunk for that
VLAN. sh vlan brief will give a listing of all created VLANs. If sh int [fx/x] switchport displays the access
VLAN as Inactive, that indicates that the VLAN is not created, even though the port may be up/up. If
not using VTP, create the VLAN on all necessary switches.
Incorrect Port Assignment: Ensure that ports are assigned to the correct VLAN. sh vlan brief will show
assignments. Trunk ports or ports assigned to nonexistent VLANs will not be listed!
MAC Address Table: Dynamically learned MACs can be displayed with sh mac address-table dynamic.
MACs, VLANs, and ports are shown. Reset with clear mac address-table dynamic.

Spanning Tree and L2 EtherChannels

STP prevents L2 loops while allowing for redundancy. Uses BPDUs to build the topology, which contain info
on ports, addresses, priorities, and costs. Exchanged every 2 seconds by default.
Root Bridge: Reference point for STP topology. Lowest BID wins election. BID = priority (32,768 def) +
MAC. Lowest MAC is only used when priorities tie. All other bridges in the topology are considered
nonroot bridges.
Root Ports: Every nonroot bridge has a single root port. Its the port on the switch that is closest to the
root bridge (lowest root path cost). Cost is inversely proportional to bandwidth. If cost is tied on
multiple uplinks, the lowest sending BID is used to break the tie, then the lowest sending Port ID.
Pelirrojoo 12/14

Designated Ports: Every network segment has a single designated port. This is the port on the segment
that is closest to the root bridge (based on cost). All ports on the root bridge are DPs.
Blocked: Nondesignated, ports blocking traffic to create the loop-free topology. Doesnt forward traffic
during normal operation, but does receive BPDUs to determine the state of the STP topology. Only one
per segment. For DP DP election, lowest path cost, lowest upstream BID, then lowest upstream PID.
STP, CST, and PVST+ use the following states, cumulative time is 50 seconds:
Blocking: Port remains here until it needs to transition. If it needs to, it will wait 20 seconds by default
(max age). If a new BPDU is not received before the max age time expires, the former BPDU is
considered stale, and the port transitions to Listening.
Listening: Port remains here for 15 seconds by default (forward delay). Port sends BPDUs to inform
adjacent switches of its intent to forward data. Also receives BPDUs from other switches to help build
the STP topology, determine the root path cost, and determine designated ports.
Learning: Port remains here an additional 15 seconds (forward delay). Adds entries to the MAC address
table, while also sending/receiving BPDUs to ensure that the decisions made in relation to the STP
topology are still accurate.
Forwarding: Port moves here and begins forwarding frames while continuing to learn MAC addresses as
well as send/receive BPDUs. Root ports and designated ports are in this state.
RSTP and MST use a handshaking mechanism, rather than timers, as their primary method of
convergence; usually in 5 seconds or less. If handshaking fails, they rely on the same timers as CST for
backup. If a neighboring switch is using CST, timers are used with them for backwards compatibility.
Blocking and Listening modes are merged into a single discarding mode.
sh span (vlan [#]) !!! root bridge id & current bridge ids/timers, ports roles/states/costs/priorities/etc.
sh span int [fx/x] detail !!! bpdus tx/rx, port id, designated/root bridges priorities and macs. root ports should only receive bpdus
and designated ports should only send bpdus.

MST: Region, revision number, and MSTI VLAN mapping must match between all switches. Preceding
info is sent as a hash.
sh span mst config !!! shows region name, revision number, and mapping.

Corruption of MAC Address Table: An STP failure may cause duplicate frames to be sent around a
network, confusing a switch as to where a frame is sourced from. As a MAC flaps between different ports
on different segments, the switch will display the message %SW_MATM-4-MACFLAP_NOTIF: host [MAC]
in vlan [#] is flapping between port [fx/x] and port [fx/x].
Broadcast Storms: During an STP failure, since L2 frame do not have TTL fields, broadcast frames
endlessly circulate through the L2 topology, consuming resources on both switches and attached
devices.
PortFast: If using PVST+, RPVST+, or MST, when a BPDU is received on a PortFast interface, it will revert
to normal behavior.
if) spanning-tree portfast (trunk) !!! (trunk) can cause a temporary loop.
sh run int [fx/x] !!! to check if enabled.
sh span int [fx/x] portfast !!! will show if enabled and on which vlan.
sh span int [fx/x] detail !!! will show this port is in the portfast mode as well as many other details.
sh spanning-tree (summary) !!! under type, will say edge. (summary) will show if enabled globally.

BPDU Guard: Used to enforce domain borders by not allowing BPDUs to be received. If a BPDU is
received, the port is placed in the err-disabled state. Revert with err-disable recovery or bounce the
port.
if) span bpduguard enable !!! per interface.
config) span portfast bpduguard default !!! globally.
sh int status !!! to find err-disabled ports.
sh span summary !!! shows if globally enabled.
sh span int [fx/x] detail !!! will show bpdu guard is enabled (by default) as well as many other details.
%spantree-2-block_bpduguard: received bpdu on port [fx/x] with bpdu guard enabled. disabling port.
%pm-4-err_disable: bpduguard error detected on [fx/x], putting [fx/x] in err-disable state.

Pelirrojoo 12/14

BPDU Filter: Suppresses the sending and receiving of BPDUs on an interface, for security reasons. No
need to send BPDUs to an end station or a router.
config) span portfast bpdufilter default !!! enables globally on all portfast interfaces. if a bpdu is received, interface will transition
through the stp states.
if) span bpdufilter enable !!! per interface, received bpdus are ignored.
sh span summary !!! shows if enabled globally.
sh span int [fx/x] detail !!! will show bpdu filter is enabled (by default) as well as many other details.

Root Guard: Protects the root bridge by ensuring that certain ports on non-root bridges are prevented
from becoming root ports. Ignores superior BPDUs and places port in the Root Inconsistent state. No
need to bounce, just remove device sending BPDUs.
if) span guard root !!! enable manually, per port, on device/port leading to bridge you dont want as root.
sh span int [fx/x] !!! to see if enabled.
sh span inconsistentports !!! lists inconsistent ports.
%spantree-2-rootguard_block: root guard blocking port [fx/x] on vlan [x].

Loop Guard: Prevents a nondesignated (blocking) port from transitioning to forwarding by placing it in the
Loop Inconsistent blocking state should it stop receiving BPDUs. May occur if a remote switch is still
running but stops sending BPDUs due to software failure, unidirectional link, etc. Transitioning the port to
forwarding would cause a loop.
if) spanning-tree guard loop !!! per interface.
config) spanning-tree loopguard default !!! globally, on all point-to-point links.
sh span inconsistent ports !!! see what ports are blocked.
%spantree-2-loopguard_block: loop guard blocking port [fx/x] on vlan [x].

Automatic Private IP Add. (APIPA) Address: Indicates a PC is not able to receive its own IP via DHCP.
Uses the 169.254.x.x/16 range.

EtherChannels and Inter-VLAN Routing

L2 EtherChannels: Multiple ports combined into a single logical bundle, also known as a port channel.
Can be L2 or L3.
if) channel-group [x] mode [on|active|passive|auto|desirable] !!! to assign an interface to a port channel.

Mismatched Port Configurations: Config of all ports making up an EtherChannel, on both ends, should
be identical. Speed, duplex, trunk mode, native VLAN, allowed VLANs, and L2/3 settings. Port channel
inherits config from the physical ports.
Mismatched EtherChannel Configurations: Both switches should be using compatible protocols and
modes. LACP, PAgP, or on are not compatible with one another. PAgP: auto/desirable, LACP:
active/passive.
sh run int [fx/x] !!! compare configurations between ports and switches, must be identical.
sh etherchannel summary !!! flags, protocol, ports, group. r=l3, s=l2, u=in use, p=bundled, i=stand alone.

Inappropriate Distribution: Hashing algorithm used to distribute traffic should be appropriate for the
load. Use powers of 2.
config) port-channel load-balance [ ? | method ] !!! to change, global per switch. (?) for options.
sh etherchannel load-balance !!! shows configured method.
sh etherchannel (#) port-channel !!! to see how links are loaded, shows in hex.

L3 EtherChannels: No need to worry about trunk mode, native VLAN, or allowed VLANs. Port channel
inherits physical attributes (L2/L3) from interfaces when created. Either issue no switchport to the
interfaces before assigning a channel group, or create the port channel with interface port channel, issue
no switchport to the port channel, then assign interfaces.
Router-on-a-Stick: Common issues are: trunk encapsulation mismatch, incorrect VLAN assignments on
routers subinterfaces, incorrect IP add, mask, or DG on PCs, switchport connected to router configured
as an access port, switchport connected to router configured to use DTP (which isnt supported by the
router), or switch ports connected to PCs being in the wrong VLAN.
config) interface [fx/x].[sub-if #] !!! on router. good practice to match vlan #.
if) encapsulation dot1q [vlan #]

Pelirrojoo 12/14

if) ip add [ip] [mask]

sh vlans !!! use on router to confirm encapsulation type.
sh interfaces trunk !!! use on switch to confirm encapsulation type.

Switched Virtual Interfaces: Create an SVI with interface vlan [x], assign an IP to be the DG, and ensure
ip routing is globally enabled. The VLAN the SVI is created for needs to exist locally, the SVI must be
enabled and not shut down, and there must be a switchport (access or trunk) that is up/up and STP
forwarding for that specific VLAN.
sh ip int brief !!! look for up/up state.
sh int vlan [#] !!! shows mac used and ip.
sh ip int vlan [#] !!! same as above plus more ip settings.

Routed Ports: Physical ports that act as L3 interfaces. No VLAN association, STP, DTP, nor subints. Use for
uplinks, enable ip routing!
if) no switchport !!! how to enable. assign an ip!
sh int [fx/x] switchport !!! will display switchport: disabled.

Switch Security
Port Security: Helps avoid CAM table flooding and ensures that only specific devices can connect to
certain switch ports. Common problems include being configured but not enabled, static MACs being
wrong, max MACs, violations blocking legit users, and running config not saved. Sticky MACs are only
saved to the running config, must write config to save across reboots.
if) switchport port-security !!! must be enabled. port must be in access mode!
if) switchport port-security maximum [max #] (vlan) !!! set max macs allowed. per vlan optional. def = 1.
if) switchport port-security mac-address [(mac) | sticky] !!! mac in dotted triple. if > 1, increase max.
if) switchport port-security violation [ shutdown | restrict | protect ]
shutdown

default. put in err-disabled state, must be bounced or err-disable recovery used.

restrict

port stays up, packets from violating macs dropped. switch can send snmp trap and syslog msg.

protect

port stays up, violating macs have packets dropped, but no notifications/records.

sh port-security !!! shows per port counters and security action.

sh port-security interface [fx/x] !!! lists options and their settings.
sh port-security address !!! lists static macs (and stickys) configured. use to verify if static is correct.
sh int status !!! will show err-disabled ports.
sh errdisable detect !!! see if psecure-violation is enabled. it is by default.
config) errdisable recovery cause psecure-violation !!! to enable auto recovery.
sh errdisable recovery !!! to see if recovery is enabled for above. disabled by default. bottom shows ports.
%pm-4-err_disable: psecure-violation error detected on [fx/x], putting [fx/x] in err-disable state
%port_security-2-psecure_violation: security violation occurred, caused by mac add [mac] port [fx/x]

DHCP Snooping: Prevents rogue DHCP servers. Creates a binding table to keep track of which devices are
connected to which interfaces, based on the IP handed out by the DHCP server.
config) ip dhcp snooping !!! enable globally.
config) ip dhcp snooping vlan [#] !!! additionally enable for specific vlans.
if) ip dhcp snooping trust !!! trust interfaces connected to dhcp servers or uplinks.
if) ip dhcp snooping limit rate [ pkts/sec ] !!! to limit dos attacks on untrusted ports. optional.
config) no ip dhcp snooping information option !!! disable option 82 if server does not support it.
sh ip dhcp snooping !!! shows if enabled, on what vlans, if 82 is enabled, trusted interfaces, rate limit.
sh ip dhcp snooping binding !!! shows binding table of macs and ips, lease, type, vlan, and interfaces.

Dynamic ARP Inspection: Layer 2. Prevents ARP spoofing (MITM attacks) by using DHCP Snoopings
binding table. When it detects an invalid ARP request or response incoming on an untrusted interface, it
drops the packet and generates the syslog message %SW_DAI-4-DHCP_SNOOPING_DENY: 1 invalid ARPs
(req) on [fx/x], vlan [x]. Verify with sh ip arp inspection.
config) ip arp inspection vlan [#] !!! enable dai.
if) ip arp inspection trust !!! interfaces where dai should not be performed. switch uplinks or static ips.

Pelirrojoo 12/14

IP Source Guard: Layer 3. Prevents IP spoofing. Uses DHCP Snoopings binding table. If a source IP is
received on an incorrect interface, the switch drops the traffic. Exempt static interfaces.
if) ip verify source (port-security) !!! enable. add (ps) to enable checking mac as well; requires port sec!
sh ip verify source !!! shows interface, filter type, mode, ip, mac, and vlan.

Protected Ports: Denys all traffic from flowing between devices connected to interfaces within the same
VLAN, on the same switch. Protected ports can only communicate with ports that are not protected ports.
if) switchport protected !!! must be enabled on both ports.
sh int [fx/x] switchport !!! at end, protected: true/false.

Private VLANs: Use a single IP subnet (saves IPs) across multiple VLANs while still maintaining traffic
isolation boundaries at L2. Breaks up a single Primary VLAN into multiple non-overlapping Secondary
VLANs. VTP v1 & v2 wont work, use transparent mode. Configuration is locally significant; configure on
each switch that is interconnected.
sh int private-vlan mapping !!! interfaces, secondary #, type.
sh vlan private-vlan !!! primary, secondary, type, ports.
sh int [fx/x] switchport !!! admin/operation mode, access mode vlan, host association, operational pvlan.

Secondary: Can communicate with ports on the Primary VLAN, but not with any other Secondary VLAN.
Shares the same IP subnet as the Primary, but each uses an individually assigned VLAN ID, which is
associated with the Primary VLAN. Trunking Secondary VLANs across trunk links is supported by most
switches. Two types:
vlan) private-vlan [ community | isolated ]

Community: Isolates hosts between different Community VLANs while allowing hosts within the same
Community to communicate with one another, as well as the Promiscuous port. Same behavior as a
normal VLAN. Multiple Community VLANs can be created and associated to the same Primary VLAN.
Isolated: Hosts arent able to communicate with other Isolated/Community ports, only the Promiscuous
port. Only one Isolated VLAN can be associated per Primary VLAN; multiple hosts are assigned to the
same Isolated VLAN with their traffic separated.
Primary: A normal VLAN used as the basis for a PVLAN, represents the set of Secondary VLANs to the
outside world. 1 per PVLAN, all Secondarys share the same Primary and broadcast domain.
vlan) private-vlan primary
vlan) private-vlan association [2nd vlan (list | add | remove)]

Promiscuous Ports: Special ports assigned to the Primary VLAN that can communicate with any port
within any (mapped) Secondary VLAN. Allows shared devices (routers, firewalls, printers, or other
gateway devices) to communicate with Secondary VLAN ports, usually connected to the default
gateway or an SVI. Assign port as promiscuous and do vlan mapping.
if) switchport mode private-vlan promiscuous !!! make interface promiscuous and do mapping below.
if) switchport private-vlan mapping [pri vlan] [2nd vlan ( list | add | remove )]
if) private-vlan mapping [2nd vlan ( list | add | remove )] !!! on primary vlans svi.

Host Ports: Ports that connect to regular hosts in either Isolated or Community VLANs. Only communicate
with Promiscuous ports or ports within the same Community VLAN. Dont use normal access VLAN
config; assign port as host and do host-association.
if) switchport mode private-vlan host !!! make interface a host and do association below.
if) switchport private-vlan host-association [ pri vlan ] [ 2nd vlan ]

VACLs: While Protected ports and Private VLANs restrict all flow between VLANs, VACLs allow granular
control. ACLs match the traffic, VLAN access maps use match/action statements, and the vlan filter
command defines which VLANs the access map will apply to. A sequence without a match statement will
match all traffic. There is an implicit deny at the end.
config) vlan access-map [ map-name ] (sequence #)
access-map) match [ip|mac] address [acl # | acl-name | mac-acl-name] !!! can be multiple per action.
access-map) action [ drop | forward (capture) | redirect (fx/x) ]
config) vlan filter [ map-name ] vlan-list [ (#) | (vlan-list) ]
sh vlan access-map (name) !!! shows configured rules.
sh vlan filter ( access-map [name] | vlan [#] ) !!! shows which vlans the map is applied to.

Pelirrojoo 12/14

FHRPs
On a PC, arp a will show you the MAC of the vIP (but will be cached during a failure), however traceroute
will show the IP of the actual router, which changes during a failure.
HSRP: Proprietary protocol. Uses a vIP and vMAC to represent a virtual router within an HSRP group. vMAC
takes form of 0000.0c07.acxx where xx is the group # in hex and 07.ac indicates HSRP (9f.f = HSRPv2).
One router is active, another is standby, and any others are in the listen state. Hellos sent every 3
seconds, hold time is 10 seconds. If an interface is shutdown, it will send a resign message. If
preemption (off by default) is enabled, a router with a higher priority will send a coup message to
take over.
sh standby (brief) !!! interface, group, priority, preempt, state, active/standby addresses, vip.
sh standby [fx/x] !!! show active vmac/vip & timers. standby ip & priority. local priority & int tracking.
if) standby [#] track [(fx/x) | (track #)] (dec #) !!! to tack an int/object for decrementing priority.
debug standby (terse) !!! shows state changes. (terse) removes hellos and advertisement packets.

VRRP: Virtual Router ID (VRID/Group) is made up of a single master, with any other routers placed in the
backup state. Preemption is on by default. Hello is 1 second by default, master down is 3 seconds.
vMAC takes form of 0000.5e00.01xx where xx is the group # (VRID) in hex and 00.01 indicates VRRP. vIP
does not have to be unique, it can be the IP of a routers physical interface (router with matching IP will
be the master, regardless of priority because it will have a priority of 255 automatically). VRRP cant
track interfaces, only track objects.
sh vrrp !!! will show object tracking and decrement.
sh vrrp brief !!! interface, group, priority, timer, vip owner, preempt, state, master ip, & group ip.
sh vrrp interface [fx/x] !!! state, vmac, priority, & timers.
sh track !!! will show track objects, their status, and what is tracking them.

GLBP: 1 AVG and up to 4 AVFs in a group. AVG (highest priority or IP) hands out AVF MACs by replying to
ARP requests for the default gateway (GLBP vIP). AVG is also an AVF itself. AVFs process the frames sent
to their MAC addresses. Preemption is off by default. vMAC takes the form of 0007.b400.xxyy where
xx = the group number (in hex) and yy = the AVF number.
sh glbp brief !!! interface, group, avf #, priority, address, active & standby routers. avf of - = avg. states of active/listen refer to
if an avf are forwarding for the virtual macs in the address column.
sh glbp (fx/x) !!! huge amount of details about state, mac, ip, timers, weighting, etc. and forwarder info.

Weighting: Used to determine which router becomes the AVF per ARP request. Each router begins with a
max weight (1-254, def = 100). If using tracking, as interfaces go down, the weight is decreased by the
decrement value. Thresholds are used to determine if a router can be an AVF; if the weight falls below
the lower, the router must give up the AVF role, it can resume if the weight returns (enable
preemption!). Optionally, the weight at which the router can return to its AVF role can be changed
(upper). If using the weighted distribution method, weight is used for load-balancing. Decrementing
weight will only reduce traffic flow if the lower isnt passed!
if) glbp [group #] load-balancing [round-robin | weighted | host-dependent]
if) glbp [group #] weighting [weight] (lower [#]) (upper [#]) !!! no upper = lower.
if) glbp [group #] weighting track [object #] (decrement [#]) !!! dec of 10 by default.
config) track [object #] interface [fx/x] (line-protocol | ip routing)

IPv4 Addressing
Check IP, mask, and default gateway on a PC with ipconfig. Make sure all IPs on a segment are within the
same IP subnet.
DHCP: Can also send TFTP, DNS, Internet Time Service (ITS), NetBIOS name/datagram servers, BootP, and
TACACS info.
Discover: Broadcast, sourced from 0.0.0.0 with the hosts MAC.
Offer: Server responds with an unleased IP, subnet mask, and def. gateway info.
Request: Broadcast, indicates the end host will use the address in the offer.
Acknowledge: Server responds that the IP is now leased and includes any additional DHCP options.
Decline: Sent from client to server to inform the server that the offered IP is already in use on the
network.
NAK: Server to client, informs client that the server declines to provide the client with the requested IP.
Pelirrojoo 12/14

10

Release: Client to server, informs server that the client has released its lease, allowing the server to
reassign the IP.
Inform: Client to server, requesting local config parameters such as a DNS server.
Because a Discover is broadcasted, it wont pass a router boundary. If the DHCP server is on a different
network, use an ip helper-address. Helpers send Time/TACACS/DNS/BOOTP/TFTP/NetBIOS by default,
change with (no) ip forward-protocol.
config) service dhcp !!! on by default, needed for relay/server functions.
if) ip helper-address [ip] !!! relay. configure on interface receiving discover messages. svi on a switch. multiple commands for
multiple servers, will send to all.
if) ip add dhcp !!! to have a router/l3 switch interface acquire an ip from a dhcp server.
config) ip dhcp excluded-address [start] (end) !!! exclude adds from pool. router wont hand out own adds.
config) ip dhcp pool [name]
dhcp) network [ip] [/## | subnet mask] !!! subnet must match that of interface.
dhcp) default-router [ip] (ip2) (ip3)... !!! should match the interface.
dhcp) lease ( infinite | [days] (hours) (minutes) ) !!! default = 1 day = 86400 secs.
dhcp) option [option number] [value] !!! 43 = lwap; 69 = smtp; 70 = pop3; 150 = voip tftp.

Router Not Forwarding Broadcasts: Must configure as relay if client and server are on different
subnets. sh ip helper-address.
DHCP Pool Out of Addresses: When exhausted, new requests are rejected. sh ip dhcp pool.
Misconfig: Range or excluded addresses may be incorrect. sh ip dhcp pool.
Duplicate IPs: Server may hand out an IP that is already statically assigned to another host. Confirm
excluded addresses.
Redundant Servers Not Communicating: If multiple servers are present, they need to communicate
with one another or else they may hand out duplicate addresses.
DHCP Pulls: Only clients can make requests, servers cant initiate a change/push information.
Int Not Using an IP in the DHCP Pool: Device must have an interface with an IP that is part of the pool
that it is handing out IPs for. Doesnt apply to helper addresses.
sh ip dhcp binding !!! shows mac <> ip binding.
sh ip dhcp conflict !!! shows issues such as duplicate addresses. clear with clear ip dhcp conflicts *.
clear ip dhcp binding [ * | (ip) ] !!! * for all, (ip) for individual.
debug ip dhcp server (events|packets) !!! (events) for updates to db. (pkts) for dora and release messages.

NAT: In/Outside refers to which host. Local/Global refers to sides of the NAT boundary (perspective).
Inside Local: The address of the inside host as seen from the inside.
Inside Global: The address of the inside host as seen from the outside.
Outside Global: The address of the outside host as seen from the outside.
Outside Local: The address of the outside host as seen from the inside.
Outside Local and Outside Global usually match.
Interfaces Not Configured Correctly: Correctly identify inside and outside interfaces.
if) ip nat [ inside | outside ]

Pool Misconfigured: Must correctly identify public addresses being translated to (Inside Global). If no
pool, interface.
config) ip nat pool [pool name] [ip start] [ip end] netmask [mask] !!! create pool.

Public Add in the Pool Not Reachable: For return traffic, the public addresses (Inside Global) must be
reachable from the Internet.
ACL Not Referencing Correct Inside Addresses: ACL needs to correctly identify the Inside Local
addresses that will be translated.
ACL/Pool Not Mapped Correctly: ip nat inside source links the ACL and pool/interface. If incorrect, NAT
wont translate correctly.
Overload Missing: Without the overload keyword, PAT wont be enabled.
config) ip nat inside source list [acl] [pool (name)|interface (fx/x)] (overload)

Pelirrojoo 12/14

11

VPNs: Some VPN protocols verify the checksum of a packet, which is calculated before NAT, and may
reject the packets because they appear to have been altered.
Hides True IP: Tracing a data flow from end-to-end may be challenging. Use sh ip nat translations.
Some Applications Incompatible: Some apps randomly determine which ports will be used, which may
not be compatible; VoIP protocols face this issue since they randomly select UDP port numbers to be
used for RTP media streams. Other apps include the IP in the payload of a packet and the remote
device may attempt to return traffic to the embedded IP, which is unreachable.
NAT Delays: Because this is an L3 manipulation (punted to CPU), packets experience more delay than
they normally would.
sh ip nat translations !!! shows inside/outside local/global addresses.
clear ip nat translations [ * | (inside | outside) | (tcp | udp) ]
sh ip nat statistics !!! shows inside/outside interfaces and number of static/dynamic translations.
debug ip nat (detailed) !!! use with caution.

IPv6 Addressing
In a /64 address, the first 64 bits is the subnet prefix. The last 64 bits (probably after a ::) represent the
interface/host ID. The IPv6 add of a PC can be seen with ipconfig; if an address contains a %
afterwards, that is the interface identifier (used because there may be multiple interfaces on the same
device with the same link-local address assigned to them).
config) ipv6 unicast routing !!! to enable ipv6 on a router.

Neighbor Discovery Protocol (NDP): If hosts are in different subnets they will need to communicate
through the def. gateway using its L2 MAC address. IPv4 uses ARP to resolve MACs, but since broadcasts
dont exist in IPv6, NDP is used instead. NDP uses multicasts; it will only send to devices listening to the
NDP multicast group address (default gateways).
Neighbor Solicitation (NS): Messages are sourced from a hosts own IPv6 address and MAC. The
destination IPv6 address and MAC are the solicited node multicast addresses. The destination IP
is FF02::1:FFxx:xxxx, and MAC is 33:33:FF:xx:xx:xx; where the xs in both represent the last 24 bits (6
hex characters) of the destinations IPv6 address. All devices will create their own solicited node
multicast groups for both their link-local and global unicast addresses. sh ipv6 int [fx/x] will show the
devices multicast groups, global unicast addresses, and link-local addresses.
Neighbor Advertisement (NA): When a device receives an NS, it will reply with an NA, which is a
unicast. Contains the source MAC of the device that received the NS.
sh ipv6 interface !!! verify multicast groups a router is listening to.

EUI-64: IPv6 addresses consist of 2 parts, the subnet ID and the host ID. To get around having to manually
create host IDs, the hosts can convert their 48 bit MAC into the 64 bits needed for the host ID. First, FFFE
is inserted into the middle, then the 7th bit from the left is flipped. Since each hex character is 4 bits, this
would affect the character second from the left. Convert it to binary, then flip the bit in the 2 position. Ex:
0800 8 1000 1010 10 a 0a00. By default, Windows PCs randomly generate their IPv6
addresses, but that can be changed. On a router, you can tell an interface to use EUI-64 formatting with
the command:
if) ipv6 add [ipv6 subnet]/[mask] eui-64

Stateless Address Autoconfiguration (SLAAC): Allows devices to configure their own IPv6 address,
prefix, and default gateway, without a DHCPv6 server. Devices send Router Solicitation (RS) messages
(to FF02::2) to determine if there are any routers connected to the local segment. They await Router
Advertisements (RA) which identify the prefix (must be /64) used by the router (default gateway) for the
segment theyre on. Routers will use EUI-64 for their interface ID while a PC will randomly generate one
(unless configured for EUI-64). The link-local address of the RA device is used as the default gateway. A
router must be configured with ipv6 unicast routing to send RAs. If the routers interface is configured
with ipv6 address autoconfig, it will not send RAs.
if) ipv6 address autoconfig !!! to tell a device to use slaac to determine its address.
if) ipv6 nd ra suppress all !!! this suppresses ras on a router, which will cause hosts to not use slaac.
sh ipv6 interface [fx/x] !!! check ipv6 is enabled, subnet is /64, nd ras are suppressed isnt present.
sh run | in ipv6 unicast routing !!! check if ipv6 is enabled.

Pelirrojoo 12/14

12

Stateful DHCPv6: Although a device can determine its own address/prefix/DG with SLAAC, you may want
to use DHCP instead to hand out addresses as well as additional info such as NTP, domain, DNS, TFTP
server, etc. Can be created on a router or an MLS.
if) ipv6 dhcp server [pool name] !!! assign an interface to a pool.
config) ipv6 dhcp pool [pool name] !!! create the pool.
dhcp) address prefix [ipv6 add/mask] !!! assign a prefix to hand out.
dhcp) dns-server [#] / domain-name [x.com] !!! assign options like in v4.
sh ipv6 dhcp binding !!! shows addresses used by clients.
sh ipv6 dhcp interface !!! local dhcp pool info per interface.
sh ipv6 dhcp pool !!! pool name, prefix, clients, and options.

Stateless DHCPv6: Combination of SLAAC and DHCPv6. SLAAC is used for clients to determine their own
address, prefix, and DG, but RAs also include a flag to tell clients to get additional info from a DHCPv6
server. Create the DHCPv6 server with necessary options as above (address prefix omitted) and enable
the flag with the command below.
if) ipv6 nd other-config-flag !!! in addition to dns server, domain name, etc.
sh ipv6 int [fx/x] !!! at bottom, hosts use slaac for addresses, hosts use dhcp to obtain other config.

DHCPv6: First four functions are similar to DORA:

SOLICIT: Client sends multicast from Link-Local address to FF02::1:2 (DHCPv6 all servers address).
ADVERTISE: Server responds to above with an advertise message, offering an address to the client.
Unicast LL to LL.
REQUEST: Client sends request to server (LL to FF02::1:2), confirming the address and any other
parameters.
REPLY: Server finalizes process. LL to LL.
CONFIRM: Client to server, to confirm if address is still appropriate.
RENEW: Client to server, extends lifetime of address assigned. If no response from server, a REBIND
is sent.
RELEASE: Client to server, informing address no longer needed.
DECLINE: Client to server, to inform address is already in use.
RECONFIGURE: Server to client, when server has new/updated information.
INFORMATION-REQUEST: Client to server, when client needs additional config without a new IP.
RELAY-FORW/RELAY-REPL: Messages between a relay agent and a server.
DHCPv6 Relay Agent: A SOLICIT message is a link-local multicast (starts with FF02). To get off the local
link, relay forwards the SOLICIT as a unicast to a DHCPv6 server.
if) ipv6 dhcp relay destination [ipv6 add]

ACLs and Prefix Lists

IPv4 ACLs: Identify traffic based on criteria such as source/dest IP, source/dest port numbers, transport
layer protocols, QoS markings, etc. Can also be used to identify IP addresses for NAT/PAT, redistribution,
PBR, etc. Use top down processing, execute immediately upon a match (rules below arent considered),
and have an implicit deny at the end. Place standard ACLs near the destination and extended ACLs
near the source.
config) ip access-list [standard|extended] [#|name] !!! to create either.
ext-nacl) (no) (seq #) [statement] (log) !!! use sequence numbers to modify acls.
config) access-list [#] !!! to create a standard acl.
if) ip access-group [#|name] [in|out] !!! to use an acl for interface filtering. [in|out] is significant.
line) access-list [#] [in|out] !!! for lines.
sh access-lists (#) !!! to see contents and counters.
sh ip int [fx/x] !!! look for outgoing/inbound access list is [x].

Time Based ACLs: Time range is based on values configured in a time-range command. Look for active
in sh access-list.
ext-nacl) [permit|deny] [ip|tcp|udp] [ip] [ip] time-range [name] !!! to apply to an acl.
config) time-range [name]
time-range) periodic [(day)|daily|weekdays|weekend] [day] [start-time] [end-time]

Pelirrojoo 12/14

13

sh time-range [name] !!! look for active and used in [acl name].
sh clock !!! make sure clock is correct and/or using ntp.

IPv6 ACLs: Processing is the same as IPv4, only addition is the implicit permit for NDP (NAs and NDs:
permit icmp any any nd-ns), placed just before the implicit deny. All manually entered commands will
be placed before this. If a manual deny ipv6 any any (log) is placed for logging, it will break NDP. There is
no standard/extended ACL difference like with IPv4; within the ACL entry you provide as little or as much
info as you need. There are no wildcard masks, instead use CIDR / notation. A /128 is equivalent to an
all 0s wildcard mask, while a /0 is equivalent to an all 255s wildcard mask. The number indicates the
number of bits that must match, from the left side.
config) ipv6 access-list [name] !!! no # standard/extended difference like ipv4.
ipv6-acl) (seq #) [permit|deny] [port|ipv6add/mask|protocol] (log)
if) ipv6 traffic-filter [name] [in|out]
sh ipv6 access-list [name]
sh ipv6 interface (fx/x) !!! look for input features: access list and inbound access list [name].

Prefix Lists: ACLs lack the ability to identify routes based on a subnet mask, this is
useful for matching routes for route filtering. Prefix lists allow you to define both
the route and the prefix that youd like to match. They perform the same for
IPv4/6. If there isnt a ge/ le, the prefix/mask is treated as an address and
subnet mask, matched exactly. If there is a ge/ le, the prefix/mask are treated
as an address and wildcard mask; the prefix/mask indicates a range, while the
ge/ le refers to the size of the subnet mask. Both ge and le can be used at
the same time. 0.0.0.0/0 is the default route. Processed the same as an ACL; top
down, immediate execution, and an implicit deny at the end (if denying specific
routes, include permit 0.0.0.0/0 le 32).

Source
Connected
Static
eBGP
EIGRP
(internal)
OSPF
RIP
EIGRP
(external)
iBGP

AD
0
1
20
90
11
0
12
0
17
0
20
0

config) ip prefix-list [name] (seq [#]) [ip]/[mask] (ge|le [mask])

sh ip prefix-list
sh ip protocols !!! look for incoming/outgoing update filter list for all interfaces is (prefix-list) [x].

Basic Routing and GRE Tunnels

Packet Forwarding: Determine where the destination IP resides; if on a remote subnet, send packets to
the default gateway. To construct the L2 frame, you need the MAC of the destination (def gateway). If the
MAC is not in the ARP cache (L3 L2 mapping table), use ARP to resolve it. Once in the cache, packets
will be sent in frames addressed to the default gateways MAC.
When the frames are received by the router, the destination MAC is torn off the L2 header. The router
inspects the L3 header, decrements the TTL (if 0, discarded and time-exceeded ICMP message is sent),
and checks the routing table for the best path to the IP address. The router adds a new L2 header and
sends it on to the next-hop.
Once the frames are received at the destination router, the headers are removed again and the TTL is
decremented again. The IP header is inspected to determine the destination network. If directly attached,
an ARP request is sent to determine the MAC address of the destination IP. The frame is then sent out the
correct interface attached to the destination network.
IP Routing Table: Used in routers, route selected is the one with the longest prefix (best match), then
lowest AD.
Routing Table Data Structure: As a router receives route information from a neighboring router, the info
is stored in the data structures of the IP routing protocol and analyzed by the routing protocol to
determine the best path, based on metrics. The routing table can be populated by the routing protocol
data structure, directly connected routes, and static routes. An IP routing protocols data structure itself
can also be populated by the local router; route redistribution (info is redistributed from the routing table
into the IP routing protocols data structure) as well as by interfaces enabled for the routing protocol and
the protocol itself.
Routing Information Sources: Routers can receive route information from multiple sources at the same
time. If the same network is received by different routing sources, administrative distance (AD) is used to
choose which is most believable. The lower the AD, the more preferred the source of information. The
Pelirrojoo 12/14

14

best route selected by a routing protocols data structure is only a candidate to be injected into the
routers IP routing table. The route is injected into the routing table if the router concludes that it came
from the best routing source. Suboptimal routing may occur due to a different routing source with a lower
AD being used. To ensure route information is never used, change the AD for a source to 255.
sh ip route [ip] [mask] longer-prefixes !!! shows info for subnets within a network.
sh ip route [ip] [mask] !!! shows information for entire subnet.
sh ip route [ip] !!! shows next-hop ip to reach an [ip], interface, routing protocol, metric, etc.

Floating Static Route: A static route with an AD higher than the preferred route; used as a backup in
case the preferred route fails. The preferred route is installed in the routing table, the static will only be
installed if the preferred route is withdrawn. Simply add the (AD) to the end of the ip route command.
config) ip route [ip] [mask] [(next-hop ip) | (exit interface)] (ad)
sh ip route [ip] !!! ad will show as distance [x].
sh ip route static !!! filters routing table to show statics. look for s at beginning. next-hop, ad, metric.

Static routes can either use a next-hop IP or an exit interface. The exit interface should only be used when
the link is pure point-to-point, such as DSL or Serial. Point-to-point Ethernet is not really p2p because
Ethernet is multi-access; it requires a source and destination MAC. If an Ethernet interface is configured
as the next-hop instead of an IP, the router will ARP for the MAC of every destination address, in every
packet, resulting in excessive processor and memory use (control plane is used during forwarding).
Proxy ARP: On by default on routers. Allows a router to respond to ARP requests with its own MAC if it has
a route in the routing table for the IP in the ARP request. In a sh ip arp you may see many IPs reachable
at the same MAC out the same interface. If Proxy ARP were not enabled, it would result in an
encapsulation failure (debugging packets would show). sh ip arp would display the addresses as
Incomplete.
IPv6 Static Routes: An exit interface is mandatory if using a link-local address because the same address
may be used on multiple router interfaces. If the next-hop is the link-local address of a neighboring
router out a specified interface, the router will check its IPv6 neighbor table for the MAC. If using a global
unicast address, since IPv6 does not use ARP, NDP is used to determine the MAC of the neighbor device.
Proxy ARP does not exist in IPv6, so the destination must be directly attached to the router if only an
interface is specified.
config) ipv6 route [ipv6 add/len] [fx/x] [link-local next-hop] (ad) !!! [link-local] needs [interface].
config) ipv6 route [ipv6 add/len] [(fx/x) (global unicast next-hop)] (ad) !!! use either or both int/ip.
sh ipv6 route static

Generic Routing Encapsulation (GRE): Protocol used to encapsulate various types of network layer
packets, inside a transport protocol, so that they can be transported over an IP network. You can create
virtual point-to-point links between remote routers across an IP network, making them appear directly
connected. The default tunnel mode for Cisco devices is GRE/IP (point-to-point). Allows routing
information to pass (since its multicast). Adds a GRE header (carrier protocol) to encapsulate the original
packet (passenger protocol), then adds a new IP header (transport protocol).
Make sure remote devices are reachable across the public network, tunnel IPs are in the same subnet, the
tunnel source/dest IPs match between routers, and the tunnel mode is correct; for IPv4/6 over an IPv4
network, GRE IP is required. Check for ACLs blocking IP protocol 47. The tunnel interface must be
added to a routing protocol for routes to be shared across the tunnel.
Fragmentation may happen due to an insufficient MTU. The GRE header is 24 bytes, which limits the
original packet to 1476 (1500 is the standard interface MTU). If packets > 1476 bytes are sent,
fragmentation occurs, resulting in processing delays and high CPU usage. Implement consistent MTU
from end-to-end. Verify MTU with sh int tun [#]. Change with interface command ip mtu [#].
The error %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing, indicates the
router is trying to route to the tunnel destination using the virtual tunnel interface instead of the physical
interface. May be due to flapping routing or a misconfiguration.
config) int tunnel [#]
if) ip add [tunnel ip] [mask]
if) tunnel source [(fx/x) | source ip of physical int]
if) tunnel dest [physical dest ip]

Pelirrojoo 12/14

15

if) tunnel mode [gre (ip) | ipip | ipsec | ipv6ip] !!! change mode, match on both ends. "gre ip is default.
sh interface tunnel [#]

IPsec: GREs main purpose is to provide simple tunneling for multiple network layer protocols. However, it
lacks security; it only provides basic plaintext authentication between remote devices using a tunnel key,
which is not valid when using GRE over an untrusted network (Internet). When doing so, confidentiality,
authentication, and data integrity can be accomplished with IPsec. Confidentiality can be provided with
symmetric algorithms, while authentication and integrity can be provided with hash message
authentication codes (HMACs). When using IPsec with GRE, GRE encapsulates the original packet payload
first, then encryption occurs with IPsec to protect the GRE packet. Supports other L3 protocols, provides
multicast and routing traffic across the VPN, and reduces management overhead in a hub-and-spoke
topology. Two different IPsec modes exist:
Tunnel Mode: Will encapsulate and encrypt the entire GRE packet, including the Transport Protocol
header. Because of this, IPsec includes a new IP header. Higher overhead.
Transport Mode: Will only encapsulate and encrypt the carrier protocol and the passenger protocol.
Transport Protocol header is reused, reducing overhead.

RIPv2 and RIPng

RIP does not establish neighbor adjacencies. Most issues are related to routing updates.
sh ip rip database !!! displays rip database; directly connected networks injected into rip, and learned networks from a neighbor
(ip), with hop count.
sh ip route rip !!! filters routing table to show only rip routes. [ad/hopcount] via neighbor (ip).
sh ip protocols !!! verify route filters, timers, redistribution, rip version sent/received, autosummarization, max paths, address in
network command, passive interfaces, who routes are learned from, and the ad.

Shut Down Interface: Use sh ip int brief to check if an interface is up/up.

Wrong Subnet: If routers exchanging updates are not in the same subnet, they will ignore the updates.
Both the IP and subnet mask assigned to an interface must be correct.
Bad/Missing Network Statement: RIP is enabled on an interface using the network command. The
actual network associated with the specified interface is injected into the RIP process and advertised to
directly connected routers out RIP-enabled interfaces. Verify enabled interfaces with sh ip protocols, sh
run | s rip, and sh ip int bri.
Passive Interface: Reduces RIP traffic on a LAN and improves security. Disables the sending of RIP
updates out of an interface, eliminating RIP-related traffic. Improves security because the router is not
advertising RIP information out an interface that could be captured. However, the interface will still
receive updates and use them; a rogue router/routes may be introduced. When an interface is
passive, the network/subnet associated with the interface is still injected into the RIP routing process and
advertised to other RIP routers. Can be made default in router mode with passive-interface default, and
individual interfaces can be changed with (no) passive-interface [fx/x].
Wrong Version: RIPv1 is enabled by default, to enable RIPv2, issue the router command version 2. If
versions dont match between directly connected routers, they will not share routing information. sh ip
protocols will display the version sent/received per interface. Version numbers can be changed per
interface via the commands ip rip send version [x] and ip rip receive version [y]. debug ip rip will display
the output RIP: ignored v2 packet from [IP] (illegal version).
Max Hop Count: RIP has a max hop count of 15; routes with a count 16 are considered unreachable.
The topology may be too large, the seed metric from redistribution may be set too high, or an offset list
may be manipulating the metric. An offset list can be verified via sh ip protocols, look for incoming
routes in [fx/x] will have [x] added to the metric if on list [y]. It is a router command with a syntax of
offset-list [ACL#] (in/out) [#] (interface).
Autosummarization: RIP autosummarizes automatically when sending updates that are part of a
different classful network than the route being advertised. This is an issue if networks are discontiguous.
Sent updates can be seen with debug ip rip. You will usually need to disable, use no auto-summary. To
verify if auto-summary is enabled, use sh ip protocols.
Authentication: When authentication is configured on an interface, it will only accept updates that pass
authentication. If misconfigured, debug ip rip will display RIP: ignored v2 packet from [IP] (invalid
authentication). Issue may be due to a key chain configuration/association, or the authentication mode.
sh key chain can be used to verify the key string. They key ID AND the key strings have to match
Pelirrojoo 12/14

16

between routers, however, the name does not have to match. By default, keys never expire, however
lifetimes can be added to modify when keys will be used; rotating multiple keys enhances security. Key
chains are assigned to an interface via ip rip authentication key-chain [key chain name] and mode is
specified with ip rip authentication mode [text|md5]. sh ip protocols allows you to verify the key being
used, but sh run int [fx/x] is needed to verify the mode.
Route Filtering: A distribute list can be applied to the RIP process, either inbound or outbound, to control
which routes are advertised to neighbors or which routes are received from neighbors. Routes
sent/received are controlled by ACLs, prefix lists, or route maps. Ensure the distribute list is placed in the
correct direction and on the correct interface. If using an ACL/prefix list/route map, check them as well.
sh ip protocols will display something similar to [fx/x] filtered by (prefix-list) [name] (per-user), default is
not set.
Split Horizon: Rule stating that any routes learned inbound on an interface will not be advertised back
out the same interface; to prevent routing loops. sh ip interface will display if enabled, it is by default.
Becomes an issue in multi-access hub-and-spoke topologies such as Frame Relay. Disable on the hub
routers multi-access interface with the no ip split-horizon interface command, or use point-to-point
subinterfaces.
Better Source of Info: Because the routing table trusts sources with lower ADs, RIP routes may not win.
RIPs AD is 120 by default. If a neighbor router knows of a route via a better (lower AD i.e. static route)
method, it may not pass the route on.
ACLs: RIP uses the destination UDP port 520 as well as the destination multicast address 224.0.0.9. If
there is an ACL filtering traffic that is not permitting that port, RIP updates will be denied. Either add
permit ip any any at the end of the ACL, or add permit udp any any eq 520 to the ACL.
Load Balancing: RIP will load balance on 4 equal cost paths by default. Verify the number with sh ip
protocols. Change with router command maximum-paths [x], max of 16.
Missing Default Route: RIP routers need to know what to do with packets that they do not have a
specific match for, thats what a default route does. Theyre typically configured on an edge device with
a next-hop address of the ISPs router. A default route needs to be injected into RIP so that it can be
advertised to other RIP routers. To do this, use the command default-information originate on the edge
device. With RIP, you do not need a static default route configured to generate a default route back to
the edge device, it may come from another routing protocol. However, if there is no known default
gateway on the edge device, it will drop the packets. Verify configuration on the edge router with sh run |
s router rip and look for the originate command. Can also be seen in sh ip rip database.
Route Summarization: Manual route summarization is enabled on a per-interface basis with the
command ip summary-address rip [ip] [mask]. Make sure you use the correct interface, specify RIP, and
use the correct summary route. Verify with sh ip protocols. A route to Null0 is not automatically
created; if a default route is also configured, a routing loop may occur if a match is not found in the
routing table. To fix, either create a static route to Null0 for the summary route or create a more
specific summary route.
RIPng (Next Generation): Designed for IPv6; it functions the same as RIPv2. Enhancements include an
all-RIP-devices multicast group of FF02::9, a named process, the removal of the network command
(replaced with an interface command), and the use of link-local addresses as the next-hop IPv6
addresses. Verify that ipv6 unicast routing is enabled! Permit UDP 521 in ACLs.
config) ipv6 router rip [name] !!! to enable ripng.
router) maximum-paths [#] !!! default of 16 equal metric paths for ripng.
router) distribute-list [#] [in/out]
if) ipv6 rip [name] enable !!! to enable an interface.
if) ipv6 rip [name] default-information originate !!! interface command. requires static default ipv6 route.
sh ipv6 rip database !!! the local database, installed indicates routes in the routing table.
sh ipv6 route rip !!! verify ripng routes installed in routing table. next-hop is a link-local address.
sh ipv6 protocols !!! not as much info as v4. only shows interfaces enabled for ripng and redistribution.
sh ipv6 rip [name] !!! timers, max paths, port number, multicast group, interfaces, default route.
sh ipv6 rip next-hops !!! verify the number of routes a router is learning from a connected ripng router.
debug ipv6 rip !!! see updates being sent out an interface for a process, link-local source, multicast destination, and included

Pelirrojoo 12/14

17

routes.
traceroute ipv6 [add]

Default route is enabled per-interface with ipv6 rip [name] default-information [originate|only]. Originate
will send a default route as well as the other routes. Only will send only a default route and suppress
the other routes. sh ipv6 rip [name] will show if a default route is being sent, but only a sh run | s rip
will show what type of default route, and what interfaces.
To verify if there are ACLs denying packets in an interface, you can use debug ipv6 packets. Alternatively,
sh run | in interface|traffic will show any interface that has the interface command ipv6 traffic-filter
[ACL] [in/out]. Then issue sh ipv6 access-list [name] to view the ACL rules. UDP port 521 needs to be
permitted with permit udp any any eq 521.

EIGRP
Establishes neighborships by sending hello packets to the multicast address 224.0.0.10 out interfaces
participating in the EIGRP process. After establishing a neighborship, the router performs a full exchange
of routing information with the newly established neighbor. After the full exchange, only updates to route
information are exchanged with that neighbor. Routing information learned from EIGRP neighbors is
inserted into the EIGRP topology table. If the EIGRP information for a specific route happens to be the
best source of information, it is installed in the routing table.
router) network [ip] [mask] !!! to select the router interfaces to run eigrp on.
sh ip eigrp int !!! verify participating interfaces. passive interfaces will not show!
sh ip eigrp events !!! shows event log.
sh ip eigrp topology (all-links) !!! see known routes. (all-links) will show non feasible successors.
sh ip eigrp neighbors !!! codes below.
H

handle, 1 per neighbor, starting with 0.

SRTT

smooth (avg) round trip time.

Address

ipv4 add of neighbor int sending hello.

RTO

retransmit time out (6x srtt).

Interface

local int use to reach neighbor.

the number of eigrp packets in queue.

Hold

nbr valid timer. reach 0 w/o hello = dead.

Seq Numkeeps track of eigrp packets rcvd from nbr.

Uptime

how long routers have been neighbors.

Pelirrojoo 12/14

18

Missing Neighbors:
Interface Down: Ensure interface is up/up with sh ip int brief.
Mismatched AS: Both routers must be in same AS for a neighborship to form. Specified in the router eigrp
[AS] command. Most commands show AS, including sh ip protocols. You can also use debug eigrp
packet which will show the local router sending hellos but not receiving any.
Different Subnets: Router interfaces must be in the same subnet. If not, and syslog is set at severity 6,
you will receive the message %DUAL-6-NBRINFO: EIGRP-IPv4 [AS]: Neighbor [IP] [fx/x] is blocked: not
on common subnet [IP].
Incorrect Network Statement: If the network statement is misconfigured, EIGRP may not be enabled on
the proper interfaces. These statements use wildcard masks. Use sh ip eigrp int to verify which
interfaces are participating. Look for the number of Peers as well as Pending routes. 0 is expected,
any other value indicates there is an issue preventing the interface from sending the necessary
updates to the neighbor. sh ip protocols will show interfaces participating under Routing for networks.
These are not the networks, just the network statements! sh run | s router eigrp will show the actual
network statements. debug eigrp packet will show hello packets exiting the incorrect interface.
Mismatched K Values: K values must match between neighbors to form an adjacency. show ip protocols
will show values. If they are changed, make them match on every router in the AS. If logging messages
at level 5, a message will display %DUAL-5-NBRCHANGE: EIGRP-IPv4 [AS]: Neighbor [IP] [fx/x] is down:
K-value mismatch. Change with metric weights [k1][k2][k3][k4][k5].
Passive Interface: Reduces traffic and increases security. Turns off sending and receiving EIGRP packets
on an interface while still injecting the interfaces network into EIGRP and advertising it to neighbors.
Prevents rogue routers from forming an adjacency. If configured on the wrong interface, will prevent
legitimate relationships. Use sh ip protocols to see if enabled (If none, the section does not appear). If
using debug eigrp packet you will notice that hellos are not being sent out the expected interface.
Timers: While EIGRP timers do not have to match, if they are off by enough, the adjacency will flap. Each
router must send hello packets at a rate that is lower than the hold timer. Verify timers with sh ip eigrp
interfaces detail.
ACLs: If there is an ACL applied to an interface and the ACL is denying EIGRP packets, a neighborship will
not form. Use sh ip int [fx/x] to see if there is an in/outbound ACL, fix with permit eigrp any any.
Protocol 88.
Authentication: Interface based. Both routers must agree on the settings for a neighborship to form.
Spot-the-difference when looking at sh run int [fx/x] or sh ip eigrp int detail [fx/x]. To see the actual key
in a key-chain, use sh key chain. Keys may have a valid time before they expire (check clock). Debug
eigrp packets will display missing if neighbor doesnt have authentication configured and invalid if
the neighbors key ID or string dont match.
if) ip authentication mode eigrp [as] md5
if) ip authentication key-chain eigrp [as] [key-chain-name]

Missing Routes:
Int Shut Down: Interface must be up/up for routes to be advertised or neighborships to form.
Missing Network Command: Even interfaces not forming neighborships need an applicable network
statement to enable EIGRP to inject the networks on those interfaces into the process and advertise
them out. In sh ip protocols the Routing for networks segment identifies the network
statements/interfaces, not the networks that are actually advertised. sh ip eigrp interfaces will identify
interfaces participating.
Default Route: Either use redistribute static (metric), setting a (metric) or set default-metric [k1][k2][k3]
[k4][k5]). If referring a network thats not 0.0.0.0, set with ip default-network. Or, send a summary
address with the interface command ip summary-address eigrp [AS] 0.0.0.0 0.0.0.0.
Better Source of Info: EIGRP has an AD of 90 for internally learned routes and 170 for external routes. If
there is a route from another source with a better AD, it is preferred. May cause suboptimal routing
because another routing protocol may have a lower AD, but longer/slower path. sh ip eigrp topology
(all-links) will identify all known EIGRP routes, while sh ip route eigrp will display only EIGRP routes
inserted into the routing table. sh ip route [ip] [mask] will identify the routing source being used.

Discontiguous Networks/Autosummarization: EIGRP supports VLSM; in older versions of IOS,

autosummarization was enabled by default and no auto-summary had to be used. In 15.0 and newer, it
is disabled by default. Verify with sh ip protocols.
Route Filtering: Distribute lists applied to EIGRP control which routes are advertised to, or received from,
neighbors. Check that the distribute list is applied to the correct interface and in the correct direction.
Check the ACL, prefix list, or route map. sh ip protocols will identify if there is a distribute list applied to
all of EIGRP, or to individual interfaces.
Split-Horizon: Any routes learned inbound on an interface will not be advertised out the same interface.
Designed to prevent routing loops. Becomes an issue in NBMA hub-and-spoke topologies as well as
DMVPNs, which both use multipoint interfaces on the hub router. Verify if enabled with sh ip int [fx/x].
Disable per interface with no ip split-horizon or specifically for EIGRP with no ip split-horizon eigrp [AS
#]. If the latter command is used, it will still show as enabled in sh ip int, need to verify with sh ip eigrp
int det [fx/x].
Feasible Successors: The best route for a specific network in the EIGRP topology table becomes a
candidate to be injected into the routers routing table. The best route is the one with the lowest
feasible distance (FD). If that candidate route has the best AD for the network and thus is injected into
the routing table, it becomes known as the successor route. sh ip eigrp topology will show the topology
table, including redistributed and local networks participating in EIGRP. This will only display successors
and feasible successors; to verify the FD/RD of other paths that arent feasible successors, add all-links
to the end of the command. After each next-hop IP is the (feasible distance/reported distance). The
reported (advertised) distance (RD) is the distance from the neighbor at the next-hop address to the
destination network. The feasible distance (FD) is the RD plus the metric to reach the neighbor at
the next-hop IP. EIGRP precalculates paths that could be used if the successor failed, known as feasible
successors. To be a feasible successor, the RD of the path must be less than the FD of the successor.
Load Balancing: By default, EIGRP will load balance across 4 equal metric paths. This can be changed
with the maximum-paths [#] command. EIGRP can also load balance across unequal paths; this is not
enabled by default, its changed with the variance [#] command, which is by default set to 1. The
number acts as a multiplier to the successors metric (FD). This will allow routes from a neighbor with a
FD below the resulting value (successors FD * variance) to be installed in the routing table. Even with
the variance command, you are limited by the maximum-paths setting. Feasibility is also important; if
alternate paths are not feasible successors (RD<FD of successor), they will not be considered. Verify
with sh ip protocols. clear ip route * to take effect.
Passive Routes: If the successor route is removed and no feasible successors exist, a router will send
query messages to find alternate routes. The route will change from passive to active while the query
process is ongoing. If another router has a route, it will reply, if not, it will send queries to each of its
neighbors and wait for replies before it will reply to the original router. All query messages must be
replied to before a new route is calculated on the original router. If all queries are not replied to, the
route is considered Stuck in Active. IOS can limit the time spent waiting with the router command
timers active-time [#] (in minutes). Avoid the SIA situation by making sure there are feasible
successors for each route. Otherwise, use stubs or summarization to limit the query scope. Older
versions of IOS brought down neighbors. Newer IOS versions send SIA Query messages halfway
through the active time; if the message is replied to, the neighbor will be kept up, but if no reply is
received, the neighbor will be brought down. SIA reasons: too busy, query packet lost, unidirectional
link, or not enough memory. The command eigrp log-neighbor-changes will send a syslog message
when SIA.
Stub: Used to control the scope of queries, which may be a waste of resources should a remote router
have no other exit points. Useful with hub-and-spoke WAN links to reduce traffic and also reduce
chances of a stuck-in-active situation. Configure the actual stub router (not hub) with eigrp stub. You
can control the routes the stub will advertise to its neighbor. By default, its connected and summary
routes; other options are redistributed, static, a combination, or receive-only (no routes). Verify on stub
with sh ip protocols, verify on neighbor with sh ip eigrp neighbors detail. To limit the size of the routing
table, you must create a default route on the stub, or send a summary address on the hub with the
interface command ip summary-address eigrp [AS] [IP] [WC mask], as well as filter out any unwanted
routes, unlike OSPF which does this automatically.

Route Summarization: Automatic summarization is not suggested, manual is. With EIGRP, this is enabled
per interface with the command ip summary-address eigrp [AS] [IP] [Mask]. Make sure that it is enabled
on the correct interface, with the correct AS, using the correct summary route. Verify with sh ip
protocols. Limits the scope of query messages; if a query received for a network matches a summary
route (not an exact match), the router will reply to the query with a no and not send out its own query
messages. When a summary route is created on a router, so is a summary route to Null0, in order to
prevent routing loops. This ensures that if a packet is received by the router destined to a network that
falls within the summary route, but the router does not actually know how to reach it, the packet will be
dropped (instead of sent back out the default route, causing a loop). The route to Null0 has an AD of
5, making it more trustworthy than most other sources of routing info.
IPv6: EIGRP for IPv6 can be configured and verified very similarly to normal EIGRP:
config) ipv6 router eigrp [as]
router) router-id [x.x.x.x] !!! if no ipv4 addresses exist on device for eigrp to use.
router) no shutdown !!! must enable!
if) ipv6 eigrp [as] !!! to enable on an interface.
sh ipv6 interface (brief | detail) !!! (brief) to verify interface is up/up. (detail) for authentication.
sh ipv6 route !!! to ensure there isnt a better source of information.
sh ipv6 protocols !!! to verify as numbers, k-values, stub, and participating/passive interfaces.
sh ipv6 eigrp interfaces (detail) !!! verify if an interface is participating, timers, and split-horizon.
sh ipv6 eigrp neighbors (detail) !!! will verify neighbors by their link-local addresses. (detail) for stub.
debug ipv6 [ eigrp | neighbor {ip} (notification) | summary]

EIGRP for IPv6 uses the multicast address FF02::A to form neighbor adjacencies, ensure that it is not
blocked by an ACL.
sh run | s ipv6 router eigrp !!! check for a distribute-list [acl | prefix-list | route-map].

Named EIGRP: The purpose is to provide you with a central location on the router to perform all EIGRP for
IPv4/6 configurations. Configurations include both an IPv4 unicast address family as well as a v6 address
family, using the same or different autonomous systems. Started with a named router eigrp command,
then select an AF to add commands to.
config) router eigrp [name] !!! start the process with a name instead of as.
router) address-family [ipv4|ipv6] unicast (vrf) autonomous-system [as] !!! enter the v4 or v6 af.
router-af) exit-address-family !!! to exit the af.

Inside the AF, you can add typical commands:

router-af) network [ip] / eigrp router-id [rid] / metric [#]

Use af-interface default to control all interfaces, or specify an interface to control just one.
router-af) af-interface default !!! change interface defaults.
router-af) af-interface [fx/x] !!! change individual interfaces.
router-af-interface) passive-interface / authentication / summary-address
router-af-interface) exit-af-interface

Use the topology base for operations that affect the topology table such as redistribution, distance, offset
lists, variance, etc:
router-af) topology base !!! enter the mode.
router-af-topology) variance [#] / no auto-summary / distance [#]
router-af-topology) exit-af-topology
sh eigrp protocols !!! displays both the v4 and v6 address families. as #, k-values, router id, stub, ad, max paths, variance.
missing interfaces participating/passive, use sh ip protocols to see them.
sh eigrp address-family [ipv4|ipv6] interfaces !!! to verify interfaces participating, but not passive.
sh eigrp address-family [ipv4|ipv6] interfaces detail !!! timers, split-horizon, authentication, stats.
sh eigrp address-family [ipv4|ipv6] neighbors (detail) !!! neighbors. (detail) shows stubs.
sh eigrp address-family [ipv4|ipv6] topology !!! topology table.

OSPF
Link-State protocol. Establishes neighborships by sending hellos out participating interfaces. Routers
receive LSAs from every router within the same area, learning about routes directly from the source
within the same area. Every router in an area must have the exact same LSDB for that area. LSDBs are
exchanged in full, then only updates are sent. Summary LSAs are sent every 30 mins.
if) ip ospf [#] area [#] !!! interface command to enable.
router) network [ip] [mask] area [#] !!! router command to match interfaces.
router) auto-cost reference-bandwidth [#] !!! for links faster than fastetherenet, increase!
sh ip ospf neighbor !!! to see neighbors (rid), priority, state, dead time, address, and interface.
sh ip ospf border routers !!! rid, via, interface, abr/asbr, area.
%ospf-5-adjchg: process 1, nbr [ip] or [fx/x] from loading to full, loading done.

Adjacency Transition States:

Down: No hellos received from a neighbor.
Attempt: Router sent a unicast hello to a configured neighbor and has not received a return hello yet.
Init: The router that has received a hello did not see its own RID in the received hello. Something is
preventing that router from receiving hello packets from the neighbor.
2Way: Two OSPF routers have received hellos from one another, and each saw its own RID in the hello
message. Acceptable state to be in among DROthers on an Ethernet LAN.
Exstart: Occurs when the routers forming a Full adjacency decide who will send their routing
information first. Router with the higher RID becomes the master, the other the slave. The master
sends info first. In a multi-access network, the DR/BDR have to be elected first before this state begins.
The DR does not have to be the master because each master/slave election is on a per-neighbor basis.
If a router remains in this state for a long period, there may be an MTU mismatch or duplicate RIDs.
Exchange: When two routers forming an adjacency send one another DBD packets. If a router remains
in this state for a long period, an MTU mismatch may exist.
Loading: Based on the missing LSDB entries identified in the Exchange state, each neighboring router
requests the other router to send over missing entries. If a router remains in this state for long, a
packet may be corrupted, there may be a memory issue, or an MTU mismatch.
Full: Neighboring routers have successfully exchanged their link-state info and an adjacency has been
formed.
LSA Types: RNSSA.
1 Router
2

3
4
5

All routers send these, but not sent out of the local area. List info about: directly connected
subnets; OSPF connection types of a router; and the known OSPF adjacencies of a router.
Network DR in a multi-access network sends these for the network if the network contains at least 2
routers, constrained to the local area. Contains a listing of routers connected to the
multi-access network.
Summary
Sourced by an ABR. Contains info about networks reachable in a other areas. Network
info is only exchanged between the backbone area and a non-backbone area.
Sum. ASBR Sourced by an ABR. Contains info stating how to reach an ASBR.
AS External Sourced by an ASBR. Contains info about networks external to the OSPF domain. Sent to
all OSPF areas except for stubs (they receive a default route from an ABR rather than
specific Type 5s).

7 NSSA

Sourced from an ASBR within an NSSA area, only exist within the NSSA area. Contain info
about external networks, just like Type 5s. External routes are sent/converted by the ABR
of the NSSA into the backbone as Type 5s. External routes known to other areas are not
sent into an NSSA since Type 5s are not permitted in an NSSA.

Route Summarization: OSPF is strict about where summarization can occur. Manual route summarization
is either enabled on a per-area basis (on an ABR to summarize routes as they enter or leave an area) or
on an ASBR (to summarize external routes being injected into an area). Verify that summarization is
being performed on the correct router, in the correct area, using an appropriate summary route. Verify
with sh ip ospf, and look for It is an area border router, and further down under the area section Area
ranges are. Interarea summaries are created on ABRs with the area [#] range [IP] [mask] router
command while external summaries are created on ASBRs with the summary-address [IP] [mask] router
command. When a summary route is created, so is a route to Null0, used to prevent routing loops by

dropping packets destine to networks not in the routing table (instead of sending them out the default
route). It is important to create accurate summary routes to ensure that your router is not advertising
networks within the summary address that it does not know how to reach. Verify with sh ip route | in Null.
While EIGRP gives the null route an AD of 5, OSPF gives it an AD of 110, which does not ensure that it is
more believable than most other sources. This may allow another route source to end up forwarding
traffic for routes included in the summary route to Null0.
Discontiguous Areas: A backbone area (0) must exist, with all other areas directly connected to it. If an
area is not physically adjacent to area 0, routes will not be successfully learned by all routers in the OSPF
domain. A virtual link can be used to logically connect the nonadjacent area to area 0. The area the
virtual link is created between is known as the transit area, because it will transmit LSAs from the
discontiguous area, to area 0, and vice versa. The transit area cannot be a stub. Virtual links are created
between the routers at the edge of the transit area, using their RIDs and the transit area number, using
the command area [x] virtual-link [RID]. Once the virtual link is established, the router connecting to the
discontiguous area becomes an ABR since it has a (virtual) interface in area 0. Verify with sh ip ospf
neighbor to see the new ABR; it will show with an OSPF_VL interface. Also, verify with sh ip ospf virtuallinks and confirm that the link is up and the state is Full. If area 0 is using authentication, the
authentication is appended to the virtual-link command with ...[authentication-key {key} | messagedigest-key {#} md5 {key}.
Load Balancing: OSPF only supports equal-cost load balancing. Consider the overall end-to-end cost and
the maximum number of paths permitted for load balancing. To verify the max paths, use sh ip protocols,
default is 4. Change with maximum-paths [#].
Default Route: With OSPF, a static route is injected into the routing process using the default-information
originate (always) command, not the redistribute static command. Use a sh run | s router ospf to confirm
the presence of the correct command.
Missing Neighbors: Process ID does not have to match. Verify adjacencies with sh ip ospf neighbor and sh
ip ospf int (fx/x).
Interface Down: Interface must be up/up for adjacency to form. sh ip int bri to confirm.
Interface Not Running OSPF: If the router network or interface ip ospf area commands are
misconfigured, OSPF may not be enabled on the proper interfaces or in the correct areas. Use sh ip
ospf int brief to confirm interfaces, area, IP/mask, state, and a count of Formed vs. Configured (F/C)
neighbors. sh ip protocols will also display configured interfaces under Routing for Networks: Note:
these are not the networks being advertised, only the statements used to match interfaces! If an
interface is configured with both types of commands, the interface ip ospf area command takes
precedence. Verify neighbor connectivity with sh cdp neighbors.
Mismatched Timers: OSPF timers have to match between neighbors. Defaults for broadcast and point-topoint networks are a hello of 10s and a dead of 40s, while NBMA/point-to-multipoint (broadcast and
nonbroadcast) networks have a hello of 30s and a dead of 120s. To verify, use sh ip ospf int [fx/x] or
debug ip ospf hello which will display the received (R) and configured (C) values. Change per interface
with ip ospf [hello|dead]-interval [#], if dead isnt set, its 4x hello. You may also change the interfaces
network type with ip ospf network [x].
Mismatched Network Types: Different network types have different default values. Non-broadcast
networks must have neighbors statically configured, DR/BDR elections are different, and timers are
different. To determine the network type associated with an interface, use sh ip ospf int [fx/x] and look
for Network Type and the timer values.
Mismatched Area Numbers: Neighboring interfaces must be in the same area. sh ip ospf int [fx/x] or sh
ip ospf int bri will display the area used for each interface. debug ip ospf adj will display OSPF-1ADJ
[fx/x]: Rcv pkt from [IP], area [area], mismatched area [area] in the header.
Mismatched Area Type: The default area type is normal. A normal area can be converted into a stub or
NSSA area to control the types of LSAs sent into the area from an ABR. For routers within an area to
form adjacencies, they must agree on the area type. Within the hello packet, there is a stub area flag,
which indicates the type of area the neighbor is in. Verify with sh ip protocols, which displays the
number and types of areas the router is in, but not which area is what type. If there are multiple areas
connected, verify with sh ip ospf to display the area type per area. debug ip ospf hello will display
OSPF-1 HELLO [fx/x]: Rcv hello from [IP] with mismatched Stub/Transit area option bit.

Different Subnets: To form a neighborship, both interfaces must be on the same subnet. sh run or sh ip
int bri.
Passive Interface: Reduces OSPF traffic and improves security. Disables sending/receiving of OSPF
packets on an interface while still injecting the interfaces network into OSPF and advertising it to OSPF
neighbors. Ensures that rogue devices that attach to the network will not be able to form an adjacency.
Verify with sh ip protocols. (no) passive-interface [default |fx/x]
MTU Mismatch: Each routers interface forming an adjacency must have the exact same MTU. If
mismatched, each router will see the other but get stuck in the Exstart/Exchange states. Verify
state with sh ip ospf neighbor, verify routes being exchanged with sh ip ospf int bri and look in the
F/C column, F should = C. Verify MTU with sh run int [fx/x]. Either change the MTU to match or apply
ip ospf mtu-ignore to the interface.
ACLs: If an ACL is applied to an interface and the ACL is not permitting OSPF packets, the neighborship will
not form. Verify ACL with sh ip int [fx/x]. Add permit ospf any any. Protocol 89.
Mismatched Authentication: Both routers must agree on authentication settings for a neighborship. Can
be enabled per interface or for all interfaces within an area. Supports three types:
Null: Type 0, no authentication.
Plain Text: Type 1, sends credentials in plain text.
MD5: Type 2, sends a hash of the credentials.
if) ip ospf authentication (message-digest | null) !!! per interface. (null) = none, blank = plain text.
if) ip ospf authentication-key [key] !!! plain text.
if) ip ospf message-digest-key [#] md5 [key] !!! md5.
router) area [#] authentication (message-digest) !!! optional. set type per area. set key on int. blank=txt.
sh ip ospf !!! to see setting for an entire area.
sh ip ospf int [fx/x] !!! see if auth set & key used with md5. if no auth, section is missing.
sh run int [fx/x] !!! to verify string.
debug ip ospf adj !!! mismatched authentication type, input packet specified type [x], we use type [y].

Duplicate RID: RIDs must me unique to form neighbors, if not, a syslog message will read OSPF-4DUP_RTRID_NBR: OSPF detected duplicate router-id [#] from [IP] on interface [fx/x]. Verify RID with
any OSPF show command. If RID is manually changed with the router-id command, reset the OSPF
process with the clear ip ospf process command before it takes effect, or set RID before enabling. RID
preference is router-id command, highest loopback interface IP, then highest physical interface IP.
Missing Routes:
Int Shut: Make sure the interface is up/up for routes to be advertised or a neighborship to be formed.
Interface Not Running OSPF: When the network area or ip ospf area commands are used, OSPF is
enabled on the interfaces. OSPF takes the associated network/mask and injects it into the LSDB. Even
interfaces that will not form neighborships with other routers need to be participating in the OSPF
process for the interfaces networks to be advertised. sh ip protocols will display the network
statements and interfaces enabled.
Better Source of Info: For an OSPF-learned route to be installed in the routing table, it has to have the
best AD. OSPF has an AD of 110 by default for intra, inter, and external routes. Use sh ip route [IP]
[mask] to verify the routing source. To verify if a network is in the LSDB, issue sh ip ospf database
router [IP]. sh ip ospf database will only display a summary of Type 1 (Router) LSAs, the router addition
will display the contents of a specific routers LSA.
Route Filtering: A distribute list applied to the OSPF process controls which routes are installed into the
routing table from the LSDB. This is different from EIGRP, which controls which routes are sent/received
between neighbors. This is because all OSPF routers within an area must have the same LSDB. To verify
if a route is in the LSDB, issue sh ip ospf database (router [IP]). To apply a route filter to OSPF, the
distribute list is applied inbound (into the routing table), and the matching is done with ACLs, prefix
lists, or route maps. Make sure the distribute list is in the correct direction and that the ACL/prefix
list/route map is correct. sh ip protocols will verify if a distribute list is applied to the OSPF process.
Stub: Because all routers in an area need identical LSDBs, the LSAs within an area cannot be manipulated.
However, you can manipulate the LSAs that go between areas by using stubs. Normal stub areas will
not receive Type 5 (External) LSAs from an ABR. Total stubs and total NSSA areas will not learn Type 3

(Inter-Area Summary) LSAs nor Type 5s; only a single default route is learned. Due to the default route,
visibility of the overall network is lost, potentially producing suboptimal routing. NSSA areas allow
external routes to be injected into the NSSA area; this is done by using Type 7 (NSSA External) LSAs for
the external routes within the NSSA area, but converting them to Type 5s at the ABR. The NSSA router
connected to the external networks becomes an ASBR. Normal NSSA areas will not receive a default
route, but total NSSA areas will. Verify with sh ip ospf.
Wrong DR Elected: On a multi-access network, rather than having all routers form a full mesh of
adjacencies, a DR is elected and all other routers on the segment form an adjacency with the DR (the
DR is actually a pseudonode). The rest of the routers (DROthers) will form 2Way adjacencies with one
another, and if a BDR exists, they will form full adjacencies with it as well. A DR is elected based on
priority, higher is preferred. If priorities are equal, the DR is elected by the highest OSPF RID. BDR
election uses the same criteria. On a multi-access Ethernet topology or a full-mesh Frame-Relay
topology, the DR placement doesnt matter. Over hub-and-spoke NBMA networks such as Frame Relay
or a DMVPN, the DR placement does matter; the DR needs to be reachable via a single hop. Hellos are
established with the multicast address 224.0.0.5, and the DR is reachable at the multicast address
224.0.0.6; packets destined to these two multicast addresses will not be relayed by other routers. To
verify DR placement, use sh ip ospf int [fx/x] on each router. Force the hub to be the DR by preventing
the spokes from participating in the DR election with the interface command ip ospf priority 0.
Duplicate RIDs: RIDs are used during the formation of neighborships and to determine which router is
advertising a specific LSA. In the same area, the routers are going to see Type 1 (Router) LSAs about
networks they do not know about, from a RID the same as their own, making them think they
generated the LSA. A router will not use information contained in an LSA they receive that they
generated themselves, because it indicates there is a loop. This leads to missing routes. Duplicate RIDs
in different areas would cause the physical OSPF topology to be different from what the SPF algorithm
sees it as. This can cause routing issues because some routes may not be passed between areas,
causing the LSDB and the routing tables to be incomplete. Verify RIDs with sh ip protocols.
OSPFv3 for IPv6: Uses the multicast group addresses of FF02::5 (all OSPFv3 routers) and FF02::6
(OSPFv3 DR/BDR).
config) ipv6 router ospf [#] !!! to enable the process.
router) router-id [x.x.x.x] !!! assign an rid if no ipv4 addresses are on the router.
if) ipv6 ospf [#] area [#] !!! to enable per interface.
sh ipv6 protocols !!! process id, rid, abr/asbr, # of areas, stub/nssa areas, ints, redistribution, etc.
sh ipv6 ospf !!! global ospfv3 settings, pid, rid, abr/asbr, timers, areas, type of area, stub, reference bandwidth, authentication,
etc.
sh ipv6 ospf int (brief) (fx/x) !!! network type, cost, authentication, dr/bdr, priority, timers.
sh ipv6 ospf nei !!! verify adjacency, neighbors rid, priority, state, dead timer, local inteface.
sh ipv6 ospf database !!! verify lsas collected and placed in lsdb.
sh ipv6 route ospf !!! verify ospfv3 routes installed in the routing table.
sh ipv6 int [fx/x] !!! verify whether the interface is listening to the multicast group address, mtu, acls.

OSPFv3 Address Families: Enable you to configure a single process that will support both IPv4/6. A
single database is maintained for both. Both OSPF for IPv4 and OSPF for IPv6 will use IPv6 to exchange
routing info; ipv6 unicast routing must be enabled! OSPFv2 and OSPFv3 AFs are not compatible.
sh ip route ospfv3 !!! to verify the ipv4 ospfv3 entries.
sh ipv6 route ospf !!! to verify the ipv6 ospfv3 entries.
sh [ip|ipv6] protocols !!! will show the usual information.
sh ospfv3 !!! displays the same info as sh ip ospf and sh ipv6 ospf. separated per af.
sh ospfv3 int bri !!! displays interfaces participating for each af.
sh ospfv3 int [fx/x] !!! detailed int config with rid, network type, cost, dr/bdr, timers. separated per af.
sh ospfv3 nei !!! normal display, separated per af.
sh ospfv3 database !!! normal display, separated per af.
debug ospfv3 (af) (events|packets|hellos|adj) !!! address family is optional, as well as options.

Adjacencies are established individually for each AF and settings can be configured per AF. Any parameter
configured under the main router OSPFv3 configuration mode will apply to all address families. If there

are conflicts between configurations in router and AF modes, the AF mode takes precedence. OSPFv3 is
enabled per interface with ospfv3 [PID] (ipv4|ipv6) area [#]. Interface parameters are still configured in
interface mode as well. If you do not specify the AF (ipv4|ipv6), the parameter will apply to all AFs. If the
config is applied to the AF, it will apply only to that AF.
config) router ospf v3 [pid]
router) area [#] stub !!! applies to all afs.
router) address-family [ipv4|ipv6] unicast (vrf) !!! enter into a single af.
router-af) passive-interface default !!! change settings per af.
router-af) exit-address-family !!! exit.
if) ospfv3 [pid] (ipv4|ipv6) area [#] !!! enable per interface.

Route Maps and Policy-Based Routing

Route maps provide a more granular level of control than ACLs/prefix lists etc. When used with
redistribution, you can treat each route, or group of routes, differently (metric cost/type manipulation,
tagging). Heavily used with BGP for path manipulation. Driving force behind PBR, allowing you to control
forwarding (next-hop IP/interface) based on source, tag, ports, etc.
Can be displayed with sh run | s route-map or sh route-map (name). Identified by a name. There may be 1
or more sequences, defined by a number. Sequences can be permit or deny, if not stated, permit is the
default. For redistribution, permit means to redistribute the route, while deny means to not redistribute
the route. For PBR, permit means to PBR route the packet, while deny means to route the packet
normally with the routing table. Within a sequence there may be match and set clauses. If there are
multiple match criteria in a single match statement, they function with OR logic, while multiple
separate match statements function with AND logic. If there is no match clause in a sequence, it will
match all (there can be a set clause added).
Top-Down Processing: Lowest sequence to highest.
Immediate Execution Upon Match: If a match clause matches the traffic in question, the process
stops and the actions in the set clause is executed. If no match is found, the next sequence is
checked.
Implicit Deny Any: If no sequence matches the traffic, any remaining traffic is treated as though it
matched a deny, like an ACL.
PBR: You can create user-defined policies that manipulate how traffic will be routed through a network,
using route maps. By default, traffic is routed based on the destination IP of a packet. With PBR you can
override this behavior and have traffic routed based on different parameters (matched per ACL (with port
#s)/prefix list/inbound interface). When troubleshooting, verify the traffics path with a traceroute. sh
route-map will indicate the number of packets that have been matched at the end. PBR can be monitored
in real time with debug ip policy. Output will show a policy match, the route map, the item #,
permit/ deny, and policy routed/policy rejected - - normal forwarding.
How the Policy is Applied: PBR is only applied to inbound packets on an interface (ip policy route-map
[name]), or locally generated packets by the router (ip local policy [name]). You must ensure that the
correct PBR route map is applied to the correct interface/router. Verify with sh ip policy to see the route
map name and interface. sh ip local policy will verify PBR applied to the router.
Route Map Order: Verify that permit sequences are used to match traffic you do want to PBR. Remember
the implicit deny. Use sh route-map to verify contents.
What Traffic is Being Matched: You can match with ACLs, prefix lists, inbound interfaces, and others.
Verify match statements with sh route-map and contents with sh ip access-list or sh ip prefix-list. If
there is no match clause, match all!
What Action Performed: Verify the set clause with sh route-map. PBR can be used to set the next-hop IP
or exit interface. If the default keyword is used, the router will route the packet normally, but if there is
no non-default route, it will PBR route the packet.

Redistribution
Allows routes learned via one source to be injected into a routing protocol. If two routing protocols are
mutually redistributed, the routes learned via each are injected into the other. A router that connects two
or more routing domains and will be the point of redistribution is known as a boundary router.
Redistribution occurs from the routing table into a routing protocols data structure (topology
table/LSDB). The two prerequisites for routes to be redistributed are for the route to be installed in the

border routers routing table by the protocol being redistributed and for the destination routing protocol
to have a reachable metric to assign to the redistributed routes.
Because different routing protocols use different types of metrics, routes being redistributed into a
different routing protocol need a seed metric assigned. The seed metric is needed to communicate
relative levels of reachability between dissimilar routing protocols metrics. They can be assigned in
three ways; a route map added to the redistribute command; the metric parameter in the redistribute
command; or the default-metric router command. They are listed in the order of preference should there
be multiple values assigned. If there is no seed assigned, the default is used; RIP and EIGRP have a
default seed metric that is considered unreachable while OSPF has a default seed of 20 (unless its a BGP
route being redistributed, which would have a seed of 1). When redistributing into BGP, BGP will use the
exact metric of the IGP. For EIGRP and RIP, you do not need to specify a metric when redistributing static
or connected routes. For EIGRP EIGRP, you do not have to specific a metric as the original metric is
preserved.
EIGRP and OSPF can tag routes as either internal or external and give priority to internal routes. The
capability to distinguish between both types can help prevent routing loops (when two routing protocols
continually redistribute the same routes into one another at multiple redistribution points).
If you are redistributing from BGP into OSPF, EIGRP, or RIP, only eBGP routes will be redistributed by
default. If you want iBGP routes to be redistributed, the router command bgp redistribute-internal must
be issued.
Source Routing Protocol: Verify that a route being redistributed from a routing protocol has been
learned by that routing protocol. Verify topology table or routing database.
Route Selection: Ensure that the routes from the source routing protocol are being injected into the
routers routing table. sh ip route [IP] [mask].
Redistribution Configuration: Check the metric being applied, check for route filtering, and check the
syntax of the redistribution command for the correct process ID, AS #, and route-map name.
Destination Routing Protocol: Check the destination routing protocol. A redistributed route may be
marked as external; check the destination routing protocol to determine if it treats external routes
differently than internal routes.
Redis. into RIP: Options are limited, when redistributing from EIGRP, BGP, static, or connected, the only
options are metric and route-map. The most common issue is related to the metric; by default, the seed
is set to infinity. If you dont set one, routes will not be advertised to other routers in the RIP domain. If
you configure the metric too high at the redistribution point, the route may become unreachable after a
few hops within the RIP domain. Check for a route-map being applied to see if there are any issues there.
When redistributing OSPF into RIP, there is the additional option to match internal, external (1 or 2),
nssa-external, or a combination of types. With RIPng, the issues are the same, with the addition of
connected networks not being redistributed by default without the include-connected keyword. Verify
redistribution on the boundary router with sh ip protocols, and the routes that were redistributed with sh
ip rip database. Verify other routers in the domain are learning with sh ip route as well as sh ip rip
database. Verify RIPng with sh ipv6 protocols.
Redis. into EIGRP: Similar to RIP, you have the metric and route-map options, as well as match when
redistributing from OSPF (internal, external, nssa-external, or a mix). By default, the seed metric is set to
infinity; if the metric (k-values) is not manually set, routes will not be advertised. You do not have to
worry about setting the metric too high as in RIP, however, consider if high metrics will cause suboptimal
traffic flow if there are multiple redistribution points in the routing domain. Again, when using IPv6,
connected routes are not advertised by default without including the include-connected parameter. Verify
redistribution is enabled with sh ip protocols, review the topology table with sh ip eigrp topology (via
Redistributed), and verify routes/metrics with sh ip route [IP]. On routers within the EIGRP domain that
are not the boundary router, sh ip route will display the routes with a code of D EX and an AD of 170. To
verify with IPv6, use sh ipv6 protocols, sh ipv6 eigrp topology, and sh ipv6 route.
Redis. into OSPF: When redistributing into OSPF, there are more options:
Metric: There as usual, but not necessary as there is a default of 20.
Metric-Type: Allows you to define the type of external route; default is Type 2 (E2), which preserves
the seed metric for external routes. Type 1 (E1) allows each router to take the seed metric and add to
it all the other links costs to reach the redistribution point in the domain.

NSSA-Only: Allows you to limit redistributed routes to the NSSA area only.
Route-Map: Allows you to use a route map to granularly control routes.
Subnets: Extremely important as without it, only classful networks will be distributed (/8, /16, /24).
Tag: Allows you to add tags to the routes so the routes can be referenced by the tag at a later point for
filtering or manipulation.
Include-Connected: For IPv6/OSPFv3, will redistribute local interfaces, which isnt done by default on
OSPFv3 as it is in OSPFv2.
Verify with sh ip protocols. Routes redistributed into a normal area will be advertised with a Type 5
(External) LSA, while routes redistributed into a NSSA or totally NSSA area will be advertised with a
Type 7 (NSSA) LSA, then converted to a Type 5 at an ABR. View the routes being injected into the LSDB
with sh ip ospf database and scroll down to the Type 5/7 areas. On the boundary router/ASBR, sh ip
route [IP] will verify how the route is known, how it is redistributed, and how it is advertised. On other
routers, sh ip route will, by default, have an AD of 110 and a code of O E2. If the metric type is
changed, the code will be O E1, and NSSA areas will appear as O N1/2. Verify OSPFv3 with sh ipv6
protocols and sh ipv6 ospf database on the ASBR.
Redis. into BGP: Same options as RIP/EIGRP; metric and route-map by default, and if injecting OSPF,
match. Only internal OSPF routes will be redistributed by default! metric is not required because BGP will
use the IGP metric by default. For IPv6, the same include-connected keyword is applicable. Verify with sh
ip protocols, and sh ipv6 protocols. In sh bgp all, the BGP table will show redistributed routes with a ?
under the Path column.
Suboptimal Routing: Can lead to users experiencing slow connectivity. When redistributing, the original
routing sources information is lost when the seed metric is in injected at the redistribution point; overall
network visibility is lost. This is not an issue when there is only 1 point of redistribution, but if there are
multiple points between two sources, a suboptimal path may be chosen. You can recognize this issue
from a topological diagram in addition to using traceroute. You can solve this issue by providing different
seed metrics on the boundary routers that will ensure a certain path is preferred because it has a lower
overall metric.
When redistributing EIGRP OSPF, routes will have a default seed metric of 20 and be classified as E2
(metric wont be incremented). You can simply make the preferred ASBR advertise a lower seed metric to
ensure that optimal routing is achieved. If using type E1, the cost of links within network are added to the
seed metric. Based on the topology, you need to be able to recognize mutual redistribution and the
different speeds of the links. Based on the routing protocols used, identify how the seed metric is
determined and how it behaves. Know how to fix issues by manipulating metrics on the boundary routers
with the default-metric command, the metric parameter in the redistribute command, or with a route
map.
Internal prefix information should always be preferred over external information. Prefixes should never be
redistributed back into a routing domain that they were originally distributed from. A topological diagram
is mandatory if you expect to solve issues quickly and efficiently.
Route Map Issues: When applying a route map, verify that you are using the correct route map, if
statements are correctly a permit/deny (permit matches what will be redistributed), if ACLs/prefix-lists
are correct, and if the set statement is applying the correct values. Extended ACLs with redistribution use
[(host) IP (WC_mask) (host) host_mask (WC_mask)] logic! If a route does not match any match
statements, it hits the implicit deny and will not be redistributed. If a route map is applied to a
redistribute command and doesnt exist, no routes will be redistributed. Verify with sh route-map and sh
run | s route-map.

Routing Loop Example: When the RIP 10.1.1.0 network is redistributed into EIGRP, it is classified as an
external route with the code D EX and an AD of 170. When R1 and R2 redistribute the same route
into OSPF (using a Type 5 External LSA), it will have code O E2 and an AD of 110. These
advertisements are flooded throughout the OSPF area, therefore, R1 and R2 will hear one anothers
advertised LSAs. Each router is now receiving two advertisements for the 10.1.1.0 network, one from the
EIGRP area with an AD of 170, and one from the OSPF area with an AD of 110. The lower AD of OSPF

170

110

110

routes causes the routers to point to one another to get to the 10.1.1.0 network, causing a routing loop.
In addition, the 10.1.1.0 network was originally in R1 and R2 as an EIGRP external route with an AD of 170.
Now that R1 and R2 are learning about the same network from one another from the OSPF domain, the
OSPF route will be preferred with an AD of 110. This causes the OSPF route to replace the EIGRP route on
R1 and R2, in turn, making the EIGRP route no longer eligible for redistribution into OSPF. Now that the
route is no longer in OSPF, the original EIGRP external route from RIP will be reinstalled, and once again
sent into OSPF. This flapping will cycle repeatedly and can be seen with debug ip routing.
The root of this issue is the differences in AD; OSPFs 110 is better than External EIGRPs 170. To fix this,
youll either have to lower the AD of the external EIGRP routes on R1 and R2 below 110, or increase the
AD of the OSPF learned routes on R1 and R2above 170. The goal is to make the external EIGRP learned
routes preferred. This is achieved with the distance command on both R1 and R2 to change AD values.
The router distance [eigrp|ospf|AD,IP,WC,(ACL)] command can either apply to all internal and external
routes, or a specific IP (with an optional ACL). If you choose to lower External EIGRPs AD, it will need to
be 109 or lower; if you raise OSPFs AD, it will need to be 171 or higher.
Another way to solve this issue is with a distribute list on the OSPF process on R1 and R2. This will deny
the 10.1.1.0 route in the OSPF database from being installed in the routing table, allowing the EIGRP
route to stay.
A third way to solve this is with route tags. R1 and R2 can add a tag when the route is redistributed via
route maps. Permit the route via match ACL/prefix-list statement, set a tag, and permit any other route.
Apply this route map to the EIGRP OSPF redistribution command. This will only tag the route, to
prevent the tagged OSPF route from entering back into EIGRP; you need to deny the route at the
opposite router from entering EIGRP. This is also done via another route map with a deny sequence
matching the respective tag (permitting all else!), applied to the OSPF EIGRP redistribution command.
Do on both R1 and R2!

BGP
BGP establishes neighbor adjacencies manually, making it more prone to human error. There are two
types, iBGP (internal) and eBGP (external). Keeps a route table separate from the IP routing table. Sends
full updates, then partial.
sh bgp ipv4 unicast summary !!! same as below.
sh ip bgp summary !!! use for initial verification of neighbors. neighbor, version, as, state, prefixes etc.
sh bgp ipv4 unicast neighbor (ip) (advertised-routes|routes) !!! same as below.
sh ip bgp neighbor (ip) (advertised-routes|routes) !!! very verbose, add filters.
%bgp-5-adjchange: neighbor [ip] up !!! ex syslog message.

Neighbor Adjacency Issues:

Interface (Peer) Down: Interface must be up/up, including physical or logical interfaces (loopback).
Loopbacks are used when there are redundant paths. If one path fails, the neighborship will still be
available using another local physical interface since the loopback is the source and destination of
packets. Verify with sh ip int brief.
L3 Connectivity Broken: While you dont have to be directly connected to form a BGP neighborship, or
even be in the same subnet, you need to have L3 connectivity to the neighbor. In sh bgp ipv4 unicast
sum, the State/PfxRcd will display Idle. This happens when the local router is unable to make a TCP
connection with the neighbor. Review the routing table with, sh ip route [IP] 255.255.255.255 and ping
(using a source) the remote router.
Path to Neighbor is via Default Route: You may be able to ping the neighbor via a default route,
however BGP requires a route other than the default route to form an adjacency. sh bgp ipv4 unicast
sum will display a state of Idle, indicating that it cannot from a TCP connection.
Neighbor Doesnt Have A Route To Local Router: Both routers forming a BGP peering must have
routes to one another (or loopbacks). If a neighbor doesnt have a route back to the local router, the
neighbor will be Idle in sh bgp ipv4 unicast sum.
Incorrect Neighbor Statement: The IP and AS # in the neighbor [IP] remote-as [#] statement must be
accurate. If AS #s match, there will be an iBGP peering. If a route is found and a three-way TCP
handshake is completed, an open message is sent. If there is no response to the open message, the
state will be Active. Verify TCP sessions with sh tcp brief all. If the AS # does not match the peers AS
#, the state will flap between Idle and Active. A syslog message is generated reading %BGP-3NOTIFICATION: sent to neighbor [IP] passive 2/2 (peer in wrong AS) 2 bytes FFDD.
ACLs: Make sure youre not blocking TCP port 179. Neighbors will have a state of Idle if they cant
establish a TCP session. If an ACL is blocking port 179 in only one direction, a neighborship will still
form because BGP sessions are server/client. The server uses port 179 while the client uses an
ephemeral port. By default, both routers will try to establish a TCP session by sourcing a packet from an
ephemeral port, with a destination port of 179. This causes two session when there can only be one,
called a BGP connection collision. BGP solves this automatically (higher BGP RID will win). You can
control the client/server with neighbor [IP] transport connection-mode [active | passive]. Active (initiate
TCP session) for client, passive (passively wait for TCP session) for server. sh bgp ipv4 unicast neighbor
will show the local and remote ports, to filter, append i ^BGP neighbor|Local port|Foreign port.
TTL of BGP Packet Expired: Happens if a peer is further away than permitted. By default, eBGP peering
is between directly connected routers (within 1 hop) while iBGP can be up to 255 hops away. sh bgp
ipv4 unicast nei |in BGP neighbor|TTL will show External BGP neighbor may be up to [#] hops away. If
the TTL isnt large enough to support the distance required, the BGP packet will be discarded. Since
loopbacks are not directly connected, they will make an eBGP peering fail by default. sh bgp ipv4
unicast sum will display the configured neighbor with a state of Idle. The TTL of eBGP packets can be
changed using the command neighbor [IP] ebgp-multihop [TTL]. Once fixed, sh bgp ipv4 unicast sum
should have a State/PfxRcd with a number.
BGP Packets Sourced From Wrong IP: The source IP of an inbound BGP packet must match the local
neighbor statement. In redundant topologies, a BGP router will have multiple active IPs across its
interfaces. When you configure a neighbor, the IP specified is used to determine if the open message
came from a router it should establish a BGP peering with. A BGP open message will contain a source
IP, which is compared against the IP in the neighbor command; only if they match will a BGP peering
form. The source IP is based on the exit interface of the router sending the BGP open message. To
control the IP that is used when sending BGP messages, use the neighbor [IP] update-source [fx/x]
command. Often set to a loopback interface. It is important that both ends be configured appropriately.
Make sure ebgp-multihop is configured as well.
Mismatched Auth: Both routers must agree on authentication parameters. BGP supports MD5
authentication. If syslog messages are enabled, a message will read %TCP-6-BADAUTH: No MD5 digest
from [IP](179) to [IP](port#) tableid 0. The state will be Idle as well.
Timers: Dont have to match; BGP will use the lowest set between neighbors. However, if the minimum
holddown from neighbor option is set, this may prevent a neighbor adjacency. If the neighbor sends a
timer that is below the minimum, they will not form a neighborship. Command appears as neighbor [IP]
[hello] [holddown] (min. holddown).

Misconfigured Peer Group: When a BGP-enabled router sends updates, it builds a separate update for
each neighbor. A large number of neighbors can have a significant impact on the CPU. Peer groups help
with this since the router will only need to run an update for an entire group instead of per neighbor.
Although the update is only run once, the TCP transmission will occur per neighbor. Also allows for less
typing/configuration. Create with neighbor [name] peer-group. Common issues are:
Not Associating the Neighbor with the PG. After the peer group is created, the neighbor still needs
to be manually defined as well as associated with the peer group with the command neighbor [IP]
peer-group [PG Name].
Not Configuring the PG Correctly: What works for one neighbor may not work for another. I.e., an
update source of a loopback may work for an iBGP peer but not an eBGP peer.
A Route Filter Applied to the Group is Not Appropriate for all Peers.
Order of Operations: If there are conflicts between the PG configuration and a specific neighbor
statement, the neighbor statement wins.
Missing Routes: Routes can be verified with sh bgp ipv4 unicast (sh ip bgp). This will include BGP-learned
routes or routes locally injected into BGP (with the network mask, redistribute, or summary-address
commands). Includes codes indicating a routes validity, best path, RIB-failure, etc. as well as each
routes individual next-hop, metric, local preference, weight, and AS path (right to left). The source of
these routes is not fully clear, however a network with a Next hop of 0.0.0.0 indicates it was
originated by the local router, otherwise it was learned from a peer. If the Path column ends in a ? it
was redistributed into BGP at some point and if it ends in an i, the route was injected with the
summary-address or network mask command. sh ip route bgp will display BGP routes in the routing
table, each beginning with a B. Append longer-prefixes to see subnets.
Missing/Bad Network Mask Command: This command is used to advertise routes into BGP. The
network/prefix being advertised has to be in the routing table from another source. Additionally, the
command must be an exact match to the network/prefix listed in the routing table. Summary addresses
will not work! Verify with sh run | s router bgp and ensure statements exactly match networks in sh ip
route. The mask is not actually required, but network is classful without it.
Route Filtering: Determine whether there is a route filter applied, and if it is the cause of the missing
routes. sh bgp ipv4 unicast will show you if BGP knows of a route. To determine if a router is receiving a
route, use sh bgp ipv4 unicast neighbor [IP] routes; this displays routes learned after local filters have
been applied. To check if the other router is sending a route, use sh bgp ipv4 unicast neighbor [IP]
advertised-routes. Use sh ip protocols to verify an incoming filter. Filters listed there will apply to the
entire BGP process. Filters can additionally be added directly to a neighbor (not interface!) using the
neighbor [IP] [distribute-list | prefix-list | route-map | filter-list] [in | out] commands. These can also be
verified with sh ip protocols, just lower, with the exception of a prefix list. This will only show in a sh run
or sh bgp ipv4 unicast neighbors [IP] | in prefix|filter|Route map.
Next-Hop Router Not Reachable: If you are seeing BGP routes in the BGP table but they are not
appearing in the routing table, the router may not be able to reach the next-hop. Run sh bgp ipv4 unicast
and look at the status codes on the left. Below, R5 has the 10.1.1.0/26 network listed as valid (*) and
internal (i), but not the best path (>). This is because a path to the next-hop IP of 1.1.1.1 is not known by
R5. Appending the next-hop IP to the command would display the route with no best path and as
inaccessible. A ping to the next-hop would fail as well.
R5# sh bgp ipv4 unicast
* indicates a network is valid.
> indicates a network is the best path and will end up in the routing table.
i indicates the route was learned via ibgp.
*i

Network

Next Hop

10.1.1.0/26

1.1.1.1

Metric

LocPrf

Weight

100

Path
65501 i

This is due to the fact that the next-hop for BGP routes outside of an AS should be the IP of the router
learning the route from the external AS (R2) and advertising it to the internal AS. However, by default,
BGP will not change the next-hop since BGP is based on AS hops, not router hops. Therefore, by default,
the next-hop is the IP of the router advertising the network from the next-hop AS (R1). To get R5 to

learn how to reach R1 you could create a static default route on R2 and R3 to R1 and advertise the
route into the IGP, advertise R1s address directly into the IGP, or create a static/static default route on
R5 to R1. The easiest/best way to solve this is with the neighbor [IP] next-hop-self command on R2 and
R3. This allows an edge router to change the next-hop address to its own address before advertising a
route to a peer.
Private AS Numbers: BGP AS numbers also have a private range. In the 2-byte AS range, it is 64,512 to
65,534 and in the 4-byte AS range, it is 4,200,000,000 to 4,294,967,294. These can be used for networks
that are single-homed or dual-homed to the same ISP to preserve public AS numbers for networks that
are multi-homed to multiple ISPs. These should be used in customer networks and must not be in the
AS_PATH when routes are advertised to the Internet since multiple ASs could be using the same private
AS numbers. If private AS numbers are sent into the global BGP table, this can be stopped with neighbor
[IP] remove-private-as.

Better Source of Info: Routes learned from eBGP peers have an AD of 20 while routes learned from iBGP
peers have an AD of 200. This is because BGP is designed to share routes between different ASs. If you
learn a route from another AS via multiple routing sources, you want the eBGP learned route to be the
preferred source over all other dynamic routing protocols. R1 below advertises its networks to both R2
and R3 using eBGP. R2 and R3 will advertise the same routes to one another due to their iBGP peering.
Additionally, R3 may redistribute its eBGP learned routes into EIGRP. Now, R2 will know about the same
networks via three different sources, eBGP (20), iBGP (200), and External EIGRP (170). eBGP will win by

default and traffic will be routed directly from R2 R1, instead of detouring through R3, which would
cause suboptimal routing.
The command sh bgp ipv4 unicast will display the BGP routes a router knows. On R5, the networks in AS
65501 have a code of *>i when going through R2 and a code of * i when going through R3. Networks
within AS 65502 have code of either r>i for paths through R2, or r i for routes through R3. The r in
place of the * indicates that the routes are not valid and there is a RIB failure (even though they may
be the best {>}), meaning that the BGP route could not be installed in the routing table. In this case, the
routes actually are in the routing table, but from another source. If you were to issue sh ip route [IP]
[mask] for the networks with an r, you would see the winning sources (connected, 0 AD or EIGRP, 100
AD). Additionally, sh bgp ipv4 unicast [IP] would show that the routes are iBGP (200 AD). You can confirm
RIB failures with sh bgp ipv4 unicast rib-failure.
BGP Split-Horizon: A BGP router that learns BGP routes through an iBGP per will not share those routes
with another iBGP peer. For R5 to learn about networks in AS 65501, it has to be a direct iBGP peer with
the router that learned about the routes from an eBGP peer (R2/R3), or it has to be a peer with a route
reflector. Creating a full mesh of iBGP peers also has the added benefit of additional redundancy. Use sh

bgp ipv4 unicast sum on all routers to identify peers.

Synchronization: iBGP routes must be synced with IGP routes before they can be used or advertised to
an external neighbor. This makes sure all routers in an AS know all routes, preventing transit routers that
arent running BGP (non-full-mesh deployment) from dropping packets with unknown destinations. Newer
routers have this disabled by default, turn off with the router command (no) synchronization.

Aggregation: BGP routers can perform aggregation of networks. This is done with the router aggregateaddress [IP] [ WC mask] command. When doing so, the atomic aggregate attribute is added to the route,
which indicates to downstream routers that aggregation was performed. The aggregator attribute
indicates what router the aggregation was performed by and what AS the aggregation was done in. By
default, BGP sends a summary route in addition to the specific routes; to send only a summary and
withdraw the specific routes, append summary-only to the aggregate command. When summarization is
done by a router thats not the originator of the route, the originating AS information is lost. To include
this originating AS in the path, append as-set to the aggregate command. On the router performing the
aggregation, if using the summary-only option, sh bgp ipv4 unicast [IP] [mask] longer-prefixes would
show the summarized routes with a code of s for suppressed.
Path Selection: BGP does not consider a links bandwidth when making route decisions. Instead, it uses
various attributes when deciding which path is best. To view all attributes per route, per neighbor, use sh
bgp ipv4 unicast [IP], they are listed newest to oldest, N WLLA OMNI:
Next-hop reachable?
Highest Weight. Def 0.
Highest Local Preference. Def 100.
Originated by Locally. (if 0.0.0.0)
Shortest AS path.
Origin code. IGP > EGP > ?
Lowest MED.
Network type. external > internal.
Lowest IGP metric.
Oldest route for eBGP paths.

R2# show bgp ipv4 unicast 10.1.1.128

BGP routing table entry for 10.1.1.128/26, version 6
Paths: (2 available, best #2, table default)
Advertised to update-groups:
2
IGP Metric
IP
RID
AS Path Refresh Epoch 2
65501
3.3.3.3 (metric 131072) from 3.3.3.3 (3.3.3.3)
Local
Origin IGP, metric 0, localpref 10, weight 10, valid, internal
pathid: 0, tx
pathid:Local
0 Preference
Originrx
Code
MED
Weight
Network Type

Lowest neighbor BGP RID.

Lowest neighbor IP address.

sh bgp ipv4 unicast will show a summary of each route, its next-hop, metric, Local_Pref, weight, and
AS path.
Weight: Proprietary feature to Cisco. Only locally significant (not advertised to other routers). Higher is
preferred. Default is 0 for learned routes, 32,768 for locally originated routes, goes up to 65,535. Used on
a single router to influence its choice of outbound routes. When BGP Updates are received, the router can
set the weight for all routes from a neighbor (neighbor [IP] weight [#]) or selectively set weights using a
route map with a set wight [#] statement and applied with neighbor [IP] route-map [name] in.
Local Preference: Well-known attribute. Higher is preferred. Used for when there are multiple paths
between ASs. Acts as the opposite of the MED. Locally significant to an AS. Decides which path to use to
exit the AS. Only passed between iBGP peers. Set with the router command bgp default local-preference
[#] for all routes advertised from a router, or selectively with a route map with a set local-pref [#]
statement, applied with neighbor [IP] route-map [name].
Multi-Exit Discriminator (MED): Optional, lower is preferred. Displays as Metric. When there are
multiple entrance points into an AS (dual homing), the MED tells a neighbor AS which link into the AS to
use. The metric will pass to a neighboring AS, but no further. Configure using a route map with a set
metric [#] statement and apply with neighbor [IP] route-map [name] out. To compare metrics from
multiple ASs use the router command always-compare-med.
Reset: IOS does not cause a newly configured BGP filter to take effect until a neighborship is cleared. A
neighbor can be disabled with the command neighbor [IP] shutdown. A simpler way is with the command
clear ip bgp [ (IP) | * ], which will reset a BGP connection; considered a hard reset because it takes down
the neighborship, TCP connection, and clears BGP table entries. To be less disruptive, clear ip bgp [ (IP) |
* ] soft will maintain the neighborship and TCP connection, but will resend outgoing Updates with the new
filter applied as well as reprocess incoming Updates, again with the new filter applied.
Default Route: To send a neighbor a default route originating from the local router use the command
neighbor [IP] default-originate.
Passwords: Passwords can be set for neighbors with the command neighbor [IP] password (0|7) [pass].
Debugging: The majority of changes that occur with BGP will generate syslog messages. debug ip routing,
while not specific to BGP, will show updates to the routers IP routing table. debug ip bgp shows real-time

state changes for BGP peering, but does not show the contents of updates. debug ip bgp updates is more
detailed and will show the content of updates.
BGP for IPv6: BGP for IPv4 and IPv6 are configured in the same address family (AF) config mode, known
as Multiprotocol BGP (MP-BGP). This requires the use of AFs and the activation of neighbors for those AFs.
There are two AFs; one for IPv4 unicast and another for IPv6 unicast. Neighbors and remote AS numbers
are identified outside the AF config. Neighbors are then additionally activated within the AF with the
neighbor [IP] activate command.
config) router bgp [as]
router) neighbor [ip] remote-as [as]
router) address-family ipv4
router-af) neighbor [ip] activate
router-af) exit-address-family
router) address-family ipv6
router-af) neighbor [ip] activate

There are two different ways to exchange IPv6 routes with BGP; they can be exchanged via IPv4 or IPv6
TCP sessions. If the IPv6 AF is using an IPv4 neighbor address to establish a TCP session, the TCP session
will be IPv4 based. sh bgp ipv6 unicast sum will display the neighbor adjacency with an IPv4 IP. To verify
IPv6 routes learned, use sh bgp ipv6 unicast. A route with a next-hop of :: is locally originated. When
neighboring with a router using its IPv4 address, the next-hop for learned networks will read FFFF:[IPv4
Add]. This address is dynamically generated and will not have a > because it is not reachable. This
occurs because an IPv6 route cannot have an IPv4 next-hop address, caused by the IPv4 adjacency for
the IPv6 AF.
R1# show bgp ipv6 unicast summary
Neighbor

2.2.2.2

AS MsgRcvd
65502

MsgSent

TblVer

25

25

InQ OutQ
0

Up/Down

State/PfxRcd

00:12:02

R1# show bgp ipv6 unicast

Network

Next Hop

Metric

LocPrf

Weight

Path
i

*> 2001:DB8:1::/64

::

32768

::FFFF:2.2.2.2

2001:DB8:2::/64

65502 i

The solution for this issue is to create a route map that will change the next-hop to a valid IPv6 address
and attach it to a neighbor statement. This has to be done on the advertising router.
config) route-map [rm name] permit 10
route-map) set ipv6 next-hop 2001:db8:12::2
config) router bgp [as]
router) address-family ipv6 unicast
router-af) neighbor 1.1.1.1 route-map [rm name] out

If you were to now look at sh bgp ipv6 unicast summary, the remote network should now display the
correct next-hop IPv6 address, 2001:db8:12::2, and have a >. When forming IPv6 TCP
sessions/neighborships, this issue doesnt exist. You simply have to define the IPv6 neighbor and activate
it (both an IPv4 and v6 neighbor entry for the same router is ok!). sh bgp ipv6 unicast sum will display a
neighbor with an IPv6 address and sh bgp ipv6 unicast will display an IPv6 next-hop.
config) router bgp [as]
router) neighbor 2001:db8:12::2 remote-as [as]
router) address-family ipv6
router-af) neighbor 2001:db8:12::2 activate

Management Protocols and Tools

Syslog and SNMP help monitor the health of the network. It is important to know what time events
occurred. Accurate time can be kept with NTP so log message have accurate time stamps across multiple
devices.
Clock: Default is March 1, 1993.
clock set [hh:mm:ss] [month] [day] [year] !!! this is an enable mode command!
sh clock (detail) !!! (detail) states time source is ntp if ntp is configured.

NTP: Used to synchronize clocks among various network devices. It is a client/server protocol.
Time Server Not Reachable: Use a ping to verify connectivity. Ensure the ping is sourced from the
correct interface if using a loopback (ntp source [fx/x]).
ACLs: NTP uses UDP port 123. Verify with sh ip int [fx/x] and sh access-list.
Authentication: While not required, client and server need to be configured with the correct
authentication key and key string. Verify with sh run | s ntp and sh ntp association detail.
Wrong Server: A client can be configured with multiple NTP servers. By default, NTP will choose the best
server. You can force a preferred server with the keyword prefer in the ntp server command. Verify the
server being used with sh ntp status (detail).
High CPU: The CPU processes NTP packets; if it is under a high load, it will fail to process packets and
synchronization will fail. Verify with sh proc cpu.

Time Offset Too High: If the offset between the server and client is extreme, it can take a long time for
the clocks to sync or they may not sync at all. Manually set the clock with the enable mode command
clock set, and allow NTP to fine-tune the clock from there. Verify the clock with sh clock.
Stratum Too High: Hierarchy based on stratum levels 1-15, 1 being the best, 16 indicating a server is
unreachable. If a device is syncing with another device that itself has a stratum of 15, it will fail. Verify
with sh ntp status.
Server has an ACL: An NTP access-group on the server can control where clients can source packets
from. Verify the ACL.
config) ntp server [ip] (prefer) (version [3|4]) (key [#]) !!! client, if multiple, pick a (prefer)red.
config) ntp authenticate !!! enable authentication.
config) ntp authentication-key [key-number] md5 [key-string] !!! define an authorization key.
sh ntp status !!! verify if the clock has synchronized, the stratum level, and the ip of the ntp server.
sh ntp association !!! verify servers. if multiple configured, all listed here. * indicates the local device is synced with that server.
+ indicates a server is a candidate for synchronization.
sh ntp association (detail) !!! additional details, including authentication.
debug ntp all !!! events, core messages, clock adjustments, reference clocks, and packets.
ntp core (notice): ntp_receive: dropping message: res_dontserve restriction !!! debug, indicates acl.

Syslog: By default, console, monitor, and buffer logging display messages with a severity of 7 (debugging)
and lower. The buffer has a default size of 8,192 bytes, once full it will overwrite old entries. Increase the
size with logging buffered [#]. View syslog messages in the console if connected to vty lines with
terminal monitor. Use sh logging to verify, ensure logging is enabled, severity levels for each type are
correct, buffer size is sufficient, and check logs.
Logging to a server is disabled by default, but once enabled, all severity levels are sent to the server. The
correct server IP has to be specified and must be reachable. Syslog uses UDP port 514, which must not
be blocked by an ACL.
terminal monitor !!! view console messages when connected to vty lines.
config) logging buffered (size 4096-huge) ( [severity #] | [name] ) !!! to enable buffer and change size.
config) logging console ( [severity #] | [name] ) !!! on by default, use to change severity.
config) logging (host) [ ip | hostname ] !!! (host) is optional, same. sends messages to syslog server.
config) logging trap [ (severity #) | (name) ] !!! what level of messages to send to syslog server.
config) (no) logging on !!! enable/disable.
line) logging synchronous !!! stop console messages from being overwritten.
sh logging
clear logging

Having log and debug messages time stamped is critical. If theyre not present, its due to the command
no service time-stamps. To configure, use service time-stamps [debug|log] [datetime|uptime].
Severity: 0-7 indicates how important. Lower # is higher priority, selecting a number includes
selected and those lower in #.
Every Awesome Cisco Engineer Will Need Icecream Daily
0 emergencies: crashes, stopped processes.
1 alerts: platform errors.
2 critical: hardware issues, port security, stp.
3 errors: acl, tcam, pagp, ethernet controller, interface up/down.
4 warnings: dhcp snooping.
5 notifications: 802.1x, dtp, etherchannel, inline power, stp, interface line protocol.
6 informational: stack events, port security, dynamic arp inspection, vtp, udld, stp, hardware diagnostics.
7 debugging: default.

SNMP: You must be able to ping the server from the agent. If L3 connectivity does not exist, the SNMP
server cant access info in the MIB on the agent. SNMP uses UDP port 161 for general messages and UDP
port 162 for traps and informs.

Manager: System that uses SNMP to poll and receive data from any number of network devices. Usually a
central application. Manager sends poll/query to the switch with the OID of a specific variable being
requested.
Agent: Process that runs on the network device being monitored. Data is gathered by the device itself and
stored locally. Agent responds to SNMP polls and queries with info from the data, and can send
unsolicited traps/informs to the manager.
Management Information Base (MIB): Database on an agent containing variables about itself.
Organized in a structured hierarchical fashion. Each MIB is referenced by an OID.
Object Identifier (OID): Long string of indexes that follows the path from the root of the tree all the way
to the variables location.
v1: Simple get (next)/set requests, traps, and unsolicited alert messages. Access is based on a community
string, which is sent in plain text (Use read only!).
config) snmp-server community [comm.-string] ( ro | rw ) (acl #)
config) snmp-server host [host ip] [comm.-string] (trap type) !!! manager where traps will be sent.

v2C: Adds 64-bit variable counters (allows for higher values), bulk requests, and inform
requests. Same first 2 commands as above.
config) snmp-server host [host ip] (informs) version 2c [comm.-string] !!! use (informs) instead of traps.

Trap: News of an event that is sent without any acknowledgment that the trap has been received.
config) snmp-server enable traps (trap name) !!! enable traps. blank is for all.

Inform Request: Same as a trap, but manager is required to acknowledge the receipt by echoing
the request back to the agent.
Issues:
Community Strings Matching: Strings must match between the server and client.
ACLs: If an ACL is used to define the source of servers on the client, it must include the correct IPs.
Config of Notifications: If the agent is configured to send traps or informs, verify that traps are enabled,
the server IP is correct, the SNMP version is correct, informs is chosen, and the correct traps are
specified. Use the command snmp-server enable traps [type] to select what type of informs/traps to
send. Traps/informs are enabled in the snmp-server host [IP] (informs) command.
Indexes Shuffling: To prevent index shuffling and guarantee index persistence during reboots or minor
software upgrades, use snmp-server ifindex persist. This shows as snmp ifmib ifindex persist in the
running config.
SNMPv3: Adds user authentication, security levels, data integrity, encryption, and groups with
read/write access.
Users are created with authentication and encryption parameters. They are what the SNMP manager will
use to communicate with the switch; create with the command below. Must match config on server!
Verify with sh users.
config) snmp-server user [user-name] [group name] v3 auth [md5|sha] [auth pass] priv [des|3des|aes(#)] [priv pass] (access
[acl#])

Users are nested into groups, which set the security policies (not passwords/keys) for users that are
assigned to the group. If using a view, it is assigned here as well. Verify with sh snmp group.
config) snmp-server group [group name] v3 [noauth|auth|priv] (read [view]) (write [view]) (notify [view]) (access [acl#])

Views define what OIDs youre able to see/access. Optional, if unused, full access. Verify with sh snmp
view.
config) snmp-server view [view name] [oid tree] [included | excluded]

Notification Config: If the agent is configured to send traps or informs, verify that they are enabled in the
host command, with the correct IP, SNMP version, security, and type (default is traps). Verify with sh
snmp host.
config) snmp-server host [ip] (informs) version [1|2|3] [noauth|auth|priv] [username] (trap-type)

Wrong Security Level: The security level set in the group, user, and host commands must match what is
used on the server.

noauth

no packet authentication or encryption.

auth

packets are authenticated but not encrypted.

privpackets are authenticated and encrypted !!! only if ios is cryptographic.

Wrong Hash/Encryption/Password: When using authentication and/or encryption, both the algorithm
and password have to match between the device and the server.
Wrong OIDs: The view identifies the objects within the MIB that the server will be able to access. Ensure
they are accurate. Prevent indexes from shuffling with the snmp-server ifindex persist command.
IP SLA: Used to measure network performance and test availability by generating a continuous, reliable
probe (simulated traffic) in a predictable manner. Can measure packet loss, one-way latency, response
time, jitter, network resource availability, application performance, server response times, and voice
quality. A source is required but a responder is optional. Responders are used to gather more accurate
statistics for services that are not offered by any specific destination device, such as jitter. A responder
can reply with more accurate measurements taking into account its own processing time of a probe.
Verify that you are using the correct operation, the destination IP is correct and reachable, the source IP is
reachable from the destination, necessary ports are not blocked, the SLA probe is started, and if a
responder is required, it is configured. Use sh ip sla application to verify supported operation types as
well as the number of configured and active entries. Use sh ip sla config to verify the specific
configuration of a probe including the timeout, source/destination addresses/ports, TOS value, packet
size/interval, and the schedule. Results can be viewed with sh ip sla statistics to see the type, time last
started, latest return code, various values, and a count of success/failures. Responders can be verified
with sh ip sla responder to see the control port number, number of probes received, number of errors,
and recent sources of probes. Debugging can be done with debug ip sla trace [#] to see the operation
running.
Object Tracking: Enables you to dynamically control what will occur if the result of a tracking object is
up/down. For example, it can be attached to a static route (ip route [ip][mask] [next-hop] track [#]) to
determine if it will be placed in the routing table. Also, FHRPs can use them to change priority values.
Object tracking can track IP routes, IP SLA instances, interfaces, and groups of objects. Verify with sh
track (#).
SPAN: Enables you to take ingress/egress frames on a switchport, copy them, and send them to another
port. The source can be: one or more physical switch ports on the same, or a different, VLAN; trunk ports;
ports that are a member of an EtherChannel; an entire port-channel interface; or an entire VLAN (VSPAN).
Cannot monitor SVIs nor mix source types. If monitoring multiple ports, repeat the source command, or
use - or , for a list. Source traffic is never affected, but if source and dest. ports operate at different
speeds, some destination traffic may be dropped. Different SPAN sessions cannot share a common
destination, only 1 destination per session. Session numbers must be unique. Session source &
destination numbers must match.
Verify that the source/destination session numbers match, the source interface/VLAN and destination
interfaces are correct, the direction is correct (both by default), and interfaces are up/up. Verify with sh
run | s monitor and sh monitor (detail). Verify the destination interface with sh interface status, which will
display monitoring.
config) monitor session [session #] source [interface (fx/x) | vlan (#)] (rx | tx | both) !!! both is def.
config) monitor session [session #] destination interface [fx/x] (encap. replicate) (ingress)
config) no monitor session [ (#) | range (range) | local | all ] !!! to delete.
sh monitor (session [ (#) | all | local | remote | range (list) ] (detail) !!! sh run for tshooting too.

Remote Span (RSPAN): A SPAN session split across two independent switches; mirrored data is
transported over a special purpose RSPAN VLAN between switches and/or intermediate switches
(provided any intermediate switches are RSPAN enabled/capable).
RSPAN VLANs have MAC address learning disabled to prevent any intermediate switches from forwarding
packets to their real dest. Switches flood RSPAN packets out all ports belonging to the RSPAN VLAN. Limit
RSPAN VLAN to appropriate links. RSPAN must allow STP to prevent loops; as a result, BPDUs cannot be
monitored. Create one RSPAN VLAN per RSPAN session. Do not allow any normal hosts to join. VTP will
duplicate an RSPAN VLAN. If VTP is not being used, create the RSPAN VLAN on each intermediate switch
and add to trunks. VTP will prune unnecessary links.

vlan) remote-span

Configure source AND dest on BOTH end points. On the mirroring side, use a source [ interface or VLAN ]
and a destination [remote VLAN]. On the receiving end, use a source [remote VLAN] and a destination
[interface].
config) monitor session [session #] destination remote vlan [rspan-vlan] (ingress) (reflector-port [fx/x])
config) monitor session [session #] source remote vlan [rspan-vlan]

Reflector Port: Some switches need to sacrifice a ports ASIC to perform remote mirroring. Appended to
destination command.
Verify that the source/destination numbers match locally, they do not have to match the remote switch.
The RPSAN VLAN must be configured and identified as remote-span, and added to trunk links. STP cannot
be blocking the RSPAN VLAN. Verify with the same commands as above. Verify the RSPAN VLAN with sh
vlan remote-span.

Management Access
Console: Used when there is physical access to the device, or through an access server.
COM Port: Ensure that on the terminal program, the correct COM port is selected, usually the last one.
Trial-and-error.
Cable and Drivers: Newer devices use a mini USB port, requiring drivers. Older devices use a serial to RJ45 rollover console cable.
Line Password: If a line password is being used, the login command needs to be configured.
Local Username: If local auth. is used, a user/pass must exist in the local database and the login local
command is needed.
AAA Server: If AAA auth. is used, a method list needs to be defined with login authentication [default |
(list name) ].
vty: Supports Telnet and SSH for remote access.
Telnet: Not recommended because all traffic is sent in plain text.
IP Reachable: Ensure the remote device is reachable with a ping.
Correct Transport Protocol: By default, Telnet and SSH are allowed. The transport input command can
change what protocols are allowed. Verify with sh line vty [#] | in Allowed or sh run | s vty.
User Credentials: By default, the login command tells the line to prompt the user for a password. To use
the local database use login local. To use AAA use login authentication [default | (list name) ].
Password: If using the default simple login, a password is required on the line. If none is set, a connecting
user will get the message Password required, but none set. If using login local or login authentication,
you will be prompted for a user/pass. If there is none in the database, the login will fail.
Access-Class: Access can be filtered with the access-class [#] in command. An explicit deny any at the
end can keep track of the number of denied remote access attempts (add log to generate a syslog
message with the IP address). Log message will display as %SEC-6-IPACCESSLOGS: list [#] denied [IP]
1 packet.
ACL: Ensure there is no ACL along the path blocking port 23 (telnet).
vty Lines: By default, there are 5 vty lines numbered 0-4. Some devices may have more. If all lines have
established connections, a new connection cannot be made. Denied users will get the Password
required, but none set message. sh users will list active connections. You can manually clear a line
with the clear line [line #] command.
SSH: Recommended, packets will be encrypted. Verify current SSH sessions with sh ssh: lists version,
encryption, hash, and user name. Same issues as Telnet, in addition:
Version: By default, versions 1 and 2 are enabled. The command ip ssh version [1|2] can manually set
one. To verify, use sh ip ssh. Version 1.99 indicates both versions 1 and 2. The error message
Connection to [IP] aborted: error status 0 usually indicates that the remote device does not use
SSHv2.

Login: The login command will not work since SSH requires a user/pass. Either use login local or login auth
for AAA.
Key: SSHv2 uses an RSA key size of 768 or greater. If a smaller key was used with SSHv1, or you
accidentally generated a key size less than 768, SSHv2 connections wont be allowed. You will need to
create a new key with crypto key generate rsa modulus [#]. Requires you to set the ip domain-name
[#]. Verify key with sh ip ssh.
ACL: SSH uses port 22, ensure no ACLs are blocking it along the path.
Password Encryption: By default, all passwords are stored in clear text. They can be encrypted with
three levels of encryption:
0 clear text

username [name] password 0 [pass].

4 (sha 256)

username [name] secret [pass]. strongest.

5 (md5)

username [name] secret 5 [hash]. paste in actual md5 hash for password.

7 type-7

username [name] password 7 [pass]. also, service password-encryption. weakest.

AAA: Authentication, Authorization, and Accounting.

Enable: AAA is disabled by default, enable with aaa new-model. Immediately, local authentication is
applied to all lines, except the console. Once activated, lines will no longer have the login local option.
Ensure there is a user/pass in the local database or you wont be able to access the device.
Local Database: By default, the local database is used, if it is empty, authentication will fail. If using an
AAA server, it is a good practice to configure a user/pass in the local database for fallback incase the
AAA server is unavailable.
Method List: Defines what methods of authentication will be used, and in what order. When no method
list exists, the vty lines use the local database by default. Successive methods are only used as a
failover, not upon denial.
config) [radius|tacacs]-server host [hostname | ip] (key [0|7] [string]) !!! to define a server.
config) aaa authentication login [ default | (name) ] [method1] (method2)... !!! define method list.
group [ tacacs+ | radius | (name) ]: use servers of that type or in named group, in order configured.
local: uses local user database.
local-case: same as above, but case-sensitive.
line: line passwords.
none: no authorization, always succeeds.

To Apply:
line) login authentication [ default | (list-name) ] !!! apply to lines.

By default, many devices use ports 1645 and 1646 for RADIUS and port 49 for TACACS. RADIUS ports were
changed and since use 1812 and 1813. Verify they are not being blocked by an ACL.
debug aaa authentication !!! to verify the authentication process.
debug radius authentication !!! view the radius authentication.
debug aaa protocol local !!! view the local authentication.