Nexus 7000 and IOS OSPF Loop Prevention and Interoperability

Blog

Nov 18, 2010 7:20 AM
Nov 18th, 2010

Introduction:

With the introduction of rfc2328, or OSPFv2, the path selection criteria for external or summary routes changed.

Specifically, the new changes call for preferring a non-backbone path over a backbone(area 0) path for the prefix.

Previously, we relied on cost to determine path selection, without regard to whether it was a backbone or non-backbone path.

IOS  has always treated rfc1583 as the default behavior for path selection,  and as support for rfc2328 was added, IOS added a toggle to prefer this  new method of path selection, but continued to keep rfc1583 behavior set  by default.

NX-OS, however, was launched with rfc2328  only behavior by default, and then to conform with RFC specs, added a command to make it optionally rf1583 compliant.

Problem Statement:

This  difference in default behavior can lead to ospf loops, where you have  some devices pointing to one path as the shortest path, and other  devices pointing to a different path as the shortest path.

The scenario below illustrates this problem:

ASBR1----area0-----(e3/7)ABR(e2/10)----area100----(G0/0)rtrB-----area100---ASBR2

ABR is an n7k, and rtrB is an IOS router (2800 in this case).


Both ASBR1 and ASBR2 redistribute a route, same prefix (192.168.0.0/16) into OSPF.

With their default configurations, the following takes place in the routing tables:

ABR# show ip route 192.168.0.0

192.168.0.0/16, ubest/mbest: 1/0
    *via 10.0.0.2, Eth2/10, [110/160], 00:03:00, ospf-loop, type-1

------------------------------------------------------------------------------------------------------

rtrB#show ip route 192.168.0.0
Routing entry for 192.168.0.0/16, supernet
  Known via "ospf 1", distance 110, metric 25, type extern 1
  Last update from 10.0.0.1 on GigabitEthernet0/0, 00:20:40 ago
  Routing Descriptor Blocks:
  * 10.0.0.1, from 2.2.2.2, 00:20:40 ago, via GigabitEthernet0/0
      Route metric is 25, traffic share count is 1

As you can see, the IOS router points out g0/0 to the n7k, and the n7k(ABR) points out e2/10 to rtrB.  This is a loop!

Now, we will turn on the rfc1583compatibility command on the n7k(ABR) and it will allow us to use the metric for our decision, like the IOS router is doing.

ABR(config)# router ospf loop
ABR(config-router)# rfc1583compatibility
ABR# show ip route 192.168.0.0

192.168.0.0/16, ubest/mbest: 1/0
    *via 10.10.10.1, Eth3/7, [110/24], 00:00:05, ospf-loop, type-1
ABR#

---------------------------------------------------------------

rtrB#show ip route 192.168.0.0
Routing entry for 192.168.0.0/16, supernet
  Known via "ospf 1", distance 110, metric 25, type extern 1
  Last update from 10.0.0.1 on GigabitEthernet0/0, 00:30:03 ago
  Routing Descriptor Blocks:
  * 10.0.0.1, from 2.2.2.2, 00:30:03 ago, via GigabitEthernet0/0
      Route metric is 25, traffic share count is 1

As you can see, if all the ospf routers in this domain are configured to run according to the same rfc mode, then we do not experience these same loops, as the complete domain is consistent in what it considers to be the shortest path.

Configuration:

On NX-OS, you can use the "rfc1583compatibility" command to make the device align with default IOS behavior.

On IOS, you can use the "no compatible rfc1583" command to make the device align with default Nexus behavior.

Which ever of the two options you use is your choice, but I will not go into the major design differences here in this post.

Average Rating: 5 (3 ratings)

Comments

mgalazka Sun, 01/30/2011 - 16:59

Great post, thanks for the information!  It is always great to learn about the little differences between behaviors in IOS and NX-OS.

I attempted to replicate this using all IOS devices, but with one of them using rfc2328 compliant OSPF (mimicking an N7K) as an ABR.  I found that I could not replicate in all IOS environment.  After doing some further searching to see where I went wrong in my lab, I found this blog post:

http://blog.ioshints.info/2008/02/common-sense-prevails-over-rfc-2328.html

It sounds like Ivan had similar results (unless I misunderstood).  In any case, I would be more apt to disable rfc2328 compatibility on NX-OS than enabling it in IOS after my testing.  Has anyone else tested this out?  I would be curious if anyone was able to get IOS to prefer the higher metric non-backbone area when using "no compatible rfc1583" ospf config.

peterbe Sun, 03/06/2011 - 19:12 (reply to mgalazka)

We have configure rfc1583compatibility.  In our network the N7K's (x2) are ASBR with the core routers in area 0. When testing prior to deploying, found that if an SVI was shutdown on one N7K, traffic was no long load balanced from the core routers to the N7K's due to the change in cost. 'rfc1583compatibility' fixed the issue.

Peter

chrismarget Mon, 04/04/2011 - 12:27
With the introduction of rfc2328, or OSPFv2, the path selection criteria for external or summary routes changed.

The outlined behavior was introduced by RFC 2178.

2178 also includes some examples that explain the reasoning behind the change.

Lisa Latour Wed, 02/01/2012 - 01:07

Hey Robert!  Got any more nuggets of knowledge for the Community? We'd love to see another post!

Actions

Login or Register to take actions

This Blog

Posted November 18, 2010 at 7:20 AM
Stats:
Comments:6 Avg. Rating:5
Views:6613   
Shares:0

Related Content