CCIE Pursuit Blog

September 23, 2008

Status Update: 9 Days Left – Going Dark

My iGooglepage has a countdown widget on it and it tells me that I’m down to single digits.  Yesterday was my last day in the office (might have to pop in on the weekend) and the remainder of my week is dedicated to labbing.  I’ve booked a ton of lab time this week and a couple of mock labs.  I’ll be spending over 50 hours on the CLI this week.  This weekend I may try to wire up my work lab to work on the CCIE Routing and Switching Practice Labs.  At the very least I’m going to read through them.

I’m a whole lot more relaxed now than I was a couple of weeks ago.  I am working on my many and varied weaknesses.  I’ve accepted that I’m not going to go into the lab as an expert on all of the technologies, but I do have a good grasp of the core stuff and some of the none-core stuff.  There are some technologies that still give me trouble if the task goes too deep, but hopefully I’ll be able to use the DOCCD to get those points.

I fly out Monday and will be spending the first two nights in San Francisco.  Those will be interesting days as I will be doing the tourist thing with my wife.  This will either be a much needed respite before the lab or it will be a complete disaster as I will piss my wife off because I’ll be too obsessed with the lab to enjoy the city.

The good thing about San Francisco is that you can walk between a lot of the attractions.  I’m planning on doing as much walking as possible so that I will be physically tired and (hopefully) more likely to sleep the night before the lab.  Even as I type this I know that I’ll probably be too nervous to get much sleep. 

Anyhoo…this will be my last blog update until after the lab.  My next post will either be my digits or my three month plan for my second attempt.

September 22, 2008

I iz brane ded

Filed under: Cisco,Cisco Certification — cciepursuit @ 11:58 am
Tags: , ,

I was reading the documentation on reflexive ACLs (trying to shore up my security weaknesses) and ran across this:

This example shows Enhanced IGRP permitted on the interface.

HUH?  What the hell is that?

DOH!  EIGRP.  I don’t think that I’ve seen it written like that in a LONG time.  I also misread it as “Enhanced IGMP” at first.

I really need to be done with studying.  :-)

September 21, 2008

IOS error(?) with OSPF point-to-multipoint network in PPPoFR Hub-and-Spoke Topology

How nerdy is that for a blog post title?   :-)

I’ve run up against this issue twice now.  The issue seems to be an order-of-operations issue in IOS with PPPoFR in a hub-and-spoke network running OSPF network type point-to-multipoint.  This is most likely something that you’ll (hopefully) never see in a real network.  If you do, then kick the router (and the architect) really hard and run away quickly.

In this case we’ve configured PPPoFR with R5 as the hub and R1 and R2 as the spokes.  On R5 we have two PPP circuits assigned – one assigned to each hub DLCI – to a single virtual-template.  Something like this:

r5:
int s0/0.1 multipoint <- just to make it more “interesting”   :-)
 frame-relay interface-dlci 501 ppp virtual-template 1
 frame-relay interface-dlci 502 ppp virtual-template 1

Everything was cool until I configured OSPF and noticed that I wasn’t seeing routes from r2:

RSRack12R5#sh ip route os
     128.8.0.0/16 is variably subnetted, 9 subnets, 2 masks
O IA    128.8.136.0/24 [110/2] via 128.8.125.1, 00:39:59, Virtual-Access2
O IA    128.8.63.0/24 [110/11113] via 128.8.125.1, 00:22:43, Virtual-Access2

Looking at the individual routes it looks like the router is sending traffic to r2 which should be going to r1:

RSRack12R5#sh ip route 128.8.136.0
Routing entry for 128.8.136.0/24
  Known via “ospf 100″, distance 110, metric 2, type inter area
  Last update from 128.8.125.1 on Virtual-Access2, 00:40:10 ago
  Routing Descriptor Blocks:
  * 128.8.125.1, from 150.8.1.1, 00:40:10 ago, via Virtual-Access2
      Route metric is 2, traffic share count is 1

RSRack12R5#sh ip route 128.8.125.1
Routing entry for 128.8.125.1/32
  Known via “connected”, distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Virtual-Access1
      Route metric is 0, traffic share count is 1

RSRack12R5#sh int virtual-access 2
Virtual-Access2 is up, line protocol is up
  Hardware is Virtual Access interface
  Internet address is 128.8.125.5/24
  MTU 1500 bytes, BW 100000 Kbit, DLY 100000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Open
  Open: IPCP
  PPPoFR vaccess, cloned from Virtual-Template1
  Vaccess status 0x44
  Bound to Serial0/0.1 DLCI 502, Cloned from Virtual-Template1, loopback not set <-502 is r2
  Keepalive set (10 sec)
  DTR is pulsed for 5 seconds on reset
  Last input 00:00:12, output never, output hang never
  Last clearing of “show interface” counters 02:09:09
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     7938 packets input, 609028 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     7949 packets output, 604952 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

RSRack12R5#p 128.8.136.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 128.8.136.3, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

RSRack12R5#trace 128.8.136.3

Type escape sequence to abort.
Tracing the route to 128.8.136.3

  1 128.8.125.228 msec 28 msec 32 msec  <-should go to r1
  2  *

An IP packet debug on r5 shows that the IOS does see any problems with shipping the wrong packets to r2:

Sep  4 07:38:04.065: IP: tableid=0, s=128.8.125.5 (local), d=128.8.136.3 (Virtual-Access2), routed via FIB
Sep  4 07:38:04.069: IP: s=128.8.125.5 (local), d=128.8.136.3 (Virtual-Access2), len 100, sending
Sep  4 07:38:04.069:     ICMP type=8, code=0

It looks like the virtual-access interfaces are associated with the wrong DLCIs.  I tried a reload – no change.

I ripped out PPPoFr and readded it:

RSRack12R5#sh ip int br | i Virtu
Virtual-Access1            128.8.125.5     YES TFTP   up                    up

Virtual-Template1          128.8.125.5     YES NVRAM  down                  down

Virtual-Access2            128.8.125.5     YES TFTP   up                    up

Virtual-Access3            unassigned      YES unset  down                  down

RSRack12R5#sh int virtual-acc 1 | i Bound
  Bound to Serial0/0.1 DLCI 501, Cloned from Virtual-Template1, loopback not set
RSRack12R5#sh int virtual-acc 2 | i Bound
  Bound to Serial0/0.1 DLCI 502, Cloned from Virtual-Template1, loopback not set
RSRack12R5#sh int virtual-acc 3 | i Bound
RSRack12R5#

RSRack12R5#sh ip route 128.8.136.3
Routing entry for 128.8.136.0/24
  Known via “ospf 100″, distance 110, metric 2, type inter area
  Last update from 128.8.125.1 on Virtual-Access2, 00:02:18 ago
  Routing Descriptor Blocks:
  * 128.8.125.1, from 150.8.1.1, 00:02:18 ago, via Virtual-Access2  <- should use virtual-access1
      Route metric is 2, traffic share count is 1

Same issue:

RSRack12R5#trace 128.8.136.3

Type escape sequence to abort.
Tracing the route to 128.8.136.3

  1 128.8.125.228 msec 28 msec 32 msec  <-should go to r1
  2  *  *

The IOS is up to date:

RSRack12R5#sh ver | i IOS|emo
Cisco IOS Software, C2600 Software (C2600-ADVENTERPRISEK9-M), Version 12.4(10), RELEASE SOFTWARE (fc1)
Cisco 2611XM (MPC860P) processor (revision 3.1) with 127308K/3764K bytes of memory.

I gave up.  I did go back and check my config line by line and everything was in agreement with the IE solution guide.  I looked in my notes and I did not encounter this issue on my last attempt at this lab.  If this were the actual lab I guess that I would rip out the PPPoFR configuration and just use a conventional hub-and-spoke FR network and eat the PPPoFR points.

It appears that I’m not the only person to run up against this issue:

It looks like the fixes are:

1) Reorder the frame-relay maps:

I did that, but IOS puts them back in order:

interface Serial0/0.1 multipoint
 frame-relay interface-dlci 501 ppp Virtual-Template1
 frame-relay interface-dlci 502 ppp Virtual-Template1

But for some reason it fixed the issue:

RSRack12R5#p 128.8.136.3

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

RSRack12R5#trace 128.8.136.3

Type escape sequence to abort.
Tracing the route to 128.8.136.3

  1 128.8.125.1 28 msec 32 msec 29 msec
  2 128.8.136.3 32 msec *  40 msec

This fix does my fucking head in.  I actually stripped out the PPPoFR configuration before and then readded it.  The actual ORDER of configuration is important?  Even though IOS reorders the configuration lines automatically?

Unfortunately this “fix” does not survive a reload:

After reload:
RSRack12R5#p  128.8.136.3

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

Success rate is 0 percent (0/3)

RSRack12R5#trace  128.8.136.3

Type escape sequence to abort.
Tracing the route to 128.8.136.3

  1 128.8.125.228 msec 32 msec 28 msec
  2
RSRack12R5#

2) Create a separate virtual-template for each DLCI (I think that this is what I did the first time that I ran through this lab).

interface Serial0/0.1 multipoint
frame-relay interface-dlci 501ppp Virtual-Template1
frame-relay interface-dlci 502ppp Virtual-Template2

interface Virtual-Template1
ip address 128.1.125.5 255.255.255.0
ip ospf network point-to-multipoint
!
interface Virtual-Template2
ip address 128.1.125.5 255.255.255.0
ip ospf network point-to-multipoint

RSRack12R5#sh ip os neigh

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.8.2.2         0   FULL/  –        00:01:59    128.8.125.2     Virtual-Access2
150.8.1.1
         0   FULL/  –        00:01:59    128.8.125.1     Virtual-Access1

Did not work:

RSRack12R5#p  128.8.136.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 128.8.136.3, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

RSRack12R5#trace  128.8.136.3

Type escape sequence to abort.
Tracing the route to 128.8.136.3

  1 128.8.125.228 msec 32 msec 33 msec
  2
RSRack12R5#

But if I switch the virtual-template assignment (as suggested in the forum)……still more failure:

interface Serial0/0.1 multipoint
 frame-relay interface-dlci 501ppp Virtual-Template2
 frame-relay interface-dlci 502ppp Virtual-Template1

RSRack12R5#p 128.8.136.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 128.8.136.3, timeout is 2 seconds:
..
Success rate is 0 percent (0/2)

RSRack12R5#trace 128.8.136.3

Type escape sequence to abort.
Tracing the route to 128.8.136.3

  1 128.8.125.229 msec 28 msec 32 msec
  2

Brian Dennis stated that the proctors do not reload your routers before grading, so I guess that I have to count on that being the case if I run across this issue in the lab.

I ran across the same issue on an IPexpert lab (mock lab 3).  I was only getting routes from one spoke in a PPPoFR PPP multilink point-to-multipoint OSPF network…with a fucking virtual link thrown in just to increase the nerdtastic design.  I had to flip the multilink assignment of (many!) frame-relay interfaces and that got is cooking once again:

interface Serial0/1/0
 no ip address
 encapsulation frame-relay
 frame-relay interface-dlci 205 ppp Virtual-Template2
 frame-relay interface-dlci 206 ppp Virtual-Template1
 frame-relay interface-dlci 215 ppp Virtual-Template2
 frame-relay interface-dlci 216 ppp Virtual-Template1
 frame-relay interface-dlci 225 ppp Virtual-Template2
 frame-relay interface-dlci 226 ppp Virtual-Template1

no frame-relay interface-dlci 205 ppp Virtual-Template2
no frame-relay interface-dlci 206 ppp Virtual-Template1
no frame-relay interface-dlci 215 ppp Virtual-Template2
no frame-relay interface-dlci 216 ppp Virtual-Template1
no frame-relay interface-dlci 225 ppp Virtual-Template2
no frame-relay interface-dlci 226 ppp Virtual-Template1

frame-relay traffic-shaping
frame-relay interface-dlci 205 ppp Virtual-Template1
frame-relay interface-dlci 206 ppp Virtual-Template2
frame-relay interface-dlci 215 ppp Virtual-Template1
frame-relay interface-dlci 216 ppp Virtual-Template2
frame-relay interface-dlci 225 ppp Virtual-Template1
frame-relay interface-dlci 226 ppp Virtual-Template2

September 20, 2008

IPexpert: $999 Blended Learning Solution Special Ends Monday

If you were putting off purchasing IPexpert’s Blended Learning Solution at $999 then you only have a few more days to procrastinate (via Twitter).

Last chance to get the CCIE Blended Learning Solution (R&S, Voice, Security) for only $999. There is no better value! Promotion ends Monday. about 17 hours ago from web

After Monday the price will double.

September 19, 2008

Barooq is CCIE #22087

Filed under: Cisco,Cisco Certification — cciepursuit @ 8:04 am
Tags: , , ,

Barooq of Chronicles of CCIE journey and CCIE Candidate passed his Routing and Switching lab yesterday on his first attempt.  He’s still drinking in the moment but there is a post up where you can leave him some love.

Congratulations Barooq!

—Update—

He now has a post up detailing his lab experience.

September 18, 2008

I’m NOT Gonna Be Your RP Sucker!

Filed under: Cisco,Cisco Certification,IOS — cciepursuit @ 11:16 am
Tags: , , , ,

The IOS has finally grown sick of me and rebelled (albeit in a very polite way):

Sep 17 15:48:36.829: %PIM-1-INVALID_RP_REG: Received Register from router 176.21.35.5 for group 239.3.1.1, 150.21.3.3 not willing to be RP.

I tried bribing it, bullying it, and complimenting it…but it was still not willing to be my RP.  :-(

September 17, 2008

EIGRP Offset-Lists and Show IP Protocols

Filed under: Cisco,Cisco Certification,EIGRP,IOS — cciepursuit @ 8:12 am
Tags: , , , , ,

It’s funny how you may have done a task many times and not noticed an IOS feature.  I applied an offset-list to some EIGRP routes and stumbled across some output I had never noticed before (to be fair I usually use offset-lists with RIP and not EIGRP):

No EIGRP offset-list(s) applied:

Rack17SW1#sh ip proto
*** IP Routing is NSF aware ***

Routing Protocol is “eigrp 10″
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 10
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    0.0.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    156.17.27.2           90      00:24:46
    156.17.67.6           90      00:24:46
  Distance: internal 90 external 170

With the offset-lists applied (different paths based on whether the 3rd octet is even or odd):

router eigrp 10
 timers active-time 5
 offset-list ODD in 666666666 Vlan18
 offset-list EVEN in 666666666 Vlan58

 network 0.0.0.0
 no auto-summary
!
ip access-list standard EVEN
 permit 0.0.0.0 255.255.254.255
ip access-list standard ODD
 permit 0.0.1.0 255.255.254.255

Notice the difference?  :-)

Rack17SW2#sh ip proto
*** IP Routing is NSF aware ***

Routing Protocol is “eigrp 10″
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Incoming routes in Vlan18 will have 666666666 added to metric if on list ODD
  Incoming routes in Vlan58 will have 666666666 added to metric if on list EVEN

  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 10
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    0.0.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    156.17.18.1           90      00:17:55
    156.17.58.5           90      00:17:55
  Distance: internal 90 external 170

September 15, 2008

OT: Business Buzzwords

Filed under: OT: Humor — cciepursuit @ 6:32 pm
Tags:

I absolutely hate business jargon.  I’m talking about stuff like “We need to socialize our mission to leverage synergies across the enterprise and quantize parter results from which we can workshop outside-the-box solutions.”  Whenever I hear shit like that I do two things: 1) stop listening, and 2) mentally flag this person as a clueless jackass.  I learned early on not to ask “what the hell is a synergy?” because you’ll lose the next fifteen minutes of your life listening to another business jargon filled fluff statement or you’ll get a suggestion to read some craptacular business tome.  Either way, you will never get a straight answer – most likely because the jackass braying this garbage doesn’t really know what it means either.

Here’s a conversation I recently had with my manager:

“Why are we doing this?”
“We are doing this to reduce the unefficatism of the processization…”
“That’s not a word.”
“What’s not a word?”
“‘Unefficatism.’  ‘Unefficatism’ is not a word.”
“Yes it is.”
“Show me the definition of ‘unefficatism’.”
“I don’t have a dictionary.”
“You have a desktop, a laptop, and a phone that all have an Internet connection.  Can’t you leverage that toolbox to socialize the definition to me?”
“It IS a word!”
“Google says that it isn’t and is asking if you mean ‘unificationism’.  Do you mean ‘unificationism’?  If so, I am not comfortable discussing religion with you.”
“Irregardless of whether you think…”
“That’s not a word either.”

That’s not to say that those of us on the techical side of the fence don’t use a lot of jargon – not to mention abreviations and acronyms.  I like to think that we try to do this to convey precise meaning and not to try to ‘impress’ others with our vocabulary.  When a biologist says something like “Evolution is any change in the frequency of alleles within a gene pool from one generation to the next” it’s not because they want to impress you with their vocabulary, it’s because those words have a very specific meaning.  If I’m talking to a networking collegue I might drop something like “EIGRP isn’t installing the route as a Feasable Successor” but I would convert that to “the router is not using both paths” when talking to someone who is not expected to know networking. 

Anyhoo…for more business jargon horror stories check out this link.

Resume leveraging your personal bandwidth to increment your mental database of vendor specific solutions.  :-)

Disabling EIGRP Unequal-Cost Load-Balancing

Filed under: Cisco,Cisco Certification,EIGRP,IOS — cciepursuit @ 6:53 am
Tags: , , , , ,

This may be old news to you guys but I had never seen the “traffic-share min across-interfaces” command before.  I was messing about with EIGRP unequal cost load-sharing the other day and came across it.

r1(config-router)#traffic-share ?
  balanced  Share inversely proportional to metric
  min       All traffic shared among min metric paths <-what’s this?

r1(config-router)#traffic-share min ?
  across-interfaces  Use different interfaces for equal-cost paths
r1(config-router)#traffic-share min across-interfaces

Weird.  It turns off unequal-cost load balancing by not allowing traffic over the Feasable Successor route(s) regardless of the variance command:

r1(config-router)#var 4
*Mar  2 00:05:02.000: %FIB-4-UNEQUAL: Range of unequal path weightings too large for prefix 150.1.6.0/24. Some available paths may not be used.

r1(config-router)#do sh ip route 164.1.26.0 255.255.255.0
Routing entry for 164.1.26.0/24
  Known via “eigrp 100″, distance 90, metric 3026432, type internal
  Redistributing via eigrp 100
  Last update from 164.1.12.2 on Serial0/0, 00:00:03 ago
  Routing Descriptor Blocks:
  * 164.1.13.3, from 164.1.13.3, 00:00:03 ago, via Serial0/1
      Route metric is 3026432, traffic share count is 1
      Total delay is 40100 microseconds, minimum bandwidth is 1280 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2
    164.1.12.2, from 164.1.12.2, 00:00:03 ago, via Serial0/0
      Route metric is 10514432, traffic share count is 0
      Total delay is 20100 microseconds, minimum bandwidth is 256 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

r1(config-router)#var 40
r1(config-router)#do sh ip route 164.1.26.0 255.255.255.0
Routing entry for 164.1.26.0/24
  Known via “eigrp 100″, distance 90, metric 3026432, type internal
  Redistributing via eigrp 100
  Last update from 164.1.12.2 on Serial0/0, 00:00:02 ago
  Routing Descriptor Blocks:
  * 164.1.13.3, from 164.1.13.3, 00:00:02 ago, via Serial0/1
      Route metric is 3026432, traffic share count is 1
      Total delay is 40100 microseconds, minimum bandwidth is 1280 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2
    164.1.12.2, from 164.1.12.2, 00:00:02 ago, via Serial0/0
      Route metric is 10514432, traffic share count is 0
      Total delay is 20100 microseconds, minimum bandwidth is 256 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

Here’s the explanation:

Similarly, when you use the traffic-share command with the keyword min, the traffic is sent only across the minimum-cost path, even when there are multiple paths in the routing table.

router eigrp 1
 network x.x.x.x
 variance 3
 traffic-share min across-interfaces

In this situation, EIGRP sends packets only through E-C-A, which is the best path to the destination network. This is identical to the forwarding behavior without use of the variance command. However, if you use the traffic-share min command and the variance command, even though traffic is sent over the minimum-cost path only, all feasible routes get installed into the routing table, which decreases convergence times. 

It turns out that this command is available for all routing protocols.

r1(config)#router os 100
r1(config-router)#traffic-share min ?
  across-interfaces  Use different interfaces for equal-cost paths
r1(config)#router rip
r1(config-router)#traffic-share min ?
  across-interfaces  Use different interfaces for equal-cost paths

September 14, 2008

Internetwork Expert: IE Turns Five

Internetwork Expert recently celebrated its five-year anniversary:

To our valued customers, we thank you for your contribution to the success of Internetwork Expert. Your loyalty, trust, suggestions, and your commitment to our company have brought us successfully to our fifth anniversary. Internetwork Expert was founded with the goal of changing CCIE training for the better and your continued support quickly helped us achieve that objective. Our dedication to leading experience, integrity, and positive results have been an integral factor in our success. By adhering to these standards, we are proud to have become the leader in the CCIE training industry.

As we move forward, we promise to continue our dedication to you, the customer. We gladly welcome your feedback, your continued support and desire to learn. To everyone who has brought us this far, we thank you for your past commitment and are truly excited to return the favor and bring you along as we revolutionize Cisco training once more… Stay tuned…

Next Page »

The Rubric Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 114 other followers