evilrouters.net

Several months ago, I wrote about discovering an “anomaly” in ProCurve firmware version K.13.45. Because I apparently already have some folks at HP pissed off, I thought I’d take a look and see if anything had changed.

Although the case hasn’t been updated since January 5th and still hasn’t been resolved, it is still listed as “in progress”.

Since simply copy/pasting the output doesn’t really show the true nature of the “anomaly”, I thought I’d go ahead and put together a video. What I didn’t mention originally (and, perhaps, should have) is that CPU utilization skyrockets to 99% while these “show” commands are running (running very slowly, that is). Originally, and in this video, I used “show ip igmp config” to demonstrate, but there are other show commands that have the same effect on CPU.

In the video, I have two SSH sessions open to an HP ProCurve 5406zl switch running version K.13.60 firmware (yes, I know it’s not the latest — read this to find out why I’m not running K.13.63). In the top session, you see me execute these commands:

HP5406# sh system
HP5406# repeat delay 1

The first command runs “show system-information”. The second causes it to be repeatedly executed, in one second intervals. (I would’ve preferred “sh system | in CPU” since HP FINALLY gave us that feature, but apparently the piping isn’t taken into account when the “repeat” command is used.) I let this run for maybe ten seconds, to give a good “baseline” of what the CPU utilization of the switch is. It hovers mostly around 3-4%.

In the bottom session, you see me execute:

HP5406# show ip igmp config

Immediately after executing this show command, notice how SLOOOOOOW the output to the terminals become. It takes two or three iterations of the “sh system” command, but the switch quickly hits 99% CPU utilization. This, of course, is why the output is being taking so long to display. I’m not sure what’s happening behind the scenes, but apparently the ProCurve doesn’t like it. I cut the video off just a bit too quickly, but it should be noted that CPU utilization returns to normal immediately after the “show” command has finished executing.

Anyway, here’s the video:

In “Configuring Frame-Relay, Part 1″, I demonstrated how to configure a basic frame-relay hub and spoke network.

In Part 2, we have the same three routers with the same physical topology, but we’ll be using point-to-point connections between each of the routers.

Here’s the topology…

…and the walkthrough…

In Part 3, we’ll add another router, R4, to the topology and use a combination of the physical interface and point-to-point subinterface on R1 to demonstrate how to use both simultaneously. We’ll follow that up in Part 4 by adding OSPF to the whole network to show the differences over various types of networks.

I am unfortunate enough to have to maintain 30 or so HP ProCurve switches (with another 10 or so almost ready to be installed). I hate them, with a passion. It is impossible for me to accurately convey how much I hate them using mere words alone.

People often wonder why.

The reasons vary. I’ve had “support” respond to me that they cannot reproduce issues in the lab because they don’t have enough GBICs available (well, go fucking get them!). Their “solution” in this case was to offer me a fresh-off-the-compiler “beta” version of the switch firmware. Because I deal with production equipment (you know, stuff I want to work), I always pass. I am not HP’s QA department, nor will I act as such. Here’s why.

Today I was reading through the K.13.63 Release Notes and noticed this “known issue”:

“Transferring a switch configuration of 4,201 bytes or larger to a switch’s /cfg/startup-config directory via SCP will result in the switch coming up on factory defaults or with the new configuration only partly installed after reboot”

Are you fuckin’ kidding me, HP? How does shit like this make it past QA?

Looking at one of my 5400s, I see its startup config is 18,370 bytes. I have a lot of stuff to add to the config on that one, so it will likely easily pass 30k before it’s “done”. Glad I didn’t “upgrade” to this firmware earlier — I would’ve hated to have been the guy to find that issue.

There’s more that I’d share, but I’ll let you browse through the “Fixes” and “Known Issues” sections of the Release Notes for yourself. Look out for phrases like “hang”, “may reboot unexpectedly”, and the like.

Tomorrow, I’ll be receiving one of the new HP ProCurve Threat Management Services zl Modules. My HP sales rep has warned me in advance that “this module is not very intuitive, like many things you may have seen before”. Why am I not surprised?

In this video, we show how to configure a basic frame-relay network with one hub and two spokes. The configuration is pretty straightforward and simple, and nearly identical on all three routers. As such, a lot of the video is repetitive. It does, however, go from blank configurations to a fully-configured frame-relay hub-and-spoke network with full connectivity.

Here’s the topology:

As you can see, we’re using the 172.16.123.0/24 network and physical interfaces (no sub-interfaces). The DLCI numbers are illustrated in the diagram.

Here’s the video:

Part 2 uses a similar topology but in a full-mesh configuration with point-to-point connections (and sub-interfaces, of course). Part 3 will use a combination of physical interfaces and sub-interfaces to show how to set up both simultaneously. In Part 4, we’ll be configuring OSPF over the network we set up in Part 3, to show the differences in how OSPF works over various types of networks.

A couple of quick videos to show how to configure basic (back-to-back/directly connected) serial and PPP links. Here’s the topology (as basic as it gets):

Configuring a serial connection

Configuring a PPP connection

Here’s another lab that I just made up using dynamips/dynagen. There is a download link to the .net file I used (modify it as needed) at the bottom of this post.

NOTE: See the video demonstration below!

For this lab, here’s the topology we’re working with:

Our scenario here is pretty basic. We are AS 65065 and are dual-homed to our service provider, AS 65001. We have two T-1 connections: R1 to R2 and R1 to R3. We’re running BGP with our service provider and we would like to load share our outgoing traffic over these two T-1 connections. Fortunately, Cisco provides us with an easy way to do this.

As you may already know, BGP will, by default, only install the one best path into the routing table. In our case, that means that we would only be utilizing one connection at a given time. That’s not exactly the best use of our available bandwidth. The “maximum-paths” command is our friend.

From the Cisco IOS IP Command Reference:

“To configure the maximum number of parallel routes that an IP routing protocol will install into the routing table, use the maximum-paths command in router configuration or address family configuration mode. To restore the default value, use the no form of this command.”

Here are our starting configurations for R2 and R3:

R2:

interface fastethernet 0/0
 ip address 172.16.23.2 255.255.255.0
 no shutdown
interface serial 1/1
 ip address 172.16.12.2 255.255.255.0
 no shutdown
router bgp 65001
 network 172.16.12.0 mask 255.255.255.0
 network 172.16.23.0 mask 255.255.255.0
 neighbor 172.16.12.1 remote-as 65065
 neighbor 172.16.23.3 remote-as 65001
 neighbor 172.16.23.3 next-hop-self
end

R3:

interface fastethernet 0/0
 ip address 172.16.23.3 255.255.255.0
 no shutdown
interface serial 1/0
 ip address 172.16.13.3 255.255.255.0
 no shutdown
router bgp 65001
 network 172.16.13.0 mask 255.255.255.0
 network 172.16.23.0 mask 255.255.255.0
 neighbor 172.16.13.1 remote-as 65065
 neighbor 172.16.23.2 remote-as 65001
 neighbor 172.16.23.2 next-hop-self
end

The interface configuration for R1 is pretty standard and simple, with perhaps one exception:

interface serial 1/0
 ip address 172.16.13.1 255.255.255.0
 ip load-sharing per-packet
 no shutdown
interface serial 1/1
 ip address 172.16.12.1 255.255.255.0
 ip load-sharing per-packet
 no shutdown

Note the use of “ip load-sharing per-packet”. Cisco’s default is to use per-destination load sharing. You’ll want to evaluate your network to decide which is best for you.

Now, let’s configure BGP on R1 and we’re practically done:

router bgp 65065
 maximum-paths 2
 neighbor 172.16.12.2 remote-as 65001
 neighbor 172.16.13.3 remote-as 65001

The only thing left to do is test and verify. See how I did it in the video below:

• Download the dynagen .NET file

UPDATE: I made a video demonstration of this as well. You can find it at the bottom of this post. Let me know what you think! Thanks.

Upon request, and as a sort of “continuation” of a prior post, “Using BGP communities to influence routing“, I’m going to demonstrate how to permit this to occur (and configure it!) from the service provider perspective.

Recall our topology:

For simplicity, I’m only going to deal with the configurations on R1 and R2 in this post (R3’s configuration is nearly identical to R2’s). Also, because I’m doing this on real gear in my lab at work and I’m currently at home, we’ll be using our FastEthernet 0/1 interfaces (instead of FastEthernet 0/0, as depicted in the diagram). IP addresses and such will remain the same.

Remember that R1 has four loopback interfaces (172.31.0.1/24, 172.31.1.1/24, 172.31.2.1/24, and 172.31.3.1/24). R1 and R2’s IP addresses are 172.16.12.1 and 172.16.12.2 (/24), respectively.

First, let’s go ahead and bring up R2’s FastEthernet 0/1 interface:

R2# conf t
R2(config)# interface fa0/1
R2(config-if)# ip address 172.16.12.2 255.255.255.0
R2(config-if)# no shutdown

Let’s configure the interfaces on R1:

R1# conf t
R1(config)# interface loopback 0
R1(config-if)# ip address 172.31.0.1 255.255.255.0
R1(config-if)# interface loopback 1
R1(config-if)# ip address 172.31.1.1 255.255.255.0
R1(config-if)# interface loopback 2
R1(config-if)# ip address 172.31.2.1 255.255.255.0
R1(config-if)# interface loopback 3
R1(config-if)# ip address 172.31.3.1 255.255.255.0
R1(config-if)# interface fa0/1
R1(config-if)# ip address 172.16.12.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# end

Make sure we have connectivity:

R1# ping 172.16.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Now we’ll work on setting up R2, the service provider router. Remember that we’re supporting two communities that our customers can send to us:

• 200: set local preference to 200
• 500: set local preference to 500

Any routes received without one of these communities will have the local preference set to 150 (this wasn’t in the previous post, but I’m adding it here so we can show off a few things later).

First, we’ll tell R2 that we want to display BGP communities in the “new” AA:NN format:

R2(config)# ip bgp-community new-format

We need to set up two “community lists”. These are what our route maps will match on:

R2(config)# ip community-list 1 permit 65001:200
R2(config)# ip community-list 2 permit 65001:500

Now we can configure our route-map. They should fairly self-explanatory:

R2(config)# route-map CUSTOMER_IN permit 10
R2(config-route-map)# match community 1
R2(config-route-map)# set local-preference 200
R2(config-route-map)# route-map CUSTOMER_IN permit 20
R2(config-route-map)# match community 2
R2(config-route-map)# set local-preference 500
R2(config-route-map)# route-map CUSTOMER_IN permit 30
R2(config-route-map)# set local-preference 150

Can you understand what those do? By this point, hopefully you can!

Let’s go ahead and configure R2’s BGP peering with R1 and apply the CUSTOMER_IN route map to the neighbor:

R2(config)# router bgp 65001
R2(config-router)# neighbor 172.16.12.1 remote-as 65065
R2(config-router)# neighbor 172.16.12.1 soft-reconfiguration inbound
R2(config-router)# neighbor 172.16.12.1 next-hop-self
R2(config-router)# neighbor 172.16.12.1 route-map CUSTOMER_IN in

At this point, we’re all set on the service provider (R2) side. All we need is for the BGP session to come up and R1 to start advertising routes to the service provider. Let’s configure R1 to also display BGP communities in the “new” AA:NN format:

R1(config)# ip bgp-community new-format

Now, before we go messing around with any route-maps on R1, let’s get the BGP session up first:

R1(config)# router bgp 65065
R1(config-router)# neighbor 172.16.12.2 remote-as 65001
R1(config-router)# neighbor 172.16.12.2 soft-reconfiguration inbound
R1(config-router)# neighbor 172.16.12.2 send-community

Verify that BGP is up and running:

R1# show ip bgp summary
BGP router identifier 172.31.3.1, local AS number 65065
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.12.2     4 65001       4       4        1    0    0 00:00:21        0

Now let’s go ahead and begin advertising our four (loopback) networks:

R1(config)# router bgp 65065
R1(config-router)# network 172.31.0.0 mask 255.255.255.0
R1(config-router)# network 172.31.1.0 mask 255.255.255.0
R1(config-router)# network 172.31.2.0 mask 255.255.255.0
R1(config-router)# network 172.31.3.0 mask 255.255.255.0

How do things look from the service provider (R2) side of things?

R2# show ip bgp
BGP table version is 5, local router ID is 172.16.12.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 172.31.0.0/24    172.16.12.1              0    150      0 65065 i
*> 172.31.1.0/24    172.16.12.1              0    150      0 65065 i
*> 172.31.2.0/24    172.16.12.1              0    150      0 65065 i
*> 172.31.3.0/24    172.16.12.1              0    150      0 65065 i

Well, there’s our routes. They are most definitely showing up. Notice that R2 has assigned them a local preference of 150 (the default is 100). This is because the routes did not have any communities associated with them, so they “fell through” the route-map on R2 and were “caught” by the last entry (”30″), which assigned them a local preference of 150.

Let’s set up two route maps on R1:

R1(config)# route-map LOCAL_PREF_200 permit 10
R1(config-route-map)# set community 65001:200
R1(config-route-map)# route-map LOCAL_PREF_500 permit 10
R1(config-route-map)# set community 65001:500

Can you figure out what those do? By assigning one of the two route maps here to our BGP adjacency with R2, we’re setting one of the community values that R2 supports.

Let’s apply the LOCALPREF200 route-map and clear our adjacency:

R1(config)# router bgp 65065
R1(config-router)# neighbor 172.16.12.2 route-map LOCAL_PREF_200 out
R1(config-router)# do clear ip bgp 172.16.12.2

Now what do we see on R2?

R2# show ip bgp | in 172.16.12.1
*> 172.31.0.0/24    172.16.12.1              0    200      0 65065 i
*> 172.31.1.0/24    172.16.12.1              0    200      0 65065 i
*> 172.31.2.0/24    172.16.12.1              0    200      0 65065 i
*> 172.31.3.0/24    172.16.12.1              0    200      0 65065 i

Aha! Now R2 has assigned a local preference value of 200 to our routes. Can you guess what will happen if we apply the LOCALPREF500 route-map on R1?

R1(config-router)# no neighbor 172.16.12.2 route-map LOCAL_PREF_200 out
R1(config-router)# neighbor 172.16.12.2 route-map LOCAL_PREF_500 out
R1(config-router)# do clear ip bgp 172.16.12.2

I bet you know what R2’s BGP table is going to look like now, don’t you!?

R2# show ip bgp | in 172.16.12.1
*> 172.31.0.0/24    172.16.12.1              0    500      0 65065 i
*> 172.31.1.0/24    172.16.12.1              0    500      0 65065 i
*> 172.31.2.0/24    172.16.12.1              0    500      0 65065 i
*> 172.31.3.0/24    172.16.12.1              0    500      0 65065 i

Bingo! R2 has now assigned a local preference value of 500 to our advertised routes! See how easy that is? Now go out there and change how your SP routes to you!

Note: If you found this useful, please do leave me a comment below and let me know. Also, if there are specific examples or “how to’s” you’re looking for, let me know that too. I’m always looking for good ideas for things to write about!

Previously I’ve covered using weight, local preference, and AS path prepending to influence routing between autonomous systems running BGP. Today we’ll look at one of the common methods for influencing routing, and that is BGP community values.

BGP communities are simply values attached to a route that is sent to BGP peers. This values have special meanings to the peers and cause specific actions to be taken, depending upon the values assigned. A customer who is multi-homed to a service provider can often use communities to tell the service provider how to route traffic to the customer autonomous system (AS).

For this example, let’s assume the following topology:

We are the customer (AS 65065) and R1 is our router. We are multi-homed to our service provider (AS 65001) with a 100 Mbit/s connection to R2 and a T-1 connection to R3. R2 and R3 are connected over a 100 Mbit/s connection as well.

Since the IP addresses being used are not illustrated in the diagram, here is a table with the IP addresses we are using:

ROUTER    INTERFACE    IP/MASK
--------------------------------------

R1        Fa0/0        172.16.12.1/24
          Se1/0        172.16.13.1/24
R2        Fa0/0        172.16.12.2/24
          Fa1/0        172.16.23.2/24
R3        Fa0/0        172.16.23.3/24
          Se1/0        172.16.13.3/24

In addition, our router (R1) has four loopback interfaces (Loopback0, Loopback1, Loopback2, and Loopback3) with the following IP addresses assigned, respectively: 172.31.0.1/24, 172.31.1.1/24, 172.31.2.1/24, and 172.31.3.1/24.

Okay, so let’s get our loopbacks configured and IP connectivity up between R1/R2 and R1/R3:

R1# conf t
R1(config)# interface loopback 0
R1(config-if)# ip address 172.31.0.1 255.255.255.0
R1(config-if)# interface loopback 1
R1(config-if)# ip address 172.31.1.1 255.255.255.0
R1(config-if)# interface loopback 2
R1(config-if)# ip address 172.31.2.1 255.255.255.0
R1(config-if)# interface loopback 3
R1(config-if)# ip address 172.31.3.1 255.255.255.0
R1(config-if)# interface fa0/0
R1(config-if)# ip address 172.16.12.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# interface se1/0
R1(config-if)# ip address 172.16.13.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# end

Let’s make sure we can ping both R2 and R3:

R1# ping 172.16.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/24 ms
R1# ping 172.16.13.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.13.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/12/20 ms

Alright, so far, so good. We have four networks that we want to advertise into BGP — the four /24 subnets assigned to our loopback interfaces. Before we do this, however, let’s take another look at our topology. Recall that we have connections into AS 65001: a 100 Mbit/s connection to 172.16.12.2 and a 1.544 Mbit/s connection to 172.16.13.3. Sure would be nice if we could tell AS 65001 to send our traffic over that 100 Mbit/s connection, wouldn’t it? Well, we can!

Our service provider, AS 65001, allows us to use the communities attribute of BGP to influence how they route our traffic. In this (simplified) example, there are three different communities we can use:

• 200: set local preference to 200
• 500: set local preference to 500

If we send routes to AS 65001 with a community of 65001:200, the SP’s routers will set the local preference on those routes to 200. If we send routes to AS 65001 with a community of 65001:500, the SP’s routers will set the local preference on those routes to 500. How handy is that?

Because of how the BGP best path selection algorithm works, we want our SP’s routers to assign a higher local preference to the routes it receives from us over that 100 Mbit/s connection, so we’ll send those routes with a community of 65001:500. Just for good measure, we’ll attach community 65001:200 to the routers we send to 172.16.13.3 over the T-1 connection as well.

Let’s go ahead and set up BGP, but don’t start advertising any routes just yet:

R1(config)# ip bgp-community new-format
R1(config)# router bgp 65065
R1(config-router)# neighbor 172.16.12.2 remote-as 65001
R1(config-router)# neighbor 172.16.12.2 next-hop-self
R1(config-router)# neighbor 172.16.12.2 send-community
R1(config-router)# neighbor 172.16.13.3 remote-as 65001
R1(config-router)# neighbor 172.16.13.3 next-hop-self
R1(config-router)# neighbor 172.16.13.3 send-community

We are all set to begin advertising our routes, with the appropriate communities attached. The next thing we need to do is create a pair of route maps. We’ll apply these route maps outbound to the BGP peers and these are what we will use to attach our communities to the routes:

R1(config)# route-map LOCAL_PREF_200 permit 10
R1(config-route-map)# set community 65001:200
R1(config-route-map)# route-map LOCAL_PREF_500 permit 10
R1(config-route-map)# set community 65001:500

Lookin’ good so far, right? Let’s apply those route map to our BGP peers:

R1(config)# router bgp 65065
R1(config-router)# neighbor 172.16.12.2 route-map LOCAL_PREF_500 out
R1(config-router)# neighbor 172.16.13.3 route-map LOCAL_PREF_200 out

That was easy enough. Now, let’s advertise those loopbacks:

R1(config-router)# network 172.31.0.0 mask 255.255.255.0
R1(config-router)# network 172.31.1.0 mask 255.255.255.0
R1(config-router)# network 172.31.2.0 mask 255.255.255.0
R1(config-router)# network 172.31.3.0 mask 255.255.255.0

Let’s take a look at how the SP sees our routes:

R2# sh ip bgp | in 65065
*> 172.31.0.0/24    172.16.12.1              0    500      0 65065 i
*> 172.31.1.0/24    172.16.12.1              0    500      0 65065 i
*> 172.31.2.0/24    172.16.12.1              0    500      0 65065 i
*> 172.31.3.0/24    172.16.12.1              0    500      0 65065 i

R3# sh ip bgp | in 65065
*>i172.31.0.0/24    172.16.23.2              0    500      0 65065 i
*                   172.16.13.1              0    200      0 65065 i
*>i172.31.1.0/24    172.16.23.2              0    500      0 65065 i
*                   172.16.13.1              0    200      0 65065 i
*>i172.31.2.0/24    172.16.23.2              0    500      0 65065 i
*                   172.16.13.1              0    200      0 65065 i
*>i172.31.3.0/24    172.16.23.2              0    500      0 65065 i
*                   172.16.13.1              0    200      0 65065 i

If we ping/traceroute from R3 to one of R1’s loopbacks, we should see that traffic first passes to R2 before being sent to R1 (which is our goal):

R3# ping 172.31.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.31.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/17/36 ms
R3# traceroute 172.31.0.1

Type escape sequence to abort.
Tracing the route to 172.31.0.1

  1 172.16.23.2 4 msec 12 msec 16 msec
  2 172.16.12.1 16 msec *  32 msec

Success!

From HP’s Advanced Traffic Management Guide:

“BPDU protection is a security feature designed to protect the active STP topology by preventing spoofed BPDU packets from entering the STP domain. In a typical implementation, BPDU protection would be applied to edge ports connected to end user devices that do not run STP. If STP BPDU packets are received on a protected port, the feature will disable that port and alert the network manager …”

In short, we want to enable BPDU protection on any “edge ports”, or ports that are connected to end user devices (PCs, printers, etc.) — any device that should not be sending out STP BPDU’s. Without BPDU protection, a malicious (or ignorant) user could plug a switch into our network and alter the spanning tree topology. That’s a bad thing.

With BPDU protection, we can a port automatically disabled if it receives an STP BPDU. Under normal circumstances, this should never happen. Enabling this feature does two things:

• helps protect your network, and
• keeps you, the network guy (or gal), informed about what is happening.

Let’s assume a user brings in their own switch from home. They unplug their PC from the wall, plug into their own switch, then plug their switch into the data jack in the wall. As soon as their switch sends out a BPDU, our switch will receive it and immediately disable the port. If you do not configure your switch to automatically re-enable the port after a specified period of time (I don’t), their data jack is effectively dead. It cannot be used again without the intervention of the network guy. When they can no longer work and must come to you for assistance, you’ll have a good idea of what they did and can promptly break their fingers educate them on why they should never do that.

On HP ProCurve switches, we enable BPDU protection with the “spanning-tree <port> bpdu-protection” command. You can do this individually per port (you can specify ranges) or do it like I do:

SWITCH(config)# spanning-tree all bpdu-protection

This, in my opinion, is the best way. This will enable BPDU protection on EVERY port. Then, you selectively disable it on your uplink ports:

SWITCH(config)# no spanning-tree a24 bpdu-protection

The default BPDU protection timeout is set to 0. This is the amount of time, in seconds, after which the switch will re-enable a port that has been disabled due to receiving an “illegal” BPDU. A value of 0 means “never”, and is the value that I prefer. This ensures that “network guy intervention” is required to break the user’s fingers re-enable the port.

Let’s take a look at what happens. In this example, I have BPDU protection enabled on port A2 (all ports except for A24, actually), as can be verified here:

SWITCH# sh spanning-tree bpdu-protection

 Status and Counters - STP Port(s) BPDU Protection Information

 BPDU Protection Timeout (sec) : 0                     
 BPDU Protected Ports : A1-A23,B1-B24,C1-C24,D1-D24,E1-E24,F1-F24,G1-G24,H1-H2...

So, having verified that BPDU protection is enabled on port A2, what happens when we plug another switch into that port? You obviously can’t see me plug in the cable, but here’s what we get in our logs:

SWITCH# sh logging
 Keys:   W=Warning   I=Information
         M=Major     D=Debug E=Error
----  Event Log listing: Events Since Boot  ----
I 03/12/09 00:02:41 00435 ports: port A2 is Blocked by STP
I 03/12/09 00:02:41 00840 stp: port A2 disabled - BPDU received on protected
            port.
I 03/12/09 00:02:41 00898 ports: BPDU protect(5) has disabled port A2 for 0
            seconds
I 03/12/09 00:02:41 00077 ports: port A2 is now off-line
----  Bottom of Log : Events Listed = 99  ----

Our switch will, when the port comes “up”, wait briefly and just listen. It will wait to see if it receives a BPDU (”Blocked by STP”) and, as soon as it does, notes this in the system log and immediately disables the port.

SWITCH# sh spanning-tree bpdu-protection a2

 Status and Counters - STP BPDU Protection Information

 BPDU Protection Timeout (sec) : 0                     
 BPDU Protected Ports : A1-A23,B1-B24,C1-C24,D1-D24,E1-E24,F1-F24,G1-G24,H1-H2..
.

  Port  Type      Protection State      Errant BPDUs
  ----- --------- ---------- ---------- ------------
  A2    100/1000T Yes        BpduError  1

The “sh spanning-tree bpdu-protection a2″ command shows us that port A2 is in “BpduError” state and has received a total of one “errant BPDUs”. Now, let’s assume we’ve unplugged the switch and plugged a PC back in. How do we get the port functional again? Easy:

SWITCH# conf
SWITCH(config)# interface a2
SWITCH(eth-A2)# enable
SWITCH(eth-A2)# end

That’s all there is to it! BPDU protection is simple to implement (assuming you know what connects where) and can add a bit of protection to your network. Turn it on!