Redistribution works differently on NX-OS

There are (at least?) two key differences between redistributing routes in NX-OS and IOS.  A customer had an untimely (2:00 AM) encounter with one of them recently, so I thought I'd spread the word about these gotchas...

You Must Use a Route-Map
NX-OS won't redistribute routes uncontrolled in the same way that IOS will.  In fact, I don't think you can even complete the 'redistribute ' command without referencing a route-map.  You should be using a route-map anyway, so it shouldn't matter.  I've been working with the N7K for about 3 years, and didn't know about this requirement until I saw it in the documentation recently.  This is probably a good sign that I'm always using route-maps :-)

Redistribution Doesn't Include Interfaces
In IOS, when we redistribute from one protocol to another, we get two types of information in the destination protocol:

1. Routes learned by that protocol, and used by the routing table.  Basically, it's the same set of data returned by show ip route <protocol>
2. Prefixes associated with any "connected" interfaces running the routing protocol.

So, consider the following network:

Sample Network 1

Redistribution of EIGRP 100 into OSPF on an IOS router would result in three OSPF external routes being learned on R3:

1. Subnet A would be learned according to rule "1" above.
2. Subnet B and Subnet S would be learned according to rule "2" above.

NX-OS is different.  It only follows the first rule above, but doesn't include interfaces running the source protocol.

If R2 were an NX-OS router, the only external prefix that would be introduced to the OSPF domain is Subnet A.  In order to get all of the EIGRP subnets into OSPF, you'd need to use redistribute direct in addition to redistribute eigrp.  Note that in addition to a route-map being required, a route-map is desired to emulate the IOS behavior.  Wide-open redistribution on R2 will include Subnet L, which an IOS router would not have introduced to OSPF because neither EIGRP nor OSPF is running in the Loopback interface.

NX-OS's rejection of the 'interfaces running the source protocol' logic can have some surprising consequences.  Lets say we redistribute OSPF into EIGRP in the following network:

Sample Network 2

EIGRP will learn precisely 3 new routes:

• 5.0.0.0/8
• 6.0.0.0/8
• 7.0.0.0/8

The 10.0.0.0/30 and 10.0.1.0/24 networks used for OSPF adjacency won't be introduced into EIGRP by NX-OS routers R1 and R2 because these prefixes are considered "direct" routes.

But what happens if an interface fails?

Sample Network 2 With Interface Failure

Suddenly, the 10.0.1.0/24 prefix is introduced to the EIGRP process.  This happens because 10.0.1.0/24 is no longer a 'direct' route from R1's perspective.  R1 has learned the path to this network from R2 over their 10.0.0.0/30 connection.  Because 10.0.1.0/24 is now an 'OSPF route' rather than a 'direct route via an interface running OSPF', it's elegible for redistribution into EIGRP.

If the route wasn't there before, you probably don't want it appearing when things start to break.  It's a good thing that (required) route-map is in place! :-)