CCIE Pursuit Blog

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

January 20, 2008

Internetwork Expert Volume II: Lab 3 – Section 4

Interior Gateway Routing – 21 Points

4.1 OSPF

“Ensure that r2 (spoke) uses r5(hub) as the next hop to reach r4(spoke), and vice versa.”

OSPF Commands

This is a tailor-made case for the OSPF network type point-to-multipoint. 

I did have a strange error pop up during this configuration:

r5(config-router)#int s0/0.245
r5(config-subif)#ip os net point-to-mu
OSPF: Cost or database-filter option is required for point-to-multipoint broadcast network
OSPF: Neighbor 136.1.245.2 command options invalid – neighbor not configured
OSPF: Cost or database-filter option is required for point-to-multipoint broadcast network
OSPF: Neighbor 136.1.245.4 command options invalid – neighbor not configured
*Mar  1 01:23:14.170: %OSPF-5-ADJCHG: Process 100, Nbr 0.0.0.0 on Serial0/0.245 from ATTEMPT to DOWN, Neighbor Down: Interface down or detached
*Mar  1 01:23:14.170: %OSPF-5-ADJCHG: Process 100, Nbr 0.0.0.0 on Serial0/0.245 from ATTEMPT to DOWN, Neighbor Down: Interface down or detached
*Mar  1 01:23:14.238: %OSPF-5-ADJCHG: Process 100, Nbr 150.1.2.2 on Serial0/0.245 from LOADING to FULL, Loading Done

r5(config-subif)#do sh run int s0/0.245
interface Serial0/0.245 multipoint
 description ->r2, r4 FR HnS
 ip address 136.1.245.5 255.255.255.0
 ip ospf network point-to-multipoint
 frame-relay map ip 136.1.245.2 502 broadcast
 frame-relay map ip 136.1.245.4 504 broadcast
end

There is an excellent breakdown on the point-to-multipoint network type in the IE solution guide.

4.2 OSPF

Read the task carefully:

“Do not use the ip ospf network type ON R5 to accomplish this.”

This doesn’t say anything about r1.

r5#sh ip os int Serial0/0.15 | i Type
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 64

Let’s change r1’s OSPF network type to point-to-point as well:

r1(config)#int s0/0
r1(config-if)#ip os net point-to-point

r1#sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.5.5         0   FULL/  –        00:00:38    136.1.15.5      Serial0/0

r1#sh ip route os
     136.1.0.0/16 is variably subnetted, 7 subnets, 2 masks
O       136.1.245.4/32 [110/129] via 136.1.15.5, 00:00:04, Serial0/0
O       136.1.245.5/32 [110/65] via 136.1.15.5, 00:00:04, Serial0/0
O       136.1.245.2/32 [110/129] via 136.1.15.5, 00:00:04, Serial0/0
O IA    136.1.4.0/24 [110/130] via 136.1.15.5, 00:00:04, Serial0/0
O IA    136.1.44.0/24 [110/130] via 136.1.15.5, 00:00:04, Serial0/0

4.3  OSPF

Easy task.  Advertise loopbacks into OSPF with /24 mask.  Just change the OSPF network type from LOOPBACK to POINT-TO-POINT on the loopback 0 interfaces.

4.4 OSPF

Configure the PTP connection from r4 to r5 in area 45 and use it only as a backup link when the Frame Relay link drops.

“Do not user the ‘backup interface’ command to accomplish this.”

I was stumped on this one initially.  I shut the Frame interface on r4 and the OSPF routes changed to the PTP link.  What I initially overlooked was that when that r4 Frame link drops, areas 4 and 44(on r4) will not have a connection to area 0.  I’ll need a virtual-link.

“Virtual-links can be used to repair broken connections to area 0, connect discontiguous area to area 0, and connect discontiguous area0s.”

The method to “trigger” the PTP connection: just give it a higher metric than the Frame Relay link.  When the Frame link drops, then traffic will route over the PTP.

ip ospf cost

area virtual-link

4.5 OSPF

“You are concerned about false routing information being injected into OSPF area 0.  In order to verify the legitimacy of routing information, configure all area 0 adjacencies to be authenticated with a secure hash value of the password CISCO.”

area authentication

Good to know:

Note:To remove the specified area from the software configuration, use the no area area-id command (with no other keywords). That is, the no area area-id command removes all area options, such as area authentication, area default-cost, area nssa, area range, area stub, and area virtual-link.

r1(config-router)#area 0 authentication ?
  message-digest  Use message-digest authentication
r1(config-router)#area 0 authentication message-digest ?
  <cr>

r1(config)#do sh ip os int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0          100   0               150.1.1.1/24       1     P2P   0/0
Se0/0        100   0               136.1.15.1/24      65    P2P   1/1

r1(config)#int s0/0
r1(config-if)#ip os authentication-key CISCO

I did miss the “Pitfall”:

“A virtual-link is an area 0 adjacency.  If authentication is required for all OSPF area adjacencies, then it must also be configured on all virtual-links.”

I also used “ip os authentication-key CISCO” under the interfaces instead of ‘ip ospf message-digest-key md5 CISCO’.

ip ospf message-digest-key md5

4.6 OSPF

Change OSPF metrics to accommodate 10Gbps connections.

auto-cost

The OSPF metric is calculated as the ref-bw value divided by the bandwidth, with mbps equal to 108 by default, and bandwidth determined by the bandwidth (interface) command. The calculation gives FDDI a metric of 1.

If you have multiple links with high bandwidth (such as FDDI or ATM), you might want to use a larger number to differentiate the cost on those links.

The value set by the ip ospf cost command overrides the cost resulting from the auto-cost command. <-nice to know as per task 4.4

So, a bit of math:

10^8 = 100,000,000

I need to make the OSPF cost for 10Gbps (10,000,000,000) = 2

So:

x/10,000,000,000 = 2
x = 2 * 10,000,000,000
x = 20,000,000,000

r5(config-router)#auto-cost reference-bandwidth ?
  <1-4294967>  The reference bandwidth in terms of Mbits per second

Divide my answer by 1,000,000 (Mbit) = 20,000

r5(config-router)#auto-cost reference-bandwidth 20000
% OSPF: Reference bandwidth is changed.
        Please ensure reference bandwidth is consistent across all routers.

I don’t have a 10Gbps interface on my router…yet 🙂  But the task does show that a T1 should have a cost of 12953.  That I can check:

r5(config-router)#do sh ip os int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Vl1          100   0               136.1.45.5/24      65534 P2P   1/1
Lo0          100   0               150.1.5.5/24       1     P2P   0/0
Se0/0.15     100   0               136.1.15.5/24      12953 P2P   1/1 
Se0/0.245    100   0               136.1.245.5/24     12953 P2MP  2/2
Se0/1        100   45              136.1.45.5/24      65534 P2P   1/1

You can see that s0/1’s hard set cost (65534) is not affected.

You need to apply this command to ALL routers running OSPF in your network.

One interesting bit:

r1:
r1#sh int s0/0 | i BW
  MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
r1#sh ip os int s0/0 | i Cost
  Process ID 100, Router ID 150.1.1.1, Network Type POINT_TO_POINT, Cost: 13020

r5:
r5#sh int s0/0.15 | i BW
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
r5#sh ip os int s0/0.15 | i Cost
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 12953

This is another “Ask the proctor” issue.  You can easily change this:

r1(config)#int s0/0
r1(config-if)#bandwidth 1544
r1(config-if)#do sh int s0/0 | i BW
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
r1(config-if)#do sh ip os int s0/0 | i Cost
  Process ID 100, Router ID 150.1.1.1, Network Type POINT_TO_POINT, Cost: 12953

4.7  EIGRP

“Do not send EIGRP hello packets out any other interfaces.”
“Do not use the ‘passive interface’ command under the EIGRP process”

“under the EIGRP process”…is there a way to do this under the interface itself?

EIGRP Commands

I couldn’t find anything like that.  What about the neighbor command?

That won’t work either.

I completely overthought this one.  😦

Just add a network mask to your EIGRP network statement:

router eigrp 100
 net 150.1.6.6 0.0.0.0

Why can’t I see r6’s loopback (150.1.6.6) on r2 or r3 or r1?

Did I forget a “no auto” statement? No. 
Something to do with router on a stick? No.
Ummmm….I forgot to advertise VLAN 16 and VLAN 36 on r6. (I caught this before consulting the solutions guide)

Nicely played.  I am learning to verify routes as I go.  🙂

4.8  RIPv2

“…use the strongest authentication on any RIP updates…”
“Do not enable RIP on any other interfaces.”

Configuring Routing Information Protocol

Enabling RIP Authentication

ip rip authentication mode
ip rip authentication mode {text | md5}

Usage Guidelines
RIP Version 1 does not support authentication. <- we use RIPv2 in the lab

passive-interface
passive-interface
 Disables sending routing updates on an interface. 

IE solution shows r5 and sw1 with “passive-interface default”, but not r6???  Why?

Answer: r6 has no overlapping classful interfaces:

r6#sh ip int br | e ass
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/0                  54.1.3.6        YES NVRAM  up                    up
FastEthernet0/1            204.12.1.6      YES NVRAM  up                    up
BVI1                       136.1.136.6     YES manual up                    up
Loopback0                  150.1.6.6       YES NVRAM  up                    up

r5 and sw1 do:

r5#sh ip int br | e ass
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.10.1.5      YES NVRAM  up                    up
Serial0/0.15               136.1.15.5      YES NVRAM  up                    up
Serial0/0.245              136.1.245.5     YES NVRAM  up                    up
FastEthernet0/1            136.1.57.5      YES NVRAM  up                    up
Serial0/1                  136.1.45.5      YES NVRAM  up                    up
Loopback0                  150.1.5.5       YES NVRAM  up                    up

sw1:
sw1#sh ip int br | e ass
Interface              IP-Address      OK? Method Status                Protocol
Vlan7                  136.1.7.7       YES NVRAM  down                  down
Vlan57                 136.1.57.7      YES NVRAM  up                    up
Loopback0              150.1.7.7       YES NVRAM  up                    up

Why is vlan7 down?

sw1#sh run int vlan7
interface Vlan7
 ip address 136.1.7.7 255.255.255.0
end

sw1#sh vlan id 7
VLAN id 7 not found in current VLAN database

That’s the reason.  🙂

Initial Configuration for switching …. IE Lab 3

I’ll go ahead and add vlan 7:

23:39:05: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan7, changed state to up

VLAN7 is not included in IE’s solution either.  They configured “no passive-interface vlan57”, but make no mention of vlan7.  Even though the task requires:

“Enable RIP on VLAN7…”

Task 4.8 – passive interface VLAN7 on SW1 

4.9  IGP Redistribution

ICK!!!

“Redistribute where necessary to obtain full IP reachabiltity to all advertised networks.”
“r5 should route through r1 to get to the prefixes learned from bb1”
“r5 should route through r2 to get to the prefixes learned from bb3”

Looking at my diagram, I have 4 possible point of redistribution:

r1 – OSPF 100 (110)  |  EIGRP 100 (90)
r2 – OSPF 100 (110)  |  EIGRP 100 (90)
r5 – OSPF 100 (110)  |  RIP (120)
r6 – EIGRP 100 (90)  |  RIP (120)

My AD matra: “Lower to higher is good.  Higher to lower is bad.”

Tasks 2 and 3 mean that I need to redistribute RIP into EIGRP on r6 and then redistribute EIGRP into OSPF on r1 and r2.  I’ll set up route maps to filter what routes are redistributed at those points.

I’m really proud of myself.  I finished this task by myself.  I met the requirements for each task, but I used a slightly different method than IE.

Differences:
1) I did not redistribute OSPF into EIGRP on both r1 and r2.  Only on r1.  There was no requirement to do it on both routers and it cut the chance of loops down.
2) I tagged the routes on r6 based on the incoming interface (fa0/1 for BB3 and s0/0 for BB1).  I redistributed all of the routes except the routes tagged from BB1 through r1 into OSPF.  I redistributed the BB1 routes into OSPF through r2 (thinking about this now, I could have probably gotten by just tagging the BB1 routes).

This task took me FOREVER, but I did complete it successfully.

I will say that the IE solution manual is VERY light on explaining their route redistribution answer.

December 2, 2007

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.

Blog at WordPress.com.