Three switches are connected to each other as shown in the network diagram. Switches D1 and D2 form the distribution layer, while switch A1 is in the access layer.  The links between the switches are all Gigabit Ethernet. Each of the switches has been left to the default STP configuration, and a partial output from each is shown below.

D1#show spanning-tree vlan 2

VLAN0002

Spanning tree enabled protocol rstp

Bridge ID Priority 32770 (priority 32768 sys-id-ext 2)

Address 001c.570f.5e80

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Aging Time 300

D2#show spanning-tree vlan 2

VLAN0002

Spanning tree enabled protocol rstp

Bridge ID Priority 32770 (priority 32768 sys-id-ext 2)

Address 001c.570f.41f0

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Aging Time 300

A1# show spanning-tree vlan 2

VLAN0002

Spanning tree enabled protocol rstp

Bridge ID Priority 32770 (priority 32768 sys-id-ext 2)

Address 001c.570f.4180

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Aging Time 300

Answer the following questions:

1. Based on the console output, which switch will be elected as the STP root for VLAN 2?
2. Is this the best choice to be the root switch? Why or why not?
3. If the root should be relocated, what configuration commands should be entered on each of the switches to force the appropriate switch to become the root?
4. After configuring the root switch, suppose that a fourth switch, A2, is introduced into the access layer of the network a month later. A2 has an uplink to each of the distribution switches. From switch A2, we can see this partial output:

A2#show spanning vlan 2

VLAN0002

Spanning tree enabled protocol rstp

Bridge ID  Priority    16386  (priority 16384 sys-id-ext 2)

Address     001c.570f.f030

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Aging Time 300

Does the addition of switch A2 sway the election and change the location of the STP root?

Stop here if you don’t want to see the solution!  Otherwise, go on to page 2…

Get a PDF version of this scenario here: PDF

Three switches are connected to each other as shown in the network diagram. Switch A has nothing but links to other switches, while switches B and C have links to switch A, as well as links to end users. The links between switches are provided over fiber optic media; the end users connect via twisted pair copper cables.

All three switches  support  the same set of VLANs, and all three use the Spanning Tree Protocol to prevent bridging loops from forming. You will need to add a Cisco feature to make sure that the links between switches can always support bidirectional traffic. In the event of an odd link failure that prevents data from flowing in one direction, the link must be automatically disabled.

Stop here if you don’t want to see the solution!  Otherwise, go on to page 2…

Get a PDF version of this scenario here: PDF

Today’s scenario involves securing a trunk between two switches…

A user PC A is located on Switch A with the interface configuration shown in the diagram below. A different user PC X is located on Switch B, and that interface configuration is also shown. Switches A and B are connected by a trunk link on their GigabitEthernet1/0/49 interfaces. The same configuration commands that are shown below the link have been applied to both switches. Assume that neither switch A nor B has been configured for IP routing.

See if you can answer the following questions:

1. Given the interface configurations, is it possible for user PC A to send traffic from VLAN 100 onto VLAN 200, so that it reaches PC X? If so, what configuration command(s) make it possible?

2. What configuration commands should you enter into switches A and B to secure the trunk link and prevent any VLAN hopping? (Hint: There may be more than one way to secure the trunk link.)

Enjoy,

Dave H

Switches A and B are connected by a single link. The configurations for each end of the link are shown in the figure below. PCs A, B, and C are connected to access interfaces assigned to VLANs 10, 20, and 30, respectively, on Switch A. PC X is connected to an interface on Switch B, which has the interface configuration shown.

Assuming that the switches are configured for Layer 2 traffic only, which one of the following can PC X reach?

A. PC A

B. PC B

C. PC C

D. None of the above

Enjoy,

Dave H

I’m going to send a CCNP SWITCH Cert Kit to the first five people who meet the following criteria:

1. You have failed to pass the 642-813 SWITCH exam
2. You don’t already have a CCNP SWITCH Cert Kit

If I’ve just described you, then email me at dave@hucaby.net and provide your full name and shipping address. I’ll take care of the rest.

For those who don’t know, the Cert Kit contains a DVD with over five hours of screen recording video of me working through about 20 different LAN switching lab scenarios. The DVD is really more like a mini course. Each lab begins with the theory behind a switch feature, then covers the configuration and testing on actual switches. The Cert Kit also contains the CCNP SWITCH Cert Flash Cards and Quick Reference booklet. It’s a $54 value — yours today for… FREE!

By the way, this is just the first round of giveaways. Stay tuned for more!

Dave H

Dave H

Controlling the Automatic State of an SVI

Because a Layer 3 SVI is bound to a Layer 2 VLAN on a switch, it normally follows the state of the VLAN on that switch automatically. If the switch has at least one Layer 2 interface that is up and active on the VLAN, then the Layer 3 SVI will be brought up, too. If all of the Layer 2 interfaces assigned to the VLAN are down, then the Layer 3 interface will be brought down.

This is the default “autostate” behavior. The idea is to bring the Layer 3 interface down so that routing protocols will cease advertising a route to the IP subnet if there are no active switch interfaces on the VLAN where the subnet exists.

When the SVI autostate feature is enabled, a Layer 3 SVI can come up only if the following three conditions are met:

• The VLAN bound to the SVI exists and is active in the VLAN database on the switch
• The SVI is not administratively shutdown
• At least one Layer 2 interface is assigned to the SVI’s VLAN and is in the up state, with STP forwarding

As an example, a switch has VLAN 2 defined and assigned to a variety of Layer 2 interfaces, but none of the interfaces are up. A Layer 3 SVI called interface vlan2 is then defined. Watch what happens to interface vlan2 in the following console output.

Switch(config)#interface vlan2

Switch(config-if)#

*Apr 21 10:13:10.949: %LINK-3-UPDOWN: Interface Vlan2, changed state to up

Switch(config-if)#

Switch(config-if)#ip address 192.168.1.1 255.255.255.0

Switch(config-if)#^Z

Switch#

Switch#show ip interface brief

Interface              IP-Address      OK? Method Status                Protocol

Vlan1                  unassigned      YES manual administratively down down

Vlan2                  192.168.1.1     YES manual up                    down

FastEthernet1/0/1      unassigned      YES unset  down                  down

FastEthernet1/0/2      unassigned      YES unset  down                  down

Even before an IP address can be configured on the new SVI, the switch brings its status up, but its line protocol stays down. In other words, the SVI now exists and is bound to VLAN 2, but it is unusable until at least one Layer 2 interface becomes active on VLAN 2.

In the following output, notice what happens as a PC is connected to interface FastEthernet1/0/1, which is assigned to VLAN 2.

Switch#

*Apr 21 10:21:31.925: %LINK-3-UPDOWN: Interface FastEthernet1/0/1, changed state to up

*Apr 21 10:21:32.009: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan2, changed state to up

*Apr 21 10:21:32.932: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/1, changed state to up

Switch#

When the Layer 2 interface comes up, so does the line protocol of the SVI. Once the PC is disconnected or powered down, the SVI is automatically taken down, as shown in the following output.

Switch#

*Apr 21 10:21:45.624: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/1, changed state to down

*Apr 21 10:21:45.624: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan2, changed state to down

*Apr 21 10:21:46.622: %LINK-3-UPDOWN: Interface FastEthernet1/0/1, changed state to down

Switch#

You can override the default behavior by disabling autostate on a per-interface basis with the following command:

Switch(config-if)# switchport autostate exclude

When an interface is excluded, any influence that it might have had over the SVI state is removed. This command isn’t normally used unless the interface is a special case, such as an interface where a network analyzer is connected. The analyzer would capture traffic without being an active participant in the VLAN that is assigned to the interface.

Let’s see if we can gather up some facts and ideas that might help with our studies. To come up with a network plan, we have to begin with some goals or objectives. These are generally based on the following things:

• Business requirements – What does the business need out of the network? What policies must be met?
• Business constraints – How much will the planned solution (hardware and labor) cost? How long will it take to implement?
• Technical requirements – Which switch features should be leveraged? How should the switch configurations be carried out? What limitations are there?

As network professionals, we may or may not have a role in identifying these requirements. But we do have a role in carrying out the work. Usually, our work follows this sequence:

1. Plan the network architecture and every switch feature that will be used. This can be done as a detailed project plan or as something sketched on a napkin over lunch. The idea is to know what needs to be done beforehand.
2. Implement the plan with switches, cables, protocols, and features. The CCNP exams have traditionally focused on implementing things.
3. Verify that the implementation works and meets the objectives of the plan.

Now let’s hold that up against the new exam blueprint. There are several broad categories where we find the words “implement” and “verify”, always with the words “create…a plan”.

Create a VLAN-based implementation plan
Create a VLAN-based verification plan

Create an implementation plan for the Security solution
Create a verification plan for the  Security solution

Create an implementation plan for the Switch-based Layer 3 solution
Create a verification plan for the Switch-based Layer 3 solution

Create a High Availability implementation plan
Create a High Availability verification plan

How would we “create a plan” on a Cisco exam? We might get multiple choice questions that ask for a best approach to a problem. More likely, we might get one of those complex scenario questions. You know – the ones where you have to read a lengthy explanation in one window, squint at the network diagram in another window, and interact with some switches in some other windows – all on one small screen.

The key here is with the scenario description. It’s nothing more than a huge word problem that lays out things like business requirements, business constraints, and a list of goals to reach. Even the network diagram becomes a part of the project definition. As you read through the scenario and look over the diagram, you have to create an implementation plan in your mind. The scenarios don’t give you a sequence of things to do; instead, they present a bunch of things to accomplish. You have to figure out what specific features you’ll need, what steps you’ll need to configure for each feature, which switch you’ll have to visit to type in configuration commands, and so on.

Even as you work through a scenario on the exam, you should spend time creating a verification plan so you can test and make sure each feature you have configured actually works as it should. Otherwise, whatever you typed into the switch emulators might not be correct and might not earn you points.

Why did Cisco move toward such broad strokes on the exam blueprint? I think it’s to test our knowledge of the many Cisco IOS features and which ones can be used to accomplish something. For example, the exam blueprint covers VLAN-based plans, Security plans, Switch-based Layer 3 plans, and High Availability plans. Those don’t say much about switch features, commands, or protocols. Instead, think of each one as a big toolbox. We have to know which tools are in each toolbox. As the old saying goes, not every problem needs a hammer.

Let’s work through an example scenario to get a feel for this. The exam question has scenario text as follows:

A company has a network as shown in the network diagram. Switches A and B form the core, while C and D act as distribution switches. Switches A through D are already configured with working links and routing protocols.

Switch E is added into the access layer. It is connected to switches C and D by two uplinks each. Each pair of uplinks should be joined together as a single logical link using a standards-based approach.

Switch E needs to support two distinct groups of users in the Accounting and Engineering departments, to be placed on VLAN 10 and 20, respectively. Each VLAN needs to have a highly available gateway address using the .1 address in the appropriate subnet. The network should be configured such that the Accounting users normally pass over the link between switches C and E, while Engineering users pass over the link between D and E.

Do not change the routing configuration on switches A, B, C, or D, other than to advertise the new Accounting and Engineering subnets. Make sure that all uplinks are functioning and that users in the Accounting and Engineering subnets can ping  the 192.168.199.10 server located in the data center.

Network Diagram for the Sample Scenario Exam Question

Whew! That scenario covers plenty of ground, and it’s really just one question on the exam! Notice that the scenario didn’t really specify any switch features or protocols to be used. Instead, we have to put on our thinking caps and develop an implementation plan  — fast! Remember that the exam clock is ticking. Our plan should include the following things:

• Create VLANs – VLAN 10 for Accounting and VLAN 20 for Engineering
• VLAN extent – the VLANs should exist on Switch E, where the users live, and also on C and D, where the gateways and routing protocols live.
• EtherChannels – Bundle one pair of uplinks between C and E and another pair between D and E. For a standards-based EtherChannel, we need to use LACP.
• Trunks – VLANs 10 and 20 will need to be carried between switches C and E and between D and E.
• Layer 3 interfaces – We’ll need an interface vlan10 and an interface vlan20 to provide Layer 3 connectivity for the user subnets. Those will be configured on switches C and D.
• HSRP – To get highly available gateways on both VLANs 10 and 20, we’ll need to configure two different HSRP groups.
• HSRP load balancing – The two user groups need to normally pass over different uplinks. We’ll need to tune the HSRP priorities so that the gateways are split across the two distribution switches.
• Routing – We will need to add the new subnets into the network commands for the preconfigured routing protocols on switches C and D.

The scenario also mentions some things we need to test and verify. Our mental verification plan can include things like the following:

To test that the server is reachable from each user subnet, a regular, simple ping won’t do. Instead, it’s better to use extended pings so that the source address can be set to the Layer 3 interface that sits on each user subnet.

———-

So, where should we go next? For me, the hardest part about these scenario-based exam questions is interacting with the emulated switches – especially when I’m under a time crunch. Would it be helpful if I post the configuration commands for each switch? Would you like to see more scenarios posted for practice?

Dave H

IP SLA

The Cisco IOS IP Service Level Agreement (IP SLA) feature can be used to gather realistic information about how specific types of traffic are being handled end-to-end across a network. To do this, an IP SLA device runs a preconfigured test and generates traffic that is destined for a far end device. As the far end responds with packets that are received back at the source, IP SLA gathers data about what happened along the way.

IP SLA can be configured to perform a variety of tests. The simplest test involves ICMP echo packets that are sent toward a target address, as shown in Figure 13-8. If the target answers with ICMP echo replies, IP SLA can then assess how well the source and destination were able to communicate. In this case, the echo failures (packet loss) and round trip transit (RTT) times are calculated, as shown in the following example:

Switch#show ip sla statistics aggregated

Round Trip Time (RTT) for       Index 1

Type of operation: icmp-echo

Start Time Index: 15:10:17.665 EDT Fri May 21 2010

RTT Values

Number Of RTT: 24

RTT Min/Avg/Max: 1/1/4 ms

Number of successes: 24

Number of failures: 0

Figure 13-8 IP SLA ICMP Echo Test Operation

For the ICMP echo test, IP SLA can use any live device at the far end. After all, most every networked device will reply when it is pinged. IP SLA can also test some network protocols, such as DNS, by sending requests to a server at the far end. Cisco IOS is needed only at the source of the IP SLA test, as the far end is simply responding to ordinary request packets.

However, IP SLA is capable of running much more sophisticated tests. Table 13-8 shows some example test operations that are available with IP SLA.

Table 13-8         IP SLA Test Operations

To leverage its full capabilities, Cisco IOS IP SLA must be available on both the source and the target devices, as shown in Figure 13-9. The source device handles the test scheduling and sets up each test over a special IP SLA control connection with the target device. The source generates the traffic involved in a test operation, and analyzes the results as packets return from the target. The target end has a simpler role — respond to the incoming test packets. In fact, the target device is called an IP SLA Responder.

Figure 13-9 IP SLA UDP Jitter Test Operation

The responder must also add timestamps to the packets it sends, to flag the time a test packet arrived and the time it left the responder. The idea is to account for any latency that is incurred while the responder is processing the test packets. For this to work accurately, both the source and responder must synchronize their clocks through NTP.

An IP SLA source device can schedule and keep track of multiple test operations. For example, an ICMP echo operation might run against target 10.1.1.1, while UDP jitter operations are running against targets 10.2.2.2, 10.3.3.3, and 10.4.4.4. Each test runs independently, at a configured frequency and duration.

What in the world does this have to do with LAN switching? And why would you want to run IP SLA on a Catalyst switch anyway? Here’s a two-fold answer:

• IP SLA will likely appear on the CCNP SWITCH exam
• IP SLA is actually a useful tool in a switched campus network

In order to run live tests and take useful measurements without IP SLA, you would need to place some sort of probe devices at various locations in the network — all managed from a central system. With IP SLA, you don’t need probes at all! Wherever you have a Catalyst switch, you already have an IP SLA “probe”.

By leveraging IP SLA test operations, you can take advantage of some fancy features:

• Generate SNMP traps when certain test thresholds are exceeded
• Schedule further IP SLA tests automatically when test thresholds are crossed
• Track an IP SLA test to trigger a next-hop gateway redundancy protocol, such as HSRP
• Gather voice quality measurements from all over a network

Configuring IP SLA

You can use the following configuration steps to define and run an IP SLA test operation.

Step 1. Enable the IP SLA responder on the target switch

Switch(config)# ip sla responder

By default, the IP SLA responder is disabled. If the IP SLA operation will involve jitter or time-critical measurements, then the responder should be enabled on the target switch.

Step 2. Define a new IP SLA operation o the source switch

Switch(config)# ip sla operation-number

The operation-number is an arbitrary index that can range from 1 to a very large number. This number uniquely identifies the test.

Step 3. Select the type of test operation to perform

Switch(config-ip-sla)# test-type parameters...

The test-type keyword can be one of the following:

dhcp, dns, ethernet, ftp, http, icmp-echo, mpls, path-echo, path-jitter, slm, tcp-connect, udp-echo, or udp-jitter

The list of parameters following the test-type varies according to the test operation. As an example, consider the following icmp-echo operation syntax:

Switch(config-ip-sla)# icmp-echo destination-ip-addr [source-ip-addr]

The parameters are simple[md]a destination address to ping, and an optional source address to use. If a switch has several Layer 3 interfaces, you can specify which one of their IP address to use as the source of the test packets.

As another example, the udp-jitter command is useful for testing time-critical traffic paths through a switched network. The command syntax is a little more complex, as follows:

Switch(config-ip-sla)# udp-jitter destination-ip-addr dest-udp-port [source-ip source-ip-addr] [source-port source-udp-port] [num-packets number-of-packets] [interval packet-interval]

In addition to the source and destination IP addresses, you can define the UDP port numbers that will be used for the packet stream. By default, 10 packets spaced at 20 milliseconds will be sent. You can override that by specifying the num-packets and interval keywords.

As an alternative, you can configure the udp-jitter operation to test Voice Over IP (VoIP) call quality. To do this, the udp-jitter command must include the codec keyword and a codec definition. The IP SLA operation will then simulate a real-time stream of voice traffic using a specific codec. In this way, you can tailor the test to fit the type of calls that are actually being used in the network.

You can define the UDP jitter codec operation by using the following command syntax:

Switch(config-ip-sla)# udp-jitter destination-ip-addr dest-udp-port codec {g711alaw | g711ulaw | g729a}

There are other keywords and parameters you can add to the command, but those are beyond the scope of this book. By default, 1000 packets are sent, 20 milliseconds apart.

Step 4. Schedule the test operation

Switch(config)# ip sla schedule operation-number [life {forever | seconds}] [start-time {hh:mm[:ss] [month day | day month] | pending | now | after hh:mm:ss}] [ageout seconds] [recurring]

In a nutshell, the command tells the switch when to start the test, how long to let it run, and how long to keep the data that is collected.

Set the lifetime with the life keyword: forever means the operation will keep running forever, until you manually remove it. Otherwise, specify how many seconds it will run. By default, an IP SLA scheduled operation will run for 3600 seconds (one hour).

Set the start time with the start-time keyword. You can define the start time as a specific time, date, after a delay with the after keyword, or right now with the now keyword.

By default, the test statistics are collected and held in memory indefinitely. You can use the ageout keyword to specify how many seconds elapse before the data is aged out.

The recurring keyword can be used to schedule the test operation to run at the same time each day, as long as you have defined the starting time with hh:mm:ss, too.

TIP

Be aware that the IP SLA operation command syntax has changed along the way. In Cisco IOS releases 12.2(33) and later, the syntax is as shown in steps 2 through 4.

Prior to 12.2(33), the commands in steps 2 through 4 included additional keywords, as follows:

Step 2. ip sla monitor operation-number

Step 3. type test-type 

Step 4. ip sla monitor schedule operation-number

It isn’t clear which version of the IP SLA commands are used in the SWITCH exam; just be prepared to see the syntax in either form.

Using IP SLA

Once you have configured an IP SLA operation, you can verify the configuration with the show ip sla configuration [operation-number] command. As an example, the following configuration commands are used to define IP SLA operation 100 — an ICMP echo test that pings target 172.25.226.1 every 5 seconds.

Switch(config)# ip sla 100

Switch(config-ip-sla)# icmp-echo 172.25.226.1

Switch(config-ip-sla)# frequency 5

Switch(config-ip-sla)# exit

Switch(config)# ip sla schedule 100 life forever start-time now

Example 13-13 shows the output of the corresponding  show ip sla configuration command.

Example 13-13 — Displaying the Current IP SLA Configuration

Switch#show ip sla configuration

IP SLAs, Infrastructure Engine-II

Entry number: 100

Owner:

Tag:

Type of operation to perform: echo

Target address: 172.25.226.1

Source address: 0.0.0.0

Request size (ARR data portion): 28

Operation timeout (milliseconds): 5000

Type Of Service parameters: 0x0

Verify data: No

Vrf Name:

Schedule:

Operation frequency (seconds): 5

Next Scheduled Start Time: Start Time already passed

Group Scheduled : FALSE

Randomly Scheduled : FALSE

Life (seconds): Forever

Entry Ageout (seconds): never

Recurring (Starting Everyday): FALSE

Status of entry (SNMP RowStatus): Active

Threshold (milliseconds): 5000

Distribution Statistics:

Number of statistic hours kept: 2

Number of statistic distribution buckets kept: 1

Statistic distribution interval (milliseconds): 20

History Statistics:

Number of history Lives kept: 0

Number of history Buckets kept: 15

History Filter Type: None

Enhanced History:

You can use the show ip sla statistics [aggregated] [operation-number] command to display the IP SLA test analysis. By default, the most recent test results are shown. You can add the aggregated keyword to show a summary of the data gathered over the life of the operation. Example 13-14 shows the statistics gathered for ICMP echo operation 100.

Example 13-14 — Displaying IP SLA Statistics

Switch#show ip sla statistics 100

Round Trip Time (RTT) for       Index 100

Latest RTT: 1 ms

Latest operation start time: 15:52:00.834 EDT Fri May 28 2010

Latest operation return code: OK

Number of successes: 117

Number of failures: 0

Operation time to live: Forever

Switch# show ip sla statistics aggregated 100

Round Trip Time (RTT) for       Index 100

Type of operation: icmp-echo

Start Time Index: 15:43:55.842 EDT Fri May 28 2010

RTT Values

Number Of RTT: 121

RTT Min/Avg/Max: 1/1/4 ms

Number of successes: 121

Number of failures: 0

It isn’t too difficult to configure an IP SLA operation manually and check the results every now and then. But does IP SLA have any greater use? Yes, you can also use an IP SLA operation to make some other switch features change behavior automatically, without any other intervention.

For example, HSRP can track the status of an IP SLA operation to lower automatically decrement the priority value when the target device stops answering ICMP echo packets. To do this, begin by using the track command to define a unique track object-number index that will be bound to the IP SLA operation number.

Switch(config)# track object-number ip sla operation-number {state | reachability}

You can use the state keyword to track the return code or state of the IP SLA operation; the state is up if the IP SLA test was successful or down if it wasn’t. The reachability keyword is slightly different[em]the result is up if the IP SLA operation is successful or has risen above a threshold; otherwise, the reachability is down.

Next, configure the HSRP standby group to use the tracked object to control the priority decrement value. As long as the tracked object (the IP SLA operation) is up or successful, the HSRP priority stays unchanged. If the tracked object is down, then the HSRP priority is decremented by decrement-value (default 10).

Switch(config-if)# standby group track object-number decrement decrement-value

In Example 13-15, SwitchA and SwitchB are configured as an HSRP pair, sharing gateway address 192.168.1.1. SwitchA has a higher priority than SwitchB, so it is normally the active gateway. However, it is configured to ping an upstream router at 192.168.70.1 every five seconds; if that router doesn’t respond, SwitchA will decrement its HSRP priority by 50, permitting SwitchB to take over.

Example 13-15 — Tracking an IP SLA Operation in an HSRP Group

Switch(config)# ip sla 10

Switch(config-ip-sla)# icmp-echo 192.168.70.1

Switch(config-ip-sla)# frequency 5

Switch(config-ip-sla)# exit

Switch(config)# ip sla schedule 10 life forever start-time now

Switch(config)# track 1 ip sla 10 reachability

Switch(config)# interface vlan10

Switch(config-if)# ip address 192.168.1.3 255.255.255.0

Switch(config-if)# standby 1 priority 200

Switch(config-if)# standby 1 track 1 decrement 50

Switch(config-if)# no shutdown

In some cases, you might need many IP SLA operations to take many measurements in a network. For example, you could use UDP jitter operations to measure voice call quality across many different parts of the network. Manually configuring and monitoring more than a few IP SLA operations can become overwhelming and impractical. Instead, you can leverage a network management application that can set up and monitor IP SLA tests automatically. To do this, the network management system needs SNMP read and write access to each switch that will use IP SLA. Tests are configured by writing to the IP SLA MIB, and results are gathered by reading the MIB.

Welcome to the learning curve.

Dave H

Dave H

————————————–

SNMP

The Simple Network Management Protocol (SNMP) is a protocol that allows a network device to share information about itself and its activities. A complete SNMP system consists of the following parts:

• SNMP Manager — A network management system that uses SNMP to poll and receive data from any number of network devices. The SNMP Manager is usually an application that runs in a central location.
• SNMP Agent — A process that runs on the network device being monitored. All types of data are gathered by the device itself and stored in a local database. The agent can then respond to SNMP polls and queries with information from the database and it can send unsolicited alerts or “traps” to an SNMP Manager.

In the case of Catalyst switches in the network, each switch automatically collects data about itself, its resources, and each of its interfaces. This data is stored in a Management Information Base (MIB) database in memory, and is updated in real time.

The MIB is organized in a structured, hierarchical fashion, forming a tree structure. In fact, the entire MIB is really a collection of variables that are stored in individual, more granular MIBs that form the branches of the tree. Each MIB is based on the Abstract Syntax Notation 1 (ASN.1) language. Each variable in the MIB is referenced by an object identifier (OID) — a long string of concatenated indexes that follow the path from the root of the tree all the way to the variable’s location.

Fortunately, only the SNMP manager and agent need to be concerned with interpreting the MIBs.  As far as the SWITCH exam and course go, you should just be aware that the MIB structure exists and that it contains everything that can be monitored about a switch.

To see any of the MIB data, an SNMP manager has to send an SNMP poll or query to the switch. The query contains the OID of the specific variable being requested so that the agent running on the switch knows what information to return. An SNMP manager can use the following mechanisms to communicate with an SNMP agent, all over UDP port 161:

• Get Request — The value of one specific MIB variable is needed.
• Get Next Request — The next or subsequent value following an initial Get Request is needed.
• Get Bulk Request — Whole tables or lists of values in a MIB variable are needed.
• Set Request — A specific MIB variable needs to be set to a value.

SNMP polls or requests are usually sent by the SNMP manager at periodic intervals. This makes real-time monitoring difficult, as changing variables won’t be noticed until the next poll cycle. However, SNMP agents can send unsolicited alerts to notify the SNMP manager of real-time events at any time. Alerts can be sent using the following mechanisms, over UDP port 162:

• SNMP Trap — News of an event (interface state change, device failure, and so on) is sent without any acknowledgement that the trap has been received.
• Inform Request — News of an event is sent to an SNMP manager, and the manager is required to acknowledge receipt by echoing the request back to the agent.

As network management has evolved, SNMP has developed into three distinct versions. The original, SNMP version 1 (SNMPv1), is defined in RFC1157. It uses simple one-variable Get and Set requests, along with simple SNMP Traps. SNMP managers can gain access to SNMP agents by matching a simple “community” text string. When a manager wants to read or write a MIB variable on a device, it sends the community string in the clear, as part of the request. If that community string matches the agent’s community string, then the request is granted.

In theory, only managers and agents belonging to the same “community” should be able to communicate. In practice, any device has the potential to read or write variables to an agent’s MIB database by sending the right community string, whether it’s a legitimate SNMP manager or not. This creates a huge security hole in SNMPv1.

The second version of SNMP, SNMPv2C (RFC 1901), was developed to address some efficiency and security concerns. For example, SNMPv2c adds 64-bit variable counters, extending the useful range of values over the 32-bit counters used in SNMPv1. In addition, SNMPv2C offers the Bulk Request, making MIB data retrieval more efficient. It also offers Inform Requests, which make real-time alerts more reliable by requiring confirmation of receipt.

Despite the intentions of its developers, SNMPv2C does not address any security concerns over that of SNMPv1. SNMPv2C does offer 64-bit variable counters, which extend the capability to keep track of very large numbers like byte counters found on very high speed interfaces. With SNMPv2C, MIB variables can be obtained in a bulk form with a single request. In addition, event notifications sent from an SNMPv2C agent can be in the form of SNMP traps or inform requests. The latter form requires an acknowledgement from the SNMP manager that the inform message was received.

The third generation of SNMP, SNMPv3, is defined in RFCs 3410 through 3415. It addresses the security features that are lacking in the earlier versions. SNMPv3 can authenticate SNMP managers through usernames. When usernames are configured on the SNMP agent of a switch, they can be organized into SNMPv3 group names.

Each SNMPv3 group is defined with a security level that describes the extent to which the SNMP data will be protected. Data packets can be authenticated to preserve their integrity, encrypted to obscure their contents, or both. The following security levels are available. The naming scheme uses “auth” to represent packet authentication and “priv” to represent data privacy or encryption.

• noAuthNoPriv — SNMP packets are neither authenticated nor encrypted.
• authNoPriv — SNMP packets are authenticated, but not encrypted.
• authPriv — SNMP packets are authenticated and encrypted.

As a best practice, you should use SNMPv3 to leverage its superior security features whenever possible. If you must use SNMPv1 for a device, you should configure the switch to limit SNMP access to a read-only role. Never permit read-write access because the simple community string authentication can be exploited to make unexpected changes to a switch configuration.

Catalyst switches offer one additional means of limiting SNMP access[md]an access list can be configured to permit only specific SNMP manager IP addresses. You should configure and apply an access list to your SNMP configurations whenever possible.

Because SNMP is a universal method for monitoring all sorts of network devices, it isn’t unique to LAN switches. Therefore, you should understand the basics of how SNMP works, the differences between the different SNMP versions, and how you might apply SNMP to monitor a switched network. You can use Table 13-7 as a memory aid for your exam study.

Table 13-7 – A Comparison of SNMP Versions and Their Features

Configuring SNMPv1 and SNMPv2C

You should be familiar with the basic SNMP configuration. Fortunately, this involves just a few commands, as follows:

Switch(config)# access-list access-list-number permit ip-addr

Switch(config)# snmp-server community string [ro | rw] [access-list-number]

!

Switch(config)# snmp-server host host-address community-string [trap-type]

First, define a standard IP access list that permits only the IP addresses of your SNMP agent machines. Then apply that access list to the SNMPv1 community string with the snmp-server community command. Use the ro keyword to allow read-only access by the SNMP manager; otherwise, use the rw keyword to allow both read and write access.

Finally, use the snmp-server host command to identify the IP address of the SNMP manager where SNMP traps will be sent. By default, all types of traps are sent. You can use the ? key in place of trap-type to see a list of the available trap types.

In Example 13-11, the switch is configured to allow SNMP polling from network management stations at 192.168.3.99 and 192.168.100.4. The community string “MonitorIt” is used to authenticate the SNMP requests. All possible SNMP traps are sent to 192.168.3.99.

Example 13-11 Configuring SNMPv1 Access

Switch(config)# access-list 10 permit 192.168.3.99
Switch(config)# access-list 10 permit 192.168.100.4
Switch(config)# snmp-server community MonitorIt ro 10
Switch(config)# snmp-server host 192.168.3.99 MonitorIt

Configuring SNMPv2C

Configuring SNMPv2C is very similar to SNMPv1. The only difference is with SNMP trap or inform configuration. You can use the following commands to configure basic SNMPv2C operation:

Switch(config)# access-list access-list-number permit ip-addr

Switch(config)# snmp-server community string [ro | rw] [access-list-number]

!

Switch(config)# snmp-server host host-address [informs] version 2c community-string

In the snmp-server host command, use the version 2c keywords to identify SNMPv2C operation. By default, regular SNMP traps are sent. To use inform requests instead, add the informs keyword.

Configuring SNMPv3

SNMPv3 configuration is a bit more involved than versions 1 or 2C, due mainly to the additional security features.

Switch(config)# access-list access-list-number permit ip-addr

!

Switch(config)# snmp-server group group-name v3 {noauth | auth | priv}

Switch(config)# snmp-server user user-name group-name v3 auth {md5 | sha} auth-password priv {des | 3des | aes {128 | 192 | 256} priv-password [access-list-number]

!

Switch(config)# snmp-server host host-address [informs] version 3 {noauth | auth | priv} user-name [trap-type]

First, use the snmp-server group command to define a group-name that will set the security level policies for SNMPv3 users. The security level is defined by the noauth (no packet authentication or encryption), auth (packets are authenticated but not encrypted), or priv (packets are both authenticated and encrypted) keyword. Only the security policy is defined in the group; no passwords or keys are required yet.

TIP

The SNMPv3 priv keyword and packet encryption can be used only if the switch is running a cryptographic version of its IOS software image. The auth keyword and packet authentication can be used regardless.

Next, define a username that an SNMP manager will use to communicate with the switch. Use the snmp-server user command to define the user-name and associate it with the SNMPv3 group-name. The v3 keyword configures the user to use SNMPv3.

The SNMPv3 user must also have some specifics added to its security policy. Use the auth keyword to define either MD5 or SHA as the packet authentication method, along with the auth-password text string that will be used in the hash computation. The priv keyword defines the encryption method (DES, 3DES, or AES 128/192/256-bit) and the priv-password text string that will be used in the encryption algorithm.

The same SNMPv3 username, authentication method and password, and encryption method and password must also be defined on the SNMP manager so it can successfully talk to the switch.

Finally, you can use the snmp-server host command to identify the SNMP manager that will receive either traps or informs. The switch can use SNMPv3 to send traps and informs, using the security parameters that are defined for the SNMPv3 user-name.

In Example 13-12, a switch is configured for SNMPv3 operation. Access list 10 permits only stations at 192.168.3.99 and 192.168.100.4 with SNMP access. SNMPv3 access is defined for a group named “NetOps”, using the priv (authentication and encryption) security level. One SNMPv3 user named “mymonitor” is defined; the network management station will use that username when it polls the switch for information. The username will require SHA packet authentication and AES-128 encryption, using the “s3cr3tauth” and “s3cr3tpr1v” passwords, respectively.

Finally, SNMPv3 informs will be used to send alerts to station 192.168.3.99 using the priv security level and username “mymonitor”.

Example 13-12 Configuring SNMPv3 Access

Switch(config)# access-list 10 permit 192.168.3.99
Switch(config)# access-list 10 permit 192.168.100.4
Switch(config)# snmp-server group NetOps v3 priv
Switch(config)# snmp-server user mymonitor NetOps v3 auth sha s3cr3tauth priv aes 128 s3cr3tpr1v 10
Switch(config)# snmp-server host 192.168.3.99 informs version 3 priv mymonitor