cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
743
Views
10
Helpful
8
Replies
techno.it
Beginner

Fabric Border Redudancy

Hello Cisco Community,

We are deploy currently have 2 x fabric borders and 2 x fusion switches.  We are looking for both failure options that is device and link. Borders will be configured as Anywhere border. Fabric underlay will run IS-IS

 

- What are available redundant options we could have between Borders ?

- What routing protocol need to run between -

Fusion to Fusion 

Border to Fusion

Border to Border

 

- Which portion of config can be automated using DNAC and which need to configured manually ?

 

Any insights would be very helpful

 

1 ACCEPTED SOLUTION

Accepted Solutions

Sure no problem.

"Both Borders having uplink to fusion switches, then iBGP between borders not necessary, running ISIS would be suffice and this can be automated using automation."

I will take this scenario as "Each border has a link to F1 and F2", if that is the case, yes, iBGP will not be needed in case B1F1 fails, as B1F2 will still be there, in case B1F1 and B1F2 fails but B1 is still up (advertising its loopback0), then the traffic is blackholed. iBGP can add a secondary redundant link but that is all.

 

ISIS will never add any level of redundancy for fabric traffic, as it only runs in GRT, it provides redundant paths to advertise and reach Lo0 of every node, redundant paths are achieved with eBGP/iBGP sessions per VRF to Fusions or other Borders.

 

"Border having single link to upstream fusion ( B1 to F1 & B2 to F2), then iBGP is required to achieve redudancy if B1 or link between B1 to F1 fails."

 

Right, if you only have B1F1 and B2F2, if B1F1 fails but B1 loopback is still advertised, all Edges could still encapsulate traffic to B1 (as its Lo0 is still reachable), once packets arrive B1, it will have no route to forward the traffic out, dropping it. If iBGP is configured in that VRF/VN, if B1F1 fails, B1 can still send the traffic via the iBGP route with the peering in B1B2.

 

 

 

View solution in original post

8 REPLIES 8
jalejand
Cisco Employee

A link between 2 Borders can add additional redundancy for both underlay and overlay (VRFs), this link be a trunk or subinterfaces to carry ISIS between borders and iBGP for South-North traffic.

 

For Borders to Fusion eBGP is a must, this is part of the Layer 3 handoff configuration.

Fusion to Fusion you can add anything you want, in the end you are likely to redistribute BGP to your IGP of preference after the Fusions.

 

DNAC will only automate:

 

BGP vpnv4 between CPs and Borders, this does not provide redundancy, it is used for BGP-LISP signaling/control plane operation.

SVIs, VRFs and BGP coniguration in Borders when the Layer 3 handoff is configured, Fusion VRFs, SVIs, VLANs, Route-Leaking maps and BGP area always manual

 

ISIS between Borders can be automated with LAN automation

iBGP between Borders are always manual.

 

Please refer to this document when confiuring fusion routers and route leaking.
https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/dna-center/213525-sda-steps-to-configure-fusion-router.html

 

When configuring iBGP between Borders, keep in mind that you need to do an additional step if you are using Anywhere borders to avoid advertisement loops, I would suggest against running anywhere borders and run external-only borders if both Borders will receive the same exact BGP routes from fusions (aka mirrored borders), they won't need anything but a default route to reach external fabric destinations.

 

For more info about border redundancy and iBGP considerations, you can check this session:

https://www.ciscolive.com/global/on-demand-library.html?search=borders%20sda&search=borders+sda#/session/1589571198356001M56T

 

 

 

 

Thanks @jalejand

 

Lets suppose we have two possible cases

Both Borders having uplink to fusion switches, then iBGP between borders not necessary, running ISIS would be suffice and this can be automated using automation.

 

Border having single link to upstream fusion ( B1 to F1 & B2 to F2), then iBGP is required to achieve redudancy if B1 or link between B1 to F1 fails.

 

Please correct if am wrong.

 

 

Sure no problem.

"Both Borders having uplink to fusion switches, then iBGP between borders not necessary, running ISIS would be suffice and this can be automated using automation."

I will take this scenario as "Each border has a link to F1 and F2", if that is the case, yes, iBGP will not be needed in case B1F1 fails, as B1F2 will still be there, in case B1F1 and B1F2 fails but B1 is still up (advertising its loopback0), then the traffic is blackholed. iBGP can add a secondary redundant link but that is all.

 

ISIS will never add any level of redundancy for fabric traffic, as it only runs in GRT, it provides redundant paths to advertise and reach Lo0 of every node, redundant paths are achieved with eBGP/iBGP sessions per VRF to Fusions or other Borders.

 

"Border having single link to upstream fusion ( B1 to F1 & B2 to F2), then iBGP is required to achieve redudancy if B1 or link between B1 to F1 fails."

 

Right, if you only have B1F1 and B2F2, if B1F1 fails but B1 loopback is still advertised, all Edges could still encapsulate traffic to B1 (as its Lo0 is still reachable), once packets arrive B1, it will have no route to forward the traffic out, dropping it. If iBGP is configured in that VRF/VN, if B1F1 fails, B1 can still send the traffic via the iBGP route with the peering in B1B2.

 

 

 

View solution in original post

Thanks @jalejand. Its super clear

 

Is there a need for IGP (ISIS) to run between borders?

 

Each border has a link to F1 and F2", if that is the case, yes, iBGP will not be needed in case B1F1 fails, as B1F2 will still be there, in case B1F1 and B1F2 fails

It just adds another level of redundancy for Lo0 reachability which also includes optimal path election.

 

For example, you have B1F1 and B2F2, with an Edge E1 dual homed to B1 and B2.


In case B2F2 fails, B2 default route to reach external destinations in GRT (like, when being managed by DNAC or when attempted to be logged in via SSH), will now point to an Edge node or Intermediate node, causing sub-optimal traffic flow.


Expected:

B2F2 fails, 0.0.0.0/0 points B1 via ISIS then out to F1

 

 

Hello @jalejand

you mentioned above that ISIS link between borders can be automated with LAN automation. 

Does it mean that in addition to choosing the ports which connect to the edge or intermediate, I also need to select the querlink ports of both borders? 

 

One more question, is the following statement correct?

If we only have B1F1 and B2F2 connections, and the border type is external only, only ISIS link between the borders will be needed. But if the border type is internal or anywhere, then iBGP per VN between the borders is neccessary.

 

Thanks for your answer.

Hi Junyi

ISIS link between borders can be autoamted with LAN auto, check:

https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/dna-center/215336-lan-automation-step-by-step-deployment.html#anc39

Check: 3. Configuring additional links after Lan auto is stopped.

 

And now to your other question :):

 

If we only have B1F1 and B2F2 connections, and the border type is external only, only ISIS link between the borders will be needed. But if the border type is internal or anywhere, then iBGP per VN between the borders is neccessary.


Regardless if they are external or anywhere, the iBGP between Borders provides additional redundancy in case of Fusion uplink failure, both roles can get benefit from the iBGP link. Only for anywhere/internal, route-tagging with communities is needed to prevent LISP-BGP advertisement loops.

Thanks for your prompt reply @jalejand.

Now it is clear for me.