CCIE Pursuit

May 15, 2008

Lab Tip: Remembering IP Precedence Values

I’ve never bothered to memorize the Cisco descriptions of IP Precedence values (i.e. IP Precedence 4 is “flash-override”).  I’ve hit a couple of labs which ask you to manipulate traffic based on these descriptions.  For instance:

“Drop all flash traffic coming into r1 from VLAN 6.”

Some commands such as ‘random detect precedence’ only use the 0 - 7 values: 

r1(config-if)#random-detect precedence ?
  <0-7>  IP precedence
  rsvp   rsvp traffic

You could look this up in the DOC CD, but there’s a quick and dirty way to do this on the command line.

1) Create a class-map.
2) Type ‘match ip precedence ?’ to see the context-sensitive help.  This will give you a list of the IP Precedence values along with their descriptions.
3) Get what you need and remember to delete the class-map.

Rack13R6(config)#class-map FAKE
Rack13R6(config-cmap)#match ip precedence ?
  <0-7>           Enter up to 4 precedence values separated by white-spaces
  critical        Match packets with critical precedence (5)
  flash           Match packets with flash precedence (3)
  flash-override  Match packets with flash override precedence (4)
  immediate       Match packets with immediate precedence (2)
  internet        Match packets with internetwork control precedence (6)
  network         Match packets with network control precedence (7)
  priority        Match packets with priority precedence (1)
  routine         Match packets with routine precedence (0)

Rack13R6(config-cmap)#exit
Rack13R6(config)#no class-map FAKE

Question Of The Day: 15 May, 2008

Topic: OSPF

You are rolling out 10 Gigabit links across your core network.  You are running OSPF in your core.  You’ve noticed that the OSPF cost for the new 10 Gigabit links is 1.  This is the same as your FastEthernet and Gigabit links.  You are tasked with configuring the core routers so that the 10 Gigabit links will have a default OSPF cost of 10.


Yesterday’s Question

Question Of The Day: 14 May, 2008 

Topic: OSPF

r1 and r2 are running OSPF in area 0.  They have established a neighbor adjacency over a single serial interface.  Configure LSAs on this adjacency to set the DoNotAge bit.

Answer:

r1 (or r2)
interface s0/0
 ip ospf demand-circuit

By default, an LSA will be refreshed every 30 minutes regardless if there are any changes in the network topology.  This is sometimes referred to as a ‘periodic’ or ‘paranoid’ update.  You can disable this update with the ‘ip ospf flood-reduction’ command.  Another way that you can accomplish this is by configuring the link as an OSPF demand circuit.

ip ospf demand-circuit

Usage Guidelines
On point-to-point interfaces, only one end of the demand circuit must be configured with this command. Periodic hello messages are suppressed and periodic refreshes of link-state advertisements (LSAs) do not flood the demand circuit. This command allows the underlying data link layer to be closed when the topology is stable. In point-to-multipoint topology, only the multipoint end must configured with this command.

Before:
r2#show ip ospf database router 1.1.1.1 | i LS
  LS age: 3
  LS Type: Router Links
  LS Seq Number: 8000000C

After:
r1(config)#int s0/0
r1(config-if)#ip ospf demand-circuit

Real World Warning: This will reset your OSPF neighbor adjacency:

*Mar  1 00:14:11.271: %OSPF-5-ADJCHG: Process 100, Nbr 2.2.2.2 on Serial1/0 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar  1 00:14:15.051: %OSPF-5-ADJCHG: Process 100, Nbr 2.2.2.2 on Serial1/0 from LOADING to FULL, Loading Done

r2#show ip ospf database router 1.1.1.1 | i LS
  LS age: 5 (DoNotAge)
  LS Type: Router Links
  LS Seq Number: 8000000E
r2#show ip ospf interface s1/0

Serial1/0 is up, line protocol is up
  Internet Address 10.1.12.2/24, Area 0
  Process ID 100, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 64
  Run as demand circuit.
  DoNotAge LSA allowed. 
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:09
  Supports Link-local Signaling (LLS)
  Index 1/1, flood queue length 0
  Next 0×0(0)/0×0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 4 msec, maximum is 4 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 1.1.1.1  (Hello suppressed)
  Suppress hello for 1 neighbor(s)

You only need to configure ‘ip ospf demand-circuit’ on one side of the link.  It will affect the DoNotAge bit on BOTH sides of the link (unlike the ‘ip ospf flood-reduction’ command):

r1#show ip ospf database router 2.2.2.2 | i LS
  LS age: 5 (DoNotAge)
  LS Type: Router Links
  LS Seq Number: 8000000C

This is good to keep in mind during a lab.  A task may ask you to set the DoNotAge bit on both sides on the link but restrict you to configuring only one side.

 

May 14, 2008

Question Of The Day: 14 May, 2008

Topic: OSPF

r1 and r2 are running OSPF in area 0.  They have established a neighbor adjacency over a single serial interface.  Configure LSAs on both ends of this adjacency to set the DoNotAge bit.  Do not use the ‘ip ospf flood-control’ command.

r1#show ip ospf interface | i proto|Network Type
Serial1/0 is up, line protocol is up
  Process ID 100, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 64

r1#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  -        00:00:37    10.1.12.2       Serial1/0

r2#show ip ospf interface | i proto|Network Type
Serial1/0 is up, line protocol is up
  Process ID 100, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 64

r2#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           0   FULL/  -        00:00:33    10.1.12.1       Serial1/0

Click Here For The Answer


Yesterday’s Question

Question Of The Day: 13 May, 2008 

Topic: OSPF

r1 and r2 are running OSPF in area 0.  They have established a neighbor adjacency over a single serial interface.  Configure LSAs on this adjacency to set the DoNotAge bit.

Answer:

r1 (or r2)
interface s0/0
 ip ospf flood-reduction

ip ospf flood-reduction

Reducing LSA Flooding

By default, an LSA will be refreshed every 30 minutes regardless if there are any changes in the network topology.  This is sometimes referred to as a ‘periodic’ or ‘paranoid’ update.  You can disable this update with the ‘ip ospf flood-reduction’ command.

Before:
r2
#show ip ospf database router 1.1.1.1 | i LS
  LS age: 153
  LS Type: Router Links
  LS Seq Number: 80000004


After:
r1
(config)#int s0/0
r1(config-if)#ip ospf flood-reduction

Real World Warning: This will reset your OSPF neighbor adjacency:

*Mar  1 00:09:28.623: %OSPF-5-ADJCHG: Process 100, Nbr 2.2.2.2 on Serial0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar  1 00:09:34.975: %OSPF-5-ADJCHG: Process 100, Nbr 2.2.2.2 on Serial0/0 from LOADING to FULL, Loading Done

r2#show ip ospf database router 1.1.1.1 | i LS
  LS age: 5 (DoNotAge)
  LS Type: Router Links
  LS Seq Number: 80000006

Whichever side of the link you configure this command on, it will affect the other side of the link.  In our example I applied the configuration on r1 only, so r2 is affected.  r1 is not:

r1#show ip ospf database router 2.2.2.2 | i LS
  LS age: 124
  LS Type: Router Links
  LS Seq Number: 80000004

If you need to affect both sides of the link, then you’ll need to apply it to both sides of the link.

There is at least one other way to accomplish this task….and that is today’s Question of the Day.  :-)

May 13, 2008

Question Of The Day: 13 May, 2008

Topic: OSPF

r1 and r2 are running OSPF in area 0.  They have established a neighbor adjacency over a single serial interface.  Configure LSAs on this adjacency to set the DoNotAge bit.

Click Here For The Answer


Yesterday’s Question

Question Of The Day: 12 May, 2008 

Topic: RIP

r1 is a high-end router running RIP on it’s connection to the low-speed router r2.  The site engineer for r2 has noticed that the routing table on r2 is losing RIP routes.  He thinks that your r1 is sending RIP updates too quickly for r2 to process.  Configure r1 to implement a 25 millisecond delay between RIP packets.

Answer:

router rip
 output-delay 25

RIP will send up to 25 RIP routes per RIP update packet.  By default, these packets will be sent with no delay between packets.  In order to implement a delay between the packets you can use the ‘output-delay’ command under the RIP process.

output-delay

May 12, 2008

Booking the CCIE Lab

Filed under: Cisco, Cisco Certification, Lab Tips — cciepursuit @ 9:19 am
Tags: , , ,

I passed the CCIE Routing and Switching written exam in mid March.  I was unable to login to the CCIE database to schedule my exam.  The problem was pretty obvious to me.  My test results listed my Cisco ID as “ID Pending”.  I had used Prometric for all of my previous certification exams and this was the first time that I had used VUE.  For some reason my Cisco ID was not in their system.  I waited the mandatory two weeks and then opened a ticket with Cisco.  I provided Cisco with all of my information and it looked like the issue would be resolved soon.  Then a week went by.  I asked for an update.  Another week went by.  Then the ticket was updated and set to close.  The last entry by Cisco:

“You need to login to the CCIE database to get your information.”

WTF???  I opened the ticket because I could NOT login to that database.  This was like telling someone who had locked their car keys in their car “You need to unlock your car and get your keys so that you can use them to unlock your car.”

I spent another week seeing if I could make headway with VUE.  That didn’t work so I opened another ticket with Cisco.  Within a couple of hours my issue was resolved and I could login.  It was now about 6 weeks since I passed the written exam.

I have been planning on taking my lab in San Jose in late July.  I plugged in July 21 to see which slots were available.  The database showed me dates in October.  Oh hell no.

I went a differnt route and just plugged in today’s date.  I saw a number of very recent dates available.  The database will show you 5 dates at a time.  I saw dates in mid June and then….early October.  :(

I bit the bullet and scheduled my lab for October 2.  I’ll just have to play the same dreary game that most candidates play: keep checking the database for slots that may come available for my preferred date.

So I plugged in my information with credit card in hand.  Then I got a bit of a shock.  I knew that Cisco does not charge your card until 28 days prior to the lab.  What I did not know is that you don’t need to provide a payment method until that time. 

Lab Request Completed
 
Your lab exam has been scheduled as requested and shown below. Be sure to review the lab preparation guidelines and best of luck on your exam.
 
Please print this page and keep it for your reference.
You may also click on Certification Status (at left) to review scheduled exams.
——————————————————————————–
 
Lab Date: 02-Oct-2008
Location: San_Jose
Lab Type: Routing and Switching
Payment Due Date: 04-Sep-2008
 
——————————————————————————–

So basically, anyone who has passed the written exam can schedule a lab date with no financial obligation until 28 days before the exam.

Cancellation Policy
Candidates must read and indicate they understand the CCIE cancellation policy before a lab date can be confirmed.

Lab dates may be cancelled or rescheduled without penalty up until the payment due date, 28 days before the scheduled lab date. Rescheduling is required for any change to lab date, track or location.
 
Once the payment due date has passed, we cannot refund payments for rescheduling, cancellations or no shows. Rescheduling a lab after the payment date has passed will require an additional payment of $1400US. Our labs have only a limited number of seats and we are unable to book another candidate to replace you so close to the exam date.
 
If you decide not to attend a scheduled lab date, you will be marked as a “no show” and will not be able to re-book any date for the next 30 days.

No wonder the lab is so booked up.  No wonder that a number of lab slots come available within 28 days of a preferred date.

I have seen this viewpoint voiced on GroupStudy and I support it as well: Cisco should take payment immediately when a lab date is scheduled.  That would decrease the number of “soft” slots that are scheduled.  Cisco could still allow you to reschedule outside of the 28 day mark, but just not provide refunds.  This would decrease the amount of daily lab date fishing.

As it stands, I’ll stick with the October date.  I hope to have a good idea of where I’m at preparation wise after the Mock Lab Workshop in June.  If I get a green light then I’ll start fishing for an earlier date.  If not, I’ll just stick with my October date.
 

Question Of The Day: 12 May, 2008

Topic: RIP

r1 is a high-end router running RIP on it’s connection to the low-speed router r2.  The site engineer for r2 has noticed that the routing table on r2 is losing RIP routes.  He thinks that your r1 is sending RIP updates too quickly for r2 to process.  Configure r1 to implement a 25 millisecond delay between RIP packets.

Click Here For The Answer


Yesterday’s Question

Question Of The Day: 06 May, 2008 

Topic: EIGRP

Limit r1’s FastEthernet0/0 interface to only be able to use up to 3Mbps for EIGRP traffic.

router eigrp 100
 no auto-summary
 network 10.1.12.1 0.0.0.0
!
interface FastEthernet0/0
 ip address 10.1.12.1 255.255.255.0
 speed 100
 duplex full

Answer:

interface fa0/0
 ip bandwidth-percent eigrp 100 3

By default, EIGRP can use up to 50% of an interface’s bandwidth.  You can control that percentage with the ’ip bandwidth-percent eigrp’ command.

ip bandwidth-percent eigrp

Usage Guidelines
EIGRP will use up to 50 percent of the bandwidth of a link, as defined by the bandwidth interface configuration command. This command may be used if some other fraction of the bandwidth is desired. Note that values greater than 100 percent may be configured. The configuration option may be useful if the bandwidth is set artificially low for other reasons.

In our example, r1’s fa0/0 interface is hard-set to 100Mbps so we need to limit EIGRP to 3% of that bandwidth.

 

 

May 11, 2008

Regular Expressions Documentation

Filed under: Cisco, Cisco Certification, Cisco Documentation, IOS — cciepursuit @ 8:31 am
Tags: , , ,

The regular expressions documentation is located in an odd corner of the DOC CD - under Terminal Services Configuration.  You may want to practice finding it a couple of times before your exam day:

12.4 Documentation Home ->
Configuration Guides ->
Cisco IOS Terminal Services Configuration Guide ->
Appendixes ->
Regular Expressions

 

May 8, 2008

Arden Packeer Is A CCIE!!!

Filed under: CCIE Blogs, Cisco, Cisco Certification — cciepursuit @ 10:36 am
Tags: , , ,

While the IT gods were hammering me this week, they were shining brightly on Arden Packeer (actually no supernatural assistance was needed, Arden was more than prepared for the lab). Arden became CCIE #20716.  He has posted his story so surf on over and show him some love.

Congratulations Arden!!!

Ethan and Arden both went one and done on the lab.  Thanks for raising the expectation bar you guys.  :-p

 

Off The Grid :-)

Filed under: Personal — cciepursuit @ 10:11 am
Tags:

I must have angered the IT gods this week.  On Sunday the drive on my work laptop fried.  I very rarely use a docking station, but my laptop does not have a DB15 connector so I’ve been using a USB converter to connect to my lab stack.  The USB converter died, so I pulled out my docking station and used it because it does have a DB15 connector.  As I was wrapping up on Sunday, I popped the laptop out of the docking station and my laptop rebooted.  Then it came up with a blue screen telling my my PsMain.db is corrupt.  Oh joy.  It may still be salvageable as the error I’m getting is from my disk encryption software.  My dilemma is that if I give it to our desktop support staff, they are very likely to just re-image the entire drive.  Of course, I have a ton of CCIE notes and configurations on that box that I never bothered to back up (I know - I’m an idiot).  That’s a tough lesson to learn.  :-(

On Monday I got a new boss.  This guy is like antimatter to me.  I took Tuesday - Thursday off to cool down and concentrate on my studies.  The CCIE is looking SO much more like a nescessity to me right now.  My chances of staying with my current company after getting my CCIE just dropped from 90% to about 10% if I have to work for this jackass.

I planned to really knuckle down on multicast (one of my big weaknesses).  I even bought some rack rental credits with IE and planned to get some labbing done.  I made a couple of blog posts and then did some yard work before the expected thunderstorm rolled in.  The rain hit and I went inside to start my studies only to find that my cable Internet connection was down.  I called the vendor and they told me that they would send a tech out on Thursday.  He just left my house.  The problem was a bent pin in the pedestal.

Two full days without Internet access - what a horror.  I am officially addicted to the Internet.  I didn’t even realize how much I used it.  What’s the temperature?  I’ll just hit weather.com.  Who’s winning the Democratic primaries?  Off to CNN.com.  Did Edith Piaf really have an affair with a Moroccan boxer who died in a plane crash (the down time let me catch up on some movies like ‘La Vie En Rose’)?  Off to wikipedia.com.

I’ve decided to finally capitulate and get a cell phone with a dataplan and Internet access.  Up until this point I have purposely only used cell phones with no bells and whistles.  My phone does voice and is text-capable.  After being separated from the life-giving teat of the Internet for 48 hours, I am finally seeing the need for another method of web access.

I have learned my lesson.  NEVER dis AT&T in a blog post.  :-)  Within a few hours they somehow managed to knock me off the web.  :-)

Anyhoo…I’ll start posting the question of the day again tomorrow.  I apologize for the backlog of comments, I’ll jump on those ASAP.  Then it’s time to get cracking on multicast.

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.  :-)

 

Next Page »

Blog at WordPress.com.