01-22-2021 01:49 AM - last edited on 01-25-2021 01:50 PM by Jonathan Cuthbert
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
01-22-2021 07:29 PM
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.
01-25-2021 01:55 PM
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.
01-25-2021 02:50 PM
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
02-15-2021 12:43 PM - edited 02-15-2021 12:59 PM
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?
02-15-2021 01:55 PM
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:
Interestingly, both of these questions came up in this post.
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."
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:
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.
02-16-2021 12:01 AM
i would answer then in this way: what if we remove LISP & stay with MPBGP/EVPN for overlay CP? :0)
02-16-2021 05:38 AM
@andy!doesnt!like!uucp wrote:
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.
02-16-2021 09:27 AM - edited 02-16-2021 11:22 AM
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?
10-26-2023 09:28 PM
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?
01-28-2021 03:39 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide