CCIE Pursuit Blog

January 13, 2008

Internetwork Expert Volume II: Lab 4 – Section 4

Section 4 – Interior Gateway Routing – 24 Points

4.1 OSPF

Easy Hub-and-Spoke OSPF network. You aren’t allowed to change the OSPF network type on r2(hub).  You can change the network type on the spokes though.

r2#sh ip os int | i Type
  Process ID 100, Router ID 150.1.2.2, Network Type NON_BROADCAST, Cost: 64
r1#sh ip os int | i Type
  Process ID 100, Router ID 150.1.1.1, Network Type POINT_TO_POINT, Cost: 65
r3#sh ip os int | i Type
  Process ID 100, Router ID 150.1.3.3, Network Type POINT_TO_POINT, Cost: 65

Change the network type on the spokes to match the hub and use neighbor statements on the hub.  Remember to configure “ip ospf priority 0” on the spokes so that the hub is elected as the DR.

4.2 OSPF

“…configure r1 so that the only recipient of its hello packets is bb2.”

Sounds like another job for the “neighbor command”:

r1(config)#router os 100
r1(config-router)#net 192.10.1.1 0.0.0.0 are 51
r1(config-router)#neighbor 192.10.1.254
OSPF: Neighbor command is allowed only on NBMA and point-to-multipoint networks
 

r1(config-if)#do sh ip os int fa0/0 | i Type|Hello
  Process ID 100, Router ID 150.1.1.1, Network Type BROADCAST, Cost: 1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

r1(config-if)#int fa0/0
r1(config-if)#ip os net non-broadcast

Remember to change the hello interval (the neighbor is going to have a hello interval of 10 because that’s the default for Broadcast)

r1(config-if)#do sh ip os int fa0/0 | i Type|Hello
  Process ID 100, Router ID 150.1.1.1, Network Type NON_BROADCAST, Cost: 1
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
    Hello due in 00:00:03

r1(config-if)#ip os hello 10

r1(config-if)#do sh ip os int fa0/0 | i Type|Hello
  Process ID 100, Router ID 150.1.1.1, Network Type NON_BROADCAST, Cost: 1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:03

r1(config-if)#do sh ip os neigh

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.2.2         1   FULL/DR         00:01:32    141.1.123.2     Serial0/0.1
192.10.1.254      1   FULL/DR         00:00:30    192.10.1.254    FastEthernet0/0

r1(config-if)#do sh ip route os
     51.0.0.0/32 is subnetted, 1 subnets
O E2    51.51.51.51 [110/20] via 192.10.1.254, 00:02:08, FastEthernet0/0

There is an excellent breakdown for this task in the IE solution guide.

4.3 OSPF

“sw3 and sw4 should use sw2 as their default-gateway.”

sw3(config)#do sh ip int br | e ass
Interface              IP-Address      OK? Method Status                Protocol
Vlan255                141.1.255.9     YES manual up                    up

sw4(config)#do sh ip int br | e ass
Interface              IP-Address      OK? Method Status                Protocol
Vlan255                141.1.255.10    YES manual up                    up

sw2(config-router)#do sh ip int br | i Vlan255
Vlan255                141.1.255.8     YES manual up                    up

Use 141.1.255.8 as the default-gateway,

sw3(config)#ip default-gateway ?
  A.B.C.D  IP address of default gateway

sw3(config)#ip default-gateway 141.1.255.8

sw3#p 141.1.255.8

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

sw3#sh ip route
Default gateway is 141.1.255.8

Host               Gateway           Last Use    Total Uses  Interface
ICMP redirect cache is empty

Weird.  I couldn’t find “ip default-gateway” in either the 3550 or 3560 command guide.

4.4 OSPF

“configure the network so that route in OSPF area 1 do not see any inter-area or external OSPF routes.”

area nssa

Configuring OSPF NSSA

NSSAs

With the no-summary keyword, the NSSA ABR will not advertise the inter-area routes (Type 3 and Type 4 summary routes) inside the NSSA, instead will advertise a default route. This default route will be propagated inside the NSSA as Type 3 LSA.

Before:
sw2#sh ip route os
     51.0.0.0/32 is subnetted, 1 subnets
O E2    51.51.51.51 [110/20] via 141.1.0.2, 13:05:22, Vlan258
     141.1.0.0/24 is subnetted, 5 subnets
O IA    141.1.123.0 [110/65] via 141.1.0.2, 13:05:22, Vlan258
O IA 192.10.1.0/24 [110/66] via 141.1.0.2, 13:05:22, Vlan258
     150.1.0.0/16 is variably subnetted, 4 subnets, 2 masks
O IA    150.1.3.3/32 [110/66] via 141.1.0.2, 13:05:22, Vlan258
O IA    150.1.2.2/32 [110/2] via 141.1.0.2, 13:05:22, Vlan258
O IA    150.1.1.1/32 [110/66] via 141.1.0.2, 13:05:22, Vlan258

area nssa only:
sw2#sh ip route os
     141.1.0.0/24 is subnetted, 5 subnets
O IA    141.1.123.0 [110/65] via 141.1.0.2, 00:00:18, Vlan258
O IA 192.10.1.0/24 [110/66] via 141.1.0.2, 00:00:18, Vlan258
     150.1.0.0/16 is variably subnetted, 4 subnets, 2 masks
O IA    150.1.3.3/32 [110/66] via 141.1.0.2, 00:00:18, Vlan258
O IA    150.1.2.2/32 [110/2] via 141.1.0.2, 00:00:18, Vlan258
O IA    150.1.1.1/32 [110/66] via 141.1.0.2, 00:00:18, Vlan258

I’m still seeing inter-area routes.  Let’t try:

area nssa no-summary
 (Optional) Allows an area to be a not-so-stubby area but not have summary routes injected into it.

area nssa no-summary (configured on ASRs only):
sw2#sh ip route os
O*IA 0.0.0.0/0 [110/2] via 141.1.0.2, 00:00:05, Vlan258

Remember the loopback that we redistributed into OSPF on sw2 (area 1)?  It shows up on the ASRs as an N1 route:

r2#sh ip route | i 150.1.8.0
O N2    150.1.8.0/24 [110/20] via 141.1.0.8, 00:11:09, GigabitEthernet0/0

r5#sh ip route | i 150.1.8.0
O N2    150.1.8.0 [110/20] via 141.1.0.8, 00:13:57, FastEthernet0/1

It will show up as an E2 route in area 0:
r3#sh ip route | i 150.1.8.0
O E2    150.1.8.0/24 [110/20] via 141.1.123.2, 00:18:12, Serial0/0:0.1

4.5 OSPF

“Configure OSPF area 2 on the Ethernet, Frame Relay, and PPP segments between r4 and r5.”
“Advertise the Loopback0 interfaces of r4 and r5 into OSPF area 2.”
“You are allowed to add one additional IP subnet to accomplish this.”

That last subtask had me confused.  Area 2 will be configured on three separate links between r4 and r5.  Further complicating issues is that that area 2 has no connection to area 0.  I’ll need to configure a virtual-link across area 1.

The first issue is getting the peering up over the FR link.  I changed the OSPF network type from non-broadcast to point-to-point on each side of the link to accomplish this.

Once the peerings were established, I advertised in the loopbacks on r4 and r5.  At this point the only OSPF route that r4 could see was r5’s loopback:

r4#sh ip route os
     150.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
O       150.1.5.5/32 [110/2] via 141.1.145.5, 00:00:05, FastEthernet0/0

Time to establish the virtual-link.  Is this where the additional subnet will come into play?  Will there be a problem because area 1 is a NSSA Totally Stub Area?

Well, here’s one problem:

r5#sh ip route 141.1.123.2
% Subnet not in table

My virtual-link is not going to work if I don’t have connectivity to area 0. 

Even if I did have connectivity, I cannot build a virtual-link through a stub area:

Creating Virtual Links

Note that virtual links cannot be configured through stub areas.

I think that giving me a subnet means that I can use it to set up a tunnel through area 1. 

tunnel

Since we’re going to tunnel from r5 to r2, let’s use 141.1.25.0/24.

r5
interface Tunnel25
 description ->tunnel to r2 (area2 to area0)
 ip address 141.1.25.5 255.255.255.0
 tunnel source FastEthernet0/1
 tunnel destination 141.1.25.2

r2
interface Tunnel25
 description ->tunnel to r5 (area0 to area2)
 ip address 141.1.25.2 255.255.255.0
 tunnel source GigabitEthernet0/0
 tunnel destination 141.1.25.5

One last thing.  I need to advertise the tunnel interfaces into OSPF.  This is where I boned up.  I initially advertised r5’s tunnel interface into area 2.  Doh!!!  It needs to be in area 0.  I fixed that and everything looked great until:

*Mar  1 22:13:16.319: %TUN-5-RECURDOWN: Tunnel25 temporarily disabled due to recursive routing

Crap!  I need to change my tunnel destination addresses.  I make this mistake so often when configuring tunnels.  😦

r5#sh run int tu25
interface Tunnel25
 description ->tunnel to r2 (area2 to area0)
 ip address 141.1.25.5 255.255.255.0
 tunnel source FastEthernet0/1
 tunnel destination 141.1.0.2

r2#sh run int tu25
interface Tunnel25
 description ->tunnel to r5 (area0 to area2)
 ip address 141.1.25.2 255.255.255.0
 tunnel source GigabitEthernet0/0
 tunnel destination 141.1.0.5

Now the peering is up:

r5#sh ip os neigh | i 150.1.2.2
150.1.2.2         0   FULL/  –        00:00:34    141.1.25.2      Tunnel25
150.1.2.2         1   FULL/DROTHER    00:00:38    141.1.0.2       Fa0/1

Let’s see if r4 is getting all of the OPSF routes now:

r4#sh ip route os
     51.0.0.0/32 is subnetted, 1 subnets
O E2    51.51.51.51 [110/20] via 141.1.145.5, 00:02:14, FastEthernet0/0
     141.1.0.0/16 is variably subnetted, 10 subnets, 2 masks
O IA    141.1.255.0/24 [110/3] via 141.1.145.5, 00:02:39, FastEthernet0/0
O IA    141.1.8.0/24 [110/3] via 141.1.145.5, 00:02:39, FastEthernet0/0
O IA    141.1.0.0/24 [110/2] via 141.1.145.5, 00:02:39, FastEthernet0/0
O IA    141.1.25.0/24 [110/11112] via 141.1.145.5, 00:02:39, FastEthernet0/0
O IA    141.1.88.0/24 [110/3] via 141.1.145.5, 00:02:39, FastEthernet0/0
O IA    141.1.123.0/24 [110/11176] via 141.1.145.5, 00:02:19, FastEthernet0/0
O IA 192.10.1.0/24 [110/11177] via 141.1.145.5, 00:02:19, FastEthernet0/0
     150.1.0.0/16 is variably subnetted, 6 subnets, 2 masks
O       150.1.5.5/32 [110/2] via 141.1.145.5, 00:02:39, FastEthernet0/0
O IA    150.1.3.3/32 [110/11177] via 141.1.145.5, 00:02:19, FastEthernet0/0
O IA    150.1.2.2/32 [110/11113] via 141.1.145.5, 00:02:19, FastEthernet0/0
O IA    150.1.1.1/32 [110/11177] via 141.1.145.5, 00:02:20, FastEthernet0/0
O E2    150.1.8.0/24 [110/20] via 141.1.145.5, 00:02:15, FastEthernet0/0

Nice!  It took me a while to struggle through this task, but I am pretty proud to have solved it on my own.

There is a nice breakdown in the solution guide.

4.6 OSPF

This task asks you to load balance over the Frame Relay and Ethernet segments between r4 and r5 without using ‘ip ospf cost’.

We are currently using the Ethernet segment between the routers:

r4#sh ip route 150.1.5.5
Routing entry for 150.1.5.5/32
  Known via “ospf 100”, distance 110, metric 2, type intra area
  Last update from 141.1.145.5 on FastEthernet0/0, 00:05:53 ago
  Routing Descriptor Blocks:
  * 141.1.145.5, from 150.1.5.5, 00:05:53 ago, via FastEthernet0/0
      Route metric is 2, traffic share count is 1

I can’t change the cost.  The cost is based on bandwidth, so what if I changed the bandwidth statement to match on the Frame Relay and Ethernet links?  I’ll set the bandwidth statement on s0/0 to 100000 to match fa0/0:

r4(config)#int s0/0
r4(config-if)#band 100000

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

r4#sh ip route 150.1.5.5
Routing entry for 150.1.5.5/32
  Known via “ospf 100”, distance 110, metric 2, type intra area
  Last update from 141.1.145.5 on FastEthernet0/0, 00:46:33 ago
  Routing Descriptor Blocks:
  * 141.1.145.5, from 150.1.5.5, 00:46:33 ago, via FastEthernet0/0
      Route metric is 2, traffic share count is 1
    141.1.54.5, from 150.1.5.5, 00:46:33 ago, via Serial0/0
      Route metric is 2, traffic share count is 1

Just need to do the same thing on r5.

4.7 OSPF

This task asks you to configure the PPP link between r4 and r5 to come up only if the Ethernet and Frame Relay connections are down.  You need to detect a failure within 10 seconds.

You have to read this task carefully.  It states that you need to “DETECT a failure of EITHER the Frame or Ethernet link WITHIN10 seconds”, but bring up the PPP link only if “BOTH the Frame and Ethernet segments are down.”

That second bit is normal behavior.  We have three links between r4 and r5, so if two of them go down then traffic will be routed over the PPP link.  When either of the other two links come back up, traffic will stop routing over the PPP link and use either/or both of the other links (better metric).

So it’s the “detect within 10 seconds” part that is the problem.

r5#sh ip os int s0/0 | i Type|Dead
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
r5#sh ip os int fa0/0 | i Type|Dead
  Process ID 100, Router ID 150.1.5.5, Network Type BROADCAST, Cost: 1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

We’ll need to change our dead timers to be less than 10 seconds.  The dead timer is 4x the Hello interval, so we’ll set our hello interval to 2 seconds on each side of the Frame and Ethernet links.

r5(config)#int fa0/0
r5(config-if)#ip os hello-interval ?
  <1-65535>  Seconds

r5(config-if)#ip os hello-interval 2
r5(config-if)#int s0/0
r5(config-if)#ip os hello-interval 2

r5#sh ip os int s0/0 | i Type|Dead
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 1
  Timer intervals configured, Hello 2, Dead 8, Wait 8, Retransmit 5
r5#sh ip os int fa0/0 | i Type|Dead
  Process ID 100, Router ID 150.1.5.5, Network Type BROADCAST, Cost: 1
  Timer intervals configured, Hello 2, Dead 8, Wait 8, Retransmit 5

Test:

r4#sh ip route 150.1.5.5
Routing entry for 150.1.5.5/32
  Known via “ospf 100”, distance 110, metric 2, type intra area
  Last update from 141.1.145.5 on FastEthernet0/0, 00:14:19 ago
  Routing Descriptor Blocks:
  * 141.1.145.5, from 150.1.5.5, 00:14:19 ago, via FastEthernet0/0
      Route metric is 2, traffic share count is 1
    141.1.54.5, from 150.1.5.5, 00:14:19 ago, via Serial0/0
      Route metric is 2, traffic share count is 1

r4(config)#int s0/0
r4(config-if)#shutdown
r4(config-if)#int fa0/0
r4(config-if)#shutdown

r4#sh ip route 150.1.5.5
Routing entry for 150.1.5.5/32
  Known via “ospf 100”, distance 110, metric 66, type intra area
  Last update from 141.1.45.5 on Serial0/1, 00:00:03 ago
  Routing Descriptor Blocks:
  * 141.1.45.5, from 150.1.5.5, 00:00:03 ago, via Serial0/1
      Route metric is 66, traffic share count is 1

4.8 RIP

Very basic RIP configuration.  The only “twist” is that you need to suppress RIP updates on some interfaces by using ‘passive-interface’.

“Enable RIP on all other interfaces of SW1” – make sure you advertise the 150.1.0.0 network

Routing Protocol is “rip”
  Sending updates every 30 seconds, next due in 18 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface                 Send  Recv  Triggered RIP  Key-chain
    Vlan7                     2     2
    Vlan77                    2     2
    FastEthernet0/3           2     2
    Loopback0                 2     2

  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    141.1.0.0
    150.1.0.0

4.9 RIP

“Routes learned from BB1 that have an even third octet should be seen with a metric of 10 on r6.”
“The access-list used to accomplish this should only have one line and should be effective for any additional networks learned from bb1 in the future.”

How do I compute complex wildcard masks for access-lists?

offset-list (RIP)

These are the routes that r6 is receiving from bb1:

r6#sh ip route rip | i 54.1.1.254
R    212.18.1.0/24 [120/1] via 54.1.1.254, 00:00:21, Serial0/0
R    212.18.0.0/24 [120/1] via 54.1.1.254, 00:00:21, Serial0/0
R    212.18.3.0/24 [120/1] via 54.1.1.254, 00:00:21, Serial0/0
R    212.18.2.0/24 [120/1] via 54.1.1.254, 00:00:21, Serial0/0

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.”

r6(config)#access-list 69 permit 0.0.0.0 255.255.254.255
r6(config)#router rip
r6(config-router)#offset-list 69 in 9 s0/0

r6#clear ip route *
r6#sh ip route rip | i 54.1.1.254
R    212.18.1.0/24 [120/1] via 54.1.1.254, 00:00:03, Serial0/0
R    212.18.0.0/24 [120/10] via 54.1.1.254, 00:00:03, Serial0/0
R    212.18.3.0/24 [120/1] via 54.1.1.254, 00:00:03, Serial0/0
R    212.18.2.0/24 [120/10] via 54.1.1.254, 00:00:03, Serial0/0

4.10 IGP Redistribution

Perform mutual redistribution on r3 and r4.  Well, the good news is that we’re only running RIP and OSPF. 🙂

I’ll start with r4:

r4(config)#route-map RIP->OSPF permit 10
r4(config-route-map)#desc Tag RIP with 4120
r4(config-route-map)#set tag 4120
r4(config-route-map)#router ospf 100
r4(config-router)#redist rip sub route-map RIP->OSPF

I should see the bb3 routes on r3 with a tag of 4120

r3#sh ip os data | i Tag|4120
Link ID         ADV Router      Age         Seq#       Checksum Tag
30.0.0.0        150.1.4.4       72          0x80000001 0x009B1F 4120
30.1.0.0        150.1.4.4       72          0x80000001 0x008F2A 4120
30.2.0.0        150.1.4.4       72          0x80000001 0x008335 4120
30.3.0.0        150.1.4.4       72          0x80000001 0x007740 4120
31.0.0.0        150.1.4.4       72          0x80000001 0x008E2B 4120
31.1.0.0        150.1.4.4       72          0x80000001 0x008236 4120
31.2.0.0        150.1.4.4       72          0x80000001 0x007641 4120
31.3.0.0        150.1.4.4       72          0x80000001 0x006A4C 4120
204.12.1.0      150.1.4.4       72          0x80000001 0x0021DD 4120

Sweet!

I shouldn’t have any problems on r4 so I’ll go ahead and redistribute OSPF into RIP:

r4(config)#route-map OSPF->RIP perm 10
r4(config-route-map)#desc Tag OSPF with 4110
r4(config-route-map)#set tag 4110
r4(config-route-map)#router rip
r4(config-router)#redist ospf 100 met 1 route-map OSPF->RIP

Okay…on to r3.  I can redist the OSPF routes into RIP (110 -> 120) with no worries as they will not be reflected back.  I also don’t think that I have to worry about the RIP routes because the RIP domain is not contiguous.

r3(config)#route-map RIP->OSPF perm 10
r3(config-route-map)#desc Tag RIP 3120
r3(config-route-map)#set tag 3120
r3(config-route-map)#router ospf 100
r3(config-router)#redist rip sub route-map RIP->OSPF

Those routes should appear on r4:

r4#sh ip os data | i Tag|3120
Link ID         ADV Router      Age         Seq#       Checksum Tag
54.1.1.0        150.1.3.3       26          0x80000003 0x00C1CA 3120
141.1.6.0       150.1.3.3       26          0x80000003 0x001B15 3120
141.1.7.0       150.1.3.3       26          0x80000003 0x00101F 3120
141.1.36.0      150.1.3.3       26          0x80000003 0x00CF42 3120
141.1.37.0      150.1.3.3       26          0x80000003 0x00C44C 3120
141.1.77.0      150.1.3.3       26          0x80000003 0x000BDD 3120
150.1.6.0       150.1.3.3       26          0x80000003 0x00A581 3120
150.1.7.0       150.1.3.3       26          0x80000003 0x009A8B 3120
212.18.0.0      150.1.3.3       26          0x80000003 0x00F1EB 3120
212.18.1.0      150.1.3.3       26          0x80000003 0x00E6F5 3120
212.18.2.0      150.1.3.3       26          0x80000003 0x00DBFF 3120
212.18.3.0      150.1.3.3       26          0x80000003 0x00D00A 3120

Now for OSPF->RIP:

r3(config)#route-map OSPF->RIP perm 10
r3(config-route-map)#desc Tag OSPF 3110
r3(config-route-map)#set tag 3110
r3(config-route-map)#router rip
r3(config-router)#redist ospf 100 met 1 route-m OSPF->RIP

r6#sh ip route 150.1.4.4
Routing entry for 150.1.4.4/32
  Known via “rip“, distance 120, metric 1
  Tag 3110
  Redistributing via rip
  Last update from 141.1.36.3 on FastEthernet0/0, 00:00:09 ago
  Routing Descriptor Blocks:
  * 141.1.36.3, from 141.1.36.3, 00:00:09 ago, via FastEthernet0/0
      Route metric is 1, traffic share count is 1
      Route tag 3110

At this point I created my ping scripts and tested connectivity (everything pinged) before completing the additional requirements:

“Routers in the OSPF domain should see two summary routes for the networks learned from BB3.”
“Do not overlap any address space when creating these summaries.”

Here are the routes learned from BB3:

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

Let’s figure out our summary routes:

Computing Access-List and Wildcard Pairs

31.0.0.0   00011111  00000000
31.1.0.0   00011111  00000001
31.2.0.0   00011111  00000010
31.3.0.0   00011111  00000011 
AND———————————
Network  00011111  00000000 31.0.0.0

31.0.0.0   00011111  00000000
31.1.0.0   00011111  00000001
31.2.0.0   00011111  00000010
31.3.0.0   00011111  00000011 
XOR———————————
Mask       00000000  00000011 0.3.255.255 – 255.253.0.0

30.0.0.0 00011110  00000000
30.1.0.0 00011110  00000001
30.2.0.0 00011110  00000010
30.3.0.0 00011110  00000011 
AND———————————
                00011110  00000000 30.0.0.0  

30.0.0.0 00011110  00000000
30.1.0.0 00011110  00000001
30.2.0.0 00011110  00000010
30.3.0.0 00011110  00000011 
XOR———————————
               00000000  00000011 0.3.255.255 –  255.252.0.0

So our two summaries will be:

summary-address (OSPF)

r4(config)#router ospf 100
r4(config-router)#summary-address 30.0.0.0 ?
  A.B.C.D  Summary mask

r4(config-router)#summary-address 31.0.0.0 255.252.0.0 tag 4120
r4(config-router)#summary-address 30.0.0.0 255.252.0.0 tag 4120

r4#sh ip ospf summary-address

OSPF Process 100, Summary-address

30.0.0.0/255.252.0.0 Metric 20, Type 2, Tag 4120
31.0.0.0/255.252.0.0 Metric 20, Type 2, Tag 4120

r3 sees theses routes as /14 routes now:

r3#sh ip route | i 30|31
     31.0.0.0/14is subnetted, 1 subnets
O E2    31.0.0.0 [110/20] via 141.1.123.2, 00:00:54, Serial0/0:0.1
     30.0.0.0/14is subnetted, 1 subnets
O E2    30.0.0.0 [110/20] via 141.1.123.2, 00:01:04, Serial0/0:0.1

Now the final subtask:

“The summaries should have a cumulative metric throughout the OSPF domain, while the route to VLAN 43 should always be seen with a metric of 100 throughout the OSPF domain.”

“cumulative metric” = E1 routes.  It looks like we’ll need to set the metric on the VLAN 43 route to 100 and make sure that it is an E2 route.  That route is already an E2, so I just need to change the metric:

r3#sh ip route | i 204.12.1.0
O E2 204.12.1.0/24 [110/20] via 141.1.123.2, 00:50:50, Serial0/0:0.1

I just need to add a line to my RIP->OSPF route-map to set the metric-type to 1.  BUT I need to use the route-map order of operations (which I am very well acquainted with after last week’s LFU) to ensure that I am setting the metric to 100 only for the VLAN43 route:

r4:
ip prefix-list VLAN34 perm 204.12.1.0/24
!
route-map RIP->OSPF permit 10
 description If VLAN43 set metric 100 tag 4120
 match ip address prefix-list VLAN43
 set metric 100
 set tag 4120
route-map RIP->OSPF permit 20
 description If not VLAN43 set E1 tag 4120
 set metric-type type-1
 set tag 4120

r3#sh ip route 204.12.1.0
Routing entry for 204.12.1.0/24
  Known via “ospf 100”, distance 110, metric 100
  Tag 4120, type extern 2, forward metric 11177
  Redistributing via rip
  Advertised by rip metric 1 route-map OSPF->RIP
  Last update from 141.1.123.2 on Serial0/0:0.1, 00:03:38 ago
  Routing Descriptor Blocks:
  * 141.1.123.2, from 150.1.4.4, 00:03:38 ago, via Serial0/0:0.1
      Route metric is 100, traffic share count is 1
      Route tag 4120

r3#sh ip route 30.0.0.0 255.252.0.0
Routing entry for 30.0.0.0/14
  Known via “ospf 100”, distance 110, metric 11197
  Tag 4120, type extern 1
  Redistributing via rip
  Advertised by rip metric 1 route-map OSPF->RIP
  Last update from 141.1.123.2 on Serial0/0:0.1, 00:02:58 ago
  Routing Descriptor Blocks:
  * 141.1.123.2, from 150.1.4.4, 00:02:58 ago, via Serial0/0:0.1
      Route metric is 11197, traffic share count is 1
      Route tag 4120

Advertisements

3 Comments »

  1. hi,

    First of all, can I just say this is a create blog… and well done….
    I have a question about the redistribution, you say you don’t need to worry about the RIP routes because the RIP domain is not contiguous…. can u explain this a bit more… I thought you need to worry about loops regardless of the domain being contiguous or not….

    Comment by JediCIsco — January 25, 2008 @ 4:28 am | Reply

  2. @JediCisco

    Hopefully my “ASCII Visios” do not get eaten by the formatting monster. 🙂 You need to ignore the “.” as that was the only way I could get the spacing to format correctly.

    Discontiguous RIP (r3 and r4 do not exchange RIP routes):

    r1 (OSPF)——————–(OSPF) r2
    (RIP)……………………………………(RIP)
    |……………………………………………|
    |……………………………………………|
    (RIP)……………………………………(RIP)
    r3 (RIP)……………………………..(RIP) r4

    In the above network, r3 and r4 are both running RIP, but they are not directly connected. If you redistribute OSPF into RIP on r1 and r2 you don’t need to be worried about OSPF routes redistributed into RIP on r1 being reflected back into the OSPF domain on r2.

    Contiguous RIP (r3 and r4 exchange RIP routes):

    r1 (OSPF)——————–(OSPF) r2
    (RIP)……………………………………(RIP)
    |……………………………………………|
    |……………………………………………|
    (RIP)……………………………………(RIP)
    r3 (RIP)————————(RIP) r4

    In this case, if you redistribute OSPF into RIP on r1 and r2, you do have the chance (let’s forget about AD/Metric for the sake of this example) of routes reflecting back into the OSPF domain (again – AD is taken out of the mix in this example).

    HTH

    Comment by cciepursuit — January 25, 2008 @ 8:19 am | Reply

  3. humm, nice diagrams…

    this stuff still worries me …. when I sleep I’m chasing my tail trying to avoid loops…

    I see you’re point,,,, I think it will become clearer further down the line….
    I did initially mean to say this is Great blog … not create.

    cheers

    Comment by JediCIsco — January 25, 2008 @ 11:52 am | Reply


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: