CCIE Pursuit Blog

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!!!

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: