CCIE Pursuit Blog

April 12, 2008

Internetwork Expert Volume III: Lab 5 – Section 4

Interior Gateway Routing – 25 Points

4.1 EIGRP

“Do not send multicast EIGRP updates within VLAN 14”

neighbor (EIGRP)

Remember that you need to configure this on both routers (unlike OSPF):

r1
router eigrp 10
 network 128.1.14.1 0.0.0.0
 no auto-summary
 eigrp router-id 150.1.1.1
 neighbor 128.1.14.4 FastEthernet0/0.2

r4
router eigrp 10
 network 128.1.14.4 0.0.0.0
 no auto-summary
 eigrp router-id 150.1.4.4
 neighbor 128.1.14.1 FastEthernet0/0

4.2 OSPF

Configure OSPF area 0.0.0.0.  This is just the dotted decimal equivalent of area 0.

r1(config-router)#do sh run | sec router os
router ospf 100
 router-id 150.1.1.1
 log-adjacency-changes
 network 128.1.136.1 0.0.0.0 area 0.0.0.0

r1(config-router)#do sh ip os int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa0/0.1      100   0.0.0.0        128.1.136.1/24     1     WAIT  0/0

4.3 OSPF

“Without enabling OSPF on r3’s interface fa0/0.2 or r6’s interface fa0/0.2, ensure that they will still receive OSPF routers from each other in the event that they lose their connectivity with r1.”

Basically, we need to make sure that r3 and r6 can communicate over their redundant LAN connection if the primary one fails.

I’m thinking that we can tunnel over that second LAN.  The only problem is that you’d need to an a new subnet to do this.  I peeked the solution guide and that exactly what they did, so I guess that it’s alright.

r6(config-router)#do sh ip os int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa0/0.1      100   0.0.0.0         128.1.136.6/24     1     DROTH 2/2
Tu0          100   0.0.0.0         128.1.63.6/24      11111 P2P   1/1

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.1.1         1   FULL/DR         00:00:31    128.1.136.1     FastEthernet0/0.1
150.1.3.3         1   FULL/BDR        00:00:32    128.1.136.3     FastEthernet0/0.1
150.1.3.3         0   FULL/  –        00:00:34    128.1.63.3      Tunnel0

r6(config)#int fa0/0.1
r6(config-subif)#shut
r6(config-subif)#do sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.3.3         0   FULL/  –        00:00:34    128.1.63.3      Tunnel0

4.4 OSPF

Configure OSPF on the PPPoFR network.

The current OPSF network type is point-to-point, which makes sense considering we’re running PPP.  🙂

r5(config-router)#do sh ip os int | i proto|Type
Virtual-Access2 is up, line protocol is up
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 1
Virtual-Template1 is down, line protocol is down
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 1
Virtual-Access1 is up, line protocol is up
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 1

I’m going to need to change the network type because this is a hub-and-spoke network.  Let’s use point-to-multipoint:

r2(config)#int virtual-template 1
r2(config-if)#ip os net non-broadcast

After all is said and done:

r2#sh ip route os
     128.1.0.0/16 is variably subnetted, 6 subnets, 2 masks
O IA    128.1.136.0/24 [110/3] via 128.1.125.5, 00:00:58, Virtual-Access1
O IA    128.1.63.0/24 [110/11114] via 128.1.125.5, 00:00:58, Virtual-Access1
O       128.1.125.1/32 [110/2] via 128.1.125.5, 00:00:58, Virtual-Access1

4.5 OSPF

Configure an OSPF stub area.  You’re also going to need a virtual-link as this new stub area is not connected to area 0 (or area 0.0.0.0 in this case 🙂 ).

r2(config-router)#area 125 virtual-link 150.1.1.1

r2(config-router)#do sh ip os int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
VL0          100   0               128.1.125.2/24     2     P2P   1/1
Gi0/0        100   12              128.1.27.2/24      1     BDR   1/1
Vi1          100   125             128.1.125.2/24     1     P2MP  1/1
Vt1          100   125             128.1.125.2/24     1     DOWN  0/0

sw1#sh ip route os
     128.1.0.0/16 is variably subnetted, 6 subnets, 2 masks
O IA    128.1.136.0/24 [110/4] via 128.1.27.2, 00:00:40, Vlan72
O IA    128.1.63.0/24 [110/11115] via 128.1.27.2, 00:00:40, Vlan72
O IA    128.1.125.5/32 [110/2] via 128.1.27.2, 00:01:08, Vlan72
O IA    128.1.125.1/32 [110/3] via 128.1.27.2, 00:01:08, Vlan72
O IA    128.1.125.2/32 [110/1] via 128.1.27.2, 00:01:08, Vlan72
O*IA 0.0.0.0/0 [110/2] via 128.1.27.2, 00:01:08, Vlan72

Why all of the virtual-links in the IE solution guide?:

Task 4.5

4.6 OSPF

You’re asked to configure area 51 (hehe) between sw1 and bb2.  The problem is that this new area is non connected to area 0 and you cannot use a virtual-link because area 12 is a stub area.

Another tunnel?  Yup.

Steps:
1) Create tunnel through area 12.
2) Enable OSPF on the tunnel interfaces.  Place them in area 0 (0.0.0.0).

I had to ‘ip os mtu-ignore’ on tu0 on r2.

4.7 OSPF Loopback Advertisements

Advertise a bunch of loopbacks into a couple of non-existant areas.  If everything is configured correctly you should see all of the loopbacks on sw1:

sw1(config-router)#do sh ip route os | i 150.1.
     150.1.0.0/16 is variably subnetted, 6 subnets, 2 masks
O IA    150.1.6.6/32 [110/11115] via 128.1.72.2, 00:00:09, Tunnel0
O IA    150.1.5.5/32 [110/11113] via 128.1.72.2, 00:00:09, Tunnel0
O IA    150.1.3.3/32 [110/11115] via 128.1.72.2, 00:00:09, Tunnel0
O IA    150.1.2.2/32 [110/11112] via 128.1.72.2, 00:00:09, Tunnel0
O IA    150.1.1.1/32 [110/11114] via 128.1.72.2, 00:00:09, Tunnel0

4.8 RIPv2

A straight-forward, easy task.  Thankfully!  🙂

4.9 Default Routing

Configure r4 to generate a default router to sw2 but not to r5.  Don’t use a distribute-list.

We can add a route-map to the ‘default-information-originate’ under the RIP process:

r4(config-router)#default-information originate ?
  route-map  Route-map reference
  <cr>

default-information originate (RIP)

So how do I write a route-map to only advertise to sw2?

r4(config-router)#do sh ip proto | sec Default version
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/1       2     2
    Dialer0               2     2

I want to send the default out fa0/1 and not dialer0 interface.

r4(config-route-map)#set ?
  interface         Output interface

route-map RIP_DEFAULT permit 10
 set interface FastEthernet0/1
!
router rip
 default-information originate route-map RIP_DEFAULT

sw2#sh ip route rip | i 0.0.0.0
R*   0.0.0.0/0
[120/1] via 128.1.48.4, 00:00:06, Vlan48

r5#sh ip route rip | i 0.0.0.0
r5# <-no default route on r5

4.10 Route Filtering

“Configure sw2 so that it will use the default route advertised by r4 to reach the 128.1.14.0/24 network.”
“Use an offset-list on sw2 to accomplish this task.”

This is just a wordy way of telling you to bitbucket the existing route to 128.1.14.0:

Before:
sw2#sh ip route 128.1.14.0
Routing entry for 128.1.14.0/24
  Known via “rip”, distance 120, metric 1
  Redistributing via rip
  Last update from 128.1.48.4 on Vlan48, 00:00:21 ago
  Routing Descriptor Blocks:
  * 128.1.48.4, from 128.1.48.4, 00:00:21 ago, via Vlan48
      Route metric is 1, traffic share count is 1

After:
access-list 71 permit 128.1.14.0 0.0.0.255
!
router rip
  offset-list 71 in 16 vlan48

sw2#sh ip route 128.1.14.0
% Subnet not in table
sw2#p 128.1.14.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 128.1.14.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

4.11 IGP Redistribution

Perform mutual redistribution on three different devices.  As with most of the Volume III labs, you may as well do the next task (the redistribution ‘gotcha’) at the same time.

4.12 Redistribution Loop Prevention

“Ensure that the RIP routes redistributed into EIGRP on r4 do not get passed back into RIP from OSPF on r5.”
“Use route tagging to accomplish this task.”

Sweet.  Route tagging is my preferred method.

So I’m going to tag RIP routes on r4 and then filter those same routes with r5:

r4#sh run | sec route-map RIP->EIGRP
 redistribute rip metric 1 1 1 1 1 route-map RIP->EIGRP
route-map RIP->EIGRP permit 10
 set tag 4120

r5#sh run | sec route-map RIP->OSPF
 redistribute ospf 100 metric 1 route-map RIP->OSPF
route-map RIP->OSPF deny 10
 match tag 4120
route-map RIP->OSPF permit 20

Everything was working fine except for 128.1.14.4 (f0/0 on r1).  I finally had to filter this route from passing to OSPF on r1 and everything was fine.

r1#sh run | sec 128_|EIGRP->OSPF
 redistribute eigrp 10 subnets route-map EIGRP->OSPF
ip prefix-list 128_1_14_0 seq 5 permit 128.1.14.0/24
route-map EIGRP->OSPF deny 10
 match ip address prefix-list 128_1_14_0
route-map EIGRP->OSPF permit 20

This didn’t break the requirements of the task, but I still bothered that I couldn’t figure out why this address was unreachable.

The IE solution guide is a mess for these tasks:

Task 4.13

The task asks you to use route tags to accomplish this task but the IE solution shows r5 changing the AD for OSPF external routes???

r5:
router ospf 1
 distance ospf external 121

 

March 28, 2008

Question Of The Day: 28 March, 2008

Topic: Route Summarization

You have the following subnets in your network:

132.16.32.0/24
132.16.121.0/24
132.16.34.0/24
132.16.33.0/24
132.16.5.0/24
132.16.181.0/24
132.16.27.0/24
132.16.2.0/24

Write a single summary route that will encompass all of these routes while being as specific as possible.

See you Monday.


Yesterday’s Question

 Question Of The Day: 27 March, 2008 

Topic: Route Redistribution 

r1 is running EIGRP and RIP:

r1#sh ip proto sum
Index Process Name
0     connected
1     static
2     eigrp 100
3     rip

r1 has the following EIGRP routes:

r1#sh ip route eigrp
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2297856] via 10.1.12.2, 00:01:06, Serial1/0.12
     22.0.0.0/32 is subnetted, 1 subnets
D EX    22.2.2.2 [170/2560512256] via 10.1.12.2, 00:00:23, Serial1/0.12

r1’s network admin wants to redistribute the EIGRP routes and pass them on to r3 in the RIP domain (directly connected to r1).  Here is his configuration:

r1(config)#route-map EIGRP->RIP perm 10
r1(config-route-map)#match route-type external
r1(config-route-map)#set tag 1170
r1(config-route-map)#route-map EIGRP->RIP perm 20
r1(config-route-map)#set tag 190
r1(config-route-map)#router rip
r1(config-router)#redistribute eigrp 100 route-map EIGRP->RIP

Which EIGRP routes will appear in r3’s (RIP) routing table?

Answer: The redistributed routes appear in r3’s routing table with a metric of 6 (set by the route-map) and r1’s locally generated RIP routes appear with a metric of 1.

r3#sh ip route rip
     2.0.0.0/32 is subnetted, 1 subnets
R       2.2.2.2 [120/6] via 10.1.13.1, 00:00:03, Serial1/0
     22.0.0.0/32 is subnetted, 1 subnets
R       22.2.2.2 [120/6] via 10.1.13.1, 00:00:03, Serial1/0
     10.0.0.0/24 is subnetted, 2 subnets
R       10.1.12.0 [120/1] via 10.1.13.1, 00:00:03, Serial1/0
     12.0.0.0/32 is subnetted, 1 subnets
R       12.12.12.12 [120/6] via 10.1.13.1, 00:00:03, Serial1/0
     13.0.0.0/32 is subnetted, 1 subnets
R       13.13.13.13 [120/1] via 10.1.13.1, 00:00:03, Serial1/0

The order of preference for defining the metric when redistributing routes into a protocol (values in parentheses are the values used in our example):

1) If a route-map is used, then use the metric specified in the route-map (6).
2) If no route-map is used or the route-map does not specify a metric, then use the metric specified in the ‘redistribute’ command (2).
3) If a metric is not specified in a route-map nor is it specified in the ‘redistribute’ command, then use the ‘default-metric'(4).
4) If no metric is specified by any of the above methods, then the routes will not be redistributed (see this QOD).

route-map > redistibution metric > default metric
redistribute (IP)

The metric value specified in the redistribute command supersedes the metric value specified using the default-metric command.

set metric (BGP, OSPF, RIP)

default-metric (RIP)

Usage Guidelines
The default-metric command is used in conjunction with the redistribute router configuration command to cause the current routing protocol to use the same metric value for all redistributed routes. A default metric helps solve the problem of redistributing routes with incompatible metrics. Whenever metrics do not convert, using a default metric provides a reasonable substitute and enables the redistribution to proceed.

The default-metric is only in conjunction with redistribution.  Don’t fall into the trap of thinking that the default metric will affect routes that are not redistibuted.

March 27, 2008

Question Of The Day: 27 March, 2008

Topic: Route Redistribution

The network admin on r1 is tasked with redistributing the EIGRP routes into RIP so that they appear in the routing table of the directly connected router r3 (running RIP only).  Here are the EIGRP routes currently in r1’s routing table:

r1#sh ip route eigrp
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2297856] via 10.1.12.2, 00:07:44, Serial1/0.12
     22.0.0.0/32 is subnetted, 1 subnets
D EX    22.2.2.2 [170/2560512256] via 10.1.12.2, 00:07:44, Serial1/0.12

Here is the configuration on r1:

router rip
 version 2
 redistribute eigrp 100 metric 2 route-map EIGRP->RIP
 passive-interface default
 no passive-interface Serial1/0.13
 network 10.0.0.0
 network 13.0.0.0
 default-metric 4
 no auto-summary
!
route-map EIGRP->RIP permit 10
 set metric 6

On r3, what will be the metric of the redistributed EIGRP routes?  What will be the metric of the locally generated RIP routes (i.e. 13.13.13.13/32)?

I’ll post the answer tomorrow.


Yesterday’s Question

 Question Of The Day: 26 March, 2008 

Topic: Route Redistribution 

r1 is running EIGRP and RIP:

r1#sh ip proto sum
Index Process Name
0     connected
1     static
2     eigrp 100
3     rip

r1 has the following EIGRP routes:

r1#sh ip route eigrp
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2297856] via 10.1.12.2, 00:01:06, Serial1/0.12
     22.0.0.0/32 is subnetted, 1 subnets
D EX    22.2.2.2 [170/2560512256] via 10.1.12.2, 00:00:23, Serial1/0.12

r1’s network admin wants to redistribute the EIGRP routes and pass them on to r3 in the RIP domain (directly connected to r1).  Here is his configuration:

r1(config)#route-map EIGRP->RIP perm 10
r1(config-route-map)#match route-type external
r1(config-route-map)#set tag 1170
r1(config-route-map)#route-map EIGRP->RIP perm 20
r1(config-route-map)#set tag 190
r1(config-route-map)#router rip
r1(config-router)#redistribute eigrp 100 route-map EIGRP->RIP

Which EIGRP routes will appear in r3’s (RIP) routing table?

Answer: NONE

RIP routes on r3 do not include the routes redistributed from EIGRP on r1: 

r3#sh ip route rip
     10.0.0.0/24 is subnetted, 2 subnets
R       10.1.12.0 [120/1] via 10.1.13.1, 00:00:22, Serial1/0
     13.0.0.0/32 is subnetted, 1 subnets
R       13.13.13.13 [120/1] via 10.1.13.1, 00:00:22, Serial1/0

When redistributing routes into RIP you must specify a default metric:

r1(config)#router rip
r1(config-router)#redistribute eigrp 100 metric 3route-map EIGRP->RIP

Now we should see the EIGRP routes in r3’s routing table with a metric of 3:

r3#sh ip route rip
     2.0.0.0/32 is subnetted, 1 subnets
R       2.2.2.2 [120/3] via 10.1.13.1, 00:00:19, Serial1/0
     22.0.0.0/32 is subnetted, 1 subnets
R       22.2.2.2 [120/3] via 10.1.13.1, 00:00:19, Serial1/0
     10.0.0.0/24 is subnetted, 2 subnets
R       10.1.12.0 [120/1] via 10.1.13.1, 00:00:19, Serial1/0
     12.0.0.0/32 is subnetted, 1 subnets
R       12.12.12.12 [120/3] via 10.1.13.1, 00:00:19, Serial1/0
     13.0.0.0/32 is subnetted, 1 subnets
R       13.13.13.13 [120/1] via 10.1.13.1, 00:00:19, Serial1/0

It’s pretty easy to forget the metric as the IOS will not throw an error.  You are basically redistributing the EIGRP routes with a metric of zero.  🙂

March 26, 2008

Question Of The Day: 26 March, 2008

Topic: Route Redistribution 

r1 is running EIGRP and RIP:

r1#sh ip proto sum
Index Process Name
0     connected
1     static
2     eigrp 100
3     rip

r1 has the following EIGRP routes:

r1#sh ip route eigrp
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2297856] via 10.1.12.2, 00:01:06, Serial1/0.12
     22.0.0.0/32 is subnetted, 1 subnets
D EX    22.2.2.2 [170/2560512256] via 10.1.12.2, 00:00:23, Serial1/0.12

r1’s network admin wants to redistribute the EIGRP routes and pass them on to r3 in the RIP domain (directly connected to r1).  Here is his configuration:

r1(config)#route-map EIGRP->RIP perm 10
r1(config-route-map)#match route-type external
r1(config-route-map)#set tag 1170
r1(config-route-map)#route-map EIGRP->RIP perm 20
r1(config-route-map)#set tag 190
r1(config-route-map)#router rip
r1(config-router)#redistribute eigrp 100 route-map EIGRP->RIP

Which EIGRP routes will appear in r3’s (RIP) routing table?

Click here for the answer.


Yesterday’s Question

 Question Of The Day: 25 March, 2008 

Topic: EIGRP

Which of the following commands will make EIGRP AS 100 consider delay only when calculating the EIGRP metric?

1) router eigrp 100
    default metric 1 1 0 1 1500

2) router eigrp 100
    metric weights 0 1 0 0 0 0    

3) router eigrp 100
    metric weights 0 0 1 0 0 0

4) router eigrp 100
    metric weights 0 0 0 1 0 0

Answer:

4) router eigrp 100
    metric weights 0 0 0 1 0 0


metric weights (EIGRP)

metric weights tos k1 k2 k3 k4 k5

The first value is ‘tos’ (Type of Service) and is always zero.  The remaining five values are the EIGRP ‘k-values’.

If k5 equals 0, the composite EIGRP metric is computed according to the following formula:

metric = [k1 * bandwidth + (k2 * bandwidth)/(256 – load) + k3 * delay]

If k5 does not equal zero, an additional operation is performed:

metric = metric * [k5/(reliability + k4)]

The ‘trick’ is not assuming that the five k-values match up with the five EIGRP metrics:

default-metric (EIGRP)

default-metric bandwidth delay reliability loading mtu

The five EIGRP metrics (which I memorized with the mnemonic “Big Dogs Really Love Meat”) do NOT correspond to the k-values.  So don’t do what I did and use ‘metric weights 0 0 1 0 0 0’  🙂

March 9, 2008

Internetwork Expert Volume III: Lab 1 – Section 4

Interior Gateway Routing – 24 Points

4.1 OSPF over NBMA

Nothing new here.  Simple hub-and-spoke OSPF network.  You cannot change the default network type (NBMA on the physical interfaces) so just set the spokes to OSPF priority 0 and configure neighbor statements on the hub.

4.2 OSPF

Very simple OSPF task.  The only issue I ran across was an MTU mismatch between r2 and sw2: 

r2(config-router)#do sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.10.5.5        1   FULL/DR         00:01:34    140.10.245.5    Serial0/0
150.10.8.8        1   DOWN/DROTHER       –        140.10.28.8     FastEthernet0/0
*Jun 11 12:01:07.591: %OSPF-5-ADJCHG: Process 100, Nbr 150.10.8.8 on FastEthernet0/0 from DOWN to DOWN, Neighbor Down: Ignore timer expired

sw2(config-router)#do sh system mtu

System MTU size is 1504 bytes
System Jumbo MTU size is 1504 bytes
Routing MTU size is 1504 bytes

r2(config-router)#int fa0/0
r2(config-if)#ip os mtu-ignore

*Jun 11 12:01:57.753: %OSPF-5-ADJCHG: Process 100, Nbr 150.10.8.8 on FastEtherne
t0/0 from LOADING to FULL, Loading Done

r2(config-if)#do sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.10.5.5        1   FULL/DR         00:01:54    140.10.245.5    Serial0/0
150.10.8.8        1   FULL/DR         00:00:39    140.10.28.8     FastEthernet0/0

You can also change the system MTU back to 1500 bytes on sw2, but that requires a reload.

4.3 OSPF Stub Area

Easy OSPF stub network task.  There is no ambiguity over what type of OSPF stub to configure.

area stub

Before stub:

sw1(config-router)#do sh ip route os
     140.10.0.0/16 is variably subnetted, 6 subnets, 2 masks
O IA    140.10.0.128/25 [110/68] via 140.10.57.5, 00:00:13, FastEthernet0/21
O IA    140.10.245.0/24 [110/65] via 140.10.57.5, 00:00:13, FastEthernet0/21
O IA    140.10.0.0/25 [110/67] via 140.10.57.5, 00:00:13, FastEthernet0/21
O IA    140.10.28.0/24 [110/66] via 140.10.57.5, 00:00:13, FastEthernet0/21
O IA    140.10.100.0/24 [110/11] via 140.10.57.5, 00:00:13, FastEthernet0/21

After stub:

sw1#sh ip route os
     140.10.0.0/16 is variably subnetted, 6 subnets, 2 masks
O IA    140.10.0.128/25 [110/68] via 140.10.57.5, 00:00:04, FastEthernet0/21
O IA    140.10.245.0/24 [110/65] via 140.10.57.5, 00:00:04, FastEthernet0/21
O IA    140.10.0.0/25 [110/67] via 140.10.57.5, 00:00:04, FastEthernet0/21
O IA    140.10.28.0/24 [110/66] via 140.10.57.5, 00:00:04, FastEthernet0/21
O IA    140.10.100.0/24 [110/11] via 140.10.57.5, 00:00:04, FastEthernet0/21
O*IA 0.0.0.0/0 [110/2] via 140.10.57.5, 00:00:04, FastEthernet0/21

4.4 OSPF

Another easy task.  You need to advertise some loopbacks, but the network mask should be /24 not /32.  You’ll need to change the OSPF network type on the loopbacks to point-to-point to accomplish this.  You should see all the loop nets on r5:

r5#sh ip route os | i 150.
     150.10.0.0/24 is subnetted, 9 subnets
O IA    150.10.8.0 [110/66] via 140.10.245.2, 00:01:02, Serial0/0
O IA    150.10.9.0 [110/67] via 140.10.245.2, 00:00:34, Serial0/0
O IA    150.10.10.0 [110/68] via 140.10.245.2, 00:00:18, Serial0/0
O       150.10.4.0 [110/65] via 140.10.245.4, 00:02:31, Serial0/0
O       150.10.6.0 [110/11] via 140.10.100.6, 00:02:57, Ethernet0/0
O       150.10.7.0 [110/11] via 140.10.57.7, 00:01:55, Ethernet0/1
O IA    150.10.2.0 [110/65] via 140.10.245.2, 00:01:22, Serial0/0
O       150.10.3.0 [110/11] via 140.10.100.3, 00:02:57, Ethernet0/0

r5#sh ip route 150.10.10.10
Routing entry for 150.10.10.0/24

4.5 RIP

Very easy RIP configuration.  Just remember to use passive interfaces on devices that have multiple interfaces in the same classful network: 

r4#sh ip int br | e ass
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            140.1.14.4      YES NVRAM  up                    up
Serial0/0                  140.1.245.4     YES NVRAM  up                    up
Serial0/1                  140.1.45.4      YES NVRAM  up                    up
Loopback0                  150.1.4.4       YES NVRAM  up                    up

r4#sh run | sec router rip
router rip
 version 2
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface Serial0/1

 network 140.1.0.0
 no auto-summary

r4#sh ip proto | sec rip
    rip, includes subnets in redistribution
Routing Protocol is “rip”
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 18 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: ospf 100, rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       2     2
    Serial0/1             2     2

  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    140.1.0.0
  Passive Interface(s):
    Serial0/0
    FastEthernet0/1
    Loopback0
    VoIP-Null0

  Routing Information Sources:
    Gateway         Distance      Last Update
    140.1.14.1           120      00:00:14
    Gateway         Distance      Last Update
    140.1.45.5           120      00:00:14
  Distance: (default is 120)  

4.6 RIP

You’ll need to use an offset-list to make the metric (hop count) of 150.1.1.0 on r4 equal 10.  Remember this as it will come back in the redistribution scenario.

4.7 Redistribution

I wish all redistribution were this easy.  You simply need to set the metric-type to type-1 in your route-map and redistribute some connected networks into OSPF.

4.8 Advanced Redistribution

You need to do mutual redistribution between RIP and OSPF on three routers.  As with most of the Volume III labs, you can complete this task with the knowledge that any redistribution issues will most likely be the focus of the next task.

4.9 Advanced Redistribution

“Ensure that reachability to r1’s loopback 0 interface is maintained.”

Before redistribution:

r5(config-route-map)#do sh ip route rip | i 150
     150.1.0.0/24 is subnetted, 10 subnets
      150.1.1.0 [120/11] via 140.1.45.4, 00:00:19, Serial0/1

r4(config-route-map)#do sh ip route rip | i 150.
     150.1.0.0/24 is subnetted, 10 subnets
R       150.1.1.0 [120/10] via 140.1.14.1, 00:00:21, Ethernet0/0

r1’s lo0 interface is advertised to r4 via RIP with a metric of 10 (we changed the metric in task 4.6).  r4 advertises that route to r5 via the point-to-point serial connection.  r5 adds the route to its routing table with a metric of 11. 

After redistribution:

r4#sh ip route rip  <-no RIP routes on r4

r4#

r4#sh ip route 150.1.1.0
Routing entry for 150.1.1.0/24
  Known via “ospf 100“, distance 110, metric 20
  Tag 5120, type extern 2, forward metric 64 
  Redistributing via rip
  Advertised by rip metric 1 route-map OSPF->RIP
  Last update from 140.1.245.5 on Serial0/0, 00:00:18 ago
  Routing Descriptor Blocks:
  * 140.1.245.5, from 150.1.5.5, 00:00:18 ago, via Serial0/0
      Route metric is 20, traffic share count is 1
      Route tag 5120 <-5120 = RIP route redistributed on r5

r5#sh ip route rip | sec 150.1.1.0
     150.1.0.0/24 is subnetted, 10 subnets
R       150.1.1.0 [120/1] via 140.1.45.4, 00:00:04, Serial0/1

r5#sh ip route 150.1.1.0
Routing entry for 150.10.1.0/24
  Known via “rip”, distance 120, metric 1
  Tag 4110 <-5120 = RIP route redistributed on r5
  Redistributing via ospf 100, rip
  Advertised by ospf 100 subnets route-map RIP->OSPF
  Last update from 140.1.45.4 on Serial0/1, 00:00:11 ago
  Routing Descriptor Blocks:
  * 140.1.45.4, from 140.1.45.4, 00:00:11 ago, via Serial0/1
      Route metric is 1, traffic share count is 1
      Route tag 4110

Once we do mutual redistribution on r4 and r5, we end up with a routing loop for the 150.1.1.0/24 network:

sw2#trace 150.1.1.1

Type escape sequence to abort.
Tracing the route to 150.1.1.1

  1 140.1.28.2 9 msec 0 msec 0 msec
  2 140.1.245.525 msec 33 msec 26 msec
  3 140.1.45.450 msec 50 msec 51 msec
  4 140.1.245.541 msec 51 msec 42 msec
  5 140.1.45.4 67 msec 59 msec 59 msec
  6 140.1.245.5 58 msec 59 msec 59 msec
  7 140.1.45.4 84 msec 75 msec 75 msec
  8 140.1.245.5 76 msec 75 msec 76 msec
  9 140.1.45.4 92 msec 92 msec 11 msec
 1 140.1.245.5 84 msec 92 msec 84 msec
 11 140.1.45.4 19 msec 19 msec 19 msec
 12 140.1.245.5 19 msec 11 msec 19 msec
 13 140.1.45.4 118 msec 134 msec 117 msec
 14 140.1.245.5 117 msec 118 msec 117 msec
 15 140.1.45.4 143 msec 134 msec 142 msec
 16 140.1.245.5 135 msec 134 msec 134 msec
 17 140.1.45.4 151 msec 159 msec 151 msec
 18 140.1.245.5 151 msec 151 msec 143 msec
 19 140.1.45.4 176 msec 168 msec 168 msec
 20 140.1.245.5 167 msec 160 msec 168 msec
 21 140.1.45.4 184 msec 185 msec 184 msec
 22 140.1.245.5 176 msec 177 msec 184 msec
 23 140.1.45.4 201 msec 202 msec 201 msec
 24 140.1.245.5 193 msec 193 msec 193 msec
 25 140.1.45.4 218 msec 21 msec 218 msec
 26 140.1.245.5 21 msec 209 msec 21 msec
 27 140.1.45.4 227 msec 234 msec 227 msec
 28 140.1.245.5 226 msec 227 msec 218 msec
 29 140.1.45.4 243 msec 252 msec 243 msec
 30 140.1.245.5 235 msec 243 msec 235 msec

So initially we have:

r4 – R [120/10] from r1 via fa0/0
r5 – R [120/11] from r4 via s0/1

r4 and r5 will each redistribute their RIP routes for 150.1.1.0/24 into OSPF.  That means that r4 and r5 will hear about the 150.1.1.0/24 route from each other via OSPF.  Since OSPF has a lower metric, those routes will be installed:

r4 – R [110/20] from r5 via s0/0
r5 – R [110/20] from r4 via s0/0

This gets even uglier because the RIP route on r4 will is replaced by the OSPF route.  Now the RIP route is no longer advertised to r5 via RIP from r4 nor is it redistributed into OSPF on r4 or r5.  So the route should disappear only to reappear again once the original RIP route is restored to r4’s routing table…which will start the whole process over again.  So we should have a “blinking route”, right?

Not really.  To add to this mindfuck, we need to consider that OSPF is being redistributed into RIP.  I did this with a seed metric of 1.  So the OSPF route to 150.1.1.0/24 advertised to r4 and then redistributed into RIP has a better (lower) metric than 10, so it will be installed instead of the original RIP route with a metric of 10.  Does your head hurt yet?

Here’s how it breaks down:

1) r4 gets RIP route from r1 [120/10] and advertises it to r5 [120/11] via RIP.
2) r4 and r5 redistribute the route into OSPF.  Each installs this route (pointing to each other) in their routing tables based on a lower AD (110 vs 120).
3) These OSPF routes are redistributed into RIP as well [120/1] (note that the metric is better than our original RIP routes) but are not installed on r4 or r5 because the OSPF routes have a lower AD.
4) The original RIP route is removed from r4’s routing table.  This means that neither r4 nor r5 can advertise it into OSPF so the 150.1.1.0/24 route should drop from OSPF.
5) The original RIP route on r4 [120/10] reappears and the whole process begins again…OR due to the slow RIP route removal process, the OSPF route from r5 gets redistributed into RIP on r4 and is installed because of the lower metric (1 vs 10).  Either way, we end up with either a “blinking loop” or a “stable loop.

To stop this we need to make sure that the 150.1.1.0/24 network is not redistributed back into RIP on r5.  This means that we’ll route over the Frame cloud to reach 150.1.1.1 on r5 instead of the serial link, but we won’t get a loop.

I filtered r1 lo0 from getting redistributed into from OSPF back into RIP on r5:

router ospf 100
 redistribute ospf 100 metric 1 route-map OSPF->RIP
!
access-list 69 deny   150.1.1.0
access-list 69 permit any
!
route-map OSPF->RIP permit 10
 match ip address 69
 set tag 5110

sw2#p 150.1.1.1

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

sw2#trace 150.1.1.1

Type escape sequence to abort.
Tracing the route to 150.1.1.1

  1 140.1.28.2 0 msec 0 msec 8 msec
  2 140.1.245.525 msec 25 msec 34 msec
  3 140.1.245.450 msec 50 msec 59 msec
  4 140.1.14.150 msec *  59 msec

Whew!!!

January 27, 2008

Internetwork Expert Volume III: Lab 4 – Section 4

Interior Gateway Routing – 27 Points

4.1 Bridging

“Disable ip routing on r6”

r6(config)#no ip routing

“Bridge IP between the Frame Relay and Ethernet segments on r6”

That explains why fa0/0 does not have an IP address configured. 🙂

After this task, I can finally ping bb1:

r6#p 54.1.10.254

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

4.2 Bridging

This task confused the crap out of me.  My bridging skills are pretty poor.

“Configure the IP address of 54.1.10.6/24 on r6.”

Ummmm….that’s already configured as the IP address of the Frame connection to bb1.  I guess that we’re going to use the same IP address for fa0/0 as well.

“r6 should have reachability to any address of the 54.1.10.0/24 subnet.”
“Don’t use IRB for this task.”

No IRB.  CRB?  Actually, the IE solution doesn’t use IRB or CRB.  The last two subtasks are basically red herrings.  I will need to review bridging.

r6#sh bridge 1 group

Bridge Group 1 is running the IEEE compatible Spanning Tree protocol

   Port 4 (FastEthernet0/0) of bridge group 1 is forwarding
   Port 11 (Serial0/0.1 Frame Relay) of bridge group 1 is forwarding

r6#sh ip int br | i 54.1.10.6
FastEthernet0/0            54.1.10.6       YES manual up                    up
Serial0/0.1                54.1.10.6       YES manual up                    up

r6#p 54.1.10.254

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

r6#p 54.1.10.100

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

I can’t ping r4 but I can ping bb1.  This poster has the opposite problem:

Task 4.2 can not ping 54.1.10.254

r6#sh cdp neigh
Capability Codes: R – Router, T – Trans Bridge, B – Source Route Bridge
                  S – Switch, H – Host, I – IGMP, r – Repeater

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
BB1              Ser 0/0.1          147       R T S I     2821      Ser 0/0/0:0.401
sw2              Fas 0/0            174         S I       WS-C3560- Fas 0/6
r6#

sw2#sh run int fa0/6
interface FastEthernet0/6 <-that’s a minimal configuration 🙂
end

How did I miss this?????  Because the port on r6 was initially shut down so I didn’t see it with “show cdp neighbor” on sw2.  Arrgh!!!  I need vlan 46 assigned to this port.

sw2(config)#int fa0/6
sw2(config-if)#swit acc vl 46

r6#p 54.1.10.100

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 54.1.10.100, timeout is 2 seconds:
!!!!!

I guess that I can take solace in the fact that I was able to find my mistake.  I just barely missed going down a deep rabbit hole chasing bridging options.

4.3 RIPv2

I initially thought that there was an error in the IE lab because although r6 was shown as running RIP on the protocol diagram, there was no mention of r6 in the task.  That’s because r6 is bridging the 54.1.10.0/24 network.  I turned off ip routing in task 4.1 so I wouldn’t be able to configure RIP on r6:

r6(config)#router rip
IP routing not enabled

This means that we should be able to see the routes from bb1(54.1.10.254) on r4:

r4#sh ip route rip | i 54.1.10.254
R    212.18.1.0/24 [120/1] via 54.1.10.254, 00:00:12, FastEthernet0/0
R    212.18.0.0/24 [120/1] via 54.1.10.254, 00:00:12, FastEthernet0/0
R    212.18.3.0/24 [120/1] via 54.1.10.254, 00:00:12, FastEthernet0/0
R    212.18.2.0/24 [120/1] via 54.1.10.254, 00:00:12, FastEthernet0/0

4.4 Network Redundancy

backup interface

Hmmmm….this is the reason for the point-to-point subinterface on r4 back in task 3.2

r4#sh ip int br | i Serial
Serial0/0                  unassigned      YES NVRAM  up                    up
Serial0/0.1                unassigned      YES unset  up                    up
Serial0/1                  152.1.54.4      YES NVRAM  standby mode          down

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

4.5 EIGRP

Basic.

4.6  OSPF

“Use the OSPF network type that was specifically designed to handle issues with routers on the same logical IP subnet not having direct communication with each other.”

Remember that we have a multipoint subinterface on the hub (r3) and point-to-point subinterfaces on the hubs (r1 and r2).  The task calls for the point-to-multipoint OSPF network type.

r3#sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.2.2         0   FULL/  –        00:01:49    152.1.123.2     Serial0/0:0.1
150.1.1.1         0   FULL/  –        00:01:54    152.1.123.1     Serial0/0:0.1

r3#sh ip route os
     152.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
O       152.1.123.2/32 [110/65] via 152.1.123.2, 00:00:07, Serial0/0:0.1
O       152.1.123.1/32 [110/65] via 152.1.123.1, 00:00:07, Serial0/0:0.1

4.7 OSPF

Basic

4.8 OSPF

In this task you need to advertise the loopbacks on r1 and r2 into area 0.  But r1 and r2 are not in area 0.  Time for a couple of virtual circuits.

4.9 OSPF Loopback Advertisement

“Advertise the Loopback0 networks of r3 and sw1 into OSPF.”
“These networks should appear in each other routing tables as intra-area routes.”

Since I’m not told which area to advertise the loopbacks into, can’t I just make this simple by advertising both loopbacks into area 37?  Answer: YES!

sw1#sh ip route | i 150.1.3.
O       150.1.3.3/32 [110/2] via 152.1.37.3, 00:00:37, Vlan37

r3#sh ip route | i 150.1.7.
O       150.1.7.7/32 [110/2] via 152.1.37.7, 00:00:00, FastEthernet0/0

4.10 IGP Redistribution

Four points of mutual redistribution.  Ugh.  The first two points are no worry (discontiguous RIP).  The other two are dangerous though.  I’ll work on those in task 4.11

4.11 Redistribution Loop Prevention

“Ensure that EIGRP extenal routes that are redistributed into OSPF on r1 and r2 do not get redistributed back into EIGRP.”
“Use AD to accomplish this.”

Here is a (simplified) view of the the two network redistribution points on r1 and r2:
                         ————(D)r1(O)———–
r4(R<->D)—r5(D)                                     (O)r3—(O<->R)sw1
                         ————(D)r2(O)———–
If we do mutual redistribution between EIGRP and OSPF on r1 and r2 we’re going to have problems with D EX routes (AD of 170) being reflected back into the EIGRP domain.  We’re given the method for preventing this.

I missed an issue on sw1 though:

Task 4.11 Redist Loop Prevention

You need to change the RIP distance or SW1 sees the routes learnt from BB3 as OSPF external routes which it uses over the correct RIP routes. if you check the routing table on SW1, the next hop for all the BB3 subnets is R3. This is resolved by changing the AD [router rip – distance 109].

January 17, 2008

Internetwork Expert Volume III: Lab 2 – Section 4

Interior Gateway Routing – 27 Points

4.1 RIPv2

The IE solution confused me at first.  Why did they configure “neighbor (RIP)” statements on both routers?  The answer came when I noticed that they had not configured “no passive-interface” for the serial links.  A subtask read:

“Use the passive-interface default” command on both r1 and r2.”

I didn’t read that to mean that you could not use “no passive-interface” on any interfaces. 

Here’s why you need to the neighbor command:

Without neighbor:

r1(config-router)#do sh run | sec router rip
router rip
 version 2
 redistribute connected metric 1 route-map CONN->RIP
 passive-interface default
 network 161.1.0.0
 no auto-summary

r2(config-router)#do sh run | sec router rip
router rip
 version 2
 redistribute connected metric 1 route-map CONN->RIP
 passive-interface default
 network 161.1.0.0
 no auto-summary

r1(config-router)#do sh ip route rip

r1(config-router)#

All of the interfaces are passive.  In RIP, a passive-interface means that you cannot send any routing updates on that interface.  In this case, we’re not sending any RIP routing updates because all of the interfaces are passive.  The easy way (the way I did it) is to simply take the interfaces between r1 and r2 out of passive.  If this is prohibited, then use the RIP neighbor statement.

neighbor (RIP)

With neighbor:

r1#sh run | sec router rip
router rip
 version 2
 redistribute connected metric 1 route-map CONN->RIP
 passive-interface default
 network 161.1.0.0
 neighbor 161.1.12.1
 no auto-summary

r2#sh run | sec router rip
router rip
 version 2
 redistribute connected metric 1 route-map CONN->RIP
 passive-interface default
 network 161.1.0.0
 neighbor 161.1.12.1
 no auto-summary

r1#sh ip route rip
     161.1.0.0/24 is subnetted, 3 subnets
R       161.1.23.0 [120/1] via 161.1.12.2, 00:00:02, Serial0/0/0
     150.1.0.0/24 is subnetted, 2 subnets
R       150.1.2.0 [120/1] via 161.1.12.2, 00:00:02, Serial0/0/0

4.2 OSPF

Simple redistribution of loopbacks using route-maps.

4.3 OSPF

“Do not change the default OSPF network type of non-broadcast.”

r3#sh ip os int s0/0/0 | i Type|Hello
  Process ID 100, Router ID 150.1.3.3, Network Type NON_BROADCAST, Cost: 64
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
    Hello due in 00:00:26

r4#sh ip os int Serial0/0/0.403 |  i Type|Hello
  Process ID 100, Router ID 150.1.4.4, Network Type POINT_TO_POINT, Cost: 64
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:09

This is another “interpretation” question.  The task says nothing about changing the default OPSF type of Point-To-Point on r4.  🙂  Make sure that you configure a neighbor statement on r4 as well so your updates are unicast.

Don’t go down the rabbit hole of changing the OSPF hello intervals.  You’ll get an adjacency but no LSAs (because non-broadcast needs a DR and ptp does not).

r4(config)#router os 100
r4(config-router)#net 150.1.4.4 0.0.0.0 ar ea 0  <- to check routes on r3

r3(config)#int s0/0/0
r3(config-if)#ip os hello 10
r3(config-if)#^Z

r3#sh ip os neigh

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.4.4         1   FULL/BDR        00:00:39    161.1.34.4      Serial0/0/0

r3#sh ip route os

r3#

4.4 OSPF

Easy task.  I ran into an MTU issue.  Good practice for the lab: 

r5#sh ip os neigh

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.4.4         0   FULL/  –        00:00:36    161.1.45.4      Serial0/0/0
150.1.8.8         1   DOWN/DROTHER       –        161.1.5.9       FastEthernet0/0

*Jan 16 20:55:12.254: %OSPF-5-ADJCHG: Process 100, Nbr 150.1.8.8 on FastEthernet0/0 from DOWN to DOWN, Neighbor Down: Ignore timer expired

r5#sh int fa0/0 | i MTU
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

sw2#sh system mtu
System MTU size is 1500 bytes
System Jumbo MTU size is 1504 bytes
Routing MTU size is 1500 bytes

r5(config-router)#int fa0/0
r5(config-if)#ip ospf ?

  mtu-ignore           Ignores the MTU in DBD packets

r5(config-if)#ip ospf mtu-ignore

r5#sh ip os neigh

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.4.4         0   FULL/  –        00:00:32    161.1.45.4      Serial0/0/0
150.1.8.8         1   FULL/DR         00:00:35    161.1.5.9       FastEthernet0/0

4.5 OSPF

Advertise in loopbacks but do not associate with an area.   Use redistribution of connected interfaces with a route-map. 

Speed Tip: You can use the same commands on each device- just cut and paste (I did change the tag on each device though):

route-map CONN->OSPF permit 10
 description Task 4.5
 match interface Loopback0
 set tag 31
!
router ospf 100
redistribute connected subnets route-map CONN->OSPF

4.6 OSPF

Easy task with summaries.  Task gives you the actual summaries to advertise, so no binary!!  🙂

You will need when and why to use area range versus summary-address.

area range

summary-address (OSPF)

4.7 OSPF Redistribution

Advertise vlan 43 on r4.  Do not use network statement.

We’re already redistributing connected, so let’s just add int fa0/0 to that existing route-map:

r4(config-router)#do sh run | sec route-map CONN->OSPF
route-map CONN->OSPF permit 10
 description Task 4.5
 match interface Loopback0
 set tag 41
r4(config-router)#route-map CONN->OSPF permit 10
r4(config-route-map)#match int fa0/0
r4(config-route-map)#do sh run | sec route-map CONN->OSPF
route-map CONN->OSPF permit 10
 description Task 4.5
 match interface Loopback0 FastEthernet0/0
 set tag 41

4.8 EIGRP

Very basic EIGRP configuration. 

4.9 EIGRP Redistribution

You’re asked to redistribute in some loopbacks.  This task will affect your IGP redistribution.

Speed Tip: Reuse commands to save time (I do alter the tags on each device):

redist conn route-map CONN->EIGRP met 1 1 1 1 1
route-map CONN->EIGRP permit 10
 description task 4.9
 match interface Loopback0
 set tag 61

4.10 IGP Redistribution

The BEAST!!!!  Actually in this lab they tell you what to do, so redistribution is not that difficult.

“Perform mutual redistribution between RIP and OSPF on r2”
“Perform mutual redistribution between OSPF and EIGRP on r4 and r5”

r2
RIP 120 -> OSPF 110
OSPF 110 -> RIP 120

I don’t see any issues on this redistribution because it’s isolated.  We don’t have any RIP routes in the routing table:

r2#sh ip route rip

r2#

The only thing we need to note is that we are already redisting lo0 into RIP:

r2#sh run | sec router rip
router rip
 version 2
 redistribute connected metric 1 route-map CONN->RIP
 passive-interface default
 network 161.1.0.0
 neighbor 161.1.12.1
 no auto-summary

route-map CONN->RIP permit 10
 description Task 4.2 lo0 to rip Tag 21
 match interface Loopback0
 set tag 11

r4 and r5

Our worry here are EIGRP routes redist on one router and then redist back into EIGRP on the other router.

r6’s loopback for instance

r5 learns it via EIGRP (90) from sw2
r5 redistributes it into OSPF (110)
r4 learns it from OSPF (110) and from EIGRP (90)

No problems….right?

Actually….we redistributed that interface into EIGRP in the last task so:

r5(config)#do sh ip route 150.1.6.6
Routing entry for 150.1.6.0/24
  Known via “eigrp 10”, distance 170, metric 2560007936
  Tag 61, type external
  Redistributing via eigrp 10
  Last update from 161.1.58.8 on FastEthernet0/1, 01:23:20 ago
  Routing Descriptor Blocks:
  * 161.1.58.8, from 161.1.58.8, 01:23:20 ago, via FastEthernet0/1
      Route metric is 2560007936, traffic share count is 1
      Total delay is 310 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 3
      Route tag 61

r5 learns it via EIGRP (170) from sw2
r5 redists it into OSPF (110)
r4 learns it from OSPF (110) and from EIGRP (170)

r4 is going to send traffic for 150.1.6.6 to r5 via frame (ospf)
r5 will send traffic for 150.1.6.6 to r4

Crap!  We need to make sure that the OSPF AD for those routes is greater than 170.  Which is precisely what we’ll do in the next task.

4.11 Redistribution Loop Prevention

This task was a bit of a bummer because it points out exactly what the problems with mutual redistribution are and how to fix them.

distance

January 16, 2008

Internetwork Expert Blog: Redistribution In IPv6

A very good post concerning the differences between route redistribution in IPv4 and IPv6:

In current IOS versions for IPv4 redistribution is a two step process. Let’s suppose that we are trying to redistribute RIPv2 into OSPFv2 by issuing the “redistribute rip subnets” command under the OSPF process. The first thing the router does is to look at the “show ip route rip” output. All of these prefixes are candidate to be redistributed into OSPF. Next the router looks at the “show ip route connected” output. The routes for any connected interfaces from this output running RIPv2 are also candidate to be redistributed into OSPF. In other words, we don’t have to issue the “redistribute connected subnets” to get connected interfaces that run RIP to be sent into the OSPF process.

For IPv6 whether or not connected links are included in redistribution is up to you at the time of configuration.

—Read the rest here—

November 24, 2007

CCIE Candidate Blog: Lab Strategy

Ethan Banks recently shared out his current (open to revision going forward) lab strategy.   He has developed some very good ideas for how to tackle labs.  I highly encourage you to check it out. 

Here’s an example:

Reading the entire lab and making those diagrams takes me about 30 – 40 minutes. At first, it scared me to take that much time up without writing a line of IOS code. However, I am convinced that doing this work up front greatly reduces errors down the road. Early on doing these practice scenarios, I made the mistake of immediately hammering away at task number 1, only to find out later that I had to rip it out because of the requirements of a different task, or to discover that I could have saved myself a bunch of time by combining a couple of tasks.

Also check out his strategy for diagramming route-redistribution.

November 21, 2007

Internetwork Expert: Free Route Redistribution vSeminar Recording

That was fast!  I think that the folks at Internetwork Experts are wrapping up the loose ends so they can get their turkey on.  🙂 

The IE crew has posted the Route Redistribution Demystified vSeminar recorded earlier today.  As I stated before, this one is definitely worth your time if you are struggling with route redistribution.

Next Page »

Create a free website or blog at WordPress.com.