IPv6 Quiz – Cisco Bias

January 16, 2018 at 7:49 pm

IPv6

This latest quiz is focused on IPv6 with a bias to Cisco Systems. These questions are what one could expect on a CCNP or CCIE exam across various tracks. Enjoy!

IPv6 Quiz - Cisco Bias

Start
Congratulations - you have completed IPv6 Quiz - Cisco Bias. You scored %%SCORE%% out of %%TOTAL%%. Your performance has been rated as %%RATING%%
Your answers are highlighted below.
Return
Shaded items are complete.
12345
6End
Return

Studying for the CCIE RS Written and Lab – EIGRP Stub

January 13, 2018 at 12:41 pm

Challenges

In this video, Anthony Sequeira gives a tip on how we should consider preparing for the CCIE written and lab exams simultaneously.

400-101 CCIE R&S Written – Free Resources – TCP Operations

December 30, 2017 at 9:48 am

TCP

Here are the free resources surrounding the Explain TCP Operations section of the CCIE R&S Written version 5.1 exam.

1.1.e Explain TCP Operations

  • 1.1.e.i     IPv4 and IPv6 PMTU
  • 1.1.e.ii    MSS
  • 1.1.e. iii  Latency
  • 1.1.e. iv  Windowing
  • 1.1.e.v    Bandwidth delay product
  • 1.1.e.vi   Global synchronization
  • 1.1.e       Options

TCP Performance – The Internet Protocol Journal – Volume 3, No. 2

Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC

IP Application Services Configuration Guide, Cisco IOS Release 15M&T

IPv6 Addressing and Basic Connectivity Configuration Guide, Cisco IOS Release 15M&T

IP SLAs Configuration Guide, Cisco IOS Release 15M&T

TCP Options

TCP Global Synchronization 

TCP/IP Illustrated, Volume 1

CCIERS

Rapid Spanning Tree Protocol (RSTP) 802.1w

December 29, 2017 at 8:10 am

rstp

Whether you are pursuing your CCNA, CCNP, CCIE, or many other Cisco Certifications, a deep knowledge of RSTP is critical. In this post, we will detail key facts for you regarding this Layer 2 loop prevention system.

  • 802.1w (RSTP) is an evolution of the classic 802.1D (STP) protocol
  • 802.1D tried to speed things up with the additions of UplinkFast, BackboneFast, and PortFast; the UplinkFast and BackboneFast features are now essentially built into RSTP, while PortFast is still a feature you enable in RSTP if desired
  • 802.1w can also revert back to 802.1D in order to interoperate with legacy bridges on a per-port basis
  • With 802.1D, once in the forwarding state, there is no way to tell from the port state whether the port is root or designated; RSTP decouples the role and the state of a port to address this issue
  • The 802.1D port states are Disabled, Blocking, Listening, Learning, Forwarding; in 802.1w these are simplified to Discarding, Learning, Forwarding
  • The port roles are expanded in 802.1w to include Backup and Alternate ports in addition to Root and Designated; these new port roles help implement the features of UplinkFast into the protocol natively
  • A Backup port receives more useful BPDUs from the same bridge it is on and is a port blocked
  • An Alternate port receives more useful BPDUs from another bridge and is a port blocked
  • RSTP now uses all six bits of the flag byte that remain in order to perform – encoding the role and state of the port that originates the BPDU and handling the proposal/agreement mechanism
  • The RSTP BPDU is now of type 2, version 2; legacy bridges must drop this new BPDU; this makes it easy for an 802.1w bridge to detect legacy bridges connected to it
  • BPDUs are sent every hello-time, and not simply relayed anymore’
  • BPDUs are now used as a keep-alive mechanism between bridges; a bridge considers that it loses connectivity to its direct neighbor root or designated bridge if it misses three BPDUs in a row; this fast aging of the information allows quick failure detection
  • To natively support the BackboneFast type behavior, RSTP accepts inferior BPDUs; when a bridge receives inferior information from its designated or root bridge, it immediately accepts it and replaces the one previously stored; this permits fast acceptance of a new Root port in the topology
  • Rapid transition is the most important feature introduced by 802.1w; RSTP is able to actively confirm that a port can safely transition to the forwarding state without having to rely on any timer configuration; in order to achieve fast convergence on a port, the protocol relies upon two new variables: edge ports and link type
  • RSTP can only achieve a rapid transition to the forwarding state on edge ports and on point-to-point links; the link type is automatically derived from the duplex mode of a port
  • A proposal/agreement process in RSTP aids in very convergence
  • The topology change notification process is overhauled in order to also aid in faster convergence and improve efficiency

For more details on these new features summarized here – check out Understanding Rapid Spanning Tree Protocol (802.1w) This document often forms the basis for plenty of RSTP-related written exam questions from CCENT to CCIE. Note that my summary document here covers most of those questions for you, however!

criers

 

Cisco IOS XE Processes

December 21, 2017 at 6:07 pm

IOS XE

The Cisco IOS XE code ensures that as much as possible is modular in the device architecture. As such, note that many separate processes are responsible for a host of functions on the Cisco device. Here is a handy list of common individual processes and their function!

  • Chassis Manager – Responsible for all chassis management functions, including management of the HA state, environmental monitoring, and FRU state control
  • Host Manager – Provides an interface between the IOS process and many of the information-gathering functions of the underlying platform kernel and operating system
  • Logger – IOS facing logging services
  • Interface Manager – Provides an interface between the IOS process and the per-SPA interface processes on the SIP
  • IOS – Implements all forwarding and routing features on the device
  • Forwarding Manager – Manages the downloading of configuration to each of the ESPs and the communication of forwarding plane information, such as statistics, to the IOS process
  • Pluggable Services – The integration point between platform policy application, such as authentication and the IOS process

Network+ 10 Question Quiz 1

December 19, 2017 at 4:52 pm

By request  – a bit longer Network+ quiz featuring new 007 blueprint topics and lots of fun!

Network+ Exam 1

Start
Congratulations - you have completed Network+ Exam 1. You scored %%SCORE%% out of %%TOTAL%%. Your performance has been rated as %%RATING%%
Your answers are highlighted below.
Return
Shaded items are complete.
12345
678910
End
Return

400-101 CCIE R&S Written – Free Resources – CEF

December 16, 2017 at 4:37 pm

CEF

1.1.b Identify Cisco express forwarding concepts

1.1.b [i] RIB, FIB, LFIB, Adjacency table

1.1.b [ii] Load balancing hash

1.1.b [iii] Polarization concepts and avoidance

How to Choose the Best Router Switching Path for Your Network

Troubleshooting Incomplete Adjacencies with CEF

Load Balancing with CEF

CEF Polarization

IP CEF Switching Configuration Guide

BRKARC-2350 – IOS Routing Internals 

AWS Solutions Arch – Compute Services – Lifecycle Hooks

December 13, 2017 at 9:52 pm

Lifecycle Hooks

Overview

You can add a lifecycle hook to your Auto Scaling group so that you can perform custom actions when instances launch or terminate. For example, while your newly launched instance is paused, you could install or configure software on it.

Each Auto Scaling group can have multiple lifecycle hooks. However, there is a limit on the number of hooks per Auto Scaling group.

How Lifecycle Hooks Work

When Auto Scaling responds to a scale-out event, it launches one or more instances. These instances start in the Pending state. If you added an autoscaling:EC2_INSTANCE_LAUNCHING lifecycle hook to your Auto Scaling group, the instances move from the Pending state to the Pending:Wait state. After you complete the lifecycle action, the instances enter the Pending:Proceed state. When the instances is fully configured, they are attached to the Auto Scaling group and they enter the InService state.

When Auto Scaling responds to a scale-in event, it terminates one or more instances. These instances are detached from the Auto Scaling group and enter the Terminating state. If you added an autoscaling:EC2_INSTANCE_TERMINATING lifecycle hook to your Auto Scaling group, the instances move from the Terminating state to the Terminating:Wait state. After you complete the lifecycle action, the instances enter the Terminating:Proceed state. When the instances are fully terminated, they enter the Terminatedstate.

You can perform a custom action using one or more of the following options:

  • Define a CloudWatch Events target to invoke a Lambda function when a lifecycle action occurs. The Lambda function is invoked when Auto Scaling submits an event for a lifecycle action to CloudWatch Events. The event contains information about the instance that is launching or terminating and a token that you can use to control the lifecycle action.
  • Define a notification target for the lifecycle hook. Auto Scaling sends a message to the notification target. The message contains information about the instance that is launching or terminating, and a token that you can use to control the lifecycle action.
  • Create a script that runs on the instance as the instance starts. The script can control the lifecycle action using the ID of the instance on which it runs.

By default, the instance remains in a wait state for one hour, and then Auto Scaling continues the launch or terminate process (Pending:Proceed or Terminating:Proceed). If you need more time, you can restart the timeout period by recording a heartbeat. If you finish before the timeout period ends, you can complete the lifecycle action, which continues the launch or termination process.

Configuration

You can create lifecycle hooks using the put-lifecycle-hook command. For more information on this command – click here.

For more information on Compute services in AWS – see my course at CBT Nuggets.

For a list of course services – see this post.