CCIE Pursuit Blog

August 30, 2007

Gigabit to the Desktop: User Perceptions vs. Reality

Filed under: Cisco,Switching,Work — cciepursuit @ 4:55 pm

I was just reading a great article by Michael Morris over at Network World.  I encourage you to read the entire article, but the basic summary is that once end users become aware that gigabit Ethernet is available, then will want to have it and will swear that they need it – even when it is obvious that they do not:

Yes, there are definitely servers, databases, and network storage in a Data Center than can fill and benefit from 1 Gbps ports, but not users. Any traffic over WAN links is going to be limited by lower WAN bandwidth and effect delay has on TCP. So, unless you’re sitting on the same LAN as the DC with a home-built, water-cooled super-PC running your own compiled version of Linux……YOU DON’T NEED A GIG PORT!

I have fought this very same battle.  My battle began with server owners adding gigabit Ethernet cards to their servers and then expressing dismay with “the network bottleneck” because we only offered them 10/100 ports (this was a few years ago).  Even when we showed the server owners that they very rarely (and most times – never) came close to the 100 megabit port speed, they insisted that they needed gig speed.  In their minds they had gigabit cards and they were being throttled back at the switchport.  We eventually built a gigabit switched network and then charged them twice as much per port (“We’re giving you 10 times the speed at only twice the cost.”).  Even when we were able to show statistics to the server owners that they were still running way under 100 megs, they consistently claimed that they were getting better throughput with the gigabit connection. [Again, this was a few years ago.  There are servers now that do use gigabit speeds, like SAN servers and also during backups.  This was not the case then.]

A collegue and I decided to do an experiment.  Since we couldn’t change the speed on the port connected to the server because they would notice it, we instead set the uplink to 100 megabits.  With only one device on the switch, that server could use the full 100 megs on the uplink to the core switch.  The setup looked like this:

Server NIC (1000 Meg)—–(1000 Meg) Switch Port | Uplink Port (100 Meg) —–(100 Meg) Core Switch Port

First we set the switch port to 100 Full and told the server owner to set their NIC to the same. 

“Can’t I get gig?”
“Sure, but our policy is only to give gig to servers that require it.”
“We need it.”
“Based on your traffic patterns, we don’t think that you do.  BUT… if you have response issues we can give you a gig.”

Sure enough, even though we never saw more than 30 Megs pumping through the switchport, the server owner was soon compaining of “slow response.”  We increased the port speed to 1 gig, BUT left the uplink to the core switch (well, actually one of the distribution switches) at 100 Meg.  To nobody’s surprise, the server owner claimed that his “slow response” issues were gone.  We never told him that the only gigabit connection was from his NIC to the switchport, because we did not want to get fired.  :-)

*Note:  looking back on this, the server owner may not have even perceived any slowness.  He may have lied about this in order to get the gig connection just because he was tweaked about initially being denied the connection.  Admittedly, this was not a perfect test. 

In another instance, my company bought a much smaller company and I was sent out to integrate the network.  The “network guy” had installed some HP switches and was balking at the cost/nescessity of replacing those with Cisco 3750s.  He bragged about the HP running gigabit to the desktop.  This was unfortunately not true.  The HP switches DID have gigabit capability (the 3750s that we were going to replace them with were 10/100) BUT none of the PCs had gigabit NICs.  Everyone was running at 100 Full.  I could not get it through his head that this was the case.  PLUS, the HPs did not sufficient backplane capacity to handles multiple machines at gigabit speed, NOR did they have uplink ports capable of handling more that gigabit speed.  The coup de grâce was that all of their servers were housed in a data center in another state that they connected to via a T1 line!  Even after trying to explain that no matter how fast the PC could speak to the switch, there was no way that it could communicate with one of the data center servers at anything more than 1.5 megabits per second.  No sale.  He was still convinced that installing the 3750s would cripple their network.  Unfortunately, he spread this rumor around the site.  Anytime that there was the slightest perceived “slowness” issue, I got a call claiming that the new switches were too slow.  ARRGGHHH!!!!

I’ve also seen this disconnect with home users.  Friends of mine SWEAR that thier “Pre-N” wireless access points give them “way faster” access to the Internet.  I try to tell them that no matter how fast they can communicate with their AP, their not going to access the Internet any faster than their cable/DSL modem allows them.  You can guess how this battle usually ends.  Sigh.

The moral to this story?  Once end users know that there is some faster, shinier, cooler technology available they will feel that they NEED it in order to do thier job –  even when it can be empirically shown that they don’t.

August 29, 2007

Cisco says “Total IP traffic will nearly quintuple from 2006 to 2011″

Filed under: Cisco — cciepursuit @ 4:03 pm

Increased traffic = job security?  Let’s hope so.  From Network World:

Video will drive a 21% compound annual growth rate in business IP traffic across WANs from 2006 to 2011, according to a forecast on global IP traffic released this week by Cisco.

That and consumer traffic, which will surpass business IP traffic in 2008, will cause overall IP traffic to almost double every two years through 2011, the Cisco report finds. Total IP traffic will nearly quintuple in the five-year period from 2006 to 2011, driven by high definition video and high speed broadband penetration, the firm says.

Cisco’s report is based on its own estimates plus projections from 10 market analysis firms on the number of Internet users, broadband connections, video subscribers, mobile connections, and Internet application adoption.

0820cisco.jpg
On the business side, Cisco found that business IP traffic — all fixed IP WAN or Internet traffic generated by organizations — will grow fastest in developing markets and Asia-Pacific. North America, Western Europe and Japan will have slower growth rates.

In volume, North America will continue to have the most business IP traffic through 2011, followed by Western Europe and then Asia-Pacific.

Meanwhile, business Internet traffic — all IP traffic that crosses an Internet backbone — will grow at a compound annual growth rate of 23% from 2006 to 2011, driven by increased broadband penetration in the small business segment.

Read the rest of the article here.

August 28, 2007

Verify Each Task Before You Proceed…Even In The Real World

Filed under: Cisco,Cisco Certification,OT: Humor,Personal — cciepursuit @ 3:15 pm

Today I started the task of replacing all of the electrical outlets in our house.  We bought a bunch of brass fixtures to replace the plastic ones.  I made the – now regrettable – suggestion that since we were dumping a bunch of money into fancy face-plates, we should also replace the old, yellowing electrical outlets.  My wife agreed and then quickly delegated the task to me because I have a Y chromosome which somehow gives me an instinctual ability to do home wiring.  I started my task and after I replaced the first light-switch, I flipped the power breaker back on and tested the light to make sure that it worked.  Success!  I then followed the same procedure after I replaced the first couple of electrical outlets.  Then, buoyed by my initial success, I decided to knock out the next five outlet replacements without the added delay of turning the power back on to verify each outlet.  As you can guess, this was a big mistake.  After replacing the last outlet and throwing the breaker, I found out that most (but not all) of my outlets did not work any longer and neither did my light-switch which was working before.

I had skipped the inconvenience of verifying each task (in this case each replaced electrical outlet) in order to complete the job quicker.  I made a mistake somewhere along the way – which I would have isolated had I stayed true to my troubleshooting methodology – and now was in the unenviable situation of having to go back and check the wiring on each outlet.  Eventually, I found the problem.  One of the wires was loose.  It was a wire that was run from the light-switch to a few of the outlets, obviously some DIY wiring project by the former owners.  A job that would have taken me two hours at most, became a 4 hour ordeal in which I was seriously considering calling an electrician to get to the house before my wife got home.  Damn the cost!  I just did not want to explain how I had “broken the electricity”.

Anyhoo…hopefully this hammers home the need to verify each task as you complete it when you undertake large projects like completing a practice lab.  The time that you might save will pale in comparison to the time it takes you to backtrack and discover your mistake.

August 27, 2007

Ping Test on 3550/60 Switches

Filed under: Cisco,Cisco Certification,IOS,Switching — cciepursuit @ 10:42 am

A simple TCL script can be invaluable for testing connectivity in the CCIE lab.  It turns out that the 3550 and 3560 series of switches do NOT support TCL scripting:

3550:
sw3#sh ver | i IOS
Cisco IOS Software, C3550 Software (C3550-IPSERVICESK9-M), Version 12.2(25)SEE2,
 RELEASE SOFTWARE (fc1)
sw3#t?
telnet  terminal  test  traceroute  tunnel <-no tcl
 
3560:
sw1#sh ver | i IOS
Cisco IOS Software, C3560 Software (C3560-IPSERVICESK9-M), Version 12.2(25)SEE2,
 RELEASE SOFTWARE (fc1)
sw1#t?
telnet  terminal  test  traceroute  tunnel <-no tcl

Since the switches used in the CCIE lab do not support TCL scripting, is it possible to set up an automated ping test similar to a TCL script on these devices?  The answer is yes.  We can use a macro to get the same functionality as a simple TCL ping script:

3550:
sw3(config-if)#do sh ip int br | e ass
Interface              IP-Address      OK? Method Status                Protocol
Loopback0              100.0.0.100     YES manual up                    up
Loopback1              100.0.1.100     YES manual up                    up
Loopback2              100.0.2.100     YES manual up                    up
sw3(config-if)#macro name PING
Enter macro commands one per line. End with the character
‘@’.
do ping 100.0.0.100
do ping 100.0.1.100
do ping 100.0.2.100
@
sw3(config)#macro global apply PING

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

3560:
sw1(config-if)#do sh ip int br | e ass
Interface              IP-Address      OK? Method Status                Protocol
Loopback0              10.0.0.100      YES manual up                    up
Loopback1              10.0.1.100      YES manual up                    up
Loopback2              10.0.2.100      YES manual up                    up
sw1(config-if)#macro name PING
Enter macro commands one per line. End with the character
‘@’.
do ping 10.0.0.100
do ping 10.0.1.100
do ping 10.0.2.100
@
sw1(config)#macro global apply PING

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


Cisco Documentation:

macro command (3550)

macro command (3560)

Status Update: 20 – 26 August

Filed under: Cisco,Cisco Certification,Personal,Status Updates — cciepursuit @ 10:16 am

Well, it was bound to happen.  This week I fell off of the CCIE study horse.  I had planned to do the following:

My goals for this week are to get 20 hours of labs done as well as reread the RIP chapter in Routing TCP volume 1 as well as review the IEATC RIP video. I’ll try to start on EIGRP as well.

This week was a mess because of the continuing painting, upgrading, moving crap going on at my house.  Plus, I had relatives in town.  But I still had enough downtime that I could have easily met my goals for this week.  Instead, I put off firing up Dynamips and labbing away because I was feeling lazy and because I had deluded myself into thinking that I need a block of at least four hours in order to do any “significant” labbing.  I went into the weekend with a big fat zero hours of lab time completed.

I did manage to get in a lot (for me) of lab time (16 hours) over the weekend.  I am proud of that.  Much like working out or dieting, it becomes really easy to completely blow off studying when you know that you are not going to meet your self-prescibed goals.  Much like one missed day at the gym quickly becomes a week, so it is with keeping up with CCIE studies.  I still managed to avoid the temptation to just fly through the labs just to put some numbers on the board.   I did manage to complete RIP and 90% of EIGRP this week(end).  Not the most difficult of topics, but still good to hammer home the easy stuff before tackling the harder technologies.  And even though RIP and EIGRP are easy in comparison to OSPF and BGP, I never touch either protocol at work, so I still need the practice.

I am really wanting to get started on full labs, but I still have a ton of labs and reading to get under my belt before I start to tackle full labs. 

This week will I plan to finish up EIGRP.  I have a set of EIGRP labs from CCBootcamp, so I’ll probably spend most of my the weekdays plowing through that material.  Then I plan to start on OSPF.  This is going to require going over the OSPF lessons in the IEATC.  There are probably a good 12 – 18 hours of lessons, so this week is going to be pretty video heavy.   I may just read my notes on the first week’s OSPF lessons, but I’ll definitely need to review the more advanced topics.

So here are my goals for this week: 20 hours of EIGRP/OSPF labs and 8 hours of reading/videos.

Days Until Lab: 218
Readiness (1 to 10): 1
Lab Hours This Week 16
Study Hours This Week (estimate): 4

August 25, 2007

CCIE Lab Strategy: A Structured Approach – V-Seminar On Demand

Filed under: Cisco,Cisco Certification,Lab Tips,Training Materials — cciepursuit @ 10:51 am

Internetwork Expert has posted the recording of their free V-Seminar “CCIE Lab Strategy: A Structured Approach” that was recorded earlier this week.  The V-Seminar page is here and the recording is here.

August 22, 2007

Beware the Q!

Filed under: Cisco,Cisco Certification,IOS — cciepursuit @ 12:32 pm

When logging out of a Cisco device, I use “lo”.  Occasionally, I’ll have someone watching over my shoulder and they will ask why I use “lo” when most people use “exit”.  I learned to use “lo”(alias for “logout”) way back in the day when I was studying for my first CCNA attempt (back in 2000).  The study guide that I used advised that “logout” was the “official” Cisco method for logging out of a device.  I have no idea if this truly is(was) the case or not.  I got used to using “lo” and have used it ever since.

Whenever I execute a command that generates a large amount of output (such as “show run”) and I want to break out of the command, I use “l”.  I could use (nearly) any character, but I use “l” because it’s the first letter of my name (there goes my Internet anonymity  :-) ).  A few years ago I was in a training class and the instructor (a CCIE) told me that the “official” Cisco character to use in this case is “q”.  He told me that another reason that I should use “q” is so that I do not accidently type “lo” when I use “l”.

I can hear you thinking, “Wow.  This is really fascinating.  What’s his point?”  Well, the other day I had an engineer over my shoulder while I was troubleshooting a router.  The WAN connection was bouncing, so I had dialed into the router via a modem connected to the AUX port.  Unfortunately, every command was taking a long time to execute because the router was trying to authenticate the commands with a TACACS+ server.  The connection to the server was bouncing with the WAN link, so I had to wait until it timed out (or I got lucky and the command got through while the link was up).  I had executed some command that generated a large amount of output.  I got what I needed and was going to type “l” to break out of the command.  The engineer over my shoulder is a CLI stickler.  He will go off every time he sees someone use “wr” instead of “copy run start”.  He also hates that I use “lo” instead of “exit”.  Not wanting to endure one of his pointless sermons, I hit “q” to break out of the command.

One of two things must have happened:

1) I hit “q” twice.
2) I hit “l” (force of habit) and then hit “q”.

Either way, I was suddenly logged out of the router.  If you enter “q” you will “quit” your session and be logged out.  Ah crap.  I avoided the CLI sermon, but I caught the full brunt of the “Why did you log out of the router?  You know that you could lock us out of the….” tirade.  I hit enter and everything was okay.  I shut down the WAN link and went on from there.

The lesson is that although “q” may be the official Cisco method of breaking out of a command (I’ve never verified this) but you need to make sure that you don’t accidently log yourself out of a device.  With “l”, you’ll only confuse the router (% Ambiguous command:  “l”) and not log yourself out.  :-)

Frame Relay Inverse-ARP Weirdness

Filed under: Cisco,Cisco Certification,IOS,Lab Tips,Tech Tips — cciepursuit @ 9:05 am

I came across an interesting Frame Relay inverse-ARP issue:

Here’s my intitial configuration (Frame Relay inverse-ARP disabled):
r4(config-if)#do sh run int s0/0
Building configuration…

Current configuration : 136 bytes
!
interface Serial0/0
 description ->r1 FR (spoke)
 no ip address
 encapsulation frame-relay
 shutdown
 no frame-relay inverse-arp
end

Let’s turn on Frame Relay inverse-ARP:
r4(config-if)#frame inv
r4(config-if)#do sh run int s0/0
Building configuration…

Current configuration : 143 bytes
!
interface Serial0/0
 description ->r1 FR (spoke)
 no ip address
 encapsulation frame-relay
 shutdown
 no frame-relay inverse-arp IP 405
end

WTF???  Where did that command come from?  Here’s the IOS version that I’m running:

r4(config-if)#do sh ver | i IOS
Cisco IOS Software, C2600 Software (C2600-ADVENTERPRISEK9-M), Version 12.4(10),
RELEASE SOFTWARE (fc1)

This command was something that I had configured on an earlier lab.  Even though I had turned off Frame Relay inverse-ARP (“no frame inverse”) for the ALL DLCIs, once I re-enabled it, it restored the old configuration that was disabling Frame Relay inverse-arp for DLCI 405 only.  This is a good “feature” to be aware of so it does not bite you in the ass on the exam.  [I should have just defaulted the interface instead of peeling off commands one at a time :-) ]

Let’s make sure that Frame Relay inverse-ARP is enabled for all DLCIs:
r4(config-if)#frame-relay inverse-arp IP 405
r4(config-if)#do sh run int s0/0
Building configuration…

Current configuration : 108 bytes
!
interface Serial0/0
 description ->r1 FR (spoke)
 no ip address
 encapsulation frame-relay
 shutdown
end

LFU 3 – Get Your Frame Relay Maps Right

Filed under: Cisco,Cisco Certification,IOS,Lab Fuck Ups — cciepursuit @ 8:49 am

While doing a Frame Relay lab, I came across an interesting issue.  I was doing ping tests to verify connectivity and that broadcasts were enabled:

r2#p 255.255.255.255 re 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 255.255.255.255, timeout is 2 seconds:

Reply to request 0 from 10.0.0.1, 76 ms
Reply to request 0 from 10.0.0.1, 76 ms

Huh?  Why am I getting TWO replies from r1?  A quick look at the Frame maps shows the problem:

r2#sh frame map
Serial0/0/0 (up): ip 10.0.0.1 dlci 201(0xC9,0x3090), dynamic,
              broadcast,, status defined, active
Serial0/0/0 (up): ip 10.0.0.2 dlci 201(0xC9,0x3090), static,
              broadcast,
              CISCO, status defined, active

Doh!!!!  I need to stop configuring the wrong IP address in my frame maps.  In this case, Frame Relay inverse-ARP mapped DLCI 201 to the correct ip (10.0.0.1) and I statically mapped it to the wrong ip (10.0.0.2).  This fuck up is insidious in that my end-to-end ping tests worked perfectly (I was able to ping r1 from r2 via the dynamic Frame mapping) so I could have easilly overlooked this mistake.  I know that I need to map the local DLCI to the remote IP address, but sometimes my fingers and mind conspire against each other.  At least I was able to quickly identify the problem in this case.

OG CCIE Explains The CCIE Numbering System

Filed under: Cisco,Cisco Certification — cciepursuit @ 8:23 am

Interesting post concerning the CCIE numbering system from one of the original CCIEs:

CCIE test and numbering
A lot of people have misconceptions about the CCIE (Cisco Certified Internetwork Expert) program and its numbering. I was consulting at Cisco in 1993 when I first heard about the program and inquired about participating. Brad Wright was the program manager and he knew what I had been doing with Cisco (CLI development, consulting, and training) and told me what I needed to do. I quickly re-worked my schedule and took the written qualification test, attended the Cisco Troubleshooting class, and setup a time for the hands-on test, all within two weeks.

In those days, the hands-on test was two days. One day of build-it and one day of fix-it after they break it. Stuart Biggs, one of the senior Customer Engineers at Cisco, assembled the lab gear and wrote up the test. The network gear was AGS, AGS+, and MGS routers. Cisco didn’t have switches at that time. I kept Stuart running around getting documentation, appliques (for the AGS gear), cables, and other things. I don’t know which of the two of us was busier.

The lab was assigned the number 1024 and had a plaque on the door (someone told me that the plaque has been kept and moved to one of the new test labs). Stuart was awarded 1025 as the person who created the test. I passed the hands-on test, fixing the things he broke in just over half a day. I was awarded CCIE # 1026 in August, 1993, the first non-Cisco person to achieve the CCIE and the first to take the test. A bunch of Cisco employees soon followed and many of them are still working at Cisco. Something like five of the first ten CCIEs work in the same building at Cisco.

Occasionally, I’ll have someone tell me that they met a CCIE who has a number lower than either Stuart’s or mine. I just laugh. There’s a Cisco web page where you can check the status of CCIEs. You have to know their CCIE registration name. It is a good thing to check when interviewing CCIEs.

-Terry

Next Page »

The Rubric Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 114 other followers