cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2216
Views
10
Helpful
4
Replies

SDA Underlay: Has Anyone Had Issues Implementing ISIS FRR?

ChuckMcF
Level 1
Level 1

Has anyone else implemented ISIS as their underlay IGP for their SDA network? If so did you implement FRR? And if so, have you had any issues after implementation? Did you need to turn on micro segmentation protection? Appreciate any thoughts.

1 Accepted Solution

Accepted Solutions

jedolphi
Cisco Employee
Cisco Employee

Hi Chuck,

DNA Centre LAN automation pushes ISIS to underlay. The LAN automation deployment guide is here:

https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/tech_notes/b_dnac_sda_lan_automation_deployment.html

LAN auto does not push FRR currently.

Alernatively you can build your underlay manually if you need to, so OSPF or EIGRP or ISIS.

I have numerous customers using ISIS underlay without FRR and they have no complaints. Are you aware of a scenario where FRR would be needed? I personally have not seen one.

I usually try to keep my networks as close to 'standard' (in this case, standard = the configuration pushed for DNA Centre LAN automation) as possible and deviate only when necessary. You can add FRR to your manual ISIS underlay if you wish, but first I would suggest trying without it. Also please note that underlay must have p2p routed interfaces between fabric nodes, not routing on SVIs.

Best regards, Jerome

 

 

 

View solution in original post

4 Replies 4

jedolphi
Cisco Employee
Cisco Employee

Hi Chuck,

DNA Centre LAN automation pushes ISIS to underlay. The LAN automation deployment guide is here:

https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/tech_notes/b_dnac_sda_lan_automation_deployment.html

LAN auto does not push FRR currently.

Alernatively you can build your underlay manually if you need to, so OSPF or EIGRP or ISIS.

I have numerous customers using ISIS underlay without FRR and they have no complaints. Are you aware of a scenario where FRR would be needed? I personally have not seen one.

I usually try to keep my networks as close to 'standard' (in this case, standard = the configuration pushed for DNA Centre LAN automation) as possible and deviate only when necessary. You can add FRR to your manual ISIS underlay if you wish, but first I would suggest trying without it. Also please note that underlay must have p2p routed interfaces between fabric nodes, not routing on SVIs.

Best regards, Jerome

 

 

 

We implemented ISIS manually back before LAN automation was available. I recently noticed that link outages would cause a 5-10 second delay in re-routing and therefore thought FRR would be a good addition. We're now having an issue with CTS that we are starting to believe is ISE related. This issue started to show it's head right around the time I implemented FRR so we thought it may be related. Consequently I removed FRR from all devices, the issue remained, and we've now troubleshot it to a CTS issue.

 

Per your reply's recommendation I will not add FRR back to our underlay. Thank you for your response!!

 

Hi Chuck,

Below is a copy of the ISIS config currently pushed by LAN automation (note it may change later, so anyone reading this in 2021 might want to re-check!). You can use it as a template for your manual ISIS deployment. Obviously change IP addresses, NET address, etc. to match your network. In the networks I've worked on underlay link failure convergence has been very very quick i.e. fraction of a second. Multi-second convergence is definitely not right and we can do better.

interface Loopback0
description Fabric Node Router ID
ip address 192.168.0.67 255.255.255.255
ip router isis
clns mtu 1400
!
interface GigabitEthernet1/0/1
description Fabric Physical Link
no switchport
dampening
ip address 192.168.0.102 255.255.255.252
ip router isis
logging event link-status
load-interval 30
bfd interval 500 min_rx 500 multiplier 3
no bfd echo
clns mtu 1400
isis network point-to-point
!
router isis
net 49.0000.1921.6800.0067.00
domain-password cisco
metric-style wide
log-adjacency-changes
nsf ietf
bfd all-interfaces
!

 

Thank you for providing this. Ours is rather similar with the exception that we're using authentication mode MD5 and a key-chain, and our bfd interval is 50 instead of 500 I applied bfd on each specific interface.