ICND2 Exam Topics Notes

NOTE: I DO NOT OWN THE IMAGES INCLUDED IN THESE NOTES

1.0 LAN Switching Technologies
1.1 Configure, verify, and troubleshoot VLANs (normal/extended range) spanning multiple
switches
- A LAN (VLAN) includes all devices in the same broadcast domain
- VLAN trunking uses VLAN tagging:
802.1Q ISL (Inter-Switch Link)
- IEEE standard - Cisco-proprietary
- Inserts an extra 4-byte 802.1Q VLAN header - Inserts an extra 26-byte ISL header and a
and changes the CRC value 4-byte CRC trailer
- MTU is 1522 bytes - MTU is 1548 bytes
- Supports a maximum of 4096 VLANs - Supports a maximum of 1000 VLANs
- Supports native VLANs, in which 802.1Q
does not tag the frames in the native VLAN
1.1.a Access ports (data and voice)
Data
Configuration:
vlan vlan-id creates the VLAN and moves the user into VLAN configuration mode
name vlan-name sets a name for the VLAN (default VLANXXXX [XXXX= VLAN ID])
switchport access vlan vlan-id specifies the VLAN number associated with the interface
(instantly creates the VLAN if not created already)
switchport mode access makes the port always operate in access mode (nontrunking)
YOU MUST exit VLAN configuration mode for the VLAN to be created, and all changes to
be in effect
- Nondeletable/reserved VLAN: 0, 1 (default VLAN), 1002 - 1005, 4095
Voice
Configuration:
switchport mode access configures the port to always operate in access mode
switchport voice vlan vlan-id puts voice traffic in the voice VLAN (802.1Q trunk link)
- CDP must be enabled
- PortFast is enabled by default
- 802.1x authentication can be enabled
- Voice VLANs are typically tagged with an 802.1Q header
- switchport voice vlan dot1p - data is in native VLAN and voice is tagged as VLAN 0
(802.1Q trunk link)
- switchport voice vlan none - data & voice in the access VLAN (access port)
- switchport voice vlan untagged - data & voice in native VLAN (802.1Q trunk link)
Verification:
- show vlan brief displays VLAN, name, status, and ports assigned to the VLAN (does NOT
show trunk ports)
- show interface switchport lists data and voice VLAN IDs
- show interface trunk lists the data and voice VLAN IDS
1.1.b Default VLAN
1.2 Configure, verify, and troubleshoot interswitch connectivity
1.2.a Add and remove VLANs on a trunk
 - switchport trunk allowed {add | except | remove} vlan vlan-id - adds or removes
VLAN/s in the trunk's allowed list
- switchport trunk native vlan vlan-id - configures the native VLAN for the trunk
- Allowed VLAN lists on both ends of the trunk should match (show interface trunk)
- show vlan [brief] - lists each VLAN and all interfaces assigned to that VLAN (no trunks)
- show vlan id vlan-id - lists both access and trunk ports in the VLAN
- show interface switchport - lists the interface's access and voice VLAN, with the
configured and operational mode & encapsulation
- show mac address-table - lists the source MAC address with the access VLAN
- show vlan will list all known VLANs, including VTP, but show running-config may not
- show interfaces trunk - lists the VLANs whose traffic will be forwarded over the trunk:
- Existing and active VLANs
- VLANs not VTP-pruned from the trunk
- VLANs in which the trunk is in an STP forwarding state in that VLAN
1.2.b DTP and VTP (v1&v2)
DTP
Configuration:
switchport mode {access | trunk | dynamic {auto | desirable}} specifies the
administrative trunking mode:
Access - always act as an access (nontrunking) port
Trunk - always act as a trunk port
Dynamic desirable: initiates negotiation messages; if the other end is dynamic auto or
static trunk, trunking succeeds
Dynamic auto: passively waits to receive negotiation messages; if the other end is
dynamic desirable or static trunk, trunking succeeds
switchport trunk encapsulation {dot1q | isl | negotiate} specifies the administrative
encapsulation type of 802.1Q, ISL or let DTP negotiate
Verification:
show interfaces switchport lists the administrative/operation mode and trunking
encapsulation, with native VLAN and voice VLAN information
show interfaces trunk lists all currently operation trunks, native/allowed VLANs etc.
Troubleshooting:
- Static trunk interface can negotiate except when configured with switchport
nonegotiate
VTP
- VTP is Cisco-proprietary
- VTP modes:
Server Client Transparent Off
Can configure VLANs Cannot configure Can configure both Can configure both
in the standard range VLANs standard and standard and
only (VLAN 1 - 1005) extended-range extended-range
VLANs (1 - 4094) VLANs (1 - 4094)
Can learn, or Can learn, or Does not Does not
advertise VLANs advertise VLANs send/receive VTP send/receive VTP
messages but messages and does
forwards them not forward them
Stores vtp Stores vtp commands Stores standard
commands and VLAN and VLAN range VLANs in
configurations in the configurations in the both vlan.dat and
vlan.dat file in flash vlan.dat file in flash running-config, but
(access VLAN (access VLAN extended. range
assignments and assignments and VLANs are always
VLAN shutdown are VLAN shutdown are stored in the
in running-config) in running-config) running-config
VTP advertisement process:
1. Raise the local database revision number for each change to the VLAN database
2. For each trunk, send VTP messages, and listen to receive them
3. If the VTP parameters match, attempt to synchronise the VLAN configuration
databases between the two switches
- VTP servers and clients send periodic VTP summary advertisements every 5 minutes
- Requirements for VTP to work between two switches:
- Link between two switches must be operating as a VLAN trunk (ISL or 802.1Q)
- The two switches' CASE-SENSITIVE VTP domain name must match
- If configured on at least one switch, both switches must have the same CASE-SENSITIVE
VTP password
- VTPv1 and VTPv2 can be used together in a network, but NOT VTPv3
- VTP transparent mode switches still need the version number
- VTP pruning removes VLANs that switches do not have access ports in, from the
appropriate trunks (does not flood frames into VLAN)
- Summary advertisements: sent every 5 minutes by default and does not contain any
VLAN information
- Advertisement request: used when switch asks for a subset advertisement when the
summary advertisement has a higher revision number than itself
- Subset advertisements: sent when VLAN configuration database has changed
Configuration:
- vtp mode {server | client | transparent | off} - configures the switch to be a server or
client, or be transparent or disable VTP
- vtp domain domain-name - configures the case-sensitive VTP domain name
- vtp password pass-value - configures the case-sensitive password
- vtp pruning - enables pruning domain-wide (only servers need the command)
- vtp version {1 | 2} - configures the VTP version the local switch will run
- By default, switches are in server mode and VTP does not work because the VTP domain
is not set (NULL)
Verification:
- show vtp status - lists the revision number, version, mode, domain name, pruning
status, MD5 digest (domain name + password) etc.
- show vtp status lists the IP address of the database from which they learned from and
the timestamp
- show vtp password - lists the clear-text password (hashed in VTPv3)
- show vlan [brief] - lists all the learned/configured VLANs on a switch
Troubleshooting:
- VTP can only synchronise if:
- At least one switch is in server mode
 - At least one operational trunk exists between the two switches
- Both switches have the same, case-sensitive VTP domain name
- Both switches have the same, case-sensitive VTP password
- Both switches have the same MD5 digest (confirms same domain name and password)
(- VTP pruning configuration mismatch does not prevent the synchronisation process)
(- VTP version does not have to match [VTPv1 and VTPv2 only])
- VTP does not advertise the administrative status of a VLAN, resulting in VLAN shut down
on one switch and active on another
- VTP client immediately rejects the command to create a standard range VLAN
- VTP client or server waits until the user exits VLAN config mode when creating an
extended range VLAN before rejecting the command
- VTP wipeout: a new switch with a higher revision number is added and all VLANs are
removed (or altered)
- Configure switch for VTP transparent mode and back to normal mode or erase the new
switch's vlan.dat files and reload the switch to reset the revision number
- Preventing trunking, setting a VTP password, using transparent mode, using a different
domain name or disabling VTP reduces/removes the risk of an attack or VTP wipeout
1.3 Configure, verify, and troubleshoot STP protocols
- Without STP: broadcast storms, MAC table instabilities, multiple frame transmissions
STP States
- Disabled: failed or administratively shutdown interfaces
- Blocking: interface does not forward frames, and does not learn MAC addresses
- Listening: interface does not forward frames and removes MAC table entries for which
no frames were received from the MAC address during the period
- Learning: interface does not forward frames, but learns MAC addresses
- Forwarding: interface forwards frames and learns MAC addresses
STP BPDUs
- 8-byte BID:
- 2-byte Priority field (4-bit Priority + 12-bit System Extension ID [VLAN ID]) +
- 6-byte System ID (burned-in MAC address)
- Hello BPDU contains:
- Root bridge ID: what the sender believes is the root switch
- Sender's BID
- Sender's root cost: STP cost between this switch and current root
- Timer values: includes Hello timer, MaxAge timer, and forward delay timer
STP Root Bridge Election
1. Lowest priority (first 2 bytes of BID)
2. If that ties, lowest System ID value (last 6 bytes of BID)
- Switch believes that it is the root until it hears a superior Hello BPDU, by when they
change to believe the sender of the superior Hello BPDU as the root bridge
STP Root Port Selection
1. Lowest root cost
2. Lowest neighbour BID
3. Lowest neighbour port priority (first 4 bits of port ID)
4. Lowest neighbour port number (last 12 bits of port ID)
- Root cost is the port cost of every outbound interface in the path for the root bridge
- 1 root port per nonroot switch; root port is in forwarding state
 STP Designated Port Selection
1. Lowest interface root cost
2. Lowest local BID
3. Lowest neighbour port priority (first 4 bits of port ID)
4. Lowest neighbour port number (last 12 bits of port ID)
- One designated port per LAN segment; DPs are put into forwarding state
- All other ports are placed into blocking state
STP Topology Changes
- Default port cost:

- Port becomes a DP if there are no STP-speaking devices on the LAN segment

- When the STP topology is stable:
1. Root bridge floods a Hello BPDU, with a root cost of 0
2. Nonroot switches change the Hello to list their own BID as the sender's BID, and lists
their own root cost and forwards the Hello out all DPs
- Hello timer: time period between Hellos created by the root (default: 2 seconds)
- MaxAge timer: how long a switch should wait, after ceasing to hear Hellos, before trying
to change the STP topology (default: 10 x Hello [20 seconds])
- Forward delay timer: how long the port stays in listening and learning state (default: 15
seconds [total: 30 seconds from blocking to forwarding])
- When MaxAge timer expires, switch makes all its STP choices again (re-evaluates root
switch, and if nonroot, chooses an RP and DP/s
- STP default convergence time: 50 seconds => slow convergence
RSTP Port Roles
- RSTP has a shorter convergence time of less than 10 seconds
- Alternate port: replaces the root port when the root port fails
- Backup port: replaces a designated port when a designated port fails
- When root port fails:
1. Both switches confirm that the other switch will use its alternate port as the root port
2. The switch flushes the required MAC table entries (faster than STP waiting for time out)
3. Switch transitions the root port to the disabled state and alternate port to root port
4. Switch transitions the new root port to a forwarding state immediately
RSTP Port States
- RSTP does not have a listening state and combines STP disabled and blocking state to
RSTP discarding state
- Point-to-point: ports that connect two switches and are not at the edge of the network
- Point-to-point edge: ports that connect to a single endpoint device at the edge
- Shared: ports connected to a hub and sharing a single collision domain
Troubleshooting:
- Finding the root switch:
- Rule out all switches with root ports - show spanning-tree, show spanning-tree root
- show spanning-tree lists "This switch is the root" if the local switch is the root bridge
- show spanning-tree root lists an empty RP column if local switch is the root
 - Check the switch that the root port connects to
- Finding the root cost:
- show spanning-tree and show spanning-tree root lists the root port and root cost
- Calculate switch's root cost using default values/spanning-tree cost effects
- Root cost is based on the CURRENT operational speed (watch for negotiation effects)
- Finding the designated port: show spanning-tree lists the port roles for interfaces
1.3.a STP mode (PVST+ and RPVST+)
Configuration:
- spanning-tree mode pvst (Cisco default, makes PVST+ the STP mode)
- spanning-tree mode rapid-pvst (makes RPVST+ the STP mode)
- spanning-tree mode mst (makes MST the STP mode)
- PVST+ allows different instances of STP for each VLAN => STP load balancing
Verification:
- show spanning-tree vlan vlan-id - lists "Spanning tree enabled protocol ieee OR rstp OR
mst" and shows the RSTP port roles
- show spanning-tree vlan vlan-id lists alternate and backup ports and RSTP port types in
the output even when using STP and not RSTP
- show spanning-tree vlan vlan-id bridge - lists "ieee", "rstp" or "mst" in Protocol field
- show spanning-tree vlan vlan-id interface int-id state shows a port's state
1.3.b STP root bridge selection
Configuration:
- spanning-tree vlan vlan-id priority x - configures the Priority field of the BID (has to be a
multiple of 4096; base priority)
- spanning-tree vlan vlan-id root primary - configures the local switch to attempt to be
the root switch:
- If the current root has a base priority higher than 24576, the local switch uses a base
priority of 24576
- If the current root's base priority is 24576 or lower, the local switch sets the base
priority to the highest number that still results in the local switch becoming root
- spanning-tree vlan vlan-id root secondary - configures the local switch to attempt to be
the switch that will take over when the root switch fails:
- Sets the switch's base priority to 28672 regardless of the root switch's current priority
value
- spanning-tree [vlan vlan-id] cost x - configures the STP port cost:
- Needs the vlan keyword for per-VLAN configuration on trunk interfaces
- spanning-tree vlan vlan-id port-priority x - sets the port priority for the interface
Verification:
- show spanning-tree vlan vlan-id - lists the root bridge BID, timers, root port (if on
nonroot switch), local BID, local timer, interface roles/states, port costs, neighbour port
ID and port type
- show spanning-tree [vlan vlan-id] root - lists the root's BID with the root cost and root
port for each/specified VLAN
- show spanning-tree [vlan vlan-id] bridge - lists the local switch's BID and STP mode
- debug spanning-tree events - switch issues debug messages whenever STP performs
changes to an interface's role/state
1.4 Configure, verify, and troubleshoot STP-related optional features
Verification:
 - show spanning-tree interface int-id detail lists PortFast and BPDU Guard status if they
are enabled
- show spanning-tree summary - shows the global settings for PortFast and BDPU Guard,
as well as the STP mode
1.4.a PortFast
- Allows port to immediately transition from blocking to forwarding state (especially at
connections to end-user devices where there is no risk of creating loops)
- RSTP point-to-point edge ports = ports that have PortFast enabled
Configuration:
- spanning-tree portfast - enables PortFast on an interface (IOS lists long warning;
interface must be in nontrunking mode)
- spanning-tree portfast default - enables PortFast globally by default
Verification:
- show spanning-tree interface int-id portfast - shows the PortFast enabled status

1.4.b BPDU Guard

- BPDU guard prevents attackers becoming the root switch and harming the network
- BPDU guard disables a port (err-disabled state) if any BPDUs are received on them
- BPDU guard should NEVER be enabled on a port that connects to another switch
- BPDU guard should be used with PortFast to prevent loops if a switch is connected
Configuration:
- spanning-tree bpduguard {enable | disable} - enables/disables BPDU guard on an
interface
- spanning-tree portfast bpduguard default - enables BPDU guard globally by default
1.5. Configure, verify, and troubleshoot (Layer 2/Layer 3) Etherchannel
- If one link fails and at least one other link is up, STP convergence does not occur
- Use the same channel group number on the same switch, but neighbouring switch may
have different channel group number settings
Verification:
- show etherchannel channel-group summary - lists the channel group, port channel and
ports in that channel group ('D' = channel is down, 'I' = physical interface is working
independently from the PortChannel
- show etherchannel channel-group port-channel - lists the negotiation protocol used
Troubleshooting:
- Do NOT use on keyword on a neighbouring switch if PAgP or LACP is in use on the other
switch
- channel-group commands for all physical interfaces must use the same channel-group
number on the same switch (can be different on different switches)
- Configuring on keyword on one switch and LACP or PAgP on other results in only one
switch using EtherChannel
- Configuring auto or passive keyword on both switches results in incompletion of
negotiation
- Configuring LACP on one switch and PAgP on the other results in a failed negotiation but
working physical interfaces
- New physical interfaces and neighbour switches must match:
- Speed
- Duplex
 - Operational access or trunking state (all access or all trunk)
- If an access port, the access VLAN
- If a trunk port, the allowed VLAN list and native VLAN
- STP interface settings (does not have to match neighbour switch)
- PAgP, LACP or CDP are used to verify the settings on the neighbouring switch
- If settings are different, PortChannel interface is placed in err-disabled state (same for
physical interfaces)
Layer 3 EtherChannel:
- Physical port: channel-group no. mode on - adds the port into the channel
- no switchport - makes each physical port a routed port
- PortChannel interface: interface port-channel no. - enters the PortChannel interface
- no switchport - makes the PortChannel interface act as a routed port (IOS may have
already added this command)
- ip address addr mask - configures the IP address and mask and enables IP
- show etherchannel summary - lists 'RU' for the PortChannel (Layer 3, in use)
- Physical and PortChannel interface must be configured with no switchport
- Physical ports in the channel must use the same speed and duplex
1.5.a Static
Configuration:
- channel-group no. mode on - statically enables EtherChannel for a channel group
1.5.b PAGP
Configuration:
- channel-group no. mode {desirable | auto} - configures PAgP to negotiate the
EtherChannel (desirable - auto, desirable - desirable)
1.5.c LACP
Configuration:
- channel-group no. mode {active | passive} - configures LACP to negotiate the
EtherChannel (active - passive, active - active)
1.6 Describe benefits of switch stacking and chassis aggregation
Switch Stacking
- Mainly used by access layer (and distribution layer) switches
- Logical switch has a single management plane, control plane and data plane
- Switches are connected by short, stacking cables in a ring
- One physical switch is selected as stack master, to control the rest of the switches
- Stack master does matching of MAC address table, but outgoing ports can be at a
different physical switch
- FlexStack: 2960-S & 2960-X, max 10 Gbps, max 4 switches in a stack
- FlexStack Plus: 2960-X & 2960-XR, max 20 Gbps, max 8 switches in a stack
Chassis Aggregation
- Mainly used in distribution and core layer switches
- Uses Ethernet interfaces to aggregate 2 switches
- VSS between aggregated switches and MEC to form EtherChannels from other switch to
both switches with two links
- Active/standby control plane: single control plane
- Active/active data plane: uses supervisors on both switches by synchronising MAC and
routing tables
- Single switch management: management protocols on the active switch get synchronised
 with the standby switch
1.7 Describe common access layer threat mitigation techniques
1.7.a 802.1x
- 802.1x switch filters all incoming traffic except 802.1x traffic until user is authenticated
- Supplicant: user that supplies the username and password
- Authenticator: switch that relays the authentication request to the authentication server
- Authentication server: server that matches the username/password and returns if user
is authenticated or not (AAA server)
- EAPoL: supplicant <=> authenticator (Ethernet + EAP header)
- EAP: authenticator <=> authentication server (UDP/TCP + RADIUS/TACACS+ + EAP
header)
1.7.b DHCP snooping
- DHCP snooping is a Layer 2 feature, not a Layer 3 feature
- Trusted ports: allow both server and client DHCP messages
- Untrusted ports: allow client DHCP messages but not server messages (discarded) (all
ports are untrusted by default)
- Prevents MITM attacks using spurious DHCP servers
- Switch keeps state information about DHCP binding table and message is discarded
when switch detects conflicts => prevents spoofing
- DHCP snooping prevents DoS attack by rate limiting the number of incoming DHCP
messages on untrusted interfaces
1.7.c Nondefault native VLAN

2.0 Routing Technologies

2.1 Configure, verify, and troubleshoot Inter-VLAN routing
2.1.a Router on a stick
- Routers assign subinterfaces with different IP addresses in different subnets to each
VLAN
- Switch: switchport mode trunk
- Router: interface type number.subint - creates and enters a subinterface
- encapsulation dot1q vlan-id [native] - enables 802.1Q and associates one specific
VLAN, and optionally makes that VLAN the native VLAN for the interface
- ip address addr mask - configures the IP settings (address and mask)
- ip address on the physical interface without encapsulation makes the physical interface
use the native VLAN
- show ip route - lists the local route of the subinterface and connected routes on it
- show vlans - lists which interfaces use which VLANs, the native VLAN, interface IP
address, packet statistics etc.
- Make sure each non-native VLAN on the router has encapsulation dot1q vlan-id and
have the correct IP address and mask
- Make sure the switch is trunking, has the VLANs in the allowed list, not VTP pruned, and
not STP blocked and has the same native VLANs
2.1.b SVI
- VLAN interfaces (SVIs) can use multiple physical interfaces
1. sdm prefer lanbase-routing - changes the ASIC settings to make space for IPv4 routes
reload - allows the new sdm prefer setting to take effect
ip routing - enables the IPv4 routing function on IOS
 2. interface vlan vlan-id - creates a Layer 3 VLAN interface
ip address addr mask - configure an IP address and mask, enabling IPv4 routing on the
interface
- SVI is up/down by default, until at least one switch port is in the VLAN and up
- show ip route lists the connected and local routes of VLAN interfaces
- VLAN must be defined on the switch explicitly or learned with VTP
- Layer 3 switch routed ports:
- Use routed ports for subnets with one physical interface and SVI for subnets with
multiple physical interfaces connected to it
- no switchport - enables a switch interface to be routed (switchport by default)
- show interface status - lists the word "routed" under the access VLAN column
2.2 Compare and contrast distance vector and link-state routing protocols
- Distance vector (Bellman-Ford): uses hop counts as the metric
- Slower convergence time
- RIP sends full routing table updates every 30 seconds by default
- Split horizon: tells routers to not advertise routes that lists that same interface as the
outgoing in an update sent out an interface
- Route poisoning: router advertises a failed route with a special metric of infinity (RIP: 32,
OSPF: 224 - 1, EIGRP: 232 - 1)
- Poison reverse: router marks the failed route and sends it out the interface that the
route was learnt from (defies split horizon)
- Link-state (Dijkstra): advertises the state of each link in a topology to every router
- Uses cost as the metric
- Faster convergence, but extra CPU and memory requirements and extra planning
- Advanced distance vector: uses a composite metric of bandwidth and delay
- Metric calculated based on the route's slowest link and the cumulative delay (+ interface
load, interface reliability and MTU)
- Reduced planning and CPU/memory usage
- EIGRP sends a full update once, and then partial update messages when requested
- Classless routing protocol: supports VLSM and manual route summarisation by
advertising subnet masks
- Classful routing protocol: does not support VLSM since it doesn't send subnet masks in
the routing update messages
2.3 Compare and contrast interior and exterior routing protocols
- IGP: a routing protocol that was designed and intended for use inside a single AS (e.g. RIP,
OSPF, EIGRP)
- EGP: a routing protocol that was designed and intended for use between different ASes
(e.g. BGP)
- AS is a network that is under the administrative control of a single organisation
- AS is assigned an ASN which is allocated by IANA and RIRs
2.4 Configure, verify, and troubleshoot single area and multiarea OSPFv2 for IPv4 (excluding
authentication, filtering, manual summarisation, redistribution, stub, virtual-link, and LSAs)
- Link-State Advertisements (LSA): a section of the topology information
- Link-State Database (LSDB): the collection of all known LSAs
- Routers reflood LSAs when some information changes or the LSA's aging timer expires
(default: 30 minutes)
- Dijkstra (SPF) algorithm is applied to the LSA for best route selection
- OSPF neighbour requirements:
- Both routers connected to the same subnet
- Both routers must be in the same OSPF area
- Both routers must have unique RIDs
- Both routers must have the same authentication (if configured)
- Both routers' Hello and Dead interval must match (default: 10, 40 seconds)
- Both routers must have the stub area flag
- RID selection process:
1. If there is one, use the configured manual value
2. If not, use the highest 'up' loopback interface IPv4 address
3. If no loopbacks interfaces, use the highest 'up' non-loopback interface IPv4 address
- Hello message: follows the IP packet header (protocol 89) and is sent to multicast address
224.0.0.5
- OSPF neighbour formation process:
1. DOWN ==> [Hello w/ R1's RID, and no neighbours] ==> DOWN
2. DOWN <== [Hello w/ R2's RID, and R1 as neighbour] <== INIT
3. (INIT ->) 2-WAY ==> [Hello with R2 as neighbour] ==> (INIT ->) 2-WAY
- 2-way routers have passed all configuration requirements and are ready to exchange
- OSPF LSA exchange process:
1. EXSTART <==> [Slave/master election, sequence number negotiation] <==> EXSTART
2. EXCHANGE <==> [DBD and LSR] <==> EXCHANGE
3. LOADING <==> [LSU and LSAck] <==> LOADING
4. FULL === [LSDBs are fully synchronised] === FULL
- Master election: highest priority -> highest RID (usually DR)
- DR: router with the highest OSPF priority (default: 1) or highest RID; exchanges LSAs with
routers and then distributes the LSAs so every LSDB on the segment is updated
- BDR: router that is second-in-line to the DR
- DROthers: have full neighbour relationships with DR and BDR (fully adjacent)
- Have 2-way relationships with other DROthers (adjacent)
- OSPF best route selection:
- OSPF cost: the sum of the OSPF interface costs for all outgoing interfaces in the route
- Cost of the interface in the destination subnet is also added
- Cost calculation: {reference bandwidth} / {interface bandwidth}
- Default reference bandwidth: 100000 Kbps (100 Mbps)
- Default interface cost:
- T1 serial interface (and all serial interfaces with default bandwidth of 1544 Kbps) = 64
- Ethernet (10 Mbps) = 10
FastEthernet (100 Mbps) or faster = 1
- Multi-area OSPF design:
- Smaller LSDBs => less memory required
- Less LSAs that SPF has to process => less processing power required
- Smaller routing tables using route summarisation => less route lookup delay
- Rules for OSPF areas:
- All interfaces connected to the same subnet should be in the same area
- An area should be contiguous
- Routers can be internal to an area, or be ABRs
- All nonbackbone areas must connect to the backbone area by having at least one ABR
 physically or logically to both the backbone and the nonbackbone area
- Area Border Router (ABR): an OSPF router with interfaces connected to both the
backbone area and to at least one other area
- Backbone router: router connected to the backbone area (includes ABRs)
- Internal router: router in one nonbackbone area
- Area: a set of routers and links that shares the same detailed LSDB information, but not
with routers in other areas
- Backbone area: a special OSPF area to which all other areas must connect - area 0
- Intra-area route: a route to a subnet inside the same area as the router
- Interarea route: a route to a subnet in an area of which the router is not a part
- Autonomous System Boundary Router (ASBR): connects to other non-OSPF networks
- LSAs coming from other areas include a very brief summary information
Configuration:
- router ospf PID - creates an OSPF process and enters OSPF configuration mode for the
process
- router-id RID - manually defines the RID (if not defined, use loopback or nonloopback
interface IPv4 address) (OSPF process needs to be cleared or router reloaded)
- clear ip ospf process - OSPF process is restarted
- network net-no. wildcard area area-id - enables OSPFv2 on any interface matched by the
configured address and for the listed area
- passive-interface {int-id |default} - configures an interface to be passive or make all
interfaces be passive by default
- Passive interfaces don't send OSPF Hellos and ignore received Hellos and don't form
neighbour relationships over the interface but OSPF still advertises the subnet connected
to the interface
- Multi-area configuration: ABR has interfaces in different areas
- default-information originate - makes a router advertise a default route using OSPF to
remote routers (if there is a default route in the routing table) (used for e.g. Internet)
- default-information originate always - router always advertises the default route, no
matter whether the router's default route is working or not
- ip ospf cost x - directly changes the interface cost
- bandwidth bw-kbps - changes the interface bandwidth (in Kbps)
- auto-cost reference bandwidth bw-mbps - changes the reference bandwidth (in Mbps)
- maximum-path no. - sets the number of maximum equal-cost routes in the routing
table (default: 4)
- New-style configuration: ip ospf PID area area-id - enables OSPF on the interface for a
process and area
Verification:
- show ip ospf interface - lists the PID, interface cost, DR/BDR connected to network,
timers, neighbour state and shows if configured by network or ip ospf
- show ip ospf interface brief - lists the PID, area, IP address/mask, cost, state and number
of neighbours connected to the interface
- show ip ospf neighbor - lists the neighbour RID and IP address and neighbour state/role
and interface connected to the neighbour
- show ip ospf database - lists the local RID, neighbour router areas and where the routers
were advertised from
- show ip protocols - lists the PID, RID, OSPF-enabled networks, maximum paths, list of
 known OSPF routers, old- or new-style configuration etc.
- show ip ospf - lists the RID, area ID, and local router's role
Troubleshooting:

- show ip protocols - basically relists the network commands

- show ip ospf interface brief - directly shows the area configured for an interface
- Finding DR/BDR: show ip ospf interface [brief] and show ip ospf neighbor
- show ip route lists 'O' for intra-area routes, 'O IA' for interarea routes and 'O*E2' for an
external OSPF-learned default route
- show ip protocols lists "Interfaces Configured Explicitly" for interfaces configured with
new commands and "Routing for Networks" for interfaces configured with the old
commands
- show ip ospf interface lists "Attached via Interface Enable" for interfaces configured with
the new commands and "Attached via Network Statement" for interfaces configured with
the old commands
- Ensure passive-interface does not prevent an interface from enabling
- show ip ospf interface brief lists all OSPF-enabled interfaces (including passive interfaces)
- All show commands that list the passive interfaces list the interfaces regardless of
interface status
- show interface [brief] lists the interface status and area ID which has to match on both
neighbours

- show ip ospf neighbor - lists all neighbours that have met the requirements
- IOS stores network commands in sequence (latter, specific command may be ignored)
- IOS uses area ID in ip ospf rather than network command
- show ip ospf - lists the RID (must match) and PID (doesn't have to match)
- shutdown - brings down neighbour relationships and quits sending Hellos
- MTU mismatch: routers can reach a 2-way state, but if they have different MTU settings,
they fail to exchange their LSDBs (ip mtu size)
Introduction to IPv6
- ipv6 unicast-routing - globally enables IPv6 routing
- ipv6 address or ipv6 enable - enables IPv6 on an interface
- Routers use the next-hop router's link-local IPv6 address
- show ipv6 route address - lists the specific IPv6 route a router would use to send packets
to the specified destination address
 - show ipv6 neighbors - lists the IPv6 replacement for the IPv4 ARP table
- Host IPv6 settings must be correct (ipv6config /all)
- Host can use stateful DHCPv6 with NDP or SLAAC with stateless DHCPv6 and NDP
- ipv6 dhcp relay destination ipv6-addr - defines the DHCP server's IPv6 address
- DHCP relay agents use the outgoing interface to the DHCPv6 server as the source IPv6
address for DHCP relays
- NDP RS and RA must work for SLAAC to work (routers need both ipv6 address and ipv6
unicast-routing)
- Router may have routing protocol issues, router-to-router link issues, incorrect static
routes or there may be a poor subnet design
- Incorrect routes may cause a packet to loop around until its Hop Limit reaches 0
2.5 Configure, verify, and troubleshoot single area and multiarea OSPFv3 for IPv6 (excluding
authentication, filtering, manual summarisation, redistribution, stub, virtual-link, and LSAs)
- OSPFv2 does not communicate with OSPFv3 (separate LSDBs, SPF algorithms etc.)
whether using address families or configured both versions
- Both OSPFv2 and OSPFv3 have many similarities (metric, route exchange, SPF algorithm,
design concepts etc.)
- OSPFv3 has different LSA structures, adds new LSA types and does not care if two
neighbour routers are in different prefixes (new name for Type 3 LSAs: inter-area prefix
LSAs)
- FF02::5 is for all OSPF routers and FF02::6 is for all DR and BDR routers
Configuration:
- ipv6 unicast-routing and ipv6 address - enables IPv6 globally and on interfaces
- ipv6 router ospf PID - creates an OSPFv3 process and enters OSPF config mode
- router-id RID - manually defines the RID (if not configured, use the highest 'up' loopback
interface IPv4 address and then the highest 'up' nonloopback interface IPv4 address)
- clear ipv6 ospf process - needs to be issued before router-id takes effect
- passive-interface int-id - configures OSPFv3 passive interfaces
- ipv6 ospf PID area area-id - enables an interface and specifies which area it belongs to
(interface subcommand)
- Multiarea configuration: interfaces on the same router placed in different areas
- ipv6 ospf cost x - sets the interface cost to a value between 1 - 65535 (interface
subcommand)
- auto-cost reference-bandwidth bw-mbps - defines the reference bandwidth
- bandwidth bw-kbps - defines the interface bandwidth
- maximum-paths no. - defines the maximum number of equal-cost OSPFv3 routes that
can be added to the IPv6 routing table (default: 4)
- default-information originate - advertises a default route with the local router as the
eventual destination if there is a default route in the IPv6 routing table
- shutdown - disables the OSPF routing process
Verification:
- show ipv6 protocols and show ipv6 ospf interface brief- lists brief information about
the OSPFv3 interface information
- show ipv6 ospf interface - lists detailed interface information including timers etc.
- All commands list both passive and nonpassive OSPFv3 interfaces
- debug ipv6 ospf adj - lists log messages for OSPFv3 adjacency events (neighbour states)
- show ipv6 ospf neighbor - lists neighbour RIDs and the local interface states
 - show ipv6 ospf database - lists the different LSAs stored in the LSDB
- show ipv6 ospf - lists the reference bandwidth and the RID
- show ipv6 ospf interface brief - lists the interface cost
- show interfaces - lists the interface bandwidth
Troubleshooting:
- Neighbours must be in the same area (show ipv6 ospf interface brief) but do not need
to be in the same subnet
- Interface should not be made passive (show ipv6 protocols)
- Neighbour requirements (show ipv6 ospf neighbor):
- Matching authentication (show ipv6 ospf interface)
- Matching Hello and Dead timers (show ipv6 ospf interface)
- Unique router IDs (show ipv6 ospf)
- Interface falls to Down state if there is a duplicate RID
- MTU mismatch causes interface to be unable to exchange routes, but allows it to reach
the 2-way state (ipv6 mtu size)
- Check directly connected neighbour relationships if there are missing routes
- Check for broken neighbour relationships in the optimal path or nondefault OSPFv3 cost
settings if there are suboptimal routes
2.6 Configure, verify, and troubleshoot EIGRP for IPv4 (excluding authentication, filtering,
manual summarisation, redistribution, stub)
- Default Ethernet EIGRP Hello timer: 5 seconds; Hold timer: 15 seconds
- Default serial EIGRP Hello timer: 60 seconds; Hold timer: 180 seconds
- EIGRP Hello messages are sent to 224.0.0.10 if multiple router need to be updated;
otherwise, they are sent to the unicast IP address of the neighbour
- Neighbour requirements:
- Matching authentication
- Same configured ASN
- Same subnet
- Matching K-values
- EIGRP does not require neighbouring routers to have the same Hello and Hold timers
- Neighbour formation and route exchange process:
1. R1 <==> [Neighbour Discovery with Hello] <==> R2
2. R1 <==> [Full routing update with RTP] <==> R2
(R1 and R2 keep sending/receiving continuous Hellos)
3. R1 <==> [Partial updates in status change/new information] <==> R2
- K1: Bandwidth (1)
K2: Load (0)
K3: Delay (1)
K4: Reliability (0)
K5: MTU (0)
- EIGRP default metric calculation: ((107 / least-bandwidth) + cumulative-delay) * 256
- Least bandwidth: lowest bandwidth link in the route, in Kbps
- Cumulative delay: sum of all the delay values for all outgoing interfaces in the route, in
tens of microseconds
- show interfaces and show ip eigrp topology lists delay in microseconds
- delay uses delay in tens of microseconds
- Default delay: serial - 20000 usec, Ethernet - 10000 / speed-Mbps
 - All serial interface default to bandwidth of 1544 Kbps
- Feasible distance: the local router's composite metric of the best route to reach a subnet
- Reported distance: the next-hop router's best composite metric for that subnet
- If a nonsuccessor route's RD is less than the FD, the route is a feasible successor route
- EIGRP uses DUAL if there are no FS routes:
- EIGRP query messages sent to working neighbours and receives EIGRP replies,
confirming that the route will not cause a loop
- EIGRP uses Reliable Transport Protocol instead of TCP/UDP to guarantee that the
neighbour received the message
- Autosummarisation summarises the routes into a classful network route
- Autosummarisation in a discontiguous network causes incorrect equal-cost routes
Configuration:
- router eigrp {ASN | name} - creates an EIGRP process in class (AS) mode or named mode
- network net-no. [wildcard] - enables EIGRP on interfaces with IP addresses that are within
the classful network (if no wildcard), and the specified subnet (if wildcard)
- OSPF requires wildcard mask; EIGRP does not require wildcard mask
- eigrp router-id RID - manually defines a RID (if none, use loopback/nonloopback interface
IP address)
- Process does not have to be cleared for new RID to take effect
- Adjacency goes down and then back up when RID is changed
- maximum-path x - sets the maximum number of concurrent equal-cost or unequal-cost
routes to reach a subnet (default: 4)
- variance multiplier - router considers FS routes with the FD less than the FD of the
successor route multiplied by the multiplier to be equal routes
- bandwidth bw-kbps and delay delay-in-10s-of-microseconds can be used to accurately
tune the metric
- [no] auto-summary - enables/disables autosummarisation (default: off)
Verification:
- show ip protocols - lists a shorthand EIGRP configuration with K-values, maximum paths,
variance, autosummarisation, passive interfaces, RID etc.
- show ip eigrp interface - lists the true interfaces on which the router has actually enabled
and configured EIGRP on
- EIGRP-enabled interface, no. of peers connected to interface etc.
- Does not list disabled or passive interfaces
- show ip eigrp interface detail - lists more detail, including timers, split horizon etc.
- show ip eigrp neighbors - lists neighbour IP address, outgoing interface, remaining hold
time, uptime etc.
- show ip eigrp topology - lists the EIGRP topology table
- Lists successor and FS routes, with their FD and RD and outgoing interface and next-hop
IP address
- show ip eigrp topology all-links - lists all routes, including non-FS, non-successor routes
- show ip eigrp topology subnet - lists the K-values and FD
- show ip route eigrp - lists the EIGRP successor routes, with code 'D' and metric
- debug eigrp fsm - lists successor route fails, routes being given the infinity metric and FS
routes becoming the successor route
Troubleshooting:
 - show ip eigrp interface lists all EIGRP-enabled interfaces that are not passive interfaces
- show ip protocols lists network commands and passive interfaces for both EIGRP and
OSPF
- If show ip eigrp interface does not list an interface, incorrect network command may be
configured -> check show ip protocols to determine the incorrect command
- Use show ip protocols to determine passive interfaces

- show ip eigrp neighbor - lists neighbours that have passed all requirements

2.7 Configure, verify, and troubleshoot EIGRP for IPv6 (excluding authentication, filtering,
manual summarisation, redistribution, stub)
- EIGRP sends multicast messages to FF02::A
- EIGRPv6 does not support the network command => ipv6 eigrp ASN
Configuration:
- ipv6 router eigrp ASN - creates the EIGRPv6 process and defines the ASN
- eigrp router-id RID - manually defines the router ID (uses highest 'up' loopback and
nonloopback interface IPv4 address)
- maximum-paths no., variance multiplier, [no] shutdown, bandwidth bw-kbps and delay
delay-10s-of-microseconds are identical to EIGRP for IPv4 configurations
- ipv6 hello-interval eigrp ASN time and ipv6 hold-time eigrp ASN time - manually sets the
EIGRPv6 Hello interval and Hold time
- ipv6 eigrp ASN - enables an interface to use EIGRPv6 and assigns an ASN to it
- EIGRPv6 does not need [no] auto-summary
Verification:
- show ipv6 eigrp interfaces - does not list any passive interfaces
- show ipv6 protocols - identifies passive interfaces
- show ipv6 eigrp interfaces detail - lists detailed interface EIGRPv6 information for
 nonpassive interfaces
- show ipv6 eigrp neighbors - lists the EIGRPv6 neighbour table
- show ipv6 eigrp topology - lists the EIGRPv6 topology table, with successor and FS
routes and feasible and reported distances
- The next-hop router IPv6 address is a link-local address
- show ipv6 route eigrp - lists the best EIGRPv6-learned routes, with the AD and metric
Troubleshooting:
- EIGRPv6 has the same neighbour requirements as EIGRP for IPv4 except neighbours can
be in different prefixes
- Omission of ipv6 eigrp ASN can result in missing routes because the router does not learn
or advertise routes over the interface
- Passive interfaces prevent the neighbour relationship from forming
- EIGRPv6 neighbour requirements:
- Matching authentication (if configured)
- Same ASN (as defined in ipv6 router eigrp ASN)
- Matching K-values
- EIGRP neighbours can:
- Be in different prefixes (subnets)
- Have mismatching Hello and Hold timers
- Have a duplicate router ID
- Make sure all interfaces in the path to a subnet all have EIGRP enabled so that they can
learn and advertise routes
- Make sure all neighbour relationships in the optimal path to a subnet are up and lowest
bandwidth and cumulative delay settings are correct to avoid using a suboptimal route

3.0 WAN Technologies

3.1 Configure and verify PPP and MLPPP on WAN interfaces using local authentication
- T-carrier system defines serial link speeds (e.g. T1, T3)
- Time-Division Multiplexing (TDM) allows speeds in between of multiples of T1 or T3
HDLC:
- HDLC is enabled by default on a serial interface
- cHDLC adds a Type and Address field in the header
- encapsulation hdlc (if another encapsulation is set)
- show controllers int-id - shows the DTE/DCE and clock rate
- show interface - lists IP address and mask, bandwidth and encapsulation type
PPP:
- PPP supports a Type field in the header to allow multiple Layer 3 protocols to pass over it
(uses same header format as cHDLC)
- PPP has built-in authentication protocols (CHAP, PAP) and control protocols (LCP, NCP)
- Link Control Protocol (LCP): establishes, configures and tests the data link
- Network Control Protocols (NCP): a category of protocols, one per network layer
protocol, and performs functions specific to its related Layer 3 protocol
- PAP authentication process:
1. Router being authenticated sends clear-text username and password
2. Authenticating router sends clear-text acknowledgement if authentication is successful
- CHAP authentication process:
1. Authenticating router sends a Challenge message
 2. Router being authenticated sends an MD5 hash of the password and Challenge
3. Authenticating router sends Success/Failure message
- MLPPP makes multiple serial interfaces look like a single Layer 3 interface
- MLPPP uses Layer 2 load-balancing across multilink interfaces with PPP header/trailers
- Multilink interface is up/up as long as at least one physical link in the MLPPP group is up
Configuration:
- encapsulation ppp - migrates from HDLC to PPP
- ppp authentication {chap pap | pap chap} - if CHAP or PAP is not supported (and has NOT
failed authentication), then use PAP or CHAP
- Implementing PPP CHAP:
- hostname name - sets the local router's name used during authentication
- username neighbour-name password pass - defines the name used by the
NEIGHBOURING router, and the matching password
- ppp authentication chap - enables CHAP on an interface
- Implementing PPP PAP:
- ppp authentication pap - enables PAP on an interface
- ppp pap sent-username local-name password pass - defines the local username and
password
- username neighbour-name password pass - defines the neighbour's name and password
- Implementing MLPPP:
- interface multilink no. - creates a multilink interface
ppp multilink group no. - refers to the multilink interface number (used on serial and
multilink interface)
encapsulation ppp - used on serial and multilink interfaces
ppp multilink - enables multilink and must be used on serial and multilink interfaces
ip address is configured on the multilink interface (no ip address on serial interface)
Verification:
- show interface - lists if PPP is enabled ("Encapsulation PPP") and lists "LCP Open" if LCP
has completed its work successfully, along with types of enabled CPs
- show ppp all - lists various LCPs and NCPs, with '+' for Open protocol and '-' for failed
protocol (e.g. LCP+, CHAP+, IPCP+)
- show interface multilink no. - lists "Multilink Open" and "Hardware is multilink group
interface" if MLPPP is working
- show ppp multilink - lists active/inactive physical interfaces in the MLPPP bundle
Troubleshooting:
- If CHAP is enabled by authentication fails, interfaces becomes up/down state and show
interfaces does not list "LCP Open"
- If router is down/down (Layer 1 problem):
- Neighbouring interface is shutdown
- Bad/unplugged cable, misconfigured or broken CSU/DSU, telco facilities problem etc.
- If router is up/down (Layer 2 problem):
- Up/down - up/down: mismatched encapsulation commands or PAP/CHAP failure
- Up/down - up/up: keepalive disabled on the up/up end when using HDLC (not PPP)
- Keepalive messages are used to help a router notice a failed link (sent every 10 seconds
by default)
- If router does not receive a keepalive for a number of keepalive intervals, router
changes the link to an up/down state
 - show interfaces lists encapsulation and keepalive "set" or "not set"
- show interfaces and show ppp all lists PPP authentication status
- debug ppp authentication - shows PPP authentication messages
- "{O | I} {CHALLENGE | RESPONSE | FAILURE | SUCCESS}" - CHAP message process
- If router is up/up but ping fails (Layer 3 problem):
- If routers have IP addresses that are in different subnets on a HDLC link, ping will not
succeed because there is no route matching the address
- If routers have IP addresses that are in different subnets on a PPP link, ping will succeed
because there is a host route matching the address (but EIGRP/OSPF adjacencies will not
form)
3.2 Configure, verify, and troubleshoot PPPoE client-side interfaces using local
authentication
- Dialer interfaces act as Layer 3 logical interfaces that can be dynamically bound to use a
physical interface
Configuration:
- Layer 1 physical interface:
- pppoe-client dialer-pool-number no. - puts the physical interface into a dial pool so that
it can be used by a dialer interface
- pppoe enable - enables PPPoE on the physical interface, but is automatically added
when pppoe-client is configured
- no ip address - physical interface does not need an IP address as the dialer interface
performs Layer 3 logic
- Layer 2 dialer interface:
- encapsulation ppp - defines the Layer 2 protocol used by the dialer interface
- ppp authentication {pap | chap} - configures the local authentication method
- ppp chap hostname name and ppp chap password pass - defines the username and
password the router uses to be authenticated by the ISP (one-way authentication)
- Layer 3 dialer interface:
- interface dialer no. - creates a dialer interface and enters dialer interface config mode
- dialer pool no. - references the dialer pool number as configured on the physical
interfaces
- ip address negotiated - causes PPP to use IPCP to dynamically learn the IP address (from
the ISP)
- mtu 1492 - reduces 8 bytes of the IP packet to make room for the additional 8-byte
PPPoE header and prevents unnecessary fragmentation
Verification:
- PPPoE session: the IOS internal process that keeps status variables for PPPoE CPs
- Virtual-access interface: logical interface dynamically created by IOs once the PPPoE
session is up and working; it is bound to the dialer interface
- show interface dialer no. - lists output for both the dialer and virtual-access interface
- Dialer interface: IP address, IP MTU, but PPP's LCP is closed
- Virtual-access interface: PPP's LCP open, but no IP address
- Up/up (spoofing) is the normal working state of the dialer interface since the data link
logic sits in the virtual-access interface
- show interface virtual-access no. - lists the virtual-access interface details
- show interface virtual-access no. configuration - lists the IOS-generated configuration in
the form of commands
 - show running-config interface virtual-access - does not include the PPP configuration
that IOS dynamically pulls from the dialer interface
- show pppoe session - displays the PPPoE status, three interfaces and remote and local
MAC addresses
- show ip interface brief - lists the dialer interface with an IP address learned from IPCP
Troubleshooting:
- When dialer interface is not fully working (default) it will be up (spoofing)/up (spoofing) in
show interfaces (show ip interface brief lists a status of up/up)
- show pppoe session returns no lines of output
- Automatic pppoe enable allows the router to try and create a PPPoE session and show
pppoe session lists state of 'PADISNT', does not list a virtual-access interface, and uses
placeholders for MAC addresses
- After Layer 2 config is added, dialer interface becomes up/up (spoofing), show pppoe
session lists a state of 'UP' and lists all three interfaces and remote/local MAC addresses
- Layer 1: check if the dial pool numbers match and dialer and physical interfaces are not
shut down
- Layer 2: if virtual-access interface is not listed in show pppoe session, check Layer 2
configuration and mistyped CHAP password
- If show interface dialer lists a status of up (spoofing)/up (spoofing), check the PPP
configuration
- show pppoe session must list a status of UP, three interfaces and 2 MAC addresses
3.3 Configure, verify, and troubleshoot GRE tunnel connectivity
- GRE packet format: delivery header + GRE header + payload packet (with IPsec)
- Delivery header: 20-byte IP header used for Internet routers to route the packet
- Payload packet: holds private source/destination addresses
- Routers use virtual tunnel interfaces that need to be using private addresses and be in the
same subnet as the tunnel interface on the other end
- Point-to-point GRE tunnels work just like a point-to-point serial link
Configuration:
- interface tunnel no. - creates a tunnel interface
- tunnel mode gre ip - tells IOS to use GRE encapsulation on the tunnel (default)
- tunnel mode gre ipv6 for IPv6 and tunnel mode gre multipoint for DMVPN
- ip address addr mask - assigns the PRIVATE IP address to the tunnel interface
- tunnel source {ip-addr | int-id} - sets the tunnel's source IP address (local interface's
PUBLIC IP address)
- Local interface or local IP address can be specified
- tunnel destination {ip-addr | hostname} - configures the tunnel's destination IP address
(other router's PUBLIC IP address)
Verification:
- show ip interface brief - lists the two-item status and IP address of the tunnel interface
- show interface tunnel no. - lists the source and destination IP address configuration,
encapsulation type and IP address/mask
- show ip route - lists a connected route for the private IP address of the other router (lists
normal route for public IP address)
- traceroute - does not list unsecured routers that are not in the GRE tunnel
Troubleshooting:
- tunnel source and tunnel destination must reference the correct IP
 addresses/interfaces/hostnames, or the tunnel interface will not be up/up
- tunnel source needs the source (local) interface to be up/up and have an IP address (or
the tunnel interface will remain in the up/down state)
- Tunnel interface is up/down at the start
- tunnel destination needs a route for the destination or a resolved hostname (stored as IP
address after being immediately resolved)
- ping the private IP address or enable a routing protocol to form neighbour relationships
to test whether the tunnel is working at Layer 3 (up/up problems)
- Inbound ACLs can match every packet, including GRE packets
- permit ip or permit gre matches the GRE tunnel's unsecured IP address
3.4 Describe WAN topology options
3.4.a Point-to-point
- Ethernet Line service (E-Line; VPWS)
- Customers are connected by an EVC, using physical Ethernet interfaces, same subnet IP
address, and routing protocol neighbour relationships
- Requires lots of lines for lots of remote sites
- Enterprise uses TDM serial links, MPLS, or MetroE to access the Internet, and:
- DSL: provides faster speeds on the existing phone lines, with no additional cabling
- ADSL provides faster download speed than upload speed
- Can degrade at longer distances (limited distance)
- Cable Internet: uses existing CATV cables and supports asymmetric speeds
- Wireless WAN (3G, 4G, LTE): devices connect wirelessly to nearby phone tower
- Fiber Internet: uses fiber-optic cables (often uses Ethernet) that are faster than copper
wires
3.4.b Hub and spoke
- Ethernet Tree service (E-Tree): partial mesh, hub and spoke, point-to-multipoint
- Central site (root) device can send Ethernet frames directly to each remote (leaf) site
- Packets from the leaf site flows through the root site
- Root can have neighbour relationships with all leaves, but leaves can only have
neighbour relationships with the root (not to other leaves)
- Root and leaves in the same EVC are in the same subnet
3.4.c Full mesh
- Ethernet LAN service (E-LAN; VPLS)
- Every site can send frames directly to each other site by using full mesh
- Multiple routers in a single subnet and each router can have multiple neighbours
3.4.d Single vs dual-homed
- Internet edge: connection between ISP customer and an ISP
- Single homed: one link from enterprise to a single ISP
- Less redundancy (single point of failure) but costs less money
- Dual homed: two links from an enterprise to a single ISP
- One enterprise router to two ISP routers
- Two enterprise routers to two ISP routers
- Single-multihomed: one link each to multiple ISPs
- Dual-multihomed: two links each to multiple ISPs
3.5 Describe WAN access connectivity options
3.5.a MPLS
- MPLS allows an SP to connect to many customers and keep their traffic separated
 - MPLS PE routers add (push) and remove (pop) MPLS headers and labels
- MPLS labels provide faster route lookup using Forwarding Equivalence Class (FEC)
- FEC contains destination IP address, local exit interface and QoS
- Label switched path is a predetermined unidirectional route for packets to a subnet
- Provider routers will not perform routing table lookups but compares the label to their
Label Information Base (LIB) and 'swaps' the incoming label with a new one
- Router before the PE router will attach a label of zero (explicit null label), indicating that
the receiving router needs to pop the label and not push a new one
- PE compares the explicit null label to LIB, pops it, and uses standard route lookup
- Penultimate hop popping: router before PE does not put any label (implicit null) and
lets the PE perform a single route lookup
- MPLS VPNs ensure packets are only sent to the destination and not other sites
- MPLS is a Layer 3 service, and uses routers, so it supports any data link protocol (e.g.
serial [TDM], frame relay, MetroE, ATM)
- CE marks packets with QoS and PEs provide associated treatment
- CE-PE link uses many routing protocols to exchange customer and other CE routes
- CE becomes neighbours with the PE router at the other end of the access link, but not
other CE routers
- MPLS network advertises the customer routes between various PE routers
- PE uses route redistribution from/to MPBGP
- MPLS PEs form a super backbone area and each PE-CE link can be any area, including the
backbone area
- PE-CE configuration at each site could use different EIGRP ASNs, making the metrics less
realistic
3.5.b MetroEthernet
- Uses Ethernet physical links to provide Layer 2 service on customer devices
- Customer uses fiber Ethernet standards for access link to SP
- Point of Presence (PoP): where the SP puts a switch near to many customer sites
- Access link: physical link between the customer and the SP (uses LX, LX10, ZX, LR, ER)
- User Network Interface (UNI): everything that happens on the access link
- With MetroE, since both LAN and WAN is Ethernet, switches can be used as WAN edge
- SP can provide service using Bandwidth Profile (BWP) that defines a specific Committed
Information Rate (CIR) over the EVC
- MetroE CEs use shaping and PEs use policing
3.5.c Broadband PPPoE
- PPPoE allows PPP on Ethernet and DSL links, transported inside Ethernet frames
- PPPoE creates a tunnel through DSL (PPPoE session) between the customer router and
the ISP router (tunnel header + PPP header + IP packet)
3.5.d Internet VPN (DMVPN, site-to-site VPN, client VPN)
- Confidentiality: prevents MITM from being able to read the data in transit
- Authentication: verifies the legitimacy of the VPN packet sender
- Data Integrity: verifies that the packet was not changed whilst in the Internet
- Anti-replay: prevents MITM from copying and replaying the. packets
- VPN tunnel: encrypted original packet + VPN header + new IP header with new source
and destination address
- Site-to-site VPN with IPsec encrypts data sent between a VPN tunnel by using
encryption/decryption keys
 - Client VPN with SSL can be used to an ASA (encrypts all packets) or to a server (one
session encryption)
- DMVPN uses only one tunnel interface per site by using a multipoint GRE tunnel
- DMVPN uses Next Hop Resolution Protocol (NHRP) to reduce configuration
- The hub site on the tunnel acts as the NHRP server
- Spoke sites can initially only communicate with the hub site
- Spoke sites (NHRP clients) register their matching public and private IP addresses with
the NHRP server
- NHRP clients can ask the NHRP server for the public address of another spoke site to
then start sending packets directly to other routers over the multipoint GRE tunnel
3.6 Configure and verify single-homed branch connectivity using eBGP IPv4 (limited to
peering and route advertisement using Network command only)
- Enterprise advertises a single route for the public IP address block (NAT, DMZ servers etc.)
- ISPs advertise the enterprise route to other ISPs and advertises a default route to the
enterprise
- BGP should be used when:
- The company is connecting to more than one AS or ISP (multihomed, dual homed)
- The routing policy of the organisation and the ISP differs
- The company is an ISP; when traffic from other ASes are using the AS as a transit
domain, it needs to run BGP
- BGP should not be used when:
- When there is a single connection to the Internet or to another AS, and no redundant
link exists (single-homed)
- When it does not matter which path is used to reach a route in another AS
- When there is a low-bandwidth connection between multiple ASes (static/default routes
is better)
- Routers exchange BGP update messages with BGP peers by using Network Layer
Reachability Information (NLRI) which contain address block information
- eBGP is used between ASes and iBGP is used within ASes
- BGP best path selection compares Path Attributes (PAs) until one is better than another
- AS_PATH PA lists ASNs like hop counts, with shorter being better
- Single-homed eBGP: ISP advertises a default route that is redistributed in the enterprise
network using IGPs
- BGP neighbour states:
- Idle: neighbour is administratively shutdown or router is waiting before next retry
- Connect: the TCP connection is being attempted, but not completed
- Active: the TCP connection has been completed, but no BGP messages have been sent
- Opensent: this router sent the first message to establish the BGP peer (BGP Open)
- Openconfirm: this router has received an Open message
- Established: the routers are now peers and can exchange update messages
1. Two routers create a TCP connection on port 179 and become BGP peers
2. Router adds NLRIs and associated PAs to its local BGP table (network)
3. eBGP advertises the best routes in its BGP table in a BGP update sent to ISP
4. BGP on ISP processes that received update and adds BGP table entries
- Discard routes can be used when there is no. routing table entry for an address block and
only for individual subnets
- Discard route = static route + outgoing interface of null0
Configuration:
- router bgp ASN - moves the user into BGP configuration mode
- neighbor peer-ip remote-as peer-ASN - defines the IP address and remote ASN of a BGP
peer in a single-homed design
- neighbor peer-ip shutdown - administratively brings down a peer (e.g. for maintenance)
- bgp router-id RID - manually defines the BGP RID (if not configured, use same RID
selection process as EIGRP and OSPF)
- network prefix mask mask - tells BGP to put the prefix into the BGP table, assuming that
prefix is already in the IP routing table
- ip route prefix mask null0 - creates a discard route which BGP can use to add an entry for
many individual subnets to the BGP table
- IGPs, such as OSPF, can use default-information originate to redistribute an eBGP default
route to the enterprise network
Verification:
- show tcp brief - lists all TCP connections that terminate at this router
- Router initiating the connection uses a dynamic port, connecting to TCP port 179
- show ip bgp - lists the BGP table with prefixes, next-hop addresses and AS_PATHs
- show ip bgp summary - lists the neighbour IP address and ASN, state and number of
prefixes received from that neighbour
- eBGP peers have different ASN to the local ASN (iBGP peers have the same ASNs)
- Lists state of "Idle (Admin)" for administratively shutdown neighbours
- show ip route prefix mask longer-prefixes - lists all IPv4 routes in the range of the subnet
4.0 Infrastructure Services
4.1 Configure, verify, and troubleshoot basic HSRP
- FHRPs provide redundant default routers by letting hosts point to the virtual IP address of
the default routers and packets are sent to the active router
- HSRP uses the active/standby model, where only one router will actively support the end-
user traffic and others wait to take over if there is a problem
- HSRP active routers use a virtual IP and MAC address
- If active router fails, the standby router uses the VIP and VMAC addresses and sends a
gratuitous ARP for switches to update their MAC address table
- Routers can have different states in different HSRP groups for load balancing
- When a router interface comes up and it sends HSRP messages, if it:
- Discovers no other HSRP routers in the subnet, the local router is the active router
- Discovers existing HSRP routers that are negotiating, the routers negotiate, with the
router with the highest HSRP priority becoming the active router
- Discovers a router that is already an active router:
- If not configured with preemption, local router becomes a standby router regardless of
its priority
- If configured with preemption, local router checks its priority versus the active router
and the router with the highest priority is the active router
- HSRP states:
- Initial: when interface first becomes available
- Learn: when router has not determined the virtual IP address and has not received an
authenticated Hello message from the active router
- Listen: when router knows the virtual IP address, but it is neither active nor standby
- Speak: when router sends periodic Hello messages and participates in the
 active/standby election
- Standby & Active
Configuration:
- standby group ip [virtual-ip] - defines the HSRP group number and virtual IP address or
lets the router learn the virtual IP address
- standby group name text - defines the name that can be assigned to the group
Verification:
- show standby brief - lists the group number, priority, preemption status, local router's
state, active router's IP address, standby router's IP address and the virtual IP address
- show standby - also lists the version, virtual MAC address, group name and counters
Troubleshooting:
1. Routers must be configured with the same HSRP version and group number
2. Routers must configure the same virtual IP address
3. Virtual IP addresses must be in the same subnet as the interface IP address and not used
by any other device in the subnet
4. Layer 2 network needs to have the interfaces on the router on the same VLAN
5. No ACLs should filter HSRP messages (UDP port 1985; v1: 224.0.0.2, v2: 224.0.0.102)
- HSRP version mismatch and group number mismatch cause both routers to be active
and detect a duplicate address
- ACLs that block HSRP messages cause both routers to be active but does not detect
duplicate addresses
- Virtual IP mismatch does not cause both routers to be active but the VIP changes
according the local router's VIP settings
4.1.a Priority
- standby group priority no. - defines the priority used for that interface in the group
(default: 100)
4.1.b Preemption
- standby group preempt - enables preemption on an interface (default: off)
- Preemption needs to be configured on the router that is taking over
4.1.c Version
- standby version {1 | 2} - sets the version for all HSRP messages sent out that interface
HSRPv1 HSRPv2
IPv6 Support No Yes
Smallest unit for Hello timer Second Millisecond
Range of group numbers 0 - 255 0 - 4095
VMAC address used (XX or XXX is the hex group 0000.0C07.ACXX 0000.0C9F:FXXX
number)
IPv4 multicast address 224.0.0.2 224.0.0.102
Uses a unique identifier for each router No Yes
4.2 Describe the effects of cloud resources on enterprise network architecture
4.2.a Traffic path to internal and external cloud services
- Internet:
- Easy deployment because companies already have Internet connections
- Fast deployment as enterprise does not need to wait for a private WAN connection
- Easy migration from one cloud provider to another because all connect to the Internet
- Internet is less secure, requires a large amount of Internet link load, does not provide
QoS and do not have SLAs
 - Private WAN and Internet VPN:
- MPLS VPNs (Layer 3) use an MPLS provider and Ethernet WAN (Layer 2) uses EVCs
between the public WAN and the enterprise
- Private WANs and Internet VPN are much more secure
- Private WAN services provide QoS (not Internet VPN)
- Private WAN connections take time to install and is harder to migrate to another cloud
provider with (Internet VPN has easier setup and migrations)
- Intercloud Exchange:
- Cloud consumers connect to intercloud exchange, which connects to cloud providers
- Cloud consumer keeps the same private WAN links, but asks the provider to
reconfigure to set up new private WAN connections to the new cloud provider
- Intercloud exchange provides easier migration but introduces another company into
the connection

- Branch offices can have private WAN connection to the central office that has an
Internet connection to the cloud provider (more load on private WAN)
- Branch offices can have direct Internet connections (reduces load but less secure)
4.2.b Virtual services
- Virtual machine (VM): virtual OS instance that is decoupled from the hardware
- Hypervisor treats each thread that can be run on a single CPU chip using multithreading
as a virtual CPU (vCPU) and assigns each VM a number of vCPUs
- A VM needs a minimum number of vCPUs, RAM, storage and NICs
- Hypervisor manages and allocates the host hardware to each VM
- Each VM has at least on vNIC, connected to an internal virtual switch
- Each VM can be in its own VLAN, share the same VLAN, or use VLAN trunking to the VM
- Each host is cabled to two ToR switches (access layer switch), which are connected to an
EoR switch (distribution layer switch)
- Criteria for a cloud computing service (NIST):
- On-demand self-service: consumer chooses when to start and stop using the service
- Broad network access: service must be available from many types of networks
- Resource pooling: the provider dynamically allocates resources from a pool for each
new request from a customer
- Rapid elasticity: to the consumer, the resource pool appears to be unlimited and
requests for new service are filled quickly
- Measured service: the provider can measure the usage and report that usage to the
consumer for transparency and billing
- Private cloud: provides service to internal customers within an enterprise
1. The cloud team configures the cloud services catalog and adds new services to it
2. The customer requests for VMs via the cloud services catalog
3. The virtualisation software adds, moves or deletes VMs accordingly
- Public cloud: offers and sells services to consumers in other companies
1. Customers send requests for VMs through the remote cloud service catalog
2. Virtualisation software in other company creates a new VM
 3. The VM is then instantiated and ready for use by the customer
- Public cloud provides different network access options (e.g. VPN and private WAN)
- Infrastructure as a Service (IaaS):
- Customer specifies the amount of hardware performance/capacity (e.g. vCPU, RAM)
and the OS and can install applications later => very flexible hardware and software
- Software as a Service (SaaS):
- The customer only chooses the application, and the hardware is managed by others =>
provides file storage features, private email services etc.
- Platform as a Service (PaaS):
- PaaS has configurable hardware and many development tools (e.g. IDEs) than IaaS
4.2.c Basic virtual network infrastructure
- Cloud providers can perform server load balancing (SLBaaS) between VMs
- VNF is a virtual instance of a traditional networking device that can be used in a cloud
- NFV is the process for how SPs virtualise network functions within their network
- DNS server in the public cloud can be used to resolve DNS queries
- The enterprise DNS server can point to the DNS server in the cloud since it automatically
creates a DNS record for each VM
- Cloud provider applies DHCP and NAT to correctly assign and translate public and private
IP addresses (as per specified by the customer in the cloud services catalog)
- Enterprise can use private addresses from their address space when using private WAN
or a VPN tunnel that terminates at the CSR that is running as a VNF
- VMs and VNFs can be NTP clients, the virtual router can be the NTP client/server and the
enterprise server can be the NTP server
4.3. Describe basic QoS concepts
- QoS manages Bandwidth, Delay, Jitter and Loss
- Bandwidth: capacity of the link; QoS can reserve percentages of bandwidth to traffic
- Delay: one-way delay (sender - destination) or round-trip delay (sender - back to sender)
- Jitter: variation in one-way delay between consecutive packets
- Loss: the amount of lost messages
4.3.a Marking
- Classification: the process of matching the fields in a message to make a QoS decision
- Marking: the process of QoS changing one or more header fields, setting a value in the
header
- First networking device to forward the packet can marks the packet's Differentiated
Services Code Point (DSCP) field, and the rest can match the DSCP value
- QoS classification can refer to an IP ACL to match packets matched with permit action
- NBAR matches packets for classification in a large variety of ways
- TOS byte (old): 3-bit IP Precedence (IPP) field (8 values to mark)
- TOS byte (new): 6-bit DSCP field (64 values to mark) + 2-bit ECN
- Class of Service (CoS) field is a 3-bit marking field in 802.1Q header (8 values to mark)
- Traffic ID (TID) for 802.11 header and EXP in MPLS label
- DSCP Expedited Forwarding (EF) (DSCP value 46):
- DSCP EF is used for voice packets for low latency (delay), low jitter and low loss
- Call signalling messages use CS3 since they do not require low delay, jitter and loss
- DSCP Assured Forwarding (AF):
- AF has 4 queues and 3 drop priority classes => 12 different DSCP AF markings
- Best AF: AF41, Worst AF: AF13
 - Class Selector (CS) allows DSCP backward compatibility with IPP values
4.3.b Device trust
- Trust boundary: the point in the path of a packet at which the networking devices can
trust the current QoS markings
- IP phones are typically the trust boundary because they can set the CoS and DSCP values
for the phone and the connected PC
4.3.c Prioritisation
4.3.c. (i) Voice
- Single voice flow requires only a little bandwidth compared to data applications
- Voice traffic should experience minimal delay, jitter and loss:
- One-way delay: 150 ms or less
- Jitter: 30 ms or less
- Loss: 1% or less
- Uses priority queue with LLQ for interactive voice for low delay, jitter and loss but place
it in a different queue from video so policing function applies separately
- Uses CAC to avoid adding to much voice/video to the network which would trigger the
policer function
4.3.c. (ii) Video
- Video traffic requires a higher bandwidth than voice per flow:
- Bandwidth: 384 Kbps to 20+ Mbps
- One-way delay: 200 - 400 ms
- Jitter: 30 - 50 ms
- Loss: 0.1% - 1%
- Uses priority queue with LLQ for interactive video for low delay, jitter and loss but
place it in a different queue from voice so policing function applies separately
4.3.c. (iii) Data
- Interactive web-based application requires a certain amount of bandwidth capacity,
and are able to take some amount of one-way delay, jitter and losses
- Interactive web-based applications require low delay and jitter for a high QoE
- Non-interactive web-based applications (e.g. backups) require more bandwidth and
less losses, but cares less about delay or jitter
- Use round robin queueing like CBWFQ for data and noninteractive voice and video
- Give more important data traffic higher weight in CBWFQ
4.3.d Shaping
- Shaper slows messages by queueing the messages and servicing them based on the
shaping rate, not the availability of the outgoing interface
- Shapers allow for a burst beyond the shaping rate
- Shaper is enabled on the egress side of the customer
- Shaper causes more delay and jitter
4.3.e Policing
- Policer can discard the packets that are over the policing rate
- Policer can re-mark the messages that exceed the policing rate, and let them into the
SP's network, but are aggressively discarded during congestion
- Policer allows for a burst beyond the policing rate for a short time, after a period of low
activity
- Policer is enabled on the ingress side of the SP
- Policer causes more loss
 4.3.f Congestion management
- Round robin: cycles through the queues in order, taking a percentage of bytes
- Weighting: scheduler takes a different number from each queue, with preferences
- CBWFQ guarantees a minimum amount of bandwidth to each class
- Round robin scheduler does not provide low delay, jitter, or loss
- Low latency queueing (LLQ): uses priority queues to always send packets
- LLQ reduces delay and jitter of voice packets in the priority queue
- LLQ can cause queue starvation when the scheduler never services other queues
because the priority queue is taking up all bandwidth
- Policing can be used to control queue starvation, but creates more loss
- Call Admission Control (CAC) limits the amount of voice and video that the network
routes out this link
- Congestion avoidance with TCP packets:
- Receiver increases window if all is well, but shrinks the window if TCP segment is lost
- Tail drop: when congestion management tools drop arriving packets when a queue is
full (causes more loss and increases delay)
- Full drop: if the queue exceeds the maximum threshold, the tool drops all packets
- Congestion avoidance tools drop some TCP segments so that windows are limited and
congestions won't happen later
4.4 Configure, verify, and troubleshoot IPv4 and IPv6 access list for traffic filtering
4.4.a Standard
IPv4
- ACL numbers 1 - 99 and additional 1300 - 1999
- Has an implicit deny any at the end that does not exist in the configuration
- access-list {1 - 99 | 1300 - 1999} {permit | deny} ip-addr [wildcard]
- Standard ACLs only match the source IP address(es)
- host keyword may be used, but IOS removes the keyword
- any keyword matches any and all source IP addresses
- Explicitly configured deny any allows show [ip] access-list to show the counter for the
number of packets matched by that explicit deny any logic
- access-list no. remark text - leaves text documentation on the ACL
- access-list ... log - causes IOS to issue log messages when an ACE is matched, and every 5
minutes after that for more matches
- log keyword makes packets be fast-switched and not CEF-switched
- Standard ACLs should be placed near to the destination to avoid filtering important
traffic
- Router does not filter packets that the router itself creates with an outbound ACL
- ip access-group {no. | name} {in | out} - enables an ACL on an interface
- show ip access-lists - lists all IPv4 ACLs with sequence numbers and counters
- show access-lists - lists all ACLs, with same information as show ip access-lists
IPv6
- IPv6 ACLs only use names to be identified (no standard or extended keywords)
- IPv6 standard ACLs can match the source and destination IPv6 address
- ACLs cannot filter based on the encapsulated or tunnelled traffic
- IPv6 ACLs have implicit permit statements (NDP NS & NA) before deny ipv6 any any
- Router can have both IPv4 and IPv6 ACLs applied inbound and outbound on a single
interface (IPv4 ACLs have no function on IPv6 packets and vice versa)
 - ICMPv6 messages (e.g. NDP, Path MTU Discovery [PMTUD]) must be permitted
- IPv6 ACLs use prefix lengths, not wildcard masks
Configuration:
- ipv6 access-list name - creates an IPv6 ACL and enters user into IPv6 ACL config mode
- remark text - leaves a text documentation on the IPv6 ACL
- {permit | deny} ipv6 {source-ipv6-prefix/prefix-length | any | host source-ipv6-addr}
{dest-ipv6-prefix/prefix-length | any | host dest-ipv6-addr} [log] - configures a standard
IPv6 ACL, with the source and destination IPv6 address(es) specified
- Standard IPv6 ACLs can have different protocol values and TCP/UDP port values
- sequence keyword allows insertion of an ACE with a specific sequence number
- ipv6 traffic-filter name {in | out} - applies the IPv6 ACL to an interface in a direction
Verification:
- show ipv6 interface - lists the ACL applied on the interface
- show ipv6 access-list - lists the contents of all IPv6 ACLs and counters for each ACE
- clear access-list counters name - clears the IPv6 ACL traffic counters
4.4.b Extended
IPv4
- Extended ACL can match protocol, source and destination IP address, source and
destination port TOS byte etc.
- ACL numbers 100 - 199 and additional 2000 - 2699
- access-list {no. | name} {deny | permit} protocol source-ip [wildcard] dest-ip [wildcard]
[log | log-input]
- access-list {no. | name} {deny | permit} {tcp | udp} source-ip [wildcard] [operator
source-port] dest-ip [wildcard] [operator dest-port] [established] [log]
- Extended ACLs must use the host keyword for a single host IP address
- Servers use well-known ports and clients use dynamic ports of 1024 and higher
- Extended ACLs should be placed as close as possible to the source of the packets to save
some bandwidth
IPv6
- IPv6 ACLs can match the flow label, Traffic Class (e.g. DSCP), source/destination IPv6
addresses, TCP/UDP port numbers, TCP flags, ICMPv6 type and code, MIPv6 headers,
extension (hop-by-hop headers, routing headers, fragmentation headers, IPsec,
destination options) and option header values
Configuration:
- {permit | deny} {icmp | tcp | udp | ipv6} {source-ipv6-prefix/prefix-length | any | host
source-ipv6-addr} [operator source-port] {dest-ipv6-prefix/prefix-length | any | host
dest-ipv6-addr} [operator dest-port] [icmp-message] [log | log-input]
- echo-request and echo-reply keywords match ICMPv6 Echo and Reply
- nd-ns and nd-na keywords match ICMPv6 NDP NS and NA
- router-solicitation and router-advertisement keywords match ICMPv6 NDP RS and RA
- ipv6 access-class name {in | out} - enables an ACL on a VTY line and restricts
management plane traffic
Verification:
- show ipv6 neighbors - lists the neighbours learnt by NDP (NS and NA must work)
- show ipv6 routers - lists the routers on the same subnet as learned by NDP (RS and RA
must work)
Troubleshooting:
 - Make sure multicast addresses are allowed:
- NDP RS sends to FF02::2 and RA sends to source router's link-local address or FF02::1
- NDP NS sends to solicited-node multicast address and NA sends to source host's unicast
address or to FF02::1
- Routing protocols and DHCPv6 uses multicast addresses
- permit icmp any any nd-na, permit icmp any any nd-ns and deny ipv6 any any are
implicitly configured on all ACLs
4.4.c Named
- Named ACLs use names to identify the ACL, ACL subcommands and allow ACL editing
- ip access-list {standard | extended} {name | no.} - enters user into ACL config mode
- permit, deny and remark commands can be entered without ip access-list {name | no.}
- no {command | seq-no.} - deletes a single line from the ACL
- seq-no. {permit | deny} ... - inserts a line into the ACL with a specified sequence number
- Numbered ACLs appear in the running-config as a global command, no matter the
configuration method
- ACEs configured in global config mode is added to the end of the ACL with automatic
sequence numbers
- show ip interfaces - lists on which interfaces ACLs are enabled, and in which direction
- show [ip] access-lists - lists the contents of each ACL
- Check for: misordered ACLs, reversed source/destination addresses/ports, syntax (tcp or
udp for ports and icmp for ICMP), dangerous inbound ACLs (with deny any) and location
of the standard ACL (should be near the destination)
- RIP uses UDP port 520 and 224.0.0.9, OSPF uses 224.0.0.5 and 224.0.0.6 and EIGRP uses
224.0.0.10
- Self-ping on a serial link sends the packet out the serial link and get routed back - local
router's inbound ACL and remote router's inbound and outbound ACL can filter
- Ethernet self-ping does not leave the interface - local router's inbound ACL can filter
4.5 Verify ACLs using the APIC-EM Path Trace ACL analysis tool
- APIC-EM adds ESA, IWAN, PnP and Path Trace etc. applications
1. Discovery application discovers the network topology
2. Path Trace application analyses where the imaginary packet would flow from the
specified source and destination address (and port)
- Path Trace does not take ACLs into consideration
- User can specify the source and destination IP address (optionally the protocol and
source and destination port numbers and ACL Trace option)
- Path Trace displays the forwarding logic between hops (e.g. switched, OSPF, connected)
- Path Trace identifies the routing protocols, SVI, switched, HSRP etc.
- Path Trace determines the path and ACL Trace determines ACLs in the path
- ACL Trace lists indicator icons for:
- No ACLs present
- An ACL is present and permits the packet
- An ACL is present and denies the packet
- An ACL is present but might or might not be denying the packet (depends on port)
- 'View Matching ACEs' shows the specific ACL and ACE that would match the packet
- If the packet may or may not be filtered, 'View Matching ACEs' lists all ACEs that may
match the packet
5.0 Infrastructure maintenance
5.1 Configure and verify device-monitoring protocols
- SNMP manager: network management application running on a PC or server (NMS)
- SNMP agent: the device that is being monitored by the SNMP manager
- Management Information Base (MIB): a database of variables that make up the
parameters, status and counters for the operations of the device using OIDs
- NMS uses SNMP Get, GetNext and GetBulk messages to ask for information from agent
- Get Request asks for contents of a variable and Get Response supplies the information
- SNMP Traps notify the NMS of an event and uses UDP
- SNMP Informs notify the NMS with. UDP, but NMS must acknowledge receipt (reliable)
- Read-only (RO) community allows Get messages
- Read-write (RW) community allows both Get and Set messages
- SNMPv3 uses username and hashed password
5.1.a SNMPv2
Configuration:
- snmp-server community comm-str {RO | RW} [ipv6 acl-name] [acl-name] - enables the
SNMP agent and sets the read-only or read-write community string and optionally
restricts incoming SNMP messages based on the IPv4 or IPv6 ACL
- snmp-server location location-text - documents the location of the device
- snmp-server contact contact-name - documents the contact
- snmp-server host {hostname | ip-addr} [informs | traps] version 2c notif-comm -
configures the SNMP agent to send either Traps or Informs to the listed host and the
notification community string (traps is the default)
- snmp-server enable traps - enables the sending of Traps and Informs
Verification:
- show snmp community - repeats the community string values and attached ACLs
- show snmp host - lists the IP address/hostname of NMS, message type, username and
version
- show snmp location - lists the configured location
- show snmp contact - lists the configured contacts
- show snmp - lists detailed counters on the number of SNMP packets input and output,
requested MIB variables, Set requests, number of altered variables etc.
5.1.b SNMPv3
Configuration:
- snmp-server group name v3 {noauth | auth | priv} [{read | write} viewname] [access
[ipv6] acl-name] - configures a group to use a certain security setting, views and ACLs
- noauth only checks message integrity
- auth checks message integrity and performs authentication
- priv checks message integrity, performs authentication and encrypts the messages
- v1default is an MIB view that includes all the useful parts of the MIB
- snmp-server view viewname {OID | word} {included | excluded}
- snmp-server user username group-name v3 [auth {md5 | sha} pass] [priv {des | 3des |
aes {128 | 192 | 256}} key-value - configures a user and its security/privacy settings
- snmp-server host {hostname | ip-addr} [informs | traps] version 3 {noauth | auth |
priv} username - configures where to send notifications to, the security setting and
username
- snmp-server enable traps - allows Traps and Informs to be sent
 Verification:
- show snmp user - lists the username, authentication and privacy protocol and group
name
- show snmp group - lists the group name, security settings, read & write view and ACL
- show snmp - lists the counters for the number of Traps and Informs sent by the agent
- show snmp host - lists the notification host, message type, username and security
5.2 Troubleshoot network connectivity issues using ICMP echo-based IP SLA
- IP SLAs measure the performance and availability statistics
- IP SLAs generate traffic (e.g. ICMP, VoIP) and measures the results of received responses
- ICMP Echo probe does not require an IP SLA responder because any device, host or server
can reply back with an ICMP Echo Reply
Configuration:
- ip sla no. - enters user into IP SLA configuration mode
- icmp-echo dest-addr source-ip source-addr - configures a source and destination for the
ICMP Echo operation
- frequency seconds - defines the time interval that the message is sent (default: 60)
- threshold milliseconds - defines the time when action is taken (e.g. send SNMP trap)
before the timeout
- history filter all - keeps all data in the history
- history buckets-kept size - defines the limit for the maximum number of buckets in the
history (default: 50)
- ip sla schedule no. life {forever | seconds} start-time {now | hh:mm:ss | after hh:mm:ss}
- defines when to start the operation and when to stop
- no ip sla schedule no. - removes the command and ends the operation
Verification & Troubleshooting:
- show ip sla summary - lists a single line of output per SLA operation (higher ID = newer)
- Lists the operation type, destination IP address, round-trip time and return code
- show ip sla statistics no. - lists counters of successes/failures of past operations and the
most recent operation's return code and RTT
- ip sla restart no. - resets the counters for an IP SLA
- show ip sla history no. - lists a single line of output for each bucket
- You can look for spikes in the RTT and consistency in the return code
5.3 Use local SPAN to troubleshoot and resolve problems
- SPAN allows traffic to be copied to the port connected to the network analyser (source
port => destination port)
- SPAN session: a collection of SPAN rules that define one or more source ports and the
destination port and the direction of flow that will be copied (Tx, Rx, both)
- Using SPAN on a VLAN indicates all ports in the VLAN, including trunks
- Local SPAN: source and destination ports are attached to the same switch
- Remote SPAN (RSPAN): forwards SPAN traffic over a trunk link at Layer 2
- Encapsulated RSPAN (ERSPAN): encapsulates the SPAN traffic in a GRE tunnel to forward
the traffic to another Layer 3 switch
Configuration:
- Local SPAN rules:
- A SPAN destination port can be used with only one SPAN session at a time
- A SPAN destination port cannot also be a SPAN source port
- The SPAN destination port is not treated as a normal port (e.g. switch does not learn
 MAC addresses from the port or sends data out the port)
- SPAN destination port can be unconfigured and then added to another session
- Multiple SPAN sources can be used in a single SPAN session
- One SPAN session must have all interface or all VLAN sources
- One SPAN session can have any combination of directions (Tx, Rx, both)
- EtherChannel interfaces and trunks can be used as source ports
- monitor session no. source {interface | vlan} {int-id [last-in-range] | vlan-id} {tx | rx |
both} - configures the SPAN source interfaces or VLANs
- both is the default keyword (therefore does not need to be explicitly configured)
- monitor session no. destination int-id - defines the one SPAN destination port for the
monitor session
Verification & Troubleshooting:
- show monitor session all - lists the enabled directions for source ports/VLANs and the
destination port
- show monitor detail - lists all three directions for both ports and VLANs
- Duplicate copies of a frame may be sent out the destination port because one port
receives the frame and another sends out the frame => use a single direction across all
ports/VLANs
5.4 Describe device management using AAA with TACACS+ and RADIUS
TACACS+: Cisco-proprietary RADIUS: RFC 2865
Most often used for network devices Most often used for users
TCP port 49 UDP port 1645, 1812
Encrypts the password AND the entire packet Encrypts ONLY the password
Supports function to authorise each user to a Doesn't support separation of
subset of CLI commands authentication and authorisation
- aaa new-model - enables AAA services in the local device and allows new commands
(default: no aaa new-model)
- tacacs server server-name - specifies a name for the server
address ipv4 ip-addr - points to the IPv4 address of the server
key key-value
port port-no.
- aaa group server group-name - creates a server group
server name server-name - adds a server to the group
- aaa authentication default [local | line | group group-name] lists different
authentication methods for the console, VTY and Aux port
5.5 Describe network programmability in enterprise network architecture
5.5.a Function of a controller
- Controller can have all, most, partial, or no control plane functions
- OpenDaylight SDN controller (ODL) uses OpenFlow, NetConf, PCEP, BGP-LS and OVSDB
etc. as the SBIs
- Switches need to support OpenFlow to support ODL
- The Cisco Open SDN Controller (OSC) is Cisco's commercial version of the ODL and picks
out the subset of features that Cisco wants to use
- Cisco switches (Nexus) and routers (ASR series) support OpenFlow
- Cisco Application Centric Infrastructure (ACI) uses endpoints (servers/VMs), endpoint
groups and policies (defines which endpoint groups can communicate with others)
- ACI uses a centralised controller called the Application Policy Infrastructure Controller
 (APIC)
- Software and scripts can define endpoint groups and policies on the centralised APIC
- ACI uses a partially centralised control plane with OpFlex as an SBI
- ONF and ACI model centralises most, or much of the control plane
- APIC-EM adds network programmability while keeping the same traditional
switches/routers (distributed control plane)
- APIC-EM controller supports Cisco applications and RESTful API, with Telnet, SSH and
SNMP as the SBI (protocols already supported)
- APIC-EM gathers information about the network over the SBI and makes that
information available through NBI applications
- APIC-EM can use Telnet/SSH to log onto a device and issue CLI commands and use SNMP
Set commands to configure the networking device

5.5.b Separation of control plane and data plane

- Data plane: matches addresses to a forwarding table, encapsulating and de-
encapsulating, filtering (ACLs, port security), NAT etc.
- Control plane: routing protocols, ARP, NDP, MAC learning, STP etc.
- Management plane: Telnet, SSH, SNMP, Syslog, NTP etc.
- Switches use specialised hardware to perform data plane processing:
- Switching logic occurs in the ASIC
- Switch uses TCAM to store the equivalent of MAC address table for fast table lookup
- Traditional network use a distributed control plane but an SDN controller centralises the
control of the networking devices
5.5.c Northbound and southbound APIs
- Southbound interface (SBI) is a software interface between the controller and the
networking devices
- SBIs include: OpenFlow, OpFlex, CLI (Telnet/SSH), SNMP
- SBI is used to collect a list of all the devices, capabilities, interfaces/ports, current state,
topology and configuration of devices
- Northbound interface (NBI) connects the controller to network applications and
programs (e.g. Java API used to exchange data between controller and application)
- Representational State Transfer (REST) describes a type of API that allows applications
to sit on different hosts, using HTTP messages to transfer data over the API (application
sends HTTP Get requests to the controller which replies with HTTP Get response)
5.6 Troubleshoot basic Layer 3 end-to-end connectivity issues
Problems between host and default router:
- Compare ipconfig /all and show interface outputs:
- Host's DNS server lists against the actual DNS server addresses (no name resolution but
ping with IP address works)
- Check host's default router settings against router's LAN interface configuration (no off-
subnet communication if mismatch)
- Check the subnet masks (host can send data off-subnet but router does not have a route
 back for the host if mismatch)
- When ping and traceroute with a hostname fails but with IP address works, check DNS
server settings and IP connectivity to DNS server
- IOS DHCP servers need correct dns-server and routers need ip name-server and ip
domain-lookup (default)
- Router must have correct ip helper-address (including subinterfaces) and have IP
connectivity to the DHCP server; DHCP servers need the correct configuration
- Speed mismatch, shutdown at switch, err-disabled switch and no cable/bad cable results
in the router LAN interface in down/down
Problems with routing packets between routers
- show ip route address - lists detailed information about the route that the router is going
to use for the listed destination IP address
- show ip route lists the timer since the route was first learned
- VLSM or full overlaps cause routing issues
- IOS disallows overlapping subnets on the same router but allows overlap on different
routers (if no shutdown is issued, IOS leaves the interface in the admin down/down state
until overlap has been resolved)