CCIE Pursuit Blog

December 2, 2007

Internetwork Expert Volume II: Lab 2 – Section 7

Section 7 – IPv6 – 2 Points

This was a very easy section that took me WAY too long to complete.  I made a couple of really stupid fat-finger mistakes (covered in this LFU).  Part of the problem is that I still have a hard time reading IPv6 addresses.  Otherwise, this was a very straight-forward task that I completed successfully, even though I wasted a lot of time on stupid mistakes.

Internetwork Expert Volume II: Lab 2 – Section 6

Section 6 – IP Multicast – 6 Points

Multicast is my absolute worst technology.  I had very little hope of getting any of these tasks correct because I really haven’t done a lot of multicast study.  This section turned out to be a pleasant surprise as the first two tasks were very easy. 

6.1 asks you to configure a number of interfaces in pim sparse-mode.  The task is  very straight-forward.  You are then asked to:

Configure r2’s most reliable interface as the RP for all multicast groups.

The most reliable interface must be lo0.  Two things to keep in mind: 1) if you make an interface the RP, you’d better configure it for multicast (pim sparse-mode in this case) even if the task does not explicitly list it (as it did not in this case), and 2) you need to configure the RP address on each device (“ip pim rp-address x.x.x.x”).

6.2 just requires you to use “ip igmp join-group”.

6.3 completely bewildered me.  The task described what would seem to be a complicated issue but it was resolved with “ip pim nbma-mode”.  Oh well, I’m pretty happy with getting the first two sections correct.

Internetwork Expert Volume II: Lab 2 – Section 5

Section 5 – Exterior Gateway Routing – 11 Points

This section started out with a very straight-forward BGP configuration.  I once again followed Ethan Bank’s suggestion to use notepad and it really helped to cut time and errors.  I did end up losing points for 5.1 though because I did not configure r4 as a route-reflector.  Although this was not  specified in the task, the answer key stated that “it is implied that r4 is performing route-reflection for these devices.”  I agree that r4 sure looks like it would be a great choice for being a route-reflector, but I’m at a loss as to why I should be configuring capabilities based on implication; especially since IE’s mantra is “if they don’t specifically request it in the lab,  then don’t do it.”

There was also a phantom peering from sw1 to bb3 in the answer key that was not specified in the task (most likely it was for the 5.3).

5.2 was a simple BGP authentication task.

5.3 was another task that I managed to pull out of my butt by simply guessing the correct BGP technology to configure.  Basically you want to peer a router in AS 54 to your router in AS 400, BUT you need to make your router in AS 400 look like it’s in AS 100 (because that’s what the router in AS 54 is configured to peer with).  You need to use the “local-as” option to accomplish this:

neighbor local-as

sw1(config-router)#neigh 204.12.1.254 remote-as 54
sw1(config-router)#neigh 204.12.1.254 local-as 100 no-prepend

Here’s a good summary of that command:

The LOCAL-AS is used to present to your neighbor a different AS than your own and the no-prepend will remove completely your own BGP AS [from the AS Path].

So if you have

R1
router bgp 100
nei 2.2.2.2 remot 200

R2
router bgp 200
nei 1.1.1.1 remot 600 <– here you see that R2 is trying to peer with you on AS 600 although R1 is in AS100

So you can

R1
router bgp 100
nei 2.2.2.2 remot 200
nei 2.2.2.2 local-as 600

If you inject a network R2 will see the route as if it came from:

*>1.1.10.10   100 600

but if you add the

 nei 2.2.2.2 local-as 600 no-prepand then you will see:

*>1.1.10.10   600

I hope it was clear enough.

5.4 was an easy BGP filtering issue.  No problems there.  You’ll need to be familiar with “ip as-path access-list” command to accomplish this:

ip as-path access-list

This section ended with a pretty straight-forward BGP route summarization.  The only strange thing was that the answer key showed that I should have advertised r5’s fa0/0 interface into BGP?  That was not stated in the task, but I think that you needed to do that int order to introduce a 132.1.1.0/24 route.  This was another “implied” answer.

Before advertising 132.1.5.5 into BGP:

r5#sh ip bgp neigh 192.10.1.254 advertised-routes | i 0.0.0.0
r5#

After advertising 132.1.5.5 into BGP:

r5(config-router)#net 132.1.5.0 mask 255.255.255.0

r5#clear ip bgp * soft
r5#sh ip bgp neigh 192.10.1.254 advertised-routes | i 0.0.0.0
*> 132.1.0.0        0.0.0.0                            32768 i

That concluded the core section of the lab.  Overall, I felt like I did pretty well for a first shot at a practice lab.  I am obviously light-years away from being ready for the real thing.

If you’ve done the Volume I labs and absorbed at least a little of the IEATC lectures, then most of the technologies and some of the verbiage should be familiar.  I hit a few features that I was unaware of, but I also managed to steal a few points by guessing right and using the DOC.

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 0x52
    LLS Options is 0x1 (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 0x0(0)/0x0(0) Next 0x0(0)/0x0(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 0x52
    LLS Options is 0x1 (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 0x0(0)/0x0(0) Next 0x0(0)/0x0(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 0x000000
        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 0x000000
        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-warningssuppresses 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.

The Rubric Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 112 other followers