Internetwork Expert Volume II: Lab 2 – Section 4

Section 4 - Interior Gateway Routing - 24 Points

This was the longest section and also the one that I had the most problems with (mostly due to route redistribution).  Although I generally had the right idea for most of the sections, I usually messed up just enough to lose points on a lot of them.

The section started out with a fairly easy OSPF task (you’ll need to know what OSPF network types do not elect a DR/BDR).  It also asked:

Adverise the Loopback 0 interfaces of r1 and r2 into OSPF area 0.

Straightforward enough, except that the lo0 interfaces have /24 network masks.  Did I need to advertise them in with the appropriate mask (change the lo0 OSPF network type to Point-To-Point) or just let OSPF advertise them with a /32 mask?  It turns out that I was reading too much into the task, no need to worry about the /24 mask.  I definitely would have been clarifying with the proctor on that task though.

4.2 asks you to:

Authenticate this adjacency (area 17) using the clear-text password CISCO.

I configured OSPF authentication under the appropriate interfaces (r1′s fa0/0 and sw1′s fa0/1).  The answer key showed that I should have configured “area 17 authentication” under the OSPF process.  There is a subtle difference between these techniques (shown below) but I did not feel that the task was written clearly enough to favor one method over the other:

r1:
router ospf 100
 router-id 150.1.1.1
 log-adjacency-changes
 area 17 authentication
 network 132.1.0.1 0.0.0.0 area 0
 network 132.1.17.1 0.0.0.0 area 17
 network 150.1.1.1 0.0.0.0 area 0
!
interface FastEthernet0/0
 ip address 132.1.17.1 255.255.255.0
 ip ospf authentication-key CISCO

sw1:
router ospf 100
 router-id 150.1.7.7
 log-adjacency-changes
 network 132.1.17.7 0.0.0.0 area 17
!
interface FastEthernet0/1
 no switchport
 ip address 132.1.17.7 255.255.255.0
 ip ospf authentication
 ip ospf authentication-key CISCO

***********
r1#sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.7.7         1   FULL/DR         00:00:33    132.1.17.7      FastEthernet0/0

r1#sh ip os nei 150.1.7.7 detail
 Neighbor 150.1.7.7, interface address 132.1.17.7
    In the area 17 via interface FastEthernet0/0
    Neighbor priority is 1, State is FULL, 6 state changes
    DR is 132.1.17.7 BDR is 132.1.17.1
    Options is 0×52
    LLS Options is 0×1 (LR)
    Dead timer due in 00:00:38
    Neighbor is up for 00:02:21
    Index 1/4, retransmission queue length 0, number of retransmission 1
    First 0×0(0)/0×0(0) Next 0×0(0)/0×0(0)
    Last retransmission scan length is 1, maximum is 1
    Last retransmission scan time is 0 msec, maximum is 0 msec

sw1#sh ip os neigh

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.1.1         1   FULL/BDR        00:00:38    132.1.17.1      FastEthernet0/1

sw1#sh ip os neigh 150.1.1.1 detail
 Neighbor 150.1.1.1, interface address 132.1.17.1
    In the area 17 via interface FastEthernet0/1
    Neighbor priority is 1, State is FULL, 6 state changes
    DR is 132.1.17.7 BDR is 132.1.17.1
    Options is 0×52
    LLS Options is 0×1 (LR)
    Dead timer due in 00:00:31
    Neighbor is up for 00:03:33
    Index 1/1, retransmission queue length 0, number of retransmission 0
    First 0×0(0)/0×0(0) Next 0×0(0)/0×0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec

Here’s the important difference:

r1#sh ip os | b Area 17
    Area 17
        Number of interfaces in this area is 1
        Area has simple password authentication
        SPF algorithm last executed 00:04:31.156 ago
        SPF algorithm executed 3 times
        Area ranges are
        Number of LSA 9. Checksum Sum 0x05D4C7
        Number of opaque link LSA 0. Checksum Sum 0×000000
        Number of DCbitless LSA 0
        Number of indication LSA 0
        Number of DoNotAge LSA 0
        Flood list length 0

sw1#sh ip os | b Area 17
    Area 17
        Number of interfaces in this area is 1
        Area has no authentication
        SPF algorithm last executed 00:03:45.385 ago
        SPF algorithm executed 3 times
        Area ranges are
        Number of LSA 9. Checksum Sum 0x05D4C7
        Number of opaque link LSA 0. Checksum Sum 0×000000
        Number of DCbitless LSA 0
        Number of indication LSA 0
        Number of DoNotAge LSA 0
        Flood list length 0

The answer seemed to favor authentication for area 17 rather than authenticating the link itself.  Like I said, I don’t feel that the task pointed towards the area authentication,  but it was a good learning experience to see the difference between the two methods. 

I bit one this task for 4.3:

…configure r3 so tat OSPF hello packets are not sent out these interfaces that connnect to the stub networks.

Argh!!!  I configured areas 3 and 33 as stub areas.  The answer was a whole lot simpler than that: just make those interfaces passive.  I really need to review the differences in what passive-interface accomplishes in each routing protocol.

I also messed up(?) on this task:

Configure OSPF area 255 on VLAN 255. 

The answer key shows that you just need to put r4′s fa0/1 interface into OSPF area 255.  I configured OSPF on sw3 and sw4 as well and added the VLAN255 interfaces to area 255.  I’m still not sure why you don’t need to do that.

4.5 was a straight forward EIGRP configuration.  I used Ethan Bank’s suggestion and did this in notepad and then dropped it on the routers since most of the configuration was similar.

I did run into an interesting issue once I configured r6 to be an EIGRP neigbor with BB1:

*Mar  1 06:39:28.850: IP-EIGRP(Default-IP-Routing-Table:10): Neighbor 54.1.10.254 not on common subnet for Serial0/0
*Mar  1 06:39:41.094: IP-EIGRP(Default-IP-Routing-Table:10): Neighbor 54.1.3.254 not on common subnet for Serial0/0
*Mar  1 06:39:52.170: IP-EIGRP(Default-IP-Routing-Table:10): Neighbor 54.1.10.254 not on common subnet for Serial0/0
*Mar  1 06:40:03.718: IP-EIGRP(Default-IP-Routing-Table:10): Neighbor 54.1.3.254 not on common subnet for Serial0/0
*Mar  1 06:40:15.310: IP-EIGRP(Default-IP-Routing-Table:10): Neighbor 54.1.10.254 not on common subnet for Serial0/0
*Mar  1 06:40:26.218: IP-EIGRP(Default-IP-Routing-Table:10): Neighbor 54.1.3.254 not on common subnet for Serial0/0
*Mar  1 06:40:38.906: IP-EIGRP(Default-IP-Routing-Table:10): Neighbor 54.1.10.254 not on common subnet for Serial0/0

The router log was filling up with these messages.  This was due to BB1 having a bunch of possible EIGRP networks to peer with.  I found a workaround in the IE forums:

Using “no eigrp log-neighbor-warnings” suppresses these messages.

4.6 was an easy EIGRP summary-address task.  Just remember that these are done at the interface level:

Configuring Summary Aggregate Addresses

4.7 was the last EIGRP task and it asked you to advertise some VLANs without using the network statement.  This meant writing a couple of easy route-maps and then using them to filter the connected routes redistributed into EIGRP.  This also meant me noting these routes because they could come back to bite me in the butt during redistibution.

My background isn’t very point-to-point heavy.  At my last job, our backup circuits were mostly ISDN and at my current job we usually only have DSL/Cable backups for our smallest sites (the rest have dual carrier BGP connections).  Task 4.8 asked for a PPP link to come up only when the Frame link went down and to configure delay for each event (Frame dropping and reestablishing).  I started down a rabbit hole by assuming that this was some fancy function of a dialer-watch tied to a serial line.  The solution was much simpler than that:

Configuring Dial Backup for Serial Lines
Dial Backup Service When the Primary Line Goes Down Example

r5(config-subif)#backup ?
  active     Configure an interface as an active backup
  delay      Delays before backup line up or down transitions
  interface  Configure an interface as a backup

interface Serial0/0.1 point-to-point
 backup delay 60 300
 backup interface Serial0/1
 ip address 132.1.35.5 255.255.255.0
 frame-relay interface-dlci 513

r5#sh ip int br | i Serial
Serial0/0                  unassigned      YES TFTP   up                    up
Serial0/0.1                132.1.35.5      YES manual up                    up
Serial0/1                  132.1.45.5      YES manual standby mode          down

“show backup” is a great verification command in this situation:

With Frame connection up:

r5#sh backup
Primary Interface   Secondary Interface   Status
—————–   ——————-   ——
Serial0/0.1         Serial0/1             normal operation

With Frame connection up (for over 60 seconds):

r5#sh ip int br | i Serial
Serial0/0                  unassigned      YES unset  administratively down down
Serial0/0.1                132.1.35.5      YES manual administratively down down
Serial0/1                  132.1.45.5      YES manual up                    up

r5#sh backup
Primary Interface   Secondary Interface   Status
—————–   ——————-   ——
Serial0/0.1         Serial0/1             backup mode

With Frame connection reestablished (but less than 300 seconds):

r5#sh ip int br | i Serial
Serial0/0                  unassigned      YES unset  up                    up
Serial0/0.1                132.1.35.5      YES manual up                    up
Serial0/1                  132.1.45.5      YES manual up                    up

r5#sh backup
Primary Interface   Secondary Interface   Status
—————–   ——————-   ——
Serial0/0.1         Serial0/1             waiting to revert (296 more seconds)

And finally, with Frame connection reestablished for more than 300 seconds:

r5#sh ip int br | i Serial
Serial0/0                  unassigned      YES unset  up                    up
Serial0/0.1                132.1.35.5      YES manual up                    up
Serial0/1                  132.1.45.5      YES manual standby mode          down

r5#sh backup
Primary Interface   Secondary Interface   Status
—————–   ——————-   ——
Serial0/0.1         Serial0/1             normal operation

Some words of advice about this task from Brian Dennis :

“Do not get caught up in semantics over 60 vs 61 seconds…ask the proctor.”
“This affects your full reachability test as you would need to do this with the primary up and the primary down.” 
“If you are short on time, just note the routes on r5 before dropping the primary and compare it.”

The next task was an easy RIP implementation.  Then came the doozy:

Configure sw1 so that it does not accept routes with an even second octet from BB3
The access-list used to accomplish this should not contain more than one line.
Do not user the distribute-list or distance keyworks to accomplish this.

Oh poop!  I couldn’t really skip this one as it would affect what routes would be seen in my IGP.  The only thing that I was sure of was that I would need to use an offset-list per the third task.  I remembered that IE had an article on their site about funky filtering:

CCIE Lab Preparation Resources
Computing Access-List and Wildcard Pairs

Here are the routes from bb3:

sw1#sh ip route rip | i 204.12.1.254
R       31.3.0.0 [120/1] via 204.12.1.254, 00:00:10, Vlan783
R       31.2.0.0 [120/1] via 204.12.1.254, 00:00:10, Vlan783
R       31.1.0.0 [120/1] via 204.12.1.254, 00:00:10, Vlan783
R       31.0.0.0 [120/1] via 204.12.1.254, 00:00:10, Vlan783
R       30.2.0.0 [120/1] via 204.12.1.254, 00:00:10, Vlan783
R       30.3.0.0 [120/1] via 204.12.1.254, 00:00:10, Vlan783
R       30.0.0.0 [120/1] via 204.12.1.254, 00:00:10, Vlan783
R       30.1.0.0 [120/1] via 204.12.1.254, 00:00:10, Vlan783

The first task states “….does not accept route with an EVEN SECOND OCTET from bb3″
so we need to filter out:

30.0.0.0
30.2.0.0
31.0.0.0
31.2.0.0

with a one line ACL!!!

ARGH!

Here’s the algorithm we need to use:

1) write out the binary for the route you want to filter
2) do a logical AND – that’s your subnet
3) do a logical OR – that’s your subnet mask

30.0.0.0  00011110.00000000
30.2.0.0  00011110.00000010
31.0.0.0  00011111.00000000
31.2.0.0  00011111.00000010
_____________________________________________
   00011110.00000000   Logical AND (all 1s = 1 else 0)
   Decimal 30.0.0.0

30.0.0.0  00011110.00000000
30.2.0.0  00011110.00000010
31.0.0.0  00011111.00000000
31.2.0.0  00011111.00000010
_____________________________________________
   00000001.00000010   Logical OR (1 and 0 = 1 else 0)
   Decimal 1.2.0.0

sw1#sh run | i access-list 99
access-list 99 permit 30.0.0.0 1.2.0.0
sw1#sh run | b router rip
router rip
 version 2
 offset-list 99 in 16
 network 150.1.0.0
 network 204.12.1.0
 no auto-summary

sw1#clear ip route *
sw1#sh ip route rip
     31.0.0.0/16 is subnetted, 2 subnets
R       31.3.0.0 [120/1] via 204.12.1.254, 00:00:06, Vlan783
R       31.1.0.0 [120/1] via 204.12.1.254, 00:00:06, Vlan783
     30.0.0.0/16 is subnetted, 2 subnets
R       30.3.0.0 [120/1] via 204.12.1.254, 00:00:06, Vlan783
R       30.1.0.0 [120/1] via 204.12.1.254, 00:00:06, Vlan783

I AM THE GREATEST!!!!

Okay…after all of my triumphant celebration…I find that IE went a different route:

ip access-list standard EVEN_SECOND_OCTET
 permit 0.0.0.0 255.254.255.255
!
router rip
 offset-list EVEN_SECOND_OCTET in 16 VLAN783

The “secret” to filtering even or odd routes is “The least significant bit of a binary number determines whether the number is even or odd.  If the least significant bit is not set, then the number must be even.  If the least significant bit is set, then the number must be odd.” 

If I’m reading this correctly, their access list allows ALL routes (not just those that start with 30 and 31) with an even second octet to be filtered.  They also specified VLAN783 in the solution, which is a more correct solution than mine (mine filters all RIP routes and not just those from bb3).

router rip
 version 2
 offset-list EVEN in 16 Vlan783
 network 150.1.0.0
 network 204.12.1.0
 no auto-summary
!
ip access-list standard EVEN
 permit 0.0.0.0 255.254.255.255

sw1#sh ip route rip
     132.1.0.0/16 is variably subnetted, 9 subnets, 2 masks
R       132.1.8.0/24 [120/1] via 204.12.1.8, 00:00:17, Vlan783
     31.0.0.0/16 is subnetted, 2 subnets
R       31.3.0.0 [120/1] via 204.12.1.254, 00:00:17, Vlan783
R       31.1.0.0 [120/1] via 204.12.1.254, 00:00:17, Vlan783
     150.1.0.0/16 is variably subnetted, 4 subnets, 2 masks
R       150.1.8.0/24 [120/1] via 204.12.1.8, 00:00:17, Vlan783
     30.0.0.0/16 is subnetted, 2 subnets
R       30.3.0.0 [120/1] via 204.12.1.254, 00:00:17, Vlan783
R       30.1.0.0 [120/1] via 204.12.1.254, 00:00:17, Vlan783

Ummmm….looking back on my solution…the exclusion of vlan783 was a HUGE mistake!!!  I filtered out the 132.1.0.0/16 and 150.1.0.0/16 networks!!!

Next came the route redistribution task.  I completely flubbed this one which was a real slap in the face after I spent so much time studying route redistribution the week before.  I don’t have a lot to say about this task because it would be too complicated to try to reproduce it in this posting and have it make any sense.  I will agree with a poster at the IE forums that IE should put a breakdown in their answer guide detailing the how and why of their answer.  I will post some general route redistribution best practices though:

“We only have to worry when we have multiple points of mutual redistribute between the same routing protocols.”

“The problem is always between the higher AD protocol being redistributed into the lower AD protocol and being lower AD protocol being redistributed back into the higher AD protocol again.”

In general I feel okay about my results in this section.  I still need to work on route redistribution (a lot!).  The only task that really threw me was the filtering of odd second-octet routes.  I did make enough small mistakes that would have cost me significant points in the real lab.