Kevin Dorrell, CCIE #20765

16 Mar 2008

NMC Lab12 : Redistribution OSPF–>EIGRP

Filed under: EIGRP, IP Routing Protocols, OSPF, Redistribution — dorreke @ 17:44

While I was doing this lab, I came across some strange behavior.  If you redistribute from OSPF to EIGRP through a route-map, and that map specifies the route-type, (local, internal, external, etc.) then there seems to be no way to include the connected interfaces.

For example, using NMC Lab 12 as a test-bed, I removed the redistribution on R2 and concentrated on R3.  R3 is connected to, which is in OSPF.  We are redistributing OSPF into EIGRP, and watching the routes turn up through EIGRP on R5:

router eigrp 100 
 redistribute ospf 12 metric 1500 100 255 1 1500 

On R5, we can see a route to

R5#show ip route 
Routing entry for 
  Known via "eigrp 100", distance 170, metric 123225600, type external 
  Redistributing via eigrp 100 
  Last update from on Serial1/1, 00:00:45 ago 
  Routing Descriptor Blocks: 
  *, from, 00:00:45 ago, via Serial1/1 
      Route metric is 123225600, traffic share count is 1 
      Total delay is 4032250 microseconds, minimum bandwidth is 128 Kbit 
      Reliability 255/255, minimum MTU 1500 bytes 
      Loading 1/255, Hops 1

I have prepared a route-map on R3 to distribute through.  Let us include locally generated routes and internal routes:

R3#show run 
route-map OSPF-->EIGRP permit 10 
 match route-type local 
route-map OSPF-->EIGRP permit 20 
 match route-type internal 

Now let us apply the route map:

R3#conf t 
Enter configuration commands, one per line.  End with CNTL/Z. 
R3(config)#router eigrp 100 
R3(config-router)#redistribute ospf 12 metric 1500 100 255 1 1500 route-map OSPF-->EIGRP 

Look what happens on R5.  We lose the route to  It does not seem to be getting past the route-map.

*Mar  1 19:29:31.788: RT: delete route to via, eigrp metric [170/123225600] 
*Mar  1 19:29:31.792: RT: SET_LAST_RDB for 
  OLD rdb: via, Serial1/1 *Mar  1 19:29:31.792: RT: no routes to 
*Mar  1 19:29:31.792: RT: NET-RED 
*Mar  1 19:29:31.792: RT: delete subnet route to 
*Mar  1 19:29:31.796: RT: NET-RED 

I would have thought the connected interface would at least be counted as a locally generated route.  How do I write a route-map to include the connected interfaces?  (Assuming that, as in this case, the scenario forbids you to redistribute the connecteds directly.)  Well, the only way I can think of is to make an access-list listing the connected prefixes of the source protocol, and add a clause to the route-map that matches the access list.  Normally I am reluctant to use access lists to filter redistributions because it is not scaleable.  However, in this case it is not so bad because it is only the locally connected prefixes you are listing.  It is still scaleable.

Key Point: If you redistribute from OSPF through a route-map, and that route-map filters by route-type, the connected networks are no longer included.

If anyone else has observed this, or can repeat the experiment, could you please leave a comment?  Thanks.



  1. If I am understanding your scenario correctly, here are my thoughts (actually, an excert from my study notes)

    What routes are redistributed?
    -Routes in the routing table from the protocol being redistributed.
    * Example: Rip is being redistributed into OSPF. OSPF will receive all of the RIP routes from the routing table (RIB)– not necessarily the networks RIP has in its ‘database’.
    -Connected interfaces that are being advertised by the protocol being redistributed. Interfaces which are a part of the network being advertised within the routing protocol.

    **Rule/Exception noted next:

    **Rule: default behavior for RIP, IGRP and EIGRP is to advertise directly connected routes when a network statement under the routing protocol includes the connected interface subnet. Directly connected includes an interface with an IP address or a static route configured with an outgoing interface as the next-hop. this silently “adds” the command ‘redistribute connected’ under the router process.
    ** Exception: if you subsequently add a ‘redistribute connected’ command for another interface, this will break the original silent redistribution command and all the originally redistributed interfaces will be lost in the redistribution.

    based on my knowledge and your scenario, it may be that by adding a route-map which selects particular routes within the RIB, this enables the exception noted above.

    good luck with your studies.

    Comment by kevin — 26 Mar 2008 @ 13:42

  2. Thank you Kevin, that is very interesting. I notice that your observation covers explicitly RIP, IGRP and EIGRP, implying that OSPF behaves differently again. Certainly the reliance on the silent “redistribute connected” can be flaky in any circumstances.

    My experience has been that if you do a blanket redistribution of OSPF, then it will include the connecteds. OTOH, this could be a false observation because, MOTN, RIP is involved somewhere and the scenario uses subnets of a class-B.

    Next time I have a lab on the rack, I shall try and repeat your observation about RIP and EIGRP. It looks like one that should be remembered.

    It is no wonder that redistribution trips me up so often!

    Comment by dorreke — 26 Mar 2008 @ 14:21

  3. The rule applies to OSPF too. My notes (good, albeit incomplete), were taken rather rapidly as I viewed an online tutorial about redistribution. I just verified via the Cisco doc that OSPF will react as does EIGRP IF-IF-IF the config specifies a network under the OSPF process. Typically though, we will configure OSPF network statements with the interface IP addr only—We tell OSPF which interfaces to run OSPF on, not which networks to ‘run’ it on. I hope I am making sense as I ramble…..Anyhow, Redistribution can be complicated, but you seem to have a good grasp on it…Your site is excellent and I have gleaned much so far….I am happy to share my knowledge as well…Thanks!

    Comment by kevhat — 26 Mar 2008 @ 14:42

  4. Kevin, that is great. Do you have a reference to that Cisco doc please? It looks like I need to do some reading.

    The OSPF network habit varies from person to person. I tend to include the whole subnet in the wildcard rather than using a, although I avoid using a wildcard that covers more than one interface. That probably explains why I have not noticed this behaviour before. Actually, my favorite way is to activate OSPF like you do it in IPv6 … on the interface itself, but that method does not seem to have caught on yet.

    Someone should write a book on these foibles. Maybe they have. I’m going to have a look in Doyle this evening.

    Thanks for the kind remarks, and thank you for sharing your experience.

    Comment by dorreke — 26 Mar 2008 @ 15:03

  5. <–older doc but still useful

    Since the OSPF topology is held in the LS database and sent via the LSA’s to it’s neighbors, defining the interface on which to run OSPF suffices. Defining a subnet or network under the process would be useful if, let’s say, your entire network was flat ( and subneted within the network with many router interfaces (physical or SVI), then you would probably enter a one line network statement to encompass all of the interfaces (network area 0). Just my thoughts, but as you say, we are creatures of habit! I think I will begin a new section in my notes called “Foibles and Gotchas” !!!!

    Comment by kevhat — 26 Mar 2008 @ 15:49

RSS feed for comments on this post. TrackBack URI

Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s

Blog at

%d bloggers like this: