CCIE Pursuit Blog

June 2, 2009

Core Knowledge Question of the Day: 02 June 2009

An OSPF virtual-link is a link to the backbone area through….

Highlight for answer: a nonbackbone(transit), non-stub area.

June 1, 2009

Core Knowledge Question of the Day: 01 June 2009

When configuring OSPF Fast Hello Packets, does the hello multiplier need to match on the entire segment?

Highlight for answer: Not as long as at least one hello packet is sent within the dead-interval (1 second).

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

April 30, 2008

Question Of The Day: 30 April, 2008

Topic: IOS

You need to add multiple lines of configuration to the following interfaces on sw1:

Fa0/1, Fa0/2, Fa0/3, Fa0/5, Fa0/7, Fa0/8, Fa0/10, Fa0/13, Fa0/14, Fa0/15, Fa0/16, Fa0/17

Can you write a single-line interface range command to apply the changes to all of these interfaces at one time?

Click Here For Answer


Yesterday’s Question

Question Of The Day: 29 April, 2008 

Topic: OSPF

You have the following configuration on r1.

interface Loopback0
 ip address 1.1.1.1 255.0.0.0
!
router ospf 100
 router-id 1.1.1.1
 log-adjacency-changes
 network 1.1.1.1 0.0.0.0 area 0
 network 10.1.12.1 0.0.0.0 area 0

r2 is seeng the loopback address with a /32 mask:

r2#sh ip route ospf
     1.0.0.0/32is subnetted, 1 subnets
O       1.1.1.1 [110/2] via 10.1.12.1, 00:00:13, FastEthernet0/0

Using only a single command, make it so that r2 sees r1’s Loopback 0 with its configured network mask.

Answer: ip ospf network point-to-point

OSPF treats Loopback interfaces as stub networks and will advertise these networks as host routes (/32) regardless of the ‘native’ network mask. 

r1#show ip ospf interface loopback 0
Loopback0 is up, line protocol is up
  Internet Address 1.1.1.1/8, Area 0 
  Process ID 100, Router ID 1.1.1.1, Network Type LOOPBACK, Cost: 1
 Loopback interface is treated as a stub Host

To avoid this behavior you need to change the OSPF network type of the Loopback interface to point-to-point.  Why point-to-point?  Because it’s the only OSPF network type that IOS will accept for a Loopback interface:

r1(config-if)#ip ospf network non-broadcast
OSPF: Invalid type for interface

      
r1(config-if)#ip ospf network broadcast
OSPF: Invalid type for interface

r1(config-if)#ip ospf network point-to-multipoint
OSPF: Invalid type for interface

r1(config-if)#ip ospf network point-to-multipoint non-broadcast
OSPF: Invalid type for interface

After you change the Loopback interface to an OSPF point-to-point network, you will see the route on r2 as a /8.

r1(config)#interface loopback 0          
r1(config-if)#ip ospf network point-to-point

r1(config-if)#do sh ip os int lo0
Loopback0 is up, line protocol is up
  Internet Address 1.1.1.1/8, Area 0
  Process ID 100, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 1
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
  Supports Link-local Signaling (LLS)
  Index 2/2, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 0, maximum is 0
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 0, Adjacent neighbor count is 0
  Suppress hello for 0 neighbor(s)

r2#sh ip route ospf
O    1.0.0.0/8 [110/2] via 10.1.12.1, 00:02:08, FastEthernet0/0

April 25, 2008

Question Of The Day: 25 April, 2008

Topic: EIGRP

r1 and r2 are directly connected via their respective fa0/0 interfaces:

r1:
interface FastEthernet0/0
  ip address 10.1.12.1
  ip hold-time eigrp 100 30
  ip hello-interval eigrp 100 5
!
router eigrp 100
  no auto-summary
  network 10.1.12.1 0.0.0.0

r2:
interface FastEthernet0/0
  ip address 10.1.12.2
  ip hold-time eigrp 100 60
  ip hello-interval eigrp 100 10
!
router eigrp 100
  no auto-summary
  network 10.1.12.2 0.0.0.0

Will r1 and r2 for an EIGRP neighbor relationship over the Ethernet link between them?

Click Here For The Answer


Yesterday’s Question

Question Of The Day: 24 April, 2008 

Topic: Route-Maps

The engineer in charge of r1 is tasked with routing packets to r2 (10.1.1.2) if they meet any of the following conditions:

1) Any packets coming in r1’s fa0/0 interface
2) Any packets with the tag 1234
3) Any D EX routes (r1 is only running EIGRP)

The engineer asks you to peer review his solution:

route-map LOOPBACK_AND_VLAN6 permit 10
 match interface FastEthernet0/0
 match tag 1234
 match route-type external
 set ip next-hop 10.1.1.2

Will this route map meet the requirements?

Answer: No.

In a route-map clause with multiple match statements, ALL match statements must be fullfilled. 

Route-Maps for IP Routing Protocol Redistribution Configuration

A match or set command in each clause can be missed or repeated several times, if one of these conditions exist:

If several match commands are present in a clause, all must succeed for a given route in order for that route to match the clause (in other words, the logical AND algorithm is applied for multiple match commands).

In our case only routes with a next-hop out fa0/0 AND a route tag of of 1234 AND a route-type of external will have their next-hop set to 10.1.1.2.  The task requires that ANY of those conditions must be met.

Steve makes a nice catch:

“Is it wrong because the ‘match interface FastEthernet0/0 line will match packets routed _out_ Fa0/0 not in?”

He’s right.  I boned up the first requirement of the question:

match interface (IP)

“To distribute any routes that have their next hop out one of the interfaces specified, use the match interface command in route-map configuration mode.”

We can write the route-map to meet the requirements by putting each requirement in its own separate clause:

route-map LOOPBACK_AND_VLAN6 permit 10
 match interface FastEthernet0/0
 set ip next-hop 10.1.1.2
!
route-map LOOPBACK_AND_VLAN6 permit 20
 match tag 1234
 set ip next-hop 10.1.1.2
!
route-map LOOPBACK_AND_VLAN6 permit 30
 match route-type external
 set ip next-hop 10.1.1.2
!
route-map LOOPBACK_AND_VLAN6 permit 1000

Each clause of the route-map will be evaluated until a match is made.  The last clause is included to override the implicit deny.  That way any packets that do not meet any of the clauses will be routed normally.

April 24, 2008

Question Of The Day: 24 April, 2008

Topic: Route-Maps

The engineer in charge of r1 is tasked with routing packets to r2 (10.1.1.2) if they meet any of the following conditions:

1) Any packets coming in r1’s fa0/0 interface
2) Any packets with the tag 1234
3) Any D EX routes (r1 is only running EIGRP)

The engineer asks you to peer review his solution:

route-map LOOPBACK_AND_VLAN6 permit 10
 match interface FastEthernet0/0
 match tag 1234
 match route-type external
 set ip next-hop 10.1.1.2

Will this route map meet the requirements?

Click Here For The Answer


Yesterday’s Question

Question Of The Day: 23 April, 2008 

Match the following with their associated OSPF LSA Type:

Inter Area Router Link States
Link (Type-8 ) Link States
Net Link States
Inter Area Prefix Link States
Summary ASB Link States
Type-5 AS External Link States
Router Link States
Type-7 AS External Link States
Intra Area Prefix Link States
Summary Net Link States

Answer:

Router Link States…………………………………LSA Type 1
Net Link States…………………………………….LSA Type 2
Summary Net Link States………………………..LSA Type 3
Inter Area Prefix Link States…………………….LSA Type 3(OSPFv3)
Summary ASB Link States………………………..LSA Type 4
Inter Area Router Link States……………………LSA Type 4(OSPFv3)
Type-5 AS External Link States…………………LSA Type 5
Type-7 AS External Link States…………………LSA Type 7
Link (Type-8 ) Link States……………………….LSA Type 8(OSPFv3)
Intra Area Prefix Link States…………………….LSA Type 9(OSPFv3)

Reference: Table 9-2. OSPFv3 LSA types and their OSPFv2 counterparts – Routing TCP/IP, Volume I, 2nd Edition

April 23, 2008

Question Of The Day: 23 April, 2008

Topic: OSPF

Match the following with their associated OSPF LSA Type:

Inter Area Router Link States
Link (Type 8 ) Link States
Net Link States
Inter Area Prefix Link States
Summary ASB Link States
Type-5 AS External Link States
Router Link States
Type-7 AS External Link States
Intra Area Prefix Link States
Summary Net Link States

Click Here For The Answer


Yesterday’s Question

Question Of The Day: 22 April, 2008 

Topic: OSPF

Which ‘show’ command will give you detailed information about Type-5 LSAs you are receiving?

Answer: ‘show ip ospf database external’

You can use ‘show ip ospf database external’ to see detailed information about Type-5 LSAs in the OSPF database:

r1#show ip ospf database external

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 992
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 33.33.33.33 (External Network Number )
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000001
  Checksum: 0x9976
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 0

April 22, 2008

Question Of The Day: 22 April, 2008

Topic: OSPF

Which ‘show’ command will give you detailed information about Type-5 LSAs you are receiving?

Click Here For The Answer


Yesterday’s Question

Question Of The Day: 21 April, 2008 

Topic: OSPF

Give two methods of introducing a default route into an OSPF NSSA.

Answer: ‘area nssa default-information-originate’ and ‘area nssa no-summary’

An OSPF NSSA (Not-So-Stubby-Area) will remove Type 5 LSAs while allowing redistribution into the area (Type 7 LSAs which are converted to Type 5 LSAs at the ABR).  The NSSA is the only OSPF stub area that does not originate a default route.  There are two methods to introduce a default route into an NSSA (both are configured on the ABR):

1) area 13 nssa default-information-originate
2) area 13 nssa no-summary

In this example, r1 is the ABR.  We’ve made area 13 an NSSA.  Now we want r1 to advertise a default route into the NSSA.

ABR:
r1
(config)#do sh ip os int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa0/0        100   0               10.1.12.1/24       1     DR    1/1
Fa1/0        100   13              10.1.13.1/24       1     BDR   1/1

Stub:
r3(config-if)#do sh ip os int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa0/0        100   13              10.1.13.3/24       1     DR    1/1

r3(config-if)#do sh ip route os
     100.0.0.0/32 is subnetted, 1 subnets
O IA    100.1.4.4 [110/4] via 10.1.13.1, 00:03:14, FastEthernet0/0
     10.0.0.0/24 is subnetted, 4 subnets
O IA    10.1.12.0 [110/2] via 10.1.13.1, 00:03:54, FastEthernet0/0
O IA    10.1.24.0 [110/3] via 10.1.13.1, 00:03:20, FastEthernet0/0
O IA    10.1.34.0 [110/4] via 10.1.13.1, 00:03:01, FastEthernet0/0

r3(config)#do show ip ospf database

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

                Router Link States (Area 13)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         11          0x80000006 0x0044A6 1
3.3.3.3         3.3.3.3         6           0x80000005 0x00C01C 1

                Net Link States (Area 13)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.13.1       1.1.1.1         12          0x80000001 0x00B74F

                Summary Net Link States (Area 13)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.12.0       1.1.1.1         46          0x80000001 0x000813
10.1.24.0       1.1.1.1         46          0x80000001 0x008D80
10.1.34.0       1.1.1.1         46          0x80000001 0x0029D9
100.1.4.4       1.1.1.1         46          0x80000001 0x00B50D

Method 1:
r1(config-router)#area 13 nssa default-information-originate

r3(config-if)#do sh ip route os           
     100.0.0.0/32 is subnetted, 1 subnets
O IA    100.1.4.4 [110/4] via 10.1.13.1, 00:06:06, FastEthernet0/0
     10.0.0.0/24 is subnetted, 4 subnets
O IA    10.1.12.0 [110/2] via 10.1.13.1, 00:06:45, FastEthernet0/0
O IA    10.1.24.0 [110/3] via 10.1.13.1, 00:06:11, FastEthernet0/0
O IA    10.1.34.0 [110/4] via 10.1.13.1, 00:05:52, FastEthernet0/0
O*N2 0.0.0.0/0 [110/1] via 10.1.13.1, 00:01:10, FastEthernet0/0
            
r3(config-if)#do show ip ospf database | b Type-7
                Type-7 AS External Link States (Area 13)

Link ID         ADV Router      Age         Seq#       Checksum Tag
0.0.0.0         1.1.1.1         84          0x80000001 0x002173 0

Note that the default route is advertised in a Type-7 LSA and that the IA routes are not filtered from the routing table.

Method 2:
r1
(config-router)#area 13 nssa no-summary

r3(config)#do sh ip route os
O*IA 0.0.0.0/0 [110/2] via 10.1.13.1, 00:00:46, FastEthernet0/0

r3(config)#do show ip ospf database

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

                Router Link States (Area 13)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         669         0x80000004 0x005C8E 1
3.3.3.3         3.3.3.3         672         0x80000004 0x00D605 1

                Net Link States (Area 13)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.13.3       3.3.3.3         672         0x80000001 0x0047B5

                Summary Net Link States (Area 13)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         1.1.1.1         77          0x80000001 0x001B17

Note that the OSPF IA routes are gone from the routing table.  We can see that the Summary Net Link States (LSA Type 3) are replaced with a default route.

When deciding between which method to use, look for phrase in the task like “introduce a default route but still allow inter-area routes to appear in the routing table” or “the default route should be advertised in a Type 7 LSA”.

Next Page »

Blog at WordPress.com.