Connetion between two borders nodes (Anywhere)

[oussama.benkraiem]

Hi 

I have two Border nodes Anyware and two fusion routers 
i configure EBGP bentween two borders (Anywhere) and two fusion 

i configure iBGP between the two border (Anywhere) 

B1-->Fusion1 : EBGP

B2-->Fusion2 : EBGP

B1-->B2 : iBGP

when i loss the connection between B2 and Fusion router i check my routing table on B2 i see the default route 0.0.0.0 through the EDGE node with ISIS so in this stat i have my problem 

[Joshua Marks]

You are receiving the default route from the edge because iBGP uses a higher administrative distance than IS-IS. Therefore Border 2 will prefer the default route which has been redistributed into IS-IS over the iBGP default route.

I would recommend 2 options:

1. Use IS-IS to connect the Border routers instead of iBGP, or

2. Use a new BGP AS on Border 2 to form an eBGP neighbourship instead of iBGP and advertise only the default route between them. With this method, you will need to ensure your eBGP route via the fusion router is more preferred than the eBGP route via Border 1.

[Jonathan Cuthbert]

Can I ask why you are using Anywhere border nodes?
Based on your topology, external-only appears to be the best option. 
In fact, external-only is really the best option for 95+% of use cases.

[oussama.benkraiem]

Hi

Because in the future i will connect my DataCenter ( ACI ) directly to the border node for this reason i think the best solution is anyware border 

i can't work with one border external and the other border internal because in my architecture i will guard the symmetric

[andy!doesnt!like!uucp]

@Jonathan Cuthbert 

i have always been sceptic about need of E-W routing interconnecs in legacy scenarios with similar topology :0) but looks like in SDA it's mandatory (i'd be glad to be mistaken :0)

so... can we replace "recommended" iBGP with unified fabric site underlay proto here?  

[Jonathan Cuthbert]

---

 but looks like in SDA it's mandatory (i'd be glad to be mistaken :0)

---

If I may answer your question with another question:

What do you think IBGP between redundant border nodes is "mandatory?"

Two of the most common questions or common misconceptions in SD-Access revolve around these two subjects:

1. What kind of border node should I provision (Internal-Only, External-Only, and Anywhere)?
2. Should I use IBGP between my redundant border nodes?

Interestingly, both of these questions came up in this post. 

1. What kind of border node should I provision (Internal-Only, External-Only, and Anywhere)?

I am currently recording some content for our YouTube channel that I hope will add additional clarity as an answer to this question.  To sum things up here, +95% of deployments should use external-only Border Nodes. 

Here is the diagram provided in the original question.

These should be external-only border nodes. Based on the information provided, they should not be anywhere border nodes.  It's adding configuration (and thus potential complexity/interactions) that are unneeded. 

Adding in even further, there should absolutely be crosslinks here.  This topology is a square. Square topologies do not provide the resilience and failover and deterministic convergence needed in networks today.  They should be avoided unless there is simply not enough fiber to make it possible.  Saying another way: avoid them unless there is absolutely no other choice.  I covered this heavily in the SD-Access CVD.  "build triangles, not squares, to take advantage of equal-cost redundant paths for the best deterministic convergence."

https://www.cisco.com/c/en/us/td/docs/solutions/CVD/Campus/cisco-sda-design-guide.html#Layer_3_Routed_Access_and_SDA_Design

https://www.cisco.com/c/en/us/td/docs/solutions/CVD/Campus/cisco-sda-design-guide.html#External_Connectivity_Design_Considerati

           2.  Should I use IBGP between my redundant border nodes?

This is a question that is pretty large in scope to answer.  There is no definitive yes and definitive no.  It is all based on what the network is trying to accomplish along with the topology.  I am working on answering this question in all the variations and permutations in a guide I am working on. 

Bear in mind that when we are discussing IBGP, we are asking two questions:

1. Should I use IBGP between my redundant border nodes (in the underlay)
2. Should I use IBGP between my redundant border nodes (in the overlay)

It's insufficient to just answer one and not the other, as they both accomplish completely different things and neither are strictly due to SDA.  The underlay question has to do with how to avoid using the IGP to 'heal' the BGP domain and the overlay question has to do with how to address VRFs continuity in BGP while providing deterministic failover and redundancy. 

[andy!doesnt!like!uucp]

@Jonathan Cuthbert 

i would answer then in this way: what if we remove LISP & stay with MPBGP/EVPN for overlay CP? :0)  

[Jonathan Cuthbert]

---

@andy!doesnt!like!uucp wrote:

@Jonathan Cuthbert 

i would answer then in this way: what if we remove LISP & stay with MPBGP/EVPN for overlay CP? :0)  

---

This is a bit of a detour from the original conversation and perhaps best addressed in a whole new post.

Would you mind opening a whole new question?  Happy to answer there.

[andy!doesnt!like!uucp]

@jonathan

ok. let's come back to dynamic protocols on the BN's E-W & North perimeter. is dynamic protocol selection there only the subject of redundancy & fast convergency or also of adding some control information into LISP neither ISIS nor OSPF can provide?

P.S. i've found something optimistic. so other protocols r allowed , but not recommended. Why?

[Michal Rzepecki]

Do I understand correctly that in the case of redundant borders running single AS, you still allow no iBGP session between them? Where I can find the guide that you were working on?

[jalejand]

Create an IS-IS peering between both borders using either an SVI or L3 interface, you can do it either manually or using lan automation.

Then the default route will point to Border 1 using ISIS and this only is relevant for INFRA_VN/GRIB.

If you still want  to use iBGP (even though using ISIS has no difference) you can use administrative distance to use iBGP:

ip access-list standard 95
10 permit 0.0.0.0
router isis
distance 201 0.0.0.0 255.255.255.255 95

For VRF/VN default route communication, that is another story. But as you are mentioning IS-IS, I assume this is all-about underlay