cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
12036
Views
20
Helpful
7
Comments
Robert Taylor
Cisco Employee
Cisco Employee

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.

7 Comments
mgalazka
Level 1
Level 1

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
Level 1
Level 1

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
Level 1
Level 1
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.

richard.simon
Level 1
Level 1

Just used the switch comparison tool from ethernetadvisor.com and found that cisco nexus 7018 switch has much better throught and growth capabilities.

Richard

Lisa Latour
Level 6
Level 6

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

Gustavo Novais
Level 1
Level 1

Excellent post.

Just saved my day!

bcoverstone
Level 1
Level 1

That's very good to know that they both have different defaults which can result in loops.

 

It may also be worthwhile to know that even if all devices are configured as rfc1583 compatible, you can still get routing loops when combining two external LSA type 7 advertisements from two different areas across a backbone.  Take a look here:

 

https://live.paloaltonetworks.com/docs/DOC-5561

 

So it's probably best to always disable rfc1583 compatibility unless the newer rfc2328 is causing an even worse issue...

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: