CCIE Pursuit Blog

January 1, 2008

Internetwork Expert Volume III: Lab 3 – Section 5

5 Exterior Gateway Routing

5.1 BGP Peerings

This task started out looking very straight-forward, then took an ugly turn.  :-(

“All devices running BGP should have reachability to all BGP learned prefixes.”
“Don’t use tunnelling to accomplish this.”

This seemed really simple.  I set up my peerings and all of the BGP learned routes were valid best routes.

I had problems with the routes learned from the backbone routers:

r3#p 113.0.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 113.0.0.1, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
r3#trace 113.0.0.1

Type escape sequence to abort.
Tracing the route to 113.0.0.1

  1 190.1.135.532 msec 32 msec 28 msec
  2 190.1.135.5 !H  *  !H

I didn’t read enough into this question as “all devices running BGP” means ALL devices not just my devices.  Since the backbones are running BGP, I need to ensure that they have full reachability as well.

I threw in the towel here.  I reallyneed to review BGP.  Luckily, the answer guide has a breakdown for this task (the only breakdown in the guide).  It had a lot of good information, but I am still lacking in my BGP skills.

5.2 BGP Summarization

You are asked to summarize 112.0.0.0/8 – 119.0.0.0/8 into a single advertisement without overlapping any other networks.

This is a case where you can quickly whip this up by utilizing the Windows Calculator in scientific mode. [You are allowed to use the Windows calculator in the CCIE lab.]

1) Open the Microsoft calculator (you can search for it in Programs or just type ‘calc’ in Start->Run).
2) Click ‘View’.  Make sure that that calculator is in ‘scientific’ mode.
3) Dec (decimal) should be selected.  Key in 112.
4) Now select Bin (binary).  You should get 1110000
5) Switch back to Dec and do the same for 119.  You should get 1110111

You want to summarize at the point where the bits no longer match

112  – 01110|000
119  - 01110|111

So your summarization will be 112.0.0.0/5 or 112.0.0.0 with a mask of 248.0.0.0.  Now it’s just a simple matter of using “aggregate-address” to advertise the summary:

aggregate-address  

router bgp 100
 aggregate-address 112.0.0.0 248.0.0.0

The IE answer key introduced me to a cool new verification command:

show ip bgp cidr-only

r6#sh ip bgp cidr-only
BGP table version is 30, local router ID is 150.11.6.6
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   54.11.1.254                            0 54 i
*> 28.119.17.0/24   54.11.1.254                            0 54 i
*> 112.0.0.0/5      0.0.0.0                            32768 i
s> 190.11.0.0/24    0.0.0.0                  0         32768 i

Internetwork Expert Volume III: Lab 3 – Section 4 Part 2

4 Interior Gateway Routing

4.13 IGP Redistribution

The dreaded IGP redistribution task.  In this lab task 4.13 explicitly tells you where and how to perform redistribution.  Task 4.14 then asks you to prevent loops:

“Do not allow the RIP routes redistributed into OSPF on r4 to be passed back into RIP on r5.”
“Use route tagging to accomplish this.”

I have the following points of redistribution:

r3: RIP 120      -> OSPF 110
    OSPF 110     -> RIP 120

r4: RIP 120      -> OSPF 110

r5: RIP 120      -> EIGRP 90
    OSPF 110     -> RIP 120
    OSPF 110     -> EIGRP 90
    EIGRP 90/170 -> OSPF 110

r5 looks ugly.  I’ll do that one last.

r3 has mutual redistribution, but this should not be a problem because it’s on the same router.  There are no routes currently being redistributed on these routers so I shouldn’t break anything.  When I redistribute RIP into OSPF, this will introduce the BB2 routes into OSPF.  I am also using IE’s recommended tagging structure (router + protocol AD):

r3(config)#router os 100
r3(config-router)#redist rip sub tag 3120

I can see the BB2 routes on r1 now:

r1#sh ip ospf data external adv-router 150.1.3.3 | i Link State|Mask|Tag
                Type-5 AS External Link States
  Link State ID: 190.1.3.0 (External Network Number )
  Network Mask: /24
        External Route Tag: 3120
  Link State ID: 192.10.1.0 (External Network Number )
  Network Mask: /24
        External Route Tag: 3120
  Link State ID: 205.90.31.0 (External Network Number )
  Network Mask: /24
        External Route Tag: 3120
  Link State ID: 220.20.3.0 (External Network Number )
  Network Mask: /24
        External Route Tag: 3120
  Link State ID: 222.22.2.0 (External Network Number )
  Network Mask: /24
        External Route Tag: 3120

I can safely redistribute the OSPF routes into RIP on r3.  The only concern is the BB2 routes reflecting back into RIP with a better AD (110 versus 120).  But the router will not install these routes.  [Basically because the RIP route would be replaced by OSPF route which would mean that the RIP route would not have been redistributed in the first place - "The Single Router Redistribution Paradox"  :-) ]

Before redistribution:
r3#sh ip route | i 220.20.3.0
R    220.20.3.0/24 [120/7] via 192.10.1.254, 00:00:14, FastEthernet0/0 <-bb2 route

r3(config)#route-map OSPF->RIP_SET_TAG permit 10
r3(config-route-map)#set tag 3110
r3(config-router)#redist ospf 100 route-map OSPF->RIP_SET_TAG metric 2

After redistribution, the route is unchanged (as I expected):
r3#sh ip route | i 220.20.3.0
R    220.20.3.0/24 [120/7] via 192.10.1.254, 00:00:14, FastEthernet0/0

On to r4.  We have to redistribute RIP (120) into OSPF (110).  This should not be an issue as it is one-way redistribution (it may become an issue later when we redistribute OSPF into RIP on r5).  This will put the bb3 routes into OSPF.  BUT we do have a possible issue because we are currently redistributing Loop0 into OSPF via connected with a route-map:

route-map LOOP0->OSPF permit 10
 match interface Loopback0
!
router ospf 100
 router-id 150.1.4.4
 log-adjacency-changes
 redistribute connected subnets tag 41 route-map LOOP0->OSPF
 network 190.1.34.4 0.0.0.0 area 34

So we know that redistribution uses a two step algorithm:

1) Take all of the RIP routes in the routing table and advertise them in OSPF.
2) Take all connected interfaces running RIP and advertise them into OSPF (implicit route-map)

In this case we will break the second step with our LOOP0->OSPF map.  We need to include the interfaces running RIP in that route-map.

  Default version control: send version 2, receive version 2
    Interface                    Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       2     2
    FastEthernet0/1       2     2
    Serial0/1                      2     2

So I need to add interfaces fa0/0, fa0/1, and s0/1 to my route-map.

The IE answer key is a little puzzling at first glance.  They show the following for r4:

router ospf 1
 redistribute rip subnets
!
route-map CONNECTED->OSPF permit 20
!
router rip
 redistribute ospf 1 metric 1  <-WTF???

The route-map CONNECTED->OSPF is what they used for task 4.7 (to get Lo0 into OSPF) so basically they are now adding a “permit all” line at the end of that route-map, so that we are redistributing ALL connected interfaces into OSPF.  Here is what they are effectively doing:

route-map CONNECTED->OSPF permit 10
 match interface loopback0
route-map CONNECTED->OSPF permit 20
!
router ospf 1
 redistribute rip subnets
 redistribute connected subnets route-map CONNECTED->OSPF

That makes sense.  I don’t know why they are redistributing the OSPF routes into RIP though?  The task requires one-way redistribution only.  Here’s my solution (I removed the old route-map and “redistribute connected” configurations):

route-map CONNECTED->OSPF permit 10
 description TASK 4.8 Lo0 into OSPF
 match interface Loopback0
 set tag 41
route-map CONNECTED->OSPF permit 20
 description TASK 4.13 RIP->OSPF redist connected
 match interface FastEthernet0/0 FastEthernet0/1 Serial0/1
 set tag 4120
!
router ospf 100
 router-id 150.1.4.4
 log-adjacency-changes
 redistribute connected subnets route-map CONNECTED->OSPF
 redistribute rip subnets tag 4120
 network 190.1.34.4 0.0.0.0 area 34

Here are the redistributed RIP routes on r1:

r1#sh ip os data | i Tag|4120
Link ID         ADV Router      Age         Seq#       Checksum Tag
10.4.4.0        150.1.4.4       653         0×80000001 0×004482 4120
10.5.5.5        150.1.4.4       653         0×80000001 0x00FAC4 4120
30.0.0.0        150.1.4.4       112         0×80000001 0x009B1F 4120
30.1.0.0        150.1.4.4       112         0×80000001 0x008F2A 4120
30.2.0.0        150.1.4.4       112         0×80000001 0×008335 4120
30.3.0.0        150.1.4.4       112         0×80000001 0×007740 4120
31.0.0.0        150.1.4.4       112         0×80000001 0x008E2B 4120
31.1.0.0        150.1.4.4       112         0×80000001 0×008236 4120
31.2.0.0        150.1.4.4       112         0×80000001 0×007641 4120
31.3.0.0        150.1.4.4       112         0×80000001 0x006A4C 4120
190.1.4.0       150.1.4.4       653         0×80000001 0x003BD9 4120
204.12.1.0      150.1.4.4       653         0×80000002 0x001FDE 4120

This accomplishes the same thing, but with the benefit of unique tags on the routes.

Okay…no more putting it off…on to r5:

r5: RIP 120      -> EIGRP 90
    OSPF 110     -> RIP 120
    OSPF 110     -> EIGRP 90
    EIGRP 90/170 -> OSPF 110

So…mutual redistribution between OSPF and EIGRP as well as one-way redistribution between OSPF and RIP as well as RIP and EIGRP.  Did I already say “yuck”? :-)

“lower to higher = good”  so OSPF into RIP should be fine.  Let’s start with that one.

Current RIP configuration:
router rip
 version 2
 no validate-update-source
 passive-interface default
 no passive-interface Serial0/1
 network 10.0.0.0
 network 150.1.0.0
 no auto-summary

Before we do this, we need to look at what’s happening with the BB3 routes.  They are being advertised from BB3 to r4 via RIP.  R4 then advertises them to r5 via RIP.

We have redistributed the RIP routes into OSPF on r4 so now they routes flow from BB3 to r4 via RIP.  They then get redistributed into OSPF.  r5 sees the routes from r4 via RIP and from r3 via OSPF.  Since OSPF has the lower AD, the OSPF routes are installed:

Before redistribution on r4:

r5#sh ip route 30.0.0.0
Routing entry for 30.0.0.0/16, 4 known subnets
  Redistributing via rip, ospf 100

R       30.2.0.0 [120/15] via 10.4.4.4, 00:00:00
R       30.3.0.0 [120/15] via 10.4.4.4, 00:00:00
R       30.0.0.0 [120/15] via 10.4.4.4, 00:00:00
R       30.1.0.0 [120/15] via 10.4.4.4, 00:00:00

After redistributing RIP->OSPF on r4:

r5#sh ip route 30.0.0.0
Routing entry for 30.0.0.0/16, 4 known subnets
  Redistributing via rip, ospf 100

O E2    30.2.0.0 [110/20] via 190.1.135.3, 00:00:33, Serial0/0.1
O E2    30.3.0.0 [110/20] via 190.1.135.3, 00:00:33, Serial0/0.1
O E2    30.0.0.0 [110/20] via 190.1.135.3, 00:00:33, Serial0/0.1
O E2    30.1.0.0 [110/20] via 190.1.135.3, 00:00:33, Serial0/0.1

So if we redistribute OSPF into RIP on r5 are we introducing a routing loop for the bb3 routes?  I don’t think so.  We’re really not doing much at all.  r4 and r5 both know all of the OSPF routes because they are running OSPF already.  Even the RIP routes learned from bb2 via r3 are already known by r5 and r3 via OSPF (RIP was redistributed into OSPF on r3 already).  I can’t see any problems with this redistribution.

route-map OSPF->RIP permit 10
 description Tag OSPF routes with 5110
 set tag 5110
!
router rip
 version 2
 no validate-update-source
 redistribute ospf 100 metric 2 route-map OSPF->RIP
 passive-interface default
 no passive-interface Serial0/1
 network 10.0.0.0
 network 150.1.0.0
 no auto-summary

Alright.  Let’s do the other one-way redistribution on r5: RIP 120 into EIGRP 90.

At first this looks like an issue because we’re going from a higher AD protocol (RIP 120) to a lower AD protocol (EIGRP 90), but we need to remember that EIGRP will give external routes an AD of 170 so we don’t need to worry about these routes coming back into RIP.

One other thing…there are no RIP routes in the r5 routing table  :-)

r5#sh ip route rip

r5#

So the only thing that we will be redistributing into EIGRP are the interfaces running RIP (only int s0/1):

Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    Serial0/1             2     2

route-map RIP->EIGRP permit 10
 description Tag RIP routes with 5120
 set tag 5120
!
router eigrp 10
 redistribute rip metric 1 1 1 1 1 route-map RIP->EIGRP

Before redistribution:

r2#sh ip route ei | sec D EX
r2#

After redistribution:

r2#sh ip route ei | sec D EX
D EX    10.5.5.0/24
           [170/2560002816] via 190.1.0.5, 00:04:24, GigabitEthernet0/0
D EX    10.4.4.4/32
           [170/2560002816] via 190.1.0.5, 00:04:24, GigabitEthernet0/0
     150.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
D EX    150.1.5.0/24
           [170/2560002816] via 190.1.0.5, 00:04:24, GigabitEthernet0/0

We can’t ping 10.4.4.4 though:

r2#p 10.4.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.4.4.4, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

That’s because there is no path back on r4:

r4#sh ip route 190.1.0.2
% Subnet not in table

Finally…the mutual redistribution on r5:

    OSPF 110     -> EIGRP 90
    EIGRP 90/170 -> OSPF 110

We should be covered here too because the OSPF routes redistributed into EIGRP will appear as D EX routes with an AD of 170.

I would filter any D EX routes from being redistributed back into OSPF

Before mutual redistribution:

r1#sh ip route | i E2
       E1 – OSPF external type 1, E2 – OSPF external type 2
O E2 222.22.2.0/24 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2 204.12.1.0/24 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2 220.20.3.0/24 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    190.1.4.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    190.1.3.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    10.4.4.0/24 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    10.5.5.5/32 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2 192.10.1.0/24 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    31.3.0.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    31.2.0.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    31.1.0.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    31.0.0.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    150.1.5.0 [110/20] via 190.1.135.5, 00:56:24, Serial0/0.1
O E2    150.1.4.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2 205.90.31.0/24 [110/20] via 190.1.135.3, 00:56:25, Serial0/0.1
O E2    30.2.0.0 [110/20] via 190.1.135.3, 00:56:25, Serial0/0.1
O E2    30.3.0.0 [110/20] via 190.1.135.3, 00:56:25, Serial0/0.1
O E2    30.0.0.0 [110/20] via 190.1.135.3, 00:56:25, Serial0/0.1
O E2    30.1.0.0 [110/20] via 190.1.135.3, 00:56:25, Serial0/0.1

r2#sh ip route | sec D EX
D EX    10.5.5.0/24
           [170/2560002816] via 190.1.0.5, 00:18:48, GigabitEthernet0/0
D EX    10.4.4.4/32
           [170/2560002816] via 190.1.0.5, 00:18:48, GigabitEthernet0/0
     150.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
D EX    150.1.5.0/24
           [170/2560002816] via 190.1.0.5, 00:18:48, GigabitEthernet0/0

We don’t have any D EX routes on r5:

r5#sh ip route ei | i D EX
r5#

We’re not redistributing connected under either protocol, so we should be good to go:

router eigrp 10
 redistribute rip metric 1 1 1 1 1 route-map RIP->EIGRP
 network 190.1.0.5 0.0.0.0
 network 190.1.5.5 0.0.0.0
 no auto-summary
 eigrp router-id 150.1.5.5
!
router ospf 100
 router-id 150.1.5.5
 log-adjacency-changes
 redistribute rip subnets tag 5120 route-map LOOP0->RIP-OSPF
 network 190.1.135.5 0.0.0.0 area 135
 neighbor 190.1.135.3
 neighbor 190.1.135.1

r1#sh ip os data | i Tag|590|5170
Link ID         ADV Router      Age         Seq#       Checksum Tag
54.1.1.0        150.1.5.5       42          0×80000001 0x001F57 590
150.1.2.0       150.1.5.5       42          0×80000001 0x002AEB 590
150.1.6.0       150.1.5.5       42          0×80000001 0x00FD14 590
150.1.8.0       150.1.5.5       42          0×80000001 0x00E728 590
190.1.0.0       150.1.5.5       42          0×80000001 0x003BB3 590
190.1.5.0       150.1.5.5       42          0×80000001 0x0004E5 590
200.0.0.0       150.1.5.5       42          0×80000001 0x00C421 590
200.0.1.0       150.1.5.5       42          0×80000001 0x00B92B 590
200.0.2.0       150.1.5.5       42          0×80000001 0x00AE35 590
200.0.3.0       150.1.5.5       42          0×80000001 0x00A33F 590

Sweet.  I’m seeing EIGRP routes, but no D EX routes redistributed into OSPF.

Now the final step.  OSPF into EIGRP.  We should be fine because the OSPF routes will become D EX routes and not reflect back into OSPF.

So now we have a ton of D EX routes on r2:

r2#sh ip route | i D EX
D EX 222.22.2.0/24
D EX 204.12.1.0/24
D EX 220.20.3.0/24
D EX    190.1.135.0
D EX    190.1.34.0
D EX    190.1.17.0
D EX    190.1.4.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    190.1.3.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    10.5.5.0/24
D EX    10.4.4.0/24
D EX    10.4.4.4/32
D EX 192.10.1.0/24
D EX    31.3.0.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    31.2.0.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    31.1.0.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    31.0.0.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    150.1.7.0/24
D EX    150.1.5.0/24
D EX    150.1.4.0/24
D EX    150.1.3.0/24
D EX    150.1.1.0/24
D EX 205.90.31.0/24
D EX    30.2.0.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    30.3.0.0 [170/2560002816] via 190.1.0.5, 00:00:20, GigabitEthernet0/0
D EX    30.0.0.0 [170/2560002816] via 190.1.0.5, 00:00:20, GigabitEthernet0/0
D EX    30.1.0.0 [170/2560002816] via 190.1.0.5, 00:00:20, GigabitEthernet0/0

But still none on R5:

r5#sh ip route | i D EX
r5#

We can ping 10.4.4.4 from the EIGRP domain now:

r2#p 10.4.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms 

We can make one more sanity check.  Let’s create a new loopback on r2 and redistribute it into EIGRP.  This will create an external route that should show up in the OSPF domain.  We can then verify that our 5170 tags are working.

r2(config)#int lo1
r2(config-if)#ip add 2.2.2.2 255.255.255.0
r2(config-if)#route-map LOOP1->EIGRP perm 10
r2(config-route-map)#match int lo1
r2(config-route-map)#router eig 10
r2(config-router)#redist conn route-map LOOP1->EIGRP met 1 1 1 1 1

It shows up on r5:

r5#sh ip route | i D EX
D EX    2.2.2.0 [170/2560002816] via 190.1.0.2, 00:00:15, FastEthernet0/0

It should now appear on r1 as an E2 OSPF route with a tag of 5170:

r1#sh ip route 2.2.2.0
Routing entry for 2.2.2.0/24
  Known via “ospf 100″, distance 110, metric 20
  Tag 5170, type extern 2, forward metric 65
  Last update from 190.1.135.5 on Serial0/0.1, 00:01:46 ago
  Routing Descriptor Blocks:
  * 190.1.135.5, from 150.1.5.5, 00:01:46 ago, via Serial0/0.1
      Route metric is 20, traffic share count is 1
      Route tag 5170

Sweet!!!  My tagging system works.  Let’s remove that configuration and then work on task 4.14

4.14 Redistribution Loop Prevention

“Do not allow the RIP routes redistributed into OSPF on r4 to be passed back into RIP on r5.”
“Use route tagging to accomplish this.”

The RIP routes redistributed into OSPF on r4 should be tagged with 4120 (and lo0 will be tagged 41).  Let’s see if they show up on r5:

r5#sh ip os data | i Tag|41
Link ID         ADV Router      Age         Seq#       Checksum Tag
10.4.4.0        150.1.4.4       971         0×80000005 0x003C86 4120
10.5.5.5        150.1.4.4       971         0×80000005 0x00F2C8 4120
30.0.0.0        150.1.4.4       692         0×80000001 0x009B1F 4120
30.1.0.0        150.1.4.4       691         0×80000001 0x008F2A 4120
30.2.0.0        150.1.4.4       691         0×80000001 0×008335 4120
30.3.0.0        150.1.4.4       691         0×80000001 0×007740 4120
31.0.0.0        150.1.4.4       691         0×80000001 0x008E2B 4120
31.1.0.0        150.1.4.4       691         0×80000001 0×008236 4120
31.2.0.0        150.1.4.4       691         0×80000001 0×007641 4120
31.3.0.0        150.1.4.4       691         0×80000001 0x006A4C 4120
150.1.4.0       150.1.4.4       971         0×80000005 0x005FD8 41
190.1.4.0       150.1.4.4       971         0×80000005 0x0033DD 4120
204.12.1.0      150.1.4.4       971         0×80000006 0x0017E2 4120

Here’s my OSPF->RIP redistribution on r5:

router rip
 redistribute ospf 100 metric 2 route-map OSPF->RIP
!
route-map OSPF->RIP permit 10
 description Tag OSPF routes with 5110
 set tag 5110

So basically, we just need to create a deny statement for routes tagged 4120 or 41:

route-map OSPF->RIP deny 10
 description Filter OSPF routes tagged 4120 or 41
 match tag 4120 41
route-map OSPF->RIP permit 20
 description Tag OSPF routes with 5110
 set tag 5110

Whew!!!  These two tasks took me awhile, but I feel like I had a very good understanding of what was going on.  I’m still painfully slow, but I the basics of route redistribution are finally baking into my brain.  :-)

Internetwork Expert Volume III: Lab 3 – Section 4 Part 1

4 Interior Gateway Routing

4.1 RIPv2

Very simple task.  Luckily they didn’t ask for a minimal configuration:

My answer:
router rip
 version 2
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet0/1
 no passive-interface Serial0/1
 network 10.0.0.0
 network 190.1.0.0
 network 204.12.1.0
 no auto-summary

IE’s answer:
router rip
 version 2
 passive-interface Serial0/0 <-much simpler  :-)
 network 10.0.0.0
 network 190.1.0.0
 network 204.12.1.0
 no auto-summary

4.2 RIPv3

“Allow r4 and r5 to send/receive RIP updates between each other across the Serial connection by disabling the validation of RIP updates.”

Remember that the r4 and r5 s1/0 are in different IP subnets.  The wording of the task gives you a huge clue.

validate-update-source

r4(config)#router rip
r4(config-router)#no validate-update-source

Now you’ll see r4′s RIP advertised networks on r5:

r5#clear ip route *
r5#sh ip route rip
R    204.12.1.0/24 [120/1] via 10.4.4.4, 00:00:03
     190.1.0.0/24 is subnetted, 5 subnets
R       190.1.34.0 [120/1] via 10.4.4.4, 00:00:03
R       190.1.4.0 [120/1] via 10.4.4.4, 00:00:03

4.3 RIPv2 Metric Manipulation

“Configure an inbound offset-list on r4so the RIP routes learned from BB3 appear in r5′s routering table with a hop count of 15.”  

This task illustrates one of the differences between the Volume II and Volume III labs: you are more likely to see tasks in the Volume III labs that explicitly tell what feature to use in order to accomplish a task.

offset-list (RIP)

I decided to just offset ALL of the RIP routes coming in fa0/0 rather than configure an explicit ACL.  You can do this by using ACL 0 in your offset-list: 

r4(config-router)#offset-list 0 in 14 fa0/0

This tells the router to add 14 to the hop count of all  RIP routes inbound on interface fa0/0 (to BB3):

r4#sh ip route rip
     31.0.0.0/16 is subnetted, 4 subnets
R       31.3.0.0 [120/15] via 204.12.1.254, 00:00:01, FastEthernet0/0
R       31.2.0.0 [120/15] via 204.12.1.254, 00:00:01, FastEthernet0/0
R       31.1.0.0 [120/15] via 204.12.1.254, 00:00:01, FastEthernet0/0
R       31.0.0.0 [120/15] via 204.12.1.254, 00:00:01, FastEthernet0/0
     30.0.0.0/16 is subnetted, 4 subnets
R       30.2.0.0 [120/15] via 204.12.1.254, 00:00:01, FastEthernet0/0
R       30.3.0.0 [120/15] via 204.12.1.254, 00:00:01, FastEthernet0/0
R       30.0.0.0 [120/15] via 204.12.1.254, 00:00:01, FastEthernet0/0
R       30.1.0.0 [120/15] via 204.12.1.254, 00:00:01, FastEthernet0/0

I was confused when I saw the IE answer:

offset-list 0 in 13 fa0/0

I have no idea why they used 13?

SHIT!!!! YES I DO.  A quick reread the question shows how I lost some easy points by not reading the question carefully:

“Configure an inbound offset-list on r4 so the RIP routes learned from BB3 appear in r5′s router table with a hop count of 15.”

My “solution” not only lost me some easy points, but it also effectively filtered all of the BB3 routes from r5 because they now have a hop-count of 16 on r5 so they are not installed:

r5#sh ip route rip
R    204.12.1.0/24 [120/1] via 10.4.4.4, 00:00:22
     190.1.0.0/24 is subnetted, 5 subnets
R       190.1.34.0 [120/1] via 10.4.4.4, 00:00:22
R       190.1.4.0 [120/1] via 10.4.4.4, 00:00:22

After a quick change:

r4(config)#router rip
r4(config-router)#offset-list 0 in 13 fa0/0  

r5#sh ip route rip
—output truncated—
R       31.3.0.0 [120/15] via 10.4.4.4, 00:00:09
R       31.2.0.0 [120/15] via 10.4.4.4, 00:00:09
R       31.1.0.0 [120/15] via 10.4.4.4, 00:00:09
R       31.0.0.0 [120/15] via 10.4.4.4, 00:00:09
     30.0.0.0/16 is subnetted, 4 subnets
R       30.2.0.0 [120/15] via 10.4.4.4, 00:00:09
R       30.3.0.0 [120/15] via 10.4.4.4, 00:00:09
R       30.0.0.0 [120/15] via 10.4.4.4, 00:00:09
R       30.1.0.0 [120/15] via 10.4.4.4, 00:00:09

4.4 OSPF

Easy OSPF task.  You need to peer r1, r3, and r5 across Frame Relay.  r5 must be the DR and you are not allowed to change the OSPF network type.  You’ll need your old friend, the ‘neighbor’ command to change your OSPF traffic to unicast to get around the default NON_BROADCAST network type.

neighbor (OSPF)

NOTE: Looking at the protocol topology, I don’t see an OSPF area 0. ????

4.5 OSPF

Here’s where that missing area 0 comes back to bite me in the ass.  You are asked to configure two more non-zero areas and then:

“Without regard to network redundancy, use the minimal number of virtual links needed to support this OSPF domain.”

I’m lost.  I thought that you needed to have an area 0.  I have 3 areas: 17, 34, and 135.

I guess that the minimum number of links is one.  We just need to connect r1 (area 17) to r3 (area 35) through area 135.  I am missing a fundamental understanding of OSPF concerning virtual-links and area 0.  I’ll need to hit the books. [It turns out that my understanding was correct, but my lab strategy was flawed...see next task.]

I also changed the OSPF network type on r3 and r4′s Frame Relay interfaces to broadcast to establish an adjacency.  IE used the neighbor command.  Both methods work.

4.6 OSPF Loopback Advertisement

LESSON LEARNED!!!  READ THE ENTIRE LAB.

Well, now I know where to find area 0.  I am tasked with advertising a loopback into area 0 in this task. This makes 4.5 make sense and it makes the virtual link come up.

4.7 OSPF Loopback Advertisement

Advertise another loopback in to OSPF and advertise it with a /24 mask.  Then:

“This subnet should not be associated with any particular area.”

There are two ways to accomplish this, but I only remember one.  :-)

Redistributing Loopback 0 into OSPF will accomplish this task.  I need to keep this in mind when it comes time to do IGP redistribution.

r4(config)#route-map LOOP->OSPF permit
r4(config-route-map)#match int lo0
r4(config-route-map)#router os 100
r4(config-router)#redist conn sub route-map LOOP->OSPF tag 41

r3#sh ip route os | i E
O E2    150.1.4.0/24 [110/20] via 190.1.34.4, 00:01:17, Serial0/1:0

4.8 OSPF Loopback Advertisement

This task switches up the previous task.  This time you need to advertise a loopback with a /24 but it needs to be associated with an area (area not specified) and you cannot use “ip ospf network point-to-point” for this task.

This can be accomplished with the “area range” command.

area range

r3(config-router)#area 3 range 150.1.3.0 255.255.255.0 advertise

r5#sh ip route os | i 150.1.3.0
O IA    150.1.3.0 [110/65] via 190.1.135.3, 00:00:51, Serial0/0.1

r5#sh ip route 150.1.3.3
Routing entry for 150.1.3.0/24
  Known via “ospf 100″, distance 110, metric 65, type inter area
  Last update from 190.1.135.3 on Serial0/0.1, 00:00:54 ago
  Routing Descriptor Blocks:
  * 190.1.135.3, from 150.1.3.3, 00:00:54 ago, via Serial0/0.1
      Route metric is 65, traffic share count is 1

4.9 OSPF Loopback Advertisement

Another variation on a theme: Advertise a loopback into OSPF.  It should appear in all other OSPF routers with a /24 mask.  It should not be associated with any area.  Don’t use ‘redistribute connected’ to do this.

I’m out of ideas.  Maybe a summary route?  Tried it – didn’t work.

The answer is pretty ingenious:

1) Advertise lo0 into RIP
2) Match lo0 in a route-map
2) Redistribute only the lo0 RIP network into OSPF using the route-map

r3#sh ip route 150.1.5.5
Routing entry for 150.1.5.0/24
  Known via “ospf 100“, distance 110, metric 20, type extern 2, forward metric 65
  Last update from 190.1.135.5 on Serial0/0:0.1, 00:00:09 ago
  Routing Descriptor Blocks:
  * 190.1.135.5, from 150.1.5.5, 00:00:09 ago, via Serial0/0:0.1
      Route metric is 20, traffic share count is 1

On the actual lab, I would have simply matched the loopback in a route-map and redistributed connected (with route-map) into OSPF.  I would have lost the points for this task, but OSPF would still have the route with a /24 mask and not associated with any area.

4.10 EIGRP

Easy EIGRP task.  IE solution guide is missing the sw3 configuration.

4.11 EIGRP

Easy EIGRP authentication task.  You need to establish a neighbor relationship with BB1.  The only thing missing is whether you need to use md5 or not (you do).  I honestly don’t think that non-md5 EIGRP authentication is an option anymore, but I will need to research that.

4.12 EIGRP Summarization

Advertise some routers’ loopbacks into EIGRP but have them appear to other routers with a /23 mask rather than a /24 mask.

You need to do route summarization.  Remember that in EIGRP that this is done under the interface that the route will go out:

r2(config-if)#ip summary-address ?
  eigrp  Enhanced Interior Gateway Routing Protocol (EIGRP)
  rip    Routing Information Protocol (RIP)

ip summary-address eigrp

/23 = 255.255.254.0

Need to be careful with sw3 (150.1.9.9)

00001001 with /23 mask will be 150.1.8.0/23

Should I leak the actual loopback IP?  Will this fuck up my router-id?

Interesting:  IOS will change your summary-address statement for you:

sw3(config)#int vlan 2569
sw3(config-if)#ip summary-address eigrp 10 150.1.9.0 255.255.254.0
sw3(config-if)#do sh run int vlan 2569
interface Vlan2569
 ip address 190.1.0.9 255.255.255.0
 ip summary-address eigrp 10 150.1.8.0 255.255.254.0 5

 r5#sh ip route 150.1.2.2 | i Routing entry|Known
Routing entry for 150.1.2.0/23
  Known via “eigrp 10″, distance 90, metric 156160, type internal

r5#sh ip route 150.1.6.6 | i Routing entry|Known
Routing entry for 150.1.6.0/23
  Known via “eigrp 10″, distance 90, metric 156160, type internal

r5#sh ip route 150.1.9.9 | i Routing entry|Known
Routing entry for 150.1.8.0/23  <-note the third octet
  Known via “eigrp 10″, distance 90, metric 156160, type internal

IE solution guide shows 150.1.8.0 255.255.255.

Internetwork Expert Volume III: Lab 3 – Section 3

3 WAN Technologies

3.1 Point-to-Point

This is a fairly easy task.  You just need to disable Frame Relay Inverse-ARP for all DLCIs except for certain DLCIs.  You’ll need to see which PVC are present on router and then explicitly disable Frame Relay Inverse-ARP for the ones that you do not want to dynamically create a Frame Relay map:

r4(config)#do sh frame pvc | i DLCI
DLCI = 401, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/0
DLCI = 402, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/0
DLCI = 403, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/0
DLCI = 405, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/0
DLCI = 413, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/0

r4(config)#int s0/0
r4(config-if)#no frame inv ip 401
r4(config-if)#no frame inv ip 402
r4(config-if)#no frame inv ip 403
r4(config-if)#no frame inv ip 405

r4#sh frame map
Serial0/0(up): ip 190.1.34.3 dlci 413(0x19D,0x64D0), dynamic,
              broadcast,
              CISCO, status defined, active

3.2 Multipoint

“Configure the routers so that if the DLCIs between them change to inactive or deleted status the interfaces used for the Frame Relay link are brought down.”

Isn’t this just saying to use physical interfaces?

I used the physical interfaces, but IE used point-to-mulitpoint subinterfaces.  I don’t see the difference.  Maybe some future task(s) affect this choice?

3.3 Point-To-Point

Nothing to say about this very basic Frame Relay point-to-point subinterface configuration.

3.4 PPP

“Configure PPP on the Serial connection between r4 and r5.”
“To ensure connectivity across this Serial connection, do not disable the peer neighbor router generated by PPP.”

Note that the connected interfaces are NOT in the same IP subnet.  BUT you will have a host route installed on each side of the link:

r4#sh ip route | i 10.5.5.5
C       10.5.5.5/32 is directly connected, Serial0/1

r5#sh ip route | i 10.4.4.4
C       10.4.4.4/32 is directly connected, Serial0/1

Note that only the host route is installed:

r4#sh ip route 10.5.5.0
% Subnet not in table

r4#sh ip route 10.5.5.5
Routing entry for 10.5.5.5/32
  Known via “connected”, distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Serial0/1
      Route metric is 0, traffic share count is 1

This is a normal function of PPP.  There is a default command of “peer neighbor-route” configured when you enable PPP.  The trick is not how to enable this feature, but rather how to disable it:

r4(config)#int s0/1
r4(config-if)#no peer neighbor-route
r4(config-if)#do clear ip route *
r4(config-if)#do sh ip route 10.5.5.5
% Subnet not in table

r5(config)#int s0/1
r5(config-if)#no peer neighbor-route
r5(config-if)#do clear ip route *
r5(config-if)#do sh ip route 10.4.4.4
% Subnet not in table

3.5 PPP Authentication

This is a pretty straightforward task that requires you to use PAP with “ppp pap sent-username“on r5.

“r5 should not authenticate r4.”

This means that you only need to turn PAP authentication on for r4.  R5 will send a username and password to r4.  r4 will authenticate r5, but r5 will not authenticate r4.

r4#sh run | sec user|Serial0/1
username ROUTER5 password 0 CISCO
!
interface Serial0/1
 ip address 10.4.4.4 255.255.255.0
 encapsulation ppp
 ppp authentication pap

r5:
interface Serial0/1
 ip address 10.5.5.5 255.255.255.0
 encapsulation ppp
 ppp pap sent-username ROUTER5 password 0 CISCO

Internetwork Expert Volume III: Lab 3 – Section 2

2 Bridging and Switching

2.1 VLAN Assignments

This should have been a very simple task, but a couple of interesting wrinkles made this a harder task than normal.  I was going to blog my whole “stream of thought” experience, but you’ll get enough of that in section 4, so I’ll spare you.  :-)

Usually you are given a list of VLANs and interfaces to configure, but in this case you are asked to configure VLANs and interfaces from the network diagram only.  This is a really good exercise.  The biggest twist with this lab (and the part that took me the most amount of time) is that you will not have VTP to propagate the VLANs to the appropriate switches (more on that in a bit) so you will need to make sure that you take trunking into account when assigning VLANs to each switch.

The reason you cannot use VTP is because one of the VLANs you need to configure is VLAN 2569.  This in an extended VLAN so VTP will not allow you to configure it:

sw1(config)#vtp mode server
sw1(config)#vtp domain IE
Changing VTP domain name from NULL to IE
sw1(config)#vlan 2569
sw1(config-vlan)#exit
% Failed to create VLANs 2569
Extended VLAN(s) not allowed in current VTP mode.
%Failed to commit extended VLAN(s) changes.

In this case VLAN 2569 is going to need to be present on each switch.  We are also tasked with running VTP so we’ll need to configure all of the switches as VTP Transparent.  This means that your VLANs are not going to propagate from switch to switch.  The easy way to handle this is to assign all known VLANs on each switch.  The IE solution does not show this.  This may be a limitation of this subtask:

“Configure VLAN assignments per the diagram.”

In the real lab you should ask the proctor about this.  It’s also good to know that you can configure all known VLANs on each switch as a workaround if you are short on time.

One other caveat for this task: you will not be able to verify reachability for some addresses until you get your trunking built (covered in the next two tasks).

2.2 Trunking

This is a very easy trunking task.  The only bit of oddness is that the IE solution guide has “switchport nonegotiate” for all trunking interfaces. I don’t see anything in the task that requires that DTP be disabled.  

2.3 EtherChannel

Easy enough.  A layer 2 map comes in handy as you are only given the interfaces on one side of each etherchannel. 

IE solution is wrong for subtask 2.  It shows “channel-group 1 mode active” when it should be “channel-group 2 mode active”.

New Internetwork Expert Blog

As I was logging into my IE account today, I noticed a new link on their site.  It appears that IE is now running a blog.  The first posts are from late December.  Some of the posts look similar to the white papers already posted in their Resources section, but most of the posts appear to be new responses to questions posed to IE by candidates.  As a matter of fact, the IE blog is opening soliciting questions:

Welcome to Internetwork Expert’s CCIE Blog! This site is dedicated to helping you in your pursuit of becoming a Cisco Certified Internetwork Expert in Routing & Switching, Voice, Security, Service Provider, and Storage. Through this blog you can submit questionsto our expert instructors, Brian Dennis – Quad-CCIE #2210, and Brian McGahan – Triple CCIE #8593. Check back daily as this blog will be updated frequently.

This is pretty cool.  A multiple-CCIE-path blog with questions answered by the Brians is a great addition to the growing group of CCIE blog.

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

Follow

Get every new post delivered to your Inbox.

Join 109 other followers