CCIE Pursuit Blog

March 23, 2009

Core Knowledge Question of the Day: 23 March 2009

By default, OSPF floods new LSAa over all interfaces in the same area except…..

Highlight for answer: the interface that the LSA arrives on.

March 18, 2009

Core Knowledge Question of the Day: 18 March 2009

Which OSPF feature allows a router to continue to forward packets while undergoing specific, well-known failure conditions?

Highlight for answer: OSPF Graceful Restart

March 16, 2009

Core Knowledge Question of the Day: 16 March 2009

Which Cisco OSPF feature allows you to detect lost neighbors within one second even when neighbor loss might not be detected the the OSI physical and data-link layers?

Highlight for answer: OSPF Fast Hello Packets

March 13, 2009

Core Knowledge Question of the Day: 13 March 2009

Okay, for reallz this time.¬† ūüôā

Which OSPF network type is ideal for partially meshed NBMA networks because it is easy to configure(requires no configuration of neighbor commands), consumes only one IP subnet, and requires no designated router election?

Highlight for answer: Point-to-multipoint

March 10, 2009

Open Ended Question of the Day: 10 March 2009

An OSPF internal router has what distinguishing feature?

Highlight for answer: All OSPF interfaces belong to the same OSPF area.

December 8, 2008

Question Of The Day: 08 December, 2008

***Update 09 December***

Assume that OSPF was configured on the router after any changes were made to the interfaces on R1.

Given the following information:

R1#sh ip int br | e ass
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            155.1.146.1     YES NVRAM  up                    up
Serial0/1                  155.1.13.1      YES NVRAM  up                    up
Loopback0                  150.1.1.1       YES NVRAM  administratively down down

R1#sh run | sec router ospf
router ospf 100
log-adjacency-changes
network 155.1.13.1 0.0.0.0 area 0

November 17, 2008

Cool Command 3: show ip ospf database database-summary

‘show ip ospf database’ is one of those commands that every CCIE candidate needs to know how to use as it can show you a ton of very good OSPF information.¬† There are a ton of options for this command:

r2#show ip ospf database ?
  adv-router        Advertising Router link states
  asbr-summary      ASBR summary link states
  database-summary  Summary of database
  external          External link states
  network           Network link states
  nssa-external     NSSA External link states
  opaque-area       Opaque Area link states
  opaque-as         Opaque AS link states
  opaque-link       Opaque Link-Local link states
  router            Router link states
  self-originate    Self-originated link states
  summary           Network summary link states
  |                 Output modifiers
  <cr>

I can’t believe that I’ve gotten this far and never used the “database-summary” option for this command.¬†

database-summary
 (Optional) Displays how many of each type of LSA for each area there are in the database, and the total.

Here’s the output of the command for an OSPF process with area 0 and three non-zero areas (note the difference in the LSA types in Area 0 versus the non-zero areas):

r1#show ip ospf database database-summary

            OSPF Router with ID (1.1.1.1) (Process ID 100)

Area 0 database summary
  LSA Type      Count    Delete   Maxage
  Router        2        0        0      
  Network       1        0        0      
  Summary Net   6        0        0      
  Summary ASBR  0        0        0      
  Type-7 Ext    0        0        0      
    Prefixes redistributed in Type-7  0
  Opaque Link   0        0        0      
  Opaque Area   0        0        0      
  Subtotal      9        0        0      

Area 100 database summary
  LSA Type      Count    Delete   Maxage
  Router        1        0        0      
  Network       0        0        0      
  Summary Net   8        0        0      
  Summary ASBR  0        0        0      
  Type-7 Ext    0        0        0      
    Prefixes redistributed in Type-7  0
  Opaque Link   0        0        0      
  Opaque Area   0        0        0      
  Subtotal      9        0        0      

Area 101 database summary
  LSA Type      Count    Delete   Maxage
  Router        1        0        0      
  Network       0        0        0      
  Summary Net   8        0        0      
  Summary ASBR  0        0        0      
  Type-7 Ext    0        0        0      
    Prefixes redistributed in Type-7  0
  Opaque Link   0        0        0      
  Opaque Area   0        0        0      
  Subtotal      9        0        0      

Area 102 database summary
  LSA Type      Count    Delete   Maxage
  Router        1        0        0      
  Network       0        0        0      
  Summary Net   8        0        0      
  Summary ASBR  0        0        0      
  Type-7 Ext    0        0        0      
    Prefixes redistributed in Type-7  0
  Opaque Link   0        0        0      
  Opaque Area   0        0        0      
  Subtotal      9        0        0      

Process 100 database summary
  LSA Type      Count    Delete   Maxage
  Router        5        0        0      
  Network       1        0        0      
  Summary Net   30       0        0      
  Summary ASBR  0        0        0      
  Type-7 Ext    0        0        0      
  Opaque Link   0        0        0      
  Opaque Area   0        0        0      
  Type-5 Ext    0        0        0      
      Prefixes redistributed in Type-5  0
  Opaque AS     0        0        0      
  Total         36       0        0

As you can see this command shows a count of each type of LSA for each OSPF area (per process if you’re running multiple processes).¬† You can limit the output to a specific area (or¬†process)¬†with a grep command:

Show just the database-summary for area 0:

r2#show ip ospf database database-summary | sec Area 0
Area 0 database summary
  LSA Type      Count    Delete   Maxage
  Router        2        0        0      
  Network       1        0        0      
  Summary Net   6        0        0      
  Summary ASBR  0        0        0      
  Type-7 Ext    0        0        0      
    Prefixes redistributed in Type-7  0
  Opaque Link   0        0        0      
  Opaque Area   0        0        0      
  Subtotal      9        0        0 

Show just the database-summary for Process 100:

r2#show ip ospf database database-summary | sec Process 100
Process 100 database summary
  LSA Type      Count    Delete   Maxage
  Router        5        0        0      
  Network       1        0        0      
  Summary Net   30       0        0      
  Summary ASBR  0        0        0      
  Type-7 Ext    0        0        0      
  Opaque Link   0        0        0      
  Opaque Area   0        0        0      
  Type-5 Ext    0        0        0      
      Prefixes redistributed in Type-5  0
  Opaque AS     0        0        0      
  Total         36       0        0

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

August 16, 2008

Internetwork Expert Volume II: Lab 8 – Section 3

Section 3 – Interior Gateway Routing – 16 Points

3.1 OSPF

Simple OSPF task.¬† The only odd bit is that you’ll be configuring OSPF over the PPPoFR network.¬† It makes sense that the OSPF network type is point-to-point.¬† ūüôā

r3(config-router)#do sh ip os int | i proto|Type
Multilink1
is up, line protocol is up
  Process ID 100, Router ID 150.1.3.3, Network Type POINT_TO_POINT, Cost: 1

r2#sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.3.3¬†¬†¬†¬†¬†¬†¬†¬† 0¬†¬† FULL/¬† –¬†¬†¬†¬†¬†¬†¬† 00:00:38¬†¬†¬† 174.1.23.3¬†¬†¬†¬†¬† Multilink1

“Authenticate the OSPF adjacency between r2 and r6 using OSPF type 1 authentication.”

Crap.¬† I think that type 1 is just clear-text (type 0 = null and type 7 = md5).¬† It’s weird that the task does not mention a password.¬† I used the old standby of “CISCO”

r6(config-router)#int FastEthernet0/1.26
r6(config-subif)#ip ospf authentication
r6(config-subif)#ip ospf authentication-key CISCO

r2(config-subif)#do sh ip os int Gi0/0.26 | i proto|authe
GigabitEthernet0/0.26 is up, line protocol is up
  Simple password authentication enabled 

3.2 OSPF

Configure area 38 so that “external LSAs” are not advertised in.

We know that we’re done to stub or totally stubby at this point.

“Ensure that devices in OSPF area 38 still have specific forwarding information about prefixes originated in other OSPF areas.”

So we need to allow IA routes (LSA 3).  That sounds like a stub area to me.

3.3 OSPF

Create area 67 and then summarize 150.1.6.6 and 150.1.7.7 with no overlapping address space:

7 0000011|1
6 0000011|0

150.1.6.0/23 or 150.1.6.0 255.255.254.0

Summary will move from area to area so use…..area range.¬† ūüôā

r6(config)#router os 100
r6(config-router)#area 67 range 150.1.6.0 255.255.254.0

r3#sh ip route 150.1.6.6
Routing entry for 150.1.6.0/23
¬† Known via “ospf 100”, distance 110, metric 3, type inter area
  Last update from 174.1.23.2 on Multilink1, 00:00:36 ago
  Routing Descriptor Blocks:
  * 174.1.23.2, from 150.1.6.6, 00:00:36 ago, via Multilink1
      Route metric is 3, traffic share count is 1

r3#sh ip route 150.1.7.7
Routing entry for 150.1.6.0/23

¬† Known via “ospf 100”, distance 110, metric 3, type inter area
  Last update from 174.1.23.2 on Multilink1, 00:00:50 ago
  Routing Descriptor Blocks:
  * 174.1.23.2, from 150.1.6.6, 00:00:50 ago, via Multilink1
      Route metric is 3, traffic share count is 1

3.4 EIGRP

Basic EIGRP task.  The only confusing bit is that the task asks you to advertise the lo0 interface of all of the EIGRP devices into EIGRP.  r3 is already advertising its lo0 interface into OSPF.  They must have meant all of the EIGRP devices except r3 (the solution guide bears this out).

Remember to disable split-horizon on the Frame Relay hub (r1):

r1(config-router)#int s0/0
r1(config-if)#no ip split-horizon eigrp 1024

3.5 RIP

Easy RIP task with authentication.

3.6 IGP Redistribution

Redistribute between RIP and EIGRP on r5 and then between OSPF and EIGRP where needed.

Remember that OSPF area 38 is a stub area so it’s not going to let in any external routes.¬† That means our OSPF<->EIGRP redistribution needs to happen on r3.

I ran into one issue.  I had a route to 174.1.31.0/24 on r1 (connected) as well as r2-3(OSPF).  But r4 and r5 did not have the route.

The problem is that r3 gets that route via OSPF and then advertises it to r1.  R1 does not install the route from r3 because it has that network as connected.  The route does not get passed on to the EIGRP routers behind r1.

I need to either redistribute that connected interface into EIGRP on r1 or find some way to have r1 prefer the route to r3 over the connected route.

r1(config)#route-map CONN->EIGRP
r1(config-route-map)#match int Fa0/0.13

r1(config-route-map)#router ei 1024
r1(config-router)#redist conn met 1 1 1 1 1 route-map CONN->EIGRP

r4#sh ip route 174.1.31.1
Routing entry for 174.1.31.0/24

¬† Known via “eigrp 1024”, distance 170, metric 2560512256, type external
  Redistributing via eigrp 1024
  Last update from 174.1.145.1 on Serial0/0, 00:00:30 ago
  Routing Descriptor Blocks:
  * 174.1.145.1, from 174.1.145.1, 00:00:30 ago, via Serial0/0
      Route metric is 2560512256, traffic share count is 1
      Total delay is 20010 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 1

r4#trace 174.1.31.1

Type escape sequence to abort.
Tracing the route to 174.1.31.1

  1 174.1.145.1 4 msec *  4 msec

I ended up with full reachability by only redistributing RIP<->EIGRP on r5, OSPF<->EIGRP on r3, and Connected (fa0/0.13) -> EIGRP on r1.

IE went a different route.  Then redistributed OSPF->EIGRP on r1, OSPF<->EIGRP on r3, as well as RIP<->EIGRP on r5.

3.7 Load Distribution

Configure the network so that traffic from r4 to r5 is distributed in a 4:1 ratio between the Ethernet connection and the Frame Relay connection.

I messed with this for tooooooooo long.¬† I tried messing with the metric weight and I was still mindfucked.¬† I’ll just eat the 3 points and move on.

Update:

I have to try this tomorrow:

Becoming a CCIE: EIGRP Unequal path load balancing

July 28, 2008

The Value Of Redoing Labs

I completed IE’s Volume II lab 3 for the second time yesterday.¬† I’ve started redoing all of the labs in order (I hope to make it through all 20 before my lab date).¬† As I’ve stated before, I was surprised that I don’t memorize labs.¬† It looks like I last did this lab back in December (where has the time gone?) so it shouldn’t be too big of a surprise.

This was a difficulty level 6 lab, so it was pretty straight forward.¬† I did hit a couple of snags, but I was able to get through them because I finally have my head around some of the technologies.¬† As Brian Dennis says, “You never stop making mistakes, you just get better at spotting them.”¬†

The first time through this lab I was nowhere near as strong in BGP and multicast (I’m still not “lab ready” in either technology, but I’m way better than I was).¬† In this lab there were two AS 100.¬† I was having a heck of a time because I could not get the backbone prefixes advertised into one AS 100 to propagate to the other AS 100 (there was a transit AS between them).¬† So I stepped back and thought about it.¬† I could see the prefixes in the peer’s BGP table and I could see that they were being advertised (‘show ip bgp neighbor x.x.x.x adv’) from the peer but not received by my router (“show ip bgp neighbor x.x.x.x route’).¬† My router was installing 3 other prefixes that were originated from a different backbone router. WTF?¬† So I started mentally running through the reasons why my router would not accept those routes.¬† What was it that was different about those 3 prefixes that were installed and the 10 that were not being installed.¬† Voila!¬† Those 10 prefixes were being advertised to the other AS 100 then to the transit AS and then dropping when hitting this AS 100.¬† DOH!¬† A BGP router will not install prefixes that already contain its own AS number.¬† That was the problem.¬† Now I could concentrate on solving this issue rather than wasting time on troubleshooting.

Now you’re probably thinking “big deal” and/or “how does this guy expect to pass the lab?”, but my point is that I was able to solve this issue by knowing the technology.¬† I’m pretty sure that the first time through this lab I did not even notice this issue (you eventually filter those routes, so it becomes a non-issue) nor would I have successfully found the reason.¬† Doing a lab for a second (or third…or forth…) time can help catch problems that you did not see the first time through.

I hit another snag when I got to multicast.¬† Try as I might I could not get one of my routers to recognize the RP.¬† The interface was configured correctly and I was seeing the PIM neighbor.¬† By doing a simple traceroute I was able to see that traffic was routing over a PTP link instead of the Frame Relay link.¬† But I took care of that earlier in the lab by setting the OSPF cost to a high value, right?.¬† Unfortunately, after that task I set the OSPF auto-cost so that all of the other links now had a higher cost.¬† My PTP link was now preferred over my Frame Relay link.¬† I had used a high cost value (6000) but it was not high enough¬†once the other costs were adjusted¬† ūüė¶¬†¬†Again, I was able to (relatively) quickly find the issue and I understood how and why it was happening (as well as how to fix it).¬† My multicast configuration was correct.¬† The first time through I most likely did not catch this issue because I probably did not verify everything with the degree of anal-retentiveness that I do now.¬† I could have easily overlooked this issue if I did not verify the RP mapping on that router.¬† The problem would not show up in my ping scripts.¬† I would have lost points for at least two sections.

Anyhoo…my point is that you should definitely do labs more than once, especially if it’s been a while since you last did the lab.

« Previous PageNext Page »

Create a free website or blog at WordPress.com.