Default routes in SD-Access Dual External Border

[hassan_yousif2005]

Hello,

In case we have dual collocated EBN/CP , the two  border nodes are the only exit out of the fabric so they are configured as an external border node.

The question is, will both EBNs generate a default route ? and will the clients traffic that leaving fabric be load balanced between the two EBNs?

Thanks

Hassan

[Mike.Cifelli]

The question is, will both EBNs generate a default route ? and will the clients traffic that leaving fabric be load balanced between the two EBNs?

This will all depend on how you have interconnected and configured your Fusion router/s (FRs). I assume that since you have dual EBNs that you have dual FRs? If so, each EBN would peer with each FR via eBGP and then it is on you to manually redistribute DRF into each respective VN from the FRs that you wish to allow routing beyond (outside) of your fabric. You could enable load balancing via setting maximum-paths in your bgp configuration. That setting will essentially install multiple paths in the RIB for load sharing.

Good luck & HTH!

[bofele]

Edge devices will be configured with PETR, that is default gateway in LISP world. Since you have 2, edge devices will LB between them. Traffic will get to borders and then it is a matter of routing table decision. I guess you will have eBGP session with fusion devices which will be preferred path to external destinations, meaning traffic will get to border and leave fabric.

Hope this answers your Q.

B.

[AbdellahBricha4369]

Asuming the shared services connected to both fusion routers.

What border role can be  configured in this situation?  internal, external or both.

Is the default route consideres external?

[jalejand]

External Borders are considered Proxy-ETRs, no default route is ever generated by these, if these Borders receive a default route via eBGP from their attached Fusions, these can be redistributed on IS-IS (manually) to allow underlay/Global RIB/non LISP default route towards the Edges.

On the other hand, for LISP, whenever a Proxy-ETR is configured, it is expected that unknown destinations from the Edge nodes are forwarded out to Borders that knows how to reach these, these are by definitions, External Borders.

An internal border is a Border who, regardless if it has a default route or not, it can't be used to reach external destinations, it can only forward traffic which was explicitly imported to him via, for example, BGP database imported route, this is, known networks via eBGP.

When an External Border or Anywhere border is configured, the use-petr command on Edges is configured with the sole purpose of creating a LISP action called "Encapsulation to ProxyETR", this means, encapsulate traffic only to the External/Anywhere borders for any unknown destination.

Internal borders aren't considered Proxy ETRs, because of this, a LISP resolution for a prefix which is not explicitly imported into LISP is replied in the form of a negative entry, to be natively forwarded (using the RIB contents) from the Edge nodes, which is usually insufficient to forward the traffic, at least on SDA.

In summary, EBNs doesn't generate a default route, they are configured as Proxy-ETRs for the Edge node perspective to encapsulate any unknown traffic towards a Border which is expected to have a default route by itself.

[mlohman1]

Hello Sir. This is great. For internal borders that are connected to a legacy date center environment, non-aci, can the data center leverage the fabric to reach external services/internet?