Solved: Re: Redistribute OSPF into RIP

lgijssel · ‎01-08-2011

Hi all,

The following is about a lab on route redistribution. For this lab I am mutually redistributing OSPF and RIP with default parameters.

Lab is built with GNS3. Routers are 3745 with version:

Cisco IOS Software, 3700 Software (C3745-ADVIPSERVICESK9-M), Version 12.4(15)T6, RELEASE SOFTWARE (fc2)

R2 is running RIP only and R4 is running only OSPF.

R1 and R3 are running both protocols. The redistribution setup is as follows: (example shows R3)

router ospf 1
log-adjacency-changes
redistribute rip subnets
network 10.1.0.0 0.0.255.255 area 0
network 10.3.3.0 0.0.0.255 area 0
!
router rip
passive-interface FastEthernet0/1
passive-interface Loopback0
network 10.0.0.0
default-metric 4

Please note that R1 and R3 are not RIP neighbors, the corresponding interfaces are passive.

What puzzles me is the finding that ospf seems to import the subnet info into RIP and that this is subsequently advertized to R2.

However, I am running RIPv1 and this version does not transport any subnet info.

Still R2 has suddenly become aware of the fact that OSPF advertizes the loopback networks as /32.

Below is the output from the related show commands on R2 before and after activating the redistribution of OSPF into RIP.

I started this by adding the line with the default metric. It should be easy to distinguish redistributed routes by their metric of four.

Before redistributing:

R2#sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 5 subnets
C       10.1.12.0 is directly connected, FastEthernet0/0
R       10.3.3.0 [120/1] via 10.1.23.3, 00:00:23, FastEthernet0/1
C       10.2.2.0 is directly connected, Loopback0
R       10.1.1.0 [120/1] via 10.1.12.1, 00:00:22, FastEthernet0/0
C       10.1.23.0 is directly connected, FastEthernet0/1
R2#

After:
R2#sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
C       10.1.12.0/24 is directly connected, FastEthernet0/0
R       10.3.3.3/32 [120/4] via 10.1.12.1, 00:00:14, FastEthernet0/0
R       10.3.3.0/24 [120/1] via 10.1.23.3, 00:00:16, FastEthernet0/1
C       10.2.2.0/24 is directly connected, Loopback0
R       10.1.1.0/24 [120/1] via 10.1.12.1, 00:00:14, FastEthernet0/0
R       10.4.4.4/32 [120/4] via 10.1.12.1, 00:00:14, FastEthernet0/0
C       10.1.23.0/24 is directly connected, FastEthernet0/1
R       10.4.44.0/24 [120/4] via 10.1.12.1, 00:00:14, FastEthernet0/0
R2#sh ip rip da
10.0.0.0/8    auto-summary
10.1.1.0/24
    [1] via 10.1.12.1, 00:00:25, FastEthernet0/0
10.1.12.0/24    directly connected, FastEthernet0/0
10.1.23.0/24    directly connected, FastEthernet0/1
10.2.2.0/24    directly connected, Loopback0
10.3.3.0/24
    [1] via 10.1.23.3, 00:00:03, FastEthernet0/1
10.3.3.3/32
    [4] via 10.1.12.1, 00:00:25, FastEthernet0/0
10.4.4.4/32
    [4] via 10.1.12.1, 00:00:25, FastEthernet0/0
10.4.44.0/24
    [4] via 10.1.12.1, 00:00:25, FastEthernet0/0
R2#

This is a theoretical excercise. The question is how it is possible that I am seeing subnet info for RIP routes on R2?

It is evident this info is derived from OSPF redistribution but R2 is RIPv1-only and updates from R1 and R3 are v1 indeed:

R2#deb ip rip
RIP protocol debugging is on
R2#
*Mar 1 05:17:38.242: RIP: sending v1 update to 255.255.255.255 via Loopback0 (10.2.2.2)
*Mar 1 05:17:38.246: RIP: build update entries
*Mar 1 05:17:38.246:   subnet 10.1.1.0 metric 2
*Mar 1 05:17:38.250:   subnet 10.1.12.0 metric 1
*Mar 1 05:17:38.250:   subnet 10.1.23.0 metric 1
*Mar 1 05:17:38.254:   subnet 10.3.3.0 metric 2
*Mar 1 05:17:42.302: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/1 (10.1.23.2)
*Mar 1 05:17:42.306: RIP: build update entries
*Mar 1 05:17:42.306:   subnet 10.1.1.0 metric 2
*Mar 1 05:17:42.310:   subnet 10.1.12.0 metric 1
*Mar 1 05:17:42.310:   subnet 10.2.2.0 metric 1
*Mar 1 05:17:54.278: RIP: received v1 update from 10.1.23.3 on FastEthernet0/1
*Mar 1 05:17:54.282:      10.3.3.0 in 1 hops
*Mar 1 05:17:55.778: RIP: received v1 update from 10.1.12.1 on FastEthernet0/0
*Mar 1 05:17:55.782:      10.1.1.0 in 1 hops

<remark Redistribution activated on R1 at this moment, additional subnets coming in>
*Mar 1 05:17:58.138: RIP: received v1 update from 10.1.12.1 on FastEthernet0/0
*Mar 1 05:17:58.138:      10.1.1.0 in 1 hops
*Mar 1 05:17:58.142:      10.1.23.0 in 4 hops
*Mar 1 05:17:58.142:      10.3.3.3 in 4 hops
*Mar 1 05:17:58.150:      10.4.4.4 in 4 hops
*Mar 1 05:17:58.154:      10.4.44.0 in 4 hops
*Mar 1 05:18:00.150: RIP: sending v1 flash update to 255.255.255.255 via FastEthernet0/0 (10.1.12.2)
*Mar 1 05:18:00.154: RIP: build flash update entries - suppressing null update
*Mar 1 05:18:00.154: RIP: sending v1 flash update to 255.255.255.255 via FastEthernet0/1 (10.1.23.2)
*Mar 1 05:18:00.154: RIP: build flash update entries
*Mar 1 05:18:00.154:   subnet 10.3.3.3 metric 5
*Mar 1 05:18:00.154:   subnet 10.4.4.4 metric 5
*Mar 1 05:18:00.154:   subnet 10.4.44.0 metric 5
*Mar 1 05:18:00.154: RIP: sending v1 flash update to 255.255.255.255 via Loopback0 (10.2.2.2)
*Mar 1 05:18:00.154: RIP: build flash update entries
*Mar 1 05:18:00.154:   subnet 10.3.3.3 metric 5
*Mar 1 05:18:00.154:   subnet 10.4.4.4 metric 5
*Mar 1 05:18:00.154:   subnet 10.4.44.0 metric 5
*Mar 1 05:18:00.270: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (10.1.12.2)
*Mar 1 05:18:00.274: RIP: build update entries
*Mar 1 05:18:00.274:   subnet 10.1.23.0 metric 1
*Mar 1 05:18:00.278:   subnet 10.2.2.0 metric 1
*Mar 1 05:18:00.278:   subnet 10.3.3.0 metric 2
*Mar 1 05:18:05.094: RIP: sending v1 update to 255.255.255.255 via Loopback0 (10.2.2.2)
*Mar 1 05:18:05.098: RIP: build update entries
*Mar 1 05:18:05.098:   subnet 10.1.1.0 metric 2
*Mar 1 05:18:05.098:   subnet 10.1.12.0 metric 1
*Mar 1 05:18:05.098:   subnet 10.1.23.0 metric 1
*Mar 1 05:18:05.098:   subnet 10.3.3.0 metric 2
*Mar 1 05:18:05.098:   subnet 10.3.3.3 metric 5
*Mar 1 05:18:05.098:   subnet 10.4.4.4 metric 5
*Mar 1 05:18:05.098:   subnet 10.4.44.0 metric 5
*Mar 1 05:18:09.554: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/1 (10.1.23.2)
*Mar 1 05:18:09.558: RIP: build update entries
*Mar 1 05:18:09.558:   subnet 10.1.1.0 metric 2
*Mar 1 05:18:09.558:   subnet 10.1.12.0 metric 1
*Mar 1 05:18:09.558:   subnet 10.2.2.0 metric 1
*Mar 1 05:18:09.558:   subnet 10.3.3.3 metric 5
*Mar 1 05:18:09.558:   subnet 10.4.4.4 metric 5
*Mar 1 05:18:09.558:   subnet 10.4.44.0 metric 5
R2#

My expectation was to see all rip-routes on R2 without any mask-info as was the case before starting the redistribution.

A /24 is the only mask configured on R2 and this is what RIP uses to derive masks for non-local routes.(?)

The /22 between R1 and R3 is not redistributed into RIP, it is when I set the mask to /24.

My guess is that when router R2 notices the last octet of a route entry is non-zero, it somehow sets it to /32 for this reason.

The RIP database is v1/v2 so it can supposedly hold this info when present.

However, I cannot remember having seen any documentation describing this behavior, it may just as well be a bug.

Perhaps there is still a RIP guru around who can clarify this phenomenon?

regards,

Leo

Richard Burts · ‎01-08-2011

I decided to look for something that would describe the behavior of RIP and host routes. I found some references in RFC 1058 which do state that RIP will process and advertise both network/subnet routes and host routes:

   The RIP packet formats do not distinguish among various types of
   address.  Fields that are labeled "address" can contain any of the
   following:

      host address
      subnet number
      network number
      0, indicating a default route

for more details see this url:
http://tools.ietf.org/rfc/rfc1058.txt

HTH

Rick

HTH

Rick

View solution in original post

Peter Paluch · ‎01-08-2011

Hello Rick,

The following document explains nicely the behavior of RIPv1 and IGRP when sending/receiving updates:

http://www.cisco.com/en/US/tech/tk364/technologies_tech_note09186a0080093fd8.shtml

It is consistent with your earlier replies.

Best regards

Peter

View solution in original post

Richard Burts · ‎01-08-2011

Leo

It has been a long time since I ran into this and I do not have specific references to back up my explanation. But I am pretty sure that this is the explanation. There are 2 things to understand which explain this behavior:

- there is an exception in RIP about not advertising routes whose mask is different from the interface mask - RIP will advertise a host route (a /32) over other interfaces.

- the default behavior of OSPF is to advertise loopback interfaces as /32 host routes, even when the loopback is configured with a /24 mask OSPF will advertise it as a /32.

HTH

Rick

HTH

Rick

Richard Burts · ‎01-08-2011

I decided to look for something that would describe the behavior of RIP and host routes. I found some references in RFC 1058 which do state that RIP will process and advertise both network/subnet routes and host routes:

   The RIP packet formats do not distinguish among various types of
   address.  Fields that are labeled "address" can contain any of the
   following:

      host address
      subnet number
      network number
      0, indicating a default route

for more details see this url:
http://tools.ietf.org/rfc/rfc1058.txt

HTH

Rick

HTH

Rick

Peter Paluch · ‎01-08-2011

Hello Rick,

The following document explains nicely the behavior of RIPv1 and IGRP when sending/receiving updates:

http://www.cisco.com/en/US/tech/tk364/technologies_tech_note09186a0080093fd8.shtml

It is consistent with your earlier replies.

Best regards

Peter

lgijssel · ‎01-08-2011

Rick and Peter,

Thank you for your time. I will check the info provided.

Lots of little details.... I guess this is part what it takes to become a ccie.

regards,

Leo