Using the same INs for two separate fabrics

[Mike.Cifelli]

Does anyone knows if there is a CVD for using the same INs with two separate fabrics.  If not, will this ever be road-mapped? Also, what are technical opinions on a scenario like this?  I am attaching a screenshot in an attempt to depict what I am talking about. 

Technically speaking, we believe it is possible to accomplish using the same INs with separate fabrics.  Separate fabrics consisting of separate DNAC clusters, ISE clusters, Fusions, EBNs, CPNs, and edge nodes. 

Here is why we think it is possible:

The INs are simply a means of transport and are connected via L3 p2p links.  In theory, the INs should only be added in DNAC inventory for IOS upgrades, etc.  However, the INs should not get provisioned so that means they are not vrf aware.  As long as the INs are running the same protocol across the board then there should not be any issue there.  We could even run the same instance of whatever protocol IMO.  The only thing would be the advertised routes into the GRT for the underlay.   Two options would be to run side A with a default, then side B with more specifics for side B underlay access.  Or simply run more specific routes for both sides so that the respective admins can manage their underlay devices.  The separate FRs would advertise DFR via bgp to the EBNs for their respective VNs for each fabric.  Then obviously each DNAC cluster would provision their NADs accordingly so each side's edge nodes would have no issues.

Anything missing? Please share opinions or ask questions.  Thanks in advance.

[jedolphi]

Hi Mike,

Some thoughts below, perhaps not well structured, but hopefully useful:

For the scenario you describe there is no CVD. Cannot comment on whether there will be such a CVD later, but i think probably not, since CVDs typically are written to accommodate most common questions and interests from the field :)

Please note that fabric nodes won't follow default routes to find other fabric nodes e.g. FE looking for RLOC of border will not work with 0.0.0.0/0. This stops a default route from black holing a fabric domain.

Regarding your questions, this is a massive topic. E.g. mixing underlay routing domains (presumably from different companies) and security consequences of that.

You are correct, the scenario you have drawn is technically possible as today the intermediate nodes simply forward packets between fabric nodes. Today the intermediate nodes don't care which overlay (fab1-vn1 or fab2-vn1) is encapsulated in IP/UDP/VXLAN. From perspective of IN an overlay is just IP coming in one port and going out another.

Later on we *may* have IN further integrated with fabric e.g. IN looking into VXLAN packets to garner some details about what is inside for assurance purposes. If this functionality comes then it's possible you'll be cutoff from that by virtue of having two fabric domains traversing same IN. I think it's too early to say anything concrete about it though.

Also this scenario might break LAN automation (LAN auto seed node needs to be in a particular DNAC, in a particular site), but you can opt not to use LAN auto and manually deploy fabric edge switches instead.

Also QOS policy might be a little more challenging on INs e.g. if IN1 has different QOS rules than IN4. Not a show stopper, but might require some manual coordination of policy across both fabrics.

Generally speaking, putting on my own personal opinion hat, the further you deviate from 'standard' network designs the more manual stuff you need to do yourself, and possibly you'll be cutoff from roadmap features in future since the features typically aren't developed for corner cases in early releases :)

But yes, I think what you have drawn is achievable.

If you're looking for an endorsement of the design I would recommend engaging your Cisco SE/AM/Partner and asking for an SDA design review please.

Best regards, Jerome