Redistribute Connected Subnets - Not Redistributing?
by David Sudjiman ~ January 11th, 2007. Filed under: Cisco.Ever come across why your OSPF networks cannot be redistributed to IGRP or RIP? This scenario is taken from the book CCNP Practical Studies: Routing (ISBN: 1-58720-054-6). While I was doing my Scenario 2-4: Basic EIGRP, page 62-70, I had to spend 6 hours just to realize what went wrong. Well, the scenario was not about ‘Basic EIGRP’. It was about redistribution between IGRP and OSPF with classless IP address.
Initial Configuration.
I have two routers connected using DTE-DCE cable with configuration shown below.
hostname r1 ! interface Loopback0 ip address 131.108.4.1 255.255.255.0 ! interface Loopback1 ip address 131.108.5.1 255.255.255.0 ! interface Loopback2 ip address 131.108.6.1 255.255.255.0 ! interface Ethernet0 ip address 131.108.1.1 255.255.255.0 ! interface Serial0 ip address 131.108.3.1 255.255.255.0 no fair-queue clockrate 56000 ! router igrp 1 network 131.108.0.0
hostname r2 ! interface Loopback0 ip address 131.108.7.1 255.255.255.255 ! interface Loopback1 ip address 131.108.8.1 255.255.255.128 ! interface Loopback2 ip address 131.108.9.1 255.255.255.224 ! interface Ethernet0 ip address 131.108.2.1 255.255.255.0 ! interface Serial0 ip address 131.108.3.2 255.255.255.0 no fair-queue ! router ospf 1 log-adjacency-changes network 131.108.2.0 0.0.0.255 area 0 network 131.108.7.1 0.0.0.0 area 0 network 131.108.8.0 0.0.0.127 area 0 network 131.108.9.0 0.0.0.31 area 0 ! router igrp 1 network 131.108.0.0
From the above configuration, we need to configure both IGRP and OSPF to redistribute their router to each other.
hostname r1 ! router igrp 1 network 131.108.0.0
hostname r2 ! router ospf 1 log-adjacency-changes redistribute igrp 1 subnets network 131.108.2.0 0.0.0.255 area 0 network 131.108.7.1 0.0.0.0 area 0 network 131.108.8.0 0.0.0.127 area 0 network 131.108.9.0 0.0.0.31 area 0 ! router igrp 1 redistribute ospf 1 metric 1500 20000 255 1 1500 network 131.108.0.0
Let’s look on r1’s routing table.
r1#sh ip route
131.108.0.0/24 is subnetted, 6 subnets
C 131.108.6.0 is directly connected, Loopback2
C 131.108.5.0 is directly connected, Loopback1
C 131.108.4.0 is directly connected, Loopback0
C 131.108.3.0 is directly connected, Serial0
I 131.108.2.0 [100/8576] via 131.108.3.2, 00:00:08, Serial0
C 131.108.1.0 is directly connected, Ethernet0
r2#sh ip route
131.108.0.0/16 is variably subnetted, 9 subnets, 4 masks
C 131.108.9.0/27 is directly connected, Loopback2
C 131.108.8.0/25 is directly connected, Loopback1
I 131.108.6.0/24 [100/8976] via 131.108.3.1, 00:00:51, Serial0
C 131.108.7.1/32 is directly connected, Loopback0
I 131.108.5.0/24 [100/8976] via 131.108.3.1, 00:00:51, Serial0
I 131.108.4.0/24 [100/8976] via 131.108.3.1, 00:00:51, Serial0
C 131.108.3.0/24 is directly connected, Serial0
C 131.108.2.0/24 is directly connected, Ethernet0
I 131.108.1.0/24 [100/8576] via 131.108.3.1, 00:00:52, Serial0
Why is r1’s routing table shows 131.108.0.0/24 and r2’s routing table shows 131.108.0.0/16? This is because all of the connected subnets on r1 are using /24 networks while on r2, there are interfaces use non-/24 networks. What we need to do next is to make OSPF routing look like /24 networks. We can do this using command summary-address.
hostname r2 ! router ospf 1 log-adjacency-changes summary-address 131.108.7.0 255.255.255.0 summary-address 131.108.8.0 255.255.255.0 summary-address 131.108.9.0 255.255.255.0 redistribute connected subnets redistribute igrp 1 subnets network 131.108.2.0 0.0.0.255 area 0 network 131.108.7.1 0.0.0.0 area 0 network 131.108.8.0 0.0.0.127 area 0 network 131.108.9.0 0.0.0.31 area 0
Henry Benjamin also suggests to add redistribute connected subnets to make redistribute those connected subnets to IGRP.
(If you wonder why Henry uses summary-address instead of area range, check this OSPF Commands.)
From the configuration above, regarding to the book, it should work. The connected subnets in OSPF area 0 from r2 will be redistributed to r1. However, that was far from true. Check the sh ip route from the from both routers.
r1#sh ip route
131.108.0.0/24 is subnetted, 6 subnets
C 131.108.6.0 is directly connected, Loopback2
C 131.108.5.0 is directly connected, Loopback1
C 131.108.4.0 is directly connected, Loopback0
C 131.108.3.0 is directly connected, Serial0
I 131.108.2.0 [100/8576] via 131.108.3.2, 00:00:35, Serial0
C 131.108.1.0 is directly connected, Ethernet0
r2#sh ip route
131.108.0.0/16 is variably subnetted, 9 subnets, 4 masks
C 131.108.9.0/27 is directly connected, Loopback2
C 131.108.8.0/25 is directly connected, Loopback1
I 131.108.6.0/24 [100/8976] via 131.108.3.1, 00:00:10, Serial0
C 131.108.7.1/32 is directly connected, Loopback0
I 131.108.5.0/24 [100/8976] via 131.108.3.1, 00:00:10, Serial0
I 131.108.4.0/24 [100/8976] via 131.108.3.1, 00:00:10, Serial0
C 131.108.3.0/24 is directly connected, Serial0
C 131.108.2.0/24 is directly connected, Ethernet0
I 131.108.1.0/24 [100/8576] via 131.108.3.1, 00:00:11, Serial0
What Went Wrong?
Having subnet 131.108.2.0 seen from r1, it means that OSPF routing on r2 was basically doing its job by redistributing it to IGRP on r2.
r2#debug ip ospf lsa-generation OSPF summary lsa generation debugging is on r2#clear ip route * r2# 00:52:39: OSPF: Generate external LSA 131.108.2.0, mask 255.255.255.0, type 5, age 0, metric 20, tag 0, metric-type 2, seq 0×80000001 00:52:39: OSPF: net 131.108.7.1 up, new metric decreases: old 16777215, new 20 00:52:40: OSPF: net 131.108.7.1 up, old cost 20, new cost 20 00:52:40: OSPF: net 131.108.7.1 down, metric 20 equal to summary metric 00:52:40: OSPF: net 131.108.8.0 up, new metric decreases: old 16777215, new 20 00:52:40: OSPF: net 131.108.8.0 up, old cost 20, new cost 20 00:52:40: OSPF: net 131.108.8.0 down, metric 20 equal to summary metric 00:52:40: OSPF: net 131.108.9.0 up, new metric decreases: old 16777215, new 20 00:52:40: OSPF: net 131.108.9.0 up, old cost 20, new cost 20 00:52:40: OSPF: net 131.108.9.0 down, metric 20 equal to summary metric 00:52:40: OSPF: Start redist-scanning 00:52:40: OSPF: Scan for both redistribution and translation 00:52:40: OSPF: max-aged external LSA for summary 131.108.7.0 255.255.255.0 00:52:41: OSPF: max-aged external LSA for summary 131.108.8.0 255.255.255.0 00:52:41: OSPF: max-aged external LSA for summary 131.108.9.0 255.255.255.0 00:52:41: OSPF: End scanning, Elapsed time 20ms
OSPF generates LSA type 5 for subnet 131.108.2.0. Of course!, OSPF uses ‘External Link LSA’ known as LSA type 5 to redistribute from or to other routing protocol. This LSA is generated by Autonomous System Backbone Route (ASBR) which in this case is r2. But why we don’t see the rest of the connected subnets’ LSA type 5?
Based on this finding, I found this link Redistributing Connected Networks into OSPF.
In Cisco IOS Software Release 12.1(3) and later, the Type-5 LSAs are no longer created for connected networks included in the network statements under router OSPF.
Now, since we cannot use redistribute connected subnets we still need to find a way on how we can redistribute those subnets 131.108.7.0/24, 131.108.8.0/24, and 131.108.9.0/24.
Routing Update Behaviour on IGRP (and RIP).
Before we continue with different way to to redistribute these OSPF subnets, we need to understand the routing behaviour of IGRP. Let’s look at r2’s debug ip igrp transactions.
r2#debug ip igrp transactions IGRP protocol debugging is on r2#clear ip route * r2# 01:14:13: IGRP: edition is now 15 01:14:13: IGRP: sending update to 255.255.255.255 via Serial0 (131.108.3.2) 01:14:13: subnet 131.108.2.0, metric=1100 01:14:13: IGRP: received update from 131.108.3.1 on Serial0 01:14:13: subnet 131.108.6.0, metric 8976 (neighbor 501) 01:14:13: subnet 131.108.5.0, metric 8976 (neighbor 501) 01:14:13: subnet 131.108.4.0, metric 8976 (neighbor 501) 01:14:13: subnet 131.108.1.0, metric 8576 (neighbor 1100)
[Updated: 11 January 2007 08:10:09AM EDST (UTC +11)] I’ve actually see IGRP on r2 tries to update to e0, lo0, lo1, and lo2, which is just a waste of task. Therefore I add passive-interface to tell IGRP not to update to those interfaces.
router igrp 1 redistribute ospf 1 metric 1500 20000 255 1 1500 passive-interface Ethernet 0 passive-interface Loopback 0 passive-interface Loopback 1 passive-interface Loopback 2 network 131.108.0.0
Another check from IGRP point of view, we find that r2 only sends updates via Serial0 about subnet 131.108.2.0, nothing else.
I thought by removing redistribute connected subnets will fix the problem as subnets 131.108.7.0/24, 131.108.8.0/24, and 131.108.9.0/24 will be advertised using command redistribute ospf 1 metric 1500 20000 255 1 1500. However, that is not likely the case.
This document Behavior of RIP and IGRP When Sending and Receiving Updates provides interesting fact that:
When RIP or IGRP send an update, they perform certain checks before they advertise the update. This list shows the sequence of events that occurs before Router 1 sends updates to Router 2.
- Is the subnet information part of the same major net as the interface that sources the update?
- NO: Router 1 summarizes at the major net boundary and advertises the network.
- YES: Does the network have the same subnet mask as the interface that sources the update?
- YES: Router 1 advertises the subnet.
- NO: Does the network have a /32 mask ?
- YES: If it is RIP, then the network is advertised. If it is IGRP, then Router 1 drops the network.
- NO: Router 1 drops the network.
It is basically trying to say that if the subnet advertised is not having the same subnet, it will be dropped.
Using Static Route.
Ok then, how can we advertise these connected network then? Check out this link Redistributing Between Classful and Classless Protocols: EIGRP or OSPF into RIP or IGRP that will show you the workaround for this issue using static routing redistribution.
r2(config)#router ospf 1 r2(config-router)#no redistribute connected subnets r2(config-router)#redistribute static % Only classful networks will be redistributed r2(config-router)#exit r2(config)#ip route 131.108.7.0 255.255.255.0 null0 r2(config)#ip route 131.108.8.0 255.255.255.0 null0 r2(config)#ip route 131.108.9.0 255.255.255.0 null0
Checking routing entry for both routers.
r2#sh ip route
131.108.0.0/16 is variably subnetted, 12 subnets, 4 masks
S 131.108.9.0/24 is directly connected, Null0
C 131.108.9.0/27 is directly connected, Loopback2
S 131.108.8.0/24 is directly connected, Null0
C 131.108.8.0/25 is directly connected, Loopback1
S 131.108.7.0/24 is directly connected, Null0
I 131.108.6.0/24 [100/8976] via 131.108.3.1, 00:00:12, Serial0
C 131.108.7.1/32 is directly connected, Loopback0
I 131.108.5.0/24 [100/8976] via 131.108.3.1, 00:00:13, Serial0
I 131.108.4.0/24 [100/8976] via 131.108.3.1, 00:00:13, Serial0
C 131.108.3.0/24 is directly connected, Serial0
C 131.108.2.0/24 is directly connected, Ethernet0
I 131.108.1.0/24 [100/8576] via 131.108.3.1, 00:00:13, Serial0
r1#sh ip route
131.108.0.0/24 is subnetted, 9 subnets
I 131.108.9.0 [100/8476] via 131.108.3.2, 00:00:01, Serial0
I 131.108.8.0 [100/8476] via 131.108.3.2, 00:00:01, Serial0
I 131.108.7.0 [100/8476] via 131.108.3.2, 00:00:01, Serial0
C 131.108.6.0 is directly connected, Loopback2
C 131.108.5.0 is directly connected, Loopback1
C 131.108.4.0 is directly connected, Loopback0
C 131.108.3.0 is directly connected, Serial0
I 131.108.2.0 [100/8576] via 131.108.3.2, 00:00:02, Serial0
C 131.108.1.0 is directly connected, Ethernet0
Seeing is believing…
r1#ping Protocol [ip]: Target IP address: 131.108.7.1 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 131.108.1.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 131.108.7.1, timeout is 2 seconds: Packet sent with a source address of 131.108.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms