DNA Fusion Router - Device Model

[d-wade]

Hi everyone!

I've looked over the official list of DNA compatible devices. However, I have not found a document outlining the requirements for a device to be considered for the role of the Fusion router. From reading through documentation, I can gather the Fusion will need to perform the following:

- IP routing

- Support for dynamic routing protocols (ISIS, BGP, EIGRP, etc.)

- VRF support

- Route redistribution

Since these requirements can be met using a true router (ISR/ASR) or a L3 switch (Catalyst), what devices have been used in environments (lab/prod)?

Just looking to see what devices have been tested and are viable options...

Thanks!

[kumaamit]

DNA-SDA solution requires Fusion router.

Today the Dynamic Network Architecture Software Defined Access (DNA-SDA) solution requires a fusion router to perform VRF route leaking between user VRFs and Shared-Services, which may be in the Global routing table (GRT) or another VRF. Shared Services may consist of DHCP, Domain Name System (DNS), Network Time Protocol (NTP), Wireless LAN Controller (WLC),  Identity Services Engine (ISE), DNAC components which must be made available to other virtual networks (VN’s) in the Campus. Thus by creating Border Gateway Protocol (BGP) peerings from the Border Routers to the Fusion Routers, on the Fusion Router the fabric VRF’s subnets which need access to these shared services will be leaked into GRT, and vice-versa. Route maps can be used to help contain routing tables to subnets specific to SDA Fabric.

[d-wade]

Thank you. On top of the logical requirements, are there any compute or memory requirements? Does the certain Fusion device need a certain amount of memory or CPU in order to handle all the processes taking place?

[kumaamit]

The memory and processing requirements are load balanced as the control plane functionality is automated.
DNA Center automates the configuration of the control plane functionality. For redundancy, you should deploy two control plane nodes to ensure high availability of the fabric, as a result of each node containing a duplicate copy of control plane information. The devices supporting the control plane should be chosen to support the HTDB, CPU, and memory needs for an organization based on fabric endpoints.

[d-wade]

I see the explanation is for the control plane node. However, I am looking for compute requirements of the fusion router.

Is there any documentation available for that?

[kumaamit · Accepted solution]

we don't have a documentation for compute requirements of fusion router. we only have the configuration guide. link to it is following:

https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/dna-center/213525-sda-steps-to-configure-fusion-router.html

[d-wade]

Thank you. For the future, I would recommend providing a document on compute requirements or, at the minimum, a list of recommended devices that can be used as the Fusion router role. I know the Fusion router isn't necessary part of the fabric, but it plays a vital role during the planning phases of rolling out DNA.

[shillings]

Is this for a lab or production network? If the latter, then a Cisco firewall makes more sense than fusion router, cost permitting. Better to punt inter-VRF traffic up to the firewalls, thereby properly securing the networks from one another, which is presumably the aim of separate VRFs in the first place. You only need to factor in the stateful performance hit on the firewall - i.e. not IPS. Try to keep VRFs to a minimum and rely more on TrustSec.

[rays]

Hi can you do SDA without the fusion device and still achieve full segmentation using SGTs? Or do you at least require a fusion router to access shared services or can shared services be placed in the same VN as all other traffic and just rely on SGTs for segmentation?

Thanks

[shillings]

Not 100% sure what you're asking so I've covered a few angles.

Yes, you can place all your corporate endpoints into a single VN and leverage micro segmentation. Better to minimise the number of VNs anyway although a single VN won't work for everyone. Typically, you'd also want a separate VN for Guest traffic as well.

As for the SDA fusion firewall requirement, it's only really necessary in order to secure endpoint-to-endpoint traffic flows where both endpoints reside within the SDA fabric but they exist within a different VN to one another. Otherwise, the amount of route leaking required undermines the whole point of applying marco segmentation in the first place.

I don't see a need for a SDA fusion firewallI for traffic flows between a fabric endpoint and server located in your DC, assuming the fabric endpoint traffic feeds into the same VRF as the server or both client and server reside in the global table. Of course, you'd still have some specific route leaking so that traffic in each VRF can reach your DHCP server, for example.

There's nothing to stop you punting all fabric endpoint-to-server traffic through a firewall anyway but that's down to your security policy. You have to consider if a L3 stateful firewall will break any of your client-server traffic flows though.

Lastly, your shared services such as DNAC and ISE will typically reside in the global table but you can put them in a dedicated VRF if you want to.