http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_25_see/command/reference/cli3.html#wp2168243

Today I was troubleshooting a problem at a newly renovated remote office with an IP phone that would power up but not boot. After swapping cables and phones, I remembered the TDR and tried it out:

Switch# test cable-diagnostics tdr interface g1/0/14
TDR test started on interface Gi1/0/14
A TDR test can take a few seconds to run on an interface
Use 'show cable-diagnostics tdr' to read the TDR results.
Switch#show cable-diagnostics tdr  interface gigabitEthernet 1/0/14
TDR test last run on: March 04 22:31:09

Interface Speed Local pair Pair length        Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi1/0/14  auto  Pair A     19   +/- 4  meters N/A         Open
                Pair B     4    +/- 4  meters N/A         Open
                Pair C     20   +/- 4  meters N/A         Open
                Pair D     20   +/- 4  meters N/A         Open

Looks like a problem on Pair B! You should have heard the suprise from the (telecom) guy on the other end of the line when I finally said "looks like a problem in the cabling, get the contractor to check pair B.

Content Copyright Sean Walberg

Using a 3750 to test cables

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Compared with the previous incarnation, this one is far more in depth — more analysis of spanning trees, in depth question on multicast, HSRP, GLBP. Several questions where you were given some show commands or debugs and asked to interpret what’s going on. The simulations were very straightforward.

I mostly used the new CCNP Self-Study: Building Cisco Multilayer Switched Networks (BCMSN), 3rd Edition (ISBN 1-58705-219-9)and some reading on cisco.com (and on the job experience, of course). I also flipped through the corresponding exam prep guide by Cisco Press, though it turned out to be the second edition which older.

Cisco Press generally puts out two books for each exam, one is the exam certification guide that is focused on the exam. The other is the foundation guide, which is basically the course notes that have been expanded into a book, and is what I used.

In this case, the exam prep guide was older and had some topics that were no longer valid, and were missing some content. The foundation book was far more in depth on all the right topics.

I found the foundation guide to be well written, though when I was reading docs on STP on CCO I found them to be nearly identical to the book. In most cases the book had done a good job of distilling the online content, though I remember one case where the online version had a worked out example for 802.1s/w that clarified a doubt I had.

All in all I’m happy with my results. The book I used did a good job of guiding me through the topics that I don’t have experience in, and even pointed out a couple of things in the areas that I work with daily. If I had to go back I’d have studied more on MST and multicast, which seemed to be the areas that I had the most problems.

I saved a lot of links that might prove helpful.

Content Copyright Sean Walberg

Passed BCMSN

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

The exam seems to only care about Protocol Independent Multicast (PIM), which uses the router’s routing table to determine whether or not a multicast packet is to be forwarded. When packet is received on an interface the router looks at the route back to the source. If the interface the packet was received on is the same as the one it would use to send a response, the reverse path forwarding test is sucessful and the packet is forwarded.

PIM operates in two modes, sparse and dense. In sparse mode it is assumed that most people don’t care about the stream and therefore the router must explicity add branches to the multicast tree. In dense mode it is assumed that there are a lot of listeners, and it is the obligation of the router to prune. This is handled through IGMP which is another article.

Consider the following network:

R5 has its E0 interface shut down so that the serial link is used.

I set up everything in PIM dense mode, meaning I needed only

ip pim dense-mode

on every interface.

From R0

r0#show ip pim neighbor
PIM Neighbor Table
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
2.2.2.1           Multilink1               1d02h/00:01:43    v2    1 / S
10.50.0.3         Ethernet0                1d02h/00:01:24    v2    1 / DR S

the output of that shows two PIM adjacencies, one out the multilink (R1) and one on the Ethernet (R3). Under the "Mode" column, S means "state refresh capable" and DR means that the router is the designated router for the segment.

To test multicast, I used Multicast Routing Monitor to generate traffic:

r1#show run int mu1
Building configuration...

Current configuration : 138 bytes
!
interface Multilink1
 ip address 2.2.2.1 255.255.255.252
 ip pim sparse-mode
 ip mrm test-sender
 ppp multilink
 multilink-group 1
end

R0:

ip mrm manager test1
 manager Ethernet0 group 239.1.1.1
 senders 1
 receivers 2 sender-list 1
access-list 1 permit 2.2.2.1
access-list 2 permit 5.5.5.5
access-list 2 permit 10.50.0.3
r3#show run int e0
Building configuration...

Current configuration : 111 bytes
!
interface Ethernet0
 ip address 10.50.0.3 255.255.255.0
 ip pim sparse-dense-mode
 ip mrm test-receiver
end

A similar receiver exists on R5's loop0.

The mrm tester on R0 sets up a multicast stream from 2.2.2.1 to 5.5.5.5 and 10.50.0.3 using multicast group 239.1.1.1:

r0#show ip mrm manager
Manager:test1/10.50.0.1 is not running
  Beacon interval/holdtime/ttl:60/86400/32
  Group:239.1.1.1, UDP port test-packet/status-report:16384/65535
  Test senders:
    2.2.2.1
  Test receivers:
    5.5.5.5                  10.50.0.3

Finally, the test can be started:

r0#mrm test1 start
r0#
1d03h: IP MRM test 'test1' starts ......
1d03h: IP MRM status report -- Test:test1  Receiver:10.50.0.3
1d03h:   Sender:2.2.2.1          Pkt Loss:1(4%)  Ehsr:8
1d03h: IP MRM status report -- Test:test1  Receiver:5.5.5.5
1d03h:   Sender:2.2.2.1          Pkt Loss:5(20%)  Ehsr:0
1d03h: IP MRM status report -- Test:test1  Receiver:10.50.0.3
1d03h:   Sender:2.2.2.1          Pkt Loss:1(4%)  Ehsr:8
1d03h: IP MRM status report -- Test:test1  Receiver:5.5.5.5
1d03h:   Sender:2.2.2.1          Pkt Loss:5(20%)  Ehsr:0
1d03h: IP MRM status report -- Test:test1  Receiver:5.5.5.5
1d03h:   Sender:2.2.2.1          Pkt Loss:15(60%)  Ehsr:0
1d03h: IP MRM status report -- Test:test1  Receiver:5.5.5.5
1d03h:   Sender:2.2.2.1          Pkt Loss:20(80%)  Ehsr:0
1d03h: IP MRM status report -- Test:test1  Receiver:5.5.5.5
1d03h:   Sender:2.2.2.1          Pkt Loss:25(100%)  Ehsr:0
1d03h: IP MRM status report -- Test:test1  Receiver:5.5.5.5
1d03h:   Sender:2.2.2.1          Pkt Loss:25(100%)  Ehsr:0

I see a bit of loss at the beginning, but after that it stops:

r0#show ip mrm manager
Manager:test1/10.50.0.1 is running, expire:23:56:53
  Beacon interval/holdtime/ttl:60/86400/32
  Group:239.1.1.1, UDP port test-packet/status-report:16384/65535
  Test senders:
    2.2.2.1          /Ack
  Test receivers:
    5.5.5.5          /Ack    10.50.0.3        /Ack

From R5, looking at the multicast route:

r5#show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:06:43/stopped, RP 10.50.0.3, flags: SJPC
  Incoming interface: Ethernet0, RPF nbr 10.50.0.3
  Outgoing interface list: Null

(2.2.2.1, 239.1.1.1), 00:06:43/00:02:54, flags: PTX
  Incoming interface: Ethernet0, RPF nbr 10.50.0.1
  Outgoing interface list: Null
r0#show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 01:27:52/stopped, RP 10.50.0.3, flags: SJCF
  Incoming interface: Ethernet0, RPF nbr 10.50.0.3
  Outgoing interface list:
    Multilink1, Forward/Dense, 01:27:52/00:00:00

(2.2.2.1, 239.1.1.1), 01:27:52/00:02:51, flags: FT
  Incoming interface: Multilink1, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet0, Forward/Dense, 00:05:32/00:00:00, A

r3#show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 01:28:24/00:03:25, RP 10.50.0.3, flags: SJCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet0, Forward/Sparse-Dense, 01:28:23/00:03:25

(2.2.2.1, 239.1.1.1), 01:28:24/00:02:59, flags: PLT
  Incoming interface: Ethernet0, RPF nbr 10.50.0.1
  Outgoing interface list: Null

Content Copyright Sean Walberg

Multicast – PIM implementation and testing with MRM

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

What is multicast?

Multicast is “one to many”, rather than “one to one” for unicast, and “one to all” for broadcast. The basic premise is that one host sends a packet to a multicast group, and only people interested get the traffic. The trick here is how to serve traffic to interested people while not flooding the network unnecessarily.

“Unnecessarily” means that the network doesn’t have to carry the traffic multiple times. If a multicast stream goes to 5 people, only one copy is sent. Routers and switches replicate the traffic as necessary, ensuring that traffic is kept to a minimum.

Multicast addressing

Multicast uses the class D address space, from 224.0.0.0 to 239.255.255.255. 224.0.0.0/24 is reserved for local LAN use (ie traffic that shouldn’t cross a router), 224.0.1.0/24 is for network control, and 239.0.0.0/8 is the “Administratively Scoped”, ie local use block. There are some other designations, but those are the main ones.

A host sends a packet to a multicast address, and never from. However there must be a layer 2 address to send the traffic to, one that must be recognized as a multicast and treated appropriately.

The IP multicast address consists of 28 bits. The ethernet multicast consists of 23. Thus, 5 bits are ignored, leading to 32 IP multicast addresses corresponding to each MAC address.

To convert from IP to MAC, simply take the 23 lower order bits of the IP address and prepend 01.00.5e. So, 224.0.0.1 becomes 0100.5e00.0001. The easiest way (that I can think of is)

- write down 0100.5e and ignore the first (from the left) octet of the IP address
- If the second octet of the IP is > 128, then subtract 128 from it (to compensate for the ignored 24th bit)
- convert the three octets to hex and copy into the MAC address

Likewise, to go from MAC to IP

- Drop the 0100.5e
- Convert each pair of nybbles left into decimal
- The valid multicast groups are then {224-239}.{x1,y1}.x2.x3 where y1 = the first decimal number + 128

ie

0100.5e10.7101 becomes 0×10, 0×71, 0×01 which is 16 113 1

Valid multicast addresses are then 224.16.113.1, 224.144.113.1, 225.16.113.1, and so forth.

Next up is some sample PIM configuration and how to test multicast. I’m not sure how detailed the exam gets, from what I’ve heard it’s pretty light, focusing mostly on the above.

Content Copyright Sean Walberg

Multicast

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

On most switches with a hardware priority queue (egress expedite queue) like the 3550, it’s statically assigned to queue 4 (on switches with 4 queues). Some switches like the 4500s let you switch the queue, but generally it’s on silicon so you’re stuck. No problem.

However, on the 3560 it’s queue 1. Luckily the commands are different (wrr-queue vs srr-queue) but it’s not exactly obvious that the pq isn’t in the same place.

I haven’t checked the 3750 series, I suspect they’ll also be on queue 1.

Content Copyright Sean Walberg

Hardware priority queues on Catalyst switches

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

The exam outline has the following items related to STP:

1. Explain the operation and purpose of the Spanning-Tree Protocol (STP) on a switched network

2. Enable Spanning Tree on ports and VLANs
3. Configure Spanning Tree parameters including: port priority, VLAN priority, root bridge, BPDU guard, PortFast amd UplinkFast
4. Tune and troubleshoot spanning-tree protocol on a multilayer switched network to enhance network performance, prevent network loops, and minimize downtime

The example

The network that I’ll be demonstrating STP on is below:

All the switches are redundantly connected, forming a loop. Consider the case where a host on switch 1 sends a packet to a host on another switch. S1 does not have the packet in its CAM table (a mapping of MAC addresses to ports), so it floods the packet to all connected ports, ie S2 and S3.

S2 and S3 are in the same situation, not knowing where the packet is to go. They flood the packet to all the ports (except the one it came in, of course). S2 sends it to S3, S3 sends it to S2. Neither knows where it is, so they both send to S1. A loop is formed, the packets continue to flood, and the results aren’t pretty. This is why IP has a Time To Live field.

The solution to the problem is to artificially induce a break in the network to stop the loop. The problem, though, is that this must be done deterministically, since switches don’t share the entire topology. That is, each switch must know if it has to shut down a port. If they were to accidentally shut down the wrong port, the network would be broken. STP’s job is to come up with the loop free topology, and allow each switch to make the decision as to if it needs to shut any ports down.

Spanning Tree Algorithm

The first step is for all nodes on the network to elect a Root Bridge. The root bridge forms the basis for all the calculations. The “Tree” from Spanning Tree implies a tree structure, the root bridge is the root (bottom) of the tree.

Each switch periodically sends out Bridge Protocol Data Units, or BPDUs. Each BPDU includes the bridge ID (a two byte priority combined with the 6 byte MAC address) of both the device that the sender thinks is the root bridge, and that of the sender, the id of the port that sent the BPDU, and the path cost from the sender to the root bridge.

Upon receiving a BPDU, the switch examines the bridge ID of the root bridge that it received from the neighbour, and that of itself. The lowest bridge ID wins. If the received bridge id is lower, the switch sets the known root bridge ID to the received one and continues on. If not, the other switch will learn about it when it gets the next BPDU. BPDUs are not passed through the switch, they are regenerated by each switch using the latest information.

Each switch starts off assuming it is the root bridge, and sets the root bridge ID to the default priority (32768, or 0xF0) and its MAC address. Note that if two priorities are equal, it is the lowest MAC address that wins.

In the network above, all switches send out BPDUs saying they are the root bridge. Assuming priorities are the same, S3 will receive BPDUs from S1 and S2, and choose S1 as the root bridge. The next time it sends out BPDUs, it will say that the root bridge is S1. Likewise, S2 will figure S1 as the root bridge. S1 will see the BPDUs from S2 and S3 but not change its perception of the network.

Once a root bridge is elected, each non root switch figures out which port is closest to the root bridge by looking at the cost field in the BPDU (assuming multiple paths to the root are found). When a BPDU comes in to a switch, it adds the local cost of the link to the received value. BPDUs coming from the root bridge will have a value of 0. The port with the lowest cost wins, or in the case of a tie, the lowest port id.

The following table summarizes the costs:

The old specification was based on 1Gbit/sec, so anyhting higher had the same cost. The new spec uses arbitrary numbers.

In the example above, assuming all ports are 100Mbit, S1 will advertise a cost of 0 to S2 and S3′s Fa0/1 interfaces. S2 will advertise a cost of 19 (0 + the received link cost of 19) to S3, and S3 will advertise 19 to S2. They will both choose Fa0/1 as the root port because the cost is only 19, as opposed to 38 by choosing Fa0/2.

The next step is to calculate the designated port. Each segment needs a designated port. The picture above has three segments, ie the links between each switch. By default, the root bridge’s ports are all designated ports, so that one is easy. The only one up in the air is the S2-S3 link.

First, the root path cost is evaluated. Both have a cost of 38 to the root, so that’s a tie. The bridge ID is examined, meaning S2′s Fa0/2 is the designated port for the segment. If this were a tie (ie two links to the same switch), the lowest port ID would have been chosen.

At this point, anything that is not a root port or a designated port is blocked. S3′s Fa0/2 blocks (ie doesn’t send or receive packets), breaking the loop in the network.

The whole process brought together

Now that the process of building the tree is out of the way, the actual operation of STP differs slightly.

First the concept of port states must be introduced. A port moves through various states and behaves differently at each step.

A port starts off as blocking, meaning it listens only for BPDUs to understand the topology, and does not send anything. From blocking, it moves to listening, where it participates in the BPDU process. Here the root bridge election happens, and the spanning tree is built. From here, it goes to learning (assuming the port wasn’t blocked for loop avoidance purposes). In learning state, it builds the MAC/CAM table based on what it hears (though it doesn’t pass any frames). After learning, the port is in forwarding mode where it works like normal.

BPDUs are sent out every two seconds using a multicast frame. BPDUs are only sent out on designated ports. In reality, there are two types of BPDUs, configuration BPDUs and topology change notification (TCN) BPDUs. The root bridge constantly sends out the configuration BPDUs out the designated ports, and not out the root port (ie not toward the root).

If an event happens (ie a link state or port mode changes), the switch starts sending TCNs out the root port until they are acknowledged by the upstream switch. This switch does the same until the root switch hears the TCN. The root then sends out a configuration BPDU with the topology change bit set for 35 seconds (max_age + forward_delay in the next section). Devices receiving this age out CAM tables entries faster (forward_delay instead of the regular 300s). The regular STP process will then cause the new link to be brought up and the tree rebuilt as necessary.

Timing Summary

A port stays in blocking for 20s called the max_age
A port stays in listening mode for 15s, called the forward_delay
forward_delay also specifies how long the port stays in learning mode.

Thus, the time for a backup link to move from blocking to forwarding after a failure is 20+15+15s = 50s. This can of course be changed by adjusting the timers.

Understanding Spanning-Tree Protocol

Content Copyright Sean Walberg

Spanning Tree Protocol

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

• Describe the features and operation of network analysis modules on Catalyst switches to improve network traffic management

Most of what I found on this is from the Network Analysis Module (NAM-1/NAM-2) page. The NAM 1/2 data sheets provide more information on what this really does.

It’s actually pretty simple. Switches, by default, support RMON. Routers also support NetFlow Export, which allows for layer 4 statistics to be obtained.

The NAM serves two main purposes. One is to listen on the backplane of the Catalyst 6500 and gather statistics. An on board web server lets you view them. The NAM can also collect netflow statistics from other devices. These NAMs can also report up to thenGenius Real-Time Monitor, part of CiscoWorks Lan Mananagement.

As it pertains to the exam, I’m not sure what can be asked about the product other than basic features. I’d suggest reading through the data sheet, and be familiar with RMON and NetFlow concepts.

Content Copyright Sean Walberg

Network Management Features

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

1. Describe the features and operation of 802.1Q Tunneling (802.1QinQ) within a service provider network
2. Describe the operation and purpose of managed VLAN services

Packet Magazine ran an article about ip tunneling, and as a good description of QinQ:

Some service providers want to offer transparent LAN services that preserve and extend customers’ virtual LAN (VLAN) groupings and associated access privileges across a metropolitan-area network (MAN) and, possibly, a WAN. To do this, they can use Cisco 802.1Q Tunneling (also called Cisco 802.1Q-in-Q).

Cisco 802.1Q Tunneling enables service providers to use a single VLAN to securely transport most or all of a single customer’s VLANs across their MAN or WAN backbone. In this case, the software adds an extra 802.1Q tag to customer traffic in the switch at the edge of the service provider’s network. This tag assigns a unique VLAN ID number to each customer to keep each customer’s VLAN traffic segregated and private.

The tag also enables as many as 4094 customer VLANs to be backhauled across a single service provider VLAN through the use of a tunnel port that is assigned to each customer site. All of a single customer’s VLANs that are configured in the tunnel port on the service provider’s WAN edge switch are aggregated and backhauled over a single VLAN.

Service providers do not have to assign a unique VLAN ID number to each individual customer VLAN, which quickly consumes the 4094-ID VLAN space supported by Ethernet’s 802.1Q technology. In this way, encapsulating multiple customer 802.1Q VLANs into a single service provider 802.1Q VLAN (thus the name, “Q in Q”) affords service providers a scalable approach to offering Ethernet services. To transport not only customers’ data traffic but also customers’ Layer 2 control traffic (such as Spanning Tree, Cisco Discovery Protocol, and VLAN Trunking Protocol), service providers must configure on 802.1Q tunneling ports Cisco Layer 2 Protocol Tunneling, a separate feature that is available in the same Cisco IOS® Software release.

In a nutshell, QinQ allows a service provider to give the customer a port that is mapped to a VLAN in the service provider network, letting the customer run a .1Q tunnel over it without having to worry about VLANid collisions.

A port configured to support 802.1Q tunneling is called a tunnel port (this is on the provider end). The customer simply configures their end of the connection as a regular 802.1Q tunnel. Within the service provider cloud, the links are carried as regular .1Q ports.

A very simplified way to look at the packet is as follows:

On the left, the customer passes a regular 802.1Q tagged packet to the provider’s tunnel port. The provider appends its own customer specific VLAN id to it and passes it through the cloud. Upon egress, the provider VLAN tag is removed and the customer sees a packet just as if it came from the other customer switch.

Consider the following network:

Customer A and B both use VLANs 6 and 7, but it doesn’t matter, because the provider has given them their own tags, say 2 and 3 (or even 6 and 7 for all it matters).

Configuring 802.1Q tunneling in CatOS is fairly easy.

! enable the feature on the switch
set dot1q-all-tagged enable
! Set it up on the port
set port dot1qtunnel mod/port access

Verify with

show port dot1qtunnel mod/port

Likewise, Configuring 802.1Q tunneling in IOS is also easy:

! Native VLAN traffic from customer should be tagged
Router(config)# vlan dot1q tag native
Router(config-if)# spanning-tree portfast trunk
Router(config-if)# switchport
Router(config-if)# switchport mode dot1qtunnel

show dot1q-tunnel interface

is used to show the tunnels.

I’m not sure how much depth the CCNP exam will get into, but some of the restrictions mentioned on the top of both of the articles may come into play. For one, since the frame is an encapsulated 802.1Q packet, it can not be routed! The IP headers are part of the underlying packet, which can not be inspected. Thus, many of the other mechanisms like QoS and filtering can not be done within the cloud, I suspect they would have to be applied at the service provider edge.

Content Copyright Sean Walberg

802.1Q Tunneling

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.