Tuesday, April 21, 2009

Seattle Seahawks at San Francisco 49ers

It's a week 11 NFL match up of division foes. The Seahawks lead the series 8-6 and have plowed through the 49ers in the last 6 meetings. They could very well post another 14+ point victory this week.

The 49ers are coming off another victory--they are 4-5 now--and hope to make it three in a row. Two weeks ago they beat the Minnesota Vikings in San Francisco 9-6. To say this game was boring is an understatement. Last week they went to Detroit and beat a lackluster Lions team 19-13. I think the Detroit Tigers would have gave them a better run for the money.

The Seahawks continue to move forward without MVP running back Shaun Alexander and Pro Bowl QB Matt Hasslebeck. However, there's good new from Seahawks camp. Both will be practicing this week. They might get some limited duty this weekend--depending how the game goes. Last week backup RB Morris and QB Wallace helped the Seahawks beat division foe St. Louis. The play of the game was the 90ish yard return by newly sign WR Nate Burleson.

Wallace is playing pretty well and the 49ers aren't exactly a top team. We might see Hasslebeck play a series or even take another week off. The remaining schedule favors the Seahawks, so they can be a bit cautious here.

I'm looking for the Hawks offense to explode on the soft 49ers secondary. This is a team--49ers--that gave up 40+ points to Chicago, Kansas City and San Diego. They also gave up 34 to Arizona and 38 to Philadelphia. This could be another explosive day for the Seahawks offense. Look for them to open it up early to get a lead and give their returning stars the opportunity to "practice" during the game. This is another great opportunity for the Seahawks defense to tighten up and work on some issues.

The author writes articles on many topics including sports wagering, jeu casino, and paris en ligne.

Labels: ,

Monday, April 13, 2009

Cisco CCNA Certification Exam Case Study: Frame Relay, Pings, And Routing Protocols

Cisco CCNA certification training includes troubleshooting your own work and that of others. The best CCNA certification training you can do is indeed troubleshooting your own Cisco router and switch configurations - as I'm always telling my students, "I can guarantee that any error you make has been made before, and you'll probably see it again one day." One such common error involves two very important CCNA certification topics - Frame Relay and routing protocols.

A student was working on his CCNA exam home lab and came up with an interesting problem. He set Frame Relay up in a hub-and-spoke configuration with R1 as the hub and R2 and R3 as the spokes. He wrote the following frame map statements:

frame-relay map ip 172.12.123.2 122

frame-relay map ip 172.12.123.3 123

He was able to ping both spokes from the hub, so he assumed everything was working correctly. Then he configured RIP version 2 on the router and got the following result after running "debug ip rip" and clearing the routing table with "clear ip route *":

03:33:01: IP: s=172.12.123.1 (local), d=224.0.0.9 (Serial0), len 72, sending broad/multicast

03:33:01: IP: s=172.12.123.1 (local), d=224.0.0.9 (Serial0), len 72, encapsulation failed

You may have already spotted the problem, and if you did, your CCNA certification exam studies are going well! The problem is that the "broadcast" option was left off the frame map statements. "broadcast" must be configured on frame map statements in order to send broadcasts and multicasts across the frame link. As you know from your CCNA certification exam studies, RIP version 1 broadcasts updates and RIP version 2 multicasts them, so the "broadcast" option must be present for either version to send updates by using those frame mappings.

He then rewrote the frame map statements as shown below....

R1(config-if)#frame map ip 172.12.123.2 122 broadcast

R1(config-if)#frame map ip 172.12.123.3 123 broadcast

... and the RIP updates went out as expected.

R1#debug ip rip

RIP protocol debugging is on

R1#clear ip route *

06:22:13: RIP: sending general request on Loopback0 to 224.0.0.9

06:22:13: RIP: sending general request on Serial0 to 224.0.0.9

06:22:13: RIP: ignored v2 packet from 1.1.1.1 (sourced from one of our addresses)

06:22:14: RIP: received v2 update from 172.12.123.3 on Serial0

06:22:14: 1.1.1.1/32 -> 0.0.0.0 in 3 hops

06:22:14: 2.2.2.2/32 -> 0.0.0.0 in 2 hops

06:22:14: 3.3.3.3/32 -> 0.0.0.0 in 1 hops

06:22:14: 172.12.23.0/24 -> 0.0.0.0 in 1 hops

06:22:14: 172.12.123.0/24 -> 0.0.0.0 in 1 hops

06:22:14: RIP: sending v2 update to 224.0.0.9 via Loopback0 (1.1.1.1)

06:22:14: 2.2.2.2/32 -> 0.0.0.0, metric 3, tag 0

06:22:14: 3.3.3.3/32 -> 0.0.0.0, metric 2, tag 0

06:22:14: 172.12.23.0/24 -> 0.0.0.0, metric 2, tag 0

06:22:14: 172.12.123.0/24 -> 0.0.0.0, metric 1, tag 0

06:22:14: RIP: sending v2 update to 224.0.0.9 via Serial0 (172.12.123.1)

Cisco CCNA certification depends on noticing details like these, and there's no better way to learn these details than by working on real Cisco routers and switches. Whether you're renting rack time online or buying used Cisco routers and switches, real-time debugs and configurations are the way to CCNA certification exam success!

Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage, home of over 100 free certification exam tutorials, including Cisco CCNA certification test prep articles. His exclusive Cisco CCNA study guide and Cisco CCNA training is also available!

Visit his blog and sign up for Cisco Certification Central, a daily newsletter packed with CCNA, Network+, Security+, A+, and CCNP certification exam practice questions! A free 7-part course, ?How To Pass The CCNA?, is also available, and you can attend an in-person or online CCNA boot camp with The Bryant Advantage!

 

Labels: , , , , ,

Thursday, April 2, 2009

Cisco CCNP CIT Exam Training: Creating A Network Baseline

 

Creating a network baseline is an important skill for the CCNP exams, and it's even more important in real-world networks.  Learn the basic of creating a baseline from Chris Bryant, CCIE #12933.

The first thing we've got to do in order to document our network is to create a network baseline.  After all, if we don't know our goals, we can't accomplish them.  A baseline is really a "network snapshot", a picture of our network devices and their performance - which also helps us spot issues before they happen.

Every network has its "breaking point", the point at which it can no longer transfer data effectively.  By creating a baseline, you can see what the current network load is now - and by maintaining that baseline, you can spot network issues well before they become critical.  For example, say you baseline all your network routers, and part of that is noting the CPU capability and usage.  By maintaining the network baseline, you can note smaller, gradual increases in CPU usage and do something about it before the situation becomes critical.

Establishing a baseline also gives less-experienced network personnel a starting point for troubleshooting, and it gives new network support personnel a starting point as well.

To begin that task, we've got to define where this baseline will begin and end - in other words, we must define the scope of the baseline.  Some questions to ask:

What is the scope of this baseline?

What goals do we have for our network?

What network devices will be part of this baseline?

What is the objective here?  Why are we creating this baseline?

Baseline construction methods differ from one vendor to another, but I recommend the first thing you do  when creating a baseline is taking inventory.  Why?  First, it's hard to create a full network picture if you don't know everything that's in your network; second, many networks are poorly inventoried.

When you're creating network documentation, consistency is vital.  This goes for abbreviations, symbols, and icons.  There are sets of Cisco icons for use in Microsoft Visio - find and use these icons when documenting and diagramming your network.  Keep your usage of these icons consistent as well.

Decide upon your scope and your goals, and stick with that decision.  Don't start documenting one part of the network and then jump to another part. 

Also, don't hide the documentation!  If I have to substitute for you at a client site, I should be able to find the documentation without asking anyone.

Most importantly, maintain the documentation.  Nothing is worse than seeing a date at the top of a network baseline doc that's from last year. (Or the last century.)  Don't fall into the trap of "I'll catch the documentation up next week", because I can practically guarantee that no matter how great your work ethic is, something's going to happen that will distract you from getting the documentation done.  Do it now.

In short, when creating network documentation, follow these rules:

Define the scope of the documentation and stick to it.

Define your objective and the values to be documented.

Consistency is key.  Keep abbreviations and terminology consistent from document to document.

Make sure the appropriate personnel have access to the documentation.

Keep the documentation current.

Your client will thank youArticle Submission, and those that follow you will thank you as well!

Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage, home of over 200 free certification exam tutorials, including CCNA certification training articles. His exclusive CCNA study guide is also available!Visit his blog and sign up for Cisco Certification Central, a daily newsletter packed with CCNA, Network+, Security+, A+, and CCNP certification exam practice questions! A free 7-part course, ?How To Pass The CCNA?, is also available, and you can attend an in-person or online Cisco CCNA training boot camp with The Bryant Advantage!

Labels: , , , ,