San Francisco Dog Friendly Landlords May Get The Cookie

A new tax break may aid in the battle to reduce the number of unwanted dogs in San Francisco if it becomes law. The idea, currently in the hands of the city animal welfare commission, would offer a reduction in tax of either 5 percent of the monthly rent or $200 per month, whichever is less, according to local television station KGO-TV.

The article claims that the number one reason cats and dogs end up in the city's shelters is landlord rejection. With San Francisco home to many pet lovers who are also largely renters, the problem is huge.

There is even a little optimism from the landlord community. Janan New, SF Apartment Association, is quoted in the KGO-TV piece as saying, "It seems like something positive, a breath of fresh air, compared to the usual antagonism we suffer at the Board of Supervisors."

Dog Pictures, dog training tips, travel, dog podcasts, pet health help and more - everything but the dog breath!

See for yourself at www.DogExplorer.com

Cisco CCNP Certification/BCMSN Exam Tutorial: Uplinkfast

You remember from your CCNA studies that when a port goes through the transition from blocking to forwarding, you're looking at a 50-second delay before that port can actually begin forwarding frames. Configuring a port with PortFast is one way to get around that, but again, you can only use it when a single host device is found off the port. What if the device connected to a port is another switch?

A switch can be connected to two other switches, giving that local switch a redundant path to the root bridge, and that's great - we always want a backup plan! However, STP will only allow one path to be available, but if the available path to the root switch goes down, there will be a 50-second delay due to the STP timers MaxAge and ForwardDelay before the currently blocked path will be available.

The delay is there to prevent switching loops, and we can't use PortFast to shorten the delay since these are switches, not host devices. What we can use is Uplinkfast.

The ports that SW3 could potentially use to reach the root switch are collectively referred to as an uplink group. The uplink group includes the ports in forwarding and blocking mode. If the forwarding port in the uplink group sees that the link has gone down, another port in the uplink group will be transitioned from blocking to forwarding immediately. Uplinkfast is pretty much PortFast for wiring closets. (Cisco recommends that Uplinkfast not be used on switches in the distribution and core layers.)

Some additional details regarding Uplinkfast:

The actual transition from blocking to forwarding mode takes about three seconds.

Uplinkfast cannot be configured on a root switch.

Uplinkfast is configured globally. You can't run Uplinkfast on some ports or on a per-VLAN basis - it's all or nothing.

The original root port will become the root port again when it detects that its link to the root switch has come back up. This does not take place immediately. The switch uses the following formula to determine how long to wait before transitioning back to the forwarding state:

( 2 x FwdDelay) + 5 seconds

Uplinkfast will take immediate action to ensure that the switch upon which it is configured cannot become the root switch. First, the switch priority will be set to 49,152, which means that if all other switches are still at their default priority, they'd all have to go down before this switch can possibly become the root switch. Additionally, the STP Port Cost will be increased by 3000, making it highly unlikely that this switch will be used to reach the root switch by any downstream switches.

And you just know there's got to be at least one option with this command, right? Let's run IOS Help and see.

SW2(config)#spanning-tree uplinkfast ?

max-update-rate Rate at which station address updates are sent

When there is a direct link failure, dummy multicast frames are sent to the MAC destination 0100.0ccd.cdcd. The max-update-rate value determines how many of these frames will be sent in a 100-millisecond time period.

Mastering the details of UplinkFast, BackboneFast, BPDU Guard, and Loop Guard are vital to your success on the CCNP exams, and one or more of these features are in use on almost every network in the world. Learn these features for success in both the exam room and the real world!
Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage (http://www.thebryantadvantage.com). For a copy of his FREE "How To Pass The CCNA" or "CCNP" ebook, visit the website and download your copies! Daily exam questions and tutorials now available through RSS feed!

Cisco CCNP / BCMSN Exam Tutorial: BPDU Skew Detection

You may look at that feature's name and think, "What is a BPDU Skew, and why do I want to detect it?" What we're actually attempting to detect are BPDUs that aren't being relayed as quickly as they should be.

After the root bridge election, the root bridge transmits BPDUs, and the non-root switches relay that BPDU down the STP tree. This should happen quickly all around, since the root bridge will be sending a BPDU every two seconds by default ("hello time"), and the switches should relay the BDPUs fast enough so every switch is seeing a BPDU every two seconds.

That's in a perfect world, though, and there are plenty of imperfect networks out there! You may have a busy switch that can't spare the CPU to relay the BDPU quickly, or a BPDU may just simply be lost in transmission. That two-second hello time value doesn't give the switches much leeway, but we don't want the STP topology recalculated unnecessarily either.

BDPU Skew Detection is strictly a notification feature. Skew Detection will not take action to prevent STP recalculation when BDPUs are not being relayed quickly enough by the switches, but it will send a syslog message informing the network administrator of the problem. The amount of time between when the BDPU should have arrived and when it did arrive is referred to as "skew time" or "BPDU latency".

A busy CPU could quickly find itself overwhelmed if it had to send a syslog message for every BPDU delivery that's skewed. The syslog messages will be limited to one every 60 seconds, unless the "skew time" is at a critical level. In that case, the syslog message will be sent immediately with no one-per-minute limit.

And what is "critical", according to BDPU Skew Detection? Any value greater than 1/2 of the MaxAge value, making the critical skew time level 10 seconds or greater.

Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage (http://www.thebryantadvantage.com), home of free CCNP and CCNA tutorials! For my FREE "How To Pass The CCNA" or "CCNP" ebook, visit the website and download your copies. Pass your CCNP exam with The Bryant Advantage

Cisco CCNP / BSCI Exam Tutorial: Filtering BGP Updates With Prefix Lists

A major part of your BSCI and CCNP exam success is mastering BGP, and that includes filtering BGP routing updates. In this tutorial, we'll take a look at how to filter BGP updates with prefix lists.

R4 is advertising three networks via BGP. The downstream router R3 sees these routes and places them into its BGP table as shown below. R3 has two downstream BGP peers, R1 and R2, and is advertising itself as the next-hop IP address for all BGP routes sent to those two routers.

R4(config)#router bgp 4

R4(config-router)#network 21.0.0.0 mask 255.0.0.0

R4(config-router)#network 22.0.0.0 mask 255.0.0.0

R4(config-router)#network 23.0.0.0 mask 255.0.0.0

R3#show ip bgp

BGP table version is 4, local router ID is 3.3.3.3

Status codes: s suppressed, d damped, h history, * valid, > best, i - Internal

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 21.0.0.0 10.2.2.4 0 0 4 I

*> 22.0.0.0 10.2.2.4 0 0 4 I

*> 23.0.0.0 10.2.2.4 0 0 4 I

R3(config)#router bgp 123

R3(config-router)#neighbor 172.12.123.1 next-hop-self

R3(config-router)#neighbor 172.12.123.2 next-hop-self

In turn, both R1 and R2 have these three routes in their respective BGP tables.

R2#show ip bgp

BGP table version is 4, local router ID is 2.2.2.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - Internal

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>i21.0.0.0 172.12.123.3 0 100 0 4 I

*>i22.0.0.0 172.12.123.3 0 100 0 4 I

*>i23.0.0.0 172.12.123.3 0 100 0 4 I

R1#show ip bgp

BGP table version is 4, local router ID is 19.1.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - Internal

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>i21.0.0.0 172.12.123.3 0 100 0 4 I

*>i22.0.0.0 172.12.123.3 0 100 0 4 I

*>i23.0.0.0 172.12.123.3 0 100 0 4 I

If we wanted R3 to receive all three of these routes from R4 but not advertise all of them to R2 and R1, we've got a couple of options on how to block these routes. Cisco's recommendation is the use of prefix-lists, and once you get used to the syntax (which you should do before taking and passing the BSCI), you'll see they are actually easier to use than access-lists.

In this case, we're going to configure R3 to send only the route to 21.0.0.0 to R1 and 23.0.0.0 to R2. However, we do want these two routers to get any future routes that R4 advertises into BGP.

Since R1 and R2 will learn about these routes from an iBGP neighbor, they will not advertise the routes to each other.

On R3, we'll write a prefix-list that denies 22.0.0.0/8 and 23.0.0.0/8, but permits all other routes. After applying the prefix list as shown, R1 sees only the 21.0.0.0 /8 route.

R3(config)#ip prefix-list FILTER_R1 deny 22.0.0.0/8

R3(config)#ip prefix-list FILTER_R1 deny 23.0.0.0/8

R3(config)#ip prefix-list FILTER_R1 permit 0.0.0.0/0 le 32

R3(config)#router bgp 123

R3(config-router)#neighbor 172.12.123.1 prefix-list FILTER_R1 out

R3#clear ip bgp * soft

R1#show ip bgp

BGP table version is 6, local router ID is 19.1.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - Internal

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>i21.0.0.0 172.12.123.3 0 100 0 4 I

The paths to 22.0.0.0/8 and 23.0.0.0/8 have been successfully filtered.

We'll do the same for R2, except the route not being expressly blocked is 23.0.0.0/8. The line "ip prefix-list permit 0.0.0.0/0 le 32" is the prefix list equivalent of a "permit any" statement in an ACL.

R3(config)#ip prefix-list FILTER_R2 deny 21.0.0.0/8

R3(config)#ip prefix-list FILTER_R2 deny 22.0.0.0/8

R3(config)#ip prefix-list FILTER_R2 permit 0.0.0.0/0 le 32

R3(config)#router bgp 123

R3(config-router)#neighbor 172.12.123.2 prefix-list FILTER_R2 out

R3#clear ip bgp * soft

R2#show ip bgp

BGP table version is 6, local router ID is 2.2.2.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - Internal

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>i23.0.0.0 172.12.123.3 0 100 0 4 I

The paths to 21.0.0.0/8 and 22.0.0.0/8 have been successfully filtered.

To see the prefix lists configured on a route as well as the order of the statements in each list, run show ip prefix-list.

R3#show ip prefix-list

ip prefix-list FILTER_R1: 3 entries

seq 5 deny 22.0.0.0/8

seq 10 deny 23.0.0.0/8

seq 15 permit 0.0.0.0/0 le 32

ip prefix-list FILTER_R2: 3 entries

seq 5 deny 21.0.0.0/8

seq 10 deny 22.0.0.0/8

seq 15 permit 0.0.0.0/0 le 32

Get some hands-on practice with prefix lists and you'll quickly master them. Prefix lists are an important part of working with BGP in the exam room and production networks, so it's vital that you are comfortable working with them.

Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage , home of free CCNA and CCNP tutorials! Pass the CCNA exam with Chris Bryant!

Cisco CCNP / BCMSN Exam Tutorial: Dynamic Trunking Protocol (DTP)

When you're studying to pass the BCMSN exam on the way to earning your CCNP certification, you're going to add to your CCNA knowledgebase every step of the way. Nowhere is that more than configuring a trunk between two switches.

You know that IEEE 802.1Q ("dot1q") and ISL are your two choices of trunking protocols, and you know the main differences between the two. What you might not have known is that there's a third trunking protocol that's running between your Cisco switches, and while it's a transparent process to many, you had better know about it for your BCMSN and other CCNP exams!

The Cisco-proprietary Dynamic Trunking Protocol (DTP) actively attempts to negotiate a trunk link with the remote switch. This sounds great, but there is a cost in overhead - DTP frames are transmitted every 30 seconds. If you decide to configure a port as a non-negotiable trunk port, there's no need for the port to send DTP frames.

DTP can be turned off at the interface level with the switchport nonegotiate command, but as you see below, you cannot turn DTP off until the port is no longer in dynamic desirable trunking mode. (Dynamic desirable is the default mode for most Cisco switch ports.)

SW2(config)#int fast 0/8

SW2(config-if)#switchport nonegotiate

Command rejected: Conflict between 'nonegotiate' and 'dynamic' status.

SW2(config-if)#switchport mode ?

access Set trunking mode to ACCESS unconditionally

dynamic Set trunking mode to dynamically negotiate access or trunk mode

trunk Set trunking mode to TRUNK unconditionally

SW2(config-if)#switchport mode trunk

SW2(config-if)#switchport nonegotiate

When you're working with Cisco switches in a home lab or rack rental environment, run IOS Help regularly to see what options are available for the commands you're practicing with. Cisco switch ports have quite a few options, and the best way to find them is with one simple symbol - the question mark!

Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage , home of free CCNA and CCNP tutorials! Pass the BCMSN exam with Chris Bryant!

Mend Your Broken Heart For Valentines's Day. Three Great Healthy Heart Exercises You Can Do In San Francisco

February is the perfect month to consider mending your broken heart and San Francisco is the just the right city to do it. No, I am not talking about your love life. I am talking about strengthening the most important muscle in your body; your heart.

Valentine's month is a period in between the holidays and summer. There are not as many distractions which make it a great month to begin an exercise program. The San Francisco setting for this is ideal with the cool clear days February provides and no fog!

More importantly there is no better city to train than San Francisco because of our unique topography. Where most cities have to rely solely on long, boring and flat cardio workouts we have a ton of options for quick, high intensity cardio workouts.

Three great options for fast cardio training that The City offers are: beach sprints, hill sprints and stair climbing.

1. Beach Sprints: Sprinting at the beach is great for developing strength in your legs as well as your heart. It takes more effort than sprinting on a solid surface and you can't beat the scenery (unless all you can see is fog but that's pretty cool too.) A great cardio workout at the beach would be to sprint for twenty seconds then walk for ten and repeat eight times for a total of four minutes. This has been proven to be just as effective as running at a steady state for longer periods.

2. Hill Sprints: When I was young and had to walk everywhere I would curse the hills of San Francisco. Driving my old cars with stick shifts was never much fun either. Now it's all about automatics and using the hills to exercise. Much like beach sprints; hill sprints are great for strengthening the legs and glutes, as well as your heart. The best thing about hill sprints is you most likely have a hill right outside your door (if you don't you probably live close to the beach.) Try the "around the block run." Jog easy downhill and around the turns and sprint uphill. Depending on the length and slope of the hill start out doing this once or twice and try to build up to five or six times or more.

3. Stair Climbing: One of the aspects of San Francisco I have always loved, even as a kid, is the amount of stairs we have. Long staircases slice through neighborhoods providing easy routes to our favorite coffee shops and create the feeling, for me, of being in an old world time and place. What I really love about them is the leg, glute and cardio workout they can provide. Try running up a long staircase, walking up two stairs at a time or carrying a pair of dumbbells on your climb. If you want to climb it more than once be careful coming back down as you will be tired.

Of course do a proper warm up before exercising and always consult a physician before starting a new exercise program. Happy Valentines Day!

Jim Phillips is a physical educator and owner of http://www.home-exercise-secrets.com

Cisco CCNP Certification: BGP Attribute Category Tutorial

You have to master the details on BGP to pass the BSCI exam and to earn your CCNP, but BGP is an entirely new world from the protocols you studied to earn your CCNA. BGP paths contain attributes, while no protocol you studied for the CCNA carried. BGP Attributes are used to choose the best path when multiple loop-free paths exist, as well as give you other specific information about the paths. This additional information includes the autonomous systems that are along the path to a given destination, what the next-hop IP address is, and much more.

Before we examine the specific attributes, we need to understand the categories used to differentiate BGP attributes. Some attributes are required, some aren't; some attributes will be carried between routers, where others will not.

The first category is the well-known mandatory attribute. As you'd expect, these attributes are required and will be understood by all BGP speakers. Mandatory attributes include the origin code, AS_Path, and next-hop.

Well-known discretionary attributes don't have to be present, but if they are , all BGP speakers will understand their meaning. BGP attributes that fall into this category are the MED, local preference, and atomic aggregate.

Optional transitive attributes may not be fully understood by all BGP speakers, but the attributes are sent between routers as paths are exchanged. The aggregator and community attributes fall into this category.

Finally, we have the optional nontransitive attribute. If a BGP speaker does not understand this attribute, the speaker will not forward the attribute. The Originator ID and Cluster ID are optional nontransitive attributes.

There's one important BGP attribute that was left out of this list; indeed, if you're working in an all-Cisco environment, it may be the most important attribute of all. The weight attribute is Cisco-proprietary, so if you're working in a multivendor environment, this attribute is of limited value. However, the weight attribute is the first attribute considered when BGP is deciding between valid, loop-free paths, so it's an attribute we have to keep in mind. The weight attribute doesn't really fit in any of the four BGP classes we talked about earlier in the article.

If you don't know what these attributes do yet, that's okay. We'll examine each of these attributes in more detail in the next part of this free BGP tutorial. Keep studying!

Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage (http://www.thebryantadvantage.com ), home of free CCNA and CCNP tutorials, and The Ultimate CCNA and CCNP Study Packages. For a copy of his FREE "How To Pass The CCNA" or "CCNP" ebook, visit the website and download your copies!