Solved

Should I redistribute OSPF into ISIS, if so, how do I do safely?

  • 1 February 2021
  • 5 replies
  • 285 views

Userlevel 6
Badge

Hi,

Have been told that it is quite routine to redistribute OSPF routes into ISIS and visa versa. In my topology OSPF is used as routes are exchanged with external firewalls.

Initially my thoughts where that I just needed to redistribute ISIS into OSPF, it doesn’t need to be the other way around. The reason for this was that each router in the topology will be running OSPF, so all routes and known paths would be shared.

Recently this changed a little, in that the network / fabric is expanding and there isn’t necessarily a need to run OSPF on these VSP’s, so should all routes be distributed into ISIS then the other fabric nodes will automatically be aware of the rest of the network.

Equally I come into a situation where the routing was not quite optimised, and OSPF was not able to reach certain nodes but ISIS could, so having the redistribution in both directions in place would have allowed connectivity to continue.

So think this gives a couple of good reasons as to why redistributing in both directions OSPF → ISIS and and ISIS → OSPF is a good idea.

Issue is, how do a do this safely without creating a routing loop?

Here is an overview of my topology:

 

The configuration on each of the VSPs currently looks like this:

ip ecmp
ip ecmp max-path 8
ip route 0.0.0.0 0.0.0.0 172.22.1.202 weight 1  
ip route 0.0.0.0 0.0.0.0 172.22.1.206 weight 1  

router ospf enable
router ospf 
as-boundary-router enable 
router-id 172.22.0.211 

router ospf
redistribute isis 
redistribute isis metric-type type1 
redistribute isis route-map "isis-internal" 
redistribute isis enable 
redistribute direct 
redistribute direct enable 
exit
router isis
redistribute direct
redistribute direct route-map "suppressIST"
redistribute direct enable
exit

ip ospf apply redistribute isis  
ip ospf apply redistribute direct  
isis apply redistribute direct 

The route map just stops traffic transversing the vIST:

ip prefix-list "suppressIST" 172.22.1.240/30 id 1 ge 29 le 29
ip prefix-list "suppressIST" 172.22.1.244/30 id 1 ge 29 le 29

route-map "suppressIST" 1
no permit
enable
match network "suppressIST"
set metric-type type2
set nssa-pbit enable
route-map "suppressIST" 2
permit
enable
match protocol local
route-map "isis-internal" 1
permit
enable
match metric-type-isis internal
exit

As you can see I am just redistributing in one direction ISIS → OSPF. Equally I am redistributing directly attached subnets into OSPF and ISIS.

Really appreciate some advise and examples.

Many thanks in advance.

 

 

icon

Best answer by Ludovico Stevens 1 February 2021, 18:43

Attached are my notes, on the various approaches.

View original

This topic has been closed for comments

5 replies

Userlevel 6
Badge

Linked the other post to this one.

The added information in this post really helps bring it together.

Just wanted to say thanks for all the information.

Userlevel 5

FYI...this topic has been brought up before. 

 

 

 

 

But as it has been explained to me by folks WAAAAAAAY smarter than me, its a traditional ISIS-to-OSPF redistribute and OSPF-to-ISIS accept policy. 

 

However to avoid routing loops there are some extra considerations you need to make.

 

1- You will want a dedicated OPSF broadcast interface between your viST Cores.  This is required on the VSPs  viST core because you want OSPF state changes from your external OSPF routers to be shared between the two VSPs. 

 

2- You want the VSPs to reject routes learnt from the external Routers by specifically marking all routes redistributed from OSPF into ISIS as “external”, as they default to type “internal”.

 

 

no ip alternative-route
router isis
redistribute ospf
redistribute ospf metric-type external
redistribute ospf enable
exit
 
 
Then, in the route-map for the accept policy you specifically match only on ISIS external routes, again discarding only those from the V-IST peer.
 
route-map "reject" 1
no permit
enable
match metric-type-isis external
exit
 
router isis
accept adv-rtr 0.0x.0x enable
accept adv-rtr 0.0x.0x route-map "reject"
exit

where  0.0x.0x is the IST peer.

 

 

alternatively. 

In the past I worked with a colleague(very smart guy) who recommended that instead of rejecting the route you can increase the the preference so the route was only used in the absence of a better route.  But it can get mixed results based on your network. 

This works well in a viST cluster to a single OSPF router.  (Triangle topology)

Example:

route-map "peer-externals" 1
permit
enable
match metric-type-isis external
set ip-preference 120
exit

router isis
accept route-map "peer-externals"
exit
isis apply accept

 

Userlevel 5

Attached are my notes, on the various approaches.

Userlevel 6
Badge

HI Mig,

Thanks for this.

Its good to get the reassurance. It stemmed from a recent GTAC call, when looking at my config they said they routinely redistribute in both directions?

My obvious concern was creating a routing loop, but the said it was easy to configure the route maps to manage it and referred me to professional services.

Obviously on the surface it didn’t seem a straight forward thing to do, so was also double checking what others might do.

Yeah, P2P’s I have already scratched to remove them tomorrow. Plan was to simply create a /29 subnet, give each VSP an IP in and use say VLAN 3401 between each of the VSP’s and just configure OSPF broadcast to share OSPF routing information between each of the VSP’s - think that's what you are referring to.

Anyway, thanks again.

Userlevel 6
Badge +1

Hi Martin,

I’m not in favour to redistribute OSPF -> ISIS and ISIS->OSPF.

This could lead to L3 loops or you need to put in place too complex route maps to avoid it.

I would:

  • remove the OSPF p2p links between VSPs (just leave ISIS between them)
  • setup OSPF between all the VSPs and the S8 chassis.
    • If the edge cluster is not handling routing stuff, it is not needed to integrate them in the OSPF cloud
    • This can be done in a dedicated VLAN to avoid p2p links.
  • if the edge cluster is doing routing stuff:
    • redistribute the isis and static routes from ISIS to OSPF.
    • This is to allow OSPF network to reach items behind the edge cluster without going through the server cluster
  • if the edge cluster is not doing routing stuff
    • redistribute only static routes from ISIS to OSPF.
    •  I don’t have a global vision of the setup and configs but here you can see that advertising only the default route from ISIS into OSPF is enough for the OSPF network be able to reach anything into the Fabric. :wink:

With this:

  • all VSPs have the OSPF routes in their routing table but do not redistribute OSPF routes into ISIS
  • all VSPs advertise into OSPF the ISIS routes and the static routes (in your config, I see only the default routes)
    • With the default routes redistributed (with the VSP as next hop), the S8 will alway be able to reach any subnet reachable by the Fabric

Regards

Mig