CCIE Pursuit Blog

February 20, 2008

Network World’s 20 Useful Sites for Cisco Networking Professionals

You may want to read this with your eyes closed as I am going to indulge in a little self-congratulatory revelry.  I was surprised and delighted to see the following comment today:

Hi CCIE Pursuit, I couldn’t find a contact address for you so I am posting my message here. I wanted to let you know that your site is one of Network World’s 20 useful sites for Cisco networking professionals http://www.networkworld.com/community/node/25115.

Nice job!

Linda Leung, Network World Assistant Site Editor.

I was pretty excited to see my blog make the list (I’m on page 18).  That is,  until I found out that CCIE Journey had made the cut as well.  The bar must be set very low for him to make it in.  :-)   Just messing around.  Mad love to CCIE Journey.

I can always count on my better half to deflate any small victories I might achieve:

“Check it out.  My blog made a top 20 list in Network World”
“Great.  Can you translate that from Nerd to English?”
“No, I can’t dumb it down for you.”
“Well, I just made a list of 20 useful things you can do around the house.”

Everyday she kills another little piece of me.  :-)

Anyhoo…check out the list.  Any list that doesn’t include CCIE Candidate is incomplete, but I think that they did a good job.  I strongly encourage you to check out the sites that they list.  I was acquainted with most of the site, but the article did expose me to a couple of interesting sites that I had not seen before:

Networking Forum

TechWise TV

Internetwork Expert Volume II: Lab 12 – Section 4

Section 4 – Interior Gateway Routing – 8 Points

“Note: Do not redistribute between IGPs”

Sweet!!!!  Well, at least I thought so at first.  This short IGP section with no redistribution only meant that I was about to get my teeth kicked in on the BGP section.  :-)

4.1  OSPF

“To minimize WAN utilization OSPF traffic should only be sent over the Frame Relay segment during initial adjacency establishment and when changes occur in the OSPF topology.”

Huh?  Does OSPF traffic include hellos?  If it doesn’t, then we’re good by default…except for the 30 minute paranoid update.  :-(

If they include hellos, then we need to configure the the point-to-point FR connection as a demand circuit.

ip ospf demand-circuit

“ip ospf demand-circuit” only needs to be configured on one side of the link.

r4(config-if)#int s0/0.54
r4(config-subif)#ip os demand

r4#sh ip os int s0/0.54
Serial0/0.54 is up, line protocol is up
  Internet Address 129.1.54.4/24, Area 0
  Process ID 100, Router ID 150.1.4.4, Network Type POINT_TO_POINT, Cost: 65
  Configured as demand circuit.
  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:01
  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 2
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 150.1.5.5  (Hello suppressed)
  Suppress hello for 1 neighbor(s)

4.2 OSPF

Interesting task:

Configure sw4 to match exactly the output below and nothing more:

sw4#sh ip os data | i Net Link States \(Area 34\)
                Net Link States (Area 34)

Currently I show:

sw4#sh ip os data | i Net Link States \(Area 34\)
                Net Link States (Area 34)
                Summary Net Link States (Area 34)

So I need to get rid of Summary Net Link States (LSA 3).  How to do this?

Stub networks?  No:

OSPF Stubs:

Type Keyword LSAs Default Injected?
stub area x stub 1,2,3,4 Yes
totally stubby area x stub no-summary 1,2,default of 3 Yes
not-so-stubby area x nssa 1,2,3,4,7 NO
not-so-totally-stubby area x nssa no-summary 1,2,default of 3,7 Yes

The answer was easy — change the OSPF network type on po34 from Broadcast to Point-to-Point:

sw4#sh ip os int po34 | i Type
  Process ID 100, Router ID 150.1.10.10, Network Type BROADCAST, Cost: 1

sw4(config)#int po34
sw4(config-if)#ip os net point-to-point

sw3(config-if)#int po34
sw3(config-if)#ip os net point-to-point
sw4
#sh ip os data | i Net Link States \(Area 34\)
                Summary Net Link States (Area 34)

Task 4.2

4.3 EIGRP

This was a pretty basic EIGRP configuration with one exception.  r1, r2, and r4 form a Frame Relay hub-and-spoke network.  r1 and r2 (spokes) are running EIGRP, but EIGRP is not enabled on r4 (hub).  Consequently, r1 and r2 are not peering though the Frame Relay cloud.

r2#sh ip ei int
IP-EIGRP interfaces for process 200

                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Lo0                0        0/0         0       0/1            0           0
Se0/0/0           0        0/0         0       0/1            0           0
Se0/1/0            1        0/0         4       0/15          50           0

r2#sh ip ei nei
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   129.1.23.3              Se0/1/0           13 00:09:18    4   200  0  11

Can I disable EIGRP split-horizon on r4 even though it’s not running EIGRP?

r4(config)#int Serial0/0.124
r4(config-subif)#no ip split-horizon eigrp ?
  <1-65535>  Autonomous system number

r4(config-subif)#no ip split-horizon eigrp 200

It takes the command, but that’s not the fix:

r2#clear ip ei neighbors
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   129.1.23.3              Se0/1/0           12 00:00:02    2   200  0  18

Okay….next try a neighbor command:

neighbor (EIGRP)

r2(config)#router ei 200
r2(config-router)#neigh 129.1.124.1 Serial0/0/0

r1(config)#router ei 200
r1(config-router)#neigh 129.1.124.2 s0/0

Sweet, sweet IOS music:

*Mar  1 21:17:56.758: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 200: Neighbor 129.1.124.2 (Serial0/0) is up: new adjacency

r2#sh ip ei nei
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   129.1.124.1           Se0/0/0          140 00:00:39   14   200  0  18
0   129.1.23.3              Se0/1/0           12 00:03:24    1   200  0  18

Alas, all of this effort was for naught.  I didn’t read the task close enough.  Instead I configured EIGRP based on the IGP diagram.  That diagram shows the spokes’ Frame Relay interfaces in the EIGRP domain, BUT the task does not require that you configure them.  :-(

This posting discusses an anomaly in the solution guide (two EIGRP routes on sw1 showing as D EX in the solution guide):

Task 4.3

Blog at WordPress.com.