CCIE Pursuit Blog

May 24, 2008

Some Of This Crap Really Has Real World Implications :-)

Filed under: BGP,Cisco,Cisco Certification,IOS,Work — cciepursuit @ 3:39 pm
Tags: , , ,

I had an issue at work with a DS3 mysteriously bouncing.  We never saw the circuit actually drop (nor any errors) but the BGP peering would sporadically drop.  After one of the engineers “solved” the problem by having AT&T set their BGP timers to match ours (see this QoD for an explanation of why that did not work) the issue came to me.  I suggested that we disable bgp fast-external-fallover and see if that at least kept the peering nailed up.  That worked!  We later found out that the site had taken a lightning strike a couple of weeks ago.  We had a vendor meet with Cisco, AT&T, the cabling vendor, and the LEC the next day.  MAGICALLY the issue “cleared while testing” once the LEC looked at the circuit.  :-)

Anyhoo…by default bgp fast-external-fallover is enabled.  This is generally a good thing as it will bring down a BGP peering if a directly connected link goes down.  No need to wait out your 3 keepalives.  In our case, their was some sporadic issue that “blinked” out the circuit (I suspect a punch-drunk repeater or some CO equipment) very briefly.  Our router would then bring down the BGP peering and then re-establish it.  By configuring ‘no bgp fast-external-fallover’ under the BGP process, we were able to keep the BGP peering up.

bgp fast-external-fallover

Usage Guidelines
The bgp fast-external-fallover command is used to disable or enable fast external fallover for BGP peering sessions with directly connected external peers. The session is immediately reset if link goes down. Only directly connected peering sessions are supported.

If BGP fast external fallover is disabled, the BGP routing process will wait until the default hold timer expires (3 keepalives) to reset the peering session. BGP fast external fallover can also be configured on a per-interface basis using the ip bgp fast-external-fallover interface configuration command.

May 6, 2008

Fun With ISPs

Filed under: BGP,Cisco,Work — cciepursuit @ 9:57 am
Tags:

Michael Morris recently vented a bit about CO techs (‘No Love For Central Office Techs’).  While I can’t agree with him about the value of unions (my father was in the IBEW and my mother is in the UAN, both of which saved our family’s ass when times were tough) I do agree with him about the flippant attitude one often encounters with carriers/LECs.  I had an interesting experience about a month ago.

A DS3 link was up and up but the BGP peering was idle.  I bounce the interface, cleared the BGP adjacency, deleted and re-added the BGP configuration, and I (eventually) reloaded the router.  Nothing changed.  The interface was up and up (I could see traffic flowing in and out of the interface) but the BGP peering would not establish. I brought our ATM subject matter expert (my ATM skills are weak) to look at the issue and he verified that ATM was working correctly.  I even looped the interface and was able to ping my interface IP address.  For whatever reason I had no layer 3 connectivity to the PER.

So I opened a ticket with AT&T and pushed them to get their BGP team involved.  They successfully tested the circuit to the CO.  Since this was a DS3 they did not have an NIU to loop at our premises.  I told them that they needed to get someone to verify the PER’s configuration (especially the BGP configuration).  They eventually verified the PER configuration.  I opened a TAC case to get the DS3 card replaced.  While the RMA was cooking, I put up a loop on my interface and asked ATT to test to it.  They successfully tested to the loop.  I dropped my loop.  Luckily, that’s when the break came.

“Thanks for your time, I’ll get Cisco to replace our card.”
“No problem.  I just ran another pattern to your loop and it was good as well.”
“Huh?”
“I just ran another pattern to your loop…”
“My loop?”
“Yes.”
“I dropped my loop 15 minutes ago.”
“Umm….”
“Are you testing the right circuit.”
“Yes.”
“Can you send a loopdown code.”
“I just did and I can still see your loop.”
“Is there a loop in the CO?”
“We’ll contact the LEC to look at that.”

Two hours later I get a call from an AT&T tech…well kind of.  The LEC for this area is SBC.  SBC recently bought AT&T.  So now the (follow me here) SBC LEC technicians refer to themselves as AT&T.  The US telecom industry can make your head explode if you try to follow it too closely. :-)  So the call was actually from the CO technician who called me by accident and thought that I was AT&T (the carrier).  The other twist to this tale, is that my company (large enterprise) does not interface directly with the LEC.  We only interface with the carrier/ISP. 

Anyhoo…the LEC tech told me that there was a loop in the CO towards the customer’s (my!) equipment and asked if I wanted it dropped (again, he thought I was the carrier and not the customer).  I asked him why the circuit was looped.

“I have no fucking idea.”
“Really?  You guys looped a DS3 for no good reason.”
“Yup.”
“Drop the loop please.”

The loop dropped, the BGP peering established, and our site was back to 100% of their bandwidth capacity.  When I called AT&T (the carrier) to get a reason for outage, they gave me the tired old “cleared while testing”.  Nice.

Actually, there was another twist to this tale.  Our NOC missed the BGP alert.  We have separate routers connected to two different carriers (AT&T and MCI) at each of our sites.  So we still had a DS3 connection to the MCI cloud.  I don’t remember how the BGP issue eventually came to light, but it had been down for nearly a week when I got involved.  It’s a testament to our bandwidth allocation (but not our network monitoring) that the site never noticed the loss of 50% of its available bandwidth.  I have NO idea how this didn’t affect their VoIP.  Anyhoo…once I finally got an AT&T BGP technician to look at this issue, he had the balls to annotate the ticket (we can view their tickets online) with “BGP has been down for a week and they’re just now opening a ticket?”  When I spoke with him I told him that we have dual carriers and that MCI hadn’t fucked up our circuit and that he should probably keep comments like that out of our tickets.  This was before we discovered that the issue was not our equipment.  Now it was my turn to be a douchebag.  When AT&T told me “cleared while testing” I told them to open a post mortem (a ticket review process) on the ticket.  Then I jumped down the throat of our ATT account manager at our next weekly meeting.

“So you’re telling me that our circuit was looped at the CO and that it took you nearly two days to figure this out AND you lied to us about the RFO?  During this time our MCI circuit handled the load.  Why should we maintain you as a carrier?”

We pay tens of millions (maybe more) dollars for our bandwidth.  Even hinting that we might axe one or our carriers in favor of the other is kind of dirty, but it makes the account managers shit their pants and jump into action anytime we mention it.  By the end of the meeting my boss got AT&T refund us for 3 months worth of charges for that DS3.  It’s good to be king.  :-)

 

April 21, 2008

Beware The Man Of One Platform

Filed under: Cisco,IOS,Switching,Work — cciepursuit @ 3:26 pm
Tags: , , , ,

I vow to never be one of those guys that expects my word to be law once I am a CCIE.  This is not because I am humble (I’m not) or because the ‘Argument From Authority’ is a logical fallacy; it’s because I am wrong more often than I care to be and I will continue to be wrong more often than I care to be regardless of any digits or abbreviations after my name.  :-)

Case in point: I was troubleshooting an issue last week and was surprised to find that the VLAN interfaces (SVIs) on a 6500 series switch (an old piece of shit 6500 switch running DECNet….but I digress) each shared a single (virtual) MAC address.  I pointed this out to one of my co-workers and he said that this was normal.  I disagreed.  I jumped on a 3750 and showed him that each SVI had a unique MAC address.  I even labbed it up quickly on my 3560 to prove my point.

We noted that this might be an interesting anomaly, but it most likely was not our issue as we were troubleshooting a duplicate IP/HSRP/DECNet/STP loop issue.

Well it turns out that we were both right (and both wrong).  Depending on the platform (and IOS version?) Cisco switches may use the System MAC Address for each SVI or they may use a unique MAC Address (derived from the System MAC Address).  CCIE candidates can see this in their labs by noting the differences between the 3560s and 3550s:

3560 uses a unique MAC for each SVI:
sw1#sh ver | i IOS|emo
Cisco IOS Software, C3560 Software (C3560-IPSERVICESK9-M), Version 12.2(25)SEE2, RELEASE SOFTWARE (fc1)
cisco WS-C3560-48PS (PowerPC405) processor (revision G0) with 118784K/12280K bytes of memory.
512K bytes of flash-simulated non-volatile configuration memory.

sw1(config-if)#do sh int | i Vlan|bia
Vlan1 is up, line protocol is up
  Hardware is EtherSVI, address is 0012.018f.d5c0(bia 0012.018f.d5c0)
Vlan2 is up, line protocol is up
  Hardware is EtherSVI, address is 0012.018f.d5c5(bia 0012.018f.d5c5)
Vlan3 is up, line protocol is up
  Hardware is EtherSVI, address is 0012.018f.d5c6(bia 0012.018f.d5c6)
Vlan4 is up, line protocol is up
  Hardware is EtherSVI, address is 0012.018f.d5c7(bia 0012.018f.d5c7)

3550 uses the same MAC for each SVI:
sw3#sh ver | i IOS|emo
Cisco IOS Software, C3550 Software (C3550-IPSERVICESK9-M), Version 12.2(25)SEE2, RELEASE SOFTWARE (fc1)
Cisco WS-C3550-24(PowerPC) processor (revision D0) with 65526K/8192K bytes of memory.

Vlan1 is administratively down, line protocol is down
  Hardware is EtherSVI, address is 000a.410e.0600(bia 000a.410e.0600)
Vlan2 is up, line protocol is up
  Hardware is EtherSVI, address is 000a.410e.0600(bia 000a.410e.0600)
Vlan3 is up, line protocol is up
  Hardware is EtherSVI, address is 000a.410e.0600(bia 000a.410e.0600)
Vlan4 is up, line protocol is down
  Hardware is EtherSVI, address is 000a.410e.0600(bia 000a.410e.0600)

Scott Morris has an article on this issue.

Now you’ll notice that all of the VLAN interfaces have the same MAC address. This is the System MAC address. The reason this is OK has to do with where MAC addresses are used.

A MAC address must be unique within a Layer2 network, a broadcast domain or subnet. Each VLAN is a separate L2 network, broadcast domain and subnet. So there should be no possibility for overlap here and nothing to worry about.

If your configuration is creating some strange bridging or other cross-VLAN behavior, there may be the possibility of odd behavior, but that isn’t the normal issue at all!

So, in the grand scheme of things, you shouldn’t see any duplicate MAC addresses in any place that makes a difference.

March 17, 2008

CCIE Salaries Redux

Filed under: Cisco,Cisco Certification,Work — cciepursuit @ 7:12 am
Tags: , , , , ,

I recently blogged about a NetworkWorld article about declining CCIE pay.  To be fair, the NetworkWorld article did not actually say that CCIE salaries were declining.  It said that in a salary survey, Routing and Switching CCIEs had average salaries that were less than the average salary for some other certifications (“Is CCIE pay slipping compared to other certifications?”).  The “slipping” refereed to the average salary of CCIEs compared to some other certifications.  Confused?  So was I.  :-)

The NW article showed that the average (US) CCIE earns $93,500.  I think that’s a livable wage.  :-)  It does, however, seem to be lower than numbers I have seen quoted before as well as the “as soon as you get your digits the money fairy descends from the heavens and hits you with her $100K wand” myth.

I looked for some other CCIE salary resources on the mighty, might Interwebs.

Certification Magazine echoes the NW articles findings in that the CCIE is not the #1 salaried certification, but their numbers show a higher average salary along with a nice increase over the last 3 years:

CertMag’s 2007 Salary Survey
Cisco CCIE, which dominated the Salary Survey in ’03 and ’04 but slipped out of the top five thereafter, came in third this year with $111,090.

CertMag’s 2006 Salary Survey
The top five certification programs saw a bit of a shake-up this year with the Cisco Certified Internetwork Expert (CCIE) falling out of the top five to sixth place with an average salary of $105,560.

CertMag’s 2005 Salary Survey: Monitoring Your Net Worth
… the Cisco Certified Internetwork Expert (CCIE), with $104,020.

Sounds good.  Well here’s a survey that shows that the median income for a US CCIE with 1 – 4 years experience is a little less than $69,000 (there were 72 respondents).

Median Salary by Years Experience – Certification: Cisco Certified Internetwork Expert (CCIE) (United States)

Brad Reese (via TCPmag.com) has a salary survey that shows US CCIEs averaging six-figures:

2008 Cisco Salary Rates

Why the wide discrepency in average CCIE salaries?  Is this a case of “lies, damn lies, and statistics”?  Maybe.  I don’t have the time nor the desire to look into the methodologies behind these surveys.  I can tell you that there are a number of variables that affect ANY salary.  If you’re a recently minted CCIE in Duluth, Minnesota then you’re very likely to be making less than a CCNP (or CCNA for that matter) in Silicon Valley or Manhattan.  Secondly, “salary” can mean different things to different people.  I think of my salary as my base salary.  I don’t include bonuses, training budget, vacation, benefits, etc. in my salary.  I remember seeing the dollar value for an FTE (Full Time Equivalent/Employee) for my current position and thinking that my employer was WAY underpaying me.  The FTE value was twice my base salary.  Of course, the FTE included ALL of my employer’s costs for that position.

Anyhoo….I still think that getting your CCIE will allow you to put clothes on your back and food on the table.  Your salary may double or it may stay the same.  If you’re doing this for money, then you have much better ROI options than the CCIE.

March 3, 2008

WO__! – Going To Internetwork Expert Mock Lab Workshop In June

If you’re confused about the title of this post – that was my lame attempt at half of a “WOOT!”  Last week I got the “it’s all good” from my company concerning my request to attend Internetwork Expert’s Mock Lab Workshop in Reno.  This is still not a 100% done deal so I hope that I’m not jinxing myself by posting this.  There are still some details to be worked out.  I need to find out if I need to pay for the class and then get reimbursed after it’s done or if there will be a PO cut.  I am also up in the air about whether or not I need to pay for my travel and expenses.  I basically went to my boss last week and asked for a decision on my training request because the Mock Lab classes are filling up quickly.  At that time I volunteered to pay my own travel and expenses if that would mean getting the training approved.  The training was approved, but I didn’t hear back about who’s buying my meals.  :-)

I now have to review my plans.  I am going to use the workshop as a final bellwether as to whether or not I am ready to take the CCIE lab.  If I find out that I am ready, it would be nice to make the drive/flight from Reno to San Jose and take the exam the following week.  I would be coming off of a week of hardcore prep and I would save myself some travel costs.  Of course, if I get the “dude, you’re not ready” report, then it would be a good idea to have my lab date at least 28 days after the end of the class so that I can either devote more study time or reschedule it altogether.  I’m leaning towards scheduling my lab for late July in case I get the thumbs down from IE.  My travel expenses will be much less than $1500 so it’s a wiser choice to give myself some options in case I am not ready.  That said, I can pretty much kiss my summer goodbye.

I REALLY wanted to take my lab before summer started, but I am sure that I would only be buying a $1500 Cisco lunch if I tried to make that deadline.  Summer means extensive house/yard work (my wife just dropped a few hundred dollars on plants so I know that I’ll be pretty busy come spring), activities for my kids (tennis and baseball – plus whatever else piques their interest), FISHING  for me (new boat plus we live on a lake), and a family summer vacation.  The biggest thing though is the ability to maintain my focus when I know that I only have a limited amount of nice days per year.  When it’s snowy and miserably cold outside, it’s much easier to sit down with a laptop and pound away at the CLI.  I guess that the point of this paragraph is that I am slowly coming to grips with the fact that the CCIE monster will likely swallow up my summer.  The CCIE is probably the most time/resource intensive thing that I’ve ever done, except for college.  At least with college you get breaks and each class offers a little (or a lot) of change from the others.  Plus, I’m finding there are a lot more parties and girls available in college than there are when studying for the CCIE.  :-)

Anyhoo…I should (barring any last minute disasters) be in Reno in June getting my IT ego crushed by the Brians.

February 6, 2008

The Sky Is Falling

Filed under: Cisco,Cisco Certification,Work — cciepursuit @ 7:41 pm
Tags: , ,

This story made the rounds at my work this week, usually hyperlinked from an email warning about the end of my networking career.

Cisco Plan Will Create 360,000 Network Engineers In India
The five-year strategy builds on Cisco’s $1.1 billion investments in Indian ventures in recent years.

Cisco (NSDQ: CSCO) released on Monday its plan to help India increase its number of networking engineers from about 60,000 today to 360,000 in five years. The plan entails, of course, training and certifying those engineers on Cisco technologies.

Cisco says it has established partnerships and is opening testing facilities to meet that workforce goal. Two of India’s largest tech training organizations, IIHT (Indian Institute of Hardware Technology) and NIIT (National Institute of Information Technology), have become certified for training on Cisco technologies. Those organizations and another, Global Knowledge and Training Partner Ltd., have begun Cisco training and certification from 200 locations in India.

Another Cisco partner in India, Pearson VUE, says it will add 150 testing facilities for Cisco certification by the end of the year, including several mobile testing centers to reach engineers in rural areas. Pearson VUE is requiring centers to adopt “increased security measures in order to safeguard the value of IT certifications.”

“With these initiatives in place, we are able to ensure that our customers and partners have the resources available to train and equip the thousands of motivated students in India with the knowledge and skills necessary to shape the country’s burgeoning information economy,” said Leo Scrivner, VP of human resources for Cisco Services & Globalisation Centre East, in a prepared statement.

Cisco inaugurated a new development center in Bangalore last October, and has spent more than $1.1 billion in Indian ventures in recent years, said a Cisco spokesman. A year ago, Cisco announced plans to triple its India-based workforce from 2,000 to 6,000 employees within several years. To support that growth, the company’s chief globalization officer, Wim Elfrink, who reports to CEO John Chambers, relocated from the United States to Bangalore last year.

I’m not going to start working on that Accounting degree or taking Hindi lessons just yet.  The article basically states that Cisco and its partners are building a training/certification infrastructure in India.  It’s my understanding that there were/are a number of testing facilities already existing in India.  Cisco’s goal of increasing the number of network engineers in India by sixfold in five years is ambitious, but what is the catalyst?  Cisco is only planning to add 4,000 of their own employees in that country (and I doubt that they are all going to be engineers).  Is there really a worldwide network (Cisco) engineer shortage of 300,000 – let alone in India?  If so, then I am vastly underpaid.  :-)

February 3, 2008

How To Look Like A Jackass

Filed under: Cisco,IOS,QoS,Work — cciepursuit @ 7:42 pm
Tags: ,

I was asked by a member of our NOC to take a look at the QoS configuration on a router to see if there were any issues.  I logged in and took a look: 

r1#show policy-map
  Policy Map FAKE
    Class FAKE1
      Strict Priority
      Bandwidth 512 (kbps) Burst 12800 (Bytes)
    Class FAKE2
      Bandwidth 128 (kbps) Max Threshold 64 (packets)
    Class FAKE3
      Bandwidth 128 (kbps) Max Threshold 64 (packets)
    Class class-default

r1#sh policy-map s0/0

r1#

The policy map exists on the router but is not assigned to the interface.  I told the NOC:

“There’s the problem.  Tell the site engineer that he did not apply the service-policy to the interface.”

A few minutes later I got a call from the engineer who supports that site:

“Why did you tell the NOC that I didn’t have QoS running on router r1?”
“Because I saw that the policy is there, but it is not applied to interface.”
“Yes it is.”
“No it isn’t.”
“Yes.  It.  Is.”

At that point I logged into the router and rechecked.  To my surprise, the policy was there:

r1#sh policy-map int s0/0

 Serial0/0

  Service-policy output: FAKE

    Class-map: FAKE1 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol edonkey
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 512 (kbps) Burst 12800 (Bytes)
        (pkts matched/bytes matched) 0/0
        (total drops/bytes drops) 0/0

    Class-map: FAKE2 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol dns
      Queueing
        Output Queue: Conversation 265
        Bandwidth 128 (kbps)Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

—OUTPUT TRUNCATED—

My first thought was that he had changed the configuration, but there were no configuration changes made.  An IOS bug?

In cases like this I have learned that the most likely suspect is myself.  This proved to be no exception.  Those of you with a good eye have already spotted my mistake:

r1#sh policy-map ?
  WORD           policy-map name
  control-plane  Show Control Plane policy
  interface      Show Qos Policy Interface
  session        Show session Qos Policy
  |              Output modifiers
  <cr>

‘show policy-map s0/0′ and ‘show policy-map int s0/0′ are not the same command.  :-)

‘show policy-map s0/0 looks for a policy-map named ‘s0/0′, while ‘show policy-map int s0/0′ shows the (inbound and outbound) policies assigned to interface s0/0.

DOH!!!!

As soon as I explained my mistake the flood of jokes at my expense began:

“Do they have QoS on the CCIE lab?  Good luck with that.”
“Why don’t you just take $1500 and light it on fire?  It’ll save you time and travel.”
“Did you hear?  Cisco has an undocumented command.  It’s called “show policy-map interface”!”
“Help!  All of my routers have lost their QoS configuration!”

And so on….all fucking day long.  :-)

It’s all in good fun.  Just be aware that if you announce that you are pursuing the CCIE, every mistake you make is going to be analyzed because you are supposed to be a guru.  :-)
 

January 30, 2008

You Snooze, You Loose

I’m pretty much set for CCIE training material.  The only thing that I really want to add before I take a shot at the lab is a Mock Lab Workshop.  I’m meeting with my manager this week for my review and will pitch this as my training class for the year.  If she says no, then I’m going to have to decide if I want to pay for this out of pocket.  If she says yea, then I’ll book it.  The only downside is that a number of the workshops have already sold out, so I’m left with the following choices:

February 11 – 15  CCIE R&S Mock Lab Workshop Online Week 1  9am PST  Sign Up – $1,995         
March 17 – 21  CCIE R&S Mock Lab Workshop Onsite (Reno, NV)  9am PST  Sign Up – $3,495               
June 16 – 20  CCIE R&S Mock Lab Workshop Onsite (Reno, NV)  9am PDT  Sign Up – $3,495               
September 1 – 5  CCIE R&S Mock Lab Workshop Onsite (Reno, NV) 9am PDT  Sign Up – $3,495      
December 1 – 5  CCIE R&S Mock Lab Workshop Online Week 1  TBA Sign Up – $1,995 

I really want to take my lab in early June because I really don’t want to keep up this study pace into the summer.  I live in Minnesota and the summer months (especially the early summer) are pretty sacred.  That said, I don’t think that I’ll be ready by 11 February and I’m not waiting until September, so my only two options are the March or June dates.  If my employer foots the bill I will probably push my lab back a couple of weeks and go in June.  If I have to pay (and I decide that it’s worth the expense), then I’ll probably go in March.

January 23, 2008

Network Device Naming Conventions

Filed under: Cisco,Personal,Work — cciepursuit @ 8:09 pm
Tags: , ,

I stumbed across this posting by Michael Morris concerning naming conventions:

When I started working on global enterprise networks it got much more interesting. Now you had thousands of routers at hundreds of sites in different rooms and closets/IDFs in all parts of the world. Now naming conventions became very important. A very large bank network I worked on was terrible: 5,000 routers with a cryptic naming convention that was (1) hard to understand and (2) not well followed. Adding to the problem was the city name of the router was often not an actual city. It was a name the bank liked to refer to the site as. Good luck trying to remember all those names. The rest of the name had some good points, but also several bad ones. It was not something I enjoyed.

The government network I worked on was minimalist. It was [city]-r1. For example, BUF-R1. Really boring and really useless. Some small company networks like to be cute and name devices after beer brands or rock bands or cartoon characters. That starts to fail quickly when the small company gets just a tad larger.

—Read The Rest Here—

My previous job was supporting an international WAN with over 3000 routers.  Not only did we have a ton of routers, but nearly 30 separate business divisions -  each of which had their own naming convention.  To add even more fun, most of the router “hostnames” were not the same as their FQDN names.  We kept a database with circuit IDs mapped to router names.  Of course, there were many deleted circuits and typos in the database.  This always made it fun when a vendor called to report a circuit down and we could not find out which device it terminated on.  Not to mention all of the tiny sites that we supported that shared a city name with a more famous, larger city.  A router named “miami” goes down and you start looking at Florida…wrong!  It’s in Miami, Oklahoma.  We had three Pittsburgh sites – none of which were in Pennsylvania.  And (as Michael Morris mentioned) there were a bunch of places (including our corporate headquarters) that were referred to by any number of local cities.  This lead to a lot of lost “support cycles” just trying to narrow down what device was being affected. 

My current job supports a uniform naming convention and it is an absolute joy to work with.  There are still the occasional anomalies, but it’s infinitely better than the mess I came from.  Our naming convention is similar to the one mention in Michael Morris’ post.  We have unique five-character real estate codes.  Prepended to that is a code for the device type.  At the end is the floor and IDF that the device is located in.  Very little time is lost trying to determine where a device is located.

I’m sure that there are a number of readers who do/did server support and have MUCH worse naming stories.  :-)

November 9, 2007

CCIE Looks Back On First Year As A CCIE

Very cool and interesting post on Group Study:

I thought I’d take a moment and do a quick review of the past year…my first year as an IE.

- Got a promotion. Same company, different department.
- Was completely confused, for like a month, by the fact I didn’t have to study anymore… man, that was weird
- First assigned task <drum roll>… team lead enterprise QoS development. My least favorite topic of topics… joy, joy! Wish I could have seen the look on my face.
- Number of times I’ve heard “We’ll you’re the IE” when presented with some off the wall question: lost count back in the spring
- Number of times I’ve said “I don’t know everything!” in response to the line above: lost count
- Number of times I’ve been asked “How did you past the lab?”: ~20
- Have received zero appreciation for my lab induced creative solutions :-)
- Have received praise for suggesting what I thought was an off-the-wall feature Cisco made me learn… go figure.
- Number of times I’ve had to clarify the fact that I’m an R&S IE when presented with VoIP, security and MPLS questions and of course the always mentioned “We’ll you’re the IE” statement: way too many
- Found out my non-IE co-workers like to make a big deal out of my mistakes… after all “I’m the IE”
- Number of times I’ve wished Cisco had not removed ATM from the lab (to make me learn it) : several! 95% of the connectivity I deal with is ATM… not sure what Cisco was thinking there.
- Surprised by the number of people who are inclined to regurgitate their resume’ when they find out I’m an IE
- Biggest screw-up: Fubar’d an ATM connection to a 400+ user call center… who knew PCR/SCR was THAT important? :-)
- Coolest new (new to me anyway) technology I’ve been working on… WAAS
- I’ve learned way more about QoS than I think I wanted to know
- Have enjoyed having access to the expertise of our Cisco AS team…instant guru on any topic
- Number of times I’ve had to deal with BGP: 2
- Number of times I’ve had to configure multicast: 0
- Surprised by the amount of knowledge I’ve lost over the last year…of course I’ve gained a lot of new stuff

All in all I’m having a blast and it was absolutely worth all the blood, sweat and tears to become a CCIE:-)

Cheers!


Scott
CCIE #17040 (R&S)

Next Page »

The Rubric Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 111 other followers